Transaction processing method, distributed database system, cluster and medium

Abstract

The application provides a transaction processing method, which is executed by a distributed database system, the system comprising a coordination node and a participation node, the coordination node and the participation node sharing a global memory, the method comprising: the coordination node receiving a plurality of query statements sent by a client, creating a transaction according to a first query statement in the plurality of query statements, executing the transaction in the global memory according to a second query statement in the plurality of query statements, and submitting the transaction according to a third query statement in the plurality of query statements. Since the global memory can be accessed across nodes without being processed by a processor and an operating system, the access path is shortened, and the synchronization time is further shortened without being scheduled by the operating system, so that real-time consistency between the coordination node and the participation node is realized, and the business requirement is met.

Description

Technical Field

[0001] This application relates to the field of database technology, and in particular to a transaction processing method, a distributed database system, a transaction processing system, a cluster, a computer-readable storage medium, and a computer program product. Background Technology

[0002] With the continuous development of database technology, managing data (such as employee attendance data, employee salary data, production data, etc.) through databases has gradually become a mainstream trend. A database is a collection of data stored together in a certain way, which can be shared by multiple users, has minimal redundancy, and is independent of application programs. Users can access the database through client applications (hereinafter referred to as clients) to read or write data.

[0003] Data reading and writing are typically implemented by a database system. A database system includes a database management system (DBMS). The database system uses the DBMS to create, query, update, and delete data. Specifically, users trigger operations on data in the database through a client, and the database system responds by executing the corresponding transaction. Taking data writing as an example, the database system performs a data write operation, writing the data to the nodes of the database system, and then writing the data to the database, such as a shared storage database, thereby achieving data persistence.

[0004] Given the high reliability and availability of distributed database systems, an increasing number of users (such as enterprise users) are adopting distributed database systems for data management. Distributed database systems can be deployed in real application clusters (RACs). Specifically, this cluster is a distributed database storage engine cluster designed for disk access and based on a shared-everything architecture. RAC includes two types of nodes: hub nodes and leaf nodes. Hub nodes are the master nodes in the cluster, interconnected via a point-to-point network to handle distributed transactions. Leaf nodes have no network connection and are used to handle concurrent queries and online reporting.

[0005] However, leaf nodes typically only obtain data through the sink node as a proxy. Because leaf and sink nodes interact bilaterally, leaf nodes must wait for operating system scheduling and access data from the sink node via a long path. Consequently, leaf nodes often only read historical data, making it difficult to meet the data consistency requirements of real-time applications. Summary of the Invention

[0006] This application provides a transaction processing method. This method utilizes shared global memory, enabling nodes in a distributed database system, such as coordinating nodes and participating nodes, to access global memory unilaterally across nodes without the need for bilateral data synchronization. This eliminates the need for processor and operating system processing, significantly shortening the access path and reducing synchronization time by eliminating the need for operating system scheduling. This achieves real-time consistency between coordinating and participating nodes, meeting the real-time consistency requirements of real-time business applications. This application also provides a distributed database system, transaction processing system, cluster, computer-readable storage medium, and computer program product corresponding to the above method.

[0007] Firstly, this application provides a transaction processing method. This method can be executed by a distributed database system. This distributed database system can be deployed in a cluster. The cluster can, for example, be a memory engine cluster. When the distributed database system runs in a cluster, it can achieve real-time data consistency between nodes, thereby meeting the needs of real-time business operations. Specifically, the distributed database system includes a coordinating node and participating nodes. The coordinating node assumes coordination responsibility during transaction execution, while the participating nodes assume execution responsibility. Here, a transaction refers to a unit of program execution that accesses and may update data in the database, typically consisting of a finite sequence of database operations.

[0008] In a distributed database system, a portion of the memory from multiple nodes is used to form global memory. This global memory is visible to all coordinating and participating nodes in the distributed database system. The remaining portion of memory in a coordinating or participating node is local memory, which is visible to the coordinating or participating node itself. Any coordinating or participating node can access the portion of global memory located on other nodes through remote direct memory access or a memory bus.

[0009] The coordinating node receives multiple query statements sent by the client, creates a transaction based on the first query statement among the multiple query statements, executes the transaction in global memory based on the second query statement among the multiple query statements, and then commits the transaction based on the third query statement among the multiple query statements, so as to achieve consistency between the coordinating node and the participating nodes.

[0010] In this distributed database system, the global memory is shared among the coordinating node and participating nodes. When a transaction executed by the coordinating node causes changes to the data stored in a portion of the global memory, participating nodes can quickly detect these changes. Participating nodes can unilaterally access this portion of the global memory across nodes for data synchronization, eliminating the need for bilateral interaction. Since this process bypasses processor and operating system processing, the access path is significantly shortened, and the lack of operating system scheduling greatly reduces synchronization time. This achieves real-time consistency between the coordinating node and participating nodes, meeting the real-time consistency requirements of real-time applications. Furthermore, the capacity of the global memory can expand with the number of nodes, no longer limited by the memory capacity of a single node, thus improving concurrency control capabilities.

[0011] In some possible implementations, the distributed database system is deployed on a cluster, and the global memory comes from the cluster. This cluster refers to a computing network consisting of at least one group of computers, used to provide computing power to the distributed database system, enabling the distributed database system to provide services based on this computing power.

[0012] This method utilizes global memory from the cluster, enabling nodes in a distributed database system to access global memory unilaterally across nodes without processing by the processor and operating system or waiting for operating system scheduling, thus achieving real-time consistency between nodes (e.g., between coordinating nodes and participating nodes).

[0013] In some possible implementations, the global memory includes a portion of the memory of the coordinating node and / or the participating nodes. Specifically, multiple nodes in the distributed database system (e.g., each node) can provide a portion of memory to form the global memory, with the remaining memory serving as the local memory of the corresponding node. The global memory is shared among the nodes in the distributed database system. These nodes can achieve cross-node unilateral access through remote direct memory access or directly via the memory bus, without needing to go through the operating system and processor, or waiting for operating system scheduling, thus enabling real-time consistency between nodes.

[0014] In some possible implementations, the coordinating node is a master node. Accordingly, this coordinating node can create a read / write transaction based on the first query statement among the multiple query statements. This can meet the needs of real-time read / write operations.

[0015] In some possible implementations, the coordinating node is a first slave node. This first slave node maintains real-time consistency with the node that is the master node. Therefore, this first slave node can also be called a real-time slave node. Correspondingly, the coordinating node can create a read-only transaction based on the first query statement among the multiple query statements. This satisfies the requirements of real-time read-only services.

[0016] In some possible implementations, the distributed database system may also include nodes of type second slave node. The second slave node maintains near real-time consistency with the node of type master node. Therefore, the second slave node can also be called a near real-time slave node. This near real-time slave node is used to handle business operations with low real-time requirements, such as non-real-time analysis operations. For example, the near real-time slave node receives query statements associated with non-real-time analysis operations and then returns the corresponding query results. This can meet the needs of non-real-time analysis operations.

[0017] In some possible implementations, before the coordinating node receives multiple query statements sent by the client, the distributed database system (e.g., the coordinating node and participating nodes in the distributed database system) may receive the number of table records in the global memory sent by the cluster management node. The distributed database system then stores the number of table records in the global memory.

[0018] In this way, when the distributed database system writes data, it can write the corresponding number of replicas based on the number of replicas of the table records in global memory, ensuring data security. Furthermore, the distributed database system can set the number of replicas at the table level, meeting the personalized needs of different business operations.

[0019] In some possible implementations, the table records are stored in the global memory of the distributed database system, while the index tree and management header of the table records are stored in the local memory of the distributed database system. This method uses limited global memory to store table records and employs local memory to store the index tree and management header for version management of the table records. This achieves one-way access to global memory across nodes, ensuring real-time consistency between nodes, while avoiding the use of global memory for index trees and other components, thus improving resource utilization.

[0020] In some possible implementations, the coordinating node can commit transactions based on a transaction commit protocol. Specifically, the coordinating node commits the transaction according to the third query statement among the multiple query statements, through a transaction commit protocol running on both the coordinating node and the participating nodes, to achieve real-time consistency between the coordinating node and the participating nodes.

[0021] By constraining the protocol nodes and participating nodes through the transaction commit protocol, the transaction operations performed by nodes that need to write data (including data insertion or update) (such as coordinating nodes and participating nodes) must either be completed simultaneously or rolled back simultaneously. This avoids the situation where some replica nodes complete the write while others fail to write, resulting in real-time inconsistency between nodes, and further ensures real-time consistency between nodes.

[0022] In some possible implementations, when a write conflict occurs, such as a read-write conflict or a write-write conflict between the transaction and other transactions, the coordinating node triggers pessimistic concurrency control, and the participating nodes trigger optimistic concurrency control. The principle of pessimistic concurrency control is that it assumes multiple concurrent transactions will affect each other during processing; therefore, data can be modified by preventing one transaction from doing so. Specifically, if a transaction performs an operation such as reading a row of data using pessimistic concurrency control (pessimistic locking), then other transactions can only execute conflicting operations after that transaction releases its permissions. The principle of optimistic concurrency control is that it assumes multiple concurrent transactions will not affect each other during processing, and each transaction can process its affected portion of data without generating locks. Before committing data updates, each transaction checks whether other transactions have modified the data after it read it. If other transactions have updated the data, the transaction currently committing will roll back.

