A globally optimized key-value storage method and device

Abstract

This invention discloses a globally optimized key-value storage method and device. Key-value pairs are stored using a GHLSM data storage structure, which is divided into a recording layer and a non-recording layer. The core data structure, GHmap, records the layer containing the latest version of a key-value pair within the recording layer. This core data structure, GHmap, helps key-value pairs determine whether they are outdated and require self-destruction during compaction, and helps index the layer containing the latest version of the key-value pair during queries, thereby avoiding the additional I / O overhead caused by useless data continuing to participate in subsequent compaction processes. This invention achieves excellent results in hardware environments such as mechanical hard drives and solid-state drives, effectively improving performance in reading, writing, and range queries.

Description

Technical Field

[0001] The present invention belongs to the field of computer software technology, and in particular relates to a globally optimized key-value storage method and device. Background Art

[0002] To meet the requirements for low-latency writes and updates in interactive scenarios, the Log-Structured Merge-Tree (LSM-Tree) (O'NEIL P, CHENG E, GAWLICK D, et al. 1996. The log-structured merge-tree (LSM-tree). Acta Informatica [J], 33:351-385.) uses an out-of-place update mechanism for data updates. This approach leverages the advantage of sequential writes over random writes on disk, providing low-latency write performance. It uses a compaction mechanism to garbage collect old versions of data and sort key-value pairs, supporting big data analytics operations primarily based on point and range queries. When writing data to a key-value store using an LSM-Tree as its primary data structure, such as RocksDB, the data is first written to a memtable in memory. When the memtable reaches a certain size, it becomes immutable and is no longer modified. The immutable memtable is then written to the L0 layer on disk, generating an SSTable file. Because these immutable memtables may contain duplicate data, the SSTable files in the L0 layer also contain duplicate data. These files are merged and sorted through the compaction process to remove duplicate data and store them in order at the next layer, the L1 layer. Subsequently, when the size of each layer on disk reaches a threshold, a compaction operation is triggered to read, merge, sort, and write the data, achieving garbage collection and layer-by-layer migration.

[0003] When data is frequently updated, key-value storage systems based on log merge trees (LSM-Trees), such as RocksDB, will have the following three problems: (1) Data redundancy and waste of disk space. The out-of-place update mechanism only inserts the new version of the key-value pair into the system and does not immediately delete or replace the old version of the key-value pair. This will result in the system having multiple versions of the value for the same key. When the system has multiple versions of data, queries only require the latest version of the data. The old version of the data is no longer needed by users, but it will still exist on the disk for a period of time, which leads to a waste of disk space. (2) Frequent compaction and serious write amplification problems. The compaction operation requires reading the key-value pairs of multiple SSTable files in two adjacent layers of the LSM-Tree into memory, merging and sorting them, and then writing them to the next layer. There are many old versions of the key-value pairs. If the old version of the key-value pairs does not meet the latest version of the key-value pairs during this compaction process, then although these old versions of the key-value pairs will not be used in subsequent reads or range queries, they will still be continuously read, processed, and written during the compaction process, resulting in useless disk IO. (3) Top-down search, layer by layer, results in a long query path. During a query, key-value pairs are moved down layer by layer during the compaction process, with newer versions of key-value pairs in the upper layers and older versions in the lower layers. Therefore, we must search from top to bottom layer by layer. Each layer may contain candidate SSTable files, and accessing candidate SSTable files results in additional disk access, reducing read performance.

[0004] To solve the above problems, technicians have proposed a variety of solutions, including:

[0005] PebblesDB (RAJU P 2018. PebblesDB: Building Key-Value Stores Using Fragmented Log-Structured Merge Trees[M].) draws on the concept of skip lists and introduces new indexes to further group SSTable files at each level of the LSM-Tree. This weakens the global order constraint and only ensures order between groups, eliminating sorting and deduplication within groups. This reduces compaction overhead and write amplification. However, the disorder of key-value pairs within a group and the presence of duplicate data between SSTable files can compromise read performance and increase query overhead.

[0006] Wisckey (LU L, PILLAI TS, GOPALAKRISHNAN H, et al. 2017. Wisckey: Separating keys from values ​​in SSD-conscious storage. ACM Transactions on Storage (TOS) [J], 13: 1-28.) separates key and value storage, using LSM-Tree to organize key storage and logs to organize value storage. This significantly reduces the depth of the LSM-Tree, improves write performance, and leverages the high parallelism of SSDs to mitigate the impact of key-value separation on query performance. However, this mechanism does not support efficient range queries. Range queries require first iterative searches in the LSM-Tree and then searching the logs for the corresponding values, which is extremely inefficient. Furthermore, this design only supports running on SSDs and cannot provide high-performance queries on hard disks.

[0007] SlimDB (REN K, ZHENG Q, ARULRAJ J, et al. 2017. SlimDB: A space-efficient key-value storage engine for semi-sorted data. 10:2037-2048.) reduces the space occupied by data and indexes in SSTable files by changing the storage method. This reduces the system size and alleviates the problem of space amplification. However, this optimization does not reduce the number of key-value pairs in the system, and a large amount of useless data still exists in the system, making little contribution to alleviating write amplification and read amplification.

[0008] Flatstore (CHEN Y, LU Y, YANG F, et al. 2020. FlatStore: An Efficient Log-Structured Key-Value Storage Engine for Persistent Memory[M], Proceedings of the Twenty-Fifth International Conference on Architectural Support for Programming Languages ​​and Operating Systems. Association for Computing Machinery; Lausanne, Switzerland: 1077–1091.) uses a new hardware NVM (Non-Volatile Memory) instead of hard disks, employing a pure log structure for data storage. It also leverages the multi-core nature of CPUs to divide data into master and slave nodes, achieving a high-throughput, low-latency, and multi-core scalable storage system. However, as a new hardware device, NVM is relatively expensive and has not yet gained widespread adoption. Furthermore, its capacity is insufficient to support large amounts of data, making it less practical. Summary of the Invention

[0009] The purpose of the present invention is to propose a globally optimized key-value storage method and device, and to construct a key-value storage system GHStore that can simultaneously improve system performance in terms of reading, writing, and range query in scenarios with frequent updates. When writing or updating data, GHStore can promptly determine whether an old version of a key-value pair with the same key as the key-value pair already exists in the system, so as to decide whether the key-value pair needs to self-destruct when participating in compaction, and delete useless data with extremely low overhead, thereby avoiding the additional IO overhead caused by the useless data continuing to participate in subsequent compaction processes, thereby achieving the purpose of reducing disk space usage and improving write performance; at the same time, GHStore can quickly locate the layer where the key-value pair of the latest version of the data to be queried is located during querying, thereby avoiding layer-by-layer search of the LSM-Tree, shortening the query path, and achieving the purpose of improving read performance.

[0010] The technical solution adopted in the present invention is as follows:

[0011] A globally optimized key-value storage method comprises the following steps:

[0012] 1) Write the key-value pair to the L0 layer of the data storage structure GHLSM, and insert a new record into the core data structure GHmap or update the original record. The data storage structure GHLSM has N layers, including P record layers L in memory.p , QP are located in the recording layer L of the disk q and NQ non-recording layers L on the disk t , 0≤p≤P-1, P≤q≤NQ-1, NQ≤t≤N-1, Q is the recording layer L p With recording layer L q The total number of,the core data structure GHmap uses a hash table for storage, the key of the hash table corresponds to the key of the key-value pair, and the value corresponds to the key-value pair in the layer where the data storage structure GHLSM is located;

