Persistent Version Storage for Relational Database
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Relational database management systems (RDBMS) face challenges in efficiently managing and storing previous versions of data, which hinders performance and complicates operations like transaction rollback, crash recovery, and data versioning.
Innovation Solution
Implementing persistent version storage within the RDBMS, where previous versions are stored either in-row or off-row, with a storage policy determining the storage scheme based on version differences and metadata needs, and a cleanup mechanism to manage and delete unnecessary versions.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If previous version information is stored in the database, then transaction rollback and crash recovery are improved, but device complexity and storage requirements increase
Solution Approach 1:
The patent segments previous version information storage by implementing separate version stores for different database pages, allowing version data to be organized and managed in distributed units rather than a monolithic structure. This reduces complexity by localizing version management to specific pages while maintaining overall system reliability.
Solution Approach 2:
The patent extracts version information management from the main database transaction log, creating a dedicated version store that handles version data separately. This extraction isolates the complexity of version tracking from core database operations, improving both reliability and maintainability without significantly impacting overall system complexity.
2Reliability
If previous version information is stored in the database, then crash recovery is accelerated, but storage space is consumed
Solution Approach 1:
The patent applies local quality by storing version information only where needed - specifically in version stores associated with database pages that have undergone modifications. This selective storage approach ensures crash recovery capability is maintained for affected pages while avoiding unnecessary storage consumption across the entire database.
Solution Approach 2:
The patent implements a mechanism where version information is discarded after successful recovery or commit operations. The version store is cleaned up by removing entries for pages that have been successfully recovered or committed, thereby recovering storage space while maintaining crash recovery capability for active transactions.
3Adaptability or versatility
If version information is stored for all records, then data versioning is improved, but device complexity increases
Solution Approach 1:
The patent implements dynamic version information storage by selectively creating version entries only when modifications occur to database pages. The version store dynamically adapts to changes in the database state, creating or removing version entries based on actual modification events rather than maintaining static version information for all records.
Solution Approach 2:
The version store structure is designed to serve multiple functions: supporting transaction rollback, enabling crash recovery, and providing data versioning capabilities. This multi-functional design improves adaptability by allowing the same infrastructure to handle various version management needs without requiring separate complex systems for each function.
Data Source
Figure 1
Figure 2A
Figure 2B
AI summary
A relational database system that implements persistent version storage may include an in-row module that is executable by one or more processors to implement an in row scheme by storing in-row previous version information within a payload of a row within a database page. The relational database system may additionally include an off-row module that is executable by the one or more processors to implement an off-row scheme by storing off-row previous version information in an off-row page that is separate from the database page. The relational database system may additionally include a storage policy that defines when previous version information is stored in accordance with the in row scheme and when the previous version information is stored in accordance with the off-row scheme. The relational database system may additionally include a cleanup module that cleans up older versions when they are deemed unnecessary by the system.