B+ tree index system of heterogeneous memory architecture

Abstract

The application discloses a B+ tree index system of a heterogeneous memory architecture and relates to the field of computer storage systems, and the method comprises an operation layer located in DRAM and a persistent layer located in PMem; by constructing a memory layout which is helpful to realize separation of key-value pair reading and writing and data persistent storage, combining a log structure storage format and a concurrent control mechanism based on an optimistic lock, random writing behavior to a persistent memory device is eliminated, and performance loss caused by a PMem writing amplification problem caused by mismatching of access granularity is effectively inhibited. The application can realize high-performance persistent B+ tree index and meet the needs of high throughput, scalability and fast fault recovery of a persistent memory storage system.

Description

Technical Field

[0001] This invention relates to the field of computer storage systems, and in particular to a B+ tree indexing system for heterogeneous memory architectures. Background Technology

[0002] Large-capacity, byte-addressable, and non-volatile persistent memory (PMem), once incorporated into the memory subsystem, forms a heterogeneous memory system together with traditional volatile dynamic random-access read-only memory (DRAM), enabling computers to implement data persistence at the main memory level. PMem provides an opportunity to build large-capacity, low-latency, and high-throughput persistent memory storage systems. Index structures are one of the core driving forces ensuring the high-quality operation of storage systems such as databases. How to construct high-performance key-value (KV) index structures adapted to heterogeneous memory architectures has naturally become a key focus for system designers. Over the past few decades, researchers have explored the construction and performance optimization methods of key-value indexes around the theme of "better memory, caching, and CPU efficiency." However, major technological changes in underlying hardware have overturned the design concepts of upper-layer application systems, prompting researchers to rethink and define new theories, methods, and strategies for building high-performance software systems based on new hardware technologies.

[0003] Building high-performance key-value indexes on heterogeneous memory systems is more challenging than traditional index structures designed for volatile DRAM or persistent storage devices. Specifically: 1. Key-value indexes must guarantee crash consistency. Traditional DRAM-based key-value indexes lack this guarantee and cannot work on persistent memory systems. Achieving crash consistency not only increases system design complexity but also incurs performance degradation. While key-value indexes for persistent external storage such as flash memory and SSDs guarantee consistency, the order-of-magnitude performance difference between persistent internal and external storage makes these index structures inefficient on persistent memory systems. 2. Due to the differences in physical properties between PMem and DRAM, performance optimization strategies for DRAM index structures become inefficient when ported to PMem systems. 3. Building indexes on PMem systems requires overcoming the interoperability issues between PMem and other hardware. Examples include interoperability issues between PMem and hardware transactional memory, performance degradation caused by accessing PMem across NUMA nodes, and PMem bandwidth degradation caused by directory-based cache coherency protocols.

[0004] In recent years, a series of PMem-based tree indexes have been proposed with the goal of minimizing data persistence and crash consistency maintenance overhead and optimizing PMem bandwidth utilization. These indexes either utilize a hybrid PMem-DRAM architecture to reduce PMem access; selectively persist metadata; use additional metadata to achieve logless crash consistency guarantees; employ custom memory allocators; or use lock-free concurrency control models. However, these designs face challenges related to performance, functional integrity, and correctness. In terms of performance, while existing designs strive to reduce PMem access, performance issues caused by random access to PMem cannot be completely eliminated. Regarding correctness, some lock-free PMem indexes exhibit anomalies such as empty reads, dirty reads, and lost update results. In terms of functional integrity, some PMem indexes do not support variable-length key-value pairs. Furthermore, the strategy of tightly coupling optimization with a single persistent memory device makes them lack versatility, hindering their deployment and application on other types of PMem devices. Summary of the Invention

[0005] The purpose of this invention is to provide a B+ tree indexing system with a heterogeneous memory architecture, which can achieve high-performance persistent B+ tree indexes and meet the needs of persistent memory storage systems for high throughput, scalability, and fast fault recovery.

