R-tree spatial index design method oriented to DRAM-NVM hybrid storage architecture

By storing internal nodes and leaf nodes in DRAM and NVM respectively in a DRAM-NVM hybrid storage architecture, and designing a persistent linked list structure and a minimum expansion strategy, the performance degradation and data consistency issues of the R-tree spatial index engine are solved, achieving efficient write request processing and fast fault recovery.

CN122019526APending Publication Date: 2026-05-12HARBIN INST OF TECH +1
View PDF 0 Cites 0 Cited by

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
HARBIN INST OF TECH
Filing Date
2024-11-12
Publication Date
2026-05-12

AI Technical Summary

Technical Problem

Under the DRAM-NVM hybrid storage architecture, the R tree spatial index engine faces risks such as performance degradation, hardware wear and tear, insufficient crash consistency guarantees, and persistent memory leaks, resulting in low query efficiency and data inconsistency.

Method used

The internal nodes and leaf nodes are stored in DRAM and NVM respectively. A persistent linked list structure is designed, and a minimum expansion strategy and in-situ update algorithm are adopted. Combined with an efficient fault recovery method, data consistency and the integrity of the index structure are ensured.

Benefits of technology

It improves write request processing efficiency, reduces the impact of NVM read/write latency, ensures data consistency and rapid fault recovery, and meets the needs of users in scenarios with fewer reads and more writes.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN122019526A_ABST
    Figure CN122019526A_ABST
Patent Text Reader

Abstract

The invention discloses an R-tree spatial index design method oriented to a DRAM-NVM hybrid storage architecture, relates to the technical field of computer data storage, and provides a write optimization spatial index HR-Tree under the DRAM-NVM hybrid architecture. The core design thought is that internal nodes are deployed on a DRAM, leaf nodes are placed on an NVM, and a targeted data read-write operation process is designed; in the aspect of an index structure and an operation mechanism, a minimum expansion strategy is adopted around a scene of less reading and more writing, a leaf node data structure and an in-situ updating algorithm on the NVM are designed in a targeted manner, and the write request processing efficiency can be improved on the premise of ensuring data consistency. And the multi-character data expansion and efficient fault recovery are provided, so that the actual requirements of the user are better met by allowing more flexible personalized configuration and shortening the service pause time. The method is suitable for the application fields of computer technology, database technology, data storage and the like.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This invention relates to the field of computer data storage technology, and more specifically to an R-tree spatial index for a DRAM-NVM hybrid storage architecture. Background Technology

[0002] As a fundamental component of spatiotemporal database systems, the R tree spatial index engine significantly improves the efficiency of retrieving specific data in the context of massive, multidimensional data. Its features, such as range queries, nearest neighbor queries, skyline queries, and Top-k dominance queries, are widely used in map navigation applications, geographic information systems, digital mock-ups (responsible for realistic computer simulations of products), and multidimensional feature vector access in machine learning. However, classic R tree indexes and their variants were primarily designed for use in traditional memory (mainly dynamic random access memory, or DRAM), aiming to provide accelerated query services for large-scale, multidimensional data stored on high-capacity external storage such as SSDs and HDDs. While leveraging the high read / write performance of DRAM, they are constrained by its high cost, poor scalability, and data loss upon power failure. These constraints have gradually become a bottleneck in the development of today's R tree spatial index engines.

[0003] With the development of computer storage technology, a new type of memory—non-volatile memory (or persistent memory, abbreviated as NVM or PM, also known as persistent memory)—has emerged and entered commercial use in recent years. NVM combines the byte-addressable characteristics of DRAM with the non-volatile nature of secondary storage. Current NVM technologies mainly include PCM, STT-RAM, ReRAM, and 3D XPoint. Intel Optane DC Persistent Memory Modules (DCPMM), as the industry's first commercially available and only widely deployed and applied non-volatile memory, uses 3D XPoint technology.

[0004] While NVM offers advantages in non-volatility, addressing mode, storage capacity, latency, power consumption, and manufacturing cost, it's also evident that currently available NVM hardware typically suffers from read latency several times that of DRAM, and write endurance is quite limited; the gap between the two remains significant. Therefore, DRAM-NVM hybrid architectures will likely remain the primary form of NVM integration in computer storage architectures for a relatively long period. Figure 1 As shown.

[0005] R-trees were proposed by Guttman in 1984. As a mainstream form of B-tree development for multidimensional space, it uses the minimum bounding rectangle (MBR) to represent multidimensional data objects.

[0006] like Figure 2 As shown, non-leaf nodes of the R-tree store entries in the form of (R, ptr), where ptr is a pointer to one of its child nodes, and R is the MBR (also known as the directory rectangle, i.e., D1, D2, and D3 in the diagram) containing all the rectangles in this child node; similarly, leaf nodes store entries in the form of (R, obj_id), where R is the data rectangle (i.e., R1-R7 in the diagram), and obj_id points to the specific description information of the data.

[0007] Many queries on an R-tree index are performed top-down. For example, a range query retrieves rectangles overlapping the query rectangle from the root node to a leaf node to find all records enclosed by the query rectangle, while a nearest neighbor query finds the k nearest records to the query point by calculating the shortest distance from the point to the rectangle and the distance from the point to every object within the rectangle. Insertion operations can cause leaf node overflow, leading to node splits along the insertion path. Guttman's two most classic node splitting methods are the linear split method and the quadratic split method, both heuristics that attempt to minimize the resulting MBR after splitting.

[0008] However, classic R-trees do not adequately consider splitting strategies, which means that when a node is about to split, other nodes at the same level may not yet be filled, thus reducing space utilization. On the other hand, minimizing the MBR does not directly avoid overlap. When a query rectangle overlaps with multiple MBRs, a query has to visit multiple subtrees, resulting in reduced query efficiency. Therefore, following R-trees, academia and industry have designed and implemented a series of R-tree variants to further improve query efficiency, space utilization, and other metrics. These are summarized in chronological order as follows:

[0009] R+ trees improve single-point query performance by splitting an object and storing the results in multiple Master Backers (MBRs) to ensure that a point is covered by at most one child node during a search. R* trees innovatively employ a more comprehensive optimization strategy, encompassing four aspects: area, overlap, margin, and space utilization. During splitting, overlap is minimized if the pointer in the current node points to a leaf node; otherwise, area is minimized. Furthermore, R* trees delay splitting by re-inserting records from one node into another node at the same level. Hilbert R trees implement linear sorting of high-dimensional data rectangles using Hilbert curves and store the largest Hilbert value (LHV) in each non-leaf node. Hilbert R trees handle overflow using an s-to-s+1 strategy, meaning that splitting only occurs when a node and its s-1 sibling nodes are full; otherwise, only the entries are redistributed among nodes. These designs allow Hilbert R trees to simultaneously improve query efficiency and space utilization. The modified R* tree is a further improvement on the R* tree. It focuses more on optimizing the overlap between MBRs and has special processing strategies for high-dimensional data.

[0010] In summary, since the birth of the classic R tree and the emergence of various variants, its advantages in querying multidimensional data objects have been gradually increasing.

[0011] Since the first batches of NVM hardware entered the market in April 2019, numerous renowned universities and research institutions both domestically and internationally have devoted themselves to research on NVM applications, targeted optimization, and performance evaluation. Current research can be mainly divided into four directions: transactional storage systems, file systems, database systems, and data analysis algorithms represented by graph algorithms. The HR-Tree proposed in this invention can be categorized into the research area of ​​storage and indexing engines optimized for NVM (or PM) within the aforementioned database systems direction. In recent years, both domestic and international researchers have made certain progress in this field; the following are some representative works.

[0012] Daniel Waddington et al. designed a key-value storage engine called MCKVS that directly utilizes NVM for data and metadata storage, and tested its performance on Intel Optane persistent memory. They obtained some noteworthy conclusions: the cache refresh cost of Optane persistent memory is very high, and the raw performance of DRAM is about 2 to 3 times that of Optane persistent memory, but the long-tail latency of the two is comparable.

[0013] Xinjing Zhou et al. proposed DPTree (Differential Persistent Tree) under a DRAM-PM hybrid memory architecture. DPTree employs a two-layer persistent index structure: the first layer is a B+ tree (also known as a Buffer Tree) residing in DRAM, and the second layer is a read-only Base Tree that can only be updated through merging. Its structure is similar to a B+ tree, but its internal nodes and leaf nodes are distributed in DRAM and PM respectively. Write requests are first absorbed by the fast and small Buffer Tree, with persistence support provided by the write-optimized PM redo log. Only when the size of the Buffer Tree reaches a set threshold will it be merged in-place into the Base Tree, which has read optimization and coarse-grained versioning technology, and persisted, ensuring crash consistency and concurrent reads. The core idea of ​​DPTree is to continuously batch process multiple write operations in DRAM and then merge them into PM to amortize persistence overhead. Experimental results show that DPTree reduces PM writes by 1.7 to 3 times compared to the state-of-the-art designs at the time.

[0014] Soojeong Cho et al. proposed the FBR-tree (Failure-atomic Byte-addressable R-tree) in NVM. Key contributions include a non-blocking, lock-free range query algorithm, insertion and deletion algorithms requiring only 8-byte atomic writes, and in-situ rebalancing algorithms that log only metadata for node splitting and merging. Furthermore, the authors raised concerns about selective persistence in distributed storage within DRAM and NVM: the tree structure needs to be rebuilt upon system restart, making the index design not strictly a persistent index.

[0015] Brandon Lavinsky et al. proposed a PM-Rtree (Persistent Merged R-tree) based on a DRAM-NVM hybrid architecture. By interleaving bitmaps and data blocks and implementing a lock-free insertion algorithm, PM-Rtree achieved a significant performance improvement over FBR-tree. However, because the authors did not further refine the persistence operations of the NVM layer to ensure atomicity in case of faults, PM-Rtree struggles to recover to a consistent state under certain abnormal system crashes (such as sudden power outages or sudden severe hardware failures).

[0016] Overall, compared to the current state of research on modifying key-value storage engines and B+ tree index engines using PM (Production Processing), research on R-tree spatial index engines started relatively late and has yielded relatively few results. Analogous to key-value storage engines and B+ tree index engines, R-trees under the DRAM-NVM hybrid memory architecture will mainly face the following three problems:

[0017] (1) The layer-by-layer read-write index structure in NVM can cause significant performance degradation and hardware wear. In the actual process of the index engine processing insert, query and other requests, node data often needs to be read and written layer by layer from top to bottom or bottom to top. Due to the higher read and write latency and shorter write life of NVM compared to DRAM, this problem cannot be avoided at present, but its impact should be minimized.

[0018] (2) The lack of crash consistency guarantees designed for NVM means that data may be inconsistent after a system crash and restart, which may lead to failure recovery. NVM has a completely different persistence mechanism from block storage devices such as SSD and HDD. If you plan to take advantage of the non-volatility of NVM, you must fully consider the persistence mechanism of NVM and redesign reliable strategies and methods.

[0019] (3) Persistent memory leak risk. Space allocation and reclamation inevitably occur frequently during the insertion, deletion and other update operations in R-trees. Improper NVM space management operations have a high probability of causing persistent memory leaks. Due to the non-volatility of NVM, such leaks can have serious consequences: not only will they reduce the currently available space and increase the risk of related processes exiting abnormally due to insufficient space allocation, but they also cannot be easily repaired by restarting the system, often requiring manual release of data. Summary of the Invention

[0020] The purpose of this invention is to provide an R-tree spatial index design method for DRAM-NVM hybrid storage architecture, which solves the technical problems mentioned in the background art above.

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

[0022] This invention provides an R-tree spatial index design method for DRAM-NVM hybrid memory architecture, the method being:

[0023] Step 1: Build the internal modules of the R tree index engine;

[0024] Step 2: Store the internal nodes and leaf nodes in the DRAM and NVM of the index engine's internal module, respectively;

[0025] Step 3: Through structural design of the leaf nodes, all leaf nodes form a persistent linked list;

