Transaction processing device and transaction processing method

Abstract

In an availability unit (12), for a transaction involving entities that are part of a data set stored in each replica, the replicas read the entities involved in the transaction before a coordinator for coordinating between the replicas determines the timestamp of the transaction. Furthermore, when committing the transaction, the availability unit (12) causes the replicas to reflect the write values calculated by the coordinator.

Description

Transaction processing device and transaction processing method

[0001] The present invention relates to a transaction processing device and a transaction processing method.

[0002] Distributed database management systems (DVTs) are emerging that achieve high availability and scalability by dividing and replicating databases across multiple servers. In such DVTs, the mechanism for executing transactions in parallel while maintaining database integrity and replication consistency is called distributed transaction processing. A transaction is a series of read and write operations on a database entity.

[0003] Traditionally, Janus is a partial state machine replication protocol designed for transaction processing on databases. Transactions executable with Janus are limited to one-shot transactions. A one-shot transaction is a model that executes transactions non-interactively, consisting of a collection of operations confined to individual partitions. Therefore, it cannot perform operations that read or write data across partitions. Janus forms a consensus on the dependency graph between transactions, allowing transactions to be committed in 1-2 round-trip times (RTTs). Transaction logic is executed asynchronously and with a delay after commit.

[0004] Accord is also a partial state machine replication protocol designed for transaction processing on databases. Accord assumes that the entities being accessed are known, non-interactive, and involve a single read-modify-write operation to multiple entities. Unlike Janus, Accord allows reading and writing data across partitions. Accord forms an agreement on the execution timestamp of a transaction and executes the transaction while resolving dependencies based on that timestamp. This allows transactions to be committed in 1-2 RTTs, although an additional 2 RTTs of communication are required after the commit to execute the transaction logic.

[0005] Benedict Elliott Smith, Tony Zhang, Blake Eggleston, and Scott Andreas. "CEP-15: General purpose transactions.", 2021 [online], [Retrieved February 6, 2025], Internet <https: / / cwiki.apache.org / confluence / x / FQRACw>

[0006] However, conventional technologies had the problem that transaction execution could be delayed. For example, although Accord can commit transactions in 1-2 RTT, it delayed the execution of logic after the transaction was committed, which caused a chain reaction of delays in the execution of subsequent transactions that depended on that transaction. Janus, on the other hand, had the problem of being less convenient because it could only execute one-shot transactions.

[0007] To solve the above-mentioned problems and achieve the objective, the transaction processing device of the present invention is characterized by having a read unit that reads the entity related to the transaction in a transaction targeting an entity which is part of a data set stored in each replica, before the coordinator that performs arbitration between replicas determines the timestamp of the transaction, and a reflect unit that reflects the write value calculated by the coordinator to the replica at the time of the transaction commit.

[0008] According to the present invention, it is possible to reduce the execution delay of transactions.

[0009] Figure 1 is a diagram showing an example configuration of a transaction processing system according to an embodiment. Figure 2 is a diagram showing the flow of a conventional transaction processing system. Figure 3 is a diagram showing the flow of transaction processing according to an embodiment. Figure 4 is a diagram illustrating an example of a transaction processing algorithm according to an embodiment. Figure 5 is a flowchart showing the processing flow of a transaction processing device according to an embodiment. Figure 6 is a diagram showing an example of a computer that executes a transaction processing program.

[0010] Hereinafter, one embodiment of the present invention will be described in detail with reference to the drawings. However, the present invention is not limited to this embodiment. Furthermore, in the drawings, the same parts are denoted by the same reference numerals.

[0011] Figure 1 shows an example configuration of a transaction processing system according to an embodiment. As shown in Figure 1, the transaction processing system has a plurality of availability units (availability unit 12, availability unit 22, and availability unit 32). The availability unit is an example of a transaction processing device.

[0012] Availability units may be determined based on the required fault tolerance, such as from a single server rack (or server racks per region or country). An availability unit may consist of one server or multiple servers (e.g., a data center and server racks). Data is replicated between availability units to ensure fault tolerance.

[0013] For example, in order to tolerate a power failure in a server rack, each server rack with a different power supply system needs to be replicated as an availability unit.

[0014] For example, to tolerate system failures caused by regional disasters, it is necessary to replicate data centers in different regions as availability units.

[0015] Furthermore, for example, to allow for system access to be blocked due to political reasons, it would be necessary to replicate data centers in different countries as availability units.

[0016] For example, if only a single server failure is acceptable, then multiple different servers within the same data center can be replicated as availability units.

[0017] The availability unit 12 includes an application 121, a coordinator 122, a replica X1, and a replica Y1. The application 121 functions as a client that requests each transaction operation based on the actions of user 11, etc. The coordinator 122 executes transaction operations and mediates between replicas. Replicas X1 and Y1 are database partitions.

