Transaction request processing method for a graph database

Abstract

This application relates to the field of electronic digital data processing technology, and in particular to a transaction request processing method for a graph database. The graph database further includes a transaction management service. The transaction request processing method includes the following steps: the graph service generates a transaction ID and an operation set Op based on the received transaction request, and sends the transaction ID to the transaction management service and the Op to the worker; if the information returned by the worker to the transaction management service containing the transaction ID is all successful execution information, the transaction management service notifies the worker to release the lock and indicates that the transaction was executed successfully; otherwise, it notifies the worker... i According to undolog i The transaction is rolled back, and the failure is indicated. This invention implements transaction functionality for graph databases.

Description

Technical Field

[0001] This invention relates to the field of electronic digital data processing technology, and in particular to a transaction request processing method for graph databases. Background Technology

[0002] Graph databases utilize real-time and massively parallel processing (MPP), and most current graph databases employ this approach. Figure 1 The technical architecture shown comprises three parts: graph service, metadata service, and storage service. Current graph databases do not yet support transaction functionality; therefore, implementing transaction functionality in graph databases is a problem that urgently needs to be solved. Summary of the Invention

[0003] The purpose of this invention is to provide a transaction request processing method for graph databases, so as to realize the transaction function of graph databases.

[0004] According to the present invention, a transaction request processing method for a graph database is provided, characterized in that the graph database includes graph services, metadata services, and storage services; the graph database further includes a transaction management service, and the transaction request processing method includes the following steps:

[0005] S100, the graph service generates a transaction ID and an operation set Op based on the received transaction request, and sends the transaction ID to the transaction management service, and sends the Op to the worker set worker = (worker1, worker2, ..., worker...) of the graph database. n ); Op=(op1, op2,..., op n ), op i This refers to the i-th operation in Op, where i ranges from 1 to n, and n is the total number of operations in Op. (The last part, "worker", appears to be a typo and can be left as is.) i To execute op i The nodes.

[0006] S200, iterate through Op, if op... i For deletion or modification operations, proceed to step S300; if op i If a new operation is to be added, then step S500 is executed.

[0007] S300, if worker i For resources i If the lock is successful, then the worker iReturn a message indicating a successful lock with the stated transaction ID to the transaction management service; if the worker i For resources i If the lock fails, then the worker i Return a lock failure message with the transaction ID to the transaction management service; resource i for op i The entity being manipulated.

[0008] S400: If all the information returned by the worker to the transaction management service with the transaction ID is a successful lock, then proceed to step S500; if the information returned by the worker to the transaction management service with the transaction ID contains a failed lock, then the transaction management service notifies the slave node that successfully locked the worker to cancel the lock and indicates that the transaction execution failed.

[0009] S500, iterate through the workers, if the worker... i For resources i If the execution result is successful, then the worker i Return a message indicating successful transaction execution with the stated transaction ID to the transaction management service, and generate an undo log. i If worker i For resources i If the execution result is failure, then the worker i Return a message to the transaction management service indicating that the transaction execution failed, containing the transaction ID.

[0010] S600: If the information returned by the worker to the transaction management service containing the transaction ID is all successful execution information, the transaction management service notifies the worker to release the lock and indicates that the transaction execution was successful; if the information returned by the worker to the transaction management service containing the transaction ID includes execution failure information, the transaction management service notifies the worker... i According to undolog i Perform a transaction rollback and indicate that the transaction failed.

[0011] Compared with the prior art, the present invention has significant advantages. Through the above technical solution, the transaction request processing method for graph databases provided by the present invention achieves considerable technical progress and practicality, and has broad industrial application value. It has at least the following advantages:

[0012] This invention improves upon the existing technical architecture of graph databases by adding a transaction management service. When a transaction request is received, this service can determine whether the transaction has succeeded or failed based on the execution results of the corresponding operations by each slave node executing the transaction, and notify each slave node to roll back the transaction if it fails. Based on this added transaction management service, this invention implements the transaction functionality of graph databases. Attached Figure Description

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

[0014] Figure 1 This is a schematic diagram of the technical architecture of an existing graph database;

