Graph database management method, equipment, storage medium and system

Abstract

The invention relates to the technical field of graph databases, and discloses a graph database management method and device, a storage medium and a system.The method comprises the steps that when a partition engine switching request for a graph database is received, an old partition with a storage engine needing to be switched and a target engine type are determined according to the partition engine switching request, creating a new partition of a target engine type, traversing the graph data in the old partition through a storage engine corresponding to the old partition, importing the traversed graph data into the new partition through the storage engine of the target engine type, updating partition metadata information after the traversed graph data is completely imported, and deleting the old partition; due to the fact that the pluggable storage engine is achieved on the partition level, that is, each partition can be switched to the corresponding storage engine according to actual requirements, the utilization rate of hardware resources can be increased, and then the performance of the graph database can be improved.

Description

Technical Field

[0001] This application relates to the technical field of graph databases, and in particular, to a graph database management method, device, storage medium, and system. Background Art

[0002] A graph database is a data management system that uses points and edges as basic storage units and is designed to efficiently store and query graph data. A distributed graph database is a logically unified graph database formed by connecting multiple physically dispersed graph database units through a computer network, and has characteristics such as being distributed, scalable, and fault-tolerant. A distributed graph database usually includes a computing engine and a storage engine, and the storage engine is a key module for realizing efficient storage and query of points, edges, and attributes.

[0003] A multi-engine distributed graph database usually supports multiple storage engines at the entire system level. The storage engines are independent of each other and do not support switching between storage engines. Summary of the Invention

[0004] The main purpose of this application is to provide a graph database management method, device, storage medium, and system, aiming to solve the technical problem that a multi-engine distributed graph database usually supports multiple storage engines at the entire system level, the storage engines are independent of each other, and do not support switching between storage engines.

[0005] To achieve the above purpose, this application provides a graph database management method, and the graph database management method includes:

[0006] When receiving a partition engine switching request for the graph database, determining the old partition that needs to switch the storage engine and the target engine type according to the partition engine switching request;

[0007] Creating a new partition of the target engine type;

[0008] Traversing the graph data in the old partition through the storage engine corresponding to the old partition, and importing the traversed graph data into the new partition through the storage engine of the target engine type;

[0009] After the traversed graph data is imported, updating the partition metadata information and deleting the old partition.

[0010] Optionally, before the step of when receiving a partition engine switching request for the graph database and determining the old partition that needs to switch the storage engine and the target engine type according to the partition engine switching request, it further includes:

[0011] When receiving a graph creation request for the graph database, converting the graph creation request into a partition creation request;

[0012] Determine the partition information corresponding to the graph to be created and the storage engine type corresponding to each partition during partitioning according to the partition creation request;

[0013] Create each partition corresponding to the graph to be created through the storage engine of the storage engine type according to the partition information.

[0014] Optionally, the storage engine type includes: a preset storage engine type and / or a custom storage engine type; before converting the graph creation request into a partition creation request when receiving the graph creation request for the graph database, it further includes:

[0015] Obtain user requirement information, and load a preset storage engine of the preset storage engine type according to the user requirement information;

[0016] and / or, obtain engine dependency information, and load a custom storage engine of the custom storage engine type according to the engine dependency information.

[0017] Optionally, the obtaining engine dependency information and loading a custom storage engine of the custom storage engine type according to the engine dependency information includes:

[0018] Obtain engine dependency information, and build a pluggable storage engine layer according to the engine dependency information, and set a custom storage engine of the custom storage engine type in the pluggable storage engine layer;

[0019] Build a table interface layer according to the original interface of the custom storage engine, and the table interface layer provides table management interfaces and table data interfaces based on the pluggable storage engine layer to call the custom storage engine;

[0020] Design the storage structure of point-edge attributes according to the characteristics of the custom storage engine, and build a semantic layer according to the storage structure;

[0021] Assemble a partition interface layer based on the semantic layer to load the custom storage engine, the partition interface layer is used to receive external operations, the semantic layer connects the partition interface layer and the table interface layer, and the semantic layer is used to convert the external operations into operations on the table management interface and / or the table data interface.

[0022] Optionally, the creating each partition corresponding to the graph to be created through the storage engine of the storage engine type according to the partition information includes:

[0023] Obtain the hot and cold partition types and / or partition hardware resource types corresponding to each partition during partitioning from the partition information, and the hot and cold partition types include cold partitions or hot partitions;

[0024] Create each partition corresponding to the graph to be created through the storage engine of the storage engine type according to the cold and hot partition type and / or the partition hardware resource type.

[0025] Optionally, creating the new partition of the target engine type includes:

[0026] Obtain the cold and hot partition type of the new partition, where the cold and hot partition type includes a cold partition or a hot partition;

[0027] When the cold and hot partition type of the new partition is a cold partition, allocate hardware resources of the first performance to the new partition, and create the new partition of the target engine type based on the hardware resources of the first performance;

[0028] When the cold and hot partition type of the new partition is a hot partition, allocate hardware resources of the second performance to the new partition, and create the new partition of the target engine type based on the hardware resources of the second performance, where the second performance is higher than the first performance.

[0029] Optionally, the graph database management method further includes:

[0030] When receiving a graph deletion request for the graph database, determine the graph to be deleted according to the graph deletion request;

[0031] When the graph to be deleted exists in the graph database, generate a partition deletion request according to the target partition storing the graph to be deleted;

[0032] Delete the partition data corresponding to the graph to be deleted in the target partition through the storage engine corresponding to the target partition based on the partition deletion request.

[0033] Optionally, the graph database management method further includes:

[0034] When receiving a partition failover request for the graph database, determine the faulty partition according to the partition failover request, and elect a new primary partition from the replica partitions corresponding to the faulty partition;

[0035] During the election process, if it is detected that the number of replica partitions does not meet the preset availability requirement, create a new replica partition;

[0036] Import the graph data of the new primary partition into the new replica partition, and update the partition metadata information.

[0037] Optionally, the graph database management method further includes:

[0038] When receiving a graph data management request for the graph database, convert the graph data management request into a graph data management operation, where the graph data management request includes a graph data operation request and / or a graph data query request;

[0039] Obtain point-edge attribute storage structure information, and operate on the graph data in the storage engine according to the graph data management operation and the point-edge attribute storage structure information.

[0040] In addition, to achieve the above object, the present application also proposes a graph database management device, where the graph database management device includes a memory, a processor, and a graph database management program stored on the memory and executable on the processor, and the graph database management program is configured to implement the graph database management method as described above.