[0006] To achieve the above objectives, the present invention provides the following solution:

[0007] A B+ tree indexing system with a heterogeneous memory architecture includes: an operation layer located in DRAM and a persistence layer located in PMem;

[0008] The operation layer is used to process query, insertion, update, and deletion requests for key-value data. The operation layer includes internal nodes and volatile leaf nodes. Internal nodes store keys arranged in ascending order and pointers to lower-level nodes. Multiple keys and pointers within the same node are stored in two separate arrays. Each volatile leaf node contains a key-value entity area and a metadata area. The key-value entity area is divided into several storage slots for storing key-value pairs. The volatile leaf nodes are connected by pointers to form a linked list.

[0009] The persistence layer ensures the device can quickly recover from sudden system crashes or normal shutdowns. The persistence layer includes: a log file, persistent leaf nodes, and a persistent memory manager. The log file stores log entities. The log entities ensure the consistency of the B+ tree during crashes and store the actual key-value data. The persistent memory manager allocates memory space for the log entities and persistent leaf nodes. Persistent leaf nodes are linked together by pointers to form a persistent leaf node linked list. This persistent leaf node linked list is used to maintain the sequential persistence of volatile leaf nodes located in DRAM. During the recovery phase, the volatile leaf node linked list in DRAM is quickly reconstructed by scanning the information in the log file and persistent leaf nodes. One persistent leaf node corresponds to one volatile leaf node.

[0010] Optionally, the internal node further includes a version number; the version number is used to record the number of times the current node is split, thereby reducing the concurrency control overhead during the internal node splitting process.

[0011] Optionally, the metadata area includes: state lock variables, version number, fingerprint array, used storage slot counter, sibling pointer, and persistent pointer;

[0012] State lock variables are used for concurrency control; state lock variables include three types of state locks: strong mutual exclusion, weak mutual exclusion, and non-blocking.

[0013] Version numbers are used to ensure crash consistency;

[0014] The fingerprint array is used to store fingerprint information extracted from the key value to speed up the query process;

[0015] The used storage slot counter is used to record the number of storage slots that are currently occupied in the node;

[0016] The sibling pointer is used to point to the right sibling node of the current node;

[0017] A persistent pointer is used to point to a persistent pointer to the corresponding leaf node in the persistent layer.

[0018] Optionally, the log entity format for workloads consisting of fixed-length key-value pairs includes: leaf pointer, timestamp, version number, operation type, key, and value;

[0019] When the workload consists of variable-length key-value pairs, the log entity format includes: leaf pointer, timestamp, version number, operation type, key, value, key length, and value length.

[0020] Optionally, the persistent leaf node includes: a version number, a bitmap, and a sibling pointer;

[0021] The version number is used to record the number of times the current leaf node has been updated. Each time the volatile leaf node splits, the persistent leaf node will be updated synchronously. At this time, the version number of the persistent leaf node will be incremented by 1.

[0022] The number of bits in the bitmap is consistent with the number of storage slots; when a bit is set, it indicates that a valid key-value pair entity is stored in the corresponding storage slot.

[0023] Sibling pointers are used to connect persistent leaf nodes into a linked list; the order of the nodes is strictly consistent with the order of the volatile leaf nodes.

[0024] Optionally, the memory pages of the persistent memory manager include data pages and log pages;

[0025] The data page is used to allocate space for newly created persistent leaf nodes; the log page is treated as a whole.

[0026] Optionally, multi-threaded concurrent access is supported, and optimistic locking is used to ensure thread safety;

[0027] The volatile leaf nodes employ tri-state locks to address the issue of read threads being blocked during insertion / update / deletion operations; these tri-state locks represent strong mutual exclusion, weak mutual exclusion, and non-blocking operations.

[0028] The persistent leaf nodes and the log files are configured to be thread-private, thus avoiding concurrency control overhead.