[0023] Through the above concurrency control, on the one hand, write-write conflicts or read-write conflicts can be avoided, ensuring consistency between coordinating nodes and participating nodes. On the other hand, the interaction between coordinating nodes and participating nodes can be reduced, the synchronization time can be shortened, and real-time consistency can be achieved.

[0024] Secondly, this application provides a distributed database system. The distributed database system includes a coordinating node and participating nodes, wherein the coordinating node and the participating nodes share global memory.

[0025] The coordination node is used to receive multiple query statements sent by the client;

[0026] The coordinating node is further configured to create a transaction based on a first query statement among the plurality of query statements, execute the transaction in the global memory based on a second query statement among the plurality of query statements, and commit the transaction based on a third query statement among the plurality of query statements.

[0027] In some possible implementations, the distributed database system is deployed on a cluster, and the global memory comes from the cluster.

[0028] In some possible implementations, the global memory includes a portion of the memory of the coordinating node and / or the participating nodes.

[0029] In some possible implementations, the coordinating node is a master node, and the coordinating node is specifically used for:

[0030] A read-write transaction is created based on the first query statement among the multiple query statements.

[0031] In some possible implementations, the coordinating node is a first slave node, which is used to maintain real-time consistency with the node of type master node. Specifically, the coordinating node is used for:

[0032] Create a read-only transaction based on the first query statement among the multiple query statements.

[0033] In some possible implementations, the coordinating node is also used to receive and store the number of table records in the global memory sent by the cluster management node;

[0034] The participating node is also used to receive and store the number of table records in the global memory sent by the cluster management node.

[0035] In some possible implementations, the table records are stored in the global memory of the distributed database system, while the index tree and management header of the table records are stored in the local memory of the distributed database system.

[0036] In some possible implementations, the coordinating node is specifically used for:

[0037] Based on the third query statement among the multiple query statements, the transaction is committed through the transaction commit protocol running on the coordinating node and the participating nodes to achieve real-time consistency between the coordinating node and the participating nodes.

[0038] In some possible implementations, the coordinating node is specifically used to trigger pessimistic concurrency control when a write conflict occurs in the transaction; the participating node is specifically used to trigger optimistic concurrency control when a write conflict occurs in the transaction.

[0039] Thirdly, this application provides a transaction processing system. The transaction processing system includes a client and a distributed database system as described in any implementation of the second aspect of this application, wherein the distributed database system is used to execute a corresponding transaction processing method based on a query statement sent by the client.

[0040] Fourthly, this application provides a cluster. The cluster includes multiple computers. Each computer includes a processor and a memory. The processor and the memory communicate with each other. The processor executes instructions stored in the memory to cause the cluster to perform a transaction processing method as described in the first aspect or any implementation thereof.

[0041] Fifthly, this application provides a computer-readable storage medium storing instructions that instruct a computer to execute the transaction processing method described in the first aspect or any implementation thereof.

[0042] Sixthly, this application provides a computer program product containing instructions that, when run on a computer, causes the computer to perform the transaction processing method described in the first aspect or any implementation thereof.

[0043] Based on the implementation methods provided in the above aspects, this application can be further combined to provide more implementation methods. Attached Figure Description

[0044] To more clearly illustrate the technical methods of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly described below.

[0045] Figure 1 A system architecture diagram of a transaction processing system provided in this application embodiment;

[0046] Figure 2 A flowchart illustrating a node configuration method provided in an embodiment of this application;

[0047] Figure 3 A flowchart illustrating a method for configuring the number of copies provided in an embodiment of this application;

[0048] Figure 4 An interactive flowchart of a transaction processing method provided in an embodiment of this application;

[0049] Figure 5 A flowchart illustrating the transaction initiation and execution phases provided in this application embodiment;

[0050] Figure 6 A flowchart of a transaction commit phase provided in an embodiment of this application;

[0051] Figure 7 A flowchart of a transaction completion phase provided in an embodiment of this application;

[0052] Figure 8 A flowchart of a transaction rollback phase provided in an embodiment of this application;

[0053] Figure 9 This is a schematic diagram of a cluster structure provided in an embodiment of this application. Detailed Implementation

[0054] The terms "first" and "second" used in the embodiments of this application are for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Therefore, a feature defined with "first" and "second" may explicitly or implicitly include one or more of that feature.

[0055] To facilitate understanding of the embodiments of this application, some of the terms involved in this application will first be explained.

[0056] Database applications refer to applications that provide data management services to users based on an underlying database. These data management services include at least one of the following: data creation, data querying, data updating, and data deletion. Typical database applications include information management systems such as attendance management systems, payroll management systems, production reporting systems, and securities trading systems. Database applications typically consist of a database system and a user-facing client. Users can trigger data creation, querying, updating, or deletion operations through the client, and the client can respond to these operations by processing the data in the database through the database system.

[0057] Database systems can be categorized into centralized and distributed database systems based on their deployment method. A distributed database system is deployed in a cluster of multiple computers. In this application, the computers in the cluster can also be referred to as nodes. Nodes can communicate with each other via a network to collaboratively complete data processing.

[0058] Database systems can determine how data is stored and retrieved through storage engines, such as those on memory or disk. The storage engine is a core component of a database system. Different types of database systems can use different storage engines, thus providing different storage mechanisms, indexing methods, and locking mechanisms. When a database system is deployed in a distributed manner across different nodes in a cluster, the cluster can also be divided into disk engine clusters and memory engine clusters based on the type of storage medium used to store data on the nodes.

[0059] Currently, the widely used RAC in the industry is a distributed database storage engine cluster (e.g., a disk engine cluster) designed for disks and based on a fully shared data architecture. RAC includes two types of nodes: hub nodes and leaf nodes. Hub nodes are the master nodes in the cluster, interconnected via a point-to-point network for handling distributed transactions. Leaf nodes are not network-connected and are used for handling concurrent queries and online reporting. However, leaf nodes typically only obtain data through the hub node as a proxy. This bilateral interaction requires the central processing unit (CPU) of both nodes, resulting in excessively long access paths. For example, the access path could be from the leaf node's CPU to its network interface card (NIC), then to the hub node's NIC, then to the hub node's CPU, and finally to the hub node's cache. Furthermore, this interaction requires waiting for operating system scheduling, leading to significant latency. Leaf nodes typically only read historical data, making it difficult to meet the data consistency requirements of real-time applications.

[0060] In view of this, embodiments of this application provide a distributed database system. This distributed database system can be deployed in a cluster. The cluster can, for example, be a memory engine cluster. When running in a cluster, the distributed database system can achieve real-time data consistency among nodes, thereby meeting the needs of real-time business operations. Specifically, the distributed database system includes a coordinating node and participating nodes. The coordinating node assumes coordination responsibility during transaction execution, while the participating nodes assume execution responsibility. A transaction refers to a unit of program execution that accesses and may update data in the database, typically consisting of a finite sequence of database operations.

[0061] In a distributed database system, a portion of the memory from multiple nodes is used to form global memory (GM). This global memory is visible to all coordinating and participating nodes in the distributed database system. The remaining portion of memory in a coordinating or participating node is local memory, which is visible to the coordinating or participating node itself. Any coordinating or participating node can access the portion of global memory located on other nodes through methods such as remote direct memory access (RDMA) or memory fabric.

[0062] The coordinating node receives multiple query statements sent by the client, creates a transaction based on the first query statement among the multiple query statements, executes the transaction in global memory based on the second query statement among the multiple query statements, and then commits the transaction based on the third query statement among the multiple query statements, so as to achieve consistency between the coordinating node and the participating nodes.

[0063] In this distributed database system, the global memory is shared among the coordinating node and participating nodes. When a transaction executed by the coordinating node causes changes to the data stored in a portion of the global memory, the participating nodes can quickly detect these changes. Participating nodes can then unilaterally access this portion of the global memory via RDMA or Memory Fabric for data synchronization, eliminating the need for bilateral interaction. Since this process bypasses processor and operating system processing, the access path is significantly shortened, and the elimination of operating system scheduling greatly reduces synchronization time. This achieves real-time consistency between the coordinating node and participating nodes, meeting the real-time consistency requirements of business applications. Furthermore, the capacity of the global memory can expand with the number of nodes, no longer limited by the memory capacity of a single node, thus improving concurrency control capabilities.

[0064] Based on the aforementioned distributed database system, this application also provides a transaction processing system. The transaction processing system provided in this application embodiment will be described in detail below with reference to the accompanying drawings.

[0065] See Figure 1 The system architecture diagram of the transaction processing system shown is as follows: Transaction processing system 10 includes a distributed database system 100, a client 200, and a database 300. Client 200 is connected to distributed database system 100, and distributed database system 100 is connected to database 300.

[0066] The distributed database system 100 includes a coordinating node and participating nodes. The coordinating node and participating nodes can be connected via RDMA or memory fabric over a high-speed network. Both the coordinating node and participating nodes run a transaction commit protocol. This protocol defines the coordinating node as the access node for transactions, and the participating nodes as the master node and the first slave node in the distributed database system 100, excluding the coordinating node.

[0067] In this context, the coordinating node can be either a master node or a first slave node. The first slave node maintains real-time consistency with the master node. Therefore, the first slave node is also called a real-time slave node. For example, for read-write transactions, the coordinating node can be a master node; for read-only transactions, it can be a real-time slave node. It should be noted that the master node has the capability to handle read-only transactions; therefore, for read-only transactions, the coordinating node can also be a master node.