[0041] In addition, to achieve the above object, the present application also proposes a storage medium, where a graph database management program is stored on the storage medium, and when the graph database management program is executed by a processor, it implements the graph database management method as described above.

[0042] In addition, to achieve the above object, the present application also proposes a graph database management system, where the graph database management system includes a master control node, computing nodes, storage nodes, and at least two pluggable storage engines;

[0043] The master control node is configured to receive a graph management request sent by a client, convert the graph management request into a partition management request, and send the partition management request to the computing nodes, where the partition management request includes at least one of a partition engine switching request, a partition creation request, a partition deletion request, and a partition failover request;

[0044] The computing nodes are configured to, when the partition management request is a partition engine switching request for the graph database, determine an old partition that needs to switch the storage engine and a target engine type according to the partition engine switching request;

[0045] The storage nodes are configured to create a new partition of the target engine type, traverse the graph data in the old partition through the storage engine corresponding to the old partition, and import the traversed graph data into the new partition through the storage engine of the target engine type;

[0046] The master control node is further configured to update the partition metadata information and delete the old partition after the traversed graph data is imported.

[0047] In this application, it is disclosed that when a partition engine switching request for a graph database is received, the old partitions that need to switch the storage engine and the target engine type are determined according to the partition engine switching request, new partitions of the target engine type are created, the graph data in the old partitions is traversed through the storage engine corresponding to the old partitions, and the traversed graph data is imported into the new partitions through the storage engine of the target engine type. After the traversed graph data is imported, the partition metadata information is updated, and the old partitions are deleted; since this application realizes a pluggable storage engine at the partition level, that is, each partition can be switched to the corresponding storage engine according to actual needs, the utilization rate of hardware resources can be enhanced, and thus the performance of the graph database can be improved. Brief Description of the Drawings

[0048] Figure 1 is a schematic structural diagram of a graph database management device in the hardware operating environment involved in the solution of the embodiment of this application;

[0049] Figure 2 is a schematic flowchart of the first embodiment of the graph database management method of this application;

[0050] Figure 3 is an architecture diagram of the graph database management system of this application;

[0051] Figure 4 is a partition-level pluggable software architecture diagram of an embodiment of the graph database management method of this application;

[0052] Figure 5 is a schematic flowchart of the second embodiment of the graph database management method of this application;

[0053] Figure 6 is a schematic flowchart of the third embodiment of the graph database management method of this application;

[0054] Figure 7 is a schematic flowchart of the fourth embodiment of the graph database management method of this application;

[0055] Figure 8 is a schematic flowchart of the fifth embodiment of the graph database management method of this application.

[0056] The implementation, functional features and advantages of the purpose of this application will be further described with reference to the embodiments and the accompanying drawings. Detailed Embodiments

[0057] It should be understood that the specific embodiments described herein are only used to explain this application and are not used to limit this application.

[0058] Refer to Figure 1 , Figure 1 is a schematic structural diagram of a graph database management device in the hardware operating environment involved in the solution of the embodiment of this application.

[0059] As shown Figure 1 in the figure, the graph database management device may include: a processor 1001, such as a Central Processing Unit (CPU), a communication bus 1002, a user interface 1003, a network interface 1004, and a memory 1005. Among them, the communication bus 1002 is used to implement connection communication between these components. The user interface 1003 may include a display screen (Display). Optionally, the user interface 1003 may further include a standard wired interface and a wireless interface. For the wired interface of the user interface 1003, it may be a USB interface in this application. The network interface 1004 may optionally include a standard wired interface and a wireless interface (such as a Wireless-Fidelity (Wi-Fi) interface). The memory 1005 may be a high-speed Random Access Memory (RAM), or a stable memory (Non-volatile Memory, NVM), such as a disk memory. Optionally, the memory 1005 may also be a storage device independent of the aforementioned processor 1001.

[0060] Those skilled in the art can understand that Figure 1 the structure shown in the figure does not constitute a limitation on the graph database management device, and it may include more or fewer components than shown in the figure, or combine some components, or have different component arrangements.

[0061] As shown Figure 1 in the figure, the memory 1005 regarded as a computer storage medium may include an operating system, a network communication module, a user interface module, and a graph database management program.

[0062] In Figure 1 the graph database management device shown in the figure, the network interface 1004 is mainly used to connect to a background server and perform data communication with the background server; the user interface 1003 is mainly used to connect to a user device; the graph database management device calls the graph database management program stored in the memory 1005 through the processor 1001 and executes the graph database management method provided in the embodiments of the present application.

[0063] Based on the above hardware structure, an embodiment of the graph database management method of the present application is proposed.

[0064] Referring to Figure 2 , Figure 2 which is a schematic flowchart of the first embodiment of the graph database management method of the present application, the first embodiment of the graph database management method of the present application is proposed.

[0065] It should be understood that in the prior art, maintenance personnel need to frequently switch databases correspondingly to process data, which is very inconvenient and inefficient.

[0066] Related solutions verify operation instructions by using a database and a Data Definition Language (DDL) execution engine, enabling the DDL execution engine to successfully complete operations on data. It can process data stored on different storage engines without switching databases, simplifying operations and thus improving operation efficiency.

[0067] However, its drawback is that starting from the operation and maintenance scenario of multiple storage engines, only the database software supports operating multiple engines and the granularity is relatively coarse. It only considers the supportability and compatibility of multiple storage engines. The engines are independent of each other and do not support mutual switching between engines. Moreover, it mainly faces relational databases and only supports DDL, not Data Manipulation Language (DML) (i.e., it does not support operations such as adding, deleting, modifying, and querying table data content). The main operation types are table creation, deletion, or clearing, adding, deleting, clearing, or moving table partitions, and column deletion.

[0068] Therefore, to overcome the above defects, in this embodiment, a pluggable storage engine is implemented at the partition level, that is, each partition can be switched to the corresponding storage engine according to actual needs, thereby enhancing the utilization rate of hardware resources and further improving the performance of the graph database. Here, pluggable means that module independence and decoupling are achieved through abstract application programming interface design, making it possible to extend the framework or replace components.

[0069] In the first embodiment, the graph database management method includes:

[0070] Step S10: When receiving a partition engine switching request for the graph database, determine the old partition that needs to switch the storage engine and the target engine type according to the partition engine switching request.

[0071] It should be noted that the execution subject of this embodiment can be a graph database management device with data processing, network communication, and program running functions, such as a server cluster, or other electronic devices that can implement the same or similar functions. This embodiment does not limit this.