[0013] 2) When the capacity of the L0 layer reaches the threshold, the key-value pair data structure is converted to non-writable, and the L0 layer is marked as the L1 layer. The relevant records in the core data structure GHmap are updated, and a new data structure is generated to construct the record layer L0;

[0014] 3) When L j When the layer capacity reaches the threshold, based on the core data structure GHmap, the L j Is the key-value pair in the layer the latest key-value pair, where 1≤j≤P-1: If so, write L j+1 layer and update the core data structure GHmap; if not, discard it;

[0015] 4) When L i When the capacity of the layer exceeds the corresponding threshold, L i Layer and L i+1 Some key-value pairs in the layer are read into memory as key-value pairs to be processed, merged and sorted, and then combined with the core data structure GHmap to calculate the latest version of the key-value pairs, where P≤i≤N-2;

[0016] 5) Write the latest version key-value pair to L i+1 layer and delete the key-value pairs to be processed.

[0017] Furthermore, the data structure of the data storage structure GHLSM includes: LSM-Tree.

[0018] Furthermore, the recording layer L p The data organization methods in include: using skip lists.

[0019] Furthermore, the core data structure GHmap locates the layer where the key-value pair is located through the following strategy:

[0020] 1) Use GHmap's first hash function Hash1 to calculate the subtable number corresponding to the key

[0021] 2) Use GHmap's second hash function Hash2 and the subtable number where the key is located to calculate the record of the key in GHmap.

[0022] 3) Locate the layer where the new key-value pair is located based on the record.

[0023] Furthermore, the latest version of the key-value pair is calculated using the following strategy:

[0024] 1) When L i Layer and L i+1 Layers belong to the recording layer L q When , request the core data structure GHmap to obtain the layer where the latest version of the key of the merged sorted data is located: if it is the layer where the merged sorted data is located, then get the latest version of the key-value pair;

[0025] 2) When L i Layer and L i+1 The layers all belong to the non-recording layer L t When , the core data structure GHmap is requested to obtain the relevant records of the keys of the merged sorted data: if there are no relevant records, the latest version of the key-value pair is obtained.