[0026] Step 4: Based on the above design, complete the data update and data query.

[0027] Furthermore, in a preferred embodiment, the internal modules of the index engine of the R-tree described above include DRAM & NVM memory management components, a basic configuration and data structure layer, an internal index operation layer, and an external interface layer.

[0028] The DRAM & NVM memory management component provides a standardized memory allocation and deallocation API for DRAM and NVM.

[0029] The configuration and data structure layer is used to load the personalized configuration when this engine is deployed, and also to maintain all data structures during engine operation and call the memory allocation and release API at any time;

[0030] The internal operation layer of the index is used to perform insertion, deletion, and query, and to execute node splitting, merging, and redistribution;

[0031] The external interface layer is used to provide users with insertion, deletion, and query functions by calling the internal operation layer of the index downwards and analyzing and presenting the returned results.

[0032] Furthermore, in a preferred embodiment, step 3 above specifically comprises:

[0033] Compared to internal nodes, leaf nodes have two additional flag bits and four 8-byte pointers. The four 8-byte pointers are the alternative pointers next0 and next1, and the predecessor pointers prev and dptr.

[0034] The metadata for each leaf node consists of a bitmap organized by two tag bits, alt and del, and the remaining bits.

[0035] Furthermore, in a preferred embodiment, the aforementioned marker bit alt is used to indicate a valid successor pointer;

[0036] The marker bit del is used to indicate whether the current dptr is valid;

[0037] A valid dptr points to a leaf node that is about to be released after the merge is complete but has not yet been released;

[0038] The predecessor pointer `prev` always points to the predecessor node of the current node.

[0039] Furthermore, in a preferred embodiment, the above data update includes insertion and deletion;

[0040] The insertion operation is as follows:

[0041] Step 1: Determine the insertion path from top to bottom based on the minimum expansion strategy, and expand the corresponding MBR in each internal node on the path;

[0042] Step 2: Write the new entry to the corresponding leaf node in NVM, and ensure that the new entry is completely written through a persistence operation;

[0043] Step 3: After confirming that the new entry has been written correctly, set the corresponding bit in the leaf node bitmap to make the new entry effective, and then perform another persistence operation to ensure that the bitmap has been updated;

[0044] The deletion operation is as follows:

[0045] Step 1: Locate the node containing the deleted entry from top to bottom;

[0046] Step 2: Set the corresponding bit in the bitmap of the node to 0 to invalidate the entry to be deleted, and use a persistence operation to ensure that the bitmap has been updated;

[0047] Step 3: Shrink the MBR corresponding to each internal node on the deletion path from bottom to top.

[0048] Furthermore, in a preferred embodiment, leaf node splitting in NVM is implemented through a leaf node splitting method with consistency guarantees;

[0049] Leaf node merging in NVM is achieved by using the del flag and dptr in the leaf nodes.

[0050] Furthermore, in a preferred embodiment, multi-word metadata of leaf nodes is designed by sharing bytes.

[0051] This invention also provides an efficient fault recovery method implemented according to the R-tree space index design method for DRAM-NVM hybrid memory architecture described in any one of the above claims, the method being:

[0052] NVM memory pool file mapping and parsing phase: The NVM layer data structure of the indexing engine is persistently stored on the NVM hardware medium in the form of a memory pool file; when fault recovery begins, the corresponding memory pool file needs to be found and opened through a pre-configured and hard-coded path in the program, so as to directly map it into the program's virtual address space without caching; using the macro functions provided by PMDK to parse the root object at a fixed offset in the memory pool, the starting offset of the persistent leaf node linked list in the pool can be obtained;

[0053] Leaf node persistent linked list consistency repair phase: Forward traverse the leaf node linked list, check each leaf node and modify it to ensure that the linked list is consistent;

[0054] Leaf node sorting phase: Traverse the linked list again, calculate the MBR of each node, and combine the MBR with the offset of the node in the pool to obtain the entry to be inserted into the bottom inner node.

[0055] DRAM layer index structure reconstruction stage: Use entries to build an R-tree index structure in DRAM; the structure reconstruction is completed by creating an empty internal node in DRAM as a new index tree and inserting entries one by one into it.

[0056] The R-tree space index design method for DRAM-NVM hybrid memory architecture described in this invention can be entirely implemented using computer software. Therefore, correspondingly, this invention also provides a computer-readable storage medium storing a computer program, which is executed by a processor to perform the R-tree space index design method for DRAM-NVM hybrid memory architecture described above.

[0057] The present invention also provides a computer device, the device including a memory and a processor, wherein the memory stores a computer program, and when the processor runs the computer program stored in the memory, the processor executes an R-tree space index design method for a DRAM-NVM hybrid memory architecture as described in any one of the above.

[0058] The beneficial effects of this invention are as follows:

[0059] 1. This invention implements the design of a hybrid R-tree spatial index engine based on minimum expansion by addressing four aspects: index structure, operating mechanism, multi-word metadata expansion, and fault recovery. Regarding the index structure and operating mechanism, this index engine adopts a minimum expansion strategy for scenarios with fewer reads and more writes, and specifically designs a leaf node data structure and in-situ update algorithm on NVM, which theoretically can improve write request processing efficiency while ensuring data consistency. The proposed multi-word metadata expansion and efficient fault recovery better meet users' actual needs by allowing for more flexible personalized configuration and shortening service downtime.

[0060] This invention is applicable to fields such as computer technology, database technology, and data storage. Attached Figure Description

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

[0062] Figure 1 This is a schematic diagram of the novel computer storage architecture mentioned in the background section;

[0063] Figure 2This is a schematic diagram of the classic R-tree index mentioned in the background section;

[0064] Figure 3 This is a schematic diagram of the internal module organization and external interface of the index engine described in this invention;

[0065] Figure 4 This is a schematic diagram of the index logic structure described in this invention;

[0066] Figure 5 This is a schematic diagram of the internal node layout described in this invention;

[0067] Figure 6 This is a schematic diagram of the leaf node layout described in this invention;

