A database processing method and related device

Abstract

Embodiments of the present application disclose a database processing method, which is applied to a database system, the database system comprising a first node and a second node, the first node and the second node respectively deploying a first database and a second database storing same data, the method comprising: obtaining a first operation set; sending the first operation set to the second node; receiving a second operation set sent by the second node, the first operation set and the second operation set being used for the second node to update the second database; and updating the first database based on the first operation set and the second operation set. Through mutual sending of operation sets of transactions between multiple nodes in the database system, the update of the database on the node takes into account the transactions committed by other databases, thereby ensuring the update synchronization between multiple databases.

Description

Technical Field

[0001] This application relates to the field of database technology, and in particular to a database processing method and related equipment. Background Technology

[0002] With the rapid development of the internet, software systems have evolved from monolithic applications to distributed applications. Distributed systems break down an application into multiple independently deployable services. Therefore, remote collaboration between services is necessary to complete transaction operations. This type of transaction, where different services collaborate remotely over a network to complete transactions in a distributed system environment, is called a distributed transaction. Examples include user registration reward points, order creation and inventory reduction, and bank transfers. In a distributed system, nodes are physically independent but communicate and coordinate through the network. Due to the transaction mechanism, data operations on each independent node can satisfy ACID properties. However, to ensure data consistency across multiple distributed machines, write operations on all nodes must either all be executed or none be executed. However, a machine executing a local transaction cannot know the results of local transactions on other machines. Therefore, it doesn't know whether the transaction should be committed or rolled back.

[0003] Currently, the conventional solution is to introduce a "coordinator" component to uniformly schedule the execution of all distributed nodes, also known as the two-phase commit method. The two-phase commit method can be summarized as follows: The coordinator sends prepare information to each participant. Each participant notifies the coordinator of the success or failure of its operation and enters a state of locking transaction resources, awaiting the coordinator's response. Based on the feedback from all participants, the coordinator decides whether each participant should execute a commit or rollback operation, and replies to each participant with its decision. Each participant then releases its transaction resources in response to the decision, thereby ensuring database consistency across all participants.

[0004] However, on the one hand, there are three interactions between the coordinator and each participant, resulting in significant communication overhead. On the other hand, due to the importance of the coordinator, if the coordinator fails, all participants will be locked in a state of locked transaction resources and unable to complete the transaction operation. Summary of the Invention

[0005] This application provides a database processing method and related equipment. Multiple nodes in a database system exchange sets of transaction operations. Updates on a node's database take into account transactions committed by other databases, thereby ensuring update synchronization among multiple databases.

[0006] The first aspect of this application provides a database processing method applied to a database system. The database system includes a first node and a second node. The first node deploys a first database, and the second node deploys a second database. The first database and the second database store the same data. The method can be executed by the first node or by a component of the first node (e.g., a processor, chip, or chip system). The method includes: the first node acquiring a first operation set, which consists of write operations or read / write operations of a first transaction set in the first database within a target time period; the first node sending the first operation set to the second node; the first node receiving a second operation set sent by the second node, which consists of write operations or read / write operations of a second transaction set in the second database within the target time period; the first operation set and the second operation set being used by the second node to update the second database; and the first node updating the first database based on the first operation set and the second operation set.

[0007] In this embodiment, multiple nodes in the database system send transaction operation sets to each other. Updates on a node's database take into account transactions committed by other databases, thus ensuring synchronization of updates across multiple databases. On one hand, transaction modifications are communicated between nodes by transmitting operation sets, avoiding multiple interactions between nodes and minimizing communication overhead. On the other hand, compared to the two-phase commit method, it avoids the inability to operate transactions due to a single point of failure in the coordinator.

[0008] Optionally, in one possible implementation of the first aspect, the above steps: the first node obtains the first operation set, including: the first node responds to and executes the first user's operation instructions on the first database; the first node records the first user's operations on data items in the first database during the execution of the operation instructions, thereby obtaining the first operation set.

[0009] In this possible implementation, as the node executes user commands for database operations, it records the first user's operations on data items in the database, obtaining an operation set. This operation set can then be used to reconstruct the user's database operations, providing a basis for subsequent database synchronization.

[0010] Optionally, in one possible implementation of the first aspect, the above-mentioned operation instruction is a write instruction, and the first operation set is a write operation set; or, the operation instruction is a read / write instruction, and the first operation set is a read / write operation set or a write operation set.

[0011] In this possible implementation, the operation set corresponding to a write command is a write operation set, and the operation set corresponding to a read / write command is either a read / write operation set or a write operation set. The specific set can be configured according to business needs and is not limited here. The operation set can record user operations on the database, enabling the replay of user actions.

[0012] Optionally, in one possible implementation of the first aspect, the above steps further include: a first node obtaining first information of a first transaction set, wherein each transaction in the first transaction set corresponds to a piece of first information, and the first information includes a first identifier and / or a first timestamp; the first node sending the first information to a second node; the first node receiving second information sent by the second node, wherein each transaction in the second transaction set corresponds to a piece of second information, and the second information includes a second identifier and / or a second timestamp; the first information and the second information being used by the second node to update the second database; the first node updating the first database based on the first operation set and the second operation set, including: the first node updating the first database based on the first operation set, the first information, the second operation set, and the second information.

[0013] In this possible implementation, in addition to exchanging sets of transaction operations, nodes can also exchange timestamps or identifiers of transactions. This allows subsequent updates to the database using the first and second transaction sets to determine which transactions need to be committed and the order in which they should be committed. By using this first and second information, conflicting transactions can be quickly identified, thereby improving the speed of subsequent database updates.

[0014] Optionally, in one possible implementation of the first aspect, the above steps: the first node updates the first database based on the first operation set, the first information, the second operation set, and the second information, including: the first node determines the transactions to be committed in the first transaction set and the second transaction set based on the first operation set, the first information, the second operation set, and the second information; the first node commits the transactions to be committed in the first database to obtain the updated first database.

[0015] In this possible implementation, when a node updates the first database using the first transaction set and the second transaction set, it can determine the transactions that need to be committed and the order in which they are committed using a first timestamp or a first identifier. By using the first and second information, conflicting transactions can be quickly identified, thereby improving the speed of subsequent updates to the first database.

[0016] Optionally, in one possible implementation of the first aspect, the first information of the first sub-transaction in the first transaction set is the first timestamp, and the second information of the second sub-transaction in the second transaction set is the second timestamp. The first sub-transaction and the second sub-transaction include at least one overlapping data item. If the first timestamp is less than the second timestamp, the second sub-transaction is a transaction that cannot be committed. Here, the transaction with the larger timestamp is determined to be a transaction that cannot be committed. It is understood that the transaction with the smaller timestamp can also be determined to be a transaction that cannot be committed. The specific rules can be set according to actual needs and are not limited here.

[0017] In this possible implementation, transactions with larger timestamps are identified as uncommittable transactions. This rule can determine which transactions in the first and second transaction sets can be committed or not. After all transactions are compared, the transactions to be committed can be committed, and the uncommittable transactions can be rolled back, thereby updating the database.

[0018] A second aspect of this application provides a database processing method applied to a database system. The database system includes a first node and a second node. The first node deploys a first database, and the second node deploys a second database. The first and second databases store the same data. The method can be executed by the second node or by a component of the second node (e.g., a processor, chip, or chip system). The method includes: the second node acquiring a second operation set, which consists of write operations or read / write operations of a second transaction set in the second database within a target time period; the second node sending the second operation set to the first node; the second node receiving a first operation set sent by the first node, which also consists of write operations or read / write operations of the first transaction set in the first database within the target time period; the first and second operation sets being used by the first node to update the second database; and the second node updating the second database based on the first and second operation sets.