[0026] Furthermore, the recording layer L q Non-recording layer L t The formats for storing key-value pairs include: SSTable files.

[0027] Furthermore, the key-value pairs to be processed are selected through the following steps:

[0028] 1) Calculate L i The score of each SSTable file in the layer, and select the SSTable file with the highest score and the adjacent files of the SSTable file with the highest score as L i SSTable files to be processed in the layer;

[0029] 2) In L i+1 Select L in the layer i There are overlapping SSTable files in the layer to be processed, as L i+1 SSTable files to be processed in the layer;

[0030] 3) Combined with L i The SSTable files to be processed in the layer and the L i+1 The SSTable files to be processed in the layer are obtained, and the SSTable file set A of the key-value pairs to be processed is obtained = {s1, s2, ..., s n}, where s is the SSTable file.

[0031] Further, write the latest version key-value pair to L through the following steps i+1 layer and delete the pending key-value pairs:

[0032] 1) Generate a new SSTable file set B = {s′1, s′2, ..., s′ m}, where s′ is the new SSTable file;

[0033] 2) Save the latest version key-value pairs in order to the new SSTable file;

[0034] 3) Delete L i Layer and L i+1 The SSTable file set A in the layer and the new SSTable file set B are added to L i+1 Layer.

[0035] Furthermore, perform point query of key-value pairs through the following steps:

[0036] 1) Use GHmap to locate the layer where the target key-value pair is located;

[0037] 2) When the target key-value pair is located at the record layer L p When , use binary search to obtain the target key-value pair;

[0038] 3) When the target key-value pair is located in L P When the layer is reached, the SSTable file is searched sequentially and the Bloom filter is used to predict L p Whether the target value exists in each SSTable file in the layer: If it is judged to exist and the Bloom filter has not made a misjudgment, the SSTable file is searched and the target key-value pair is read from the corresponding SSTable file;

[0039] 4) When the target key-value pair is located at the record layer L q and not located in L P When searching for a layer, use binary search to obtain the target key-value pair;

[0040] 5) When the target key-value pair is located in the non-record layer L t When the non-recording layer L is searched layer by layer, t , find the SSTable file containing the target value, and obtain the target key-value pair.

[0041] Furthermore, perform range query of key-value pairs through the following steps:

[0042] 1) Call the seek() operation to search the SSTable files of each layer of the data storage structure GHLSM layer by layer, and locate a key in the layer that is greater than or equal to the minimum value of the given range;

[0043] 2) Call next() to determine whether the key of each subsequent key-value pair meets the given range;

[0044] 3) All key-value pairs that meet the requirements are read into memory, merged and sorted, and then returned to the user.

[0045] Furthermore, when the system crashes or loses power, the data in the core data structure GHmap is restored using the following strategy:

[0046] 1) In the recovery record layer L p At the same time as the layer data is added, a new record is inserted into the core data structure GHmap.

[0047] 2)L i Layer SSTable files and L i+1 When performing compaction on the SSTable files of the layer, if the corresponding key-value pairs cannot be found in the core data structure GHmap, all key-value pairs processed by the compaction will be written to the L i+1 At the same time as the layer, it is recorded in the core data structure GHmap.

[0048] A storage medium stores a computer program, wherein the computer program is configured to execute the above method when running.

[0049] An electronic device includes a memory and a processor, wherein the memory stores a program for executing the above method.

[0050] Compared with the existing technology, the advantages of the present invention are:

[0051] 1. Low cost and universal equipment. The present invention is not limited to a specific hardware device and can achieve good results in hardware environments such as mechanical hard drives and solid-state drives.

[0052] 2. Multi-faceted performance improvement: This invention can effectively improve the performance of reading, writing, and range queries. Compared with simply improving the write performance, this invention is more practical. BRIEF DESCRIPTION OF THE DRAWINGS

[0053] Figure 1 This is the GHStore system architecture diagram of the present invention.

[0054] Figure 2 This is the GHmap structure design diagram of the present invention.

[0055] Figure 3A This is an example diagram of compaction algorithm scenario 1.

[0056] Figure 3B This is an example diagram of compaction algorithm scenario 2.

[0057] Figure 3CThis is an example diagram of compaction algorithm scenario 3.

[0058] Figure 3D This is an example diagram of compaction algorithm scenario 4.

[0059] Figure 4 This is the write, update, and delete flowchart for GHStore.

[0060] Figure 5 This is the compaction flowchart of GHStore.

[0061] Figure 6 This is the point query flow chart of GHStore.

[0062] Figure 7 Flowchart of range query for GHStore.

[0063] Figure 8 This is a diagram of the system file size under different update ratios and different value conditions.