[0068] Figure 7 This is a schematic diagram of leaf node splitting as described in this invention;

[0069] Figure 8 This is the leaf node splitting algorithm described in this invention;

[0070] Figure 9 This is a schematic diagram of leaf node merging as described in this invention;

[0071] Figure 10 This is the leaf node merging algorithm described in this invention;

[0072] Figure 11 This is a schematic diagram of the internal structure of the leaf node supporting multi-word metadata as described in this invention;

[0073] Figure 12 This is a schematic diagram of the macroscopic process for index engine failure recovery as described in this invention;

[0074] Figure 13 This invention describes the impact of index tree size changes on the insertion throughput of various index engines. Figure (a) shows the impact of index tree size changes on the Wroclaw dataset, and Figure (b) shows the impact of index tree size changes on the Synthetic dataset.

[0075] Figure 14 This invention describes the impact of bitmap size changes on the insertion throughput of various indexing engines. Figure (a) shows the impact of bitmap size changes on the Wroclaw dataset, and Figure (b) shows the impact of bitmap size changes on the Synthetic dataset.

[0076] Figure 15 This invention describes the impact of index tree size changes on the query throughput of various index engines. Figure (a) shows the impact of index tree size changes on the Wroclaw dataset, and Figure (b) shows the impact of index tree size changes on the Synthetic dataset.

[0077] Figure 16 This invention describes the impact of bitmap size changes on the insertion throughput of various indexing engines. Figure (a) shows the impact of bitmap size changes on the Wroclaw dataset, and Figure (b) shows the impact of bitmap size changes on the Synthetic dataset. Detailed Implementation

[0078] The specific embodiments of the present invention will be further described in detail below with reference to the accompanying drawings. These embodiments will help those skilled in the art to further understand the present invention, but do not limit the invention in any way. It should be noted that those skilled in the art can make several changes and improvements without departing from the concept of the present invention, and these all fall within the protection scope of the present invention.

[0079] Implementation Method 1: This implementation method provides an R-tree spatial index design method for DRAM-NVM hybrid storage architecture. The index design method is based on the minimum expansion hybrid R-tree spatial index technology, mainly targeting scenarios with few writes and few reads, and has made targeted optimizations for typical write scenarios such as insertion and deletion.

[0080] The method includes the following steps:

[0081] Step 1: Build the internal modules of the R tree index engine;

[0082] Step 2: Store the internal nodes and leaf nodes in the DRAM and NVM of the index engine's internal module, respectively;

[0083] Step 3: Through structural design of the leaf nodes, all leaf nodes form a persistent linked list;

[0084] Step 4: Based on the above design, complete the data update and data query.

[0085] This embodiment proposes a core design principle for R-trees in a hybrid architecture: internal nodes and leaf nodes are stored in DRAM and NVM respectively, enabling the maintenance of leaf node data consistency for fault recovery. This principle fully leverages the characteristics of each part in the DRAM-NVM hybrid architecture. Specifically:

[0086] (1) NVM only needs to be responsible for the leaf node layer, thereby reducing the impact of its read and write latency on the efficiency of the index engine and the write wear of the NVM hardware itself.

[0087] (2) On medium to large-scale datasets, the index tree has a relatively large number of internal node layers, and these layers have better read and write performance in DRAM.

[0088] (3) All the original data of the R tree is stored in the leaf nodes. Maintaining leaf node consistency is sufficient for fault recovery and can also reduce the space occupied by NVM.

[0089] Implementation Method 2, see below Figure 3 This embodiment describes the internal module organization of the R-tree index engine in the R-tree spatial index design method for DRAM-NVM hybrid storage architecture described in Embodiment 1.

[0090] like Figure 3 As shown, the internal modules of the R-tree index engine proposed in this embodiment consist of a DRAM & NVM memory management component, a basic configuration and data structure layer, an internal index operation layer, and an external interface layer; the functions of each component are described below:

[0091] DRAM & NVM Memory Management Components: Provides APIs for DRAM and NVM memory allocation and deallocation.

[0092] Basic configuration and data structure layer: Loads the personalized configurations when this engine is deployed (including the number of slots in nodes, data dimensions, minimum node fill, etc.), maintains all data structures during engine operation, and calls memory allocation and release APIs at any time to maintain necessary but not excessive space occupation.

[0093] The index's internal operation layer actually completes insertion, deletion, and query requests through various methods, and performs node splitting, merging, and redistribution at appropriate times.

[0094] External interface layer: It hides all specific execution details and provides users with services such as insertion, deletion, and query by calling the internal operation layer of the index and analyzing and presenting the returned results.

[0095] Implementation Method 3, see below Figures 4 to 6 This embodiment describes step 3 of the R-tree spatial index design method for a DRAM-NVM hybrid memory architecture described in Embodiment 1.

[0096] Considering real-world scenarios with fewer reads and more writes, a large number of insert and delete write requests often lead to significant overhead in target node selection, index data updates, and structural adjustments. Therefore, reducing these overheads is crucial for improving the overall execution efficiency of the R-tree spatial index engine in this scenario. The index engine implemented in this embodiment uses the classic, concise, and efficient target node selection strategy of R-trees—minimum expansion—combined with a specially designed in-situ update algorithm on NVM. This allows for the rapid determination of optimal target nodes, reducing NVM writes to some extent and delaying structural adjustments.

[0097] The index logical structure is as follows Figure 4 As shown, internal nodes and leaf nodes are stored in the DRAM and NVM of the index engine's internal module, respectively. In the event of a system crash, this logical structure allows for the reconstruction of the complete index structure based on the leaf nodes. As long as the data consistency of the leaf nodes can be guaranteed, the reconstructed index structure will inevitably reach a consistent state.

[0098] Internal node layout as follows Figure 5 As shown, the leaf node layout is as follows Figure 6 As shown in the diagram, both internal nodes and leaf nodes contain bitmaps and entry slots, which are essential node structures. Considering that current hardware architectures only support 8-byte NVM atomic writes, the leaf node metadata size is limited to 8 bytes.