[0018] Availability units 22 and 32 have the same configuration as availability unit 12. Specifically, availability unit 22 has application 221, coordinator 222, replica X2, and replica Y2. Availability unit 32 has application 321, coordinator 322, replica X3, and replica Y3. Availability unit 22 is operated by user 21, and availability unit 32 is operated by user 31. Note that the configuration in the figure is just an example, and for example, the coordinator and replicas, or the coordinator and application, can run on the same computer. In addition, each availability unit 12, 22, and 32 may replicate only a part of the entire data set. Also, although Figure 1 illustrates the case where X and Y exist as database partitions, there may be any number of database partitions, not limited to X and Y.

[0019] Furthermore, availability units 12, 22, and 32 are connected by a network and are capable of data communication with each other. The coordinators are also capable of data communication with each replica. For example, the solid lines connecting coordinator 122 to each replica indicate that coordinator 122 can communicate with each replica. Although the solid lines are omitted in Figure 1, coordinators 222 and 322 are similarly capable of data communication with each replica of the other availability units.

[0020] Coordinator 122 has a consensus formation unit 122A, a calculation unit 122B, and a reflection unit 12C. While the other coordinators 222 and 322 have a similar configuration to coordinator 122, their respective functional units are omitted from the diagram for convenience.

[0021] The consensus formation unit 122A performs processing to form an agreement on the execution timestamp of a transaction. For example, when the consensus formation unit 122A receives a transaction to be executed, it assigns a unique timestamp to the transaction and performs processing to form an agreement on the execution timestamp.

[0022] The calculation unit 122B calculates the write value when the transaction is committed. For example, when agreement on the execution timestamp is completed and the transaction is committed, the calculation unit 122B calculates the value to be written based on the transaction logic.

[0023] The reflection unit 122C reflects the write value calculated by the coordinator to the replica when a transaction is committed. For example, the reflection unit 122C includes the write value calculated by the calculation unit 122B in the commit message (hereinafter referred to as the commit message) and sends this message to the replica, thereby reflecting the write value to the replica.

[0024] Furthermore, replicas X1 and Y1 each have a reading unit 123A and a writing unit 123B. Note that the other replicas X2 and Y2 have the same configuration as replicas X3 and Y3, but for convenience, the descriptions of each functional unit are omitted in the diagram.

[0025] The reading unit 123A reads the entities involved in a transaction that targets entities, which are part of the data set stored in each replica, before the coordinator that mediates between replicas determines the transaction's timestamp.

[0026] The write unit 123B writes the write value calculated by the coordinator when a transaction is committed. For example, when the write unit 123B receives a commit message sent from the coordinator, it reflects the write value included in the commit message.

[0027] Thus, in this embodiment, the availability unit 12 reads the entities involved in a transaction that targets entities which are part of the data set stored in each replica, before the coordinator that mediates between replicas determines the transaction's timestamp. Then, at the time of transaction commit, the availability unit 12 reflects the write value calculated by the coordinator to the replica. For this reason, the availability unit 12 in this embodiment can reduce execution delays by, for example, extending Accord to speculatively execute transactions when consensus is reached on the transaction's execution timestamp.

[0028] Here, Figure 2 shows the transaction processing flow in conventional Accord. Figure 2 is a diagram illustrating the conventional transaction processing flow. As illustrated in Figure 2, the coordinator assigns a unique timestamp to the transaction and forms an agreement on the execution timestamp (see (1) and (2) in Figure 2). Then, once an agreement on the execution timestamp is formed, the availability unit confirms the transaction commit (see (3) in Figure 2). The transaction commit delay is 1 RTT when there are no conflicts, and 2 RTT when there are conflicts.

[0029] Subsequently, the target replica reads the entities involved in the transaction and passes the data to the coordinator (see (4) in Figure 2). Then, the target replica calculates the write values ​​based on the transaction logic and reflects the transactional changes in all replicas (see (5) in Figure 2).

[0030] Traditional Accord delays logic execution after a transaction commit, requiring an additional 1 RTT (Return to Time) for each read and write operation. Consequently, subsequent transactions that depend on a particular transaction must wait until the transaction's write operation is complete, leading to a chain reaction of delays in the execution of conflicting transactions.

[0031] In contrast, the availability unit 12 according to this embodiment reduces execution delay by executing transactions speculatively. The transaction processing flow according to the embodiment will now be explained using Figure 3. Figure 3 is a diagram showing the transaction processing flow according to the embodiment. In the following example, it is assumed that, similar to Accord, the read set and write set of transactions are known before execution, and the transaction logic is a single read-modify-write for multiple entities.