[0068] In some possible implementations, the distributed database system 100 also includes non-transactional nodes, such as second slave nodes. These second slave nodes maintain near real-time consistency with the node whose node type is the master node. Therefore, the second slave node is also called a near real-time slave node. Considering that some business operations (such as non-real-time analysis operations) do not have high real-time requirements, the distributed database system 100 can process these business operations through the second slave node. For example, the second slave node in the distributed database system 100 can receive query statements associated with non-real-time analysis operations, and return query results based on these query statements.

[0069] In this distributed database system 100, a portion of the memory from multiple nodes (e.g., each node) can be used to form global memory. This global memory can be managed through a software module, such as a global memory management module, which manages memory addressing, allocation, and deallocation. The global memory management module can be a software module of the distributed database system 100.

[0070] The global memory management module manages the memory of nodes in the distributed database system 100. Specifically, it supports single-replica or multi-replica memory allocation and deallocation, which are performed at the byte level. Data using single-replica global memory is typically cached on a single node. When that node fails, the data becomes inaccessible in the cache. During the takeover phase, the data is loaded from the storage system and can then be accessed again. Data using multi-replica global memory is typically cached across multiple nodes. When one node fails, it can still be accessed through other nodes. The global memory management module can also provide allocation and deallocation for small blocks of memory formed by portions of memory across multiple nodes. Specifically, it provides a global memory interface that can be used to allocate small blocks of memory of a specified length.

[0071] The single-copy or multi-copy memory returned by the global memory interface is uniformly addressed by the global memory management module. This address is called the global memory address GmAddr. For a given global memory address, any node in the distributed database system 100 can access the data at that address. Furthermore, the global memory management module can determine the node identifier and offset position of the corresponding node based on the global memory address. Local or remote read / write access can be achieved based on the node identifier and offset position.

[0072] Client 200 can be a general-purpose client such as a browser, or a specialized client such as a client for various information management systems. Users can write query statements through client 200 according to a query language, such as Structured Query Language (SQL). Distributed database system 100 (e.g., the coordinating node in distributed database system 100) receives multiple query statements. It can create a transaction based on the first query statement, execute the transaction in global memory based on the second query statement, and then commit the transaction based on the third query statement, thereby realizing the creation, querying, updating, and / or deletion of data. The global memory visible to both the coordinating node and participating nodes ensures real-time consistency between them. Furthermore, the transaction commit protocol running on the coordinating node and participating nodes ensures that transaction operations are either executed simultaneously or rolled back simultaneously, further guaranteeing real-time consistency between the coordinating node and participating nodes.

[0073] Database 300 is used for persistent data storage. For example, database 300 can persistently store log data. When a node in the distributed database system 100 recovers from a failure, or when the distributed database system 100 as a whole is powered on and restored, the distributed database system 100 can load data from database 300 into memory.

[0074] It should be noted that database 300 can be a database within a shared storage system. This shared storage system includes any one or more of raw devices, automatic storage management (ASM) devices, or network attached storage (NAS) devices. The shared storage system has shared access capabilities. Nodes in the distributed database system 100 can connect to and access the shared storage system. The shared storage system can use cross-node replication or cross-node erasure coding to ensure data reliability and the atomicity of data writes. Atomicity means that all operations within a transaction either complete completely or not at all; it will not end at any intermediate stage. If an error occurs during the execution of a transaction, it will be rolled back to the state before the transaction began.

[0075] In this embodiment, the distributed database system 100 can be deployed in a cluster, for example, in a memory engine cluster. Correspondingly, the transaction processing system 10 may also include a cluster management node 400. This cluster management node 400 is connected to the distributed database system 100.

[0076] The cluster management node 400 is used for the operation and maintenance of the cluster (e.g., the distributed database system 100 within the cluster). Specifically, the cluster management node 400 can be used to discover nodes in the distributed database system 100, manage the status of nodes in the distributed database system 100, or manage metadata. This metadata may include at least one of node attribute information and a data table schema. Node attribute information includes any one or more of node identifier (ID), node network address (Internet protocol address, IP), node type, and node status. The data table schema includes any one or more of table name, table ID, table type, number of fields, and field type descriptions.

[0077] In some possible implementations, the transaction processing system 10 also includes a time server 500. The time server 500 is connected to the distributed database system 100. The time server 500 provides a monotonically increasing clock service. This clock can specifically be a logical clock, a true time clock, or a hybrid logical clock. A hybrid logical clock refers to a logical clock that incorporates physical clocks (such as true time). The time server 500 can provide the distributed database system 100 with a timestamp of the current moment. This timestamp can specifically be a time-representing value of 8 bytes or 16 bytes. The distributed database system 100 can obtain the timestamp to determine the visibility of data to a transaction.

[0078] Before performing transaction processing, the distributed database system 100 can be installed. During the installation of the distributed database system 100, the user may be prompted to configure the nodes in the distributed database system 100. For ease of understanding, the node configuration method provided in this embodiment of the application will be described below with reference to the accompanying drawings.

[0079] See Figure 2 The diagram shows the interaction flow of the node configuration method, which includes:

[0080] S202: Configure node IPs, install log file systems, and set node types in the distributed database system 100.

[0081] The distributed database system 100 may include multiple nodes. For any given node, the node IP can be automatically configured based on an IP address pool. In some embodiments, the node may also receive a node IP manually configured by an administrator, thereby achieving node IP configuration.

[0082] Similarly, nodes can be automatically configured with node types, or they can receive manual configuration from administrators to achieve node type configuration. Node types can include master nodes and real-time slave nodes; furthermore, node types can also include near-real-time slave nodes. In some embodiments, master nodes can be used to handle read-write transactions, real-time slave nodes can be used to handle read-only transactions, and near-real-time slave nodes can be used to handle non-transactional requests, such as query requests related to analytics. This can meet the needs of different business operations.

[0083] Considering that the memory in the distributed database system 100 is a volatile storage medium, to ensure the durability of transaction-related data, a successful transaction commit notification message can be returned to the client 200 only after the transaction log file (redo log) has been successfully persisted. Directly writing the log file to the shared storage system (e.g., a database within the shared storage system) can increase transaction commit latency, resulting in faster transaction processing on the distributed database system 100 side, but slower log file persistence, thus impacting overall latency and performance.

[0084] To this end, some nodes in the distributed database system 100 (such as the master node) can also be configured with high-speed persistent media for log file persistence. This high-speed persistent media includes, but is not limited to, power-protected memory, non-volatile random access memory (NVRAM), or other non-volatile 3D-point media. Nodes can install a log file system (LogFs) to manage the local high-speed persistent media. The log file system can also provide a file semantics access interface for persisting log files, such as redo log files.

[0085] Furthermore, real-time slave nodes can also be configured with high-speed persistent media so that, in the event of a master node failure, the node type of the real-time slave node can be changed to that of the master node. Near-real-time slave nodes are primarily used to handle non-transactional requests and do not require local log file persistence, thus eliminating the need for high-speed persistent media configuration.

[0086] Because the size of the redo log file increases with the number of transaction commits, the redo log file can be moved from the log file system to the shared storage system by a background task (such as a task triggered by a node in the distributed database system 100). This moving process is completed by a background task and does not affect the transaction execution latency.

[0087] It's important to note that high-speed persistent storage has relatively small capacity requirements. For example, if a single node has a transaction processing capacity of 1 million transactions per second, and the redo log file has a data volume of 1 gigabyte (GB) per second, and background tasks migrate data every 0.5 seconds, then a 1GB high-speed persistent storage capacity is sufficient for writing redo log files on one node. Before the redo log file is migrated to the shared storage system, it can be written to multiple nodes to ensure its reliability. Assuming it's written to three nodes, the high-speed persistent storage capacity can be configured as 1GB * 3 = 3GB.

[0088] The above structure of the distributed database system 100 can logically divide the distributed database system 100 into an index layer, a table record layer, and a near-end persistence layer. The index layer stores the index tree of table records and the management header (rhead) of the table records. The rhead records the global memory address and log file address (e.g., redo log file address) of that version of the table record. The index layer is typically implemented using local memory and accessed locally. The index tree and rhead exist on all nodes in the distributed database system 100. The index tree and rhead on the master node and real-time slave nodes are consistent in real-time, specifically when consistent data is formed upon transaction commit. The table record layer stores the table records. The table record layer is typically implemented using global memory and can be accessed remotely via methods such as RDMA or memory fabric. The near-end persistence layer is used for persistent storage of log files such as redo log files. The near-end persistence layer is typically implemented using high-speed persistence media.

[0089] S204: Nodes in the distributed database system 100 report node configuration information to the cluster management node 400.

[0090] The node configuration information may include the node IP address and node type. Furthermore, the node configuration information may also include one or more of the following: memory capacity and log file system capacity.

[0091] S206: Cluster management node 400 checks the number of nodes corresponding to each node type. When the number of nodes meets the set conditions, it saves the node configuration information to the system node table sysNodeTbl.

[0092] The distributed database system 100 includes at least a master node. In some possible implementations, the distributed database system 100 also includes at least one of real-time slave nodes and near-real-time slave nodes. Based on this, the cluster management node 400 can check whether the number of master nodes Nm satisfies the following condition: Nm > 0. Optionally, the cluster management node 400 can check whether the number of real-time slave nodes Nr and the number of near-real-time slave nodes Nq satisfy the following conditions: Nr ≥ 0, Nq ≥ 0.

