Data access method, storage system, computer program product, and storage medium
By optimizing the data flow mechanism and data structure of the multi-level storage system, the write blocking problem caused by the untimely release of NVM storage space was solved, thus improving the system's read and write performance.
Patent Information
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- Filing Date
- 2025-02-26
- Publication Date
- 2026-03-05
AI Technical Summary
In the prior art, the storage space of non-volatile memory (NVM) is not released in a timely manner, which can cause the system to be blocked when the write traffic is large, thus affecting read and write performance.
A multi-level storage system is adopted, which releases storage space in a timely manner through the data flow mechanism from the first storage layer (DRAM) to the second storage layer (NVM), and splits the data into multiple third tables for persistent storage. Data access is optimized by using data structures such as skip lists and B+ trees.
It alleviates issues such as write stoppages, reduces system latency, and improves read and write performance.
Smart Images

Figure CN2025079209_05032026_PF_FP_ABST
Abstract
Description
Data access methods, storage systems, computer program products and storage media
[0001] This application claims priority to Chinese Patent Application No. 202411218016.X, filed on August 29, 2024, entitled “Data Access Method, Storage System, Computer Program Product and Storage Medium”, the entire contents of which are incorporated herein by reference. Technical Field
[0002] This application relates to the field of storage technology, and in particular to a data access method, storage system, computer program product, and storage medium. Background Technology
[0003] Log structured merge tree (LSM tree) is a data structure that stores data based on an in-memory table (MemTable) and a sorted string table (SSTable) in a block device.
[0004] Taking a storage system using an LSM tree as an example, related technologies typically employ non-volatile memory (NVM) to improve the read and write performance of the storage system. For instance, the storage system first stores the data of a write request in the form of key-value pairs (KV) in a MemTable. When the MemTable is full, the data in the MemTable is dumped to the NVM. When the NVM is full, the data in the NVM is dumped to the SSTable.
[0005] However, due to the large capacity of NVM, it takes a long time for the storage system to dump data from NVM to SSTable, resulting in untimely release of NVM storage space. When the write traffic of the storage system is high, it is unable to dump data from MemTable to NVM in a timely manner, thereby blocking the system's normal writing to MemTable, increasing system latency, and affecting the overall read and write performance of the system. Summary of the Invention
[0006] This application provides a data access method, storage system, computer program product, and storage medium, which can alleviate problems such as write stoppage in storage systems, reduce system latency, and improve system read and write performance.
[0007] Firstly, this application provides a data access method, including:
[0008] The received data is stored in the first table of the first storage layer in the storage system. When the size of the first table reaches the first threshold, the first table is stored in the second table of the second storage layer in the storage system.
[0009] When the size of the second table reaches the second threshold, at least one third table is split from the second table. When the size of the third table reaches the third threshold, the data of at least one third table is recorded in the fourth table. The fourth table records multiple fifth tables.
[0010] Persist at least one of the multiple fifth tables.
[0011] The first storage layer is, for example, DRAM. It should be understood that DRAM is a temporary storage medium usable by an operating system or other running programs, and is therefore a volatile storage medium. The second storage layer is a non-volatile storage layer, for example, using a skip list to store key-value pairs from the first storage layer. The second storage layer is, for example, NVM, which has byte-addressable access characteristics. Persistently storing the fifth table refers to storing the fifth table to a persistent storage device, such as a solid-state drive (SSD), a hard disk drive (HDD), or a disk array consisting of multiple disks. Furthermore, the table involved in this application can be a skip list or a data table based on a B+ tree; this application does not limit the specific type of table.
[0012] In the above method, for a storage system employing multi-level storage, this application provides a fine-grained data flow mechanism. Schematic, after storing received data into a first table in a first storage layer, when the size of the first table reaches a first threshold, the first table is stored into a second table in a second storage layer, realizing data flow from the first storage layer to the second storage layer. Then, when the size of the second table reaches a second threshold, at least one third table with a size reaching a third threshold is split from the second table, and the data in these third tables is recorded into a fourth table. The fourth table records multiple fifth tables. Based on this, the storage system can persistently store these fifth tables at the fifth table level, realizing fine-grained data flow from the second storage layer to the persistent storage device. With granular flow, the storage system can not only release storage space in the second storage layer in a timely manner, without waiting for all data in the second table to be persistently dumped before creating a new table in the second storage layer to receive data from the first storage layer, thus reducing the blocking of normal writes to the first storage layer, but also, since the storage system records the third table split from the second table to the fourth table and dumps it at the fifth table as a granularity, it can ensure that the system can still access the fifth table in the fourth table that has not yet been dumped while dumping part of the fifth table, thereby improving the system's read performance. It can be seen that the above method, while ensuring that the system obtains the benefits brought by the non-volatile second storage layer, greatly reduces problems such as write stoppage, reduces the long-tail latency of the system, and improves the system's read and write performance.
[0013] In some embodiments, splitting at least one third table from the second table includes: dividing the second table into multiple regions; when the size of the second table reaches a second threshold, calculating the data size of each region; and splitting the regions whose data size reaches a third threshold from the second table to form a third table.
[0014] Using the above method, regions in the second table whose data size reaches the third threshold are designated as regions to be split. These regions are then split from the second table to form the third table. In other words, regions that meet the criteria are promptly split off based on data size, thereby freeing up storage space in the second table.
[0015] In some embodiments, the second table is a skip list. Dividing the second table into multiple regions includes using the node with the highest index level in the second table as the boundary point for region division. It should be understood that a skip list is a data structure based on probability balance. This application utilizes this probability balance characteristic to divide the second table into multiple consecutive regions by setting the node with the highest index level as the boundary node for region division. By setting the height of the highest index level in the second table, when the number of nodes in the second table is sufficiently large, the number of nodes in each region will approach an expected value. That is, by controlling the height of the highest index level in the second table, the size of the region division can be controlled, and the region division can be automatically performed according to a preset size without changing the skip list structure.
[0016] In some embodiments, splitting regions whose data size reaches a third threshold from the second table to form a third table includes:
[0017] Multiple regions whose data size reaches the third threshold are split from the second table according to their access frequency, forming multiple third tables.
[0018] In this way, when splitting the third table from the second table, the access frequency of the data in the second table is taken into account. Data with lower access frequency is split out first, while data with higher access frequency is kept in the second table for as long as possible, thereby improving the system's read performance.
[0019] In some embodiments, the second table is a skip list, and regions whose data size reaches a third threshold are split from the second table to form a third table, including:
[0020] Based on the position of the target region in the second table that has reached the third threshold in terms of data size, a target head node is created to point to the target boundary node. The pointers of the nodes associated with the target region are adjusted to split the target region out of the second table and form the third table corresponding to the target region.
[0021] It should be understood that the target region to be split can be located at the head, middle or tail of the second table. The splitting method varies depending on the location, but the common point is that the skip list is split by creating a new head node and adjusting the pointer of the specified node. This method can complete the skip list split with less overhead and save computing resources.
[0022] In some embodiments, based on the position of the target region in the second table where the data size reaches a third threshold, a target header node is created to point to the target region, the pointers of the nodes associated with the target region are adjusted, and the target region is split from the second table to form a third table corresponding to the target region, including any of the following:
[0023] If the target region is located at the head of the second table, create a first head node pointing to the first boundary node, add a first jump pointer to the predecessor node of the first boundary node pointing to the first boundary node, perform a break-chain operation on the target region, configure the first head node as the head node of the second table, and obtain the third table corresponding to the target region. The first boundary node refers to the next boundary node in the second table adjacent to the target region; or...
[0024] If the target region is located in the middle of the second table, create a second head node to point to the second boundary node. Add a second jump pointer to the last node of each level in the target region to point to the third boundary node. Perform a break-chain operation on the target region, and set the pointer of the predecessor node of the second boundary node in the second table to the third boundary node. This yields the third table corresponding to the target region. The second boundary node refers to the boundary node of the target region, and the third boundary node refers to the next boundary node in the second table adjacent to the target region. Alternatively,
[0025] If the target region is located at the end of the second table, create a third head node to point to the fourth boundary node, perform a break-chain operation on the target region, and set the pointer of the predecessor node of the fourth boundary node in the second table to null, thus obtaining the third table corresponding to the target region. The fourth boundary node refers to the boundary node of the target region.
[0026] In some embodiments, recording data from at least one third table to a fourth table includes:
[0027] Determine whether the data range recorded in the third table overlaps with the data already recorded in the fifth table (as recorded in the fourth table);
[0028] If there is overlap, merge the overlapping portion with the contents of the overlapping fifth table, and record the non-overlapping portion as the fifth table in the fourth table; or,
[0029] If there is no overlap, the third table will be recorded as the fifth table in the fourth table.
[0030] In some embodiments, the fourth table includes an index to each fifth table, where the key of the index is the smallest key in the fifth table, and the value of the index is a pointer to the fifth table corresponding to the index.
[0031] Using the above method, the multiple split third tables were merged to obtain the fourth table. Since the index key in the fourth table is the smallest key of the fifth table, and the index value is a pointer to the fifth table, the storage system can use the index to quickly query the records in the fourth table for each fifth table, thereby improving the system's read performance.
[0032] In some embodiments, the method includes:
[0033] Receive a read request, and query the first table based on the read request;
[0034] If the data requested by the read request is not found in the first table, query the second table;
[0035] If no data is found in the second table, query at least one third table that was split from the second table.
[0036] If no data is found in at least one of the third tables, query the fourth table;
[0037] If no data is found in the fourth table, query the persistent storage device.
[0038] In some embodiments, if no data is found in at least one third table, a fourth table is queried, including:
[0039] If no data is found in at least one of the third tables, the fifth table is queried based on the index of each fifth table in the fourth table. The key of the index is the smallest key in the fifth table, and the value of the index is a pointer to the fifth table corresponding to the index.
[0040] As can be seen, because this application optimizes the storage mechanism of multiple storage layers in the storage system, it can alleviate problems such as write stoppage in the storage system. Therefore, when the storage system receives a read request, it can search layer by layer from the first storage layer, the second storage layer, and the persistent storage device, thereby improving the system's read performance.
[0041] Secondly, this application provides a storage system including at least one functional module for implementing the data access method provided by the first aspect or any possible implementation thereof.
[0042] Thirdly, this application provides a computer program product that, when run on a storage system, causes the storage system to implement the data access method provided by the first aspect or any possible implementation thereof. The computer program product can be a software installation package; when the aforementioned method needs to be implemented, the computer program product can be downloaded and executed on the storage system.
[0043] Fourthly, this application provides a computer-readable storage medium for storing at least one piece of program code, which implements the data access method provided by the first aspect or any possible implementation thereof. This storage medium includes, but is not limited to, volatile memory, such as random access memory, and non-volatile memory, such as flash memory, hard disk drive (HDD), and solid-state drive (SSD). Attached Figure Description
[0044] Figure 1 is a schematic diagram of an LSM tree structure;
[0045] Figure 2 is a schematic diagram of a skip list;
[0046] Figure 3 is a schematic diagram of an implementation environment provided in an embodiment of this application;
[0047] Figure 4 is a schematic diagram of the structure of a computing device provided in an embodiment of this application;
[0048] Figure 5 is a schematic diagram of the storage mechanism of a storage system provided in an embodiment of this application;
[0049] Figure 6 is a flowchart of a data access method provided in an embodiment of this application;
[0050] Figure 7 is a schematic diagram of a skip list head splitting provided in an embodiment of this application;
[0051] Figure 8 is a schematic diagram of a partial split in a skip table provided in an embodiment of this application;
[0052] Figure 9 is a schematic diagram of a jump table tail splitting according to an embodiment of this application;
[0053] Figure 10 is a schematic diagram of the access popularity of a region to be split according to an embodiment of this application;
[0054] Figure 11 is a schematic diagram of multi-table merging provided in an embodiment of this application;
[0055] Figure 12 is a flowchart of a data writing process provided in an embodiment of this application;
[0056] Figure 13 is a flowchart of another data access method provided in an embodiment of this application;
[0057] Figure 14 is a flowchart of a data query provided in an embodiment of this application;
[0058] Figure 15 is a schematic diagram of a read / write performance test provided in this application;
[0059] Figure 16 is a schematic diagram of the architecture of a storage system provided in an embodiment of this application. Detailed Implementation
[0060] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be further described in detail below with reference to the accompanying drawings. It should be noted that the information (including but not limited to user equipment information, user personal information, etc.), data (including but not limited to data used for analysis, stored data, displayed data, etc.), and signals involved in this application are all authorized by the user or fully authorized by all parties, and the collection, use, and processing of related data must comply with the relevant laws, regulations, and standards of the relevant countries and regions. For example, skip lists, write requests, read requests, etc., involved in this application are all obtained under fully authorized conditions.
[0061] To facilitate understanding, the key terms and concepts involved in this application will be explained below.
[0062] Dynamic random access memory (DRAM) is typically used as main memory and is an internal memory that directly exchanges data with the central processing unit (CPU). Because data stored in DRAM disappears when power is turned off, DRAM is a type of volatile memory.
[0063] Non-volatile memory (NVM) is a type of memory that stores data that is not lost when power is off; it is a byte-addressable persistent memory. Compared to DRAM, NVM has advantages such as lower static power consumption, higher storage density, and data persistence. Compared to block devices, NVM has byte-addressable characteristics and higher read / write performance.
[0064] A log-structured merge tree (LSM tree) is a data structure that stores data using an in-memory table (MemTable) and a sorted string table (SSTable) on a block device. LSM trees convert random writes into sequential writes, resulting in extremely high write performance. They also use logs to ensure data persistence, making them highly suitable for write-intensive applications and capable of efficiently handling large-scale data. For example, the core data structures of NoSQL databases such as LevelDB, RocksDB, HBase, and Cassandra all employ LSM trees.
[0065] Taking LevelDB as an example, refer to Figure 1, which is a schematic diagram of an LSM tree structure. As shown in Figure 1, the LSM tree adopts a hierarchical structure, including the MemTable in memory DRAM and the SSTable in block devices (such as SSDs or HDDs). Illustratively, in a data insertion scenario (or data writing scenario), the storage system receives a user's write request, extracts key-value pairs from the write request, records this data write operation in the block device's log, and then stores the key-value pairs in the DRAM MemTable. When the MemTable is full, a new MemTable is created to receive write requests, transforming the original MemTable into an immutable MemTable (e.g., by setting a flag or status variable to mark the MemTable as immutable) and waiting for a background thread to initiate a dump process, flushing the data in the immutable MemTable to the block device. In the block device, the LSM tree adopts a multi-level structure (e.g., L0-L in Figure 1). n The data is stored using a layer (where n is an integer). The smaller the layer, the newer the data. The data is merged and sorted through a compaction operation and then written to the next layer. In this way, the data is gradually organized into a more orderly manner while reducing data redundancy.
[0066] Write pauses, also known as write stalls or write delays, refer to the situation where, when the write traffic of the storage system is high, the data dumping and merging process of the LSM tree blocks the normal writing to the MemTable, thereby increasing system latency and affecting the overall read and write bandwidth of the system.
[0067] A skip list is a data structure based on probability balance. The average time complexity of insertion or query operations in a skip list is O(logN), where N is the total number of nodes in the skip list. Referring to Figure 2, which illustrates the structure of a skip list, the skip list is built in layers. The bottom layer is an ordered linked list. Whenever a new key-value pair is inserted, a node is added to the skip list. For any given node, its height is at least 1, and its height is generated by probability. If the probability of adding a layer is 'a', then the probability of a node having a height of H is also 'a'. H-1Generally, nodes at higher levels have a lower probability of being generated, resulting in fewer high-level nodes and more other nodes between adjacent high-level nodes. Furthermore, each node contains both a pointer to the next node and multiple pointers to subsequent nodes (such as the next-level index node). This avoids unnecessary nodes during the search, insertion, and deletion processes, thus improving efficiency. Illustratively, during a query, the skip list searches downwards from the top level, using its upper-level linked list structure as an index for key queries, accelerating the query process and avoiding unnecessary search steps. For example, in Figure 2, using key=35 as an example, the search starts from the top level and continues downwards until a key greater than or equal to 35 is found, retrieving the value corresponding to key=35. The query process is shown by the dotted lines in the figure.
[0068] B+ trees (B-Plus trees) are self-balancing multi-way search trees widely used in database indexing. A key characteristic of B+ trees is that each node can store multiple key values and pointers to its child nodes, forming a multi-level structure. During queries, the time complexity is optimized through level-by-level search and intra-page binary search.
[0069] A sorted string table (SSTable) is an ordered key-value pair storage structure commonly used in storage systems employing LSM trees. In block devices, each SSTable contains a series of blocks (typically 64KB in size, configurable according to business needs). At the end of the SSTable are block indexes used to locate the blocks. These indexes are loaded into memory when the SSTable is opened. During a lookup, a binary search is performed from the in-memory indexes to find the block, and then the corresponding block is retrieved via a single disk lookup.
[0070] The application scenarios and implementation environment of this application are described below.
[0071] This application applies to scenarios where data is stored using an LSM tree data structure. It provides a multi-level memory-based LSM tree storage mechanism that effectively mitigates write-stop problems in storage systems, reduces system latency, and improves system read / write performance. The implementation environment of this application will be described below with reference to Figure 3.
[0072] Figure 3 is a schematic diagram of an implementation environment provided in an embodiment of this application. As shown in Figure 3, the implementation environment includes a storage system 300, which includes a processing layer 301 and multiple storage layers 302.
[0073] In this embodiment, the storage system 300 is a key-value storage system. The processing layer 301 handles data read / write requests for the storage system 300, providing data access functionality. For example, it receives a user's write request, extracts key-value pairs from the write request, and stores the key-value pairs in multiple storage layers 302. Alternatively, it receives a user's read request, extracts the target key from the read request, performs data queries in multiple storage layers 302 based on the target key, and returns the queried value to the user. In some embodiments, the processing layer 301 is also used to coordinate and manage the storage system 300. For example, the processing layer 301 uses cache management to determine which storage layer among the multiple storage layers 302 to store data, thereby improving data access speed; and manages the data transfer and merging processes between different storage layers, etc. Furthermore, the processing layer 301 is also used to maintain data consistency between different storage layers and to communicate with external devices, etc. This application does not limit the functions of the processing layer 301.
[0074] Multiple storage layers 302 employ an LSM tree storage architecture for data storage. Schematic, the multiple storage layers 302 include a first storage layer and a second storage layer. The first storage layer is a volatile storage layer; for example, it uses a skip list to store key-value pairs in write requests. The first storage layer is, for example, DRAM. It should be understood that DRAM is a temporary storage medium that can be used by an operating system or other running programs, and is therefore a volatile storage medium. The second storage layer is a non-volatile storage layer; for example, it uses a skip list to store key-value pairs from the first storage layer. The second storage layer is, for example, NVM, which has byte-addressable access characteristics. In some embodiments, the storage system 300 can access persistent storage devices, such as SSDs, HDDs, or disk arrays composed of multiple disks, etc., which are not limited in this application. In some scenarios, the persistent storage device can also be abstracted as a persistent storage layer of the storage system 300, used to receive data from the multiple storage layers 302. For example, this persistent storage layer uses SSTables to store key-value pairs from the second storage layer. It should be noted that the above-described method of dividing multiple storage layers 302 is only one optional implementation. In some embodiments, more storage layers can be deployed to meet different business needs.
[0075] In some embodiments, the storage system 300 is deployed on servers, server clusters consisting of multiple physical servers, or cloud server clusters providing basic cloud computing services such as cloud storage, cloud services, cloud databases, cloud computing, cloud functions, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDNs), big data, and artificial intelligence platforms. This application does not limit this to any particular type. Taking a cloud server as an example, a cloud server is also called a cloud platform (short for cloud computing platform), which refers to a service based on hardware and software resources that provides computing, network, and storage capabilities. Through the network "cloud," massive amounts of data are processed and analyzed remotely before being returned to the user, featuring large scale, distributed architecture, virtualization, high availability, scalability, on-demand service, and security. Cloud platforms can achieve rapid deployment and release of configurable computing resources with relatively low management costs or low interaction complexity between users and service providers. Taking the storage system 300 deployed in a server cluster as an example, the storage system 300 can adopt a storage-compute separation architecture. Schematic, the storage system 300 includes compute nodes and storage nodes, wherein the compute nodes are used to implement the functions of the aforementioned processing layer 301, and the storage nodes are used to implement the functions of the aforementioned multiple storage layers 302.
[0076] Furthermore, the networks mentioned above include, but are not limited to, data center networks, storage area networks (SANs), local area networks (LANs), metropolitan area networks (MANs), wide area networks (WANs), mobile, wired or wireless networks, private networks, or virtual private networks (VPNs). In some implementations, technologies and / or formats, including Hypertext Markup Language (HTML) and Extensible Markup Language (XML), are used to represent data exchanged over the network. Additionally, conventional encryption technologies such as Secure Sockets Layer (SSL), Transport Layer Security (TLS), Virtual Private Networks (VPNs), and Internet Protocol Security (IPsec) can be used to encrypt all or part of the links. In other embodiments, custom and / or dedicated data communication technologies can be used to replace or supplement the aforementioned data communication technologies.
[0077] The hardware deployment environment of the storage system 300 is described below.
[0078] This application provides a computing device for implementing the data access function of a storage system 300. Schematically, referring to FIG4, FIG4 is a structural schematic diagram of a computing device provided in an embodiment of this application. As shown in FIG4, the computing device 400 includes a memory 401, a processor 402, a communication interface 403, and a bus 404. The memory 401, processor 402, and communication interface 403 are interconnected via the bus 404.
[0079] Memory 401 refers to a device for storing data, which may be a read-only memory (ROM) or other types of static storage devices capable of storing static information and instructions, random access memory (RAM) or other types of dynamic storage devices capable of storing information and instructions, or electrically erasable programmable read-only memory (EEPROM), compact disc read-only memory (CD-ROM) or other optical disc storage, optical disc storage (including compressed optical discs, laser discs, optical discs, digital universal optical discs, Blu-ray discs, etc.), magnetic disk storage media or other magnetic storage devices, or any other medium capable of carrying or storing desired program code having an instruction or data structure form and accessible by a computer, but not limited thereto. Illustratively, memory 401 is used to store at least one piece of program code. When the program code stored in memory 401 is executed by processor 402, processor 402 is used to perform the data access method provided in the following method embodiments. In some embodiments, memory 401 is also used to provide storage space for the storage layer of storage system 300.
[0080] Processor 402 may be a network processor (NP), a central processing unit (CPU), a graphics processing unit (GPU), an application-specific integrated circuit (ASIC), or an integrated circuit used to control the execution of the program in this application. Processor 402 may be a single-core (single-CPU) processor or a multi-core (multi-CPU) processor. The number of processors 402 may be one or more.
[0081] The communication interface 403 uses a transceiver module, such as a transceiver, to enable communication between the computing device 400 and other devices or communication networks. For example, data can be acquired through the communication interface 403.
[0082] The memory 401 and the processor 402 can be set separately or integrated together.
[0083] Bus 404 may include a pathway for transmitting information between various components of computing device 400 (e.g., memory 401, processor 402, communication interface 403).
[0084] It should be noted that the computing device 400 shown in Figure 4 above is only a hardware structure diagram provided by this application that can be configured to implement the data access function of the storage system 300 described above. In some embodiments, the computing device 400 may also include other components to achieve more functions, and this application does not limit this.
[0085] The following describes the method for data access based on storage system 300.
[0086] As described above, the storage system provided in this application includes multiple storage layers. Based on this, this application optimizes the storage mechanism of these multiple storage layers to alleviate write stoppages and improve system read / write performance. The storage mechanism of the storage system provided in this application will be described below with reference to Figure 5. Figure 5 is a schematic diagram of the storage mechanism of a storage system provided in an embodiment of this application. As shown in Figure 5, the description will focus on a storage system with multiple storage layers, including a first storage layer (DRAM) and a second storage layer (NVM).
[0087] Taking the use of skip lists to store data in the first storage layer as an example, in some scenarios, the skip list in the first storage layer is also called a memory table (MemTable), and the first storage layer is also called a DRAM buffer. Illustratively, when the storage system receives a write request from a user (e.g., an insert operation to insert new key-value pairs), it extracts the key-value pairs from the write request, writes the key-value pairs to the log in the persistent storage device, and then writes the key-value pairs to the MemTable in the first storage layer. When the MemTable is full (for example, when the amount of data in the MemTable reaches a threshold, or when the size of the MemTable reaches a threshold), the MemTable is transformed into an immutable MemTable (e.g., by setting a flag or status variable to mark the MemTable as immutable), and it is quickly dumped to the skip list in the second storage layer. It should be understood that, in this application, dumping one skip list to another means transferring the data stored in one skip list to another. Furthermore, after the processing layer transforms the MemTable into an immutable MemTable, it creates a new MemTable to continue receiving key-value pairs from other write requests. It should be noted that this application does not limit the number of MemTables in the first storage layer. When the first storage layer includes multiple MemTables, each MemTable can concurrently receive data from write requests, and each MemTable can be managed and processed independently.
[0088] Taking the use of skip lists to store data in the second storage layer as an example, in some scenarios, the skip lists in the second storage layer include at least one of a ReceiveTable and a CompactTable. Illustratively, after the storage system converts the MemTable in the first storage layer into an immutable MemTable, it dumps this immutable MemTable to the ReceiveTable in the second storage layer. That is, the ReceiveTable in the second storage layer acts as an extended cache for the first storage layer (i.e., DRAM memory) to handle the data in the first storage layer. When the ReceiveTable is full (full, for example, when the amount of data in the ReceiveTable reaches a threshold, or when the size of the ReceiveTable reaches a threshold), the storage system initiates a skip list splitting process, splitting multiple skip lists from the ReceiveTable and temporarily storing these split skip lists in a cache queue (for example, controlling the number of skip lists in the cache queue to a preset number, such as 3). Since the capacity of the skip lists split from the ReceiveTable is smaller than the capacity of the ReceiveTable, this process can also be understood as splitting multiple smaller skip lists (SplitTable) from the large ReceiveTable. Next, leveraging the ordered nature of the data in the skip lists, the multiple split skip lists can be merged to obtain a compressed table, CompactTable. For example, an accelerated index can be built based on the multiple smaller skip lists, using a skip list structure. The key of the accelerated index is configured as the smallest key of the smaller skip lists, and the value of the accelerated index is configured as a pointer to the smaller skip lists. In some embodiments, B+ trees, trie trees, etc., can also be used to construct the accelerated index; this application does not limit this approach. In this way, the storage system can utilize the accelerated index to query the compressed table, improving the system's read performance. After obtaining CompactTable, the storage system initiates a dump process to remove the smaller skip lists from CompactTable and persistently store them. In other words, the CompactTable in the second storage layer acts as an accelerated cache for persistent storage, handling the data that is being persistently dumped. This enables fine-grained data flow from the second storage layer to the persistent storage device. It should be understood that because fine-grained data flow from the second storage layer to the persistent storage device is achieved, the system can release the storage space of the second storage layer in a timely manner without waiting for all the data in the ReceiveTable to be persistently stored before creating a new ReceiveTable. This reduces the blocking of normal writes to the MemTable. While ensuring that the system obtains the benefits brought by non-volatile memory (NVM), it greatly alleviates problems such as write stoppages and reduces the long-tail latency of the system.
[0089] Additionally, the storage system can access persistent storage devices. Illustratively, taking the persistent storage device using sorted string tables (SSTables) to store data as an example, the SSTables are divided into multiple levels according to their age. Each level's SSTables are ordered and their key ranges do not overlap. When an SSTable in a certain level is full, the storage system initiates a background merge thread to select and merge SSTables in that level. For example, when the number of SSTables in a certain level reaches a preset threshold (e.g., 10 SSTables), or when the disk space occupied by that level reaches a certain proportion (e.g., 80% of the disk space is occupied by SSTables in that level), a background merge operation is triggered. It should be understood that, based on Figure 1 above, in related technologies, SSTables on block devices can be divided into L0-L0 levels according to their age. n In this application, since CompactTable is deployed in the second storage layer as an accelerated cache for persistent storage, CompactTable in the second storage layer can be understood as the first layer of SSTable, i.e., layer L0, with the rest being layer L1-L2. n The layer is deployed on a persistent storage device.
[0090] Therefore, the storage system provided in this application optimizes the storage mechanism of the second storage layer and the data transfer mechanism from the second storage layer to the persistent storage device. This allows the system to release the storage space of the second storage layer in a timely manner, thereby reducing the blocking of normal writes to the memory table. While ensuring the system obtains the benefits of non-volatile memory, it greatly alleviates write stop problems, reduces long-tail latency, and improves system read and write performance. It should be noted that Figure 5 illustrates the skip list as an example. The above storage mechanism is similarly applicable to B+ tree-based data tables or other types of data tables. For example, taking a B+ tree-based data table as an example, in the second storage layer, based on the leaf nodes of the data table, the data table is divided into multiple regions. Regions that meet the conditions are split off from the data table to obtain sub-tables, which are then persistently stored.
[0091] The data access method provided in this application will be described below through several method implementation examples.
[0092] Figure 6 is a flowchart of a data access method provided in an embodiment of this application. As shown in Figure 6, the method is applied to a storage system, for example, executed by the processing layer of the storage system. The storage system also includes multiple storage layers, including a volatile first storage layer and a non-volatile second storage layer. Schematically, the method includes the following steps 601 to 605.
[0093] 601. The storage system stores the received data into the first table of the first storage layer.
[0094] In this embodiment, the storage system includes a processing layer for managing multiple storage layers. For example, the processing layer creates multiple threads, each executing the operations described in this application within its respective storage layer. Illustratively, upon receiving a write request, the storage system extracts key-value pairs from the write request and stores them in a first table of the first storage layer. Taking a skip list as an example, the first table stores key-value pairs sequentially according to their keys. The key of the key-value pair in the write request is compared with the keys of already stored key-value pairs in the first table to determine the insertion position of the key-value pair. For example, if the key of the key-value pair in the write request is 'b', and the keys of already stored key-value pairs are 'a', 'c', and 'd', then by comparing the keys, the insertion position of the key-value pair is determined to be after key 'a' and before key 'c'. In some embodiments, the key is also called a keyword, which is not limited in this application.
[0095] In some embodiments, when a write request is received, the storage system checks whether an existing table in the first storage layer is full. If it is not full, the data of the write request is stored in that table, i.e., the first table. If it is full, the system checks whether an immutable table exists in the first storage layer. If it exists, the immutable table is dumped to the second storage layer, the existing table is converted into an immutable table, a new table is created, i.e., the first table, and the data of the write request is stored in the first table. If the table does not exist, the existing table is converted into an immutable table, a new table is created, i.e., the first table, and the data of the write request is stored in the first table. Furthermore, in this application, a table being full is, for example, when the amount of data in the table reaches a threshold, or when the size of the table reaches a threshold; this will not be elaborated further.
[0096] 602. When the size of the first table reaches the first threshold, the storage system stores the first table in the second table of the second storage layer.
[0097] In this embodiment, when the size of the first table reaches a first threshold, the storage system converts the first table into an immutable first table and dumps the immutable first table to a second table in the second storage layer. The first threshold is a preset threshold that can be set according to business needs; this application does not limit its setting. For example, the first threshold could be 4MB. Illustratively, the second table is used to sequentially store key-value pairs according to the key order. The storage system inserts key-value pairs from the first table into the second table. This process is similar to the process of inserting key-value pairs into the first table in step 601, and therefore will not be described again.
[0098] Furthermore, based on the storage mechanism shown in Figure 5 above, taking the skip table in the second storage layer as an example, the skip table includes a receive table. In this step, the second table is also a kind of receive table. That is, the second table serves as an extended cache of the first storage layer to receive the data in the first storage layer, i.e., the data in the first table.
[0099] 603. When the size of the second table reaches the second threshold, the storage system splits at least one third table from the second table, and the size of the third table reaches the third threshold.
[0100] In this application embodiment, the number of third tables can be set according to actual business needs, and this application does not limit this. The second table reaching the second threshold can also be understood as the second table meeting the splitting condition. Both the second and third thresholds are preset thresholds that can be set according to business requirements, and this application does not limit them. For example, the second threshold is 128GB, and the third threshold is 64MB. For any third table, splitting it from the second table means extracting a portion of the data from the second table to form a new table, thereby releasing the storage space occupied by this portion of data in the second table. In other words, a smaller table is formed by separating a portion of the data from the second table, allowing the storage system to continue transferring data from the first storage layer to the second table. It should be understood that since the capacity of the third table split from the second table is smaller than the capacity of the second table, the process of splitting multiple third tables from the second table can also be understood as splitting at least one smaller table from the large second table. In some embodiments, the storage system stores at least one split third table in the cache queue of the second storage layer for subsequent processing, such as merging multiple third tables or persistently storing multiple third tables. The cache queue, as a temporary storage space for the split third table, can be a static queue (such as limiting the number of third tables in the queue to 3) or a dynamic queue. This application does not limit this.
[0101] The following section uses any third table as an example to illustrate how a storage system can split a third table from a second table.
[0102] In this application, the second table is divided into multiple regions. When the size of the second table reaches a second threshold, the data size of each region is calculated, and regions whose data size reaches a third threshold are split from the second table to form a third table. That is, the second table includes multiple regions. The storage system designates regions whose data size meets certain conditions as regions to be split, and splits these regions from the second table to obtain the third table corresponding to each region to be split. The data size can be reflected by counting the number of nodes in each region or by counting the actual amount of data in each region; this application does not limit this approach. In this way, regions that meet certain conditions are promptly split off based on data size, freeing up storage space in the second table.
[0103] In some embodiments, the second table is a skip list, and the aforementioned division of the second table into multiple regions includes using the node with the highest index level in the second table as the boundary point for region division. That is, for any region, the boundary node of that region is the node with the highest index level in the second table. It should be understood that a skip list is a data structure based on probability balance. This application utilizes this probability balance characteristic, dividing the second table into multiple consecutive regions by setting the node with the highest index level as the boundary node. By setting the height of the highest index level in the second table, when the number of nodes in the second table is sufficient, the number of nodes in the region will approach an expected value. In other words, by controlling the height of the highest index level in the second table, the size of the region division can be controlled, and the region division can be automatically performed according to a preset size without changing the skip list structure. For example, if the expected region size is X, then the height of the highest index level... Where 'a' represents the probability of adding each new height layer (or index layer). In some embodiments, the second table records the number of boundary nodes. The storage system can adjust the number of boundary nodes to keep it within a preset range, thereby avoiding situations where there are too many or too few boundary nodes.
[0104] In some embodiments, the second table is divided into multiple regions. When the size of the second table reaches a second threshold, the access frequency of each region is calculated, and regions whose access frequency meets the criteria are split from the second table to form a third table. Illustratively, for any given region, the access frequency can be determined based on the difference between a first timestamp and a second timestamp. The first timestamp refers to the time of the region's most recent update (including insert operations), and the second timestamp refers to the current timestamp. If the difference between the first and second timestamps reaches a fourth threshold, it indicates that the region has existed in the second table for a long time without being accessed, belonging to an "overly inactive" region. Therefore, this region is designated as a region to be split and is removed from the second table. In some embodiments, taking the second table as a skip list as an example, a frequency field, including the first timestamp, is stored in the boundary nodes of the regions. For example, the storage system periodically scans all boundary nodes in the second table. If the difference between the first and second timestamps corresponding to a boundary node reaches the fourth threshold, the region containing that boundary node is determined as a region to be split. In this way, we can avoid having overly cold regions in the second table that remain stagnant in the second table for a long time. By using the access frequency of a region as a criterion, we can promptly split off the overly cold regions and free up storage space in the second table.
[0105] It should be understood that the above are only a few optional methods for splitting the third table from the second table provided by this application, and do not constitute a limitation on this application. For example, the user can also specify which areas to split from the second table.
[0106] The following section continues by using any region to be split as an example to illustrate the process of the storage system splitting this region from the second table. Illustratively, this region is referred to as the target region. Taking the second table as a skip list, the storage system creates a target head node pointing to the target region based on its position in the second table, adjusts the pointers of the nodes associated with the target region, and splits the target region from the second table to obtain the corresponding third table. It should be understood that the target region's position in the second table can be at the head, middle, or tail. The splitting method differs depending on the position, but the common point is that skip list splitting is achieved by creating a new head node and adjusting the pointers of specified nodes. This method can complete skip list splitting with relatively low overhead, saving computational resources.
[0107] Schematic, the storage system can determine the position of the target region in the second table based on the boundary nodes of the target region. For example, if the boundary node of the target region is the head node of the second table, then the target region is located at the head of the second table; if the predecessor pointer of the boundary node of the target region is not null and the successor pointer of the last node in each level of the target region is not null, then the target region is located in the middle of the second table; if the predecessor pointer of the boundary node of the target region is not null and the successor pointer of the last node in each level of the target region is null, then the target region is located at the tail of the second table.
[0108] The following describes the splitting process using examples of target regions in different locations, including the following scenarios:
[0109] Scenario 1: The target area is located at the beginning of the second table.
[0110] In this scenario, the storage system splits the target region from the second table to obtain a third table, including: creating a first head node pointing to a first boundary node, where the first boundary node is the next boundary node in the second table adjacent to the target region; adding a first jump pointer to the predecessor node of the first boundary node to point to the first boundary node; performing a disconnect operation on the target region; configuring the first head node as the head node of the second table; and obtaining the third table corresponding to the target region. The disconnect operation refers to setting the successor pointer of the last node at each level of the target region to null. In some embodiments, after performing the disconnect operation on the target region, the first jump pointer is deleted, or the first jump pointer is set to null. It should be understood that adding a jump pointer to the predecessor node of the first boundary node during the splitting of the target region from the second table ensures that if the system receives a read request before performing the disconnect operation, the first boundary node can be queried through the jump pointer. After performing the disconnect operation, the target region has been split from the second table, and deleting or setting the jump pointer at this point avoids read anomalies.
[0111] Schematic, referring to Figure 7, which is a schematic diagram of a skip list head splitting according to an embodiment of this application. As shown in Figure 7, the target region is located at the head of the second table. The storage system creates a first head node 701 and points the first head node 701 to the next boundary node adjacent to the target region, i.e., the first boundary node 702. Then, a first skip pointer is added to the predecessor node of the first boundary node to point to the first boundary node, that is, a first skip pointer is added to the last node of each layer of the target region to point to the first boundary node. After storing the target region in the cache queue, a chain break operation is performed on the target region, that is, the successor pointer of the last node of each layer of the target region is set to null, thus obtaining the third table corresponding to the split region. In addition, the first head node 701 is configured as the head node of the second table to ensure the structural integrity of the second table, and the first skip pointer is deleted to avoid read anomalies in the system.
[0112] Scenario 2: The target area is located in the middle of the second table.
[0113] In this scenario, the storage system splits the target region from the second table to obtain a third table, including: creating a second head node pointing to a second boundary node, where the second boundary node is the boundary node of the target region; adding a second jump pointer to the last node of each level of the target region to point to a third boundary node, where the third boundary node is the next boundary node in the second table adjacent to the target region; and performing a disconnect operation on the target region, setting the pointer of the predecessor node of the second boundary node in the second table to the third boundary node, thus obtaining the third table corresponding to the target region. The disconnect operation refers to setting the successor pointer of the last node of each level of the target region to null. In some embodiments, after performing the disconnect operation on the target region, the second jump pointer is deleted, or the second jump pointer is set to null. It should be understood that adding a jump pointer to the last node of each level of the target region during the splitting process from the second table ensures that if the system receives a read request before performing the disconnect operation, the third boundary node can be queried through the jump pointer. After performing the disconnect operation, the target region has been split from the second table, and deleting or setting the jump pointer at this point avoids read anomalies.
[0114] Schematic, referring to Figure 8, which is a schematic diagram of a split skip table provided in an embodiment of this application. As shown in Figure 8, the target region is located in the middle of the second table. The storage system creates a second head node 801 and points the second head node 801 to the boundary node of the current target region, that is, the second boundary node 802. Then, a second skip pointer is added to the last node of each layer of the target region to point to the third boundary node, that is, the next boundary node adjacent to the target region. After storing the target region in the cache queue, a chain break operation is performed on the target region, that is, the successor pointer of the last node of each layer of the target region is set to null, thus obtaining the third table corresponding to the split region. In addition, the pointer of the predecessor node of the second boundary node 802 in the second table is pointed to the third boundary node, that is, the pointer pointing to the boundary node of the target region is pointed to the next boundary node of the adjacent region to ensure the structural integrity of the second table. The second skip pointer is deleted to avoid read anomalies in the system.
[0115] Scenario 3: The target area is located at the end of the second table.
[0116] In this scenario, the storage system splits the target region from the second table to obtain a third table. This involves: creating a third head node to point to a fourth boundary node, where the fourth boundary node is the boundary node of the target region; and performing a break-chain operation on the target region, setting the pointer of the predecessor node of the fourth boundary node in the second table to null, thus obtaining the third table corresponding to the target region. Specifically, the break-chain operation involves setting the successor pointer of the last node in each layer of the target region to null.
[0117] Schematic, referring to Figure 9, which is a schematic diagram of a skip list tail splitting according to an embodiment of this application. As shown in Figure 9, the target region is located at the tail of the second table. The storage system creates a third head node 901 and points the third head node 901 to the boundary node of the current target region, that is, the fourth boundary node 902. Then, after storing the target region in the cache queue, a chain break operation is performed on the target region, that is, the successor pointer of the last node of each layer of the target region is set to null, thus obtaining the third table corresponding to the split region.
[0118] Based on the above, taking any target region as an example, the process of the storage system splitting the target region from the second table is described. In some embodiments, the storage system can split multiple regions whose data size reaches a third threshold from the second table according to their access frequency, forming multiple third tables. For example, the access frequency of each region to be split is sorted, and each region to be split is split from the second table in ascending order of access frequency. In this way, when splitting the third table from the second table, the access frequency of the data in the second table is considered, prioritizing the splitting of data with lower access frequency, and retaining data with higher access frequency in the second table for as long as possible, thereby improving the system's read performance.
[0119] Schematic illustration: For any region to be split, the access popularity of that region is determined based on its access frequency and creation time. For example, the ratio of access frequency to creation time can be used as the access popularity of that region. Schematic illustration: The storage system maintains a metadata array for each region to be split in the second storage layer. This metadata array records the access frequency and creation time of each region to be split. Access frequency refers to the number of times the storage system dumps data to the region to be split, that is, the number of times data from the first storage layer is inserted into the region to be split. The creation time of the region to be split is reflected by the number of times data is dumped from the first table in the first storage layer to the second table in the second storage layer. For example, the creation time is recorded as 1 when the storage system dumps data from the first table to the second table for the first time, and as 2 when it dumps data from the first table to the second table for the second time. It should be understood that each time the storage system dumps data from the first table in the first storage layer to the second table in the second storage layer, it updates the access frequency and creation time of each region to be split. For example, referring to Figure 10, which is a schematic diagram of the access popularity of a region to be split according to an embodiment of this application, as shown in Figure 10, the first table in the first storage layer includes 10,000 key-value pairs. When dumping to the second table, 3,000 key-value pairs are dumped to region A to be split, and 7,000 key-value pairs are dumped to region B to be split. At the same time, the creation time of each region to be split is updated. It should be understood that the above description of access frequency, creation time, and access popularity is only illustrative and does not constitute a limitation of this application. In practical applications, other forms can also be used to reflect the access popularity of the region to be split, such as using the access frequency of the region to be split as the access popularity.
[0120] After steps 601 to 603, the storage system dumps the first table in the first storage layer to the second table in the second storage layer, and then splits at least one third table from the second table. In some embodiments, the storage system persists at least one third table. For example, the storage system persists each third table that is split off. Or, the storage system stores the split third tables in a cache queue. If the number of third tables in the cache queue meets a threshold (e.g., set to 3), multiple third tables are persisted. This application does not limit this.
[0121] In other embodiments, since the third table split from the second table usually stays temporarily in the second storage layer, waiting for a background thread to persist it, and there is usually a performance gap between the second storage layer and the persistent storage device (usually the read performance of the second storage layer is greater than that of the persistent storage device), when the storage system faces a write burst, a large number of split third tables may accumulate in the second storage layer. To improve their read performance, the storage system can merge at least one of the split third tables, build an acceleration index on these third tables to improve the system's read performance, and persist the data of these third tables based on the merged table. The merging and persistent storage process is described below through steps 604 and 605.
[0122] 604. The storage system records data from at least one third table to a fourth table, and the fourth table records data from multiple fifth tables.
[0123] The second storage layer, in addition to storing the second table, can also store a fourth table. The fourth table is a compressed table that includes an index and multiple fifth tables. Taking a skip list as an example, the compressed table is illustrated in Figure 5 above and will not be repeated here. The fourth table includes an index for each fifth table, used to query data across multiple fifth tables. It should be understood that the data in the multiple fifth tables includes data from at least one third table. That is, after the storage system records data from at least one third table into the fourth table, the data from the original at least one third table is stored in the multiple fifth tables within the fourth table. Illustratively, for any fifth table, the key of its index is the minimum key of the fifth table, also called the anchor key, used to locate the fifth table. The index value is a pointer to the fifth table.
[0124] In some embodiments, the storage system records data from at least one third table to a fourth table by: determining whether the data range recorded in the third table overlaps with a fifth table already recorded in the fourth table; if there is an overlap, merging the overlapping portion with the content of the overlapping fifth table, and recording the non-overlapping portion as the fifth table in the fourth table; or, if there is no overlap, recording the third table as the fifth table in the fourth table. That is, when the fourth table in the second storage layer already records the fifth table, the storage system records data from at least one third table to the fourth table based on the data range of the third table and the data range of the fifth table recorded in the fourth table.
[0125] Schematic illustration: For any third table, the storage system, based on the indexes of the fifth table already recorded in the fourth table and the data range of the third table, determines at least one region of the third table to be merged. For any region to be merged, the data range of the region to be merged conforms to the data range of the fifth table, i.e., there is overlap. At least one region to be merged is then merged into the fifth table corresponding to each region to be merged. For example, the fourth table includes fifth table A and fifth table B, with indexes of (key=10, value=pointer to fifth table A) and (key=100, value=pointer to fifth table B) respectively. The data range of the third table to be merged is 40-260. Based on the indexes of fifth table A and fifth table B in the fourth table and the data range of the third table, the storage system determines the regions to be merged: 40-100 (conforming to the data range of fifth table A) and 100-260 (conforming to the data range of fifth table B). The data of each region to be merged is then merged into the corresponding fifth table. It should be noted that this is only an example and does not constitute a limitation of this application. In practical applications, data from at least one third table can be recorded into a fourth table according to the user-specified merging strategy.
[0126] In other embodiments, when the fourth table in the second storage layer does not yet record the fifth table, each third table in the storage system is treated as the fifth table and recorded in the fourth table. For example, if the data range of third table A is 10-50 and the data range of third table B is 100-300, then the storage system builds an index based on third table A (key = 10, value = pointer to third table A) and an index based on third table B (key = 100, value = pointer to third table B). It should be noted that this is only an example and does not constitute a limitation of this application. In practical applications, data from multiple third tables can be merged according to a user-specified merging strategy to form a fifth table, which is then recorded in the fourth table.
[0127] Referring to Figure 11, the execution steps of a storage system recording data from at least one third table to a fourth table are illustrated below. Figure 11 is a schematic diagram of multi-table merging provided in an embodiment of this application. As shown in Figure 11, the second storage layer includes a fourth table (i.e., a compressed table, CompactTable), which includes an index (key = 10, value = pointer to fifth table A) and an index (key = 100, value = pointer to fifth table B) of fifth table A. The data range of the third table to be recorded is shown in the figure. Schematic, the storage system performs the following steps to record data from the third table to the fourth table:
[0128] Step S1: Search the index of the fourth table for an anchor key that is less than or equal to the smallest key in the third table. Referring to Figure 11, this means searching the index of the fourth table for an anchor key less than or equal to key=40.
[0129] Step S1 includes the following two cases:
[0130] Step S1.1: If the storage system finds an anchor key in the index of the fourth table that is less than or equal to the smallest key in the third table, record the anchor key returned by the search as the first boundary X. Compare the largest key of the fifth table corresponding to the first boundary X with the smallest key of the third table. If the largest key of the fifth table is less than the smallest key of the third table, insert a new node (key is the smallest key of the third table, value is a null pointer) in the index of the fourth table to replace the original first boundary X to further refine the area to be merged in the third table. If the largest key of the fifth table is greater than or equal to the smallest key of the third table, keep the first boundary X unchanged.
[0131] Step S1.2: If the storage system does not find an anchor key in the index of the fourth table that is less than or equal to the smallest key in the third table, then insert a new node in the index of the fourth table (key is the smallest key in the third table, value is a null pointer), and denote the smallest key in the third table as the first boundary X.
[0132] Step S2: The storage system searches in the index of the fourth table for an anchor key that is less than or equal to the largest key in the third table, and records the anchor key returned by the search as the second boundary Y.
[0133] After the aforementioned steps S1 and S2, the fifth table corresponding to the anchor key within the merged range of [X, Y] is a skip table for receiving data from the third table.
[0134] Step S3: The storage system divides the third table into regions based on the anchor keys in the merge range [X, Y], resulting in multiple regions to be merged. Specifically, the storage system searches the third table for anchor keys belonging to the merge range [X, Y]. If an anchor key greater than or equal to X, or an anchor key greater than or equal to Y, is found, the set of anchor keys returned by the search results becomes the region splitting point for the third table. Referring to Figure 11, if the merge range [X, Y] is [10, 100], the set of anchor keys returned by the search in the third table is 40 and 200. Thus, the third table is divided into two regions to be merged: 40-90 and 200-260.
[0135] Step S4: The storage system merges the data in the third table into the corresponding fifth table according to the divided areas to be merged. Referring to Figure 11, areas 40-90 to be merged are merged into fifth table A, and areas 200-260 to be merged are merged into fifth table B.
[0136] After step 604 above, the ordered nature of the data in the data table is utilized to transfer at least one third table record to the fourth table. Since the key of the index in the fourth table is the smallest key of the fifth table, and the index value is a pointer to the fifth table, the storage system can use the index in the fourth table to quickly query the fourth table, thereby improving the system's read performance. Moreover, the above method can solve the problem of overlapping ranges between different tables and ensure the ordered nature of the data in the fourth table.
[0137] 605. The storage system will persistently store at least one of the multiple fifth tables.
[0138] In this process, the storage system initiates a background dump thread to persistently store at least one of the multiple fifth tables. That is, the fifth table is removed from the fourth table, and data from the fifth table is stored in the persistent storage device at the fifth table level. The storage mechanism of the persistent storage device is described in Figure 5 above and will not be repeated here. In some embodiments, the storage system can persistently store the multiple fifth tables sequentially according to a specified order, or it can randomly select at least one fifth table from the multiple fifth tables for persistent storage. Alternatively, it can persistently store fifth tables whose data range does not overlap with the first level of the SSTable in the persistent storage to reduce the merging overhead in the persistent storage device. This application does not limit this approach.
[0139] As can be seen, the fourth table in the second storage layer acts as an acceleration cache to receive data dumped to the persistent storage device, enabling fine-grained data flow from the second storage layer to the persistent storage device. This allows the storage system to promptly release storage space in the second storage layer without waiting for all data in the second table to be persistently stored before creating a new table in the second storage layer to receive data from the first storage layer, reducing blocking of normal writes to the first storage layer. Furthermore, since the storage system records data from the third table (splittered from the second table) to the fourth table and dumps data at the fifth table level, it ensures that the system can still access the un-dumped portions of the fifth table in the fourth table while dumping a portion of it, thus improving system read performance. Therefore, the above method, while ensuring the system obtains the benefits of the non-volatile second storage layer, significantly reduces write stop issues, lowers long-tail latency, and improves system read and write performance.
[0140] In summary, in the data storage method provided in this application, after storing the first table in the first storage layer into the second table in the second storage layer, when the data size of the second table reaches a second threshold, a third table with a size reaching a third threshold is split from the second table, and the data in the third table is recorded into a fourth table. The fourth table records multiple fifth tables. Based on this, the storage system can persistently store these fifth tables at the granularity of the fifth tables, realizing fine-grained data flow from the second storage layer to the persistent storage device. Thus, the storage system can not only release the storage space of the second storage layer in a timely manner, but also does not need to wait until all the data in the second table has been transferred to the persistent storage device. After persistent dumping, a new table is created in the second storage layer to receive data from the first storage layer, reducing the blocking of normal writes to the first storage layer. Moreover, since the storage system records the third table split from the second table to the fourth table and dumps at the fifth table as the granularity, it can ensure that the system can still access the fifth table in the fourth table that has not yet been dumped while dumping part of the fifth table, thereby improving the system's read performance. It can be seen that the above method not only ensures that the system obtains the benefits brought by the non-volatile second storage layer, but also greatly reduces the write stop problem, reduces the long tail latency of the system, and improves the system's read and write performance.
[0141] Based on the method embodiment shown in Figure 6 above, this application also provides a data writing flowchart, as shown in Figure 12. The data writing process of this application is described below with reference to Figure 12. Referring to Figure 12, taking a skip list as an example, the data storage method provided by this application includes the following stages A1 to A3 when writing data.
[0142] Phase A1: The storage system receives a write request (WRITE) from the user, extracts key-value pairs from the write request, and determines whether the current skip table (i.e., the memory table MemTable) in the first storage layer has remaining capacity (or whether it is full). If there is remaining capacity, the key-value pairs are written to the current skip table MemTable; otherwise, proceed to phase A2.
[0143] In phase A2, the storage system determines whether an immutable skip list (i.e., an immutable MemTable) exists in the first storage layer. If it does not exist, the current skip list is converted into an immutable skip list, a new skip list is created, key-value pairs are written to the new skip list, and a background dump thread is started to dump the immutable skip list to the ReceiveTable in the second storage layer. If it exists, the system waits for a signal from the background dump thread to dump the immutable skip list to the ReceiveTable in the second storage layer.
[0144] In stage A3, the storage system determines whether the ReceiveTable in the second storage layer meets the splitting condition (i.e., whether the size of the ReceiveTable has reached a preset threshold). If it does, a background skip list splitting process is started to split a smaller skip list, SplitTable, from the ReceiveTable and store it in the cache queue of the second storage layer. Next, a background dump thread is started to persistently store the smaller skip lists in the CompactTable of the second storage layer to the SSD. Simultaneously, a background merge thread is started to select smaller skip lists from the cache queue for merging until the cache queue is empty. If the ReceiveTable does not meet the splitting condition, the current process terminates.
[0145] In addition, based on the storage system provided in this application, this application also provides another data access method, which will be described below with reference to Figure 13.
[0146] Figure 13 is a flowchart of another data access method provided in an embodiment of this application. As shown in Figure 13, the method is applied to the storage system of a storage system, which further includes multiple storage layers, including a volatile first storage layer and a non-volatile second storage layer. Schematically, the method includes the following steps 1301 to 1305.
[0147] 1301. The storage system receives a read request and, based on the read request, queries the first table in the first storage layer.
[0148] In this embodiment, when the storage system receives a read request from a user, it extracts the target key from the read request and queries the first table in the first storage layer based on the target key. Taking a skip list as an example, this first table is also the memory table MemTable. If the target key is found in the first table, the key-value pair corresponding to the target key is returned to the user as the query result. If the target key is not found in the first table, step 1302 is executed. In some embodiments, if the target key is not found in the first table, an immutable table in the first storage layer is queried. If the target key is not found in the immutable table, step 1302 is executed.
[0149] 1302. If the data requested by the read request is not found in the first table, the storage system queries the second table in the second storage layer.
[0150] The second table in the second storage layer is the aforementioned ReceiveTable. If the target key is found in the second table, the key-value pair corresponding to the target key is returned to the user as the query result; if the target key is not found in the second table, step 1303 is executed.
[0151] 1303. If the data requested by the read request is not found in the second table, the storage system queries at least one third table that was split from the second table.
[0152] At least one third table split from the second table is stored in the second storage layer, for example, in a cache queue within the second storage layer. If the storage system finds the target key in at least one third table, it returns the key-value pair corresponding to the target key as the query result to the user; if the target key is not found in at least one third table, step 1304 is executed.
[0153] 1304. If no data is found in at least one third table, query the fourth table in the second storage layer. The fourth table records multiple fifth tables.
[0154] The fourth table includes an index for each fifth table. The key of the index is the smallest key in the fifth table, and the value of the index is a pointer to the fifth table corresponding to the index. The fourth table is also the aforementioned CompactTable. To illustrate, if no data is found in at least one third table, the fifth table recorded in the fourth table is queried based on the index of each fifth table in the fourth table. For example, the largest index node less than or equal to the target key is found in the indexes of each fifth table in the fourth table. If found, the fifth table pointed to by the pointer of that index node is queried. If the target key is not found in the fourth table, step 1305 is executed.
[0155] 1305. If the data requested by the read request is not found in the fourth table, the storage system queries the persistent storage device.
[0156] In this application, the persistent storage device uses a sorted string table (SSTable) to store data. The storage system searches layer by layer from top to bottom based on the target key until the data requested by the read request is found. For example, a Bloom filter of the SSTable can be used to quickly determine whether the target key exists, and then the index of the SSTable can be read into memory for a binary search. This application does not limit the implementation method of the storage system querying the persistent storage device.
[0157] As can be seen, because this application optimizes the storage mechanism of multiple storage layers in the storage system, it can alleviate problems such as write stoppage in the storage system. Therefore, when the storage system receives a read request, it can search layer by layer from the first storage layer, the second storage layer, and the persistent storage device, thereby improving the system's read performance.
[0158] Based on the method embodiment shown in Figure 13 above, this application also provides a data query flowchart, as shown in Figure 14. The data query process of this application will be described below with reference to Figure 14. Referring to Figure 14, taking a skip list as an example, the data query method provided by this application includes the following stages B1 to B6 when performing data queries.
[0159] Phase B1: The storage system receives read requests from users and extracts the target key from the read requests.
[0160] In stage B2, the storage system queries the target key in the memory table MemTable of the first storage layer using a skip list index. If found, it returns directly. If not found, it checks whether an immutable memory MemTable exists. If it exists, it proceeds to stage B3; otherwise, it proceeds to stage B4.
[0161] In stage B3, the storage system searches for the target key in the unmodifiable memory table MemTable. If found, it returns directly; otherwise, it proceeds to stage B4.
[0162] In stage B4, the storage system queries the target key in the ReciveTable of the second storage layer using a skip list index. If found, it returns directly; otherwise, it proceeds to stage B5.
[0163] In stage B5, the storage system queries the target key in the second storage layer. First, it traverses the small skip lists in the cache queue. If the target key is not found, it searches for the largest index node less than or equal to the target key in the accelerated index of the CompactTable. If the corresponding node is found, it enters the small skip list pointed to by its value for further querying. If the target key is still not found, it checks if a marked skip list exists (a marked skip list refers to a skip list extracted from the CompactTable and prepared for writing to the SSD). If it exists, it enters that skip list for further querying.
[0164] In stage B6, the storage system queries the target key on the SSD, searching layer by layer from top to bottom. For example, it uses the Bloom filter of the SSTable to quickly determine if the target key exists, and then reads the SSTable index into memory to perform a binary search.
[0165] As can be seen from the above description, this application provides a multi-level memory-based LSM tree storage mechanism that is completely different from the traditional LSM tree structure, effectively mitigating problems such as write stoppages in storage systems. The following experimental data provides a clear demonstration of the technical effectiveness of this application.
[0166] Figure 15 is a schematic diagram of a read / write performance test provided in this application. Referring to Figure 15, the test dataset uses an 80GB dataset YCSB (Cloud Serving Benchmark, a Java-based database performance testing tool for cloud or server use). The storage system provided in this application is referred to as StarKV. The related technologies for comparison include NoveLSM (ATC'18) and MatrixKV (ATC'20).
[0167] Read and write performance tests were conducted on three systems: StarKV, NoveLSM, and MatrixKV. The maximum NVM size used for all systems was 64GB. Data was collected from seven test scenarios.
[0168] Test Scenario A: Read / Write Balance, 50% R + 50% U (50% reads + 50% writes);
[0169] Test Scenario B: Read-heavy, write-light, 95% Read + 5% Write;
[0170] Test Scenario C: Read-only, 100% Read (100% Read);
[0171] Test Scenario D: Reading the most recently written record, 95% Read + 5% Insert (95% Read + 50% Insert);
[0172] Test scenario E: Scanning a small interval, 95% S + 5% I (95% scan + 5% insert);
[0173] Test Scenario F: Read and write record balance, 50% R + 50% R&U (50% read + 50% write);
[0174] As can be seen, StarKV's load performance is 4.3 times and 3.4 times higher than NovLSM and MatrixKV, respectively. In other AF test scenarios, StarKV's read performance is significantly improved compared to MatrixKV, and its write performance is significantly improved compared to NovLSM and MatrixKV. In the figure, KIOPS refers to thousands of read / write operations per second (or thousands of input / output operations per second), where "K" stands for kilo and "IOPS" is Input / Output Operations Per Second.
[0175] Next, referring to Table 1, which is a data table of YCSB-A 1KB long-tail latency test provided in this application, it can be seen that for the 90th percentile latency, StarKV reduces latency by 12.2 times compared to NovLSM and by 13.8 times compared to MatrixKV. For the 99th percentile latency, StarKV reduces latency by 110.1 times and 19.5 times compared to NovLSM and MatrixKV, respectively. For the 99.9th percentile latency, StarKV reduces latency by 64.9 times and 193.3 times compared to NovLSM and MatrixKV, respectively.
[0176] Table 1
[0177] Figure 16 is a schematic diagram of the architecture of a storage system provided in an embodiment of this application. As shown in Figure 16, the storage system includes a first storage module 1601, a splitting module 1602, and a second storage module 1603.
[0178] The first storage module 1601 is used to store the received data into the first table of the first storage layer in the storage system, and when the size of the first table reaches the first threshold, store the first table into the second table of the second storage layer in the storage system.
[0179] The splitting module 1602 is used to split at least one third table from the second table when the size of the second table reaches a second threshold, and to record the data of at least one third table to the fourth table when the size of the third table reaches a third threshold. The fourth table records multiple fifth tables.
[0180] The second storage module 1603 is used to persistently store at least one of the multiple fifth tables.
[0181] In some embodiments, the splitting module 1602 is configured to:
[0182] The second table is divided into multiple regions. When the size of the second table reaches the second threshold, the data size of each region is counted, and the regions whose data size reaches the third threshold are split from the second table to form the third table.
[0183] In some embodiments, the second table is a skip list, and the splitting module 1602 is used to: use the node with the highest index level in the second table as the boundary point for region division.
[0184] In some embodiments, the second table is a skip list, and the splitting module 1602 is used for:
[0185] Based on the position of the target region in the second table that has reached the third threshold in terms of data size, a target head node is created to point to the target boundary node. The pointers of the nodes associated with the target region are adjusted to split the target region out of the second table and form the third table corresponding to the target region.
[0186] In some embodiments, the splitting module 1602 is configured to:
[0187] Multiple regions whose data size reaches the third threshold are split from the second table according to their access frequency, forming multiple third tables.
[0188] In some embodiments, the splitting module 1602 is configured to:
[0189] Determine whether the data range recorded in the third table overlaps with the data already recorded in the fifth table (as recorded in the fourth table);
[0190] If there is overlap, merge the overlapping portion with the contents of the overlapping fifth table, and record the non-overlapping portion as the fifth table in the fourth table; or,
[0191] If there is no overlap, the third table will be recorded as the fifth table in the fourth table.
[0192] In some embodiments, the fourth table includes an index to each fifth table, where the key of the index is the smallest key in the fifth table, and the value of the index is a pointer to the fifth table corresponding to the index.
[0193] In some embodiments, the system further includes a query module for:
[0194] Receive a read request, and query the first table based on the read request;
[0195] If the data requested by the read request is not found in the first table, query the second table;
[0196] If no data is found in the second table, query at least one third table that was split from the second table.
[0197] If no data is found in at least one of the third tables, query the fourth table;
[0198] If no data is found in the fourth table, query the persistent storage device.
[0199] For a storage system employing multi-tiered storage, after storing the first table from the first storage tier into the second table of the second storage tier, when the data size of the second table reaches a second threshold, a third table is split from the second table to a size reaching a third threshold. The data from the third table is then recorded into a fourth table, which contains multiple fifth tables. Based on this, the storage system can persistently store these fifth tables at a granular level, enabling fine-grained data flow from the second storage tier to the persistent storage device. In this way, the storage system can promptly release storage space in the second storage tier without waiting for all the data in the second tables to be processed. After persistent dumping, a new table is created in the second storage layer to receive data from the first storage layer, reducing the blocking of normal writes to the first storage layer. Moreover, since the storage system records the third table split from the second table to the fourth table and dumps at the fifth table as the granularity, it can ensure that the system can still access the fifth table in the fourth table that has not yet been dumped while dumping part of the fifth table, thereby improving the system's read performance. It can be seen that the above method not only ensures that the system obtains the benefits brought by the non-volatile second storage layer, but also greatly reduces the write stop problem, reduces the long tail latency of the system, and improves the system's read and write performance.
[0200] It should be noted that the storage system provided in the above embodiments is only illustrated by the division of the above functional modules when performing data access. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. In addition, the data access device and data access method embodiments provided in the above embodiments belong to the same concept, and their specific implementation process can be found in the method embodiments, which will not be repeated here.
[0201] In this application, the terms "first," "second," etc., are used to distinguish identical or similar items that have substantially the same function and purpose. It should be understood that there is no logical or temporal dependency between "first," "second," and "nth," nor does it limit the quantity or order of execution. It should also be understood that although the following description uses the terms "first," "second," etc., to describe various elements, these elements should not be limited by the terms. These terms are merely used to distinguish one element from another. For example, without departing from the various examples described, a first table can be referred to as a second table, and similarly, a second table can be referred to as a first table. Both a first table and a second table can be tables, and in some cases, they can be separate and distinct tables.
[0202] In this application, the term "at least one" means one or more, and the term "multiple" means two or more. For example, multiple tables means two or more tables.
[0203] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.
[0204] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, in the form of program structure information. This program structure information includes one or more program instructions. When these program instructions are loaded and executed on a computing device, the processes or functions according to the embodiments of this application are generated, in whole or in part.
[0205] Those skilled in the art will understand that all or part of the steps of the above embodiments can be implemented by hardware or by a program instructing related hardware. The program can be stored in a computer-readable storage medium, such as a read-only memory, a disk, or an optical disk.
[0206] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit it. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.
Claims
1. A data access method, characterized in that, The method includes: The received data is stored in the first table of the first storage layer in the storage system. When the size of the first table reaches a first threshold, the first table is stored in the second table of the second storage layer in the storage system. When the size of the second table reaches the second threshold, at least one third table is split from the second table. When the size of the third table reaches the third threshold, the data of the at least one third table is recorded in the fourth table. The fourth table records multiple fifth tables. At least one of the plurality of fifth tables is persistently stored.
2. The method according to claim 1, characterized in that, Splitting at least one third table from the second table includes: The second table is divided into multiple regions. When the size of the second table reaches the second threshold, the data size of each region is counted, and the regions whose data size reaches the third threshold are split from the second table to form the third table.
3. The method according to claim 2, characterized in that, The second table is a skip list, and dividing the second table into multiple regions includes using the node with the highest index level in the second table as the boundary point for region division.
4. The method according to claim 2 or 3, characterized in that, The second table is a skip list. The step of splitting the region whose data size reaches the third threshold from the second table to form the third table includes: Based on the position of the target region in the second table that reaches the third threshold in terms of data size, a target head node is created to point to the target boundary node. The pointers of the nodes associated with the target region are adjusted to split the target region from the second table and form the third table corresponding to the target region.
5. The method according to any one of claims 2 to 4, characterized in that, The step of splitting the region whose data size reaches the third threshold from the second table to form the third table includes: Multiple regions whose data size reaches the third threshold are split from the second table according to their access frequency, forming multiple third tables.
6. The method according to any one of claims 1 to 5, characterized in that, The step of recording data from at least one third table to a fourth table includes: Determine whether the data range recorded in the third table overlaps with the data already recorded in the fifth table in the fourth table; If there is overlap, merge the overlapping portion with the contents of the overlapping fifth table, and record the non-overlapping portion as the fifth table in the fourth table; or, If there is no overlap, the third table will be recorded as the fifth table in the fourth table.
7. The method according to any one of claims 1 to 6, characterized in that, The fourth table includes an index to each fifth table, where the key of the index is the smallest key in the fifth table, and the value of the index is a pointer to the fifth table corresponding to the index.
8. The method according to any one of claims 1 to 7, characterized in that, The method further includes: Receive a read request, and query the first table based on the read request; If the data requested by the read request is not found in the first table, query the second table; If the data is not found in the second table, query at least one third table that is split from the second table; If the data is not found in at least one of the third tables, query the fourth table; If the data is not found in the fourth table, query the persistent storage device.
9. A storage system, characterized in that, The storage system includes: The first storage module is used to store the received data into a first table of a first storage layer in the storage system, and when the size of the first table reaches a first threshold, store the first table into a second table of a second storage layer in the storage system. A splitting module is used to split at least one third table from the second table when the size of the second table reaches a second threshold, and when the size of the third table reaches a third threshold, record the data of the at least one third table to a fourth table, and the fourth table records multiple fifth tables. The second storage module is used to persistently store at least one of the plurality of fifth tables.
10. The system according to claim 9, characterized in that, The splitting module is used for: The second table is divided into multiple regions. When the size of the second table reaches the second threshold, the data size of each region is counted, and the regions whose data size reaches the third threshold are split from the second table to form the third table.
11. The system according to claim 10, characterized in that, The second table is a skip list, and the splitting module is used to: use the node with the highest index level in the second table as the boundary point for region division.
12. The system according to claim 10 or 11, characterized in that, The second table is a skip list, and the splitting module is used for: Based on the position of the target region in the second table that reaches the third threshold in terms of data size, a target head node is created to point to the target boundary node. The pointers of the nodes associated with the target region are adjusted to split the target region from the second table and form the third table corresponding to the target region.
13. The system according to any one of claims 10 to 12, characterized in that, The splitting module is used for: Multiple regions whose data size reaches the third threshold are split from the second table according to their access frequency, forming multiple third tables.
14. The system according to any one of claims 9 to 13, characterized in that, The splitting module is used for: Determine whether the data range recorded in the third table overlaps with the data already recorded in the fifth table in the fourth table; If there is overlap, merge the overlapping portion with the contents of the overlapping fifth table, and record the non-overlapping portion as the fifth table in the fourth table; or, If there is no overlap, the third table will be recorded as the fifth table in the fourth table.
15. The system according to any one of claims 11 to 14, characterized in that, The fourth table includes an index to each fifth table, where the key of the index is the smallest key in the fifth table, and the value of the index is a pointer to the fifth table corresponding to the index.
16. The system according to any one of claims 11 to 15, characterized in that, The system also includes a query module for: Receive a read request, and query the first table based on the read request; If the data requested by the read request is not found in the first table, query the second table; If the data is not found in the second table, query at least one third table that is split from the second table; If the data is not found in at least one of the third tables, query the fourth table; If the data is not found in the fourth table, query the persistent storage device.
17. A computer program product, characterized in that, When the computer program product is run on the storage system, the storage system enables the data access method as described in any one of claims 1 to 8.
18. A computer-readable storage medium, characterized in that, The computer-readable storage medium is used to store at least one piece of program code, which is used to implement the data access method as described in any one of claims 1 to 8.
Citation Information
Patent Citations
Partition splitting method and device, electronic equipment and readable storage medium
CN110032549A
Key value storage method based on multi-tree conversion mechanism
CN114996275A
LSM-tree key value storage method and device based on persistent memory and medium
CN118349167A
High density data storage based on log structured storage techniques
WO2024020070A1
Cited By
Evolution method, system and equipment for evolutionary database index structure
CN122019550A