[0064] Figure 9 This is a schematic diagram of write amplification under different update ratios and different value sizes.

[0065] Figure 10 Write performance diagrams for different update ratios.

[0066] Figure 11 Write a performance diagram for different value sizes.

[0067] Figure 12 This is a diagram of single-point query performance.

[0068] Figure 13 This is a diagram showing range query performance.

[0069] Figure 14 Schematic diagram of YCSB performance under mixed load. DETAILED DESCRIPTION

[0070] In order to make the objectives, technical solutions and advantages of the present invention more clearly understood, the present invention is further described in detail below with reference to the accompanying drawings.

[0071] 1. GHStore system architecture design

[0072] The overall structure of GHStore is as follows Figure 1As shown in Figure 1, it consists of two parts: the data storage structure GHLSM and the core data structure GHmap. GHLSM is a 7-layer LSM-Tree, divided into the record layer and the non-record layer. GHmap is used to record the layer where the latest version of the key-value pair in the record layer is located. It plays the role of a "God's perspective" and will participate in every link of the system reading and writing. It has two main functions: (1) Helping key-value pairs determine whether they are outdated and need to be self-destructed during compaction. (2) Helping to index the layer where the latest version of the key-value pair is located during query.

[0073] 2. Design of the core data structure GHmap

[0074] GHmap mainly records the location of the key-value pairs of the latest version. Figure 2 As shown, it is a global data structure that needs to participate in all aspects of the write process and involves frequent queries and modifications. Therefore, we use a hash table to store it, where the key of the hash table is the key of the key-value pair in the system, and the value is the layer where the key-value pair is located.

[0075] The SSTable file ID of a file is incremental. Even if the old file has been deleted, its ID will no longer be used and will only continue to increase. Therefore, as the amount of data increases, the ID will continue to increase, and the space overhead for storing it will also continue to increase. However, the data structure LSM-Tree for storing key-value pairs in GHStore has a maximum of 7 layers. Except for the L0 layer, the SSTable files in each layer are disjoint and non-repeated, so the layer where the key-value pair is recorded can also represent the location of a certain key-value pair. Then we only need 1B to locate the location of the key-value pair. At the same time, in the query stage, after we locate the layer where the latest version of the key-value pair is located, the search for the target SSTable file in the layer is determined by comparing the file boundaries in memory, and the time overhead is negligible, so the recording layer can achieve the same purpose as recording the SSTable file ID in a smaller space.

[0076] Since in GHStore, users write data and the backend compaction process are in parallel, so as a global table, GHmap must also support multi-threaded access. Therefore, GHmap is divided into multiple sub-tables in implementation, and the impact of locking on system performance is minimized as much as possible through fine-grained segmented locks based on sub-tables, thereby reducing the overhead brought by the introduction of additional data structures. At the same time, since the sub-tables are divided, the size of each sub-table is much smaller than the size of a table when it is not divided, so the query path will be shortened and the query performance will be improved. After testing, in a multi-threaded environment, dividing the sub-tables can effectively reduce the latency of GHmap, but the number of sub-tables is not the more the better. When the number of sub-tables reaches 16, further division will not bring significant improvement. Therefore, in the present invention, we divided 16 sub-tables.

[0077] GHmap uses open addressing to resolve conflicts. This method avoids the time overhead of allocating address space for each new data entry, making it faster to insert new data. Furthermore, compared to chain addressing, it doesn't require additional space to store the pointer to the next node, resulting in lower memory overhead. To minimize memory usage, we chose a conflict factor of 0.875. Testing has shown that this value achieves both low memory overhead and high query performance.

[0078] 3. Design of data storage structure GHLSM

[0079] GHLSM is a 7-layer LSM-Tree, which is divided into two parts: the recording layer and the non-recording layer. The recording layer is divided into the memory part and the disk part. The memory part includes 2 layers, each layer is composed of one or more memtables, and its structure is organized by the skip list to ensure the order of key-value pairs; the disk part includes N-2 layers, each layer is composed of one or more SSTable files. The number of SSTable files in each layer increases by 10 times from layer to layer, and the compaction operation ensures the order of key-value pairs in the SSTable files of each layer and the garbage collection of old versions of key-value pairs.

[0080] We consider that the L2 layer data is written directly to the disk from the non-writable memtable in memory without merging or sorting operations, so there will be data overlap between each SSTable file, which will have a certain impact on point queries. In extreme cases, each SSTable file in this layer is a candidate file (files with key-value pairs in the SSTable file that meet minKey<key<maxKey are considered candidate files), and disk access is required to determine whether the data to be queried exists. Therefore, we added a Bloom filter to this layer. For each candidate file, the Bloom filter is first used to judge, and the disk is only accessed when the Bloom filter determines that the data to be queried may exist.