[0099] Leaf nodes add two flag bits and four 8-byte pointers compared to internal nodes. The metadata of each leaf node consists of two flag bits (alt and del) and a bitmap organized using the remaining bits, thus supporting a maximum of 62 entry slots.

[0100] `alt` indicates a valid successor pointer (next0 or next1, collectively referred to as candidate pointers); `del` indicates whether the current `dptr` is valid; a valid `dptr` points to a leaf node that will be released after the merge but has not yet been released; `prev` is the predecessor pointer, always pointing to the predecessor node of the current node. This layout design ensures that all leaf nodes form a persistent linked list, playing a crucial role in data consistency guarantees and fault recovery.

[0101] The index structure of HR-Tree is a key factor in its efficient data update and query capabilities. As an R-tree spatial indexing engine applied to multidimensional objects, data updates mainly include insertion and deletion operations, as well as the node splitting and merging they cause; while data queries primarily focus on range query operations in multidimensional queries.

[0102] Implementation Method 4: This implementation method provides a detailed explanation of data updates in the R-tree spatial index design method for a DRAM-NVM hybrid memory architecture described in Implementation Method 1.

[0103] Data updates mainly include insertion and deletion operations;

[0104] The insertion operation is specifically defined as follows: The minimum expansion strategy is a classic, concise, and efficient target node selection strategy for insertion operations. It attempts to select the node with the smallest increase in MBR area before and after inserting a new entry from all branches of the current internal node as the target node. If there are two or more branches with equal increases in MBR area, the node with the smallest area is further selected to avoid a "tie".

[0105] Inserting a new index data entry requires three steps, provided it does not trigger node overflow: ① Determine the insertion path from top to bottom based on a minimum expansion strategy, and expand the corresponding MBR in each internal node along the path; ② Write the new entry to the corresponding leaf node in the NVM, and ensure the new entry has been completely written through a persistence operation; ③ After confirming that the new entry has been written correctly, set the corresponding bit in the leaf node bitmap to make the new entry effective, and ensure the bitmap has been updated again through a persistence operation. In step ③, since the leaf node metadata size is limited to 8 bytes, the bitmap update can be considered atomic.

[0106] Similarly, for deletion operations: if the entry to be deleted exists and no node underflow is triggered after deletion (i.e., the node utilization is still higher than the minimum fill after deletion), only three steps are needed: ① Find the node where the entry to be deleted is located from top to bottom; ② Set the corresponding bit in the bitmap of the node to 0 to invalidate the entry to be deleted, and use a persistence operation to ensure that the bitmap has been updated; ③ Shrink the MBR corresponding to each internal node on the deletion path from bottom to top.

[0107] It's worth noting that since the internal nodes involved in insertion and deletion are all in DRAM, any adjustments can be made directly without compromising data consistency. However, when modifying data on leaf nodes in NVM, a persistence operation is often required afterward. This pauses the current CPU pipeline to ensure the modification is fully written before proceeding to the next step. For insertion operations, the two persistence operations ensure that steps ② and ③ are not reversed due to the out-of-order execution of the CPU. Even assuming a system crash or abnormal power loss could occur before or after step ③, as long as the bitmap hasn't been updated, the insertion can be considered not to have been performed. Conversely, if the corresponding bit in the bitmap is updated, the new entry must have already been written to the corresponding position beforehand, similarly avoiding inconsistency.

[0108] Implementation Method 5, see below Figure 7 and Figure 8 This embodiment describes the situation where node splitting is required during the insertion operation described in Embodiment 4 when there are no available entry slots in the node.

[0109] Inserting a new entry into a node when there are no available slots will cause the node to overflow. The conventional way R-trees handle node overflow is through node splitting. Since internal nodes reside in DRAM, splitting requires no consistency guarantees. However, for leaf nodes in NVM, splitting must be performed with great care to avoid inconsistencies in the event of a system crash.

[0110] This embodiment implements leaf node splitting in NVM using a leaf node splitting method with consistency guarantees; such as Figure 7As shown, the old node N1 in the diagram will be split into N1 and N2, with N2 being the successor node of N1 before the split. The basic idea is to utilize the three pointers (prev, next0, and next1) in the leaf node. After allocating an empty new leaf node N3 and initializing it by pointing its prev and next0 pointers to N1 and N2 respectively, half of the entries will be copied from N1 to N3. The corresponding bits in the bitmap of N3 will also be set to 1 to make the copied entries effective. At the same time, by pointing the next1 pointer of N1 to N3 and simultaneously updating the bitmap of N1 and setting the alt flag to 1 using NVM atomic write, the successor of N1 is atomically updated to N3, thus adding N3 to the leaf node persistent linked list. Finally, setting the prev pointer of N2 to point to N3 completes the bidirectional connection. If the system crash occurs before the last step, the leaf node linked list may have a previous pointer inconsistency, but this inconsistency can be detected and repaired during the fault recovery process.

[0111] The main difference between the above design and the classic R-tree lies in the process of loading the determined partitioning scheme into the two nodes. Algorithm 1 describes the specific details of this process, such as... Figure 8 As shown, specifically, the LoadLeafNodes() method requires the old leaf node that overflowed, the empty new leaf node after allocation and initialization, and the partitioning scheme. Its execution consists of three phases: Phase 1 (lines 1-13) loads one set of entries from the two sets determined by the partitioning scheme into the new node, sets the corresponding bit position in its bitmap to 1, and sets the corresponding bit position in a copy of the old node's metadata to 0. The final persistence operation in this phase ensures that all the above modifications have been written to NVM, thus preparing the new node for addition to the leaf node persistent list. Phase 2 (lines 14-22) first sets a candidate successor pointer for the old node. Through persistence operations, it ensures that after the candidate successor pointer is written, an 8-byte NVM atomic write converts the set candidate successor pointer into a valid pointer and actually updates the old node's metadata, ensuring that the old node contains only the other set of entries from the partitioning scheme. If the successor node of the old node is not empty, it also sets the predecessor of the successor node to point to the new node. Finally (lines 23-29), if the new entry that triggered the split is assigned to the old node group, it can be inserted according to the normal procedure.

