Transactional Support for Non-Relational Database via Versioning
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Non-relational databases lack robust transactional support, leading to issues such as data inconsistency and single points of failure, which can impact the reliability and scalability of cloud services.
Innovation Solution
A database management system is implemented to provide atomicity and isolation for non-relational databases by using key-value pairs with versioning and a timer mechanism, ensuring that transactions are processed reliably and avoiding data overwrites and single points of failure.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Ease of manufacture
If non-relational databases are used, then deployment cost and maintenance cost are reduced, but transactional support and data consistency are weakened
Solution Approach 1:
The patent segments the transactional support mechanism into separate components: version vectors for tracking changes, timer mechanisms for isolation, and committed version records for ensuring atomicity. This allows non-relational databases to achieve relational-like transactional properties without requiring a complete relational database system, thus maintaining low deployment costs while improving reliability.
Solution Approach 2:
The patent introduces version vectors and timer parameters to the non-relational database key-value pairs. By changing the data structure to include version information and temporal parameters, the database can enforce ACID properties without altering the fundamental non-relational architecture, thereby maintaining ease of deployment while achieving robust transactional support.
2Reliability
If relational databases are used, then transactional support is improved, but deployment cost and maintenance cost increase
Solution Approach 1:
The patent creates a simplified copy of relational database transactional mechanisms adapted for non-relational databases. Instead of implementing full relational database functionality, it copies only the essential transactional support features (versioning, isolation through timers, atomicity through committed records) into the non-relational database structure, achieving reliability at lower cost.
3Reliability
If a central relational database is used, then data consistency is improved, but system scalability and fault tolerance are reduced
Solution Approach 1:
The patent segments the central database into distributed non-relational database instances that can operate independently. Each instance maintains its own version vectors and committed version records, allowing the system to scale horizontally while maintaining data consistency through the replicated transactional mechanisms across multiple nodes.
Solution Approach 2:
The patent adds temporal and versioning dimensions to the data storage structure. By incorporating version vectors and timer-based isolation, the system achieves consistency across distributed nodes without requiring a centralized architecture, thus improving both scalability and fault tolerance while maintaining data consistency.
4Productivity
If failed transactions are committed in non-relational databases, then processing speed is improved, but data integrity is compromised
Solution Approach 1:
The patent performs preliminary actions by maintaining version vectors and timer mechanisms before transactions are committed. This allows the system to detect and prevent failed transactions from being committed without requiring complex post-commission checks, thus maintaining fast processing speeds while ensuring data integrity through proactive validation.
Solution Approach 2:
The patent implements feedback mechanisms through version vectors that track transaction status and timer-based isolation signals. This feedback allows the database to quickly identify failed transactions and prevent their commitment, maintaining both high processing speed and data integrity by eliminating the need for slow post-commission verification processes.
Data Source
Figure 1
Figure 2
Figure 3A~3B
AI summary
Techniques of transaction support for a database are disclosed herein. One example technique includes generating a new version value for key-value pairs in the database and creating, in the database, a new key-value pair corresponding to a parameter to be updated with a new value using both the generated new version value and a name of the parameter as a key and the new value as the corresponding value for the created new key-value pair. The example technique can then include determining whether creating the new key-value pair is completed successfully in the database, and in response to determining that creating the new key-value pair corresponding to the parameter is not completed successfully, the existing value of the parameter is returned as a current value of the parameter instead of the new value in response to a query for the current value of the parameter.