Graph database storage method and device based on Hash mapping, equipment and medium

Abstract

The invention discloses a graph database storage method, device and equipment based on Hash mapping and a medium, a graph database comprises a storage engine, the storage engine comprises a plurality of storage areas which are arranged on a disk and are mutually independent in logic, and the storage areas comprise Hash index areas. The Hash index area comprises a storage file managed by a Hash index structure, and the method comprises the following steps: adding a write-in request for the graph database into a pre-write log queue; analyzing the write-in statement to obtain write-in statement data; inserting to-be-written data into a variable hash table in a memory through log structured merging-hash; and when the table is full of data, writing the storage data into an immutable storage file on the disk layer by layer. According to the embodiment of the invention, the performance is stable and predictable; high write throughput is kept; the efficiency of complex traversal query is greatly improved; efficient storage of the storage structure is achieved, and efficient support of point and edge query and traversal operation under a graph data model is achieved.

Description

Technical Field

[0001] This application relates to the field of computer data storage technology, and in particular to a graph database storage method, apparatus, device and medium based on hash mapping. Background Technology

[0002] Currently, many graph databases are built on top of general-purpose key-value storage engines. These engines (such as those based on B+ trees) are typically used to maintain the order of data to support efficient range queries. A graph is an important data structure widely used in data storage across various fields, including finance and commerce. Graph data generally consists of nodes (vertices) and edges connecting them. Nodes (or vertices) represent entities, and edges represent relationships between nodes. Typically, the core operations of graph databases are: retrieving attributes by vertex ID (gV(id)) or retrieving outgoing edges by vertex ID (gV(id).outE()), which are essentially precise vertex queries based on unique identifiers.

[0003] In related technologies, even with indexes, exact lookups cannot avoid the overhead of binary search with a time complexity of O(log N) in ordered storage structures. This overhead becomes a bottleneck restricting query latency, especially when the data volume of graph databases is large. In addition, traditional update-in-place storage engines not only suffer from high disk seek costs when dealing with frequent random writes, but also have the disadvantage of poor write performance, resulting in problems such as excessively long query paths and limited write throughput.

[0004] In view of this, there is a need to provide a storage solution specifically designed for graph data access patterns in order to solve the problems existing in related technologies. Summary of the Invention

[0005] The embodiments of this application adopt the following technical solutions: This application provides a graph database storage method based on hash mapping. The graph database includes a storage engine, which includes several logically independent storage areas located on a disk. Each storage area includes a hash index area, which includes storage files managed by a hash index structure. The method includes: In response to a write request for the graph database, the write request is added to the write-ahead log queue; The write statement contained in the write request is parsed to obtain the data to be written contained in the write statement; The data to be written is inserted into a variable hash table in memory using Log Structured Merge-Hash (LSM-Hash). When the variable hash table in memory is full of data, the stored data of the variable hash table is written layer by layer to an immutable disk file on the disk.

[0006] In some embodiments, the plurality of storage areas further include a data area, and the method further includes: The data compression and processing (Compaction) process on the backend server merges several small files into one large file; wherein the several small files include the immutable disk files; Obtain a target key set after merging the several small files; wherein the target key set contains at least one key, the at least one key is used to indicate the storage location of the data of the storage file in the data area, and N is a positive integer greater than 1; Based on the target key set, a perfect hash function is constructed, and the constructed perfect hash function is used as the index of the large file; Reclaim the aforementioned small files and their indexes.

[0007] In some embodiments, a perfect hash function is constructed based on the target key set, and the constructed perfect hash function is used as the index of the large file, including: When merging the several small files through the Compaction process, a perfect hash function is dynamically calculated and constructed based on the set of valid IDs contained in the large file obtained by merging through the Compaction process; wherein, the set of valid IDs includes the node ID, edge ID, or source node ID of the large file; The perfect hash function and the corresponding data storage location information obtained through the target key set are stored as the metadata index of the large file.