[0019] Optionally, in one possible implementation of the second aspect, the above steps: the second node obtains the second operation set, including: the second node responds to and executes the second user's operation instructions on the second database; the second node records the second user's operations on data items in the second database during the execution of the operation instructions, thereby obtaining the second operation set.

[0020] Optionally, in one possible implementation of the second aspect, the above-mentioned operation instruction is a write instruction, and the second operation set is a write operation set; or, the operation instruction is a read / write instruction, and the second operation set is a read / write operation set or a write operation set.

[0021] Optionally, in one possible implementation of the second aspect, the above steps further include: the second node obtaining second information of the second transaction set, where each transaction in the second transaction set corresponds to a piece of second information, the second information including a second identifier and / or a second timestamp; the second node sending the second information to the first node; the second node receiving first information sent by the first node, where each transaction in the first transaction set corresponds to a piece of first information, the first information including a first identifier and / or a first timestamp; the first information and the second information being used by the first node to update the second database; the second node updating the second database based on the first operation set and the second operation set, including: the second node updating the second database based on the first operation set, the first information, the second operation set, and the second information.

[0022] Optionally, in one possible implementation of the second aspect, the above steps: the second node updates the second database based on the first operation set, the first information, the second operation set, and the second information, including: the second node determines the transactions to be committed in the first transaction set and the second transaction set based on the first operation set, the first information, the second operation set, and the second information; the second node commits the transactions to be committed in the second database to obtain the updated second database.

[0023] Optionally, in one possible implementation of the second aspect, the first information of the first sub-transaction in the first transaction set is a first timestamp, the second information of the second sub-transaction in the second transaction set is a second timestamp, the first sub-transaction and the second sub-transaction include at least one overlapping data item, the first timestamp is less than the second timestamp, and the second sub-transaction is a transaction that cannot be committed.

[0024] A third aspect of this application provides a first node applied to a database system, the database system further including a second node. The first node deploys a first database, and the second node deploys a second database. The first database and the second database store the same data. The first node includes: an acquisition unit for acquiring a first operation set, the first operation set being write operations or read / write operations of a first transaction set in the first database within a target time period; a sending unit for sending the first operation set to the second node; a receiving unit for receiving a second operation set sent by the second node, the second operation set being write operations or read / write operations of a second transaction set in the second database within the target time period, the first operation set and the second operation set being used by the second node to update the second database; and an update unit for updating the first database based on the first operation set and the second operation set.

[0025] Optionally, in one possible implementation of the third aspect, the aforementioned acquisition unit is specifically used to respond to and execute the first user's operation instructions on the first database; the acquisition unit is specifically used to record the first user's operations on data items in the first database during the execution of the operation instructions, thereby obtaining a first operation set.

[0026] Optionally, in one possible implementation of the third aspect, the above-mentioned operation instruction is a write instruction, and the first operation set is a write operation set; or, the operation instruction is a read / write instruction, and the first operation set is a read / write operation set or a write operation set.

[0027] Optionally, in one possible implementation of the third aspect, the aforementioned acquisition unit is further configured to acquire first information of the first transaction set, wherein each transaction in the first transaction set corresponds to a piece of first information, and the first information includes a first identifier and / or a first timestamp; the sending unit is further configured to send the first information to the second node; the receiving unit is further configured to receive second information sent by the second node, wherein each transaction in the second transaction set corresponds to a piece of second information, and the second information includes a second identifier and / or a second timestamp; the first information and the second information are used by the second node to update the second database; the updating unit is specifically configured to update the first database based on the first operation set, the first information, the second operation set, and the second information.

[0028] Optionally, in one possible implementation of the third aspect, the aforementioned update unit is specifically used to determine the transactions to be committed in the first transaction set and the second transaction set based on the first operation set, the first information, the second operation set, and the second information; the update unit is specifically used to commit the transactions to be committed in the first database to obtain the updated first database.

[0029] Optionally, in one possible implementation of the third aspect, the first information of the first sub-transaction in the first transaction set is the first timestamp, the second information of the second sub-transaction in the second transaction set is the second timestamp, the first sub-transaction and the second sub-transaction include at least one overlapping data item, the first timestamp is less than the second timestamp, and the second sub-transaction is a transaction that cannot be committed.

[0030] A fourth aspect of this application provides a second node applied to a database system. The database system further includes a first node, on which a first database is deployed, and on which a second database is deployed. The first database and the second database store the same data. The second node includes: an acquisition unit for acquiring a second operation set, wherein the second operation set consists of write operations or read / write operations of a second transaction set in the second database within a target time period; a sending unit for sending the second operation set to the first node; a receiving unit for receiving a first operation set sent by the first node, wherein the first operation set consists of write operations or read / write operations of a first transaction set in the first database within the target time period, and the first operation set and the second operation set are used by the first node to update the first database; and an update unit for updating the second database based on the first operation set and the second operation set.

[0031] Optionally, in one possible implementation of the fourth aspect, the aforementioned acquisition unit is specifically used to respond to and execute the second user's operation instructions on the second database; the acquisition unit is specifically used to record the second user's operations on data items in the second database during the execution of the operation instructions, thereby obtaining a second operation set.

[0032] Optionally, in one possible implementation of the fourth aspect, the above-mentioned operation instruction is a write instruction, and the second operation set is a write operation set; or, the operation instruction is a read / write instruction, and the second operation set is a read / write operation set or a write operation set.

[0033] Optionally, in one possible implementation of the fourth aspect, the aforementioned acquisition unit is further configured to acquire second information of the second transaction set, wherein each transaction in the second transaction set corresponds to a piece of second information, and the second information includes a second identifier and / or a second timestamp; the sending unit is further configured to send the second information to the first node; the receiving unit is further configured to receive first information sent by the first node, wherein each transaction in the first transaction set corresponds to a piece of first information, and the first information includes a first identifier and / or a first timestamp; the first information and the second information are used by the first node to update the first database; the updating unit is specifically configured to update the second database based on the first operation set, the first information, the second operation set, and the second information.

[0034] Optionally, in one possible implementation of the fourth aspect, the aforementioned update unit is specifically used to determine the transactions to be committed in the first transaction set and the second transaction set based on the first operation set, the first information, the second operation set, and the second information; the update unit is specifically used to commit the transactions to be committed in the second database to obtain the updated second database.

[0035] Optionally, in one possible implementation of the fourth aspect, the first information of the first sub-transaction in the first transaction set is the first timestamp, the second information of the second sub-transaction in the second transaction set is the second timestamp, the first sub-transaction and the second sub-transaction include at least one overlapping data item, the first timestamp is less than the second timestamp, and the second sub-transaction is a transaction that cannot be committed.

[0036] The fifth aspect of this application provides a first node for performing the methods in the aforementioned first aspect or any possible implementation thereof.

[0037] The sixth aspect of this application provides a second node for performing the methods in the aforementioned second aspect or any possible implementation thereof.

[0038] A seventh aspect of this application provides a database system, including a first node of the aforementioned third or fifth aspect, and / or a second node of the aforementioned fourth or sixth aspect.

[0039] An eighth aspect of this application provides a chip including a processor and a data interface. The processor reads instructions stored in a memory through the data interface to execute the method in the first aspect or any possible implementation thereof; or to execute the method in the second aspect or any possible implementation thereof. In specific implementation, the chip may be implemented in the form of a central processing unit (CPU), a microcontroller unit (MCU), a microprocessor (MPU), a digital signal processor (DSP), a system on chip (SoC), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or a programmable logic device (PLD).