[0029] According to specific embodiments provided by the present invention, the present invention discloses the following technical effects:

[0030] This invention provides a heterogeneous memory architecture B+ tree index system that addresses the shortcomings of existing B+ tree index systems designed for persistent memory environments. By constructing a memory layout that separates key-value pair reading and writing from persistent data storage, and combining a log-structured storage format with an optimistic locking-based concurrency control mechanism, it eliminates random write behavior to persistent memory devices and effectively suppresses performance loss caused by PMem write amplification due to mismatched memory access granularity. This results in a high-performance persistent B+ tree index that meets the high throughput, scalability, and rapid fault recovery requirements of persistent memory storage systems. Attached Figure Description

[0031] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0032] Figure 1A schematic diagram of a B+ tree index system structure for a heterogeneous memory architecture provided by the present invention;

[0033] Figure 2 This is a schematic diagram of the internal node space layout;

[0034] Figure 3 This is a schematic diagram of the spatial layout of the metadata area;

[0035] Figure 4 A schematic diagram of the log entity format when the workload consists of fixed-length key-value pairs;

[0036] Figure 5 A schematic diagram of the log entity format when the workload consists of variable-length key-value pairs;

[0037] Figure 6 A schematic diagram of the spatial layout of persistent leaf nodes;

[0038] Figure 7 This is a schematic diagram of the collaborative splitting process of volatile leaf nodes and persistent leaf nodes according to the present invention. Detailed Implementation

[0039] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0040] The purpose of this invention is to provide a B+ tree indexing system with a heterogeneous memory architecture, which can achieve high-performance persistent B+ tree indexes and meet the needs of persistent memory storage systems for high throughput, scalability, and fast fault recovery.

[0041] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0042] Persistent memory, also known as non-volatile memory (NVM), features large capacity, byte addressability, and low read / write latency. It not only boasts memory access performance approaching that of traditional dynamic random access memory (DRAM), but also provides data non-volatility similar to traditional external storage such as SSDs, flash memory, and HDDs. The advent of PMem fundamentally revolutionized the design of memory storage systems. In particular, with Intel's release of Optane DCPMM (Optane Data Center Persistent Memory Module), the design of high-performance index structures based on PMem has flourished, such as B+ trees, ART trees, tire systems, and hash tables.

[0043] Designing high-performance persistent index structures is a highly challenging task because persistent memory platforms require crash consistency guarantees to ensure data consistency in the event of sudden events such as power outages and system crashes. However, ensuring crash consistency introduces additional overhead. For example, on processors supporting Intel Optane DCPMM, special instructions (such as clwb and mfence on x86 platforms) are needed to explicitly persist data from the CPU on-chip cache to PMem in a specific order. Using these instructions not only increases coding complexity but also introduces significant additional overhead. Furthermore, persistent memory devices have high random read and write latency, and index structures such as B+ trees have significant random access characteristics, limiting their performance on persistent memory platforms.

[0044] like Figure 1 As shown, the present invention provides an operation layer for DRAM and a persistent layer located in PMem; the leaf nodes in the operation layer and the persistent layer have a one-to-one correspondence, and the volatile leaf nodes in the operation layer are ordered. To ensure that the B+ tree can recover to the consistent state before the crash after a sudden system crash or power outage, this ordering among the volatile leaf nodes needs to be persistently preserved.

[0045] A B+ tree consists of multiple levels of nodes, with the bottom-level nodes called leaf nodes and nodes at other levels called internal nodes. Internal nodes contain only keys and pointers to lower-level nodes, while leaf nodes contain both keys and values. To read data from a leaf node, you must traverse each level from the top-level internal node until you reach the target leaf node. There are no restrictions on the number of leaf nodes or internal nodes; the B+ tree can automatically split and merge nodes based on the data size to increase or decrease space. No data transfer is required between internal and leaf nodes.