[0072] It can be understood that for the convenience of managing the graph database, in this embodiment, a graph database management system can be deployed on the server cluster. The graph database management method of this application can be implemented through the graph database management system. In specific implementation, for example, the graph database management system can be a distributed graph database system with a pluggable storage engine.

[0073] For ease of understanding, reference is made to Figure 3 for illustration, but this does not limit the present application. Figure 3 FIG. Figure 3 is an architecture diagram of a graph database management system according to an embodiment of the graph database management method of the present application. In the figure, the graph database management system includes, but is not limited to, a plurality of master control nodes, a plurality of computing nodes, and a plurality of storage nodes. Among them, the master control node is used to implement distributed control and graph management, the computing node is used to receive, parse, and execute user query statements, and the storage node is used to store and manage graph data information and provide query capabilities. In the figure, Leader is the main partition, Follower is the replica partition, SSD (Solid State Drive) is a solid-state drive, HDD (Hard Disk Drive) is a hard disk drive, MEM (Memory) usually refers to the memory in a computer and is also called random access memory (Random Access Memory, RAM), and RocksDB, LMDB, and Redis are storage engines.

[0074] It can be understood that the partition engine switching request can be initiated by the user to the master control node through the client, or can be automatically initiated by the master control node according to the actual requirements of the partition. This embodiment does not limit this. Determining the old partition that needs to switch the storage engine and the target engine type according to the partition engine switching request can be to parse the partition engine switching request to determine the old partition that needs to switch the storage engine and the target engine type.

[0075] In a specific implementation, the master control node receives the partition engine switching request sent by the client and sends the partition engine switching request to the computing node. The computing node determines the old partition that needs to switch the storage engine and the target engine type according to the partition engine switching request. For example, assuming that partition P1 is switched from the RocksDB storage engine to the Redis storage engine, the user specifies the partition for which the engine needs to be switched (for example, partition P1 is switched from the RocksDB storage engine to the Redis storage engine) through the client. The client sends a partition engine switching request to the master control node (the old partition that needs to switch the storage engine is P1, and the target engine type is Redis). The master control node sends the partition engine switching request to the computing node, and the computing node determines that the old partition that needs to switch the storage engine is P1 and the target engine type is Redis according to the partition engine switching request.

[0076] It can be understood that in order to implement a pluggable storage engine at the partition level, in this embodiment, the graph database management system includes a partition-level pluggable software architecture. For ease of understanding, reference is made to Figure 4 for illustration, but this does not limit the present application. Figure 4This is a partition-level pluggable software architecture diagram of an embodiment of the graph database management method of this application. In the figure, it includes five layers: a partition interface layer, a semantic layer, a structure layer, a table interface layer, and a pluggable storage engine layer.

[0077] Among them, the partition interface layer is an external-facing partition capability layer that provides capabilities to computing nodes and the master control node. It includes partition management interfaces such as partition creation and deletion, graph data operation interfaces such as adding, deleting, and modifying point-edge attributes (i.e., adding, deleting, and modifying points, edges, and attributes), and graph data query interfaces such as querying, traversing, and neighbor querying of point-edge attributes (i.e., points, edges, and attributes).

[0078] The semantic layer connects the partition interface layer and the table interface layer. Its function is to convert partition operation primitives (the smallest functional units of partitions) and graph operation primitives (the smallest functional units of graphs) into table operations based on the structure layer. At the same time, better primitive granularity control can enable the partition interface layer to better combine and assemble primitives to implement more complex partition interfaces. This layer mainly includes partition operation primitives and graph operation primitives.

[0079] At the same layer as the semantic layer is the structure layer, which complements the semantic layer and provides a storage structure design for point-edge attributes optimized for the engine, such as optimizing the structure based on the engine as much as possible to improve graph storage and query efficiency.

[0080] The table interface layer is based on the underlying storage engine and provides the most basic table management interfaces such as creating and deleting data tables, and at the same time provides table data interfaces such as data querying, data operation, and data traversing.

[0081] The pluggable storage engine layer is an engine-dependent layer that provides data storage and query capabilities based on self-developed or third-party storage engines, such as the RocksDB storage engine, the LMDB storage engine, the Redis storage engine, etc.

[0082] Step S20: Create a new partition of the target engine type.

[0083] It should be understood that creating a new partition of the target engine type can be to create a new partition of the target engine type through the storage node where the new partition is located. In a specific implementation, for example, the storage node where the new partition is located is denoted as the target storage node. Assuming that partition P1 is switched from the RocksDB storage engine to the Redis storage engine, the target storage node creates a new Redis storage engine partition named P1_new.

[0084] Step S30: Traverse the graph data in the old partition through the storage engine corresponding to the old partition, and import the traversed graph data into the new partition through the storage engine of the target engine type.

[0085] It should be noted that in a graph database, graph data can be a data structure composed of nodes and edges as basic elements, used to represent the relationships between entities. Graph data consists of nodes and edges. Nodes represent entities or objects, and edges represent the relationships between nodes.

[0086] In one example, taking social network data as an illustration, social network data includes users and the follow relationships between them. The specific steps to represent social network data using a graph database are as follows:

[0087] 1. Define two types of nodes: user nodes and post nodes. Each user node represents a user and contains user attributes such as ID, name, age, etc. Each post node represents a post and contains post attributes such as ID, title, content, etc.

[0088] 2. Use edges to represent the follow relationships between users and the publish relationships between users and posts: For example, an edge type of "follow" can be defined to connect two user nodes, indicating that one user follows another user. Similarly, an edge type of "publish" can be defined to connect a user node and a post node, indicating that a user has published a post.

[0089] In the above way, the users in the social network and the follow relationships between them, as well as the publish relationships between users and posts, can be represented in the form of graph data. Through the graph database system, various graph operations and queries can be performed, such as finding all followers of a certain user, finding posts related to a certain topic, etc.

[0090] It should be understood that in order to achieve seamless switching, in this embodiment, the storage node where the new partition is located will send a graph data traversal request to the storage node where the old partition is located, and copy the data from the old partition to the new partition in a streaming manner. Of course, in order to meet other transmission requirements, in this embodiment, the data can also be copied from the old partition to the new partition in other ways, and this embodiment does not limit this.

[0091] In a specific implementation, for example, assuming that partition P1 is switched from the RocksDB storage engine to the Redis storage engine, the target storage node sends a graph data traversal request to the storage node where the old partition P1 is located, traverses the graph data in the old partition P1 through the RocksDB storage engine corresponding to the old partition P1, and imports the traversed graph data into the new partition P1_new through the Redis storage engine.