[0040] A ninth aspect of this application provides a computer-readable medium storing program code that, when executed on a computer, causes the computer to perform the methods described in the first aspect or any possible execution of the first aspect; and causes the computer to perform the methods described in the second aspect or any possible execution of the second aspect. Such computer-readable storage includes, but is not limited to, one or more of the following: read-only memory (ROM), programmable ROM (PROM), erasable PROM (EPROM), flash memory, electrically EPROM (EEPROM), and hard drive.

[0041] The tenth aspect of this application provides a computer program product that, when executed on a computer, causes the computer to perform the methods in the aforementioned first aspect or any possible implementation thereof; or causes the computer to perform the methods in the aforementioned second aspect or any possible implementation thereof.

[0042] The technical effects of the second to tenth aspects or any of the possible implementations thereof can be found in the first aspect or the technical effects of different possible implementations of the first aspect, and will not be repeated here.

[0043] As can be seen from the above technical solutions, the embodiments of this application have the following advantages: the first node obtains a first set of operations related to a first set of transactions in the first database, receives a second set of operations related to a second set of transactions in the second database sent by the second node, and updates the first database based on the first and second set of operations. This ensures that the update of the first database takes into account the transactions committed by other databases, thereby guaranteeing the synchronization of updates among multiple databases. On the one hand, transaction modifications are communicated between nodes by transmitting operation sets, without involving multiple interactions between nodes, resulting in low communication overhead. On the other hand, compared to the two-phase commit method, it avoids the inability to operate transactions due to a single point of failure of the coordinator. Attached Figure Description

[0044] Figure 1 A schematic diagram of a database system architecture provided in an embodiment of the present invention;

[0045] Figure 2 A schematic flowchart illustrating the database processing method provided in this application embodiment;

[0046] Figure 3 An example diagram of the first and second databases provided in the embodiments of this application;

[0047] Figure 4 A schematic diagram illustrating a process for updating a first database and a second database, provided as an embodiment of this application;

[0048] Figure 5 A schematic diagram of the structure of the first node provided in an embodiment of this application;

[0049] Figure 6 A schematic diagram of the structure of the second node provided in an embodiment of this application;

[0050] Figure 7 This is a schematic diagram of the structure of a communication device provided in an embodiment of this application. Detailed Implementation

[0051] This application provides a database processing method and related equipment. Multiple nodes in a database system exchange sets of transaction operations. Updates on a node's database take into account transactions committed by other databases, thereby ensuring update synchronization among multiple databases.

[0052] The technical solutions of the embodiments of the present invention will now be described with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present invention, and not all of them. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without creative effort are within the scope of protection of the present invention.

[0053] Furthermore, in the embodiments of this application, the words "exemplary," "for example," etc., are used to indicate that they are examples, illustrations, or descriptions. Any embodiment or design scheme described as "exemplary" in this application should not be construed as being more preferred or advantageous than other embodiments or design schemes. Specifically, the use of the term "exemplary" is intended to present the concept in a concrete manner.

[0054] In this application, "at least one" means one or more, and "more than one" means two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can mean: A alone, A and B together, and B alone, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, or c can mean: a, b, c, ab, ac, bc, or abc, where a, b, and c can be single or multiple.

[0055] To facilitate understanding, the relevant terms and concepts mainly involved in the embodiments of this application will be introduced below.

[0056] 1. Database

[0057] A database, also known as a data management system, is an electronic archiving system that stores data in a structured manner. The main storage structure in a database is a table.

[0058] 2. Database system

[0059] A database system can be understood as a distributed database system, consisting of multiple nodes, each hosting a database. In one scenario, some nodes can handle read and write requests, while others can only handle read requests. In another scenario, all nodes can handle write requests, resulting in higher overall resource utilization. Here, a node in a network or distributed system refers to a single computer or software instance within a network or distributed system involving multiple computers.

[0060] 3. Database Management System (DBMS)

[0061] A database management system (DBMS) is a large-scale computer software management system designed for managing object databases. The database processing method provided in this application can be applied to MySQL, Oracle, openGauss, etc., and is not specifically limited here.

[0062] 4. Database transactions (or simply transactions)

[0063] A transaction is a logical unit in the execution process of a database management system, consisting of a finite sequence of database operations. For example, a bank transfer: a complete transaction requires deducting an amount from one account and adding an amount to another account.

[0064] After a transaction executes successfully, it needs to be "committed." Once committed, the changes will take effect and cannot be lost. If a transaction fails (abort), it needs to be "rolled back," and all changes will be nullified.

[0065] Transactions have the following four characteristics:

[0066] Atomicity: All operations in a transaction are indivisible as a whole, like atoms; either all succeed or all fail.

[0067] Consistency: The execution result of a transaction must bring the database from one consistent state to another. A consistent state means: 1. The system's state satisfies data integrity constraints (primary key, referential integrity, check constraints, etc.). 2. The system's state reflects the true state of the real world that the database should describe; for example, the total amount in two accounts should remain unchanged before and after a transfer.

[0068] Isolation: Concurrently executed transactions do not affect each other, and their impact on the database is the same as if they were executed sequentially. For example, if multiple users transfer money to the same account simultaneously, the final account result should be the same as if the transfers were made in the order they occurred.

[0069] Durability: Once a transaction is committed, its updates to the database are permanent. No data loss will occur due to any transaction or system failure.

[0070] 5. Transaction Sets

[0071] The transaction set proposed in this application includes one or more transactions, and one transaction includes one or more operations. Furthermore, one transaction corresponds to one timestamp or one identifier.

[0072] 6. Optimistic concurrency control (OCC)

[0073] OCC (Optical Concurrency Control) is a concurrency control method used in database management systems. OCC assumes that multiple transactions can complete in parallel without interfering with each other. At runtime, transactions use data resources without acquiring locks on those resources. Before committing, each transaction verifies that no other transaction has modified the data it has read or modified. If the check reveals conflicting modifications, the transaction will need to be rolled back.

[0074] 7. Second-stage submission

[0075] Two-phase commit is an algorithm used in computer networks and databases to ensure consistency among all nodes in a distributed system architecture when committing transactions. It is often referred to as a protocol. In a distributed system, while each node knows whether its own operation succeeded or failed, it cannot know the success or failure of other nodes' operations. When a transaction spans multiple nodes, to maintain the four properties of a transaction, a coordinator is needed to centrally manage the results of all nodes' (participants) operations and ultimately instruct them whether to commit the results (e.g., writing updated data to disk). Therefore, the algorithm for two-phase commit can be summarized as follows: The coordinator sends prepare information to each participant. Each participant notifies the coordinator of the success or failure of its operation and enters a state of locking transaction resources, awaiting the coordinator's response. Based on the feedback from all participants, the coordinator decides whether each participant should execute a commit or rollback operation and replies to the participants with its decision. Each participant then releases its transaction resources in response, thus ensuring database consistency across all participants.

[0076] However, on the one hand, there are three interactions between the coordinator and each participant, resulting in significant communication overhead. On the other hand, due to the importance of the coordinator, if the coordinator fails, all participants will be locked in a state of locked transaction resources and unable to complete the transaction operation.

[0077] To address the aforementioned issues, this application provides a database processing method that ensures synchronized updates among multiple databases by having multiple nodes in a database system exchange transaction operation sets with each other. This allows updates on a node's database to take into account transactions submitted by other databases.