[0015] Figure 2 This is a schematic diagram of the technical architecture of a graph database provided in an embodiment of the present invention;

[0016] Figure 3 A flowchart of a transaction request processing method for a graph database provided in an embodiment of the present invention. Detailed Implementation

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

[0018] According to the present invention, a method for processing transaction requests in a graph database is provided. For example... Figure 2 As shown, the graph database architecture of the present invention differs from existing graph database architectures in that, in addition to graph service, metadata service, and storage service, it also includes transaction management service.

[0019] Those skilled in the art will understand that any graph database architecture constructed using the existing graph service, metadata service, and storage service structures is within the scope of protection of this invention. As a specific implementation of a graph database architecture in the prior art, the graph service is responsible for handling client query requests, including four main steps: parsing the query statement, validating the statement, generating execution steps, and executing according to the execution steps. The metadata service is responsible for storing and managing shard location information and ensuring load balancing of shards. It stores schema information and is also responsible for adding, modifying, and deleting schemas, and recording their versions. The storage service is divided into three layers: the interface layer defines a series of graph-related application programming interfaces (APIs) for key-value (KV) operations on shards; the consensus layer implements Multi Group Raft to ensure strong consistency and high availability; and the storage engine layer provides get, put, and scan operations on local data. The graph service and metadata service are deployed on the master node of the graph database, and the storage service is deployed on the worker nodes of the graph database.

[0020] According to the present invention, the newly added transaction management service in the graph database architecture includes three components: Transaction Coordinator (TC), Transaction Manager (TM), and Resource Manager (RM). These three components cooperate to complete distributed transaction management. Specifically, the TC maintains the state of global and branch transactions and drives global transactions to commit or rollback; the TM defines the scope of global transactions: starting, committing, or rolling back global transactions; and the RM manages the resources for branch transaction processing, communicates with the TC to register branch transactions and report their status, and drives branch transactions to commit or rollback.

[0021] Preferably, to prevent single points of failure, the transaction management service adopts a master-slave architecture and uses the Raft consensus algorithm for election to ensure strong data consistency. As a specific implementation, this invention uses three master nodes for transaction coordination and simultaneously employs the Raft consensus algorithm to elect a transaction coordinator, ensuring that at any given time, one master node is coordinating transactions.

[0022] The transaction request processing method for graph databases of the present invention is as follows: Figure 3 As shown, it includes the following steps:

[0023] S100, the graph service generates a transaction ID and an operation set Op based on the received transaction request, and sends the transaction ID to the transaction management service, and sends the Op to the worker set worker = (worker1, worker2, ..., worker...) of the graph database. n ); Op=(op1, op2,..., op n ), op i This refers to the i-th operation in Op, where i ranges from 1 to n, and n is the total number of operations in Op. (The last part, "worker", appears to be a typo and can be left as is.) i To execute op i The nodes.

[0024] According to the present invention, after receiving a transaction request, the graph service generates a transaction ID and an operation set Op, and then sends the transaction ID (i.e., tranID) to the transaction management service. The transaction ID is unique and can be used to distinguish the transaction request from other transaction requests. Therefore, the transaction management service can determine whether subsequently received information belongs to the same transaction based on the transaction ID. The graph database sends the generated Op to the worker, and the worker executes the transaction.

[0025] According to the present invention, the graph service also generates a list of slave nodes executing the transaction based on the transaction request sent by the client, and sends the list of slave nodes to the transaction management service. Thus, the transaction management service can know which slave nodes are executing the transaction, and then make a determination on whether the Op has been executed successfully only after receiving the return information of all slave nodes executing the transaction.

[0026] According to the present invention, Op is a set of n operations, each executed by a slave node; therefore, the number of slave nodes included in the worker is also n. It should be understood that executing op... i It is a worker i Therefore, the method used in this invention to send Op to the worker is: to send the op... i Send to worker i .

[0027] S200, iterate through Op, if op... i For deletion or modification operations, proceed to step S300; if op i If a new operation is to be added, then step S500 is executed.

[0028] According to the present invention, op i For add, modify, or delete operations, when op i For modification or deletion operations, the entity needs to be locked first; therefore, this invention addresses this issue in the op... i The operation also includes determining the op during modification or deletion.i The steps to determine whether the entity being operated on has been successfully locked.

