Hashing engine for implementing point queries

Abstract

Embodiments of the present disclosure relate to a hash engine for implementing point queries. Systems and methods for improving point queries of a database are provided. Index values are separated from data and retained in cache memory to allow access without disk input / output (I / O) operations, with less latency caused by such disk I / O operations. In some embodiments, the index values may be compressed using an algorithm, such as Crack-Bit-Trie, to allow the index values to be stored in a limited cache memory space. When the cache memory is insufficient to store all index values, the index values can be selected for storage according to the least recently used method to maintain the hit rate of the cache portion and reduce disk I / O operations.

Description

Technical Field

[0001] The present disclosure relates to systems and methods for implementing point queries of a database. Background Art

[0002] Point queries in database systems and cloud-based storage can result in high tail latency, particularly due to read input / output (I / O) operations and the need to access disk to perform the query. This is especially true for systems using solid-state drives (SSDs). Summary of the invention

[0003] The present disclosure relates to systems and methods for implementing point queries of a database.

[0004] By using memory efficient index structures and caching techniques, an index with a high hit rate can be maintained in the cache memory, thereby reducing the number of disk I / O operations required to complete a point query. This in turn improves the efficiency of the database system in responding to such point queries, thereby improving the operation of the database system itself. Specifically, the index component can be separated from the data component, and only the index component is maintained in the cache memory to allow the index component to be stored in the available limited cache. In addition, the index component can be compressed to further allow the index to be stored in the limited cache. Compression can use Crit-Bit-Trie compression methods to provide compression, thereby allowing the index to be stored in the limited cache. When the data cannot be completely stored in the cache memory, a least recently used (LRU) strategy can be used to select the data maintained in the cache memory, thereby supporting the hit rate of the cached index data when all index data cannot be cached. Therefore, the disk I / O requests required to serve the point query can be reduced, and in some instances can even be reduced to a single I / O request, thereby avoiding most of the tail delays and making the database system more efficient and faster.

[0005] In an embodiment, a database system includes one or more memories storing a database, a cache memory, and one or more processors. The one or more processors are configured together to obtain index information from the database. The index information is separated from the data components of the database. The one or more processors are also configured to generate a compact index based on the index information. The size of the compact index is smaller than the index information. The compact index is generated by compressing the index information and omitting at least one of a portion of the index information from the compact index. The one or more processors are also configured to guide the storage of the compact index in the cache memory, receive a point query, and identify data responsive to the point query by referring to the compact index stored in the cache memory. The one or more processors are also configured to retrieve data responsive to the point query from the database.

[0006] In an embodiment, the index information includes a first level index that maps keys to large object file numbers and a second level index that maps keys to block offsets within the large object file.

[0007] In an embodiment, the one or more processors are configured to perform compression of the index information using a compression algorithm selected from the group consisting of Zstandard, LZ4, Snappy, Bzip2, LZMA, Gzip, Blosc, and Crit-Bit-Trie compression algorithms. In an embodiment, the compression algorithm is Crit-Bit-Trie.

[0008] In an embodiment, the one or more processors are configured to select the portion to be omitted from the index information based on a least recently used policy.

[0009] In an embodiment, the portion of the index information omitted from the compact index is stored in one or more memories, and the one or more processors are configured to obtain the omitted index information from the one or more memories when the index information stored in the cache memory is not responsive to a point query.

[0010] In an embodiment, the compact index stored in the cache memory includes all index metadata for the index information.

[0011] In an embodiment, one or more processors are configured to perform cache warming when the database is started, the cache warming comprising obtaining initial index data and storing the initial index data in a cache memory.

[0012] In an embodiment, the size of each key value entry of the index information stored in the cache memory is 6B or less.

[0013] In an embodiment, the one or more processors are configured to identify data responsive to the point query and to retrieve the data responsive to the point query from the one or more memories storing the database using a single input / output operation.

[0014] In an embodiment, a method for point querying of a database includes obtaining index information from a database, the index information being separated from a data component of the database, and generating a compact index based on the index information using a processor. Generating the compact index includes at least one of: compressing the index information and omitting a portion of the index information from the compact index. The method also includes storing the index information in a cache memory, receiving a point query, and identifying data responsive to the point query by referring to the index information stored in the cache memory. The method also includes retrieving response data from the database.

[0015] In an embodiment, the index information includes a first level index that maps keys to large object file numbers and a second level index that maps keys to block offsets within the large object file.

[0016] In an embodiment, generating the compact index comprises compressing the index information using a compression algorithm selected from the group consisting of Zstandard, LZ4, Snappy, Bzip2, LZMA, Gzip, Blosc, and Crit-Bit-Trie compression algorithms. In an embodiment, the compression algorithm is Crit-Bit-Trie.

[0017] In an embodiment, generating the compact index includes omitting the portion of the index information from the compact index, wherein the portion of the index information is determined based on a least recently used policy.

[0018] In an embodiment, when the index information stored in the cache memory does not respond to the point query, the method further comprises accessing a database to obtain omitted partial index information.

[0019] In an embodiment, the method further comprises performing cache warming when the database is started, wherein the cache warming comprises obtaining initial index data and storing the initial index data in a cache memory.

[0020] In an embodiment, said identifying of said data responsive to said point query and said retrieving of said response data from said database are performed using one single input / output operation.

[0021] In an embodiment, the size of each key value entry of the index information stored in the cache memory is 6B or less.

[0022] In an embodiment, the compact index stored in the cache memory includes all index metadata for the index information.

[0023] In an embodiment, a hash engine system for a database includes one or more processors configured to receive index information. The index information is separated from the data components of the database. The one or more processors are also configured to generate a compact index based on the index information. Generating the compact index includes at least one of the following: compression of the index information, and omitting a portion of the index information from the compact index. The one or more compressors are also configured to direct storage of the compact index in a cache memory.

[0024] In an embodiment, the one or more processors are further configured to receive a point query, reference the compact index to determine data responsive to the point query, and retrieve the data responsive to the point query from a database based on the compact index. BRIEF DESCRIPTION OF THE DRAWINGS

