Parallel Database Update via Timestamp Segmentation and Dependency Graphs
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Traditional database systems fail to support parallel updates while ensuring ACID properties and serializable isolation, often requiring cascading rollbacks that severely impact performance.
Innovation Solution
A database system with a concurrency control protocol, write-ahead log, cache, persistence, write control, and read control modules that manage timestamps and dependency graphs to enable parallel updates without cascading rollbacks, ensuring ACID compliance and serializable isolation.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If traditional concurrency control methods (2-phase locking, timestamp ordering, optimistic concurrency control) are used to ensure database integrity and serializable isolation, then ACID properties and serializable isolation are maintained, but parallel updates cannot be supported and transactions must be serialized
Solution Approach 1:
The patent segments the write operation into two independent parts: normal writes (structure-changing operations) and incremental updates (value-changing operations). Normal writes maintain ACID properties through traditional locking mechanisms, while incremental updates use version vectors and dependency graphs to enable parallel execution. This segmentation allows conflicting transactions to run in parallel for incremental updates while preserving serializable isolation for normal writes.
Solution Approach 2:
The patent introduces version vectors as a parameter to track the version of each data item across transactions. By attaching version vectors to incremental updates and using them in dependency graph construction, the system enables parallel execution of transactions that do not conflict on version dependencies, while maintaining serializable isolation for transactions that do conflict.
2Productivity
If dirty reads with cascading rollbacks are used to support parallel updates, then parallel update capability is achieved, but system performance deteriorates due to severe performance jitter caused by cascading rollbacks
Solution Approach 1:
The patent performs preliminary validation by constructing a dependency graph before executing transactions. The dependency graph pre-identifies all conflicts between transactions by analyzing their read-write and write-write dependencies. By detecting potential cascading rollback scenarios in advance and adjusting transaction schedules, the system avoids actual cascading rollbacks and maintains stable performance while enabling parallel updates.
Solution Approach 2:
The patent uses version vectors as feedback mechanisms to track the execution state of transactions. When a transaction completes its incremental updates, it updates the version vector of affected data items. Other transactions can query these version vectors to determine whether they can proceed in parallel or need to wait, enabling dynamic parallel execution without cascading rollbacks.
3Productivity
If fasterKV is used to support parallel updates, then parallel update performance is improved, but ACID properties and serializable isolation cannot be guaranteed
Solution Approach 1:
The patent merges the advantages of fasterKV's parallel update capability with the ACID guarantees of traditional database systems. By combining version vectors and dependency graphs (from fasterKV) with two-phase locking and timestamp ordering (from traditional systems), the patent creates a hybrid concurrency control mechanism that provides both parallel update performance and ACID compliance.
Solution Approach 2:
The patent introduces dependency graphs as an intermediary structure between transactions and the concurrency control mechanism. The dependency graph mediates between conflicting transactions by identifying and resolving conflicts before execution, allowing parallel updates to proceed when no conflicts exist while ensuring ACID properties when conflicts are detected.
4Reliability
If normal write operations are performed on data items with constraints or indexes, then data integrity is maintained, but parallel updates cannot be performed due to read-modify-write requirements
Solution Approach 1:
The patent segments the write operation into normal writes (which maintain data integrity through locking) and incremental updates (which enable parallel execution). For data items with constraints or indexes, normal writes use traditional locking to ensure integrity, while incremental updates use version vectors and dependency graphs to enable parallel execution, thus resolving the contradiction between data integrity and parallel update capability.
Data Source
AI summary
A database system and method supporting parallel update includes: a concurrency control protocol, which caches max Read Timestamp, max Write Timestamp and max Normal Write Timestamp for each data item in the database; a write-ahead log module, which records normal logs and delta logs; a cache module, which caches normal records with the largest version number of the data item and all subsequent delta records; a persistence module, which saves the records in the cache to a persistent medium; a write control module, which controls the write operation, and which, if transaction timestamp is greater than the max Read Timestamp, determine and execute normal write and incremental write respectively and generate normal records and delta records, and update the max Write Timestamp and the max Normal Write Timestamp; and a read control module maintaining a dependency graph according to dependency between the write transaction and the read transaction.