[0029] It should be understood that if op i For the operation of deleting or modifying 'a', then op... i The entity being manipulated in the text refers to 'a'.

[0030] Preferably, the locking in this invention refers to write locking.

[0031] S300, if worker i For resources i If the lock is successful, then the worker i Return a message indicating a successful lock with the stated transaction ID to the transaction management service; if the worker i For resources i If the lock fails, then the worker i Return a lock failure message with the transaction ID to the transaction management service; resource i for op i The entity being manipulated.

[0032] It should be understood that a single slave node can only obtain information about whether it has successfully locked the data. After returning this information to the transaction management service, the transaction management service then has the ability to determine whether all slave nodes that performed the delete or modify operation have successfully locked the data.

[0033] S400: If all the information returned by the worker to the transaction management service with the transaction ID is a successful lock, then proceed to step S500; if the information returned by the worker to the transaction management service with the transaction ID contains a failed lock, then the transaction management service notifies the slave node that successfully locked the worker to cancel the lock and indicates that the transaction execution failed.

[0034] It should be understood that transactions are atomic; a transaction request can only be successfully executed if all slave nodes performing the delete or modify operation have successfully locked their positions. Therefore, this invention determines that the transaction execution has failed when the information returned to the transaction management service contains information indicating a locking failure, and notifies the slave nodes in the worker that successfully locked their positions to cancel the locks.

[0035] S500, iterate through the workers, if the worker... i For resources i If the execution result is successful, then the worker iReturn a message indicating successful transaction execution with the stated transaction ID to the transaction management service, and generate an undo log. i If worker i For resources i If the execution result is failure, then the worker i Return a message to the transaction management service indicating that the transaction execution failed, containing the transaction ID.

[0036] According to the present invention, worker i For resources i Upon successful execution, a rollback log is also recorded to facilitate reverse operations in case of transaction failure, ensuring the atomicity of the transaction. Preferably, to simplify the process, the rollback log in this invention only records the initial value of each entity before the transaction execution and the final value after the transaction ends.

[0037] S600: If the information returned by the worker to the transaction management service containing the transaction ID is all successful execution information, the transaction management service notifies the worker to release the lock and indicates that the transaction execution was successful; if the information returned by the worker to the transaction management service containing the transaction ID includes execution failure information, the transaction management service notifies the worker... i According to undolog i Perform a transaction rollback and indicate that the transaction failed.

[0038] It should be understood that if a slave node has successfully executed the operation to delete 'a', then when rolling back the transaction, the slave node needs to add 'a'; if a slave node has successfully executed the operation to modify 'a', and the modified 'a' is 'a', then when rolling back the transaction, the slave node needs to modify 'a' back to 'a'; if a slave node has successfully executed the operation to add 'a', then when rolling back the transaction, the slave node needs to delete 'a'.

[0039] In one specific implementation, the transaction request received by the graph service is a batch operation request, which includes deleting entities A and B, adding entities C and D, and modifying entities E and F. The graph service generates a corresponding operation set Op based on the received transaction request. The operation set includes the following operations: deleting entity A, deleting entity B, modifying entity E, modifying entity F, adding entity C, and adding entity D. The graph service distributes different operations in Op to different slave nodes. Specifically, worker1 locks entity A, worker2 locks entity B, worker3 locks entity E, and worker4 locks entity F. If any of the four slave nodes fails to lock an entity, the successfully locked slave node is notified to cancel the lock. If all four slave nodes successfully lock entities, the following steps continue:

[0040] Worker1 deletes entity A, worker2 deletes entity B, worker3 modifies entity E, worker4 modifies entity F, worker5 adds entity C, and worker6 adds entity D. Simultaneously, rollback logs are recorded for each operation, and the final rollback logs are shown in Table 1.

[0041] Table 1

[0042]

[0043]

[0044] If all six slave nodes successfully execute their respective operations, the transaction management service notifies the worker to release the lock and indicates that the transaction was executed successfully. If any of the six slave nodes fails to execute, the transaction management service notifies the worker to roll back the transaction according to the rollback log and indicates that the transaction failed. Based on the rollback log in Table 1, the corresponding transaction rollback operations are shown in Table 2.