[0078] Figure 1 A schematic diagram of a database system is provided. This database system may include: node A 101, node B 102, node C 103, and node D 104. Node A 101 hosts database A, and the user of database A is user A. Node B 102 hosts database B, and the user of database B is user B. Node C 103 hosts database C, and the user of database C is user C. Node D 104 hosts database D, and the user of database D is user D. All databases store the same data. Nodes A 101, B 102, C 103, and D 104 communicate with each other.

[0079] The nodes mentioned above can transmit their own operation sets (also known as local operation sets) to each other, and update their own databases (also known as local databases) based on the operation sets of transaction sets received from other databases and the operation sets of local transaction sets.

[0080] In this embodiment, the operation set refers to the data items modified by the node in response to user operation instructions (such as write instructions, read-write instructions, etc.), or the modified data items and read data items. This operation set can also be called a write set or a read-write set. The receiving node can update its local database through the operation set sent by the sending node, making the updated local database consistent with the data stored in the sending node's database, thereby ensuring synchronization between the databases.

[0081] In one possible implementation, each of the above nodes can provide read and write services to the user. Of course, some of the above nodes may only provide read services to the user, or there may be forwarding nodes. Alternatively, it can be understood that the method provided in this application embodiment can be applied to multi-master replication scenarios or master-slave replication scenarios, and no specific limitation is made here.

[0082] Optionally, to ensure database synchronization, each node, after sending its operation set to other nodes, receives a success message from the other nodes before updating its database using its local operation set and the operation sets of other nodes. Additionally, it should be noted that in scenarios where operation sets are exchanged between multiple nodes, ... Figure 1 Taking the four nodes shown as an example, if node A sends operation set A to nodes B, C, and D respectively, but only receives successful reception messages from nodes B and C, and not from node D, node A can still use its local operation set to update its database with the operation sets of other nodes. In other words, most nodes in the database system have successfully received the operation set and updated their local databases, ensuring database synchronization across most nodes. Ideally, the sending node should update its local database only after receiving the successful reception message from the receiving node, thus ensuring data consistency across all nodes in the database system.

[0083] Taking user A as an example, generally, user A sends read and write requests to the nearest node (e.g., node A) for processing. In the case of write requests, the system waits for node A to complete its processing and synchronize the data to other nodes. Then, it combines the operation sets of other nodes (e.g., transaction read and write sets) to perform conflict detection and resolution before returning the result to the client (this can also be understood as returning the result only after the database synchronization is successful).

[0084] For example, taking the interaction between node A and node B in the above example, node A can receive operation instructions from user A for database A. During the execution of these instructions, node A records the data items read or modified by user A, thus obtaining node A's operation set. After obtaining the operation set, node A can send it to node B. Node A can also receive the operation set sent by node B (i.e., the data items read and modified by node B during the execution of user B's operation instructions for database B). Therefore, node A can update database A based on the operation sets A and B. Node B can update database B based on the operation sets A and B, thereby achieving consistency between database A and database B. Alternatively, an interaction cycle can be set, where within each interaction cycle, the two nodes exchange their own data sets, thereby achieving synchronization between database A and database B.

[0085] In this embodiment of the application, the operation set refers to the integration of user operations during database operations. For example, the operation set may be a read-write set or a write set, etc., and the specifics are not limited here.

[0086] In addition, any two users among A, B, C and D in this application embodiment can be the same user or different users, and no specific limitation is made here.

[0087] In this embodiment, only four nodes and four users are used as an example for illustrative purposes. In practical applications, the database system in this embodiment may include more or fewer nodes and users, and this embodiment does not limit the number of nodes and users.

[0088] In this application's embodiments, a node refers to a computer or software instance within a network or distributed system involving multiple computers. For example, the node can be a server or terminal device. This terminal device is a device with wireless / wired transceiver capabilities, which can be deployed on land (including indoors or outdoors, handheld, wearable, or vehicle-mounted); it can also be deployed on water (such as on ships); and it can be deployed in the air (such as on airplanes, balloons, and satellites). This terminal device can be a mobile phone, tablet, computer with wireless transceiver capabilities, virtual reality (VR) terminal device, augmented reality (AR) terminal device, wireless terminal in industrial control, vehicle-mounted terminal device, wireless terminal in self-driving, wireless terminal in remote medical care, wireless terminal in smart grid, wireless terminal in transportation safety, wireless terminal in smart city, wireless terminal in smart home, wearable terminal device, etc. The embodiments of this application do not limit the application scenarios. Terminal equipment may also be referred to as a terminal, user equipment (UE), access terminal equipment, vehicle-mounted terminal, industrial control terminal, UE unit, UE station, mobile station, mobile station, remote station, remote terminal equipment, mobile device, UE agent, or UE device, etc. Terminal equipment can be fixed or mobile. Additionally, terminal equipment can also be a chip system used to implement UE functions.

[0089] The following is combined Figure 1 The interaction flow between any two nodes in the database system shown describes the database processing method in this application embodiment. Please refer to... Figure 2 One embodiment of the database processing method provided in this application includes steps 201 to 206. The first node and the second node can be the aforementioned... Figure 1 Any two nodes in the method are not specifically limited here. Furthermore, this method can be executed by a communication device (e.g., a server or terminal device) or by a component of the communication device (e.g., a processor, chip, or chip system). It is understood that the communication device can be a chip or a unit or physical device with transceiver capabilities. In addition, the database processing method provided in this application embodiment can be applied to MySQL, Oracle, openGauss, etc., and is not specifically limited here.

[0090] Step 201: The first node obtains the first set of operations.

[0091] In this embodiment, the first node and the second node can be any two nodes in the database system. The first node deploys a first database, and the second node deploys a second database, with the first database and the second database storing the same data.

[0092] In this embodiment, an operation set can be used to record the execution process of a database transaction. No matter how complex the execution process of a database transaction is, the operation set can be used to replay the transaction's execution process and produce the same execution result. Furthermore, multiple nodes can synchronize the database by sending their local operation sets to each other.

[0093] The operation set (including the first operation set and the second operation set) in the embodiments of this application may include one or more transactions, and one transaction may correspond to one or more operations (e.g., read, write, etc.). Among them, write operations may include operations such as add, delete, and modify.

[0094] Additionally, it should be noted that the first transaction set can be any committable transaction in the first database (which can also be understood as, when there are multiple transactions in the first transaction set, there are no conflicts between these transactions), and the second transaction set can be any committable transaction in the second database (which can also be understood as, when there are multiple transactions in the second transaction set, there are no conflicts between these transactions). Alternatively, the first transaction set can be all transactions in the first database, and the second transaction set can be all transactions in the second database.

[0095] In this embodiment, the first node obtains the first operation set only by means of operation instructions from the first user. It is understood that it could also be obtained by other devices sending the first operation set, etc., and this is not limited here. The first operation set refers to write operations or read / write operations of the first transaction set in the first database within a target time period. Furthermore, the number of transactions in the first transaction set can be one or more, and the number of write operations or read / write operations in the first operation set is not limited. The target time period can be set according to actual needs, and this is not limited here.

[0096] The target time period mentioned above can refer to a time cycle. In this case, the target time period can be understood as the time period between the last synchronization time and the target time. Optionally, the first node can obtain the first operation set in each cycle of the preset cycle and periodically send the operation set to the second node. There is no limit to the number of cycles here. For example, if a cycle is 10 milliseconds, then the target time period can be 10 milliseconds, that is, the first node will obtain the first operation set once every 10 milliseconds and send the first operation set to the second node once.

[0097] It is understandable that the target time period can also refer to the time period from the creation time of the first database to the target time. That is, the first set of operations refers to the write or read / write operations of the first set of transactions in the first database before the target time. In this case, it can be understood that in order to ensure data synchronization between the first database of the first node and the database of the second node at the target time, all the first set of operations before the target time can be sent at once.