[0092] Step S40: After the traversed graph data is imported, update the partition metadata information and delete the old partition.

[0093] For the sake of easy understanding, in combination with Figure 3This is for illustration purposes only and does not limit the present application. The seamless switching process of the partition-level storage engine is as follows:

[0094] 1. The user specifies, through the client, the partition for which the engine needs to be switched (for example, partition P1 is switched from the RocksDB storage engine to the Redis storage engine). The client sends a partition engine switching request to the master control node (the old partition for which the storage engine needs to be switched is P1, and the target engine type is Redis). The master control node sends the partition engine switching request to the computing node.

[0095] 2. The computing node determines, based on the partition engine switching request, that the old partition for which the storage engine needs to be switched is P1 and the target engine type is Redis.

[0096] 3. Denote the storage node where the new partition is created as the target storage node. The target storage node creates a new Redis storage engine partition named P1_new. The target storage node sends a graph data traversal request to the storage node where the old partition P1 is located, traverses the graph data in the old partition P1 through the RocksDB storage engine corresponding to the old partition P1, and imports the traversed graph data into the new partition P1_new through the Redis storage engine.

[0097] 4. After the traversed graph data is imported, the master control node updates the metadata information of the partition, adds P1_new to the partition list, and deletes the metadata information of the old partition P1.

[0098] In this embodiment, when receiving a partition engine switching request for a graph database, it is disclosed to determine the old partition for which the storage engine needs to be switched and the target engine type according to the partition engine switching request, create a new partition of the target engine type, traverse the graph data in the old partition through the storage engine corresponding to the old partition, and import the traversed graph data into the new partition through the storage engine of the target engine type. After the traversed graph data is imported, update the partition metadata information and delete the old partition. Since this embodiment realizes a pluggable storage engine at the partition level, that is, each partition can be switched to the corresponding storage engine according to actual needs, the utilization rate of hardware resources can be enhanced, and thus the performance of the graph database can be improved.

[0099] Refer to Figure 5 , Figure 5 which is the flowchart of the second embodiment of the graph database management method of the present application. Based on the first embodiment shown above Figure 2 a second embodiment of the graph database management method of the present application is proposed.

[0100] In the second embodiment, before the step S10, it further includes:

[0101] Step S01: When receiving a graph creation request for the graph database, convert the graph creation request into a partition creation request.

[0102] It should be understood that different storage engines have different engine implementations and certain focuses. For example, the RocksDB storage engine has good write performance but average read performance, the LMDB storage engine has good read performance but poor random write performance, and the Redis storage engine has good throughput but a special persistence method. Therefore, in order to use the appropriate storage engine in the appropriate scenario according to the engine characteristics, in this embodiment, when creating partitions according to the graph creation request, the storage engine type corresponding to each partition is specified, and each partition corresponding to the graph to be created is created through the storage engine of the storage engine type according to the partition information.

[0103] It can be understood that the graph creation request can be initiated by the user through the client to the master node. In a specific implementation, for example, the user initiates a graph creation request for the graph database through the client, the client sends the graph creation request to the master node, the master node converts the graph creation request into a partition creation request, and sends the partition creation request to the computing node.

[0104] Furthermore, in order to facilitate subsequent management of the graph database, in this embodiment, it is necessary to pre-load the storage engines of the preset storage engine type and / or the custom storage engine type. The storage engine type includes: the preset storage engine type and / or the custom storage engine type; before step S01, it further includes: obtaining user requirement information and loading the preset storage engine of the preset storage engine type according to the user requirement information; and / or, obtaining engine dependency information and loading the custom storage engine of the custom storage engine type according to the engine dependency information.

[0105] It should be understood that after the user installs the distributed graph database system with pluggable storage engines, in order to facilitate subsequent management of the graph database, in this embodiment, the pre-installed and adapted storage engines can be loaded according to the user's needs. For example, the RocksDB storage engine, the LMDB storage engine, the Redis storage engine, and / or, load the newly adapted storage engine by the user, that is, obtain the user requirement information and load the preset storage engine of the preset storage engine type according to the user requirement information, and / or, obtain the engine dependency information and load the custom storage engine of the custom storage engine type according to the engine dependency information.

[0106] Further, to support more new storage engines, in this embodiment, the user can adapt a third-party or self-developed engine by themselves. The obtaining of engine dependency information and the loading of a custom storage engine of a custom storage engine type according to the engine dependency information include: obtaining engine dependency information, and constructing a pluggable storage engine layer according to the engine dependency information, where a custom storage engine of a custom storage engine type is set in the pluggable storage engine layer; constructing a table interface layer according to the original interface of the custom storage engine, and the table interface layer provides a table management interface and a table data interface based on the pluggable storage engine layer to call the custom storage engine; designing a storage structure for point-edge attributes according to the characteristics of the custom storage engine, and constructing a semantic layer according to the storage structure; assembling a partition interface layer based on the semantic layer to load the custom storage engine, the partition interface layer is used to receive external operations, the semantic layer connects the partition interface layer and the table interface layer, and the semantic layer is used to convert the external operations into operations on the table management interface and / or the table data interface.

[0107] It should be understood that the engine adaptation process can be as follows:

[0108] 1. The user introduces relevant engine dependencies as a pluggable storage engine layer according to a self-developed engine or a third-party storage engine;

[0109] 2. The user implements the table interface layer according to the engine dependencies, and completes the implementation of the table interface layer, including but not limited to table management interfaces such as data table creation and deletion, and table data interfaces such as data query, data operation, and data traversal;

[0110] 3. The user designs a targeted point-edge storage structure based on the known information of the engine, so that the structure design can improve the efficiency of adding, deleting, modifying, and querying graph data, storage space efficiency, traversal query efficiency, adjacent edge query efficiency, etc. as much as possible;

[0111] 4. The user completes the implementation of the graph semantic layer based on the structure design and the table interface layer, implements the partition operation primitive as a call behavior to the table interface layer, and implements the graph operation primitive (including operations such as adding, deleting, modifying, querying, traversing, and neighbor query of point-edge attributes) as a call behavior to the table interface layer;

[0112] 5. The user assembles a partition interface layer for the outside at the partition level based on the semantic layer to meet the call requirements of the computing node and the master control node.

[0113] For ease of understanding, the LMDB storage engine is taken as an example for illustration, but the present application is not limited thereto. The following is the adaptation process of the LMDB engine:

[0114] 1. First, introduce the LMDB engine dependency package as a pluggable storage engine layer;