[0025] Figure 1 A schematic diagram of a database according to an embodiment is shown.

[0026] Figure 2 An index structure according to an embodiment is shown.

[0027] Figure 3 An example of a key store according to an embodiment is shown.

[0028] Figure 4 A logical flow for preparing a compact index according to an embodiment is shown.

[0029] Figure 5 An example of performing a read request according to an embodiment is shown.

[0030] Figure 6 The structure of a large object file according to an embodiment is shown.

[0031] Figure 7 The construction of an index structure according to an embodiment is shown.

[0032] Figure 8 The flow of index reading according to an embodiment is shown.

[0033] Fig. 9 An index cache according to an embodiment is shown.

[0034] Fig.10 A transformation of writes to read caches according to an embodiment is shown.

[0035] Fig.11 Warming up of an index cache according to an embodiment is shown.

[0036] Fig.12 A flow chart of a method for point query according to an embodiment is shown.

[0037] Fig.13 A key-value system integrated with a file system according to an embodiment is shown. DETAILED DESCRIPTION

[0038] The present disclosure relates to systems and methods for implementing point queries on a database.

[0039] Figure 1A schematic diagram of a database according to an embodiment is shown. The database system 100 includes a shard manager 102 and shards 104. Each shard includes a memory repository 106 and a disk repository 108. The database system 100 also includes a memory repository manager 110. The memory repository manager 110 may include a cache policy manager 112, a write-to-read cache manager 114, an index cache heater 116, and a data cache manager 118. The database system 100 may be configured to interface with a file system 120. The database system 100 may be configured to provide a high cache hit rate for point queries, thereby reducing references to the disk repository 108 when processing point queries by compactly storing index data in the memory repository 106.

[0040] The database system 100 is configured to enable efficient point queries by managing indexes for stored data.The database system 100 may require any suitable processor, memory, and / or other computing device to perform the functions described herein.

[0041] The shard manager 102 manages the sharding of the data of the database system. Sharding may include partitioning and distributing the data across multiple nodes or servers of the database system 100. Sharding by the shard manager 102 may allow each shard to manage its own index, thereby reducing computational overhead, reducing unnecessary replication during garbage collection on the database, and controlling resource allocation to each shard. The shard manager 102 may divide the data of the database into shards 104, for example, by splitting the database or specific shards thereof or merging shards according to any suitable criteria.

[0042] Each shard 104 includes a memory repository 106. The memory repository 106 is a cache memory. The memory repository 106 may include one or more memory devices suitable for cache operations, such as dynamic random access memory (DRAM), persistent memory (PMEM), solid-state drives (SSDs), such as NVMe SSDs, as non-limiting examples. The memory repository 106 may contain an index for data in the corresponding disk repository 108 of the shard 104, such as the compact index for point lookups described herein.

[0043] The shards 104 also each include a disk repository 108 that is configured to store data distributed by the shard manager 102 to that particular shard 104. The disk repository 108 includes one or more suitable storage memories, such as, by way of non-limiting example, a PMEM, an SSD such as an NVMe SSD, or a hard disk drive (HDD). In various embodiments, the disk repository 108 may store index information that cannot be retained in the memory repository 106, for example, because the index has a size that is greater than the capacity of the memory repository 106.

[0044] The memory repository manager 110 is a module for memory management. The memory repository manager 110 may include any suitable hardware, software, and combination thereof for performing the memory management described herein. The memory repository manager 110 includes a cache policy manager 112. The cache policy manager 112 is configured to generate a compact index cache to store index information so that the index information can be maintained in the memory repository 106. The cache policy manager is configured to generate a compact index cache to store key index information. The cache policy for the compact index cache prioritizes caching all index metadata, index data from the first level index, and all index data from the first and second level indexes.

[0045] The compact index cache may include multiple layers. The first layer may be stored in the database in the form of an SST file summary, and key-value separation may be performed. The SST file summary may store data in the form of a key pointing to a large object (blob) file number. The second layer may contain a key pointing to a data block offset. The second layer may be stored in a large object file summary. Each layer may include index metadata, which is also included in the cache. In an embodiment, the total size of the index metadata in memory is <= 1.4B per entry. Based on an estimate of a database of approximately 4 million entries, the index metadata occupies a total of 5.6GB of memory and can therefore be completely cached in memory. In addition to the index metadata, a first level of the index may also be provided in the cache memory, such as Figure 2 The first level compact index 202 is shown in FIG. 1 and described in further detail below.

[0046] The memory repository manager 110 may also include a write-to-read cache manager 114. The write-to-read cache manager 114 is configured to ensure that the cache remains valid after background tasks such as compression, flushing, and garbage collection (GC) operations of the database system 100. Using the write-to-read cache manager 114 to maintain cache validity can reduce read latency fluctuations that may be caused by cache misses after compression. When these background tasks reassemble old data from old blocks and write them into new blocks, the write-to-read cache manager 114 is configured to actively write new blocks to the cache to maintain the validity of cache index data relative to the new data blocks. The write-to-read cache manager 114 can be configured to selectively perform such writing of new blocks to the cache to avoid polluting the cache with too much data.

[0047] The memory repository manager 110 may include an index cache heater 116. The cache heater 116 may address the problem of an empty index cache at database startup. An empty cache may cause latency fluctuations in the early stages of database operations. The cache heater 116 may be operated at database startup to generate a cache. The cache heater 116 may run a background thread that traverses all file summaries containing first-level index data and stored data summaries containing second-level index data within a database of the database system 100 or a particular shard 104 thereof. This data may be used to generate a compact index file based on the operation of the cache policy manager 112 as discussed above. The compact index file generated by the cache heater 116 may be used as an index cache. This may reduce potential cache misses and improve overall query performance for a period of time after database startup.