[0008] In some embodiments, the graph database further includes a query engine, and the method further includes: In response to a query request for the graph database, the query statement contained in the query request is parsed to obtain at least one query ID contained in the query statement; The query engine searches for candidate disk files that may contain the query ID. For each candidate disk file that may contain the query ID, load the perfect hash function for each candidate disk file; Calculate the hash value of the query ID contained in each of the candidate disk files based on the perfect hash function of each candidate disk file; Based on the calculated hash value of the query ID, determine the bucket location information of the data bucket in the candidate disk file; Based on the offset of the bucket location information, the target node, target edge, or target adjacency list contained in the target data block are directly read.

[0009] In some embodiments, the storage file includes a point storage file for storing attribute data of each node, an edge storage file for storing attribute data of each edge, or an adjacency list storage file for storing the outgoing edge list of each point. In this context, nodes represent entities, edges represent relationships between nodes, each node and edge has several attribute information, and multiple nodes or edges with the same several attribute information are stored in the same data block. The storage engine maintains tag information corresponding to each data block, and the tag information is used to describe the same several attribute information possessed by multiple nodes or edges contained in the data block.

[0010] In some embodiments, the format of each of the stored files includes: The key, which is a composite key, includes: a 64-bit globally unique identifier for a point or edge, and the starting byte offset of the target data in the storage file; Values, used to represent serialized data records, include: The values ​​of the point storage file are used to represent the set of attributes of the node; The values ​​in the edge storage file are used to represent the set of attributes of the edge; The adjacency list stores the values ​​of the file, which contains a data block with a fixed format.

[0011] In some embodiments, the data block includes a source node ID, the number of output edges of the source node, and a continuous list, wherein each item in the continuous list contains a target node ID and an edge ID connecting the source node and the target node, and the edge ID is used to quickly locate detailed information about the edge in the edge storage file.

[0012] This application embodiment also provides a graph database storage device based on hash mapping. The graph database includes a storage engine, and the storage engine includes several logically independent storage areas disposed on a disk. The several storage areas include a hash index area, and the hash index area includes storage files managed by a hash index structure. The device includes: The response unit is configured to add the write request to the write-ahead log queue in response to a write request for the graph database. The parsing unit is configured to parse the write statement contained in the write request to obtain the data to be written contained in the write statement; The insertion unit is configured to insert the data to be written into a variable hash table in memory via Log Structured Merge-Hash (LSM-Hash); The write unit is configured to write the stored data of the variable hash table to an immutable disk file on the disk layer by layer when the variable hash table in the memory is full of data.

[0013] This application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements any of the methods described above.

[0014] This application also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable by the processor, wherein the processor executes the computer program to implement any of the methods described above.

[0015] The above-described technical solutions adopted in the embodiments of this application can achieve the following beneficial effects: This application provides a graph database storage method based on hash mapping. By introducing a perfect hash index, it achieves O(1) time complexity for querying points, edges, and adjacency lists in the worst case, with stable and predictable performance, outperforming traditional hash and Bloom filter schemes. It adopts a log structured merge-hash (LSM-Hash) architecture, converting random writes into sequential writes and maintaining high write throughput. By separating and logically independent storing adjacency lists and edge attribute data, multiple-hop queries only require a single I / O operation to obtain all neighboring edge IDs of a point, avoiding the read amplification problem caused by querying attributes separately for each edge in traditional methods. This optimizes multi-hop query performance and significantly improves the efficiency of complex traversal queries. Separating the storage files for points, edges, and adjacency lists conforms to the natural form of graph data, achieving efficient storage of the storage structure. Optimizing the data layout and index structure through the storage engine enables efficient support for point and edge query and traversal operations under the graph data model. Attached Figure Description

[0016] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings: Figure 1 This application provides a flowchart illustrating a graph database storage method based on hash mapping. Figure 2 This application provides a schematic diagram of the structure of a graph database storage device based on hash mapping. Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0017] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of them. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0018] The technical solutions provided by the various embodiments of this application are described in detail below with reference to the accompanying drawings.

