Distributed Database Reads Using Safe Timestamps Without Logging
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
In distributed databases, read locks can block write operations for prolonged periods, delaying other transactions and causing inefficiencies.
Innovation Solution
Implementing a method where a leader replica reserves a range of timestamps for exclusive use, allowing transactions to be executed without logging, and extending these timestamps to ensure consistent reads and writes without locking.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If read locks are used to ensure consistent database state, then data consistency is improved, but database blocking increases and productivity deteriorates
Solution Approach 1:
The patent extracts the consistency guarantee mechanism from the traditional read lock approach. Instead of using locks to ensure consistency, the system uses a combination of timestamps, version vectors, and causal ordering to achieve consistency without blocking. The read lock concept is replaced by a non-blocking read protocol that uses transaction timestamps and replica state information to ensure consistent reads while allowing concurrent writes.
Solution Approach 2:
The patent replaces the mechanical locking system with a time-based ordering system. Instead of using physical locks that block operations, the system uses timestamps and version vectors to order and track transactions. This substitution eliminates the blocking mechanism while maintaining consistency through causal ordering and replica state management.
2Reliability
If read locks are used to prevent concurrent access, then data consistency is improved, but operation time increases and speed deteriorates
Solution Approach 1:
The patent removes the time-consuming lock acquisition and release operations from the transaction flow. By extracting the consistency guarantee from the locking mechanism, the system achieves consistency through timestamp ordering and replica state tracking, eliminating the wait time associated with lock contention while maintaining transaction consistency.
Solution Approach 2:
The patent performs preliminary actions by pre-establishing timestamp ordering and version vectors before transactions execute. This allows the system to determine consistency and ordering relationships in advance, eliminating the need for real-time lock waiting and reducing transaction execution time while maintaining consistency guarantees.
3Reliability
If traditional logging mechanisms are used for transaction tracking, then reliability is improved, but system complexity increases and device complexity deteriorates
Solution Approach 1:
The patent extracts the essential transaction tracking information from the complex logging system. Instead of using comprehensive logging mechanisms, the system tracks only the critical state information (timestamps, version vectors, replica states) needed for consistency guarantees. This extraction reduces system complexity while maintaining the reliability of transaction tracking.
Solution Approach 2:
The patent applies partial tracking by monitoring only the specific state information necessary for consistency (timestamps and version vectors) rather than implementing full transaction logging. This partial action approach reduces the complexity of the tracking system while providing sufficient information for reliable transaction management and conflict resolution.
Data Source
AI summary
The subject matter described herein provides techniques to ensure that queries of a distributed database observe a consistent read of the database without locking or logging. In this regard, next-write timestamps uniquely identify a set of write transactions whose updates can be observed by reads. By publishing the next-write timestamps from within an extendable time lease and tracking a “safe timestamp,” the database queries can be executed without logging read operations or blocking future write transactions, and clients issuing the queries at the “safe timestamp” observe a consistent view of the database as it exists on or before that timestamp. Aspects of this disclosure also provide for extensions, done cheaply and without the need for logging, to the range of timestamps at which read transactions can be executed.