[0046] The operation layer is used to process query, insert, update, and delete requests for key-value data; the operation layer includes: internal nodes and volatile leaf nodes; the internal nodes are used to store keys arranged in ascending order and pointers to lower-level nodes; multiple keys and pointers within the same node are stored in two separate arrays (see...). Figure 2 The key_array and ptr_array in the volatile leaf node are used to accelerate the key-value comparison process during query operations; the volatile leaf node contains a key-value entity area and a metadata area; the key-value entity area is divided into several storage slots for storing key-value pair entities; the volatile leaf nodes are connected by pointers to form a volatile leaf node linked list.

[0047] The persistence layer ensures the device can quickly recover from sudden system crashes or normal shutdowns. The persistence layer includes: a log file, persistent leaf nodes, and a persistent memory manager. The log file stores log entities. The log entities ensure the consistency of the B+ tree during crashes and store the actual key-value data. The persistent memory manager allocates memory space for the log entities and persistent leaf nodes. Persistent leaf nodes are linked together by pointers to form a persistent leaf node linked list. This persistent leaf node linked list is used to maintain the sequential persistence of volatile leaf nodes located in DRAM. During the recovery phase, the volatile leaf node linked list in DRAM is quickly reconstructed by scanning the information in the log file and persistent leaf nodes. One persistent leaf node corresponds to one volatile leaf node.

[0048] like Figure 2 As shown, the internal node also maintains a version number. The version number records the number of times the current node has been split, which is used to reduce the concurrency control overhead during the internal node splitting process.

[0049] like Figure 3 As shown, the metadata area includes: state lock variables, version number, fingerprint array, used storage slot counter, sibling pointer, and persistent pointer;

[0050] The state lock variable (state_lock) is used for concurrency control; the state lock variable includes three states: strong mutual exclusion, weak mutual exclusion, and non-blocking.

[0051] Version numbers are used to ensure crash consistency;

[0052] The fingerprint array is used to store fingerprint information extracted from the key value to speed up the query process;

[0053] The used storage slot counter (used_counter) is used to record the number of storage slots that are currently occupied in the node;

[0054] A sibling pointer is used to point to the right sibling node of the current node;

[0055] A persistent pointer (pptr) is used to point to a persistent pointer to the corresponding leaf node in the persistent layer.

[0056] 4. Log files store log entries and are configured as thread-private to reduce synchronization overhead. Insert / update / delete operations performed by the operation layer write a log entry to the persistence layer. Two log entry formats are set for fixed-length key-value pairs and variable-length key-value pairs. Figure 4 The image shows the log entity format when the workload consists of fixed-length key-value pairs, such as... Figure 4As shown, the log entity format when the workload is a fixed-length key-value pair includes: leaf pointer, timestamp, version number, operation type, key, and value;

[0057] Leaf pointer (PLeafaddr): 8 bytes, a pointer to a persistent leaf node in the persistence layer, which contains the same key-value pairs as the current log entity;

[0058] Timestamp: 8 bytes, the time when the log entity was generated;

[0059] Version number: 4 bytes, records the version number of the volatile leaf node to which the insert, delete, or update operation was performed;

[0060] Operation type (op): 1 byte, records the type of operation that generated the current log entity. The operation types include insert, delete, and update.

[0061] Key and value: each occupy 8 bytes.

[0062] like Figure 5 As shown, the log entity format for workloads consisting of variable-length key-value pairs includes: leaf pointer, timestamp, version number, operation type, key, value, key length (key_len), and value length (val_len). Each field occupies 4 bytes.

[0063] like Figure 6 As shown, the persistent leaf node includes: a version number, a bitmap, and a sibling pointer;

[0064] The version number is used to record the number of times the current leaf node has been updated. Each time the volatile leaf node splits, the persistent leaf node will be updated synchronously. At this time, the version number of the persistent leaf node will be incremented by 1. The version number is 4 bytes.