[0048] The memory repository manager 110 may include a data cache manager 118. The data cache manager 118 may adjust the caching of data, for example, determining whether to cache data as a block or an entire row. Caching an entire row can potentially significantly improve cache hit rates and provide more efficient memory usage and faster access times. When a point query is performed, when the data is present in the cache and is stored as such a row, the entire row associated with the queried key can be directly obtained from the cache, thereby eliminating the need for block-level lookups and improving cache hit rates. However, row storage takes up more space in the memory and requires further overhead. Therefore, the data cache manager 118 may determine the form in which the data is to be cached, such as the blocks or rows discussed herein. Non-limiting examples of factors evaluated by the data cache manager 118 may include the size of the row, the cache eviction policy, memory utilization, and the overall impact on query performance. The data cache manager 118 may determine whether to store cache information as a block or a row based on these factors, and direct such storage to the cache.

[0049] File system 120 is a file system configured to communicate with database system 100 through front-end and / or back-end input / output (I / O) systems. File system 120 may include a connection to a drive such as an SSD provided in the kernel space of a computing system including database system 100.

[0050] Figure 2 An index structure according to an embodiment is shown. Cache memory 200 contains a first level compact index 202 and one or more second level compact indexes 204. Storage memory 206 contains large object files 208, each large object file 208 having a large object file digest 210.

[0051] The cache memory 200 is a cache memory separated from the storage memory 206. The cache memory 200 may include one or more suitable memory devices for caching operations, such as DRAM, PMEM, one or more SSDs (such as NVMe SSDs), etc. The cache memory is configured to store a compact index. In an embodiment, the compact index can be accessed without accessing the storage memory 206. The compact index may contain a key value obtained by separating the key value from the data component in the large object file 208. In an embodiment, the key value separation mechanism utilizes the LSM tree structure, thereby providing advantages such as block-level disk indexes and compressed data blocks to reduce index overhead. In an embodiment, the compact index can identify data in response to a point query without accessing the storage memory 206. The compact index stored in the cache memory 200 may include a first-level compact index 202 and a second-level compact index 204.

[0052] The first level compact index 202 maps keys to the large object file number (blob_file_no) of the large object file 208. The first level compact index can be stored in any suitable file, such as residing in an SST file. Each SST file can have an associated SST file summary, which can contain the first level compact index 202. The first level compact index 202 can be organized according to the LSM tree structure, receiving the result of key-value separation in the form of an LSM tree and storing it accordingly.

[0053] The second level compact index 204 maps keys to block offsets (block_offset) within the large object file 208. Each large object file 208 may have a corresponding large object file digest 210 that contains the offsets referenced by the corresponding second level compact index 204. For the second level compact index 204, a large object file digest 210 may be generated for each corresponding large object file 208 to store the offsets corresponding to each second level compact index 204.

[0054] Storage memory 206 is a repository configured to store data of a database, such as large object files 208. Storage memory 206 may be any suitable storage memory, such as PMEM, SSD, HDD, etc. Large object files 208 are binary large objects, such as binary data blocks, for example, binary data encoding large objects (such as video, audio, images, combinations thereof, etc., as non-limiting examples). These large object files may include large object file digests 210, which contain data referenced by the second level compact index, so that the large object file digests 210 can identify valid data blocks according to the offsets provided in the second level compact index 204.

[0055] Figure 3 An example of key storage according to an embodiment is shown. After key value separation, an SST file can be generated, which contains first-level index data that associates each key with a specific large object file number. The size of this SST file can be reduced to generate a compact index. The compact index can be generated by any appropriate means to reduce the size of the first-level index data while maintaining its index attribute. Examples of methods for generating compact indexes include reducing the number of index keys, or reducing the size of the key by compression. The method for generating a compact index can be adaptively selected to reduce memory overhead. The adaptive selection can be based on the memory overhead estimate determined for each corresponding method to select a key reduction or compression method. The memory overhead for each method can be determined based on the characteristics of the SST file (such as the size of the SST file, the content of the SST file, etc.). Adaptive selection of memory overhead and a compact index method with reduced memory overhead can be performed for each SST file. The resulting compact index can be stored in a cache memory so that a point search related to the value in the data indexing the key is subsequently performed.

[0056] The reduction in the number of indexed keys can be achieved by appropriately removing keys from the compact index. In an embodiment, the boundaries of adjacent keys pointing to the same large object file are stored in the compact index. Figure 3As shown in, in this method, key 1, key 4, and key 8 are saved because they represent the boundaries between files. When the engine needs to find the specific large object file number where the expected value is located based on the key in the first-level index, a binary search between these three keys will be performed to locate the corresponding file number. Since this method of generating a compact index does not store all keys, false positives may occur. When a false positive occurs, the real key content must be obtained from the large object file, which requires an I / O operation to the storage medium containing the large object file. Therefore, false positives reduce the advantages of the cached compact index in reducing storage I / O operations during point searches. In order to solve the false positive problem from the reduced key set, a Bloom filter for all keys can be generated and used to identify locations where there is no response data to reduce the false positive rate. The Bloom filter can be stored in a compact index generated according to this method. The size of the compact index formed in this way and the space savings generated compared to the original SST file can be variable, depending on the number of keys found at the boundaries between files. Reducing index keys according to file boundaries depends on the arrangement of key-value pairs within large object files. Thus, in the case of interleaving of key-value pairs, boundaries will be detected frequently, and the extent to which the number of index keys is reduced due to such interleaving may be reduced, resulting in a relatively high memory overhead for the compact index obtained by removing keys. In an embodiment, background compaction may be performed to rewrite all values, resulting in consecutive key-value combinations being written back to the same large object file.

[0057] The compression of the key may be performed by any suitable compression algorithm. Non-limiting examples of suitable compression algorithms or libraries include Zstandard, LZ4, Snappy, Bzip2, LZMA, Gzip, Blosc, Crit-Bit-Trie, etc. The compression ratio and / or the speed of operation of the compression algorithm may be used as a selection criterion for the compression algorithm to be used. Figure 3 In the embodiment shown in , a Crit-Bit-Trie is used to compress the key. In an embodiment, the compressed key may include additional storage of a hash value of the key to reduce false positive rates and reduce the performance of additional storage I / O operations. The hash value may be stored in any suitable form. In an embodiment, a 1-bit hash width may be used. Figure 3 In the embodiment shown in , all keys are included in the compact index and compressed using Crit-Bit-Trie, each key will consistently consume 3B, and the size of the resulting compact index will be adjusted accordingly.

