Inline LOB Storage for Locator Overhead Reduction
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Relational database management systems (RDBMS) experience performance degradation due to the overhead of creating and managing LOB locators for Large Object (LOB) queries, which is particularly pronounced for semi-structured and unstructured data stored as LOBs, leading to slower query execution times compared to non-LOB datatypes.
Innovation Solution
Implementing automatic inference of locator-less LOB by value semantics in RDBMS, where the system determines whether an inline LOB column needs to be returned to the client based on the statement's semantics, allowing for direct access to LOB data in the shared buffer cache without creating a LOB locator when not required, thereby reducing overhead.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Ease of operation
If LOB locators are created and managed for LOB queries, then random piece-wise access to LOB data is enabled, but query execution time increases due to overhead
Solution Approach 1:
The patent extracts the LOB locator creation and management overhead from the query execution path by using inline LOB storage, where the LOB data is stored directly in the table row without requiring separate locator structures. This eliminates the intermediate step of creating and managing locators while preserving random piece-wise access capability through direct offset-based access to the inline stored data.
Solution Approach 2:
The patent copies the LOB data directly into the table row storage structure rather than storing it separately and requiring locators. By copying the actual LOB values into the inline storage area of the table row, the system enables direct access without the need for locator creation, thereby reducing query execution time while maintaining access flexibility.
2Adaptability or versatility
If LOB data is stored out-of-line for larger LOBs, then storage flexibility is improved, but data copying overhead increases
Solution Approach 1:
The patent implements a dynamic storage approach where LOB data can be stored inline when size permits and access patterns benefit from it, rather than always storing out-of-line. The system dynamically determines the optimal storage location based on LOB size and access requirements, allowing smaller LOBs to be stored inline to avoid copying overhead while larger LOBs can be stored out-of-line for storage flexibility.
Solution Approach 2:
The patent applies different storage qualities to different LOB data based on their specific characteristics. Inline storage is applied to LOBs that benefit from direct access and small size, while out-of-line storage is applied to larger LOBs where storage flexibility is more important. This local differentiation optimizes the trade-off between access performance and storage flexibility for each LOB individually.
3Adaptability or versatility
If LOB locators are created for all LOB access, then consistent access interface is maintained, but system resource allocation increases
Solution Approach 1:
The patent applies partial action by creating LOB locators only when necessary - specifically when LOB data is stored out-of-line or when the query requires locator-based operations. For inline LOB access where the data is already in the table row, the system performs direct access without creating locators, thus allocating system resources only when absolutely necessary while maintaining interface consistency through the unified LOB access API.
Data Source
AI summary
An approach for improving LOB query performance via automatic inference of locator-less LOB by value semantics in a relational database system is provided. A relational database management system (RDBMS) is implemented to perform operations on LOBs based on the semantics of a statement. During statement compilation, the RDBMS identifies inline LOB column(s) that are not required to be returned to a client. During execution, the identified column(s) are accessed via a shared buffer cache and fed to an operator for evaluation. For inline LOB column(s) that must be returned to the client, during execution, the inline LOB data is copied from the shared buffer cache to a temporary buffer area. Data in the temporary buffer area is fed to an operator for evaluation and is used to create a LOB locator for the inline LOB column(s) that must be returned to the client.