[0115] 2. Design and implement the table interface layer based on the original interfaces provided by the LMDB engine, including table management interfaces such as data table creation, deletion, data clearing, opening, and closing, as well as table data interfaces such as data query, data modification, data deletion, and data traversal.

[0116] 3. Based on the characteristics of the LMDB engine, specifically design the storage structure of vertex-edge attributes to maximize the efficiency of graph data addition, deletion, modification, query, storage space, traversal query, and adjacent edge query. Specifically, design vertices and edges as key-value pairs, where the vertex ID and its meta-information are set as the key, and the attribute information of the vertex is set as the value. The edge ID and its meta-information are set as the key, and the attribute information of the edge is set as the value, so that vertices and their adjacent edges are stored adjacent and ordered to improve the adjacent edge query efficiency.

[0117] 4. Complete the implementation of the semantic layer based on the structure design. Implement partition operation primitives as call behaviors on the table interface layer, and implement graph operation primitives as call behaviors on the table interface layer. Specifically, convert partition operation primitives such as partition creation, partition deletion, partition data clearing, partition opening, and partition closing into calls to the table management interface (and its combinations), and convert graph operation primitives such as vertex addition, vertex attribute modification, vertex deletion, edge addition, edge attribute modification, edge deletion, neighbor edge query, and vertex-edge quantity statistics into calls to the table data interface (and its combinations).

[0118] 5. Based on the semantic layer, assemble and form a graph interface for partitions at the partition level, including graph partition creation, graph partition deletion, graph partition data clearing, graph partition opening, graph partition closing, vertex addition, vertex attribute modification, vertex deletion, vertex upsert, edge addition, edge attribute modification, edge deletion, edge upsert, neighbor edge query, and vertex-edge quantity statistics, to meet the call requirements of computing nodes and the master control node.

[0119] Step S02: Determine the partition information corresponding to the graph to be created and the storage engine type corresponding to each partition during partitioning according to the partition creation request.

[0120] It should be noted that the partition information includes, but is not limited to, information such as the number of partitions, the number of replicas, the type of hot and cold partitions, the type of partition hardware resources, and the file system path. The storage engine type includes, but is not limited to, types such as the RocksDB storage engine, the LMDB storage engine, and the Redis storage engine.

[0121] It can be understood that determining the partition information corresponding to the graph to be created and the storage engine type corresponding to each partition during partitioning according to the partition creation request can be that the computing node parses the partition creation request to obtain the partition information corresponding to the graph to be created and the storage engine type corresponding to each partition during partitioning.

[0122] Step S03: Create each partition corresponding to the graph to be created through the storage engine of the storage engine type according to the partition information.

[0123] For ease of understanding, it is described in conjunction with Figure 3 for illustration purposes, but does not limit this application. The graph creation process is as follows:

[0124] 1. The user installs a distributed graph database system with a pluggable storage engine and loads a pre-configured and adapted storage engine according to the user's needs, such as the RocksDB storage engine, LMDB storage engine, Redis storage engine, or loads a newly adapted storage engine by the user himself / herself;

[0125] 2. The master control node receives a graph creation request initiated by the user through the client, converts the graph creation request into a partition creation request according to partition information such as the number of partitions, number of replicas, partition hardware resource type, file system path, etc. customized by the user or recommended by the master control node according to the user's usage scenario and the storage engine type corresponding to each partition, and sends the partition creation information to the computing nodes;

[0126] 3. The computing nodes parse the partition creation request, obtain the partition information corresponding to the graph to be created and the storage engine type corresponding to each partition during partitioning, and distribute the partition information corresponding to the graph to be created and the storage engine type corresponding to each partition during partitioning to each storage node;

[0127] 4. Each storage node creates partitions according to the partition information corresponding to the graph to be created and the storage engine type corresponding to each partition during partitioning, that is, uses the storage engine of the storage engine type and information such as the specified path to complete the partition creation behavior;

[0128] 5. After all graph partitions are created, the master control node prompts the user that the graph creation is successful and can be used for subsequent graph data operations, graph data queries, graph deletion and other requests.

[0129] In this embodiment, when creating partitions according to the graph creation request, the storage engine type corresponding to each partition is specified, and each partition corresponding to the graph to be created is created through the storage engine of the storage engine type, so that a suitable storage engine can be used in a suitable scenario according to the engine characteristics, thereby improving the performance of the graph database.

[0130] Further, in order to enable users to select an engine according to the hardware and business scenarios, so that the hardware resources can be fully utilized, the performance in the user business scenario can be fully improved, and the cost can be reduced, step S03 includes: obtaining the cold / hot partition type and / or partition hardware resource type corresponding to each partition during partitioning from the partition information, where the cold / hot partition type includes a cold partition or a hot partition; creating each partition corresponding to the graph to be created through the storage engine of the storage engine type according to the cold / hot partition type and / or the partition hardware resource type.

[0131] It can be understood that in this embodiment, in order to make the graph database have high flexibility, different graphs can support different business scenarios, and the same graph can also be extended to support cold / hot partitioning. For example, the hot partition uses LMDB / Redis storage, and the cold partition uses RocksDB storage. In addition, it can support hybrid hardware, where the main data is based on a solid-state drive and the LMDB engine, and the replica data is based on a mechanical hard drive and the RocksDB engine, enabling users to select an engine according to the hardware and business scenarios, so that the hardware resources can be fully utilized, the performance in the user business scenario can be fully improved, and the cost can be reduced.

[0132] In the second embodiment, after step S03, it further includes:

[0133] Step S04: When receiving a graph deletion request for the graph database, determine the graph to be deleted according to the graph deletion request.

[0134] It should be understood that in order to facilitate the management of the graphs in the graph database, in this embodiment, the graphs in the graph database can be deleted according to actual needs.

[0135] It can be understood that the graph deletion request can be initiated by the user through the client to the master control node. In a specific implementation, for example, the user initiates a graph deletion request for the graph database through the client, the client sends the graph deletion request to the master control node, when receiving the graph deletion request for the graph database, determine the graph to be deleted according to the graph deletion request, when there is a graph to be deleted in the graph database, generate a partition deletion request according to the target partition storing the graph to be deleted, and send the partition creation request to the computing node.

[0136] Step S05: When there is the graph to be deleted in the graph database, generate a partition deletion request according to the target partition storing the graph to be deleted.

[0137] For ease of understanding, it is described in conjunction with Figure 3 but does not limit the present application. The graph deletion process is as follows:

[0138] 1. The user specifies the graph to be deleted through the client;

