OLTP Database Block Compression Without Slowing Transactions
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing database management systems (DBMS) for online transaction processing (OLTP) cannot efficiently compress data due to the real-time nature of transactions, which makes compression delay response times and is not feasible for OLTP systems, unlike bulk load operations where data is readily available for compression.
Innovation Solution
Implementing a method where database blocks are initially filled with uncompressed data until a predetermined condition is met, allowing for periodic compression and re-compression, enabling real-time OLTP transaction processing without performance degradation, and utilizing separate transactions for compression to maintain responsiveness.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Quantity of substance
If data is compressed in real-time during OLTP transactions, then storage efficiency is improved, but transaction response time deteriorates
Solution Approach 1:
The system performs compression in advance during bulk load operations before OLTP transactions begin. Data is compressed and stored in a compressed format in the database, so that when OLTP transactions occur, the data is already compressed and no real-time compression is needed during transaction processing.
Solution Approach 2:
The system separates compression operations from transaction operations by using different transactions: bulk load transactions handle compression while OLTP transactions handle data access. This segmentation allows compression to occur independently without impacting transaction performance.
2Speed
If data is stored uncompressed, then transaction processing speed is improved, but storage space utilization deteriorates
Solution Approach 1:
Data is compressed in advance during bulk load operations before OLTP transactions begin. The compression is performed as a preliminary action, so that when OLTP transactions occur, the data is already in compressed form and can be accessed without additional compression overhead.
3Quantity of substance
If compression is performed during every OLTP transaction, then storage efficiency is improved, but system complexity increases
Solution Approach 1:
The system separates compression operations from transaction operations by using different transactions: bulk load transactions handle compression while OLTP transactions handle data access. This segmentation simplifies the system architecture by avoiding the need to integrate compression logic into every transaction path.
Solution Approach 2:
Instead of compressing data in every OLTP transaction, the system performs compression only during bulk load operations. This partial action approach reduces system complexity while still achieving storage efficiency goals for the data that is compressed.
Data Source
AI summary
A computer is programmed to compress data of a database in response to database modification language (DML) statements generated by on-line transaction processing (OLTP) systems. In several embodiments, data that is initially added to a database block is left uncompressed until a predetermined condition is satisfied, which happens infrequently (relative to OLTP transactions on the block). When satisfied, the computer automatically compresses all uncompressed data in the block, which increases the amount of unused space in the block. New data is thereafter added uncompressed to the partially compressed block, until satisfaction of a predetermined condition whereby the partially compressed block is again compressed, i.e. re-compressed. Adding of new data to a partially compressed block and its compression are repeated unless another predetermined condition is met, in response to which the block is not further re-compressed, thereby to recognize a limit on the benefit from compression.