[0058] Figure 4 FIG. 1 shows a logical flow for preparing a compact index according to an embodiment. SST data is obtained from disk and a compact index is generated. Figure 4As shown in , the memory cost is determined for the corresponding option of reducing the number of indexed key value combinations or reducing the key size by compression. The option with the lower memory cost is executed, and then the memory cost for the corresponding option is calculated again. When the reduction of the indexed key value is selected based on the second memory cost calculation, the key value at the boundary of the specific large object file is identified and the Bloom filter is generated, as described above with respect to Figure 3 When compression of the key value is selected based on the second memory cost calculation, compression is performed. The resulting compact index and the method used for the compact index can then be written to the SST file.

[0059] Figure 5 An example of executing a read request according to an embodiment is shown. Figure 5 In the embodiment shown in , the original KV data from the SST for the compact indexes corresponding to L(0) and L(1) are used directly, while the compact index is only provided at L(2). Figure 5 With the index cache in DRAM provided in , the original SST is cached for the higher layers of the tree, which does not contribute much to the overall size of the tree in terms of required storage space. Figure 5 , the total space occupied by L(0) and L(1) is only about 10% of the entire LSM tree. Therefore, storing the entire SST for higher levels of the tree does not significantly increase memory overhead compared to caching SST file summaries for all levels. Storage of the entire tree at a high level can reduce the number of storage I / O operations required in the event of a cache miss and allow cache misses to be resolved more efficiently, thereby ensuring stable read latency. In an embodiment, storage of the entire tree at a high level can ensure that at most only one storage I / O operation is required when a cache miss occurs.

[0060] Figure 6 FIG. 1 shows the structure of a large object file in the database system 100 according to an embodiment. Figure 6 The large object file is a repository of real key-value data, which provides a large object file summary. The large object file summary can be a large object file summary based on a second-level compact index, such as the second-level compact index 204 described above. The large object file summary contains compact index data implemented for point queries. The index block of the large object file can also be maintained in the large object file instead of being replaced by the compact index, so that the index block of the large object file can be used to facilitate search operations, while the large object file summary is used to obtain operations, such as point queries.

[0061] In a large object file summary, a segmented Crit-Bit-Trie structure can be used to arrange the index. Segmenting the large object file summary can improve memory access locality, for example by reducing the space that may be required to randomly access bit positions. In addition, segmenting the large object file summary can control the size of the Crit-Bit-Trie index, thereby supporting caching of the index. In addition, limiting the size of the index can also reduce read latency fluctuations caused by large read I / O amplification when the index must be read from disk (for example, due to cache misses). Segmenting the Crit-Bit-Trie index can include indexing specific locations of the Crit-Bit-Trie block based on a key, or within the Crit-Bit-Trie block, indexing the location of the data block within the large object file based on the corresponding key. Each data block can be a compression unit of the large object file, for example, a compression unit of the large object file, such as a 16KB portion of the large object file.

[0062] Figure 7 The construction of the index structure according to the embodiment is shown. Figure 7 The constructed index structure is a Crit-Bit-Trie index. The Crit-Bit-Trie index can convert the Trie-based string retrieval into a binary tree by extracting the CritBit. The CritBit is the location where the difference occurs in the binary representation of the two keys. The key can be queried in a byte-by-byte manner by comparing the position of the CritBit in the key set to find the only leaf for the desired key. Since the width of the key is not affected by the overall original key length after this transformation, and only the position of the CritBit is recorded, the bit width can be reduced, thereby compressing the key.

[0063] like Figure 7 As shown in , a string is used to generate a Trie structure, and then the Trie is used to obtain the difference (change / increment) to identify the CritBit. The structure of the tree can be stored as BitArray_1, such as Figure 7 As shown in . In order to obtain BitArray_1, the binary tree structure can be converted using the level ordered unary degree sequence (LOUDS). The tree structure conversion according to LOUDS can use 1 as the representation of internal nodes and 0 as the leaf nodes when converting the tree structure. Then, the subsequent operations on the binary tree can be replaced by the sorting / selection (Rank / Select) operations on the bit array (BitArray). As shown in Figure 7 The BitArray_2 shown in FIG. 1 may contain CritBits, which are arranged and stored in ascending order. When the index includes a block offset (such as Figure 2In the second level compact index 204 shown in and described above), the block offset may be recorded in a vector of each block offset corresponding to the correct record of compressed data. In an embodiment, the CritBits may be stored in a binary tree; the tree may be provided to preserve the structure of the original binary tree. In an embodiment, such a binary tree storing the CritBits may be an array of unsigned integers representing the minimum bit width.

[0064] Figure 8 An example of a process for index reading according to an embodiment is shown. Figure 8 In the example shown in , there are 6 keys (denoted as 1 to 6) and 5 CritBits (denoted as ABCDE). During index construction, lower CritBits are provided at upper levels of the tree to maintain the same order as lexicographic comparison (from low byte to high byte).

[0065] Initially, the index function starts at the root of the binary tree and traverses downward. When the bit pointed to by the node is 0, the index function moves to the left subtree; otherwise, the index function moves to the right subtree until a leaf node is reached. The index function returns the position number of the key (e.g., Figure 8 As shown in , the position number of key 2 is 1 and the position number of key 5 is 4). Then, the corresponding complete key (best_match_key) is found based on the position number. The index function then checks whether the identified best_match_key is equal to the target_key of the index read operation. If they are an exact match, the function directly returns the best_match_key.