[0019] See Figure 1 , Figure 1 This is a flowchart illustrating a graph database storage method based on hash mapping provided in an embodiment of this application. The graph database includes a storage engine, which comprises several logically independent storage areas located on a disk. Each storage area includes a hash index area, which includes storage files managed by a hash index structure. The method includes: S101. In response to a write request for the graph database, the write request is added to the write-ahead log queue.

[0020] This application primarily focuses on the design and implementation of a persistent storage engine for graph databases. This persistent storage engine optimizes data layout and index structure to efficiently support vertex and edge queries and traversals within a graph data model. The persistent storage engine can include a storage engine and a query engine. The storage engine maintains three logically independent storage areas on the disk, each implemented as a storage file managed by a hash index: a vertex storage file, an edge storage file, and an adjacency list storage file.

[0021] Graph databases are databases that use graph structures (including vertices, edges, and attributes) for data modeling and querying; persistent storage refers to the process of permanently storing data on non-volatile storage media (such as hard disks and solid-state drives).

[0022] S102. Parse the write statement contained in the write request to obtain the data to be written contained in the write statement.

[0023] S103. Insert the data to be written into a variable hash table in memory using Log Structured Merge-Hash (LSM-Hash).

[0024] Log Structured Merge-Hash (LSM-Hash) represents a storage architecture inspired by the Log Structured Merge Tree (LSM-Tree). It writes data to memory and logs first, then flushes it sequentially to disk, and merges the disk files through a backend server. However, the underlying data organization and indexing are based on hash mapping rather than sorting trees.

[0025] A hash map is a data structure that uses a hash function to map keys to storage locations, thereby enabling fast access.

[0026] S104. When the variable hash table in the memory is full of data, the stored data of the variable hash table is written layer by layer to the immutable disk file on the disk.

[0027] This application provides a graph database storage method based on hash mapping. By introducing a perfect hash index, it achieves O(1) time complexity for querying points, edges, and adjacency lists in the worst case, with stable and predictable performance, outperforming traditional hash and Bloom filter schemes. It adopts a log structured merge-hash (LSM-Hash) architecture, converting random writes into sequential writes and maintaining high write throughput. By separating and logically independent storing adjacency lists and edge attribute data, multiple-hop queries only require a single I / O operation to obtain all neighboring edge IDs of a point, avoiding the read amplification problem caused by querying attributes separately for each edge in traditional methods. This optimizes multi-hop query performance and significantly improves the efficiency of complex traversal queries. Separating the storage files for points, edges, and adjacency lists conforms to the natural form of graph data, achieving efficient storage of the storage structure. Optimizing the data layout and index structure through the storage engine enables efficient support for point and edge query and traversal operations under the graph data model.

[0028] In some embodiments, the plurality of storage areas further include a data area, and the method further includes: The data compression and processing (Compaction) process on the backend server merges several small files into one large file; wherein the several small files include the immutable disk files; Obtain a target key set after merging the several small files; wherein the target key set contains at least one key, the at least one key is used to indicate the storage location of the data of the storage file in the data area, and N is a positive integer greater than 1; Based on the target key set, a perfect hash function is constructed, and the constructed perfect hash function is used as the index of the large file; Reclaim the aforementioned small files and their indexes.

[0029] Optionally, the data compression and sorting process refers to the background process in the Log Structured Merge-Hash (LSM-Hash) architecture that merges multiple old data files (small files in this embodiment) and cleans up expired data to optimize read performance and storage space.

[0030] In some embodiments, a perfect hash function is constructed based on the target key set, and the constructed perfect hash function is used as the index of the large file, including: When merging the several small files through the Compaction process, a perfect hash function is dynamically calculated and constructed based on the set of valid IDs contained in the large file obtained by merging through the Compaction process; wherein, the set of valid IDs includes the node ID, edge ID, or source node ID of the large file; The perfect hash function and the corresponding data storage location information obtained through the target key set are stored as the metadata index of the large file.

