Distributed Database systems

A distributed database is a database that is composed of two or more files that are situated in different locations either on the same network or on entirely different networks. Precisely, in this type of database, portions of the database are stored in multiple physical locations and processing is distributed among the different database nodes. This type of database has a number of features. The database is not a loosely connected file system, it is hardware independent, has a distributed transaction management, the operating system is independent, and a distributed query process. Additionally, distributed databases can either be homogenous or heterogeneous. In a homogeneous distribution system, all the physical locations run the same operating systems and database applications as well as the same underlying hardware (Elvis & Godbole 361-370). These systems appear to the user as a single system and tend to be easier to manage and design. For a distribution database to be homogenous, the data structures at each location must either be compatible or identical. On the other hand, in a heterogeneous distributed database, the operating system, hardware, and database applications tends to be different at each location. Different sites may use different software and schemas though this difference can make transaction and query processing to be challenging.

How concurrency control is done in a distributed database

Concurrency control is a fundamental aspect in a distributed database system design. Precisely, concurrency allows numerous transactions to be performed simultaneously in such a way that the collection of manipulated data item is left in a consistent state (Mahnaz & Mahdi 200-205). Additionally, concurrency control allows the users to access a database in a multi-programmed fashion, while at the same time preserving the illusion that user is performing alone on a dedicated system.

In distributed systems, concurrency control is achieved through a program that is referred to as the scheduler. This program helps in ordering the operations of a transaction in such a way that the resulting logs is serializable.  Concurrency control in a distributed database system occur in two ways, which are not limited to locking approach and non-locking approach. Locking approach occurs when two phase lock is broadly used and purpose for distributed database system (Mahnaz & Mahdi 200-205). Precisely, before the distributed system can access some components of the database, it must embrace a locking system such that each transaction has to obtain a lock. Apparently, if such a component is locked by another transaction, the access request will be blocked and the consequential transaction has to wait. Additionally, a two phase locking tends to be more serious especially due to the fact that it contributes to the occurrence of a dreadlock challenge, which in most cases contributes to a high communication cost.

On the other hand, the non-locking approach is categorized into two types, which are the serialization Graph Testing (STG) and the Timestamp Ordering (TO). Timestamp ordering uses a special transaction timestamp for determining the serialization order, and it is categorized further into three different modes which are not limited to optimistic, conservative and basic modes (Mahnaz & Mahdi 200-205). For the case of the Serialization Graph Testing, it has the most attractive log class especially due to its ability of holding the largest known class of serializable logs.

What happens when one or more servers go offline and online in a distributed database system

When one or more servers goes offline or online in a distributed database system, the user can perform data modifications and can issue the ADD COLUMN DDL and the ALTER COLUMN commands (Paul 56). When one or more servers go offline, the system becomes inactive, and it is said to be quiesced, and this means that all the activities on the published tables at al nodes has been suspended. In addition, when one or two servers are offline, the system ensures that each of the nodes have received all the changes from the other nodes.

How replication occurs in a distributed database system

Database replication entails the aspect of copying of data from a database in one server or computer to a database in another in order for all users to share the same level of information. In a distributed database system, replication tends to occur in such a way that copying of data from a database can take place without interfering with the operations of the other users (Ray 121). Precisely, the users can easily access data without interfering with the work of others.

Unique challenges that Developers face when using distributed databases

Developers face a number of challenges when using distributed database systems. For example, developers face the challenge of data security, especially due to the fact that in the present world, data breach has not only been so costly, but ruins the goodwill and reputation of a company. Additionally, developers have also been experiencing the challenge of increasing data volumes (Imed n.p). When the data generated explores, it becomes challenging for the companies to keep up. Moreover, the developers are also facing the limitations of scalability, growing complexities in landscape, and decentralized of data management.

Works Cited

Elvis Foster, and Godbole Shripad. “Distributed database systems.” Database Systems. Apress, Berkeley, CA, 2016. 361-370.

Imed Bouchrika. Challenges for a Distributed System. Posted on 21^st September, 2013. Accessed from, http://www.ejbtutorial.com/distributed-systems/challenges-for-a-distributed-system

Mahnaz Nasseri,, and Mahdi Seyed Jameii. “Concurrency control methods in distributed database: A review and comparison.” 2017 International Conference on Computer, Communications and Electronics (Comptelix). IEEE, 2017.

Paul, Sujoy. Pro Sql Server 2008 Replication. Berkeley, CA: Apress, 2009. Internet resource.

Ray, Chhanda. Distributed Database Systems. Delhi: Pearson, 2009. Internet resource.