[0112] Implementation Method Six, see below Figure 9 and Figure 10 This embodiment describes the situation where node splitting is required when there are no available entry slots in a node during the deletion operation described in Embodiment 4.

[0113] A node underflow is defined as a node's utilization falling below a set threshold due to a deletion operation. If another sibling node can be found through the parent node of the underflow node, and all entries of both the sibling node and the underflow node can be accommodated by a single node, then node merging can be performed. Internal node merging in DRAM can still be performed without any consistency guarantees, but unlike leaf node splitting, the two nodes involved in leaf node merging are usually not empty. In this case, releasing the failed node to be deleted after the merge is completed too early may result in the loss of index entries after power failure recovery, while releasing it too late may cause incorrect duplicate entries. Therefore, this embodiment addresses the asynchrony between the release of failed nodes and the activation of merged entries by using the del flag and dptr in the leaf node.

[0114] like Figure 9 As shown, leaf nodes N1 and N2 will be merged into N1. First, all entries in N2 are copied to N1, and N1's dptr is set to point to N2 (since the bitmap hasn't been updated and the del flag is 0, the copied entries and dptr are not yet effective). A persistence operation ensures the nodes are ready to merge. Then, a single 8-byte NVM atomic write and persistence operation is performed. The bitmap update and del flag setting of N1 are completed atomically, indicating that N1 is now responsible for storing all entries from both nodes. N2, however, is considered invalidated but not yet released because N1's active dptr is still valid. Afterward, by setting the successor / predecessor pointers of N2's predecessor / successor nodes to point to each other, N2 is truly removed from the leaf node persistent list. Finally, N1's del flag is reset to 0, and the space occupied by N2 is released.

[0115] Algorithm 2 describes the detailed process of the leaf node merging operation, such as... Figure 10 As shown. The MergeLeafNodes() method only operates on the two leaf nodes involved in the merge. After the merge process is complete, the node will contain all the entries from the original two nodes, while delNode will be removed from the leaf node list and released. There are two controls for illegal access in the method: setting the dptr pointer must be done before setting the del flag to 1 to avoid using an illegal dptr during fault recovery; before releasing the node, the del flag is set to 0 to invalidate the dptr pointer, eliminating the risk of duplicate space release.

[0116] It's worth noting that if a system crash or unexpected power outage occurs at certain points during leaf node splitting and merging (e.g., after a new node has been created for the split but before it's added to the linked list), the relevant nodes may become inaccessible through the persistent leaf node linked list. However, this will not cause a persistent memory leak. Database administrators can use the internal collections API provided by PMDK to traverse all objects in the NVM memory pool when necessary, thereby detecting nodes not in the linked list and actively releasing them.

[0117] Implementation Method Seven: This implementation method provides a detailed explanation of data querying in the R-tree spatial index design method for DRAM-NVM hybrid storage architecture described in Implementation Method One.

[0118] In terms of data querying, the main focus is on range query operations in multidimensional queries.

[0119] Without using R-trees, the most basic range query involves traversing the entire dataset and returning all data falling within the range, which is obviously prohibitively expensive for large datasets. Since this embodiment focuses on the single-threaded nature of the index engine, range queries don't need to consider read-read concurrency or read-write concurrency scenarios, and directly adopt the classic R-tree design: given a query rectangle Q, find all data rectangles that intersect with it. The query starts from the root node. For each entry (R, ptr) in an internal node, if R intersects Q, the query recursively proceeds to the child nodes pointed to by ptr. When a leaf node is reached, it tests whether Q intersects with the data rectangles in each data entry and returns the intersecting data entries. This process is recursively executed until returning from the root node level, at which point all results satisfying the conditions have been found.

[0120] Implementation Method 8, see below Figure 11 This embodiment describes the size of the leaf node metadata as described in Embodiment 1.

[0121] To overcome the node metadata size limitation imposed by 8-byte NVM atomic writes, allowing users to set more entry slots in a single node, reducing DRAM usage, and further optimizing insertion performance, the index engine in this embodiment also supports multi-word metadata (one word is 8 bytes in a 64-bit machine) through a shared-byte design. The integrated leaf node internal structure is as follows: Figure 11 As shown, each pair of words in the multi-word metadata shares one byte. This byte contains two 1-bit spl and mer flags to indicate the metadata update progress during the split and merge processes, respectively. The remaining 6 bits are used normally as a bitmap. The main body of the split and merge process remains unchanged, but the metadata update needs to be performed word by word. In addition to setting the bitmap normally, the corresponding bits of the shared bytes contained in the word are also flipped.

[0122] Taking the splitting process as an example, the metadata update of the old leaf node starts with WordA. Through a single 8-byte NVM atomic write, the bitmap update within WordA and the spl flag being set to 1 are completed atomically and simultaneously. Subsequently, the updates of Word B and other intermediate words involve two spl flag bits in the two shared bytes before and after. Again, a single 8-byte NVM atomic write can set the first spl flag to 0 while the second spl flag is set to 1. When updating the last word, WordN, simply setting the spl flag of its first byte to 0 indicates that a split is complete. If a system crash or unexpected power outage occurs midway, only one flag bit will be 1. Therefore, upon recovery, the interruption point can be quickly located by using the 1-bit flag, and the splitting or merging process can be continued by referring to another node.

[0123] Implementation Method Nine, see below Figure 12 This embodiment describes an efficient fault recovery method implemented using an R-tree spatial index design method for a DRAM-NVM hybrid memory architecture, as described in any of the above embodiments. The fault recovery method specifically includes:

[0124] The non-volatility of NVM is the hardware-layer foundation for fault recovery in pure NVM architectures and various novel systems under DRAM-NVM architectures, and the hybrid R-tree space index engine is no exception. The design and implementation guarantee the eventual consistency of the persistent linked list of leaf nodes in NVM (i.e., the list is either consistent or has only recoverable inconsistencies). After a system crash or unexpected power outage and restart, this persistent linked list is needed to restore and rebuild a complete and consistent index structure. The macroscopic process of fault recovery is as follows: Figure 12 As shown.

