Distributed Database Replication, Concurrency, and Atomicity
Data Replication in Distributed Databases
Replication in a distributed database, where each node holds a complete copy, impacts data availability and system cost. While it ensures high availability and reliability, especially for read-intensive systems, it incurs high storage and write costs. The trade-off is between availability and cost: higher availability necessitates constant uptime, increasing expenses.
For instance, a replicated database offers excellent availability but at the expense of high write costs.
Concurrency Control Mechanisms
Concurrency control addresses isolation and consistency issues in transaction processing within distributed databases. It ensures database consistency in multi-user environments. While running transactions sequentially guarantees consistency, it hinders performance. Concurrency control mechanisms balance database consistency with a high level of concurrency.
Inadequate concurrency control can lead to anomalies like lost updates (transaction effects not reflected) and inconsistent retrievals.
Global Atomicity in Distributed Databases
Global atomicity ensures that all operations within a distributed transaction either complete successfully or roll back entirely, maintaining data integrity across multiple nodes. The protocol enabling global atomicity is the Two-Phase Commit (2PC) protocol.
ACID properties (Atomicity, Consistency, Isolation, Durability) are crucial for transaction management. A database management system compliant with ACID ensures that transactions possess these properties.
Transaction Coordinator Failure
If a transaction coordinator fails, subordinate nodes send an ‘Abort’ message to other nodes, initiating transaction rollback.
Example of a Distributed Transaction
A typical example is a bank transaction involving multiple entities.
Failure Modes in Distributed Systems
Distributed systems face similar failures as centralized systems (software errors, hardware failures, disk failures). However, they also encounter unique failures:
- Site failure
- Message loss
- Communication link failure
- Network partition
Message loss or corruption is a constant possibility. Systems employ transmission control protocols (e.g., TCP/IP) to handle such errors. Refer to standard networking textbooks for more details.
Case Study: NH Hotel Chain
The NH Hotel chain uses a distributed database. Each hotel node stores room data and corresponding activities. The headquarters node holds hotel data.
The headquarters needs to access all hotel activity descriptions and dates for all 4,000 hotels (6-byte hotel code). There are 40,000 rooms, averaging 200 entries per room. Activity descriptions are 128 bytes, and dates are 6 bytes.
Cost of Query using Semi-Join
Headquarters to Hotel Node: 4,000 hotels * 6 bytes/hotel = 24,000 bytes
Hotel Node to Local Node:
40,000 rooms * 200 entries/room * (128 bytes description + 6 bytes date + 6 bytes hotel code) = 11,200,000 bytes
Total Semi-Join Cost (S): 24,000 bytes + 11,200,000 bytes = 11,224,000 bytes