[0098] Optionally, the first database can provide write services or read-write services to the first user, meaning the first user can perform a series of operations on the table entries of the first database in the first node, such as writing (e.g., adding, deleting, modifying) and reading (e.g., querying). During the execution of these operations, the first node records the first user's operations on the data items in the first database, thus obtaining the first set of operations.

[0099] For example, the first node receives read and write instructions from the first user for the first database. The first node responds to these instructions by performing read and write operations on table entries in the first database. During the execution of these read and write operations, it records the data items read and modified by the first user, thus obtaining the first read and write set. In this example, the first operation set is either the read and write operation set or the write operation set of the first transaction set, depending on actual needs; no specific limitation is made here.

[0100] For example, the first node receives a write instruction from the first user for the first database. The first node responds to the write instruction by performing a write operation on a table entry in the first database. During the execution of this write operation, the first node records the data items modified by the first user, thus obtaining the first write set. That is, in this example, the first operation set is the set of write operations of the first transaction set.

[0101] For example, to better understand the subsequent synchronization process between the first and second databases, the following example illustrates that the first and second databases store data as follows: Figure 3 The data shown in Table 1 is used as an example for illustrative description. The first set of transactions executed by the first user in the first database includes: Transaction 1 and Transaction 2. Transaction 1: Delete “Sun Wu”. Transaction 2: Modify the “delivery address” of “Li Liu” to “Room 801, F Hotel, E Street, Nanshan District, Shenzhen, Guangdong Province”. Therefore, the first set of operations of the first set of transactions includes: deletion operations and modification operations.

[0102] For ease of subsequent description, at least one of the first timestamp, first identifier, or first period identifier for each transaction in the first transaction set mentioned below can be referred to as first information. Each transaction in the first transaction set corresponds to one first timestamp or first identifier. That is, the first timestamp and first identifier can be used to uniquely locate a transaction in the first transaction set. Furthermore, the first timestamp or first identifier can also be used to sort multiple transactions in the first transaction set to determine the transactions to be committed or the order in which multiple transactions are committed.

[0103] Optionally, during the process of obtaining the first operation set of the first transaction set, the first node may also record the end time (which can be called the first timestamp) or first identifier of the last operation of each transaction. The first timestamp may be the local timestamp of the first node at the end time of the last operation, the logical time in the database system, or the timestamp assigned by a specific central node, etc., and there is no specific limitation here. The first identifier may be a globally unique auto-incrementing transaction identifier in the database system.

[0104] Furthermore, if multiple nodes in a database system periodically send local operation sets to each other, the first node can also obtain the period identifier of each transaction. During database updates, if there are cross-period operation sets among the multiple operation sets—for example, one operation set is from the first period and another is from the second period—the order of transactions corresponding to the committed operation sets can be determined by the period number, thus ensuring synchronization between multiple databases. Of course, if there are cross-period operation sets among the multiple operation sets, there may also be operation sets within the same period. During database updates, the order of transactions corresponding to a small range of operation sets can be determined first based on the period identifier, and then the order of transaction commits can be determined based on the timestamp or identifier.

[0105] For example, if applied to an openGauss scenario, and Figure 1The four nodes shown are located in different regions, and each node can process all user-submitted transactions within its region. Specifically, after receiving a user's operation request and verifying its authentication, the first database connector passes the structured query language (SQL) statement to components such as the SQL parser and optimizer for lexical analysis, syntax analysis, and query optimization. First, it identifies system-supported keywords and identifiers from the query statement. Then, based on the standard SQL syntax rules, it matches the words generated during lexical analysis to these rules. If an SQL statement matches a syntax rule, a corresponding abstract syntax tree is generated. Finally, the query optimizer optimizes the SQL through query rewriting, using existing statement features and relational algebra operations to generate more efficient equivalent statements, and generates a final query plan based on cost estimation. A preset period is established; the first node must collect the operation sets of all nodes in the database system for that period before it can perform conflict detection and handling (which can also be understood as updating the database). For example, the first information includes the first period identifier and the first timestamp. The preset period is 50 milliseconds (ms), meaning a new synchronization period is generated every 50ms. It's important to note that a successfully executed transaction on the first node is not immediately written to the first database. It needs to be merged and verified with transactions corresponding to the operation sets sent by other nodes within the current period, and then the database is synchronized. When two transactions conflict within the same period, concurrency control follows the "first write wins" principle. Specifically, when two transactions attempt to modify the same data item, the transaction to be committed and the transaction to be rolled back are determined based on the timestamps of the two transactions (described in step 205 later, and will not be elaborated here). Understandably, the subsequent operations of the second node are similar to those of the first node, and will not be repeated here.

[0106] Step 202: The first node sends a first set of operations to the second node. Correspondingly, the second node receives the first set of operations sent by the first node.

[0107] After the first node obtains the first set of operations, it can send the first set of operations to the second node. Correspondingly, the second node receives the first set of operations sent by the first node.

[0108] It is understandable that the first node can send the first set of operations to the second node once or multiple times, that is, it can be sent in full or in batches, and the specific number is not limited here.

[0109] Optionally, if in step 201 above, the first node also obtains at least one of a first timestamp, a first identifier, or a first period identifier, the first node may also send at least one of the first timestamp, the first identifier, or the first period identifier to the second node. Accordingly, the second node receives at least one of the first timestamp, the first identifier, or the first period identifier sent by the first node.

[0110] For example, continuing the example from the openGauss scenario, at the end of a cycle, the first node sends the first set of operations to the other nodes in the database system. Ultimately, each node will have the operation set of all transactions within that cycle, and can then perform concurrency control according to the same rules (e.g., "first write wins"), thereby ensuring data consistency across all nodes. Understandably, the subsequent operations of the second node are similar to those of the first node, and will not be elaborated further.

[0111] Step 203: The second node obtains the second set of operations.

[0112] In this embodiment, the second node obtains the second operation set in a similar way to the first node obtains the first operation set. It can be obtained based on the operation instructions of the second user, or by other devices sending the second operation set; the specific method is not limited here. The second operation set refers to the write or read / write operations of the second transaction set in the second database within a target time period. Furthermore, the number of transactions in the second transaction set can be one or more, and the number of write or read / write operations in the second operation set is not limited. The target time period can be set according to actual needs; the specific method is not limited here.

[0113] The target time period in this step is similar to the target time period described in step 201 above. Optionally, the second node can acquire the second operation set in each cycle of a preset period and periodically send the operation set to the first node. There is no limit to the number of cycles. For example, if a cycle is 10 milliseconds, the target time period can be 10 milliseconds, meaning the second node will acquire the second operation set once every 10 milliseconds and send it to the first node once. The target time period can be referred to in the previous description, and will not be repeated here.

[0114] Optionally, the second database, similar to the first database, can provide write or read-write services to the second user. That is, the second user can perform a series of operations on the table entries in the second database within the second node, such as adding, deleting, modifying, and querying. During the execution of these operations, the second node records the second user's actions on the data items in the second database, thus obtaining the second operation set.

[0115] For example, the second node receives read and write instructions from the second user for the second database. The second node responds to these instructions by performing read and write operations on the table entries in the second database. During the execution of these read and write operations, it records the data items read and modified by the second user, thus obtaining the second read and write set. In this example, the second operation set is either a set of read and write operations or a set of write operations from the second transaction set; the specific setting depends on actual needs and is not limited here.

