Optimistic Garbage Collection in Multi-Writer Databases
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
In distributed multi-writer database systems, efficient garbage collection is challenging due to conflicts between delete operations and page writes, especially when using optimistic concurrency, where the lack of transactional rollback information complicates handling failures and requires complex retry strategies.
Innovation Solution
Implementing an optimistic multi-writer database system that employs batch retry strategies for delete operations, leveraging idempotency and loose ordering properties to validate deletes at checkpoints without waiting for individual confirmations, and using a garbage collector that can issue delete operations optimistically, retrying batches of operations in case of conflicts without extensive rollback processes.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Productivity
If optimistic concurrency is used to allow multiple writers to perform writes without coordination, then write performance and scalability are improved, but conflicts between delete operations and page writes increase complexity of garbage collection
Solution Approach 1:
The garbage collection process is segmented into two distinct phases: a marking phase that identifies objects needing deletion, and a sweeping phase that actually performs the deletion. This segmentation allows the GC to operate independently from the optimistic write operations, reducing interference and complexity while maintaining high write performance.
Solution Approach 2:
The marking phase performs preliminary identification of objects that need to be deleted before the actual deletion occurs. By pre-marking objects during a low-conflict period, the system can prepare deletion tasks without interfering with ongoing optimistic writes, thereby reducing the complexity of coordinating deletions with concurrent writes.
2Reliability
If individual monitoring of delete operations is performed to ensure correctness, then reliability is improved, but processing time and rework overhead increase
Solution Approach 1:
The marking phase performs preliminary identification of objects that need to be deleted before the actual deletion occurs. By pre-marking objects during a low-conflict period, the system can prepare deletion tasks without interfering with ongoing optimistic writes, thereby reducing the complexity of coordinating deletions with concurrent writes.
Solution Approach 2:
The garbage collector operates as a background process that continuously performs marking and sweeping operations without blocking the main write path. This continuous operation ensures correctness through persistent monitoring while minimizing the time impact on database performance by utilizing idle periods and background processing.
3Reliability
If transactional rollback information is maintained for conflict resolution, then correctness is improved, but memory usage and system overhead increase
Solution Approach 1:
The system extracts and removes transactional rollback information from the optimistic write path, allowing writes to proceed without maintaining detailed rollback state. Conflicts are resolved at the storage layer without requiring extensive rollback information to be retained in memory, thereby reducing memory usage while maintaining correctness through selective conflict resolution.
Solution Approach 2:
The system discards detailed transactional rollback information after conflicts are resolved or after a retention period, reducing memory footprint. The garbage collector recovers from conflicts by retrying delete operations or by having the storage layer resolve conflicts, eliminating the need to permanently maintain extensive rollback state in memory.
Data Source
AI summary
Systems and methods are disclosed to implement, in a multi-writer database system, a database engine node that optimistically sends queued purge operations to a backend storage system without waiting for acknowledgement of previous operations from the storage system. If a conflict is later detected for a particular operation, the database engine node may retry some portion of the purge operations in the queue. In embodiments, the purge operations are performed as part of a garbage collection phase of a multi-version concurrency control (MVCC) protocol, where unneeded versions of objects previously generated for isolated snapshots are deleted. In embodiments, the operations in the queue may be grouped so that a rejection of one operation in the group will cause the entire group to be retried. Because these purge operations are idempotent and directed to objects that are invisible, they may be freely retried in arbitrary order, without maintaining any rollback state.