[0065] The size of the bitmap is configurable, and its number of bits is consistent with the number of storage slots; when a bit is set, it indicates that a valid key-value pair entity is stored in the corresponding storage slot.

[0066] Sibling pointers are used to link persistent leaf nodes into a linked list; the order of the nodes is strictly consistent with the order of the volatile leaf nodes. A sibling pointer is 8 bytes long.

[0067] Nalloc is a lightweight persistent memory manager that uses pages (fixed-size blocks of memory) to manage persistent memory; the memory pages of the persistent memory manager include data pages and log pages.

[0068] The data pages are used to allocate space for newly created persistent leaf nodes; the log pages are treated as a single unit. Each memory page has a metadata area aligned with a cache line. For data pages, the metadata area contains a 30-bit memory page number field (page_id), a 2-bit page type field (page_type), and a 4-byte used_sz field, where the memory page number is globally unique. The metadata area of ​​a log page only contains the memory page number and page type fields.

[0069] This invention avoids random writes to persistent memory devices caused by insert / delete / update operations. B+ tree indexes exhibit significant random write patterns. However, the high latency of random writes to persistent memory leads to suboptimal performance of persistent B+ tree indexes. This invention avoids this problem by storing actual key-value pairs in the DLeaf. When inserting / updating / deleting a key-value pair, this invention first traverses the internal nodes to find the target DLeaf, and then performs the corresponding write operation on the DLeaf. Afterwards, a log entry is written to the log file in the persistent layer to ensure crash consistency.

[0070] A persistent leaf node corresponds to a volatile leaf node; for simplicity, these two types of leaf nodes are denoted as PLeaf and DLeaf, respectively. Initially, the key-value pairs in PLeaf are identical to their corresponding key-value pairs in DLeaf. However, since write requests such as insertion, update, and deletion are performed on DLeaf, the data in DLeaf and PLeaf becomes inconsistent at runtime. Although the device can tolerate this inconsistency, it increases recovery overhead, and after structured modification operations such as splitting DLeaf, the structural consistency between the DLeaf and PLeaf linked lists is broken, making it impossible to correctly rebuild the operation layer during recovery. Therefore, this invention proposes a data synchronization mechanism triggered by a split event on DLeaf to ensure data consistency between DLeaf and PLeaf.

[0071] Different concurrency control mechanisms are used for internal nodes, volatile leaf nodes, and persistent leaf nodes. Internal nodes employ read-write locks based on hardware transactional memory.

[0072] (1) Concurrency control for internal nodes is divided into two scenarios: concurrency control during normal operations and concurrency control during splitting operations. For normal operations, the worker thread first locks all internal nodes with a reader lock, and then traverses layer by layer until a candidate DLeaf is found, at which point the reader lock is released. For the second scenario, internal nodes are locked with a reader lock before being updated. Then, the internal nodes on the traversal path are checked in reverse from bottom to top to find all internal nodes on the traversal path that need to be updated. Next, by comparing the current version number of these internal nodes with the corresponding version number stored in the traversal path, it is verified whether these internal nodes were split during the splitting process of DLeaf. If not, the reader lock is upgraded to a writer lock, the internal node is updated directly, and the lock is released after completion. Otherwise, the check is repeated, the reader lock is upgraded to a writer lock, and the internal node is updated.

[0073] (2) Volatile leaf nodes use a three-state lock to solve the problem of read threads being blocked during insert / update / delete operations. A volatile leaf node lock has three states: 0, 1, and 2. State 0 is the idle state, indicating that no thread holds the lock, and the node can be accessed by any thread. State 1 is the weakly mutually exclusive state, indicating that the node is being modified by a thread performing an insert / update / delete operation. Nodes in the weakly mutually exclusive state can be accessed by other reader threads, but are prohibited from being accessed by other writer threads. State 2 is the strongly mutually exclusive state, indicating that the node is being split. Leaf nodes with locks in the strongly mutually exclusive state are prohibited from being read / written by other threads. Other threads are prohibited from reading because the required key-value pairs may be moved to the newly created leaf node during the splitting process.