[0139] 2. When the master control node receives a graph deletion request from the user, if the graph does not exist, an error is prompted.

[0140] 3. If the graph exists, the master control node generates a partition deletion request based on the target partition storing the graph to be deleted and sends the partition creation request to each storage node.

[0141] 4. When each storage node receives the partition deletion request, it deletes the table according to the table deletion interface of its respective partition storage engine.

[0142] 5. After all partitions are deleted, the master control node prompts the user that the graph deletion is successful.

[0143] Step S06: Based on the partition deletion request, delete the partition data corresponding to the graph to be deleted in the target partition through the storage engine corresponding to the target partition.

[0144] In an example, assume there is a distributed graph database that contains a graph named "SocialNetwork". Now the user wants to delete this graph. The specific graph deletion process is as follows:

[0145] 1. The user specifies the graph to be deleted as "SocialNetwork" through the client.

[0146] 2. When the master control node receives the graph deletion request from the user, the master control node checks whether there is a graph named "SocialNetwork" in the graph database. If it does not exist, an error message is returned to the user, prompting that the graph does not exist.

[0147] 3. If it does not exist, since the "SocialNetwork" graph is distributedly stored, the master control node generates a partition deletion request based on the target partition storing the graph to be deleted and sends the partition creation request to each storage node.

[0148] 4. After each storage node receives the partition deletion request, it executes the deletion operation of the corresponding partition data according to the table deletion interface of its own partition storage engine. For example, storage node A is responsible for storing the vertices and edges of the graph, and it executes the operation of deleting the vertices and edges of the graph on its partition.

[0149] 5. After each storage node completes the partition deletion operation, it notifies the master control node that the deletion is completed. For example, after storage node A finishes the deletion, it sends a notification of completion to the master control node; when the master control node receives the deletion completion notifications from all storage nodes, it prompts the user with a message indicating that the graph deletion is successful, confirming that the graph "SocialNetwork" has been successfully deleted.

[0150] In this embodiment, the graph in the graph database is deleted according to actual requirements, so as to facilitate the management of the graphs in the graph database.

[0151] Refer to Figure 6 , Figure 6 FIG. is a schematic flowchart of the third embodiment of the graph database management method of the present application. Based on the above embodiments, the third embodiment of the graph database management method of the present application is proposed.

[0152] In the third embodiment, step S20 includes:

[0153] Step S201: Obtain the cold and hot partition types of the newly created partition, where the cold and hot partition types include cold partitions or hot partitions.

[0154] It should be understood that, in order to improve the utilization rate of hardware resources and the performance in the user business scenario, in this embodiment, when creating a newly created partition of the target engine type, hardware resources with corresponding performance can also be allocated according to the cold and hot partition types of the newly created partition. In a specific implementation, obtaining the cold and hot partition types of the newly created partition can be obtaining the partition classification information input by the user through the client and determining the cold and hot partition types of the newly created partition according to the partition classification information; it can also be predicting the data access situation of the newly created partition and determining the cold and hot partition types of the newly created partition according to the data access situation of the newly created partition. Among them, cold partitions are used to store data with less access or infrequent access, and hot partitions are used to store data with frequent access or high performance requirements.

[0155] Step S202: When the cold and hot partition type of the newly created partition is a cold partition, allocate hardware resources of the first performance to the newly created partition, and create the newly created partition of the target engine type based on the hardware resources of the first performance.

[0156] It can be understood that when the cold and hot partition type of the newly created partition is a cold partition, it means that the newly created partition is used to store data with less access or infrequent access. Therefore, hardware resources of the first performance can be allocated to the newly created partition, that is, hardware resources with lower usage cost and larger capacity (such as mechanical hard disks) can be allocated to the newly created partition, and a newly created partition of the target engine type can be created based on the hardware resources of the first performance.

[0157] Step S202': When the cold and hot partition type of the newly created partition is a hot partition, allocate hardware resources of the second performance to the newly created partition, and create the newly created partition of the target engine type based on the hardware resources of the second performance, where the second performance is higher than the first performance.

[0158] It should be understood that when the cold and hot partition type of the newly created partition is a hot partition, it indicates that the newly created partition is used to store frequently accessed data or data with high performance requirements. Therefore, the hardware resources with the second performance can be allocated to the newly created partition, and the second performance is higher than the first performance, that is, the hardware resources with higher usage cost but faster speed are allocated to the newly created partition (such as a solid-state drive), and the newly created partition of the target engine type is created based on the hardware resources with the second performance.

[0159] In this embodiment, when creating a newly created partition of the target engine type, the hardware resources with corresponding performance can also be allocated according to the cold and hot partition type of the newly created partition, so as to improve the utilization rate of the hardware resources and the performance in the user service scenario.

[0160] Refer to Figure 7 , Figure 7 is a schematic flowchart of the fourth embodiment of the graph database management method of the present application. Based on the above embodiments, the fourth embodiment of the graph database management method of the present application is proposed.

[0161] In the fourth embodiment, the graph database management method further includes:

[0162] Step S50: When receiving a partition failover request for the graph database, determine the failed partition according to the partition failover request, and elect a new master partition from the replica partitions corresponding to the failed partition.

[0163] It should be understood that in order to implement heterogeneous engine failover and ensure the availability of the graph database, in this embodiment, when a failed partition appears in the graph database, a new master partition is elected from the replica partitions corresponding to the failed partition for heterogeneous engine failover, and during the transfer process, the availability of the system is also taken into account.

[0164] Step S60: During the election process, if it is detected that the number of replica partitions does not meet the preset availability requirement, create a new replica partition.

[0165] For ease of understanding, it is described in combination with Figure 3 but does not limit the present application. The heterogeneous engine failover process is as follows:

[0166] 1. When the master control node identifies a failed partition, first perform a partition election on the failed partition to elect a new master partition;

[0167] 2. If the number of replica partitions is insufficient, it is considered that the availability is weakened, and an operation to add replica partitions is performed;

[0168] 3. Select a suitable target node to create a replica partition;

[0169] 4. Stream out the graph data of the new primary partition and import it into the newly created replica partition until the data catches up with the primary partition;

[0170] 5. The master control node updates the partition metadata information.

[0171] Step S70: Import the graph data of the new primary partition into the new replica partition and update the partition metadata information.

[0172] It should be understood that since the heterogeneous engines have the same interfaces and in-memory data structures, the partition data replication between heterogeneous engines can be directly carried out. Therefore, the graph data of the new primary partition can be directly imported into the new replica partition.

