Database Concurrent Operation Version Management
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing methods for concurrent database operations face inefficiencies, particularly when handling a large number of requests, as they either result in long processing times due to locking mechanisms or significant version management overhead, especially when the number of put requests exceeds scan and get requests.
Innovation Solution
The solution involves updating a global version number upon receipt of a scan request rather than every put request, allowing for concurrent execution of scan and get operations while performing put operations consecutively, thus reducing version management overhead and enabling efficient processing of multiple requests.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If locking mechanism is used to avoid conflict between retrieving and updating data, then data consistency is ensured, but processing time increases significantly
Solution Approach 1:
The database operations are segmented into different types (scan, get, put) that can be handled differently. Scan and get operations are allowed to proceed concurrently without locking, while put operations are handled separately. This segmentation allows reading operations to avoid the overhead of locking mechanisms while maintaining data consistency through version numbers.
Solution Approach 2:
A version number mechanism is introduced as an intermediary to coordinate between concurrent read operations and write operations. Instead of using direct locking between operations, the version number acts as a mediator that allows read operations to proceed freely while put operations update the version number, thereby ensuring consistency without blocking reads.
2Productivity
If new data version is created upon each put request to enable concurrent processing, then concurrent processing is achieved, but version management overhead increases significantly
Solution Approach 1:
Instead of creating a new data version for every put request (excessive action), the system uses a single global version number that is updated selectively. This partial action approach creates only the necessary version information (the global counter) rather than full data copies, significantly reducing version management overhead while still enabling concurrent scan and get operations to access consistent data snapshots.
3Reliability
If locking database during put operation is used to ensure data consistency, then data consistency is maintained, but scan and get operations are blocked
Solution Approach 1:
The system segments operations into read-type (scan, get) and write-type (put) operations. Read operations are allowed to execute concurrently without acquiring locks, while write operations update the global version number. This segmentation enables read operations to proceed without being blocked by write operations, thereby maintaining both data consistency and high concurrent throughput.
Solution Approach 2:
The traditional mechanical locking system is replaced with a version number-based coordination mechanism. Instead of using locks that physically block operations, the system uses version numbers that allow read operations to proceed freely while providing write operations with a simple counter to update. This substitution eliminates the blocking behavior of locks while maintaining consistency guarantees.
Data Source
AI summary
The present teaching relates to concurrent database operation. In one example, a plurality of requests which includes a scan request to obtain first data associated with a plurality of first keys stored in a database is received concurrently. A global version number is updated upon receipt of the scan request. The first data associated with the plurality of first keys is obtained based on the updated global version number. The first data is provided in response to the scan request.