[0093] Furthermore, considering the cost of expanding the distributed database system 100, the sum of the number of master nodes Nm and the number of real-time slave nodes Nr is typically set to an upper limit, which can be a first preset value Q1. Similarly, the number of near-real-time slave nodes Nq is also set to an upper limit, which can be a second preset value Q2. Based on this, the cluster management node 400 can check whether the sum of the number of master nodes Nm and the number of real-time slave nodes Nr satisfies the following condition: Nm + Nr ≤ Q1, and check whether the number of near-real-time slave nodes Nq satisfies the following condition: Nq ≤ Q2. Q1 and Q2 can be set based on empirical values; for example, Q1 can be set to 8, and Q2 can be set to 64.

[0094] When the number of nodes (e.g., the number of nodes of a single type and / or the sum of the number of nodes of different types) meets the set conditions, it indicates that the node configuration is valid, and the cluster management node 400 can save the node configuration information to the system node table sysNodeTbl.

[0095] S208: Cluster management node 400 returns a configuration success message to the nodes in the distributed database system 100.

[0096] S210: A node in the distributed database system 100 returns a configuration success message to the client 200.

[0097] Specifically, the cluster management node 400 returns a configuration success message to each node in the distributed database system 100, and then each node returns a configuration success message to the client 200.

[0098] It should be noted that if the number of nodes does not meet the set conditions, such as exceeding the upper limit or falling below the lower limit, the node configuration will fail. Correspondingly, the cluster management node 400 can also return a configuration failure message so that the node configuration can be re-attempted.

[0099] S212: Client 200 sets the effective flag for the system node table sysNodeTbl.

[0100] S214: Client 200 sends the system node table sysNodeTbl effective flag to cluster management node 400.

[0101] Specifically, the activation flag is used to identify the system node table sysNodeTbl. The client 200 sets the activation flag and sends the activation flag to the cluster management node 400 to activate the system node table sysNodeTbl.

[0102] S216: Cluster management node 400 returns the system node table sysNodeTbl to the nodes in the distributed database system 100.

[0103] S218: The nodes in the distributed database system 100 store the system node table sysNodeTbl.

[0104] S220: Cluster management node 400 returns node configuration information to client 200.

[0105] Specifically, the cluster management node 400 returns the node configuration information of each node to the client 200, such as the node IP and node type. In this way, the client 200 can not only obtain the node configuration information, but also obtain the number of nodes based on the node configuration information, such as the number of nodes of each node type.

[0106] It should be noted that S210 to S220 are optional steps in the node configuration method provided in the embodiments of this application. In other possible implementations of this application, S210 to S220 may not be executed.

[0107] After configuring the nodes, you can also configure the number of table records in global memory: RecordMemRepNum. The minimum value of RecordMemRepNum can be set to 1. Considering that the data in the master node and real-time slave nodes in the distributed database system 100 needs to be kept consistent in real time, if the number of replicas in global memory exceeds the sum of the number of master nodes Nm and the number of real-time slave nodes Nr (Nm+Nr), it will increase memory consumption without improving availability. Therefore, the maximum value can be set to Nm+Nr.

[0108] When the business has high requirements for recovery time, RecordMemRepNum can be configured to be greater than 1. In this way, when a node fails, the table records cached on that node become inaccessible, but the coordinating or participating nodes in a normal state can still directly access the table records from the memory of the in-memory replica node of that data table. In this case, the recovery time objective (RTO) = 0.

[0109] When the business has low requirements for recovery time, RecordMemRepNum can be configured to be equal to 1. In this way, when a node fails, other nodes (such as the coordinating or participating nodes in a normal state) cannot access the table records cached on the failed node. Transactions accessing these table records can wait for a node in the distributed database system 100 to take over the failed node and recover from the shared storage system, or for the data to be replayed from a log file such as the redo log file, before continuing execution. In this case, RTO > 0.

[0110] When configuring RecordMemRepNum, information prompts can be provided to users, such as the minimum and maximum values ​​of RecordMemRepNum, so that users can refer to these minimum and maximum values ​​for configuration. After configuration, the cluster management node 400 can also store RecordMemRepNum as a table attribute in the system metadata table sysMetaTbl, and the nodes in the distributed database system 100 can also update the system metadata table sysMetaTbl in their local memory.

[0111] Next, the method for configuring RecordMemRepNum provided in the embodiments of this application will be described in conjunction with the accompanying drawings.

[0112] See Figure 3 The diagram shown illustrates the interactive flow of configuring RecordMemRepNum, which includes:

[0113] S302: Client 200 sends a table creation command to the master node in the distributed database system 100. The table creation command includes RecordMemRepNum.

[0114] The table creation command includes table parameters, which can include the number of copies of the table records in global memory, i.e., RecordMemRepNum. In some possible implementations, the table parameters may also include one or more of the following: table name, column name, and column type.

[0115] S304: The master node forwards the table creation command to the cluster management node 400.

[0116] The master node can execute create table commands to create data tables. Furthermore, the master node forwards create table commands, for example, forwarding the RecordMemRepNum parameter from the create table command to the cluster management node 400 to set RecordMemRepNum.

[0117] In this way, the number of records (RecordMemRepNum) in global memory can be configured at the data table level, which meets the availability requirements of different data tables and allows memory consumption to be controlled according to the needs of the data tables.

[0118] S306: Cluster management node 400 checks whether RecordMemRepNum is within the preset range. If yes, proceed to S308; otherwise, proceed to S320.

[0119] The default range is the value range of RecordMemRepNum. This range can be greater than or equal to 1 and less than or equal to the sum of the number of master nodes Nm and the number of real-time slave nodes Nr, i.e., Nm+Nr. The cluster management node 400 checks whether RecordMemRepNum is greater than or equal to 1 and less than or equal to Nm+Nr. If yes, it indicates that the configured RecordMemRepNum is valid, and S308 can be executed; if no, it indicates that the configured RecordMemRepNum is invalid, and S320 can be executed.

[0120] S308: Cluster management node 400 stores RecordMemRepNum in the system metadata table sysMetaTbl.

[0121] Specifically, the cluster management node 400 adds a table record to the system metadata table sysMetaTbl. This table record is specifically used to record RecordMemRepNum, and the cluster management node 400 can persistently store the above data in the table record.

[0122] S310: Cluster management node 400 sends the system metadata table sysMetaTbl to the master node, real-time slave node, and near-real-time slave node.

[0123] The cluster management node 400 can send the aforementioned system metadata table sysMetaTbl to the nodes in the distributed database system 100. When the distributed database system 100 does not include real-time slave nodes or near-real-time slave nodes, the step of sending the system metadata table sysMetaTbl to the real-time slave nodes or near-real-time slave nodes may not be performed.

[0124] S312: In the distributed database system 100, the master node, real-time slave node, and near-real-time slave node update the system metadata table sysMetaTbl in local memory.

[0125] S314: The master node, real-time slave node, and near-real-time slave node in the distributed database system 100 send an update completion notification to the cluster management node 400.

[0126] The update completion notification is used to inform the cluster management node 400 that the update of the system metadata table sysMetaTbl has been completed in the local memory of each node of the distributed database system 100.

[0127] S316: Cluster management node 400 sends a configuration success response to the master node in distributed database system 100.

[0128] S318: The master node sends a configuration success response to client 200.

[0129] In some possible implementations, the cluster management node 400 can also directly send a configuration success response to the client 200 to notify the client 200 that the configuration of RecordMemRepNum is complete.

[0130] S320: Cluster management node 400 sends a configuration failure response to the master node in the distributed database system 100.

[0131] S322: The master node sends a configuration failure response to client 200.

[0132] In some possible implementations, the cluster management node 400 can also directly send a configuration failure response to the client 200 to notify the client 200 that the configuration of RecordMemRepNum has failed. Based on this, the client 200 can also adjust the table parameters and then resend the table creation command.

[0133] It should be noted that S314 to S322 are optional steps in the method of configuring RecordMemRepNum provided in the embodiments of this application. In other possible implementations of this application, S314 to S322 may not be executed.

[0134] After configuring the nodes and the number of replicas of table records in global memory, transaction processing can be performed based on the transaction processing system 10 described above. Next, the transaction processing method provided in the embodiments of this application will be described in detail with reference to the accompanying drawings.

[0135] See Figure 4 The flowchart shown illustrates a transaction processing method, which includes:

[0136] S402: Client 200 sends multiple query statements to the coordinating node in the distributed database system 100.

[0137] A query statement is a statement written in a query language used to process data in database 300. Processing data in database 300 includes any one or more of the following: data creation, data querying, data updating, and data deletion.

[0138] Client 200 can receive multiple query statements written by the user using a query language, and then send these multiple query statements to the coordinating node in the distributed database system 100. The query language can be determined by the user from a list of query languages ​​supported by the database 300. For example, the query language can be SQL, and correspondingly, the query statements written by the user can be SQL statements.

[0139] When client 200 sends multiple query statements, it can send them all at once, thus improving throughput. In some possible implementations, client 200 can also send query statements one by one. Specifically, client 200 can send one query statement first, and then send the next query statement after that query statement has been executed.

[0140] In some possible implementations, multiple query statements can be used to form a transaction. Client 200 determines the transaction type based on the query statements. Transaction types include read-write transactions and read-only transactions. Read-only transactions do not support insert, delete, or update operations within the transaction. Client 200 can determine whether a transaction is a read-write or read-only transaction based on whether the query statements indicate inserting, deleting, or updating table records. For example, if at least one of the multiple query statements indicates inserting, deleting, or updating table records, client 200 can determine that the transaction type is a read-write transaction; otherwise, it is determined to be a read-only transaction.