[0031] Optionally, a perfect hash function refers to a hash function designed for a specific set of keys during construction. This function guarantees that there will be no collisions for any of the keys in the set and can achieve O(1) lookup in the worst case.

[0032] This application embodiment achieves optimal balance between read and write performance through automated high-performance index management: the background compaction thread not only manages storage space, but also automatically generates the best perfect hash index for each generation of data files.

[0033] In some embodiments, the graph database further includes a query engine, and the method further includes: In response to a query request for the graph database, the query statement contained in the query request is parsed to obtain at least one query ID contained in the query statement; The query engine searches for candidate disk files that may contain the query ID. For each candidate disk file that may contain the query ID, load the perfect hash function for each candidate disk file; Calculate the hash value of the query ID contained in each of the candidate disk files based on the perfect hash function of each candidate disk file; Based on the calculated hash value of the query ID, determine the bucket location information of the data bucket in the candidate disk file; Based on the offset of the bucket location information, the target node, target edge, or target adjacency list contained in the target data block are directly read.

[0034] The embodiments of this application achieve an exact lookup with a worst-case time complexity of O(1), completely eliminating the collision overhead of traditional hash tables and the false positive rate of Bloom filters.

[0035] This application embodiment separates the adjacency list from the edge data, eliminating the need to immediately load detailed edge attributes when querying the adjacency relationship of a point. This reduces read amplification overhead during multi-hop queries, thereby improving the performance of graph traversal queries. Its data writing process employs an LSM-Hash architecture, including a write-ahead log, an in-memory hash table, and disk files. A background compaction process manages the disk files and builds the corresponding perfect hash index.

[0036] In some embodiments, the storage file includes a point storage file for storing attribute data of each node, an edge storage file for storing attribute data of each edge, or an adjacency list storage file for storing the outgoing edge list of each point. In this context, nodes represent entities, edges represent relationships between nodes, each node and edge has several attribute information, and multiple nodes or edges with the same several attribute information are stored in the same data block. The storage engine maintains tag information corresponding to each data block, and the tag information is used to describe the same several attribute information possessed by multiple nodes or edges contained in the data block.

[0037] In some embodiments, the format of each of the stored files includes: The bond, the structure of which is a compound bond, has the following structure:<id,offset> id represents a 64-bit globally unique identifier for a point or edge, and offset represents the starting byte offset of the target data in the storage file; Values, used to represent serialized data records, include: The values ​​of the point storage file are used to represent the set of attributes of the node; The values ​​in the edge storage file are used to represent the set of attributes of the edge; The adjacency list stores the values ​​of the file, which contains a data block with a fixed format.

[0038] Optionally, for example, the value of the vertex storage file is represented as {name: "Alice", age: 30}; the value of the edge storage file usually represents the set of attributes of the edge, typically including the source vertex ID and the target vertex ID (e.g., {weight: 0.5, from: 123, to: 456}); the value of the adjacency list storage file is represented as a data block with a fixed format, and the structure of this database is {src_id, list_size, [dst_id, edge_id]+}. Here, src_id represents the source vertex ID; list_size represents the number of output edges from the source vertex; [dst_id, edge_id]+ represents a continuous list, each item containing the target vertex ID dst_id and the edge ID edge_id connecting the two vertices. The edge_id allows for quick location of detailed edge information in the edge storage file.

[0039] In some embodiments, the data block includes a source node ID, the number of output edges of the source node, and a continuous list, wherein each item in the continuous list contains a target node ID and an edge ID connecting the source node and the target node, and the edge ID is used to quickly locate detailed information about the edge in the edge storage file.