[0173] In an example, assume there is a distributed graph database that contains a graph named "SocialNetwork" which is divided into multiple partitions for storage and replication. The heterogeneous engine failover process includes:

[0174] 1. The master control node identifies the faulty partition: The master control node monitors that a certain partition in the graph named "SocialNetwork" has failed and cannot work properly. For example, partition P1 has failed;

[0175] 2. Partition election and selection of the new primary partition: The master control node conducts a partition election for the faulty partition P1 and elects a new primary partition from other available replica partitions. For example, it elects replica partition P2 as the new primary partition from replica partitions P2, P3, and P4;

[0176] 3. New operation for replica partitions: If it is found during the election process that the number of replica partitions is not sufficient to ensure the availability of the system, the master control node considers the availability weakened and conducts a new operation for replica partitions to increase redundant replicas. For example, if there are only three replica partitions, P2, P3, and P4, then a new operation for replica partitions is carried out;

[0177] 4. Create a replica partition and import data: The master control node selects a suitable target node and creates a new replica partition P5 on the target node. Then, it streams out the graph data of the new primary partition P2 and imports it into the newly created replica partition P5 until the data is synchronized with the primary partition, which can be achieved through data replication, data transmission, or other means;

[0178] 5. Update the partition metadata information: The master control node updates the partition metadata information, including adding the replica partition P5 to the replica list of P2 and updating the relevant partition status and topology information. In this way, the system can recognize the existence of the new primary partition and replica partition.

[0179] In this embodiment, when a faulty partition is detected in the graph database, a new primary partition is elected from the replica partitions corresponding to the faulty partition to perform heterogeneous engine failover. During the transfer process, the availability of the system is also taken into account, thereby enabling heterogeneous engine failover and ensuring the availability of the graph database.

[0180] Reference Figure 8 , Figure 8 This is a flow chart of the fifth embodiment of the graph database management method of the present application. Based on the above embodiments, the fifth embodiment of the graph database management method of the present application is proposed.

[0181] In a fifth embodiment, the graph database management method further includes:

[0182] Step S50': upon receiving a graph data management request for the graph database, converting the graph data management request into a graph data management operation, wherein the graph data management request includes a graph data operation request and / or a graph data query request.

[0183] It should be understood that in order to facilitate the management of graph data in the graph database, in this embodiment, when a graph data management request for the graph database is received, the graph data in the storage engine is operated based on the graph data management request.

[0184] In a specific implementation, for example, a user initiates a graph data management request for a graph database through a client, a computing node receives the graph data management request sent by the client, converts the graph data management request into a graph data management operation, and sends the graph data management operation to a storage node.

[0185] For ease of understanding, combined Figure 4 For illustration, but not for limitation of this application. In the figure, the partition interface layer is an external partition capability layer, which provides capabilities for computing nodes and master control nodes, including partition management interfaces such as partition creation and deletion, graph data operation interfaces such as vertex and edge attribute addition, deletion and modification (i.e., addition, deletion and modification of vertex, edge and attribute), and graph data query interfaces such as vertex and edge attribute neighbor query and traversal (i.e., query, traversal and neighbor query of vertex, edge and attribute). In this embodiment, graph data management requests include graph data operation requests and / or graph data query requests, graph data management operations include graph data operations and / or graph data queries, graph data operations are implemented through graph data operations, and graph data queries are implemented through graph data query interfaces, wherein graph data operations include but are not limited to operations such as vertex and edge attribute addition, deletion and modification, and graph data queries include but are not limited to vertex and edge attribute neighbor query and traversal.

[0186] Step S60': Acquire the node-edge attribute storage structure information, and operate the graph data in the storage engine according to the graph data management operation and the node-edge attribute storage structure information.

[0187] It should be noted that the dot-edge attribute storage structure information can be the storage structure information of dots, edges, and attributes.

[0188] In a specific implementation, for example, the storage node obtains the dot-edge attribute storage structure information, and operates on the graph data in the storage engine according to the graph data management operation and the dot-edge attribute storage structure information.

[0189] For ease of understanding, it is described in conjunction with Figure 4 but does not limit the present application. In the figure, the storage node obtains the dot-edge attribute storage structure information through the structure layer.

[0190] In this embodiment, when receiving a graph data management request for the graph database, the graph data in the storage engine is operated based on the graph data management request, so as to facilitate the management of the graph data in the graph database.

[0191] In addition, referring to Figure 3 , an embodiment of the present application also proposes a graph database management system.

[0192] The graph database management system includes a master control node, a computing node, a storage node, and at least two pluggable storage engines;

[0193] The master control node is configured to receive a graph management request sent by a client, convert the graph management request into a partition management request, and send the partition management request to the computing node. The partition management request includes at least one of a partition engine switching request, a partition creation request, a partition deletion request, and a partition failover request;

[0194] The computing node is configured to, when the partition management request is a partition engine switching request for the graph database, determine an old partition that needs to switch the storage engine and a target engine type according to the partition engine switching request;

[0195] The storage node is configured to create a new partition of the target engine type, traverse the graph data in the old partition through the storage engine corresponding to the old partition, and import the traversed graph data into the new partition through the storage engine of the target engine type;

[0196] The master control node is further configured to update the partition metadata information and delete the old partition after the traversed graph data is imported.

[0197] In this embodiment, when a partition engine switching request for the graph database is received, the old partitions that need to switch the storage engine and the target engine type are determined according to the partition engine switching request, new partitions of the target engine type are created, the graph data in the old partitions is traversed through the storage engine corresponding to the old partitions, and the traversed graph data is imported into the new partitions through the storage engine of the target engine type. After the traversed graph data is imported, the partition metadata information is updated, and the old partitions are deleted; since this embodiment realizes a pluggable storage engine at the partition level, that is, each partition can be switched to the corresponding storage engine according to actual needs, the utilization rate of hardware resources can be enhanced, and thus the performance of the graph database can be improved.

[0198] For other embodiments or specific implementation manners of the graph database management system of this application, reference may be made to the above method embodiments, which will not be elaborated here.

[0199] In addition, an embodiment of this application also proposes a storage medium, on which a graph database management program is stored. When the graph database management program is executed by a processor, the graph database management method described above is implemented.

[0200] It should be noted that in this article, the term "including", "comprising" or any other variant thereof is intended to cover non-exclusive inclusion, so that a process, method, article or system including a series of elements not only includes those elements, but also includes other elements not explicitly listed, or also includes elements inherent to such a process, method, article or system. Without further limitations, an element defined by the statement "including a..." does not exclude the existence of another identical element in the process, method, article or system including that element.