[0074] (3) Persistent leaf nodes and log files are configured as thread-private, which does not generate concurrency control overhead.

[0075] This invention employs a PMem-DRAM hybrid memory layout, maintaining volatile leaf nodes containing key-value pairs in the DRAM to ensure that query operations (including single-point and range queries) do not require accessing persistent memory devices to read data. In this layout, random writes, which are unfriendly to persistent memory devices, are offloaded to the DRAM, which offers better memory access performance. Through log-structured storage technology and batch write methods, the performance suppression caused by persistent memory write amplification is effectively mitigated, and persistent memory bandwidth utilization is maximized. This invention does not specifically specify the type of persistent memory device and does not rely on any technology supported only by a particular hardware architecture or platform, thus offering better portability and a wider range of application scenarios.

[0076] The operation layer handles read and write requests from upper-layer applications, while the persistence layer ensures persistent data storage and system fault recovery. This architecture eliminates the need for read operations (including single-point and range queries) to access the PMem, and random writes to the PMem device by the index structure are completely eliminated, resulting in higher throughput than comparable devices. Furthermore, the persistent memory components are designed to be thread-private, avoiding synchronization overhead in multi-threaded scenarios and achieving superior tail latency performance compared to similar devices.

[0077] The following uses fixed-length key-value pairs<K,V> Taking this example, and referring to the accompanying drawings in the embodiments of the application, the flow of single-point query, range query, insertion, deletion, and update operations of the present invention is described in detail. These operations share a common sub-process—traversing from the root to the target leaf node. During the traversal, after the worker thread acquires the reader lock, it traverses downwards layer by layer from the root node, releasing the reader lock after reaching the bottom leaf node. Then, the following processes are executed respectively.

[0078] 1. Single-point query

[0079] 1) Read the lock variable of the leaf node. If the lock variable is in a strong mutual exclusion state, it means that the current leaf node is being split by other threads, and the worker thread will backtrack to the root node and start traversing again;

[0080] 2) Otherwise, the worker thread searches for a key-value pair with a key equal to K within the leaf node. If found, it returns the corresponding V; if not found, it returns null to indicate that the requested content does not exist.

[0081] 2. Range query

[0082] 1) The worker thread checks the lock variable of the leaf node. If the lock is free, it sets the lock state to strong mutex and enters the leaf node to read the key-value data that meets the conditions; if the lock is held by another thread, it waits for the other thread to release the lock before performing the above steps. The lock is released after all the data in the current leaf node has been read.

[0083] 2) Determine if a sufficient number of key-value entities have been read. If the preset number of reads has been reached, end the range query and return the query results; if the preset number of reads has not been reached, check if the sibling node's lock is occupied. If the sibling node's lock is idle, set the lock state to strong mutual exclusion, and then enter the sibling node to read key-value entities; if the sibling node's lock is occupied, wait for other threads to release the lock.

[0084] 3) Repeat the above process until a sufficient number of key-value pairs have been read or there are no more sibling nodes.

[0085] 3. Insert

[0086] 1) Check the lock status of the leaf node. If the lock of the leaf node is held by another thread, backtrack to the root node and start traversing again; if the lock is free, set the lock to mutex and enter the leaf node to perform the insertion operation.

[0087] 2) Upon entering a leaf node, first check if there is already a key-value pair entity with a key equal to K in the current node. If there is, end the insertion and return an insertion failure; otherwise, find a free storage slot based on the used_counter field of the leaf node, write K and V, and update the metadata of the leaf node at the same time.

[0088] 3) After updating the metadata, the worker thread writes a log entity to the log file it is bound to. The format of the log entity is as follows: Figure 4 As shown; the lock is released after the log entity is written;