[0066] If best_match_key is not equal to target_key for the index read operation, it means that the path taken is incorrect and a new search is performed. In the new search, a common prefix is ​​found for best_match_key and target_key. This identifies the valid part of the binary tree path. The search that follows the common prefix is ​​then replanned. If the value of target_key is greater than the value of the determined best_match_key, the function moves from the node after the common prefix node to the right subtree until it reaches a leaf node and increases the position of the leaf node by 1. If the value of target_key is less than the value of the determined best_match_key, the function moves from the node after the common prefix node to the left subtree until it reaches a leaf node, which is the final result.

[0067] As a basis Figure 8, when the target key is 00001, after the indexing process, the best_match_key is key 1, and since the target_key is greater than the best_match_key, the function needs to start at node A and move right and reach position 1. After adding 1 to that position, it returns position 2 and key 3. When the target key is 00011, after the indexing process, the best_match_key is key 3, and since the target_key is greater than the best_match_key, the function needs to start at node D and move right and reach position 5. After adding 1 to the position, it returns position 6 and ends. When the target key is 00010,001, after the indexing process, the best_match_key is key 5, and since the target_key is less than the best_match_key, the function needs to start at node E and move left and reach position 4, returning position 4 and key 5. When the target key is 00010,00100,01, after index processing, the best_match_key is key 6, and because the target_key is less than the best_match_key, the function needs to start from node E to the left, reach position 4, and return position 4 and key 5.

[0068] Fig. 9 An index cache according to an embodiment is shown. Fig. 9 The compact index cache shown in can include two layers. The first layer can be stored in the SST file summary after key-value separation. The format of the index data of the first layer can be that the key points to a specific large object file number. The second layer can be stored in the large object file summary after key-value separation, and the format is that the key points to the data block offset. Both layers of the index contain index metadata. These metadata can also be retained in the cache. The size of the index metadata can be approximately 1.4B or less per entry. Therefore, for a database with approximately 4 billion entries, the index metadata will occupy a total of approximately 5.6GB or less of memory, allowing these index metadata to be cached.

[0069] The index metadata can be organized into an LSM tree. When the index metadata is in LSM tree format, the search of the index can be performed as a top-down sequential process. The search can include first looking at each SST file at level L(0), then searching the corresponding SST files at levels L(1) to L(N-1) in sequence, and finally performing a search in the corresponding SST file digest at level L(N), and then leading to the search for the correct large object file digest and the correct location within the large object file, such as Fig. 9, as shown in the path taken on the corresponding file in . When the index metadata for each file is fully cached, at most one I / O operation is required for the index data of each file. The index data itself can include data from the first-level index L(N) in all SST file summaries and data from the second-level index in the large object file summary. The index data can be provided in a single LRU cache to replace the first and second levels of the index.

[0070] Fig.10 The write-to-read cache transformation according to an embodiment is shown. The write-to-read cache transformation can be performed by a suitable module of the database system, such as Figure 1 , and described above are written to the read cache manager 114. Fig.10 As shown in , when the compression of blocks 1 and 2 results in the formation of block 3 in the database, the indexes of blocks 1 and 2 will be invalid, resulting in a cache miss after compression. The write-to-read cache transformation generates index data for block 3 and writes the index information to the index cache after block 3 is generated by compression. The active writing of index data for block 3 can be triggered by any appropriate condition to prevent pollution caused by excessive cache of index information.

[0071] Fig.11 1 shows preheating of the index cache according to an embodiment. Preheating of the index cache can be performed by a cache heater module, such as Figure 1 Cache heater 116 shown in and described above. During database startup, the index cache is empty. By preheating the index cache, for example according to Fig.11 , which can reduce or avoid cache misses and latency fluctuations during point queries after startup. When the database starts, the background thread traverses all files on the disk that contain first-level index data and large object file summaries that contain second-level index data within the database. Compact index data can be obtained from the first-level index data (such as SST file summaries and large object file summaries). The compact index data obtained from the disk can then be placed into the index cache to form a compact index cache to support future point queries. Adding compact index data to the compact index cache can reduce potential cache misses and improve overall query performance.

[0072] Fig.12A flow chart of a method for point querying according to an embodiment is shown. The method 1200 includes obtaining index information from a database at 1202, compressing the index information using a processor at 1204, and storing the index information in a cache memory at 1206. The method also includes receiving a point query at 1208, identifying data responsive to the point query at 1210, and retrieving the responsive data from the database at 1212. The method 1200 optionally also includes removing some of the index information at 1214. Optionally, the method 1200 also includes accessing the database at 1216 to obtain index information that is not present in the cache memory.

[0073] At 1202, index information is obtained from a database. The index information may be obtained by a processor at 1202. The index information may be, for example, a key value for a corresponding data component. When the index information is obtained from the database at 1202, the index information may be separated from the data component. The index information may be used to provide an index of the data component of the database. The database storing the index information and the data component from which the index information is obtained may be located on any suitable storage medium, such as one or more PMEMs, SSDs, HDDs, etc.

[0074] At 1204, the index information may be compressed. The compression may be performed by the processor that obtained the index information at 1202. The compression of the index information may reduce the size of the index, for example to support storing part or all of the index in a limited cache memory. The compression of the index information may be performed by applying any suitable compression algorithm, non-limiting examples of which include Zstandard, LZ4, Snappy, Bzip2, LZMA, Gzip, Blosc, and Crit-Bit-Trie compression algorithms. In an embodiment, the compression of the index information at 1204 may be performed by applying a Crit-Bit-Trie compression algorithm. For example, when the compression algorithm is used according to the above description of Figure 2 and Figure 3 When Option 2 discussed to store the key values, compression may be performed at 1204 .

[0075] The index information may be stored in a cache memory at 1206. The cache memory may be any suitable cache memory device or devices, non-limiting examples include DRAM, PMEM, SSD, etc. The index information may be stored in the cache memory at 1206 so that the index information may be referenced when a point query is received without accessing the storage memory of the database.