[0116] For example, the second node receives a write command from the second user for the second database. The second node responds to the write command by performing a write operation on the table entries in the second database. During the execution of this write operation, the node records the data items modified by the second user, thus obtaining the second write set. In this example, the second operation set is the set of write operations from the second transaction set.

[0117] For example, continuing with the second database, such as Figure 3 The example in Table 1 assumes that the second user's second set of transactions executed in the second database includes: Transaction 3. Transaction 3: Add "Zhou Qi", "15789012345", "Guangdong Province, Shenzhen City, Luohu District, No. W Primary School". Then the second set of operations includes: Add operations.

[0118] Similar to the aforementioned first information, for ease of subsequent description, at least one of the second timestamp, second identifier, or second period identifier mentioned later may be referred to as second information. Specifically, one transaction in the second transaction set corresponds to one second timestamp or second identifier. That is, the second timestamp and second identifier can be used to uniquely locate a single transaction. Furthermore, the second timestamp or second identifier can also be used to sort multiple transactions to determine the transactions to be committed or the order in which multiple transactions are committed.

[0119] Optionally, during the process of obtaining the second set of operations for the second transaction set, the second node may also record the end time (which can be called the second timestamp) or second identifier of the last operation of each transaction. The second timestamp may be the local timestamp of the second node at the end time of the last operation, the logical time in the database system, or the timestamp assigned by a specific central node, etc., and there is no specific limitation here. The second identifier may be a globally unique auto-incrementing transaction identifier in the database system.

[0120] Furthermore, if multiple nodes in a database system periodically send local operation sets to each other, the second node can also obtain the transaction period identifier. During database updates, if there are cross-period operation sets among the multiple operation sets—for example, one operation set is from the first period and another is from the second period—the order of committing transactions corresponding to the operation sets can be determined using the period number, thus ensuring synchronization between multiple databases. Of course, if there are cross-period operation sets among the multiple operation sets, there may also be operation sets within the same period. During database updates, the order of transactions corresponding to a small range of operation sets can be determined first based on the period identifier, and then the order of committing transactions can be determined based on the timestamp or transaction identifier.

[0121] Step 204: The second node sends the second set of operations to the first node. Correspondingly, the first node receives the second set of operations sent by the second node.

[0122] After the second node obtains the second set of operations, it can send the second set of operations to the first node. Correspondingly, the first node receives the second set of operations sent by the second node.

[0123] It is understandable that the first node can send the first set of operations to the second node once or multiple times, that is, it can be sent in full or in batches, and the specific number is not limited here.

[0124] Optionally, if in step 203 above, the second node also obtains at least one of a second timestamp, a second identifier, or a second periodic identifier, the second node may also send at least one of the second timestamp, the second identifier, or the second periodic identifier to the first node. Correspondingly, the first node receives at least one of the second timestamp, the second identifier, or the second periodic identifier sent by the second node.

[0125] Step 205: The first node updates the first database based on the first operation set and the second operation set.

[0126] After obtaining the first set of operations and the second set of operations, the first node can update the first database based on these sets. Specifically, the first node can first determine the transactions to be committed in the first database based on the first and second sets of operations, and then commit those transactions in the first database. In other words, the first node can determine the operations to be performed in the second database in the second node based on the second set of operations, and then execute the operations in the second set of operations. This ensures that the updates to the first database take into account the modifications to the second database, thereby guaranteeing data synchronization between the databases.

[0127] In one possible implementation, if the first transaction set consists of committable transactions in the first database, and the second transaction set consists of committable transactions in the second database, then when the first node updates the first database, it only needs to determine whether there are transaction conflicts between the first and second transaction sets. This is because whether there are conflicts between transactions in the first or second transaction sets has already been determined locally on each node. The determination of whether transactions conflict as described in this embodiment can be understood as determining whether each transaction is a transaction to be committed or a transaction to be rolled back.

[0128] In another possible implementation, if the first transaction set comprises all transactions in the first database, and the second transaction set comprises all transactions in the second database, then when the first node updates the first database, it needs to determine not only whether there are transaction conflicts between the first and second transaction sets, but also whether there are conflicts between multiple transactions within the first transaction set and between multiple transactions within the second transaction set.

[0129] Optionally, the first node can merge the first operation set and the second operation set, determine which operations in the first operation set and the second operation set conflict, identify the transactions to be committed and the transactions to be rolled back, and thus advance the database consistency point.

[0130] Optionally, the first node obtains at least one of the first timestamp, first identifier, or first period identifier (or first information) for each transaction in the first transaction set, and receives at least one of the second timestamp, second identifier, or second period identifier (or second information) sent by the second node. The first node can determine the transactions to be committed in the first transaction set and the second transaction set based on the first operation set, the first information, the second operation set, and the second information, and commit the transactions to be committed in the first database to obtain the updated first database.

[0131] Furthermore, if there are no conflicts between the transactions in the first and second transaction sets, then all transactions in both sets can be considered as transactions to be committed. If there are conflicts between the transactions in the first and second transaction sets (these conflicting transactions can be called conflicting transactions), then the transactions to be committed and the transactions to be rolled back within the conflicting transactions can be determined according to preset rules. The transactions to be committed will be committed, and the transactions to be rolled back will be rolled back. These preset rules can be set according to actual needs, and are not limited here. For example, the preset rule could be that the transaction with the smaller timestamp among the conflicting transactions is the transaction to be committed, or the transaction with the larger timestamp is the transaction to be committed.

[0132] Understandably, when the first transaction set includes multiple first sub-transactions and the second transaction set includes multiple second sub-transactions, to determine whether multiple first sub-transactions conflict with multiple second sub-transactions, it is assumed that there is a target sub-transaction among the multiple first sub-transactions. This target sub-transaction needs to be used to perform conflict detection with all other remaining transactions. Only when there is no conflict with all other transactions can the target sub-transaction be determined as a transaction to be committed.

[0133] For example, in a scenario where the first transaction set includes multiple first sub-transactions and the second transaction set includes multiple second sub-transactions, if it is determined whether a sub-transaction 11 conflicts with a sub-transaction 12, and the timestamp of sub-transaction 11 is greater than the timestamp of sub-transaction 12, then sub-transaction 11 with the larger timestamp is a transaction to be rolled back, while sub-transaction 12 with the smaller timestamp is not rolled back. However, sub-transaction 12 is not necessarily a transaction to be committed. This is because sub-transaction 12 still needs to undergo conflict checks with other transactions before it can be determined whether sub-transaction 12 is a transaction to be committed. After all transactions have been compared, the transactions that are determined not to be rolled back can be committed. It is understood that the identifiers of sub-transaction 11 and sub-transaction 12 (i.e., 11 and 12) here are just examples.

[0134] It should be noted that the method in this application embodiment can be applied to the OCC scenario, in which "commit" in the commit transaction is equivalent to actually writing the data updated by the write operation into the database.

[0135] For example, in the first transaction set, the first information of the first sub-transaction is the first timestamp, and in the second transaction set, the second information of the second sub-transaction is the second timestamp. If the first and second sub-transactions include at least one overlapping data item, and the first timestamp of the first sub-transaction is less than the second timestamp of the second sub-transaction, then the first sub-transaction can be determined as a transaction that does not need to be rolled back, and the second sub-transaction as a transaction that needs to be rolled back. After comparing the timestamps of the first sub-transaction with those of all other transactions, the transactions that do not need to be rolled back are determined as transactions to be committed. Alternatively, the transaction with the larger timestamp can be the one that does not need to be rolled back, and the transaction with the smaller timestamp can be the one to be rolled back.