[0040] See Figure 2 , Figure 2 This application provides a schematic diagram of the structure of a graph database storage device based on hash mapping, and further provides a graph database storage device based on hash mapping. The graph database includes a storage engine, which includes several logically independent storage areas disposed on a disk. Each storage area includes a hash index area, which includes storage files managed by a hash index structure. The device includes: Response unit 21 is configured to add the write request to the write-ahead log queue in response to a write request for the graph database. The parsing unit 22 is configured to parse the write statement contained in the write request to obtain the data to be written contained in the write statement; Insertion unit 23 is configured to insert the data to be written into a variable hash table in memory via Log Structured Merge-Hash (LSM-Hash); The writing unit 24 is configured to write the stored data of the variable hash table to an immutable disk file on the disk layer by layer when the variable hash table in the memory is full of data.

[0041] It should be noted that the execution subject of each step of the method provided in this application embodiment can be the same device, or the method can be executed by different devices. For example, the execution subject of steps S101 and S102 can be device 1, and the execution subject of step S103 can be device 2; or the execution subject of step S101 can be device 1, and the execution subject of steps S102 and S103 can be device 2; and so on.

[0042] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0043] Therefore, this application also proposes a computer-readable storage medium having a computer program stored thereon that, when executed by a processor, implements the methods described in any embodiment of this application.

[0044] Furthermore, this application also proposes an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the method described in any embodiment of this application.

[0045] This application provides an electronic device. Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. For example... Figure 3 As shown, this embodiment provides an electronic device 300, which includes: one or more processors 320; and a storage device 310 for storing one or more programs. When the one or more programs are run by the one or more processors 320, the one or more processors 320 implement the graph database storage method based on hash mapping provided in this application embodiment. The graph database includes a storage engine, and the storage engine includes several logically independent storage areas disposed on a disk. The several storage areas include a hash index area, and the hash index area includes storage files managed by a hash index structure. The method includes: In response to a write request for the graph database, the write request is added to the write-ahead log queue; The write statement contained in the write request is parsed to obtain the data to be written contained in the write statement; The data to be written is inserted into a variable hash table in memory using Log Structured Merge-Hash (LSM-Hash). When the variable hash table in memory is full of data, the stored data of the variable hash table is written layer by layer to the immutable storage file on the disk.

[0046] Figure 3 The electronic device 300 shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0047] like Figure 3 As shown, the electronic device 300 includes a processor 320, a storage device 310, an input device 330, and an output device 340; the number of processors 320 in the electronic device can be one or more. Figure 3 Taking a processor 320 as an example; the processor 320, storage device 310, input device 330, and output device 340 in the electronic device can be connected via a bus or other means. Figure 3 Taking the connection between China and Israel via bus 350 as an example.

[0048] Storage device 310, as a computer-readable storage medium, can be used to store software programs, computer-executable programs, and module units, such as program instructions corresponding to a graph database storage method based on hash mapping in an embodiment of this application.

[0049] Storage device 310 may primarily include a program storage area and a data storage area. The program storage area may store the operating system and at least one application program required for a function; the data storage area may store data created based on terminal usage. Furthermore, storage device 310 may include high-speed random access memory and non-volatile memory, such as at least one disk storage device, flash memory device, or other non-volatile solid-state storage device. In some instances, storage device 310 may further include memory remotely located relative to processor 320, and these remote memories can be connected via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0050] Input device 330 can be used to receive input digital, character, or voice information, and to generate key signal inputs related to user settings and function control of the electronic device. Output device 340 may include electronic devices such as a display screen and a speaker.

[0051] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0052] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0053] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0054] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0055] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0056] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0057] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0058] The above description is merely an embodiment of this application and is not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A graph database storage method based on hash mapping, characterized in that, The graph database includes a storage engine, which comprises several logically independent storage areas located on a disk. Each storage area includes a hash index area, which includes storage files managed by a hash index structure. The method includes: In response to a write request for the graph database, the write request is added to the write-ahead log queue; The write statement contained in the write request is parsed to obtain the data to be written contained in the write statement; The data to be written is inserted into a variable hash table in memory using Log Structured Merge-Hash (LSM-Hash). When the variable hash table in memory is full of data, the stored data of the variable hash table is written layer by layer to an immutable disk file on the disk.