[0081] Since GHmap is a data structure located in memory, if we record all the keys, it will cause great memory pressure and reduce the actual availability of the system. Therefore, the present invention further divides the disk part of the GHLSM into a recording layer and a non-recording layer. When the depth of the part of the GHLSM located on the disk is greater than 2, the system will automatically be divided into two parts: the recording layer and the non-recording layer. GHmap only records the layer where the latest version of the key-value pair in the recording layer is located. Therefore, in most cases, for a GHLSM with a depth of N, the recording layer is the 1st layer to the N-2th layer (the first 2 layers are in memory), and the non-recording layer is the N-1 layer and the N layer.

[0082] 4. Analysis of Compaction Scenarios

[0083] When the system triggers compaction, the following four scenarios may occur. The system will take different actions for each scenario.

[0084] (1) Assume that the key-value pairs of the new and old versions at the current moment<Ka,Va*> and<Ka,Va> are located in the recording layer, where<Ka,Va*> For the new version,<Ka,Va> For older versions. During compaction, if they are in adjacent layers, the old version is removed after merging and sorting, and the GHmap (ka) is updated as the output layer. If they are not in adjacent layers, they will not participate in the same compaction process. It is necessary to determine whether the key-value pair participating in the compaction is a new version. The new version is retained in the output, the GHmap is updated, and the old version is discarded. Figure 3A This is an example of a diagram for this scenario. Since the old and new versions are not adjacent, and the new version<Ka,Va*> The layer triggers compaction, so it is retained and output to the next layer, and the GHmap is updated at the same time.

[0085] (2) Assume that the key-value pairs of the new and old versions at the current moment<Kc,Vc*> and<Kc,Vc> are all located in the non-recording layer,<Kc,Vc*> For the new version,<Kc,Vc> This is an old version. Since there are only two non-record layers, the two must be located in adjacent layers. Therefore, during compaction, the first step is to merge and sort to remove<Kc,Vc> , then determine whether the record related to Kc exists in GHmap. If so, it means that there is a newer version of the key-value pair in the record layer, which is discarded; if not, it means that it is the latest version and the output is retained. Figure 3B As an example of the schematic diagram in this scenario, since there is no record of Kc in GHmap, it is retained and output to the next layer.

[0086] (3) Assume that the key-value pairs of the new and old versions at the current moment<Kb,Vb*> and<Kb,Vb> ,in<Kb,Vb*> It is a new version, located at the record layer,<Kb,Vb> It is an old version and is located in a non-record layer. During compaction, if they are in two adjacent layers, the old version is removed after merging and sorting, and the record of Kb in GHmap is deleted. If they are not in two adjacent layers, it is necessary to determine whether the key-value pair participating in the compaction is a new version.<Kb,Vb> You can find the record of Kb in GHmap, and it can know that it is an old version.<Kb,Vb*> It finds that the version recorded in GHmap is itself, and it can also know that it is a new version. Figure 3C For example, the schematic diagram of this scenario is as follows.<Kb,Vb*> and<Kb,Vb> Located in two adjacent layers, they are merged and sorted and then output to the non-record layer, so the records need to be deleted from the GHmap.

[0087] (4) Figure 3D As shown, assuming that the current key-value pair<Kd,Vd*> The first layer is located in the non-record layer, but the second layer is full of data. At this time, a new layer will be created to store the data, and part of the data will be moved to the new layer. At this time, the non-record layer is temporarily three-layered, and we need to restore it to a two-layer structure. According to the algorithm described in (3), because the system cannot find any records in GHmap when moving data to a new layer, it will be considered that these data are new versions. In order to ensure that the data is not deleted by mistake, we will temporarily retain the output, and for the non-record layer, we propose a "fault-tolerant delayed update" mechanism to restore the two-layer structure of the non-record layer. n-2 The first layer of the non-recording layer, level n-1 For the second layer, level n For the last layer, we need to level n-2 Re-record it into GHmap and add it to the record layer. n-2Reaching maximum capacity, level n-2 and level n-1 When compaction occurs, they are all located in the non-record layer, so we process them according to the algorithm shown in (2). n-2 The maximum capacity has not yet been reached, level n-3 and level n-2 If compaction occurs first, the processed data will be written to the level n-2 In the GHmap, the level that needs to be restored is the level that needs to be restored to the record level. n-2 If the system finds the record related to the key-value pair (such as Kd), the key-value pair must be new data and needs to be retained. At the same time, the record will be inserted into the GHmap; if the system can find the level n-2 If there is a record related to a key-value pair (such as Kd), it means that there is a new version of the key-value pair in the first n-2 layers. The key-value pair is outdated and does not need to be retained. In LSM-Tree, the capacity of the lower layer is 10 times that of the upper layer, so in the last layer (level n ) before reaching maximum capacity, level n-2 All key-value pairs will participate in the compaction and update the GHmap. In other words, GHStore completes the structural recovery work with low misjudgment rate and low overhead.