[0076] A point query may be received at 1208. A point query may be a request for specific information from a database. The point query may be received from any suitable source, such as user input, other system components, an API, etc. The point query may be received at a processor. In an embodiment, the processor may be the same processor that obtains the index information at 1202 and / or compresses the index information at 1204.

[0077] Data responsive to the point query is identified at 1210. Data responsive to the point query may be identified by reference to index information stored in a cache memory. Data responsive to the point query may be identified by associating a key value with a particular file. The response data may then be retrieved from the database at 1212. The response data may be retrieved by an I / O operation to a storage disk containing the response data. In an embodiment, the I / O operation performed to the storage disk to retrieve the response data may be the only I / O operation required to implement and complete the point query received at 1208.

[0078] Optionally, some of the index information may be removed at 1214. The index information may be removed to reduce the size of the index information, for example, to allow the index information to be stored in a cache memory even when cache space is limited. The removed index information may be from the index information stored in the cache memory, where the index information in the storage medium of the database is maintained. The index information may be removed based on a policy that supports the relevance of the index information maintained in the cache memory. A non-limiting example of a policy for removing index information at 1214 may be a least recently used (LRU) policy.

[0079] The database may be accessed to obtain index information that is not present in the cache memory at 1216. The access to the database at 1216 may be access to one or more memories of a storage medium of the database. The access to the database at 1216 may be performed when a cache miss occurs and data responsive to the point query cannot be determined based on the index information stored in the cache memory. For example, a cache miss may occur when the removal of index information at 1214 affects the index information associated with the point query received at 1208. The access to the database may provide index information associated with the point query received at 1208 so that data responsive to the point query may be successfully identified and subsequently obtained from the storage medium of the database.

[0080] Fig.13A key-value system integrated with a file system according to an embodiment is shown. The key-value store and file system 1300 includes a key-value system 1302. The key-value system 1302 includes a log engine 1304, a hash engine 1306, a sort engine 1308, and a garbage collection manager 1310. The key-value store and file system 1300 also includes a collaboration layer 1312 and a file system 1314. The key-value store and file system 1300 can interact with a kernel space 1316, which includes one or more disks 1318. The key-value store and file system 1300 can interact with an application 1320.

[0081] The key-value and file system 1300 can be used for storage in cloud applications, for example, to provide data persistence required by cloud services. The key-value system 1302 is configured to provide key-value storage, for example, as part of the storage backend of a cloud service. Non-limiting examples of cloud services using the key-value system 1302 include shopping, social media, metadata management, etc. The file system 1314 can be a dedicated user-level append-only file system that is configured to provide storage specifically to facilitate the operation of the key-value system 1302.

[0082] Journal engine 1304 is configured to allow to write multiple log files simultaneously, thereby reducing the number of compression and garbage collection operations. The journal that journal engine 1304 writes can be configured to make processing described journal not need strong sorting. Journal engine 1304 is configured to, by reducing the synchronous write overhead of journal from multiple input / output (I / O) operations to single I / O operation, using lockless queue aggregation to write to control delay and improve throughput and / or providing asynchronous interface to enhance thread model, improve the throughput performance problem in journal writing and improve recovery speed. In the case that key value system 1302 and file system 1314 are integrated and cooperated, journal engine 1304 can be used to store pre-write log (WAL) with predefined structure, and this predefined structure has defined actual file size. The definition file size for WAL can cause needing less I / O operation in turn, thereby improving performance, and simultaneously alleviating the potential trade-off relevant with data consistency.

[0083] The hash engine 1306 is configured to process point queries within the key-value system 1302. In particular, the hash engine 1306 is configured to reduce tail latency in point queries. The hash engine 1306 includes separation of data and index components, and maintaining the index in a cache memory, for example, by compressing the index and / or caching partial data. The partial data can be selected using, for example, a least recently used strategy. The operation of the hash engine 1306 is further detailed herein.

[0084] The sorting engine 1308 is configured to perform range scan operations while reducing write amplification factors and / or read / write latency associated with such operations. The sorting engine 1308 is configured to use a partitioned log structure merge (LSM) tree. The classification of I / O streams and the scheduling of tasks can also be performed by the sorting engine 1308.

[0085] The garbage collection manager 1310 is configured to perform garbage collection and / or compression operations in the key-value and file system 1300. The garbage collection manager 1310 can be configured to reduce unnecessary data movement during garbage collection and / or compression operations in the key-value and file system 1300. The garbage collection manager 1310 can perform garbage collection and / or compression operations based on knowledge of application-side data deletions (such as page expiration). The garbage collection and compression performed by the garbage collection manager 1310 can be configured to arrange data to support other modules such as the sorting engine 1308. The garbage collection manager 1310 can coordinate the preservation of data during garbage collection and / or compression operations. The operation of the garbage collection manager 1310 is Fig.13 are further detailed in and described below.

[0086] The collaboration layer 1312 is configured to facilitate collaboration between the key-value system 1302 and the file system 1314. Based on the collaboration between the key-value system 1302 and the file system 1314, the collaboration layer 1312 can also facilitate efficient compression and / or garbage collection operations in the key-value system 1302. The collaboration can reduce write amplification problems caused by compression and / or garbage collection operations. In an embodiment, the collaboration layer 1312 can disclose region usage information from the key-value system 1302 to the file system 1314.

[0087] The file system 1314 can be configured to split data from the log and use a log-structured append-only write as a write model, where append-only operations can be performed. In an embodiment, the file system can also provide pre-allocated data space, where synchronous writes occur only for data persistence, and in an embodiment, metadata persistence is not required. In an embodiment, data persistence and global log persistence for different files can be performed separately. These aspects of the file system can allow the file system to avoid some metadata persistence operations, such as those caused by a single data write persistence operation.