[0125] Fault recovery consists of four specific stages:

[0126] Phase (1): NVM memory pool file mapping and parsing phase. The NVM layer data structure of the indexing engine is persistently stored on the NVM hardware medium in the form of memory pool files. When fault recovery begins, the corresponding memory pool file needs to be found and opened first through a pre-configured path hard-coded into the program, so as to directly map it into the program's virtual address space without caching. Using the macro functions provided by PMDK to parse the root object at a fixed offset in the memory pool, the starting offset of the persistent leaf node linked list in the pool can be obtained.

[0127] Phase (2): Leaf Node Persistent Linked List Consistency Repair Phase. This phase involves forward traversal of the leaf node linked list, checking each leaf node and making necessary modifications to ensure the list is consistent. If a node's del flag is set to 1, its dptr must point to a failed but not yet released node. In this case, the predecessor and successor nodes of the failed node should be linked together, the del flag should be set to 0, and the failed node should be released. In addition, incomplete splits and merges may not update the node's prev pointer, but all next pointers are always valid, so an incorrect prev pointer can be pointed to the last visited node. For scenarios where multi-word metadata extension is enabled, the spl and mer flags in each word of the leaf node metadata need to be checked. If a flag set to 1 is found, the bit in the bitmap should be compared with another related node (reachable via next or dptr) starting from the current word, and the split or merge process should continue.

[0128] Phase (3): Leaf Node Compilation Phase. After Phase (2) is completed, the persistent leaf node list can be considered to be in a consistent state, containing valid leaf nodes that are bidirectionally linked. This phase requires traversing the list again, calculating the MBR of each node, and combining the MBR with the node's offset in the pool to obtain the entry to be inserted into the bottom-level inner node. It is these index entries that establish the access bridge between DRAM and NVM.

[0129] Phase (4): DRAM Layer Index Structure Reconstruction Phase. This phase uses entries to construct a relatively small R-tree index structure in DRAM. Ignoring the complete index structure of the index engine, the portion in DRAM is essentially an R-tree index. The structure reconstruction is completed by creating an empty internal node in DRAM as the new index tree and inserting entries one by one into it.

[0130] Since leaf nodes in NVM typically hold at least dozens of entries, DRAM write latency is significantly lower than that of NVM, and all operations are performed in-place without persistence. Therefore, the time overhead for index engine failure recovery is theoretically much lower than rebuilding the complete index using the original dataset.

[0131] Implementation Method 10, see below Figures 13 to 16 This embodiment describes a test experiment to verify the R-tree spatial index design method for DRAM-NVM hybrid storage architecture described in the above embodiment.

[0132] All comparative experiments were conducted on a real server platform, and the specific platform configuration is shown in Table 1.

[0133] Table 1

[0134]

[0135] The experiments primarily use two datasets: Wroclaw and Synthetic, as described below:

[0136] (1) Wroclaw public transport (Wroclaw): A two-dimensional point dataset containing GPS location data of public transport vehicles in Wroclaw, Poland, from April 13, 2022 to April 30, 2022, totaling approximately 25,700,000 records. The first 25,000,000 records were actually extracted in the test.

[0137] (2) Synthetic dataset: A three-dimensional point dataset containing 1,000,000,000 randomly distributed generated data points, with all three dimensions of the data uniformly sampled from the interval (0, 100000).

[0138] For the two datasets mentioned above, in order to simulate the user's real query request, the query rectangles are obtained by randomly shifting each dimension boundary by normal distribution using a portion of the data as the base value.

[0139] The Wroclaw dataset will primarily be used to test the impact of changes in index tree size and bitmap size on the single-threaded insertion and query performance of each index engine instance, respectively; the Synthetic dataset will be used to impose a larger workload on each instance, forcing each instance to maintain a larger-scale index structure.

[0140] The experiment used the FBR-Tree (Failure-atomic Byte-addressable R-Tree) as a comparison object. It is the current state-of-the-art R-tree with fault atoms and byte-addressable structure under pure NVM architecture. The read and write performance of the two indexes were measured under different scales and bitmap size settings.

[0141] Insertion performance verification:

[0142] Figure 13This demonstrates how the insertion throughput of each indexing engine changes as the index tree size increases. In this set of experiments, this embodiment uses 20%–100% of the Wroclaw dataset and 0.1%–100% of the Synthetic dataset to construct index structures with a fixed bitmap size of 55. On both datasets, HR-Tree significantly outperforms FBR-Tree, achieving speeds of 1.9–2.2 times and 1.5–1.7 times respectively. This indicates that the DRAM-NVM architecture does indeed offer a certain write performance advantage compared to the pure NVM architecture. Overall, on the Wroclaw dataset, the performance of each indexing engine is relatively stable, which is because the dataset size is relatively small and the number of index tree levels does not change significantly. For the Synthetic dataset, as the index tree size increases, the number of index tree levels continuously increases, and the more levels there are, the longer the traversal time, resulting in a performance decrease.

[0143] In another set of insertion performance evaluation experiments, with the index tree size fixed at 100%, the bitmap size was adjusted to 55, 116, 170, and 224 respectively. The results are as follows: Figure 14 As shown, HR-Tree's insertion throughput on the Wroclaw and Synthetic datasets is 1.6–2.0 times and 1.4–1.7 times that of FBR-Tree, respectively. With increasing bitmap size, the insertion performance of all indexing engines exhibits the same decreasing trend, because the node splitting cost for each indexing engine is proportional to the square of the bitmap size.

[0144] Query performance verification:

[0145] Figure 15 The impact of index tree size changes on the query throughput of each indexing engine is shown (with the bitmap size also fixed at 55). As the index tree size increases, the query performance of the indexing engines gradually degrades, and the trend is basically consistent. In addition, the query performance of HR-Tree is slightly higher than that of FBR-Tree. On the two datasets, the average query throughput of HR-Tree is approximately 1.5 times and 1.1 times that of FBR-Tree, respectively.