[0088] 4. Fault recovery mechanism

[0089] When the system crashes or loses power, the data in the memory of the storage system will be lost. The data in the memory of GHStore is mainly stored in GHmap and memtable. For the data in the memtable, like LevelDB and RocksDB, we use the write-aheadlog (WAL) method to recover. For the data in GHmap, considering that GHmap records all the keys of the record layer of GHLSM, if the data is restored by traversing layer by layer, it is necessary to access all SSTable files of the record layer in sequence, which will consume a lot of time and cause the system to recover slowly. Therefore, in order to reduce the cost of crash recovery, we proposed a "delayed recovery" mechanism to recover GHmap: if the data cannot be found in GHmap during compaction, it is considered to be a new version, and it is written to the next layer and recorded in GHmap at the same time, and then updated as the compaction process progresses.

[0090] 5.GHStore write, update, and delete processes

[0091] Since GHStore uses a delayed update mechanism to delete and update data, the deletion and update process is basically the same as the write process.

[0092] like Figure 4 As shown in the figure, when a new key-value pair is written into the system, the data is first written into the memtable component of the memory. At the same time, a new record is inserted into the GHmap or the original record is updated, indicating that the key-value pair is the latest version of the key data, located at the memtable layer.

[0093] When the memtable reaches a certain capacity, it becomes immutable, waiting for a background thread to write it to disk. When the background thread arrives, it first checks GHmap to determine whether the key-value pair to be written to disk is the latest version. If so, the new key-value pair is written to the disk record layer as an SSTable file and the core data structure GHmap is updated. If not, the new key-value pair is discarded.

[0094] When the capacity of a certain layer exceeds the threshold and compaction is triggered, some SSTable files of this layer and some SSTable files of the lower layer that overlap with the key range are selected as the files to be processed, read into the memory for merge sorting, and then GHmap is used to determine whether the key-value pairs therein are the latest versions. For all data in the record layer, the judgment method is: whether the layer where the latest version of the key-value pair recorded in GHmap is located is smaller than the layer where the key-value pair is located. If it is equal, it is the latest; if it is smaller, it is expired. For all data in the non-record layer, the judgment method is: if it exists, it is the latest; if it does not exist, it is expired.

[0095] After processing, the system will only write the latest version of the key-value pair to the SSTable file of the next layer. At the same time, the GHmap is updated. If the output layer belongs to the record layer, its related records are updated; if the output layer belongs to the non-record layer, its related records are deleted.

[0096] 6.GHStore compaction process

[0097] like Figure 5 As shown in the figure, when a layer triggers a compaction operation, the system will calculate a score for all SSTable files in the layer, select the SSTable file with the highest score, and read its adjacent files into the memory as the SSTable files to be processed in the layer; accordingly, the SSTable files in the next layer that overlap with the data in these files are read as the SSTable files to be processed in the next layer. We denote this batch of files to be processed as A = {s1, s2, ..., s n}, the system will decompress and convert A and read it into memory for merge sorting, remove duplicate data, and then use GHmap to judge the remaining data in turn. First, determine which part of the GHLSM the data comes from, and execute different algorithm strategies for data from the record layer and data from the non-record layer. For data from the record layer, it is necessary to request GHmap to obtain the layer where the latest version of the key of the current data is located. If it happens to be the layer where the current data is located, it means that it is the latest version and needs to be retained, otherwise it needs to be deleted; for data from the non-record layer, it is necessary to request GHmap to obtain whether there is a record related to the key of the current data. If it does not exist, it means that it is the latest version and needs to be retained, otherwise it needs to be deleted.

[0098] The system then updates all records related to the retained data in GHmap. If the output layer of the compaction is a record layer, the records in GHmap are updated. If the output layer of the compaction is a non-record layer, the records in GHmap are deleted.

[0099] Finally, the system will create a new batch of SSTable files B = {s1, s2, ..., s m}, used to save the latest version of the key-value pair, and put this batch of files into the output layer, while deleting the original files A={s1,s2,...,s n}

[0100] 7. GHStore point query process

[0101] like Figure 6 As shown in the figure, when a request is made to find the value of a key, the GHmap index is used to locate the layer where the value to be found is located.

[0102] If the value to be searched is located in the record layer of memory in GHLSM, that is, in the memtable or immutable memtable, a binary search is performed on the target value and the result is returned to the user;

[0103] If the value to be searched is located in the first layer of the disk's record layer in GHLSM, since the SSTable files of this layer are overlapped, the candidate files of this layer can only be searched sequentially (files whose key-value pairs satisfy minKey<key<maxKey in the SSTable file are considered candidate files). Then use the Bloom filter to predict whether these candidate files contain the value to be searched. Only when it is judged that they exist, the disk read operation will be performed. At this time, due to the characteristics of the Bloom filter, misjudgment may occur. Once a misjudgment occurs, the value cannot be found in the candidate file. The system can only access the next candidate file that is predicted to exist until the target value is read from the file and returned to the user;