[0089] 4) If no free storage slot is found, a split operation is triggered. See the split process for details. Figure 7 As shown.

[0090] After the split is complete, the worker thread rolls back to the root node and restarts the traversal, finds the target leaf node and writes K and V, the process is the same as the writing process described in the previous step.

[0091] 4. Delete

[0092] 1) Check the lock status of the leaf node. If the lock of the leaf node is held by another thread, backtrack to the root node and start traversing again; if the lock is free, set the lock to mutex and enter the leaf node to perform the deletion operation.

[0093] 2) Delete key-value pair entities. Locate the entity with key K in the leaf node, delete the data entity, and update the metadata;

[0094] 3) After execution, a log entry is generated and written to the log file bound to the current worker thread. The format of the log entry is as follows: Figure 4 As shown. The lock is released after the log entity is written. After deleting a data entity, if used_counter is 0, it indicates that there are no more data entities in the current leaf node. In this case, the leaf node is reclaimed to improve space utilization.

[0095] 5. Update

[0096] 1) Check the lock status of the leaf node. If the lock of the leaf node is held by another thread, backtrack to the root node and start traversing again; if the lock is free, set the lock to mutex and enter the leaf node to perform the update operation.

[0097] 2) Update key-value entities. Within the leaf nodes, search for the entity with the key K. Once found, replace its value with V.

[0098] 3) Generate a log entry and write it to the log file bound to the current worker thread. The format of the log entry is as follows: Figure 4 As shown. The lock is released after the log entity is written.

[0099] 6. Node Splitting

[0100] When inserting a key-value entity, if there are no free storage slots in the volatile leaf node (DLeaf) to be inserted, it will trigger a split of the node, accompanied by data synchronization between the node and its corresponding persistent leaf node (PLeaf). The process of leaf node splitting and data synchronization is shown in the figure below, and consists of three stages.

[0101] Phase 1: Sort the key-value entities within the volatile leaf nodes to be split, and at the same time, adjust the position of the fingerprints of the key-value entities accordingly.

[0102] Phase Two: Data Synchronization. This phase consists of three steps:

[0103] 1) Select the middle key of the sorted leaf node as the split key, and write all key-value pairs (including the split key) between the first key and the split key into the corresponding persistent leaf node in sequence;

[0104] 2) Create a new volatile leaf node (denoted as DLeaf-N) and a new persistent leaf node (denoted as PLeaf-N);

[0105] 3) Copy the remaining key-value pairs and their fingerprints from DLeaf to DLeaf-N, and copy the remaining key-value pairs to PLeaf-N.

[0106] Phase 3: Update the node's metadata.

[0107] 1) Update the metadata of PLeaf-N and point the sibling pointer of PLeaf-N to the sibling node of the old PLeaf;

[0108] 2) Perform the same operation on DLeaf-N.

[0109] 3) Set the persistent pointer (pptr) of DLeaf-N to point to PLeaf-N;

[0110] 4) Update the metadata of PLeaf and DLeaf, and set their sibling pointers to PLeaf-N and DLeaf-N respectively.

[0111] There are two points to clarify regarding the data synchronization process: 1) When updating the node's metadata, to ensure consistency in case of crashes, PLeaf-N must be updated before PLeaf is updated. 2) After the right half of the key-value pairs from DLeaf is synchronized to PLeaf-N and DLeaf-N in the second phase, they are not deleted from DLeaf. Instead, in the third phase, when updating the metadata of DLeaf, the used_counter value of DLeaf is halved to invalidate these key-value pairs. When inserting a new key-value pair into DLeaf, it directly overwrites the invalid key-value pair in the storage slot indexed by used_counter.

[0112] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the systems disclosed in the embodiments, since they correspond to the methods disclosed in the embodiments, the descriptions are relatively simple; relevant parts can be referred to the method section.