2. The graph database storage method based on hash mapping according to claim 1, characterized in that, The plurality of storage areas further includes a data area, and the method further includes: The data compression and processing (Compaction) process on the backend server merges several small files into one large file; wherein, the several small files include the immutable disk files; Obtain a target key set after merging the several small files; wherein the target key set contains at least one key, the at least one key is used to indicate the storage location of the data of the storage file in the data area, and N is a positive integer greater than 1; Based on the target key set, a perfect hash function is constructed, and the constructed perfect hash function is used as the index of the large file; Reclaim the aforementioned small files and their indexes.

3. The graph database storage method based on hash mapping according to claim 2, characterized in that, Based on the target key set, a perfect hash function is constructed, and the constructed perfect hash function is used as the index of the large file, including: When merging the several small files through the Compaction process, a perfect hash function is dynamically calculated and constructed based on the set of valid IDs contained in the large file obtained by merging through the Compaction process; wherein, the set of valid IDs includes the node ID, edge ID, or source node ID of the large file; The perfect hash function and the corresponding data storage location information obtained through the target key set are stored as the metadata index of the large file.

4. The graph database storage method based on hash mapping according to claim 3, characterized in that, The graph database also includes a query engine, and the method further includes: In response to a query request for the graph database, the query statement contained in the query request is parsed to obtain at least one query ID contained in the query statement; The query engine searches for candidate disk files that may contain the query ID. For each candidate disk file that may contain the query ID, load the perfect hash function for each candidate disk file; Calculate the hash value of the query ID contained in each of the candidate disk files based on the perfect hash function of each candidate disk file; Based on the calculated hash value of the query ID, determine the bucket location information of the data bucket in the candidate disk file; Based on the offset of the bucket location information, the target node, target edge, or target adjacency list contained in the target data block are directly read.

5. The graph database storage method based on hash mapping according to claim 1, characterized in that, The storage files include a point storage file for storing the attribute data of each node, an edge storage file for storing the attribute data of each edge, or an adjacency list storage file for storing the outgoing edge list of each point. In this context, nodes represent entities, edges represent relationships between nodes, each node and edge has several attribute information, and multiple nodes or edges with the same several attribute information are stored in the same data block. The storage engine maintains tag information corresponding to each data block, and the tag information is used to describe the same several attribute information possessed by multiple nodes or edges contained in the data block.

6. The graph database storage method based on hash mapping according to claim 5, characterized in that, The format of each of the stored files includes: The key, which is a composite key, includes: a 64-bit globally unique identifier for a point or edge, and the starting byte offset of the target data in the storage file; Values, used to represent serialized data records, include: The values ​​of the point storage file are used to represent the set of attributes of the node; The values ​​in the edge storage file are used to represent the set of attributes of the edge; The adjacency list stores the values ​​of the file, which contains a data block with a fixed format.

7. The graph database storage method based on hash mapping according to claim 6, characterized in that, The data block includes a source node ID, the number of output edges of the source node, and a continuous list. Each item in the continuous list contains a target node ID and an edge ID connecting the source node and the target node. The edge ID is used to quickly locate detailed information about the edge in the edge storage file.

8. A graph database storage device based on hash mapping, characterized in that, The graph database includes a storage engine, which comprises several logically independent storage areas located on a disk. Each storage area includes a hash index area, which includes storage files managed by a hash index structure. The device includes: The response unit is configured to add the write request to the write-ahead log queue in response to a write request for the graph database. The parsing unit is configured to parse the write statement contained in the write request to obtain the data to be written contained in the write statement; The insertion unit is configured to insert the data to be written into a variable hash table in memory via Log Structured Merge-Hash (LSM-Hash); The write unit is configured to write the stored data of the variable hash table to an immutable disk file on the disk layer by layer when the variable hash table in the memory is full of data.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the method as described in any one of claims 1 to 7.

10. An electronic device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the method as described in any one of claims 1 to 7.

Images