[0045] Table 2

[0046] Serial Number Rollback Log Rollback operation 1 {tranId,delete,A} Add entity A to the current node. 2 {tranId,delete,B} Add entity B to the current node. 3 {tranId,update,E,E'} Change entity E' to E in the current node. 4 {tranId,update,F,F'} Change entity F' to F in the current node. 5 {tranId,add,C} Delete entity C in the current node. 6 {tranId,add,D} Delete entity D in the current node.

[0047] While specific embodiments of the invention have been described in detail by way of example, those skilled in the art should understand that the examples are for illustrative purposes only and not intended to limit the scope of the invention. It should also be understood that various modifications can be made to the embodiments without departing from the scope and spirit of the invention. The scope of the invention is defined by the appended claims.

Claims

1. A method for processing transaction requests in a graph database, characterized in that, The graph database includes graph services, metadata services, and storage services; the graph database also includes a transaction management service, and the transaction request processing method includes the following steps: S100, the graph service generates a transaction ID and an operation set Op based on the received transaction request, and sends the transaction ID to the transaction management service, and sends the Op to the worker set worker = (worker1, worker2, ..., worker...) of the graph database. n ); Op=(op1, op2,..., op n ), op i This refers to the i-th operation in Op, where i ranges from 1 to n, and n is the total number of operations in Op. (The last part, "worker", appears to be a typo and can be left as is.) i To execute op i The nodes; S200, iterate through Op, if op... i For deletion or modification operations, proceed to step S300; if op i If a new operation is to be added, then step S500 is executed; S300, if worker i For resources i If the lock is successful, then the worker i Return a message indicating a successful lock with the stated transaction ID to the transaction management service; if the worker i For resources i If the lock fails, then the worker i Return a lock failure message with the transaction ID to the transaction management service; resource i for op i The entity being manipulated; S400, if all the information returned by the worker to the transaction management service with the transaction ID is a successful lock, then proceed to step S500; if the information returned by the worker to the transaction management service with the transaction ID contains a failed lock, then the transaction management service notifies the slave node in the worker that the lock was successfully locked to cancel the lock and indicates that the transaction execution failed. S500, iterate through the workers, if the worker... i For resources i If the execution result is successful, then the worker i Return a message indicating successful transaction execution with the stated transaction ID to the transaction management service, and generate an undo log. i If worker i For resources i If the execution result is failure, then the worker i Return a message to the transaction management service indicating that the transaction execution failed, containing the transaction ID. S600: If the information returned by the worker to the transaction management service containing the transaction ID is all successful execution information, the transaction management service notifies the worker to release the lock and indicates that the transaction execution was successful; if the information returned by the worker to the transaction management service containing the transaction ID includes execution failure information, the transaction management service notifies the worker... i According to undolog i Perform a transaction rollback and indicate that the transaction failed.

2. The method according to claim 1, characterized in that, In S100, the graph service also generates a list of slave nodes to execute the transaction based on the received transaction request, and sends the list of slave nodes to the transaction management service.

3. The method according to claim 1, characterized in that, The transaction management service includes a transaction coordinator, a transaction manager, and a resource manager. The transaction coordinator is used to maintain the state of global and branch transactions and drive global transactions to commit or rollback. The transaction manager is used to define the scope of a global transaction: start a global transaction, commit a global transaction, or roll back a global transaction; The resource manager is used to manage resources for branch transaction processing, communicate with the transaction coordinator to register branch transactions and report their status, and drive branch transactions to commit or rollback.

4. The method according to claim 1, characterized in that, The metadata service is used to store and manage the location information of shards and ensure load balancing of shards.

5. The method according to claim 1, characterized in that, The transaction management service adopts a master-slave architecture and uses the Raft consensus algorithm for election to ensure data consistency.

6. The method according to claim 1, characterized in that, op i For adding, modifying, or deleting operations.

7. The method according to claim 1, characterized in that, The graph service and the metadata service are both deployed on the master node of the graph database, and the storage service is deployed on the slave node of the graph database.

Images