[0141] When the transaction type is a read-write transaction, client 200 can determine the coordinating node from the master node of distributed database system 100 and send multiple query statements to the coordinating node. When the transaction type is a read-only transaction, client 200 can determine the coordinating node from the real-time slave nodes of distributed database system 100 and send multiple query statements to the coordinating node. In some possible implementations, when the transaction type is a read-only transaction, client 200 can also determine the coordinating node from the master node; this embodiment of the application does not limit this.

[0142] S404: The coordinating node in the distributed database system 100 creates a transaction based on the first query statement among multiple query statements.

[0143] The first query statement can be a query statement that indicates the start of a transaction. For example, when the first query statement is an SQL query statement, it can include a begin command. The coordinating node can execute the first query statement to create a transaction. Specifically, when the coordinating node is a master node, it can create a read-write transaction based on the first query statement. When the coordinating node is a real-time slave node, it can create a read-only transaction based on the first query statement.

[0144] See Figure 5 The flowchart shown illustrates the transaction initiation phase. The coordinating node (e.g., master node 1 in the distributed database system 100) can initiate the transaction based on the first query statement representing the start of the transaction (e.g., ...). Figure 5As shown in the diagram (begin), a transaction is created. Specifically, the coordinating node can create a global transaction, request a global transaction unique identifier (gtxid), and request a local transaction control block from local memory, obtaining a local transaction control block unique identifier (lotxid). Furthermore, the coordinating node can also obtain a start timestamp (begin timestamp, beginTs) from the time server 500.

[0145] The gtxid can be determined based on the node identifier and the sequence number within the node; for example, it can be a string obtained by concatenating the node identifier and the sequence number within the node. A global transaction includes multiple sub-transactions (e.g., local transactions on the coordinating node and participating nodes), and these sub-transactions can be associated with each other using the gtxid. When the coordinating node encounters an anomaly and is taken over by another node, the other participating nodes can use the node identifier in the gtxid to query the cluster management node (400) for the identifier of the taking-over node, thereby initiating a global transaction status reconfirmation process with the taking-over node.

[0146] The local transaction control block is a segment of memory in local memory used for process state control. The unique identifier of the local transaction control block, lotxid, can be a strictly monotonically increasing value, which can be an 8-byte number. lotxid can be recorded in the rhead of the index layer. When other transactions on the same node need to wait for this transaction to complete, they can find this transaction through its lotxid and add the other transactions to this transaction's wait queue.

[0147] The transaction start timestamp, or beginTs, can be recorded in the local transaction control block to provide a basis for determining transaction visibility. Specifically, at the start of a transaction, the coordinating node obtains the current timestamp from the time server (500) as beginTs. The coordinating node can then determine the visibility of the transaction record in the visibility table based on the start timestamp and visibility rules. The following is a detailed explanation of the visibility determination process based on visibility rules.

[0148] Specifically, the rhead of a version of a table record includes the lifetime window of that version of the table record. The lifetime window can be characterized by the minimum timestamp tmin representing the start time and the maximum timestamp tmax representing the end time. The coordinating node can determine the visibility of a version of the table record to a transaction based on the relationship between the size of tmin and tmax in the rhead of a version of the table record and the transaction's beginTs.

[0149] In the case where timestamps (instead of gtxids) are recorded for both tmin and tmax, if beginTs >= tmin and beginTs < tmax, the table records of this version are visible to this transaction; otherwise, they are not visible. In the case where at least one of tmin or tmax records a gtxid (instead of a timestamp), the coordinating node can find the local transaction based on the lotxid recorded in rhead, add this transaction to the waiting queue of the local transaction, and when the transaction is awakened from the waiting queue, read tmin and tmax again for visibility judgment.

[0150] S406: The coordinating node in the distributed database system 100 executes a transaction in the global memory according to the second query statement in multiple query statements.

[0151] The second query statement can be a query statement indicating a transaction operation. Among them, the transaction operation includes a data manipulation language (DML) operation. Among them, the DML operation can include insert, delete, or update operations. The transaction operation can also include a query operation.

[0152] Among them, when the second query statement is a statement indicating an insert operation, the second query statement can also carry the record data of the table record to be inserted. When the second query statement is a statement indicating an update operation, the second query statement can also carry the primary key of the table record to be updated and the updated record data. When the second query statement is a statement indicating a delete operation, the second query statement can also carry the primary key of the table record. When the second query statement is a statement indicating a query operation, the second query statement can also carry a query condition. Among them, the query condition can include the primary key of the table record or a predicate condition. A predicate is used to represent a comparison operation, and a predicate condition includes a query condition expressed by a comparison operation. The predicate condition is used to narrow the range of the result set returned by the query.

[0153] The coordinating node can execute this second query statement to execute a transaction in the global memory. For example, the coordinating node can execute at least one of operations such as data insertion, deletion, update, or reading in the global memory. Among them, the second query statement can include one or more. The following takes the second query statement as a statement indicating an insert operation, a delete operation, an update operation, and a query operation respectively to illustrate the process of executing a transaction.

[0154] See Figure 5The flowchart shown illustrates the transaction execution phase. When the second query statement is an instruction to perform an insert operation, the coordinating node (e.g., master node 1 in distributed database system 100) can query the system metadata table `sysMetaTbl` to obtain table attributes. These attributes include the number of replicas of the table records in global memory, which can be denoted as `RecordMemRepNum`. The coordinating node can then call the global memory interface provided by the global memory management module to request a specified number of global memory spaces (e.g., denoted as `gm1`), and then fill `gm1` with record data. The specified number of replicas is equal to `RecordMemRepNum`.

[0155] Specifically, the coordinating node can call the global memory interface to obtain a list of nodes where the replicas of gm1 reside. Then, based on this list, it fills the newly added record data into the global memory of the first replica node (e.g., the coordinating node). Here, tmin can be set to gtxid, and tmax can be set to -1 (to represent infinite). It should be noted that tmin is set to gtxid before committing and to a timestamp after committing, while tmax remains unchanged before and after committing.

[0156] Furthermore, the coordinating node can query the system node table sysNodeTbl. If a near real-time slave node exists in the list of replica nodes, the newly added record data will be populated into the global memory of that near real-time slave node. Here, tmin is set to gtxid, and tmax is set to -1.

[0157] The coordinating node can also allocate local memory to store the `rhead` and the indirect index `indirect`. The `rhead` contains the global memory address, physical address, and `lotxid` of the record data to be inserted. Since the transaction has not yet been committed, the physical address can be 0. The `indirect` points to the `rhead`. Next, the coordinating node inserts the new record data into the local index tree. If a key conflict exists, the insert fails, and the previously allocated global and local memory are released. The coordinating node can also return error messages. These error messages can indicate that the insert failed, and further, the reason for the failure. If the insert succeeds, the `indirect` is modified to point to the newly added record data. Then, the coordinating node records the operation type as `insert` in the local transaction write set (`wset`) and returns a 200 success response to the client. The local transaction write set will be referred to as the write set below.

[0158] When the second query statement is a statement instructing the execution of an update operation, the coordinating node (e.g., master node 1 in distributed database system 100) can query the system metadata table sysMetaTbl to obtain table attributes, including RecordMemRepNum. The coordinating node finds the version of the table record for the update operation, determines the visibility of the table record to the transaction based on tmin and tmax in beginTs and rhead, and returns the correct version of the table record.

[0159] Specifically, the coordinating node searches for the version list of the table record (i.e., the rhead list) in the index data, such as the index tree, based on the primary key of the table record being updated. Then, the coordinating node reads the corresponding tmin and tmax of the table record based on the global memory address of the rhead record, and performs visibility checks based on tmin and tmax. If tmin or tmax in the version is a gtxid instead of a timestamp, the transaction is added to the wait queue of the local transaction control block identified by lotxid in the rhead. After the transaction is awakened, the traversal process of the rhead list can be re-executed. The gtxid or timestamp can be distinguished by its high-order bits: if the high-order bit of tmin or tmax is 1, then tmin or tmax is a gtxid; if the high-order bit of tmin or tmax is not 1, then tmin or tmax is a timestamp. If tmin or tmax are both timestamps in this version, when beginTs is within [tmin, tmax), it indicates that the table records of this version are visible to transactions, and the coordinating node can return the table records of this version and rhead. When beginTs is not within [tmin, tmax), it indicates that the table records of this version are not visible to transactions, and the coordinating node can continue to traverse the previous version based on the address of the previous version of the rhead record.

[0160] The coordinating node can obtain the global memory address of the table record based on the returned version's rhead, and then attempt to mark the update in the table record based on the global memory address. Specifically, if the returned version's tmax is not -1, it indicates that the version is not the current version and has been updated by another transaction, i.e., a write-write conflict has occurred, and the coordinating node can return a marking failure notification to client 200. If the returned version's tmax is -1, it indicates that it is the latest version, and the coordinating node can call the global memory interface to obtain a list of memory replica nodes, initiate a compare and swap (CAS) atomic operation on the tmax of the corresponding table record in the global memory of the first replica node, and mark tmax as gtxid. If the CAS atomic operation returns failure, it indicates a write-write conflict, and a marking failure notification is returned to client 200; if the CAS atomic operation returns success, it indicates that the marking is successful, and the coordinating node can execute the update to the table record.

[0161] When the coordinating node updates a table record, it first calls the global memory interface to request a specified number of global memory replicas, and then fills in the updated record data. The specific implementation of the coordinating node requesting global memory and filling in the updated record data in global memory can be found in the description of the insert operation, and will not be repeated here. Then, the coordinating node requests local memory to store the rhead, which contains the global memory address, lotxid, and physical address of the updated table record. At this point, the physical address can be 0.