[0032] As illustrated in Figure 3, the coordinator 122 of the availability unit 12 sends a Pre-Accept message to each replica in order to form an agreement on the execution timestamp of a transaction. Each replica then performs a speculative read when forming an agreement on the execution timestamp of a transaction. Each replica then reads the entities involved in the transaction and returns the read entities to the coordinator 122 (see (1) in Figure 3).

[0033] Next, the coordinator 122 sends an Accept message to each replica in order to reach an agreement on the transaction execution timestamp. When each replica receives this Accept message, it may speculatively read an entity to reach an agreement on the transaction execution timestamp. In this case, each replica returns the read entity to the coordinator 122 (see (2) in Figure 3). The timing of when the replica reads the entity is either when it receives the Pre Accept message or when it receives the Accept message. Furthermore, if the agreement on the execution timestamp is successful due to the Pre Accept message, the sending and receiving of the Accept message may be omitted.

[0034] Next, the coordinator 122 calculates the write value at the time of commit and sends it to the replica along with the write value in the commit message. The replica then reflects the write value included in the commit message (see (3) in Figure 3).

[0035] Thus, the availability unit 12 according to this embodiment speculatively reads at the start of consensus formation of execution timestamps, constructs a consistent snapshot upon completion of consensus formation, calculates the values ​​to be written based on the transaction logic, and reflects the written values ​​at commit. As a result, the availability unit 12 according to this embodiment can, for example, commit a single read-modify-write to multiple non-interactive entities with known access entities in 1-2 RTTs, similar to Accord, and can reduce the execution delay of the transaction logic by up to 2 RTTs. In this way, the availability unit 12 mitigates the problem of cascading delays in dependent transactions while maintaining the convenience of Accord.

[0036] Figure 4 illustrates the transaction processing algorithm implemented by the availability unit of this specific embodiment. In the example in Figure 4, the transaction transitions through the states in the order of PreAccepted, Accepted, Committed, and Executed. Also, in the example in Figure 4, the initial execution timestamp assigned to transaction τ by the coordinator 122 is ts ０ τ The algorithm illustrated in Figure 4 includes the process of the replicas reading the entities involved in a transaction before the coordinator 122, which performs arbitration between replicas, determines the transaction's timestamp, and the process of reflecting the write value calculated by the coordinator 122 to the replicas when the transaction is committed.

[0037] As illustrated in Figure 4, for example, the coordinator 122 processes transaction τ and initial execution timestamp ts ０ A PreAccept message containing the above is sent to the replica (see the third line of the algorithm in Figure 4).

[0038] And, when forming an agreement on the execution timestamp of transaction τ, for each replica, when the initial execution timestamp of transaction γ that depends on transaction τ on the replica is ts ０ γ < ts ０ τ If the state of all transactions γ with this condition is Executed, the coordinator executes the read of transaction τ and returns the set of read entities as rs τ to the coordinator (see line 11 of Algorithm in FIG. 4).

[0039] And, when the coordinator 122 receives valid rs τ from all replicas in the supermajority quorum Q ∈ F τ or, when a supermajority cannot be obtained, when receiving valid rs τ from all replicas in the majority quorum Q ∈ F τ it calculates the set of entities ws to be written according to the logic of transaction τ and includes ws when sending the commit message (see lines 17 and 35 of the algorithm in FIG. 4). Thus, the coordinator 122 reflects the write at the time of commit. Note that when the availability unit 12 fails to obtain valid rs τ it performs read and write again after commit.

[0040] (Transaction Processing) Next, referring to FIG. 5, an example of the presentation processing by the transaction processing apparatus 10 according to the present embodiment will be described. FIG. 5 is a flowchart showing the processing flow of the transaction processing apparatus according to the embodiment.

[0041] As illustrated in FIG. 5, when the transaction processing apparatus 10 receives a transaction to be executed from a client (YES in step S101), the coordinator 122 starts forming an agreement on the execution timestamp of the transaction (step S102).

[0042] Then, the replica speculatively reads the data before determining the transaction execution timestamp (step S103). The coordinator 122 then calculates the write value at commit time (step S104) and sends the commit message containing the write value to the replica (step S105). Subsequently, the replica reflects the write value included in the commit message (step S106).

[0043] (Effects) As described above, in the availability unit 12 of this embodiment, in a transaction targeting an entity which is part of the data set stored in each replica, the replica reads the entity involved in the transaction before the coordinator that arbitrates between replicas determines the transaction's timestamp. Then, at the time of transaction commit, the availability unit 12 reflects the write value calculated by the coordinator to the replica. For this reason, the availability unit 12 of this embodiment can reduce execution delay.

