In-Memory Database Overcommitment via SSD Swap and Prefetching
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
In-memory database management systems face performance bottlenecks due to slow disk access times required for durability, which slows down response times and increases computing overhead, especially in single-threaded systems that rely on standby replicas for durability, and are limited by system memory size.
Innovation Solution
Implementing a method that allows memory overcommitment by swapping data to faster persistent storage devices like SSDs, using deterministic record and replay techniques, and prefetching data to maintain performance comparable to non-overcommitted systems while ensuring durability through virtualization and clone database engines.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If synchronous logging to disk is implemented to ensure durability, then data reliability is improved, but response time deteriorates due to slow disk access
Solution Approach 1:
The system performs preliminary actions by pre-fetching data from swap space to buffer cache before it is actually needed for transaction processing. This anticipatory data loading reduces the impact of disk access on response time, as data is already available in faster buffer cache memory when transactions require it.
Solution Approach 2:
The invention introduces buffer cache as an intermediary layer between disk storage and the in-memory database system. This intermediary buffer cache acts as a temporary storage that mediates between slow disk access and fast memory access, allowing the system to maintain durability while reducing the direct impact of slow disk I/O on transaction response times.
2Productivity
If multi-threaded capabilities are added to service transactions in parallel, then throughput is improved, but device complexity increases due to locking and buffer management mechanisms
Solution Approach 1:
The system segments transaction processing into two distinct phases: a pre-processing phase that can be performed in parallel by multiple threads before transactions are committed, and a final commit phase that ensures durability. This segmentation allows parallel processing to improve throughput while minimizing the complexity of coordination mechanisms needed during the critical commit path.
Solution Approach 2:
The invention uses cloning/replication of database objects and transactions in a virtualized environment, allowing multiple virtual instances to process transactions simultaneously. This copying approach enables parallel throughput improvement while the virtualization layer abstracts away the complexity of low-level locking and buffer management mechanisms.
3Quantity of substance
If memory overcommitment is implemented by swapping pages to disk, then memory capacity is improved, but performance deteriorates due to slow disk access
Solution Approach 1:
The system applies local quality by differentiating between hot data (frequently accessed) and cold data (rarely accessed). Hot data is kept in fast buffer cache memory, while cold data can be swapped to slower disk storage. This localized optimization ensures that the most performance-critical data paths maintain high access speeds while still allowing memory overcommitment for less frequently accessed data.
Solution Approach 2:
The system performs preliminary data loading by pre-fetching data from swap space to buffer cache before it is actually needed for transaction processing. This anticipatory action ensures that data is already in fast memory when needed, eliminating the performance penalty of slow disk access during actual transaction processing while still allowing memory overcommitment.
Data Source
AI summary
A computer system includes an SSD as swap space for a database management system that comprises a primary database engine and at least one clone database engine. A queued database transaction is sent to the clone database engine for pre-processing while the primary database engine is processing a current database transaction and if data needed to process the queued database transaction is not currently cached in the computer system, the clone database engine fetches the data and caches it into a buffer accessible by the primary database engine. When the primary database engine is ready to process the queued database transaction, it will be able to access the needed data without accessing the SSD, thereby avoiding delays resulting from accessing the SSD.