[0162] Next, the coordinating node installs the new version chain, specifically by pointing the management header (newrhead) of the updated table record to the address of the previous version's rhead, and pointing the indirect to newrhead. The coordinating node records the operation type as update, along with the addresses of rhead (i.e., oldrhead) and newrhead, in the write set (wset) within its local transaction control block. Upon completing these operations, the coordinating node can return a 200 update success notification to the client.

[0163] When the second query statement is an instruction to perform a delete operation, the coordinating node (e.g., master node 1 in distributed database system 100) can find the version of the table record to be deleted, determine the visibility of the table record to the transaction based on `beginTs` and `tmin` and `tmax` in `rhead`, and return the correct version of the table record. Then, the coordinating node obtains the global memory address of the table record based on the returned version's `rhead` and marks the update in the table record. The specific implementation of the coordinating node determining visibility, returning the correct version of the table record, and marking the update can be found in the description of the update operation; it will not be repeated here.

[0164] Next, the coordinating node records the operation type "delete" in the write set of its local transaction control block, along with the address of the record's rhead. Upon completing these operations, the coordinating node can return a successful deletion notification to the client (200 status code).

[0165] When the second query statement is a statement instructing the execution of a query operation, the coordinating node (e.g., master node 1 in distributed database system 100) can find the version of the table record for the query based on the query conditions, determine the visibility of the table record for the transaction based on tmin and tmax in beginTs and rhead, and return the correct version of the table record. The specific implementation of the coordinating node determining visibility and returning the correct version of the table record can be found in the description related to update operations. Then, the coordinating node can also traverse and read records in the local transaction read set (rset), checking for phantoms to verify read-write conflicts. When the verification passes, it can return the correct version of the table record to respond to the query operation. The local transaction read set will be referred to as the read set below.

[0166] After the above processing, for insert / update operations, the coordinating node has allocated a specified number of global memory replicas for the new version of the table records, and has filled in the record data for the first replica node (e.g., the coordinating node), setting tmin and tmax. If the replica nodes include near-real-time slave nodes, the record data for the near-real-time slave nodes is also filled in, and tmin and tmax are set. Furthermore, the coordinating node has allocated an rhead for the new version of the table records. The rhead records the global memory address of the record data or the updated record data, and has been installed in the local index tree and indirect. For update / delete operations, the tmax of the first replica node of the original version has been CAS-set to gtxid, thus achieving concurrency conflict handling with other transactions. The write set in the local transaction control block has recorded the gtxid, beginTs, and newrhead addresses. The read set in the local transaction control block has recorded the read records and query conditions (e.g., predicate conditions). The read records can be used for read-write conflict verification.

[0167] S408: The coordinating node in the distributed database system 100 commits a transaction based on the third query statement among multiple query statements.

[0168] The third query statement can be a query statement that instructs the transaction to be committed. For example, when the third query statement is an SQL query statement, it can include a commit command. The coordinating node can execute the third query statement to commit the transaction, ensuring that newly added, updated, deleted, or retrieved records are consistent in real time among the coordinating node and participating nodes.

[0169] See Figure 6 The flowchart shown illustrates the transaction commit phase. The coordinating node (e.g., master node 1 in distributed database system 100) can query the locally cached system node table `sysNodeTbl` to obtain a list of other master nodes and real-time slave nodes; these nodes are the participating nodes. Based on the operation type in the write set (e.g., one or more of insert, update, delete) and the addresses of `newrhead` and `oldrhead`, the coordinating node packages the operation type, the global memory addresses of the old and new version table records, and the record data of the new version table record into a pre-synchronization (also called a preinstall) request message. The pre-synchronization request message includes `gtxid` and `beginTs`. The coordinating node sends the pre-synchronization request message to the participating nodes (e.g., master node 2, master node 3, real-time slave node 1, real-time slave node 2, etc. in distributed database system 100). Upon receiving the pre-synchronization request message, each participating node creates a local transaction on its own node and obtains `lotxid`.

[0170] Participating nodes traverse the write set in the pre-synchronization request message and perform the following processing based on the operation type:

[0171] For the insert operation, participating nodes allocate local memory for the new version, which is used to store `newrhead`. The participating nodes record the global memory address, `lotxid`, and physical address carried in the pre-synchronization request message in `newrhead`, where the physical address is 0. Then, `indirect` is assigned a value to point to `newrhead`. Next, the participating nodes check if they have a copy of the new version's global memory address. If a copy exists, and it's not the first copy, the node fills in the record data in its copy and sets `tmin = gtxid` and `tmax = -1`. Finally, the participating nodes insert the new record data into the index tree based on its primary key. If a key conflict exists, a pre-synchronization failure notification is sent to the coordinating node; otherwise, the insertion succeeds. It should be noted that if other transactions discover this record data at this point, they add this transaction to the wait queue of the local transaction control block corresponding to `lotxid` in `rhead`.

[0172] For update operations, participating nodes allocate local memory for the new version, which is used to store `newrhead`. The participating nodes record the global memory address, loxid, and physical address carried in the pre-synchronization request message in `newrhead`. At this point, the physical address is 0. The participating nodes check if the global memory address of the new version is replicated on their node. If a replica exists, and it is not the first replica, the participating nodes fill in the record data in their replica and set `tmin = gtxid` and `tmax = -1`. Then, based on the primary key recorded in the old version table, the participating nodes look up the indirect address in the local index and obtain the rhead it points to, setting `newrhead` to point to the current rhead. If the participating nodes have a replica of the global memory address recorded in the old version table, and it is not the first replica, then they can modify `tmax` to `gtxid` in their replica.

[0173] For a delete operation, the participating node searches for the address of the indirect in its local index tree based on the primary key of the old version table record, obtains the rhead pointed to by the indirect, and sets the newrhead to point to the current rhead. Then, the participating node checks the global memory address of the old version record data. If the global memory is replicated on this node and is not the first replica, then tmax can be modified to gtxid in the replica on this node.

[0174] Next, the participating nodes send pre-synchronization response messages to the coordinating node. Once the coordinating node has collected all the pre-synchronization response messages from the participating nodes, and all of them indicate successful pre-synchronization, the coordinating node obtains the current timestamp as the termination timestamp endTs.

[0175] The coordinating node determines the transaction isolation level. When the transaction isolation level is Serializable Snapshot Isolation (SSI), the coordinating node can check for read-write conflicts. Specifically, the coordinating node can traverse the read set `rset` and use `endTs` to check the visibility of the table records corresponding to `rhead` in `rset`, thereby determining whether a read-write conflict has occurred. The coordinating node can re-execute the table record query according to the predicate conditions, checking whether the table records visible based on `endTs` and those visible based on `beginTs` are the same. If they are the same, it means that there are no read-write conflicts for the table records covered by the predicate conditions during the transaction execution. If a table record is not visible, it indicates that another transaction has modified that table record, i.e., a read-write conflict has occurred. The coordinating node can terminate the transaction, perform a rollback operation, notify other participating nodes to terminate the transaction, and return a 200 error response to the client. It should be noted that when the transaction isolation level is other isolation levels such as Read Committed (RC) or Snapshot Isolation (SI), the coordinating node does not need to perform this step to check for read-write conflicts.

[0176] The coordinating node obtains a list of nodes configured with a log file system such as LogFs based on the node configuration information in the system node table. The coordinating node can select a corresponding number of nodes from this list to write log files, based on a pre-set replica count. For example, if the pre-set replica count is N, the coordinating node can write the log file and send synchronization requests (also called prepare requests) to N-1 other nodes configured with LogFs to notify them to write log files (e.g., redo log files). This log file records gtxid, endTs, newly added record data and its global memory address, and deleted record data. The coordinating node then waits for synchronization responses from these nodes. If the redo log does not meet the pre-set replica count requirement (e.g., if the pre-set replica count is 3, but the number of nodes configured with high-speed persistent media is 2), the coordinating node can directly write the redo log to the shared storage system. When the coordinating node determines the RC or SI of a transaction, it can directly generate a log file, such as a redo log file.

[0177] Upon receiving a synchronization request, participating nodes write a log file (e.g., a redo log file) to their local logFs directory with the same filename, and then return a synchronization response to the coordinating node. Before writing to the log file, participating nodes can also verify read-write conflicts and write-write conflicts. The process for participating nodes to verify read-write conflicts can be referenced from the specific implementation of read-write conflict verification by the coordinating node. Participating nodes can verify write-write conflicts as follows: They determine whether a write-write conflict has occurred based on the index of at least one table record in the transaction's write set. For example, if a uniqueness conflict occurs when a participating node inserts a write record index entry into the index, it indicates a write-write conflict. If the participating node determines that no write-write conflict has occurred, it generates a redo log file; if it determines that a write-write conflict has occurred, it returns an error response to the coordinating node. After receiving the synchronization response (also called a commit reply), the coordinating node can proceed with the transaction completion process.

[0178] Specifically, see Figure 7 The flowchart shown illustrates the transaction completion phase. The coordinating node (e.g., master node 1 in distributed database system 100) sends a transaction completion request to each participating node (e.g., master node 2, master node 3, real-time slave node 1, real-time slave node 2, etc. in distributed database system 100). This transaction completion request carries the IVOs of each participating node. The coordinating node iterates through the write set in its local transaction and applies the modifications made in this transaction.