[0104] If the value to be searched is located in the record layer of the disk in GHLSM and is not the first layer, since these layers are obtained by compaction processing, the SSTable files in these layers are arranged in order and there are no duplicates (the result of merge sort), so there is only one candidate file, namely the target file. Therefore, a binary search is used to find the file containing the target value, and the target value is read from the file and returned to the user;

[0105] If the value to be searched is in the non-record layer of GHLSM, the files in the non-record layer are searched layer by layer. Since the non-record layer is also obtained by compaction processing, there is at most one candidate file in each layer. Therefore, at most two files need to be read to find the target value.

[0106] 8. GHStore range query process

[0107] like Figure 7 As shown in the figure, when a user requests to obtain data information within a certain range, the system's iterator will be called to perform a range query operation.

[0108] First, call the seek() operation to search the SSTable files of each layer of GHLSM layer by layer, and locate a key in the layer that is greater than or equal to the minimum value of the given range.

[0109] Then we call next() to check whether the key of each subsequent data meets the given range. Finally, we read all the data that meets the requirements into memory, merge and sort them, and return them to the user, completing the request.

[0110] 9. Experimental Data

[0111] We used the db_bench testing tool to conduct comprehensive tests on the system's write, read, and range queries, and also evaluated GHStore's effectiveness in reducing system data volume, lowering write amplification, and minimizing file access. In the experiment, we set the memtable size to 64MB, writing to disk when the size reached 6. Up to 10 threads performed compaction operations in parallel in the background, and used 40GB of benchmark data for updates and queries.

[0112] The experimental results are as follows Figure 8-13 As shown in the figure, in scenarios with frequent updates, the final system data size of GHStore is reduced by 8% to 23% compared to RocksDB, alleviating the problem of data redundancy; write amplification is reduced by 5% to 21% compared to RocksDB, alleviating the write amplification problem; system performance is also comprehensively improved compared to RocksDB, with write performance improved by 13% to 22%, read performance improved by 20% to 28%, and range query performance improved by 13% to 25%.

[0113] YCSB includes 6 default mixed workloads, each representing a real-world scenario. Figure 14 As shown in the figure, the distribution of operation numbers in all workload scenarios follows the Zipfian distribution. Workload A is a read-write balanced scenario, with a read operation ratio of 50% and an update operation ratio of 50%; Workload B is a read-mostly write-less scenario, with a read operation ratio of 95% and an update operation ratio of 5%; Workload C is a read-only scenario, with a read operation ratio of 100%; Workload D is a read-most-recently-written scenario, with a read operation ratio of 95% and a write operation ratio of 5%; Workload E is a scan scenario, with a range query operation ratio of 95% and a write operation ratio of 5%; Workload F is a modification scenario, with a read operation ratio of 50% and a read-modify-write operation ratio of 50%.

[0114] In the experiment, 40GB of randomly generated key-value pairs (KVs) from a Zipfian distribution, with 1KB values, were loaded into the system. Then, workloads AF were executed with 2 million operations to evaluate the performance of RocksDB and GHStore. The results show that because the load phase randomly inserts 40GB of data and does not involve any updates, effectively performing an initial backup, RocksDB achieves slightly higher performance. However, GHStore outperforms RocksDB in all workload scenarios: workloada, a read-write balance (50% reads + 50% updates), saw a 35.45% improvement; workloadb, a read-heavy, write-light workload (95% reads + 5% updates), saw a 37.05% improvement; workloadc, a read-only workload, saw a 30% improvement; workloadd, a read-only workload (95% reads + 5% inserts), saw a 28.08% improvement; workloade, a scan workload (95% scans + 5% inserts), saw a 27.85% improvement; and workloadf, a modification workload (50% reads + 50% modifications), saw a 28.19% improvement. Overall, GHStore achieves significant performance improvements in all scenarios.

[0115] The above embodiments are only used to illustrate the technical solutions of the present invention rather than to limit the same. Those skilled in the art may modify or make equivalent substitutions for the technical solutions of the present invention without departing from the spirit and scope of the present invention. The scope of protection of the present invention shall be based on the claims.

Claims