[0088] File system 1314 can be configured to support general files and instant files. General files and instant files can both be written sequentially, and can both be read sequentially or randomly. General files can be optimized for continuous low latency in sequential or random reads. General files can be used to write data in batches, and there is no need to flush data (such as SST files) to disk after each write. Storage space is allocated in large units, and a non-limiting example of unit size is 1MB. Large allocation units can reduce the metadata size of general files so that the metadata of all general files can be stored in memory during normal file system operations. By storing metadata in memory, no matter how the read offset is, the read operation of general files does not require further I / O to access metadata. This can reduce the read tail latency of general files. Instant files can be optimized for fast, incremental synchronous writes, while having good sequential and random read performance near the tail. Instant files can be used to write data that needs to be frequently flushed to disk to achieve instant durability, such as pre-written log files of key-value systems. For instant files, data and metadata written separately each time can be bundled together. Bundled data and metadata can be written to a journal file that is shared by all instant files. Bundling data and writing it to a journal file can improve the speed of incremental writes and sync operations. This approach is structured to support sequential reads, but there may be tradeoffs in terms of random reads. Since instant files are expected to be mostly read sequentially, and random reads are mainly concentrated near the tail, the most recently written data for each instant file that is actively being written can be cached to improve read performance.

[0089] The file system 1314 may include a user space I / O scheduler to assign I / O priorities to different I / O types. The I / O scheduler marks the foreground I / O as a high priority, while the background I / O will be marked as a low priority. In addition, the key value system 1302 may include a scheduler for scheduling its background tasks to ensure that each I / O issued by the upper application has a consistent I / O amplification. By jointly designing I / O scheduling in the key value system 1302 and the file system 1314, since both I / O amplification and I / O latency are consistent, the tail latency can remain stable and low. In addition, reading common files from the file system does not require the I / O of metadata, and using large spaces for common files can ensure that most read operations only require a single I / O.

[0090] Kernel space 1316 may contain disks 1318. Disks 1318 may include one or more storage media, such as solid-state drives (SSDs). In an embodiment, at least some of disks 1318 are zoned storage (ZNS) SSDs.

[0091] Application 1320 is any suitable application that utilizes key-value and file system 1300, for example, online shopping, social media, metadata management applications, etc. Application 1320 may interface with key-value and file system 1300 through any suitable application programming interface (API). In an embodiment, the API may be specific to a particular type of file, for example, whether the nature of the file is a general file or an instant file is determined by the API that receives the file.

[0092] In an embodiment, the method further comprises acquiring initial index data when starting the database, and storing the initial index data in a cache memory.

[0093] All aspects:

[0094] It is understood that any one of aspects 1-10 can be combined with any one of aspects 11-20 or 21-22. It is understood that any one of aspects 11-20 can be combined with any one of aspects 21-22.

[0095] Aspect 1. A database system comprising:

[0096] One or more memories storing a database;

[0097] Cache memory; and

[0098] One or more processors, wherein the one or more processors together are configured to:

[0099] Obtaining index information from a database, wherein the index information is separated from data components of the database;

[0100] generating a compact index based on the index information, wherein the compact index is smaller in size than the index information, the compact index being generated by at least one of compressing the index information and omitting a portion of the index information from the compact index;

[0101] directing storage of the compact index in the cache memory;

[0102] Receiving point query;

[0103] identifying data responsive to the point query by reference to a compact index stored in the cache memory; and

[0104] Data is retrieved from the database in response to the point query.

[0105] Aspect 2. The database system according to Aspect 1, wherein the index information includes a first-level index and a second-level index, wherein the first-level index maps the key to the large object file number, and the second-level index maps the key to the block offset within the large object file.

[0106] Aspect 3. A database system according to any one of Aspects 1-2, wherein the one or more processors are configured to perform compression of index information using a compression algorithm selected from a group including Zstandard, LZ4, Snappy, Bzip2, LZMA, Gzip, Blosc, and Crit-Bit-Trie compression algorithms.

[0107] Aspect 4. The database system according to Aspect 3, wherein the compression algorithm is Crit-Bit-Trie.

[0108] Aspect 5. The database system according to any one of aspects 1 to 4, wherein the one or more processors are configured to select the portion to be omitted from the index information based on a least recently used strategy.

[0109] Aspect 6. A database system according to any one of Aspects 1-5, wherein the portion of index information omitted from the compact index is stored in one or more memories, and the one or more processors are configured to obtain the omitted index information from the one or more memories when the index information stored in the cache memory does not respond to a point query.

[0110] Aspect 7. The database system according to any one of Aspects 1 to 6, wherein the compact index stored in the cache memory includes all index metadata for the index information.

[0111] Aspect 8. A database system according to any one of Aspects 1 to 7, wherein the one or more processors are configured to perform cache warming when the database is started, the cache warming comprising obtaining initial index data and storing the initial index data in a cache memory.

[0112] Aspect 9. The database system according to any one of Aspects 1 to 8, wherein the size of each key value entry of the index information stored in the cache memory is 6B or less.

[0113] Aspect 10. A database system according to any one of Aspects 1-9, wherein the one or more processors are configured to identify data responsive to a point query and to retrieve the data responsive to the point query from one or more memories storing the database using a single input / output operation.

[0114] Aspect 11. A method for point query of a database, comprising:

[0115] Obtaining index information from a database, the index information being separate from data components of the database;

[0116] Using a processor, generating a compact index based on the index information, wherein generating the compact index comprises at least one of: compressing the index information, and omitting a portion of the index information from the compact index;

[0117] storing the index information in a cache memory;

[0118] Receiving point query;

[0119] identifying data responsive to the point query by referring to index information stored in the cache memory; and

[0120] The response data is retrieved from the database.

[0121] Aspect 12. The method according to Aspect 11, wherein the index information includes a first-level index and a second-level index, the first-level index maps the key to the large object file number, and the second-level index maps the key to the block offset within the large object file.

[0122] Aspect 13. A method according to any one of Aspects 11-12, wherein generating a compact index comprises compressing the index information using a compression algorithm selected from a group including Zstandard, LZ4, Snappy, Bzip2, LZMA, Gzip, Blosc and Crit-Bit-Trie compression algorithms.

[0123] Aspect 14. The method according to aspect 13, wherein the compression algorithm is Crit-Bit-Trie.