[0136] Additionally, the first node can determine the commit order of transactions to be committed based on the first and second information. Specifically, if multiple nodes in the database system periodically send local operation sets to each other, this step can also be periodic. Furthermore, if there are cross-period operation sets among the multiple operation sets—for example, one operation set is from the first period and another from the second period—the order of committing transactions corresponding to the operation sets can be determined using the period number, thereby ensuring synchronization between multiple databases. Of course, if there are cross-period operation sets among the multiple operation sets, there may also be operation sets within the same period. During database updates, the order of transactions corresponding to a small range of operation sets can be determined first based on the period identifier, and then the order of committing transactions can be determined based on the timestamp or transaction identifier.

[0137] Optionally, after updating the first database, the first node can log or update a snapshot.

[0138] For example, continuing the previous example, the first set of transactions executed by the first user in the first database includes: Transaction 1 and Transaction 2. Transaction 1: Deletes "Sun Wu". Transaction 2: Modifies the "delivery address" of "Li Liu" to "Room 801, F Hotel, E Street, Nanshan District, Shenzhen, Guangdong Province". The first set of operations in the first set of transactions includes: deletion operations and modification operations. The second set of transactions executed by the second user in the second database includes: Transaction 3. Transaction 3: Adds "Zhou Qi", "15789012345", and "W Primary School, Luohu District, Shenzhen, Guangdong Province". The second set of operations includes: add operations. The process of the first node updating the first database based on the first set of operations and the second set of operations is as follows: Figure 4 As shown, the updated first database is as follows: Figure 4 As shown in Table 2.

[0139] For example, continuing the example from the openGauss scenario, after receiving the set of transaction operations sent by other nodes in the current period, the first node parses out the relevant transaction data and uses the same rules to implement concurrency control (which can also be understood as determining the transactions to be committed and the transactions to be rolled back). It commits the transactions to be committed and rolls back the transactions to be rolled back. It is understood that the subsequent operations of the second node are similar to those of the first node, and will not be elaborated further.

[0140] Step 206: The second node updates the second database based on the first operation set and the second operation set.

[0141] After obtaining the first and second operation sets, the second node can update the second database based on these sets. Specifically, the second node can first determine the transactions to be committed in the second database based on the first and second operation sets, and then commit those transactions in the second database. In other words, the second node can determine the operations to be performed in the first database from the first node based on the first operation set, and then execute the operations in the first operation set. This ensures that the updates to the second database take into account the modifications to the first database, thereby guaranteeing data synchronization between the databases.

[0142] Optionally, the second node obtains at least one of the second timestamp, second identifier, or second period identifier (or second information) for each transaction in the second transaction set, and receives at least one of the first timestamp, first identifier, or second period identifier (or first information) sent by the first node. The second node can determine the transactions to be committed in the first transaction set and the second transaction set based on the first operation set, the first information, the second operation set, and the second information, and commit the transactions to be committed in the second database to obtain the updated second database.

[0143] For descriptions regarding overlapping data items between transactions in the first and second transaction sets, transactions to be committed, and transactions to be rolled back, please refer to the description in step 205 above, which will not be repeated here.

[0144] Optionally, after updating the second database, the second node can log or update a snapshot.

[0145] For example, continuing the previous example, the first transaction set includes: Transaction 1 and Transaction 2. Transaction 1: Deletes "Sun Wu". Transaction 2: Modifies the "delivery address" of "Li Liu" to "Room 801, F Hotel, E Street, Nanshan District, Shenzhen, Guangdong Province". The first operation set of the first transaction set includes: deletion and modification operations. The second operation set includes: addition processing. The second transaction includes: adding "Zhou Qi", "15789012345", and "W Primary School, Luohu District, Shenzhen, Guangdong Province". Then the process of the second node updating the second database based on the first operation set and the second operation set is as follows: Figure 4 As shown, the updated second database is as follows Figure 4 As shown in Table 2.

[0146] It is understood that the embodiments of this application do not limit the timing of the above steps. For example, step 203 may precede step 202 or step 201. Another example is that step 206 may follow step 205, etc., and no specific limitation is made here.

[0147] Furthermore, steps 201 to 206 in this process can be executed periodically. In this embodiment, the number of times steps 201 to 206 are executed can be once or multiple times; no specific limitation is made here. Of course, if the execution is periodic, transactions in the new cycle cannot be committed until the previous cycle is synchronized and completed.

[0148] In this embodiment, the first node obtains a first set of operations related to a first set of transactions in the first database, receives a second set of operations related to a second set of transactions in the second database sent by the second node, and updates the first database based on the first and second sets of operations. This ensures that the update of the first database takes into account the transactions committed by other databases, thereby guaranteeing update synchronization among multiple databases. On one hand, transaction modifications are communicated between nodes by transmitting operation sets, avoiding multiple interactions between nodes and minimizing communication overhead. On the other hand, compared to the two-phase commit method, it avoids the inability to operate transactions due to a single point of failure of the coordinator.

[0149] The database processing method in the embodiments of this application has been described above. The first node and the second node in the embodiments of this application are described below. The first node and the second node are applied to a database system. The first node deploys a first database, and the second node deploys a second database. The first database and the second database store the same data. Please refer to [link to relevant documentation]. Figure 5 One embodiment of the first node in this application includes:

[0150] The acquisition unit 501 is used to acquire a first operation set, which is a set of write or read / write operations of a first transaction set in a first database within a target time period.

[0151] Sending unit 502 is used to send the first operation set to the second node;

[0152] The receiving unit 503 is used to receive the second operation set sent by the second node. The second operation set is the write operation or read-write operation of the second transaction set in the second database within the target time period. The first operation set and the second operation set are used by the second node to update the second database.

[0153] Update unit 504 is used to update the first database based on the first operation set and the second operation set.

[0154] In this embodiment, the operations performed by each unit in the first node are the same as those described above. Figures 1 to 4 The embodiments shown are similar and will not be repeated here.

[0155] In this embodiment, multiple nodes in the database system send transaction operation sets to each other. Updates on a node's database take into account transactions committed by other databases, thus ensuring synchronization of updates across multiple databases. On one hand, transaction modifications are communicated between nodes by transmitting operation sets, avoiding multiple interactions between nodes and minimizing communication overhead. On the other hand, compared to the two-phase commit method, it avoids the inability to operate transactions due to a single point of failure in the coordinator.

[0156] Please see Figure 6 One embodiment of the second node in this application includes:

[0157] The acquisition unit 601 is used to acquire the second operation set, which is the write operation or read / write operation of the second transaction set in the second database within the target time period;

[0158] Sending unit 602 is used to send the second operation set to the first node;

[0159] The receiving unit 603 is used to receive a first operation set sent by the first node. The first operation set is a write operation or read-write operation of a first transaction set in the first database within a target time period. The first operation set and the second operation set are used by the first node to update the first database.

[0160] Update unit 604 is used to update the second database based on the first operation set and the second operation set.

[0161] In this embodiment, the operations performed by each unit in the second node are the same as those described above. Figures 1 to 4 The embodiments shown are similar and will not be repeated here.

[0162] In this embodiment, multiple nodes in the database system send transaction operation sets to each other. Updates on a node's database take into account transactions committed by other databases, thus ensuring synchronization of updates across multiple databases. On one hand, transaction modifications are communicated between nodes by transmitting operation sets, avoiding multiple interactions between nodes and minimizing communication overhead. On the other hand, compared to the two-phase commit method, it avoids the inability to operate transactions due to a single point of failure in the coordinator.

