Hardware Optimized String Table for Database Query Acceleration
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing hash table implementations for dynamic string tables in relational database systems often require serial processing, limiting parallelism and efficiency on modern multi-core, multi-threaded hardware, and also lead to increased memory footprint.
Innovation Solution
A hardware optimized dynamic string table is organized as a hierarchy of buckets, allowing for parallel comparison of in-line and out-of-line strings using SIMD instructions, and minimizing memory footprint by sharing code portions and using fixed-sized buckets aligned with cache lines.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Productivity
If existing hash table implementations are used for dynamic string tables, then string matching can be performed, but serial processing is required which limits parallelism and reduces efficiency on multi-core hardware
Solution Approach 1:
The hash table is divided into multiple buckets that can be independently processed. Each bucket contains entries with strings and associated data, allowing different buckets to be processed in parallel by different threads or CPU cores. This segmentation enables concurrent string matching operations without serial processing constraints.
Solution Approach 2:
The patent introduces a new dimension to the traditional hash table structure by adding bucket-level parallelism. Instead of processing entries sequentially within a single hash table, the system processes multiple buckets simultaneously across different memory locations, leveraging multi-core hardware capabilities for parallel string matching.
2Productivity
If multiple levels of indirection are added to enable parallelism, then concurrent thread access is improved, but memory access is fragmented leading to reduced performance
Solution Approach 1:
Each bucket is designed with localized data structures that keep related information (strings, hashes, and associated data) together in contiguous memory locations. This local organization allows threads to access bucket contents efficiently without traversing multiple indirection levels, maintaining both parallelism and memory access performance.
3Productivity
If traditional hash table structures are used, then string matching functionality is achieved, but memory footprint is increased particularly for in-memory database implementations
Solution Approach 1:
The patent extracts the string data from the hash table structure and stores it separately in a compact format. Only the essential metadata (hash values, pointers to string data, and associated data) are stored in the hash table buckets, significantly reducing the memory footprint while maintaining string matching capability.
Solution Approach 2:
The bucket structure serves multiple functions: it stores hash values for quick lookup, maintains pointers to string data, and holds associated data. This multi-functional design eliminates the need for separate data structures, reducing overall memory consumption while preserving full string matching functionality.
Data Source
AI summary
Data structures and methods are described to enable a hardware optimized dynamic string table for accelerating relational database queries. A method comprises retrieving a lookup key for a query against a dynamic string table, the lookup key associated with a key length and a key hash. The method further comprises configuring a formatted lookup key as in-line or out-of-line based on whether the key length exceeds a maximum inline key size. The method further comprises replicating, into a first plurality of single instruction, multiple data (SIMD) lanes, the formatted lookup key. The method further comprises writing a candidate bucket, selected from the dynamic string table based on the key hash, into a second plurality of SIMD lanes. The method further comprises performing a SIMD compare of the first plurality of SIMD lanes and the second plurality of SIMD lanes, and returning an associated code when the lookup key is matched.