[0124] Aspect 15. The method according to any one of aspects 11-14, wherein generating a compact index comprises omitting the portion of index information from the compact index, wherein the portion of index information is determined based on a least recently used policy.

[0125] Aspect 16. The method according to aspect 15, wherein when the index information stored in the cache memory does not respond to the point query, the method further comprises accessing a database to obtain the omitted portion of the index information.

[0126] Aspect 17. The method according to any one of Aspects 11-16 further comprises performing cache warming when the database is started, wherein the cache warming comprises obtaining initial index data and storing the initial index data in a cache memory.

[0127] Aspect 18. The method according to any one of aspects 11-17, wherein identifying data responsive to the point query and retrieving the responsive data from the database are performed using a single input / output operation.

[0128] Aspect 19. The method according to any one of Aspects 11 to 18, wherein the size of each key value entry of the index information stored in the cache memory is 6B or less.

[0129] Aspect 20. The method according to any one of aspects 11-19, wherein the compact index stored in the cache memory includes all index metadata for the index information.

[0130] Aspect 21. A hash engine system for a database, comprising one or more processors, wherein the one or more processors are configured to:

[0131] receiving index information, wherein the index information is separated from data components of a database;

[0132] Generating a compact index based on the index information, wherein generating the compact index comprises at least one of: compressing the index information, and omitting a portion of the index information from the compact index; and

[0133] Directs storage of compact indexes in cache memory.

[0134] Aspect 22. The hash engine system according to Aspect 21, wherein the one or more processors are further configured to:

[0135] Receiving point query;

[0136] referencing the compact index to determine data responsive to the point query; and

[0137] Based on the compact index, data responsive to the point query is retrieved from the database.

[0138] The examples disclosed in this application should be considered in all respects as illustrative and not restrictive. The scope of the invention is indicated by the appended claims rather than the foregoing description; and all changes within the equivalent meaning and range of the claims are intended to be included therein.

Claims

1. A database system, comprising: One or more memories storing a database; Cache memory; as well as One or more processors, wherein the one or more processors together are configured to: obtaining index information from the database, wherein the index information is separated from data components of the database; generating a compact index based on the index information, wherein the compact index is smaller in size than the index information, the compact index being generated by at least one of compressing the index information and omitting a portion of the index information from the compact index; directing storage of the compact index in the cache memory; Receiving point query; identifying data responsive to the point query by reference to the compact index stored in the cache memory; as well as The data responsive to the point query is retrieved from the database.

2. The database system according to claim 1, wherein the index information includes a first-level index and a second-level index, the first-level index maps keys to large object file numbers, and the second-level index maps keys to block offsets within the large object file.

3. The database system of claim 1 , wherein the one or more processors are configured to: perform the compression of the index information using a compression algorithm selected from the group consisting of Zstandard, LZ4, Snappy, Bzip2, LZMA, Gzip, Blosc, and Crit-Bit-Trie compression algorithms.

4. The database system according to claim 3, wherein the compression algorithm is Crit-Bit-Trie. 5 . The database system of claim 1 , wherein the one or more processors are configured to select the portion to be omitted from the index information based on a least recently used strategy.

6. A database system according to claim 1, wherein the portion of the index information omitted from the compact index is stored in the one or more memories, and the one or more processors are configured to: obtain the omitted index information from the one or more memories when the index information stored in the cache memory does not respond to the point query. 7 . The database system according to claim 1 , wherein the compact index stored in the cache memory includes all index metadata for the index information.

8. The database system according to claim 1, wherein the one or more processors are configured to: perform cache warming when the database is started, the cache warming comprising obtaining initial index data and storing the initial index data in the cache memory.

9. A database system according to claim 1, wherein the one or more processors are configured to: identify the data responsive to the point query, and retrieve the data responsive to the point query from the one or more memories storing the database using a single input / output operation.

10. A method for point query of a database, comprising: Acquire index information from the database, the index information being separated from data components of the database; Based on the index information, using a processor, generating a compact index, wherein generating the compact index comprises at least one of: compressing the index information, and omitting a portion of the index information from the compact index; storing the index information in a cache memory; Receiving point query; identifying data responsive to the point query by referring to the index information stored in the cache memory; as well as The response data is retrieved from the database.

11. The method of claim 10, wherein the index information comprises a first level index that maps keys to large object file numbers and a second level index that maps keys to block offsets within the large object file.

12. The method of claim 10, wherein generating the compact index comprises compressing the index information using a compression algorithm selected from the group consisting of Zstandard, LZ4, Snappy, Bzip2, LZMA, Gzip, Blosc, and Crit-Bit-Trie compression algorithms.

13. The method of claim 12, wherein the compression algorithm is Crit-Bit-Trie.

14. The method of claim 10, wherein generating the compact index comprises: The portion of the index information is omitted from the compact index, wherein the portion of the index information is determined based on a least recently used policy.

15. The method according to claim 14, wherein when the index information stored in the cache memory does not respond to the point query, the method further comprises: The database is accessed to obtain the omitted portion of the index information.

16. The method according to claim 10, further comprising: Cache pre-warming is performed when the database is started, wherein the cache pre-warming includes acquiring initial index data and storing the initial index data in the cache memory.

17. The method of claim 10, wherein said identifying of said data responsive to said point query and said retrieving of said responsive data from said database are performed using a single input / output operation.

18. The method of claim 10, wherein the compact index stored in the cache memory includes all index metadata for the index information.

19. A hash engine system for a database, comprising one or more processors, wherein the one or more processors are configured to: receiving index information, wherein the index information is separate from data components of the database; generating a compact index based on the index information, wherein generating the compact index comprises at least one of: compressing the index information, and omitting a portion of the index information from the compact index; and Storing of the compact index in the cache memory is directed.

20. The hash engine system of claim 19, wherein the one or more processors are further configured to: Receiving point query; referencing the compact index to determine data responsive to the point query; and The data responsive to the point query is retrieved from a database based on the compact index.

Images