[0113] This document uses specific examples to illustrate the principles and implementation methods of the present invention. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of the present invention. Furthermore, those skilled in the art will recognize that, based on the ideas of the present invention, there will be changes in the specific implementation methods and application scope. Therefore, the content of this specification should not be construed as a limitation of the present invention.

Claims

1. A B+ tree indexing system with a heterogeneous memory architecture, characterized in that, include: The operation layer is located in the DRAM and the persistence layer is located in the PMem; The operation layer is used to process query, insertion, update, and deletion requests for key-value data. The operation layer includes internal nodes and volatile leaf nodes. Internal nodes store keys arranged in ascending order and pointers to lower-level nodes. Multiple keys and pointers within the same node are stored in two separate arrays. Each volatile leaf node contains a key-value entity area and a metadata area. The key-value entity area is divided into several storage slots for storing key-value pairs. The volatile leaf nodes are connected by pointers to form a linked list. The persistence layer ensures the system can quickly recover from sudden system crashes or normal shutdowns. It includes a log file, persistent leaf nodes, and a persistent memory manager. The log file stores log entities; these entities ensure the B+ tree's crash consistency and store the actual key-value data. The persistent memory manager allocates memory space for the log entities and persistent leaf nodes. A persistent leaf node linked list is formed using pointers. This linked list ensures the sequential persistence of volatile leaf nodes located in DRAM. During the recovery phase, the volatile leaf node linked list in DRAM is quickly reconstructed by scanning the information in the log file and persistent leaf nodes. One persistent leaf node corresponds to one volatile leaf node. The metadata area includes: state lock variables, version number, fingerprint array, used storage slot counter, sibling pointer, and persistent pointer; State lock variables are used for concurrency control; state lock variables include three types of state locks: strong mutual exclusion, weak mutual exclusion, and non-blocking. Version numbers are used to ensure crash consistency; The fingerprint array is used to store fingerprint information extracted from the key value to speed up the query process; The used storage slot counter is used to record the number of storage slots that are currently occupied in the node; The sibling pointer is used to point to the right sibling node of the current node; A persistent pointer is used to point to a persistent pointer to the corresponding leaf node in the persistent layer; The persistent leaf node includes: version number, bitmap, and sibling pointer; The version number is used to record the number of times the current leaf node has been updated. Each time the volatile leaf node splits, the persistent leaf node will be updated synchronously. At this time, the version number of the persistent leaf node will be incremented by 1. The number of bits in the bitmap is consistent with the number of storage slots; when a bit is set, it indicates that a valid key-value pair entity is stored in the corresponding storage slot. Sibling pointers are used to connect persistent leaf nodes into a linked list; the order of nodes is strictly consistent with the order of volatile leaf nodes. The internal nodes support multi-threaded concurrent access and use optimistic locking to ensure thread safety; The volatile leaf nodes employ a tri-state lock to address the issue of read threads being blocked during insertion / update / deletion operations; the tri-state lock consists of strong mutual exclusion, weak mutual exclusion, and non-blocking mechanisms. The persistent leaf nodes and the log files are configured to be thread-private, thus avoiding concurrency control overhead.

2. The B+ tree indexing system for a heterogeneous memory architecture according to claim 1, characterized in that, The internal node also includes a version number; the version number is used to record the number of times the current node is split, reducing the concurrency control overhead during the internal node splitting process.

3. The B+ tree indexing system for a heterogeneous memory architecture according to claim 1, characterized in that, When the workload consists of fixed-length key-value pairs, the log entity format includes: leaf pointer, timestamp, version number, operation type, key, and value; When the workload consists of variable-length key-value pairs, the log entity format includes: leaf pointer, timestamp, version number, operation type, key, value, key length, and value length.

4. The B+ tree indexing system for a heterogeneous memory architecture according to claim 1, characterized in that, The persistent memory manager's memory pages include data pages and log pages; The data page is used to allocate space for newly created persistent leaf nodes; the log page is treated as a whole.

Images