Lazy Timestamping in Transaction Time Databases
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Conventional lazy timestamping methods in transaction-time databases incur high overhead during short transactions and require significant resources to maintain a persistent transaction ID timestamp table, while they do not efficiently guarantee the durability of timestamped records.
Innovation Solution
The proposed solution involves storing the mapping between transaction ID and timestamp in the commit record on the recovery log, allowing batch updates of the persistent timestamp table during checkpointing, and using a volatile reference count to track incomplete timestamping, ensuring records are durably stored before removing transaction ID timestamp information.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If conventional lazy timestamping methods are used to maintain serialization order, then timestamp consistency is ensured, but overhead during short transactions increases significantly
Solution Approach 1:
The patent segments the timestamping process into two distinct phases: (1) transaction execution phase where records are updated with transaction IDs but timestamps are not yet assigned, and (2) commit phase where timestamps are lazily assigned to all updated records. This segmentation allows transactions to complete quickly without the overhead of immediate timestamping, while still ensuring timestamp consistency through the structured two-phase approach.
Solution Approach 2:
The patent performs preliminary actions by assigning transaction IDs to records during the transaction execution phase, before the actual timestamping occurs. This preliminary marking of records with transaction IDs enables the lazy timestamping mechanism to efficiently identify and timestamp all affected records after commit, without requiring immediate timestamp calculation during the transaction itself.
2Ease of operation
If a persistent transaction ID timestamp table is maintained to map transaction IDs to timestamps, then timestamp retrieval is enabled, but the cost of maintaining the table increases
Solution Approach 1:
The patent replaces the expensive persistent transaction ID timestamp table with a much cheaper in-memory hash table that is rebuilt from the recovery log during checkpointing. This disposable approach eliminates the need for complex persistent storage, indexing, and maintenance operations, while still providing efficient timestamp retrieval during the active transaction period. The table is discarded and rebuilt periodically, avoiding the cumulative maintenance overhead of a persistent table.
Solution Approach 2:
The patent creates a copy of the necessary timestamp mapping information in the form of commit records in the recovery log, which are then used to rebuild the in-memory hash table during checkpointing. This copying mechanism eliminates the need to maintain the original persistent table, as the recovery log serves as a sufficient source for reconstructing the mapping information when needed.
3Productivity
If transaction ID timestamp information is deleted early to reduce maintenance cost, then resource utilization improves, but the risk of losing timestamp data before durability is guaranteed increases
Solution Approach 1:
The patent implements a feedback mechanism through reference counting that tracks how many records associated with a transaction have been durably written to disk. The system continuously monitors this count and only deletes transaction ID timestamp information when the reference count reaches zero, indicating all records are durably stored. This feedback loop ensures durability is guaranteed before resource cleanup occurs.
Solution Approach 2:
The patent performs preliminary durability checking by tracking the write status of all records associated with a transaction through reference counting. Before allowing deletion of transaction ID timestamp information, the system preliminarily verifies that all records have been durably written to disk, ensuring that no timestamp data is lost. This preliminary verification step prevents premature deletion that could compromise data durability.
Data Source
AI summary
Systems and methods for facilitating more efficient timestamping in a lazy timestamping transaction time database environment are described herein. A recovery log component can store timestamp information of a transaction in a commit record of the transaction, wherein the commit record of the transaction is included in a recovery log. A volatile reference count component can update reference count data of the transaction in a volatile timestamp table to reflect a number of records of the transaction that do not persistently include timestamp information. Further, a checkpoint component can update timestamp information for a batch of transactions, wherein the timestamp information is updated in a record of the persistent timestamp table to ensure that the timestamp information persists in the record of the persistent timestamp table before the commit record of the transaction that contains the transaction's timestamp information is deleted from the recovery log.