[0201] The serial numbers of the embodiments of this application above are only for description and do not represent the superiority or inferiority of the embodiments.

[0202] Through the description of the above embodiments, those skilled in the art can clearly understand that the above embodiment methods can be implemented by means of software plus a necessary general hardware platform. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation manner. Based on such an understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as a Read Only Memory image (ROM) / Random Access Memory (RAM), magnetic disk, optical disc), and includes several instructions to enable a terminal device (which can be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0203] The above are only the preferred embodiments of the present application, and do not limit the patent scope of the present application. Any equivalent structure or equivalent process transformation made by using the content of the specification and drawings of the present application, or directly or indirectly applied in other related technical fields, shall be equally included in the patent protection scope of the present application.

Claims

1. A graph database management method, characterized in that, The described graph database management method includes: When receiving a partition engine switching request for the graph database, determining the old partitions that need to switch the storage engine and the target engine type according to the partition engine switching request; Creating new partitions of the target engine type; Traversing the graph data in the old partitions through the storage engine corresponding to the old partitions, and importing the traversed graph data into the new partitions through the storage engine of the target engine type; After the traversed graph data is imported, updating the partition metadata information and deleting the old partitions.

2. The graph database management method according to claim 1, characterized in that, Before the step of when receiving a partition engine switching request for the graph database and determining the old partitions that need to switch the storage engine and the target engine type according to the partition engine switching request, it further includes: When receiving a graph creation request for the graph database, converting the graph creation request into a partition creation request; Determining the partition information corresponding to the graph to be created and the storage engine type corresponding to each partition during partitioning according to the partition creation request; Creating each partition corresponding to the graph to be created through the storage engine of the storage engine type according to the partition information.

3. The graph database management method according to claim 2, characterized in that, The storage engine type includes: a preset storage engine type and / or a custom storage engine type; before the step of when receiving a graph creation request for the graph database and converting the graph creation request into a partition creation request, it further includes: Obtaining user requirement information and loading a preset storage engine of the preset storage engine type according to the user requirement information; And / or, obtaining engine dependency information and loading a custom storage engine of the custom storage engine type according to the engine dependency information.

4. The graph database management method according to claim 3, wherein The step of obtaining engine dependency information and loading a custom storage engine of the custom storage engine type according to the engine dependency information includes: Obtaining engine dependency information and constructing a pluggable storage engine layer according to the engine dependency information, and setting a custom storage engine of the custom storage engine type in the pluggable storage engine layer; Constructing a table interface layer according to the original interface of the custom storage engine, and the table interface layer provides a table management interface and a table data interface to call the custom storage engine based on the pluggable storage engine layer; Designing a storage structure for point-edge attributes according to the characteristics of the custom storage engine, and constructing a semantic layer according to the storage structure; Assembling to form a partition interface layer based on the semantic layer to load the custom storage engine, the partition interface layer is used to receive external operations, the semantic layer connects the partition interface layer and the table interface layer, and the semantic layer is used to convert the external operations into operations on the table management interface and / or the table data interface.

5. The graph database management method according to claim 2, wherein, The step of creating each partition corresponding to the graph to be created through the storage engine of the storage engine type according to the partition information includes: Obtaining the cold-hot partition type and / or the partition hardware resource type corresponding to each partition during partitioning from the partition information, and the cold-hot partition type includes cold partitions or hot partitions; Creating each partition corresponding to the graph to be created through the storage engine of the storage engine type according to the cold-hot partition type and / or the partition hardware resource type.

6. The graph database management method according to any one of claims 1 to 5, characterized in that, Creating the new partition of the target engine type includes: Obtaining the cold / hot partition type of the new partition, where the cold / hot partition type includes a cold partition or a hot partition; When the cold / hot partition type of the new partition is a cold partition, allocating the hardware resources of the first performance to the new partition, and creating the new partition of the target engine type based on the hardware resources of the first performance; When the cold / hot partition type of the new partition is a hot partition, allocating the hardware resources of the second performance to the new partition, and creating the new partition of the target engine type based on the hardware resources of the second performance, where the second performance is higher than the first performance.

7. The graph database management method according to any one of claims 1 to 5, characterized in that, The graph database management method further includes: When receiving a graph deletion request for the graph database, determining the graph to be deleted according to the graph deletion request; When the graph to be deleted exists in the graph database, generating a partition deletion request according to the target partition storing the graph to be deleted; Deleting the partition data corresponding to the graph to be deleted in the target partition through the storage engine corresponding to the target partition based on the partition deletion request.

8. The graph database management method according to any one of claims 1 to 5, characterized in that, The graph database management method further includes: When receiving a partition failover request for the graph database, determining the faulty partition according to the partition failover request, and electing a new master partition from the replica partitions corresponding to the faulty partition; During the election process, if it is detected that the number of replica partitions does not meet the preset availability requirement, creating a new replica partition; Importing the graph data of the new master partition into the new replica partition, and updating the partition metadata information.

9. The graph database management method according to any one of claims 1 to 5, characterized in that, The graph database management method further includes: When receiving a graph data management request for the graph database, converting the graph data management request into a graph data management operation, where the graph data management request includes a graph data operation request and / or a graph data query request; Obtaining the point-edge attribute storage structure information, and operating on the graph data in the storage engine according to the graph data management operation and the point-edge attribute storage structure information.

10. A graph database management device, characterized in that, The graph database management device includes: a memory, a processor, and a graph database management program stored on the memory and executable on the processor. When the graph database management program is executed by the processor, it implements the graph database management method according to any one of claims 1 to 9.

11. A storage medium, characterized in that, A graph database management program is stored on the storage medium. When the graph database management program is executed by the processor, it implements the graph database management method according to any one of claims 1 to 9.

12. A graph database management system, characterized in that, The graph database management system includes a master control node, computing nodes, storage nodes, and at least two pluggable storage engines; The master control node is configured to receive a graph management request sent by a client, convert the graph management request into a partition management request, and send the partition management request to the computing nodes. The partition management request includes at least one of a partition engine switch request, a partition creation request, a partition deletion request, and a partition failover request; The computing node is used to determine the old partitions that need to switch the storage engine and the target engine type according to the partition engine switching request when the partition management request is a partition engine switching request for the graph database; The storage node is used to create new partitions of the target engine type, traverse the graph data in the old partitions through the storage engine corresponding to the old partitions, and import the traversed graph data into the new partitions through the storage engine of the target engine type; The master control node is further used to update the partition metadata information and delete the old partitions after the import of the traversed graph data is completed.

Images