Distributed Database System

A distributed database is basically a database that is not limited to one system, it is spread over
different sites, i.e, on multiple computers or over a network of computers. A distributed database
system is located on various sites that don’t share physical components. This may be required
when a particular database needs to be accessed by various users globally. It needs to be
managed such that for the users it looks like one single database.

Types:

1. Homogeneous Database:
In a homogeneous database, all different sites store database identically. The operating system,
database management system, and the data structures used – all are the same at all sites. Hence,
they’re easy to manage.

2. Heterogeneous Database:
In a heterogeneous distributed database, different sites can use different schema and software
that can lead to problems in query processing and transactions. Also, a particular site might be
completely unaware of the other sites. Different computers may use a different operating system,
different database application. They may even use different data models for the database. Hence,
translations are required for different sites to communicate.

Distributed Data Storage :

There are 2 ways in which data can be stored on different sites. These are:

1. Replication –
In this approach, the entire relationship is stored redundantly at 2 or more sites. If the entire
database is available at all sites, it is a fully redundant database. Hence, in replication, systems
maintain copies of data.

This is advantageous as it increases the availability of data at different sites. Also, now query
requests can be processed in parallel.
However, it has certain disadvantages as well. Data needs to be constantly updated. Any change
made at one site needs to be recorded at every site that relation is stored or else it may lead to
inconsistency. This is a lot of overhead. Also, concurrency control becomes way more complex
as concurrent access now needs to be checked over a number of sites.

2. Fragmentation –
In this approach, the relations are fragmented (i.e., they’re divided into smaller parts) and each of
the fragments is stored in different sites where they’re required. It must be made sure that the
fragments are such that they can be used to reconstruct the original relation (i.e, there isn’t any
loss of data).
Fragmentation is advantageous as it doesn’t create copies of data, consistency is not a problem.
Fragmentation of relations can be done in two ways:

Horizontal fragmentation – Splitting by rows –

The relation is fragmented into groups of tuples so that each tuple is assigned to at least one
fragment.
Vertical fragmentation – Splitting by columns –
The schema of the relation is divided into smaller schemas. Each fragment must contain a
common candidate key so as to ensure a lossless join.

In certain cases, an approach that is hybrid of fragmentation and replication is used.

Applications of Distributed Database:

It is used in Corporate Management Information System.

It is used in multimedia applications.
Used in Military’s control system, Hotel chains etc.
It is also used in manufacturing control system.

A distributed database system is a type of database management system that stores data across
multiple computers or sites that are connected by a network. In a distributed database system,
each site has its own database, and the databases are connected to each other to form a single,
integrated system.

The main advantage of a distributed database system is that it can provide higher availability
and reliability than a centralized database system. Because the data is stored across multiple
sites, the system can continue to function even if one or more sites fail. In addition, a distributed
database system can provide better performance by distributing the data and processing load
across multiple sites.
There are several different architectures for distributed database systems, including:

Client-server architecture: In this architecture, clients connect to a central server, which manages
the distributed database system. The server is responsible for coordinating transactions,
managing data storage, and providing access control.

Peer-to-peer architecture: In this architecture, each site in the distributed database system is
connected to all other sites. Each site is responsible for managing its own data and coordinating
transactions with other sites.

Federated architecture: In this architecture, each site in the distributed database system maintains
its own independent database, but the databases are integrated through a middleware layer that
provides a common interface for accessing and querying the data.

Distributed database systems can be used in a variety of applications, including e-commerce,

financial services, and telecommunications. However, designing and managing a distributed
database system can be complex and requires careful consideration of factors such as data
distribution, replication, and consistency.
Advantages of Distributed Database System :

1) There is fast data processing as several sites participate in request processing.

2) Reliability and availability of this system is high.
3) It possess reduced operating cost.
4) It is easier to expand the system by adding more sites.
5) It has improved sharing ability and local autonomy.
Disadvantages of Distributed Database System :

1) The system becomes complex to manage and control.

2) The security issues must be carefully managed.
3) The system require deadlock handling during the transaction processing otherwise
the entire system may be in inconsistent state.
4) There is need of some standardization for processing of distributed database
system.

Distributed databases often involve complex coordination mechanisms to ensure data

consistency across multiple nodes. Two critical aspects in this context are Commit
Protocols and Locking Mechanisms.

Commit Protocol in DBMS

The concept of the Commit Protocol was developed in the context of database systems. Commit
protocols are defined as algorithms that are used in distributed systems to ensure that the
transaction is completed entirely or not. It helps us to maintain data integrity, Atomicity, and
consistency of the data. It helps us to create robust, efficient and reliable systems.

A commit protocol ensures that a transaction in a distributed database either completes fully
(commit) or is entirely rolled back (abort), even in the presence of failures. The most commonly
used protocol is the Two-Phase Commit Protocol (2PC).
Two-Phase Commit Protocol (2PC)

The 2PC ensures atomicity in distributed transactions. It consists of two phases:

Prepare Phase:
The Coordinator node sends a Prepare message to all participating nodes (or cohorts)
involved in the transaction.
Each cohort checks if it can commit the transaction. If it can, it sends a Yes response to the
coordinator; otherwise, it sends No.

Commit Phase:
If all cohorts respond with Yes, the coordinator sends a Commit message to all cohorts, and
the transaction is committed.
 If any cohort responds with No, the coordinator sends a Rollback message, and all cohorts
abort the transaction.

Example:

Imagine an e-commerce system with a distributed database:

Node A: Updates the inventory.

Node B: Updates the payment records.
Node C: Sends a notification to the customer.

A transaction involves updating inventory, processing payment, and sending a notification.

In the Prepare Phase, the coordinator asks Nodes A, B, and C if they can commit:
Node A checks if inventory update is possible.
Node B verifies if the payment record is valid.
Node C ensures the notification system is available.

If all nodes respond Yes, the coordinator proceeds to the Commit Phase and informs all nodes
to commit the transaction. Otherwise, it aborts.

2. Locking Mechanisms

Locks ensure consistency and prevent conflicts in distributed transactions. Locks can be:

Shared Locks (Read Locks): Allow multiple transactions to read but not write.
Exclusive Locks (Write Locks): Allow a single transaction to write and block others.

Two-Phase Locking Protocol (2PL)

This is a common locking protocol used in distributed databases:

Growing Phase:
A transaction acquires all necessary locks but cannot release any.
Shrinking Phase:
A transaction releases locks but cannot acquire any new ones.

2PL ensures serializability, meaning the results of transactions are the same as if they were
executed sequentially.
Example:

Consider a banking application:

Transaction 1: Transfers ₹500 from Account A to Account B.

Transaction 2: Reads the balance of Account A and Account B.
To avoid conflicts:

Transaction 1 acquires an exclusive lock on Account A and Account B to perform the transfer.
Transaction 2 tries to acquire a shared lock on Account A and Account B to read the balances
but is blocked until Transaction 1 releases the locks.

This ensures no intermediate states (e.g., debited from A but not yet credited to B) are visible to
Transaction 2.
Challenges

Commit Protocols:
High latency due to multiple communication steps.
Vulnerable to failures during the process (handled by timeouts and retries).
Locking Mechanisms:
Risk of deadlocks (when two transactions wait for each other's locks).
Reduced concurrency due to lock contention.