[0179] The coordinating node applies the modifications made in this transaction, which may involve setting `tmin` to `endTs` in the first copy of the new version table record in global memory and the near-real-time slave node copy (if any), and setting the physical address in `rhead` to the redo log file identifier and offset. Then, the coordinating node sets `tmax` to `endTs` in the first copy of the old version table record in global memory and the near-real-time slave node copy (if any), and updates the physical address in `rhead` to the redo log file identifier and offset. The coordinating node sets the `lotxid` of all `rhead` records in the write set to 0. At this point, the coordinating node retrieves the list of local transactions awaiting visibility determination and wakes them all up. The woken-up transactions will re-check the visibility of the table records. The coordinating node adds the local transactions to the recycling list, waiting for all active transactions to complete before reclaiming the old version chain and deleting the indexes.

[0180] Upon receiving a transaction completion request, participating nodes employ a similar processing method to the coordinating node. Specifically, participating nodes iterate through the write set, applying the modifications made in this transaction. If a new version table record in the write set has a copy on this node, the participating node sets the `tmin` of the new version table record to `endTs`, and the physical address in `rhead` to the redo log file identifier and offset. The participating node also sets the `tmax` of the old version table record in the write set to `endTs`, and updates the physical address in `rhead` to the redo log file identifier and offset. The participating node sets the `lotxid` of all `rhead` records in the write set to 0. At this point, the participating node retrieves the list of local transactions awaiting visibility determination and wakes them all up. Then, the participating node adds the local transactions to the recycling list, waiting for all active transactions to complete before recycling the old version chain and deleting the indexes. Finally, the participating node can send a transaction completion response to the coordinating node.

[0181] It should be noted that when the coordinating node verifies read-write conflicts based on isolation levels, if a table record is not visible, it indicates that another transaction has modified that table record, resulting in a read-write conflict. The coordinating node can terminate the transaction and roll it back. In some embodiments, when the coordinating node receives a pre-synchronization response from participating nodes, if it includes an error response, the coordinating node can also terminate the transaction and roll it back. The rollback process is described in detail below.

[0182] Specifically, see Figure 8 The flowchart shown illustrates the transaction rollback phase. The coordinating node (e.g., master node 1 in distributed database system 100) sends transaction rollback requests (such as...) to each participating node (e.g., master node 2, master node 3, real-time slave node 1, real-time slave node 2, etc. in distributed database system 100). Figure 8 As shown in the final-abort example, the transaction rollback request carries the lotxid of each participating node. The coordinating node traverses the write set in the local transaction and rolls back the modifications of this transaction. Specifically, the coordinating node removes the index of the new version table record in the write set from the index tree, sets the tmax of the first copy of the old version table record in the write set in global memory and the near-real-time slave node copy (if there is a near-real-time slave node copy) to -1, restores the indirect of the old version table record in the write set to point to the old version, and sets the lotxid of all rhead records in the write set to 0. At this time, the coordinating node retrieves the list of local transactions waiting for visibility determination in the local transaction and wakes them all up. It should be noted that the awakened transactions will re-check the visibility of the records. Then the coordinating node adds the local transactions to the recycling list, waits for all active transactions to finish, and then performs global and local memory reclamation of the new version table record.

[0183] Upon receiving a transaction rollback request, participating nodes can employ a similar approach to that of the coordinating node. Specifically, participating nodes iterate through the write set, applying the modifications made in the current transaction. If the global memory for the old version table record in the write set is replicated on this node, `tmax` is set to -1, and the `indirect` pointer of the old version table record in the write set is restored to point to that old version. The `lotxid` pointer of all `rhead` records in the write set is set to 0. At this point, the participating node retrieves the list of local transactions awaiting visibility determination and wakes them all up. The participating node adds the local transactions to the reclamation list and waits for all active transactions to complete before reclaiming the global and local memory for the new version table record.

[0184] For query operations, the coordinating node (either a master node or a real-time slave node) can determine the visible version and directly return the record data of the table record to the client. Specifically, when the transaction isolation level is SSI, if the table record has not yet been committed (tmin or tmax indicates uncommitted when gtxid is used) and the beginTs of this transaction is greater than the beginTs of the local transaction corresponding to the uncommitted record, the coordinating node can add this transaction to the waiting queue of the other party's transaction; otherwise, it directly returns the record data of the table record.

[0185] In some possible implementations, the distributed database system 100 also includes near real-time slave nodes. These near real-time slave nodes can receive query requests from clients related to analytical tasks, and generate index trees and data copies locally by replaying the redo log. Specifically, the near real-time slave nodes can periodically (e.g., at 0.5-second intervals) replay all redo logs, using the table record content and global memory addresses recorded in the redo logs to generate local index trees and new version table record data.

[0186] To ensure the consistency of redo log replay content, near real-time slave nodes can take the minimum endTs of all active transactions in the cluster as the replay cutoff time. Transaction logs in the redo log that are less than this endTs will be replayed.

[0187] In this embodiment, the transaction commit protocol defines a write conflict (write-write conflict or read-write conflict) control method. Specifically, the coordinating node adopts pessimistic concurrency control (also known as pessimistic locking), and the participating nodes adopt optimistic concurrency control (also known as optimistic locking). On the one hand, this can avoid write-write conflicts or read-write conflicts, ensuring consistency between the coordinating node and the participating nodes. On the other hand, it can reduce the interaction between the coordinating node and the participating nodes, shorten the synchronization time, and achieve real-time consistency.

[0188] The principle of pessimistic concurrency control is that it assumes multiple concurrent transactions will affect each other during processing. Therefore, data can be modified by preventing one transaction from doing so. Specifically, if a transaction performs an operation such as reading a row of data using pessimistic concurrency control (pessimistic locking), then other transactions can only execute conflicting operations after this transaction releases its privileges. The principle of optimistic concurrency control is that it assumes multiple concurrent transactions will not affect each other during processing. Each transaction can process its affected portion of the data without generating locks. Before committing data updates, each transaction checks whether any other transaction has modified the data after it has read it. If other transactions have updated the data, the transaction currently committing will roll back.

[0189] Based on the above description, this application provides a transaction processing method. In this method, a portion of the memory of multiple nodes in a distributed database system 100 is used to form a global memory. This global memory is visible to the coordinating node and participating nodes in the distributed database system 100. That is, the global memory is shared by the coordinating node and participating nodes. When the coordinating node executes a transaction that causes changes to the data stored in a portion of the global memory, the participating nodes can quickly detect the change and access the portion of the global memory across nodes based on the transaction commit protocol via RDMA or memoryfabric for data synchronization, without having to synchronize data through message interaction. This significantly shortens the synchronization time, achieves real-time consistency between the coordinating node and participating nodes, and meets the real-time consistency requirements of real-time services. In addition, the capacity of the global memory can expand with the number of nodes, no longer limited by the capacity of a single node's memory, thus improving concurrency control capabilities.

[0190] Compared to traditional disk-based disk engine clusters, the memory engine cluster provided in this application embodiment has no pages and no rollback logs, resulting in better performance. Furthermore, this application embodiment provides different types of nodes, such as master nodes, real-time slave nodes, and near-real-time slave nodes, to meet the needs of real-time read / write operations (e.g., transaction scenarios), real-time read-only operations (e.g., real-time analysis scenarios), or non-real-time read-only operations (e.g., non-real-time analysis scenarios). This application embodiment can also set the number of replicas of table records in global memory at the table granularity, which can control memory usage and meet the high availability requirements of different data tables.

[0191] The above text combined Figures 1 to 8 The transaction processing method provided in the embodiments of this application has been described in detail. The distributed database system 100 and transaction processing system 10 provided in the embodiments of this application will be described below with reference to the accompanying drawings.

[0192] See Figure 1 The diagram shown illustrates the structure of a distributed database system 100, which includes:

[0193] The coordinating node is used to receive multiple query statements sent by the client;

[0194] The coordinating node is also configured to create a transaction based on a first query statement among the plurality of query statements, execute the transaction in the global memory based on a second query statement among the plurality of query statements, and commit the transaction based on a third query statement among the plurality of query statements.

[0195] In some possible implementations, the distributed database system is deployed on a cluster, and the global memory comes from the cluster.

[0196] In some possible implementations, the global memory includes a portion of the memory of the coordinating node and / or the participating nodes.

[0197] In some possible implementations, the coordinating node is a master node, and the coordinating node is specifically used for:

[0198] A read-write transaction is created based on the first query statement among the multiple query statements.

[0199] In some possible implementations, the coordinating node is a first slave node, which is used to maintain real-time consistency with the node of type master node. Specifically, the coordinating node is used for:

[0200] Create a read-only transaction based on the first query statement among the multiple query statements.

[0201] In some possible implementations, the coordinating node is also used to receive and store the number of table records in the global memory sent by the cluster management node;

[0202] The participating node is also used to receive and store the number of table records in the global memory sent by the cluster management node.

[0203] In some possible implementations, the table records are stored in the global memory of the distributed database system, while the index tree and management header of the table records are stored in the local memory of the distributed database system.

[0204] In some possible implementations, the coordinating node is specifically used for:

[0205] Based on the third query statement among the multiple query statements, the transaction is committed through the transaction commit protocol running on the coordinating node and the participating nodes to achieve real-time consistency between the coordinating node and the participating nodes.

[0206] In some possible implementations, the coordinating node is specifically used to trigger pessimistic concurrency control when a write conflict occurs in the transaction;

[0207] The participating node is specifically used to trigger optimistic concurrency control when a write conflict occurs in the transaction.