[0146] Figure 16 The effect of bitmap size variation on query throughput of each index engine is shown (index tree size is fixed at 100%). It can be seen that HR-Tree's query performance is slightly higher than FBR-Tree under all four bitmap sizes.

[0147] In summary, this embodiment conducted multiple comparative experiments on HR-Tree and the current state-of-the-art design FBR-Tree to comprehensively evaluate the performance of HR-Tree and provide a brief analysis. The experimental results show that HR-Tree exhibits a significant advantage in insertion performance, while also slightly improving query performance, and can meet the practical needs of scenarios with fewer reads and more writes.

[0148] The above description is merely an embodiment of the present invention and is not limited to the present invention. For those skilled in the art, the present invention proposes a write-optimized space index HR-Tree under a DRAM-NVM hybrid architecture. Its core design idea is to deploy internal nodes on DRAM, place leaf nodes on NVM, and design targeted data read and write operation processes, ultimately achieving a significant insertion performance advantage. This idea can also be used for other storage engines with similar hierarchical architectures under the same storage architecture.

[0149] In the foregoing description, specific details such as particular system architectures and techniques have been set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application can also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted to avoid unnecessary detail that could obscure the description of this application.

Claims

1. A method for designing R-tree spatial indexes for DRAM-NVM hybrid memory architectures, characterized in that, The method is as follows: Step 1: Build the internal modules of the R tree index engine; Step 2: Store the internal nodes and leaf nodes in the DRAM and NVM of the index engine's internal module, respectively; Step 3: Through structural design of the leaf nodes, all leaf nodes form a persistent linked list; Step 4: Based on the above design, complete the data update and data query.

2. The R-tree spatial index design method for DRAM-NVM hybrid memory architecture according to claim 1, characterized in that, The R-tree indexing engine internal modules include DRAM & NVM memory management components, a basic configuration and data structure layer, an internal index operation layer, and an external interface layer. The DRAM & NVM memory management component provides a standardized memory allocation and deallocation API for DRAM and NVM. The configuration and data structure layer is used to load the personalized configuration when this engine is deployed, and also to maintain all data structures during engine operation and call the memory allocation and release API at any time; The internal operation layer of the index is used to perform insertion, deletion, and query, and to execute node splitting, merging, and redistribution; The external interface layer is used to provide users with insertion, deletion, and query functions by calling the internal operation layer of the index downwards and analyzing and presenting the returned results.

3. The R-tree spatial index design method for DRAM-NVM hybrid memory architecture according to claim 2, characterized in that, Step 3 specifically involves: Compared to internal nodes, leaf nodes have two additional flag bits and four 8-byte pointers. The four 8-byte pointers are the alternative pointers next0 and next1, and the predecessor pointers prev and dptr. The metadata for each leaf node consists of a bitmap organized by two tag bits, alt and del, and the remaining bits.

4. The R-tree spatial index design method for DRAM-NVM hybrid memory architecture according to claim 3, characterized in that, The alt flag bit is used to indicate a valid successor pointer; The marker bit del is used to indicate whether the current dptr is valid; A valid dptr points to a leaf node that is about to be released after the merge is complete but has not yet been released; The predecessor pointer `prev` always points to the predecessor node of the current node.

5. The R-tree spatial index design method for DRAM-NVM hybrid memory architecture according to claim 4, characterized in that, Data updates include insertion and deletion; The insertion operation is as follows: Step 1: Determine the insertion path from top to bottom based on the minimum expansion strategy, and expand the corresponding MBR in each internal node on the path; Step 2: Write the new entry to the corresponding leaf node in NVM, and ensure that the new entry is completely written through a persistence operation; Step 3: After confirming that the new entry has been written correctly, set the corresponding bit in the leaf node bitmap to make the new entry effective, and then perform another persistence operation to ensure that the bitmap has been updated; The deletion operation is as follows: Step 1: Locate the node containing the deleted entry from top to bottom; Step 2: Set the corresponding bit in the bitmap of the node to 0 to invalidate the entry to be deleted, and use a persistence operation to ensure that the bitmap has been updated; Step 3: Shrink the MBR corresponding to each internal node on the deletion path from bottom to top.

6. The R-tree spatial index design method for DRAM-NVM hybrid memory architecture according to claim 5, characterized in that, Leaf node splitting in NVM is implemented using a leaf node splitting method with consistency guarantees; Leaf node merging in NVM is achieved by using the del flag and dptr in the leaf nodes.

7. The R-tree spatial index design method for DRAM-NVM hybrid memory architecture according to claim 5, characterized in that, Multi-word metadata for leaf nodes is designed using shared bytes.

8. The efficient fault recovery method implemented by the R-tree space index design method for DRAM-NVM hybrid memory architecture as described in any one of claims 1-7, characterized in that, The method is as follows: NVM memory pool file mapping and parsing phase: The NVM layer data structure of the indexing engine is persistently stored on the NVM hardware medium in the form of a memory pool file; when fault recovery begins, the corresponding memory pool file needs to be found and opened through a pre-configured and hard-coded path in the program, so as to directly map it into the program's virtual address space without caching; using the macro functions provided by PMDK to parse the root object at a fixed offset in the memory pool, the starting offset of the persistent leaf node linked list in the pool can be obtained; Leaf node persistent linked list consistency repair phase: Forward traverse the leaf node linked list, check each leaf node and modify it to ensure that the linked list is consistent; Leaf node sorting phase: Traverse the linked list again, calculate the MBR of each node, and combine the MBR with the offset of the node in the pool to obtain the entry to be inserted into the bottom inner node. DRAM layer index structure reconstruction stage: Use entries to build an R-tree index structure in DRAM; the structure reconstruction is completed by creating an empty internal node in DRAM as a new index tree and inserting entries one by one into it.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, performs an R-tree space index design method for a DRAM-NVM hybrid storage architecture as described in any one of claims 1-7.

10. A computer device, characterized in that, The device includes a memory and a processor, wherein the memory stores a computer program, and when the processor runs the computer program stored in the memory, the processor executes an R-tree space index design method for a DRAM-NVM hybrid memory architecture as described in any one of claims 1-7.