[0163] See Figure 7 This application provides a schematic diagram of the structure of a communication device. This communication device can be one of the aforementioned... Figures 1 to 4 The first node or the second node in the illustrated embodiment. The communication device may include a processor 701, a memory 702, and a communication interface 703. The processor 701, memory 702, and communication interface 703 are interconnected via lines. The memory 702 stores program instructions and data.

[0164] In one possible implementation, the memory 702 stores the aforementioned Figures 1 to 4 In the corresponding implementation, the program instructions and data corresponding to the steps executed by the first node. Processor 701 is used to execute the aforementioned... Figures 1 to 4 The steps performed by the first node are shown in any of the embodiments illustrated. Communication interface 703 can be used to perform the aforementioned steps. Figures 1 to 4 The steps related to acquisition, sending, and receiving are performed by the first node in any of the illustrated embodiments. For example, communication interface 703 can be used to send a first set of operations and first information, and to receive a second set of operations and second information.

[0165] In another possible implementation, the aforementioned memory 702 stores... Figures 1 to 4 In the corresponding implementation, the program instructions and data corresponding to the steps executed by the second node. Processor 701 is used to execute the aforementioned... Figures 1 to 4 The steps performed by the second node are shown in any of the embodiments illustrated. Communication interface 703 can be used to perform the aforementioned steps. Figures 1 to 4 The second node performs steps related to acquisition, sending, and receiving in any of the embodiments shown. For example, communication interface 703 can be used to send a second set of operations and second information, and to receive a first set of operations and first information.

[0166] It is understandable that communication equipment may include, relative to Figure 7 More or fewer components are merely illustrative in this application and are not intended to limit the scope of the application.

[0167] In addition, embodiments of this application provide a database system, which includes the features described above. Figure 5 The first node shown, and / or as described above Figure 6 The second node is shown. Or the database system includes, as described above. Figure 7 The communication device shown.

[0168] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, or indirect coupling or communication connection between apparatuses or units, and may be electrical, mechanical, or other forms.

[0169] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0170] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated units described above can be implemented wholly or partially through software, hardware, firmware, or any combination thereof.

[0171] When the integrated unit is implemented using software, it can be implemented wholly or partially in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of the present invention are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state disk (SSD)).

[0172] The terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such terms are interchangeable where appropriate; this is merely a way of distinguishing objects with the same attributes in the embodiments of this application. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion, so that a process, method, system, product, or apparatus that comprises a series of elements is not necessarily limited to those elements, but may include other elements not explicitly listed or inherent to those processes, methods, products, or apparatuses.

Claims

1. A database processing method, characterized in that, The method is applied to a database system, which includes a first node and a second node. The first node deploys a first database, and the second node deploys a second database. The first database and the second database store the same data. The method includes: The first node obtains a first set of operations, which consists of write operations or read / write operations of the first transaction set in the first database within the target time period. The first node sends the first set of operations to the second node; The first node receives a second set of operations sent by the second node. The second set of operations consists of write operations or read / write operations of a second set of transactions in the second database within the target time period. The first set of operations and the second set of operations are used by the second node to update the second database. The first node updates the first database based on the first set of operations and the second set of operations.

2. The method according to claim 1, characterized in that, The first node obtains the first set of operations, including: The first node responds to and executes the first user's operation instructions for the first database; During the execution of the operation instructions, the first node records the first user's operations on data items in the first database, thus obtaining the first operation set.

3. The method according to claim 2, characterized in that, The operation instruction is a write instruction, and the first operation set is a write operation set; or, the operation instruction is a read / write instruction, and the first operation set is a read / write operation set or a write operation set.

4. The method according to any one of claims 1 to 3, characterized in that, The method further includes: The first node obtains the first information of the first transaction set, where each transaction in the first transaction set corresponds to a piece of first information, and the first information includes a first identifier and / or a first timestamp; The first node sends the first information to the second node; The first node receives second information sent by the second node. Each transaction in the second transaction set corresponds to a piece of second information. The second information includes a second identifier and / or a second timestamp. The first information and the second information are used by the second node to update the second database. The first node updates the first database based on the first operation set and the second operation set, including: The first node updates the first database based on the first operation set, the first information, the second operation set, and the second information.

5. The method according to claim 4, characterized in that, The first node updates the first database based on the first operation set, the first information, the second operation set, and the second information, including: The first node determines the transactions to be committed in the first transaction set and the second transaction set based on the first operation set, the first information, the second operation set, and the second information; The first node submits the transaction to be submitted in the first database, thereby obtaining the updated first database.

6. The method according to claim 5, characterized in that, The first information of the first sub-transaction in the first transaction set is the first timestamp, the second information of the second sub-transaction in the second transaction set is the second timestamp, the first sub-transaction and the second sub-transaction include at least one overlapping data item, the first timestamp is less than the second timestamp, and the second sub-transaction is a transaction that cannot be committed.

7. A first node, characterized in that, The first node is applied to a database system, which further includes a second node. The first node deploys a first database, and the second node deploys a second database. The first database and the second database store the same data. The first node includes: The acquisition unit is used to acquire a first set of operations, wherein the first set of operations consists of write operations or read / write operations of a first set of transactions in the first database within a target time period. The sending unit is used to send the first operation set to the second node; The receiving unit is configured to receive a second set of operations sent by the second node. The second set of operations consists of write operations or read / write operations of a second set of transactions in the second database within the target time period. The first set of operations and the second set of operations are used by the second node to update the second database. The update unit is used to update the first database based on the first operation set and the second operation set.

8. The first node according to claim 7, characterized in that, The acquisition unit is specifically used to respond to and execute the operation instructions of the first user on the first database; The acquisition unit is specifically used to record the first user's operations on data items in the first database during the execution of the operation instruction, thereby obtaining the first operation set.

9. The first node according to claim 8, characterized in that, The operation instruction is a write instruction, and the first operation set is a write operation set; or, the operation instruction is a read / write instruction, and the first operation set is a read / write operation set or a write operation set.

10. The first node according to any one of claims 7 to 9, characterized in that, The acquisition unit is further configured to acquire first information of the first transaction set, wherein each transaction in the first transaction set corresponds to a first information, and the first information includes a first identifier and / or a first timestamp; The sending unit is further configured to send the first information to the second node; The receiving unit is further configured to receive second information sent by the second node, wherein each transaction in the second transaction set corresponds to a second piece of information, and the second information includes a second identifier and / or a second timestamp; the first information and the second information are used by the second node to update the second database; The update unit is specifically used to update the first database based on the first operation set, the first information, the second operation set, and the second information.

11. The first node according to claim 10, characterized in that, The update unit is specifically used to determine the transactions to be committed in the first transaction set and the second transaction set based on the first operation set, the first information, the second operation set, and the second information. The update unit is specifically used to submit the transaction to be submitted in the first database to obtain the updated first database.

12. The first node according to claim 11, characterized in that, The first information of the first sub-transaction in the first transaction set is the first timestamp, the second information of the second sub-transaction in the second transaction set is the second timestamp, the first sub-transaction and the second sub-transaction include at least one overlapping data item, the first timestamp is less than the second timestamp, and the second sub-transaction is a transaction that cannot be committed.

13. A first node, characterized in that, include: A processor coupled to a memory for storing a program or instructions which, when executed by the processor, cause the first node to perform the method as described in any one of claims 1 to 6.

14. A computer storage medium, characterized in that, Includes computer instructions that, when executed on an electronic device, cause the electronic device to perform the method as described in any one of claims 1 to 6.

15. A computer program product, characterized in that, When the computer program product is run on a computer, it causes the computer to perform the method as described in any one of claims 1 to 6.

Images