Unified Transaction Object for Row and Column Store Concurrency
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing multi-version concurrency control (MVCC) systems in database management are limited in providing concurrency control across different data stores and types of table storage, leading to inconsistent views and increased locking and coordination requirements.
Innovation Solution
Implementing multi-version concurrency control by using shared transaction objects across both row stores and column stores, where a single transaction object is used for updates in both storage types, and atomic commits ensure consistent state management.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If separate concurrency control mechanisms are used for row store and column store, then each storage type can be independently managed, but inconsistent views of data and increased locking coordination requirements occur
Solution Approach 1:
The patent merges the concurrency control mechanisms of row store and column store into a unified system. A single set of transaction logs and version information is shared between both storage types, allowing them to be managed together rather than separately. This is achieved by having both row store and column store operations participate in the same transaction context, using common commit records and version identifiers.
Solution Approach 2:
The patent creates a universal concurrency control mechanism that serves both row store and column store operations. The transaction management system is designed to handle multiple types of storage operations through a single interface, using the same transaction objects, lock management, and version control for both storage types, thereby eliminating the need for separate control mechanisms.
2Measurement precision
If separate transaction objects are used for row store and column store updates, then each update can be tracked independently, but locking and coordination overhead increases
Solution Approach 1:
The patent combines multiple transaction objects into a single shared transaction object that is used for both row store and column store updates. Instead of creating separate transaction contexts for each storage type, the system uses one transaction object to track all modifications, maintaining a unified view of the transaction state and reducing the number of locks that need to be coordinated.
Solution Approach 2:
The patent designs a universal transaction object that can track updates across different storage types. This single transaction object serves multiple functions: it manages row store modifications, column store modifications, and coordinates between them using a common lock hierarchy and versioning scheme, thereby reducing overall system complexity.
3Productivity
If different commit records are used for row store and column store, then each store can commit independently, but atomicity of transactions across stores is compromised
Solution Approach 1:
The patent merges the commit records of row store and column store into a single shared commit record. When a transaction commits, both storage types update the same commit record atomically, ensuring that either both commits succeed together or both fail together. This eliminates the possibility of partial commits across different storage types while maintaining efficient commit operations.
Solution Approach 2:
The patent creates a universal commit record that serves both row store and column store operations. This single commit record is used to record the outcome of transactions affecting either or both storage types, providing a unified mechanism for ensuring atomicity across different storage systems while allowing parallel commit processing.
Data Source
AI summary
Techniques and solutions are provided for performing transactions within a database system that stores database data using a row store and a column store. For example, a transaction that performs operations to update data in both the row store and the column store can use the same transaction object. The state of the transaction can be atomically changed. For example, the state of the transaction object can be atomically changed from uncommitted to committed (e.g., set to a commit identifier to represent the committed state).