[0208] The distributed database system 100 according to the embodiments of this application can correspond to the execution of the methods described in the embodiments of this application, and the above and other operations and / or functions of each module / unit of the distributed database system 100 are respectively for implementing Figure 4 For the sake of brevity, the corresponding processes of each method in the illustrated embodiments will not be described in detail here.

[0209] Based on the distributed database system 100 provided in the embodiments of this application, the embodiments of this application also provide a transaction processing system 10. See also Figure 1 The schematic diagram of the transaction processing system 10 shown includes a distributed database system 100 and a client 200.

[0210] The distributed database system 100 is used to execute corresponding transaction processing methods based on the query statements sent by the client 200, such as executing... Figure 4 The transaction processing method is illustrated below. Specifically, client 200 sends multiple query statements to distributed database system 100. The coordinating node of distributed database system 100 receives the multiple query statements, creates a transaction based on the first query statement among the multiple query statements, executes the transaction in the global memory based on the second query statement among the multiple query statements, and commits the transaction based on the third query statement among the multiple query statements.

[0211] In some possible implementations, the transaction processing system 10 also includes a database 300, and the distributed database system 100 executes transaction processing methods to manage the data in the database 300, such as inserting new record data, updating record data, or deleting record data, etc.

[0212] Similarly, the transaction processing system 10 also includes a cluster management node 400. This cluster management node 400 is used to configure the nodes of the distributed database system deployed in the cluster, such as configuring node IPs and node types. The transaction processing system 10 may also include a time synchronization server 500, which provides timestamps to the distributed database system 100 to determine the visibility of data to transactions based on the timestamps.

[0213] This application embodiment also provides a cluster 90. The cluster 90 includes multiple computers. These computers can be servers, such as local servers in a private data center or cloud servers provided by a cloud service provider. The computers can also be terminals. Terminals include, but are not limited to, desktop computers, laptops, and smartphones. The cluster 90 is specifically used to implement the functions of the distributed database system 100.

[0214] Figure 9 A schematic diagram of the structure of cluster 90 is provided, such as Figure 9 As shown, cluster 90 includes multiple computers 900. Each device 900 includes a bus 901, a processor 902, a communication interface 903, and a memory 904. The processor 902, memory 904, and communication interface 903 communicate via the bus 901.

[0215] The 901 bus can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of representation, Figure 9 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0216] The processor 902 can be any one or more of the following processors: central processing unit (CPU), graphics processing unit (GPU), microprocessor (MP), or digital signal processor (DSP).

[0217] Communication interface 903 is used for communication with external systems. For example, communication interface 903 can be used to receive multiple query statements sent by client 200, obtain start timestamps and end timestamps from time synchronization server 500, or return a submission response to client 200, etc.

[0218] Memory 904 may include volatile memory, such as random access memory (RAM). Memory 904 may also include non-volatile memory, such as read-only memory (ROM), flash memory, hard disk drive (HDD), or solid state drive (SSD).

[0219] The memory 904 stores executable code, and the processor 902 executes the executable code to perform the aforementioned transaction processing method.

[0220] Specifically, in achieving Figure 1 In the case of the illustrated embodiment, and Figure 1 When the components of the distributed database system 100 described in the embodiment are implemented in software, the execution... Figure 1 The software or program code required for the functions of each component is stored in memory 904. Processor 902 executes the program code corresponding to each component stored in memory 904 to perform the aforementioned transaction processing method.

[0221] This application also provides a computer-readable storage medium including instructions that instruct a computer 900 to execute the transaction processing method applied to a distributed database system 100 described above.

[0222] It should be noted that the instructions in the computer-readable storage medium can be executed by multiple computers 900 in the cluster 90. Therefore, each computer 900 can also execute a part of the transaction processing method applied to the distributed database system 100 described above. For example, some computers can execute the steps in the transaction processing method executed by the coordinating node, while other computers can execute the steps in the transaction processing method executed by the participating nodes.

[0223] This application also provides a computer program product, which, when executed by a computer, enables the computer to perform any of the aforementioned transaction processing methods. The computer program product can be a software installation package; when any of the aforementioned transaction processing methods is required, the computer program product can be downloaded and executed on the computer.

Claims

1. A transaction processing method, characterized in that, Applied to a distributed database system, the distributed database system including a coordinating node and participating nodes, the coordinating node and the participating nodes sharing global memory, the method includes: The coordination node receives multiple query statements sent by the client; The coordinating node creates a transaction based on the first query statement among the multiple query statements; The coordinating node executes the transaction in the global memory according to the second query statement among the multiple query statements; The coordinating node submits the transaction based on the third query statement among the multiple query statements; The coordinating node submitting the transaction according to the third query statement among the multiple query statements includes: the coordinating node sending a pre-synchronization request message to the participating node, the pre-synchronization request message including the operation type and the global memory address of the old and new version table records, the record data of the new version table records, and receiving a pre-synchronization response message sent by the participating node in creating a local transaction according to the pre-synchronization request message.

2. The method according to claim 1, characterized in that, The distributed database system is deployed on a cluster, and the global memory comes from the cluster.

3. The method according to claim 1, characterized in that, The global memory includes a portion of the memory of the coordinating node and / or the participating nodes.

4. The method according to any one of claims 1 to 3, characterized in that, The coordinating node is a master node, and it creates a transaction based on the first query statement among the multiple query statements, including: The coordinating node creates a read-write transaction based on the first query statement among the multiple query statements.

5. The method according to any one of claims 1 to 3, characterized in that, The coordinating node is a first slave node, which is used to maintain real-time consistency with the node of the master node type. The coordinating node creates a transaction based on the first query statement among the multiple query statements, including: The coordinating node creates a read-only transaction based on the first query statement among the multiple query statements.

6. The method according to any one of claims 1 to 3, characterized in that, Before the coordinating node receives multiple query statements sent by the client, the method further includes: The distributed database system receives the number of table records in the global memory sent by the cluster management node; The distributed database system stores the number of copies of the table records in the global memory.

7. The method according to claim 6, characterized in that, The table records are stored in the global memory of the distributed database system, while the index tree and management header of the table records are stored in the local memory of the distributed database system.

8. The method according to any one of claims 1 to 3, characterized in that, The coordinating node submits the transaction based on the third query statement among the multiple query statements, including: The coordinating node submits the transaction based on the third query statement among the multiple query statements, through the transaction commit protocol running on the coordinating node and the participating nodes, so as to achieve real-time consistency between the coordinating node and the participating nodes.

9. The method according to claim 8, characterized in that, When a write conflict occurs in the transaction, the coordinating node triggers pessimistic concurrency control, and the participating node triggers optimistic concurrency control.

10. A distributed database system, characterized in that, The system includes a coordinating node and participating nodes, and the coordinating node and participating nodes share global memory. The coordination node is used to receive multiple query statements sent by the client; The coordinating node is further configured to create a transaction based on a first query statement among the plurality of query statements, execute the transaction in the global memory based on a second query statement among the plurality of query statements, and commit the transaction based on a third query statement among the plurality of query statements; Specifically, the coordinating node is used to: send a pre-synchronization request message to the participating node, the pre-synchronization request message including the operation type and the global memory address of the old and new version table records, and the record data of the new version table records; and receive a pre-synchronization response message sent by the participating node in creating a local transaction based on the pre-synchronization request message.

11. The system according to claim 10, characterized in that, The distributed database system is deployed on a cluster, and the global memory comes from the cluster.

12. The system according to claim 10, characterized in that, The global memory includes a portion of the memory of the coordinating node and / or the participating nodes.

13. The system according to any one of claims 10 to 12, characterized in that, The coordinating node is a master node, and the coordinating node is specifically used for: A read-write transaction is created based on the first query statement among the multiple query statements.

14. The system according to any one of claims 10 to 12, characterized in that, The coordinating node is a first slave node, which is used to maintain real-time consistency with the node of the master node type. Specifically, the coordinating node is used for: Create a read-only transaction based on the first query statement among the multiple query statements.

15. The system according to any one of claims 10 to 12, characterized in that, The coordinating node is also used to receive and store the number of table records in the global memory sent by the cluster management node; The participating node is also used to receive and store the number of table records in the global memory sent by the cluster management node.

16. The system according to claim 15, characterized in that, The table records are stored in the global memory of the distributed database system, while the index tree and management header of the table records are stored in the local memory of the distributed database system.

17. The system according to any one of claims 10 to 12, characterized in that, The coordination node is specifically used for: Based on the third query statement among the multiple query statements, the transaction is committed through the transaction commit protocol running on the coordinating node and the participating nodes to achieve real-time consistency between the coordinating node and the participating nodes.

18. The system according to claim 17, characterized in that, The coordinating node is specifically used to trigger pessimistic concurrency control when a write conflict occurs in the transaction. The participating node is specifically used to trigger optimistic concurrency control when a write conflict occurs in the transaction.

19. A transaction processing system, characterized in that, The transaction processing system includes a client and a distributed database system as described in any one of claims 10 to 18, wherein the distributed database system is used to execute a corresponding transaction processing method based on a query statement sent by the client.

20. A cluster, characterized in that, The system comprises multiple computers, each including a processor and a memory, the memory storing computer-readable instructions, the processor executing the computer-readable instructions to cause the cluster to perform the transaction processing method as described in any one of claims 1 to 9.

21. A computer-readable storage medium, characterized in that, Includes computer-readable instructions that, when executed on a computer, cause the computer to perform the transaction processing method as described in any one of claims 1 to 9.

Images