1. A globally optimized key-value storage method, comprising the following steps: 1) Write the key-value pair to the L0 layer of the data storage structure GHLSM, and insert a new record into the core data structure GHmap or update the original record. The data storage structure GHLSM has N layers, including P record layers L in memory. p , QP are located in the recording layer L of the disk q and NQ non-recording layers L on the disk t , 0≤p≤P-1, P≤q≤NQ-1, NQ≤t≤N-1, Q is the recording layer L p With recording layer L q The total number of,the core data structure GHmap uses a hash table for storage, the key of the hash table corresponds to the key of the key-value pair, and the value corresponds to the key-value pair in the layer where the data storage structure GHLSM is located; 2) When the capacity of the L0 layer reaches the threshold, the key-value pair data structure is converted to non-writable, and the L0 layer is marked as the L1 layer. The relevant records in the core data structure GHmap are updated, and a new data structure is generated to construct the record layer L0; 3) When L j When the layer capacity reaches the threshold, based on the core data structure GHmap, the L j Is the key-value pair in the layer the latest key-value pair, where 1≤j≤P-1: If so, write L j+1 layer and update the core data structure GHmap; if not, discard it; 4) When L i When the capacity of the layer exceeds the corresponding threshold, L i Layer and L i+1 Some key-value pairs in the layer are read into memory as pending key-value pairs for merge sorting. Then, the latest version of the key-value pairs is calculated by combining the core data structure GHmap. Where P≤i≤N-2, the latest version of the key-value pairs is calculated using the following strategy: When L i Layer and L i+1 Layers belong to the recording layer L q When , request the core data structure GHmap to obtain the layer where the latest version of the key of the merged sorted data is located: if it is the layer where the merged sorted data is located, then get the latest version of the key-value pair; When L i Layer and L i+1 The layers all belong to the non-recording layer L t When , request the core data structure GHmap to obtain the relevant records of the keys of the merged sorted data: if there is no relevant record, get the latest version of the key-value pair; 5) Write the latest version key-value pair to L i+1 layer and delete the key-value pairs to be processed.

2. The method according to claim 1, wherein The data structure of the data storage structure GHLSM includes: LSM-Tree; record layer L p The data organization methods in include: using skip lists.

3. The method according to claim 1, wherein The core data structure GHmap locates the layer where the key-value pair is located through the following strategy: 1) Use the first hash function Hash1 of GHmap to calculate the subtable number corresponding to the key; 2) Use GHmap's second hash function Hash2 and the subtable number where the key is located to calculate the record of the key in GHmap; 3) Locate the layer where the new key-value pair is located based on the record.

4. The method according to claim 1, wherein Recording layer L q Non-recording layer L t The formats for storing key-value pairs include: SSTable files.

5. The method according to claim 4, wherein Select the key-value pairs to be processed by following the steps below: 1) Calculate L i The score of each SSTable file in the layer, and select the SSTable file with the highest score and the adjacent files of the SSTable file with the highest score as L i SSTable files to be processed in the layer; 2) In L i+1 Select L in the layer i There are overlapping SSTable files in the layer to be processed, as L i+1 SSTable files to be processed in the layer; 3) Combined with L i The SSTable files to be processed in the layer and the L i+1 The SSTable files to be processed in the layer are obtained, and the SSTable file set A of the key-value pairs to be processed is obtained = {s1, s2, ..., s n }, where s is the SSTable file.

6. The method according to claim 5, wherein Write the latest version of the key-value pair to L using the following steps i+1 layer and delete the pending key-value pairs: 1) Generate a new SSTable file set B = {s1 ′ ,s2 ′ ,…,s ′ m }, where s ′ For the new SSTable file; 2) Save the latest version key-value pairs in order to the new SSTable file; 3) Delete L i Layer and L i+1 The SSTable file set A in the layer and the new SSTable file set B are added to L i+1 Layer.

7. The method according to claim 4, wherein Perform a point query of key-value pairs by following the steps below: 1) Use GHmap to locate the layer where the target key-value pair is located; 2) When the target key-value pair is located at the record layer L p When , use binary search to obtain the target key-value pair; 3) When the target key-value pair is located in L P When the layer is reached, the SSTable file is searched sequentially and the Bloom filter is used to predict L p Whether the target value exists in each SSTable file in the layer: If it is judged to exist and the Bloom filter has not made a misjudgment, the SSTable file is searched and the target key-value pair is read from the corresponding SSTable file; 4) When the target key-value pair is located at the record layer L q and not located in L P When searching for a layer, use binary search to obtain the target key-value pair; 5) When the target key-value pair is located in the non-record layer L t When the non-recording layer L is searched layer by layer, t , find the SSTable file containing the target value, and obtain the target key-value pair.

8. The method according to claim 4, wherein Perform a range query on a key-value pair by following these steps: 1) Call the seek() operation to search the SSTable files of each layer of the data storage structure GHLSM layer by layer, and locate a key in the layer that is greater than or equal to the minimum value of the given range; 2) Call next() to determine whether the key of each subsequent key-value pair meets the given range; 3) All key-value pairs that meet the requirements are read into memory, merged and sorted, and then returned to the user.

9. An electronic device comprising a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to perform the method according to any one of claims 1 to 8.

Images