[0044] Furthermore, the availability unit 12 calculates the write value when the coordinator 122 commits a transaction and reflects the calculated write value in the replica. The availability unit 12 then includes the calculated write value in the message related to the commit and sends this message to the replica, thereby reflecting the write value in the replica.

[0045] Therefore, for example, the availability unit 12 according to this embodiment can commit a single read-modify-write to multiple entities in 1-2 RTTs, even if the entities being accessed are known, similar to Accord, and can reduce the execution delay of the transaction logic by up to 2 RTTs. As a result, the availability unit 12 can mitigate the problem of dependent transactions being delayed in a chain reaction while maintaining the convenience of Accord.

[0046] (Program) In one embodiment, a transaction processing device can be implemented by installing a transaction processing program, which performs the above processing as packaged software or online software, on a desired computer. For example, by having an information processing device execute the above transaction processing program, the information processing device can be made to function as a transaction processing device. The information processing device referred to here includes desktop or notebook personal computers. In addition, the information processing device also includes smartphones, tablet terminals, and the like.

[0047] Figure 6 shows an example of a computer that executes a transaction processing program. Computer 1000 has, for example, memory 1010 and CPU 1020. Computer 1000 also has a hard disk drive interface 1030, a disk drive interface 1040, a serial port interface 1050, a video adapter 1060, and a network interface 1070. These components are connected by a bus 1080.

[0048] Memory 1010 includes ROM (Read Only Memory) 1011 and RAM (Random Access Memory) 1012. ROM 1011 stores, for example, a boot program such as BIOS (Basic Input Output System). The hard disk drive interface 1030 is connected to the hard disk drive 1090. The disk drive interface 1040 is connected to the disk drive 1100. For example, a removable storage medium such as a magnetic disk or optical disk is inserted into the disk drive 1100. The serial port interface 1050 is connected to, for example, a mouse 1110 and a keyboard 1120. The video adapter 1060 is connected to, for example, a display 1130.

[0049] The hard disk drive 1090 stores, for example, the OS 1091, application programs 1092, program modules 1093, and program data 1094. That is, the programs that define each process of the transaction processing unit are implemented as program modules 1093 in which executable code for the computer is written. The program modules 1093 are stored, for example, in the hard disk drive 1090. For example, a program module 1093 for performing processes similar to the functional configuration in the transaction processing unit is stored in the hard disk drive 1090. Note that the hard disk drive 1090 may be replaced by an SSD.

[0050] Furthermore, the configuration data used in the processing of the above-described embodiment is stored as program data 1094 in, for example, memory 1010 or hard disk drive 1090. The CPU 1020 then reads the program module 1093 and program data 1094 stored in memory 1010 or hard disk drive 1090 into RAM 1012 as needed and executes the processing of the above-described embodiment.

[0051] Furthermore, the program module 1093 and program data 1094 are not limited to being stored in the hard disk drive 1090; for example, they may be stored in a removable storage medium and read by the CPU 1020 via a disk drive 1100 or the like. Alternatively, the program module 1093 and program data 1094 may be stored in another computer connected via a network (LAN (Local Area Network), WAN (Wide Area Network), etc.). The program module 1093 and program data 1094 may then be read by the CPU 1020 from the other computer via a network interface 1070.

[0052] Although embodiments applying the invention made by the present inventors have been described above, the present invention is not limited by the descriptions and drawings that constitute part of the disclosure of the present invention in this embodiment. That is, all other embodiments, examples, and operational techniques made by those skilled in the art based on this embodiment are included in the scope of the present invention.

[0053] 10 Transaction Processing Units 11, 21, 31 Users 12, 22, 32 Availability Units 121, 221, 321 Applications 122, 222, 322 Coordinators X1, Y1, X2, Y2, X3, Y3 Replicas

Claims

1. A transaction processing device characterized by having a read unit that reads the entities related to a transaction in a transaction that targets entities which are part of a data set stored in each replica, before a coordinator that mediates between replicas determines the timestamp of the transaction, and a reflect unit that reflects the write value calculated by the coordinator to the replica when the transaction is committed.

2. The transaction processing device according to claim 1, wherein the coordinator further comprises a calculation unit that calculates a write value when the transaction is committed, and the reflection unit reflects the write value calculated by the calculation unit to the replica.

3. The transaction processing device according to claim 2, characterized in that the reflection unit includes the write value calculated by the calculation unit in the message relating to the commit, and sends the message to the replica, thereby reflecting the write value in the replica.

4. A transaction processing method executed by a transaction processing device, characterized in that, in a transaction targeting an entity which is part of a data set stored in each replica, the replica reads the entity related to the transaction before a coordinator performing mediation between replicas determines the timestamp of the transaction, and the reflection step reflects the write value calculated by the coordinator to the replica at the time of the transaction commit.

Images