Transaction execution method and distributed database system

Abstract

The present application provides a transaction execution method and distributed database system, relating to the field of cloud computing. In this embodiment, the coordination node CN and the data node DN use the first start timestamp and timestamp list of the target transaction provided by the timing node TSO to modify the local active transaction information and obtain the globally consistent active transaction information corresponding to the target transaction; based on the globally consistent active transaction information, the target transaction is executed. This embodiment integrates TSO and local active transaction information, modifies the local active transaction information according to the timestamp assigned by TSO, and achieves global transaction consistency.

Description

Technical Field

[0001] The present application relates to the field of cloud computing technology, and in particular to a transaction execution method and a distributed database system. Background Art

[0002] In mainstream stand-alone relational databases, Multi-Version Concurrency Control (MVCC) is generally used as a concurrency control technology to ensure transaction consistency. This technology provides transaction isolation for each database session. With the ever-increasing volume of data, stand-alone databases are no longer sufficient. Distributed databases are rapidly developing, and they can scale storage and throughput by expanding nodes.

[0003] However, in a distributed architecture, data distribution and transaction processing involve different physical machines. The original single-machine MVCC technology cannot guarantee the consistency of global transactions, resulting in the inability to execute transactions correctly. Summary of the Invention

[0004] The embodiments of the present application provide a transaction execution method and a distributed database system to achieve consistency of global transactions in a distributed database and ensure correct execution of transactions.

[0005] In a first aspect, an embodiment of the present application provides a transaction execution method, which is applied to a coordination node CN in a database, and includes:

[0006] Receive the execution request of the target transaction and obtain local active transaction information; the transactions in the local active transaction information include uncommitted transactions;

[0007] Obtain the first start timestamp and timestamp list of the target transaction from the time service node TSO in the database, where the timestamp list includes the second start timestamps of transactions that have been prepared but not submitted before the first start timestamp;

[0008] Modify the local active transaction information according to the first start timestamp and the timestamp list to obtain the globally consistent active transaction information corresponding to the target transaction;

[0009] Execute the target transaction based on the globally consistent active transaction information to achieve global transaction consistency.

[0010] In a second aspect, an embodiment of the present application provides a transaction execution method, which is applied to a data node DN in a database, and includes:

[0011] Receive a first start timestamp and a timestamp list of a target transaction sent by a CN or TSO, where the timestamp list includes second start timestamps of transactions that have been prepared but not yet committed before the first start timestamp;

[0012] Obtain local active transaction information; transactions in local active transaction information include uncommitted transactions;

[0013] Modify the local active transaction information according to the first start timestamp and the timestamp list to obtain the globally consistent active transaction information corresponding to the target transaction;

[0014] Execute the target transaction based on the globally consistent active transaction information to achieve global transaction consistency.

[0015] In a third aspect, an embodiment of the present application provides a transaction execution method, which is applied to a time service node TSO in a database, and includes:

[0016] Receive the start timestamp acquisition request of the target transaction sent by CN or DN;

[0017] The first start timestamp and timestamp list of the target transaction are sent to the CN or DN, so that the CN or DN modifies the local active transaction information according to the first start timestamp and timestamp list to obtain the globally consistent active transaction information corresponding to the target transaction; the timestamp list includes the second start timestamps of the transactions that have been prepared but not committed before the first start timestamp; the globally consistent active transaction information is used by the CN or DN to execute the target transaction to achieve global transaction consistency.

[0018] In a fourth aspect, an embodiment of the present application provides a transaction execution method, the method comprising:

[0019] The timing node TSO receives a request for obtaining the start timestamp of the target transaction sent by the coordinating node CN or the data node DN;

[0020] The TSO sends the first start timestamp and a timestamp list of the target transaction to the CN or DN; the timestamp list includes the second start timestamps of transactions that have been prepared but not committed before the first start timestamp;

[0021] The CN or DN modifies the local active transaction information based on the first start timestamp and the timestamp list to obtain the globally consistent active transaction information corresponding to the target transaction;

[0022] CN or DN executes the target transaction based on the globally consistent active transaction information to achieve global transaction consistency.

[0023] In a fifth aspect, an embodiment of the present application provides a distributed database system, which includes a coordination node CN, a data node DN, and a timing node TSO according to any one of the above embodiments.

[0024] In a sixth aspect, an embodiment of the present application provides an electronic device, comprising a memory, a processor, and a computer program stored in the memory, wherein the processor implements any of the above methods when executing the computer program.

[0025] In a seventh aspect, an embodiment of the present application provides a computer-readable storage medium, in which a computer program is stored. When the computer program is executed by a processor, any of the above methods is implemented.

[0026] Compared with the prior art, this application has the following advantages:

[0027] The embodiment of the present application provides a transaction execution method and a distributed database system, in which the coordination node CN and the data node DN use the first start timestamp and timestamp list of the target transaction provided by the timing node TSO to modify the local active transaction information and obtain the globally consistent active transaction information corresponding to the target transaction; and execute the target transaction according to the globally consistent active transaction information. In this embodiment, TSO and local active transaction information are integrated, and the local active transaction information is modified according to the timestamp assigned by TSO to achieve global transaction consistency. Through the TSO global centralized timing service, the timestamp length is fixed and does not increase with the increase in transactions, and does not affect the scalability of the distributed cluster. Moreover, by modifying the local active transaction information, the MVCC based on the active transaction table in the kernel of a single-machine database is retained, and there is no need for MVCC development based on timestamps, which reduces modifications to the kernel and avoids concurrency conflicts caused by the misalignment of write timestamps and read timestamps, thereby achieving high scalability, high compatibility and high stability of the database kernel.

[0028] The above description is only an overview of the technical solution of this application. In order to more clearly understand the technical means of this application, it can be implemented in accordance with the contents of the specification. In order to make the above and other purposes, features and advantages of this application more obvious and easy to understand, the specific implementation methods of this application are listed below. BRIEF DESCRIPTION OF THE DRAWINGS

[0029] In the accompanying drawings, unless otherwise specified, the same reference numerals throughout the multiple drawings represent the same or similar components or elements. These drawings are not necessarily drawn to scale. It should be understood that these drawings only depict some embodiments according to the present application and should not be regarded as limiting the scope of the present application.

[0030] Figure 1 A schematic diagram of a scenario for the transaction execution method provided in this application;

[0031] Figure 2 This is a flowchart of a transaction execution method according to an embodiment of the present application;

[0032] Figure 3 This is a flowchart of a transaction execution method according to an embodiment of the present application;

[0033] Figure 4 This is a flowchart of a transaction execution method according to an embodiment of the present application;

[0034] Figure 5 This is an interactive diagram of the distributed transaction execution process at the RR / SSI isolation level according to an embodiment of the present application;

[0035] Figure 6 This is an interactive diagram of the distributed transaction execution process at the RC isolation level according to an embodiment of the present application;

[0036] Figure 7 This is an interaction diagram of the non-distributed transaction execution process at the RR / SSI isolation level according to an embodiment of the present application;

[0037] Figure 8 This is an interaction diagram of a non-distributed transaction execution process at the RC isolation level according to an embodiment of the present application;

[0038] Figure 9 This is a structural block diagram of a transaction execution device according to an embodiment of the present application;

[0039] Figure 10 This is a structural block diagram of a transaction execution device according to an embodiment of the present application;

[0040] Figure 11 A structural block diagram of a transaction execution device according to an embodiment of the present application; and

[0041] Figure 12 A block diagram of an electronic device used to implement an embodiment of the present application. DETAILED DESCRIPTION

[0042] Hereinafter, only certain exemplary embodiments are briefly described. As will be appreciated by those skilled in the art, the described embodiments may be modified in various ways without departing from the spirit or scope of the present application. Therefore, the drawings and description are to be regarded as illustrative in nature and not restrictive.

[0043] To facilitate understanding of the technical solutions of the embodiments of the present application, the following describes the related technologies of the embodiments of the present application. The following related technologies can be combined with the technical solutions of the embodiments of the present application as optional solutions, and all of them fall within the scope of protection of the embodiments of the present application.

[0044] Figure 1FIG. 1 is a schematic diagram of an exemplary application scenario for implementing the method of the embodiment of the present application. Figure 1 As shown, the database system includes a timer oracle (TSO), a coordinator node (CN) 1, a coordinator node 2, a data node (DN) 1, and a data node 2, wherein the coordinator node and the data node can be multiple and can be configured according to specific needs. Each node can be deployed in its own corresponding device. The timer node can be in the form of a component and can be deployed in the same device as the coordinator node or the data node, or it can be deployed separately. Multiple data tables can be stored in the coordinator node or the data node, and each data table can be used to store one or more data items.

[0045] The coordinating node receives a request from the application to execute a target transaction and obtains local active transaction information. This information includes transactions that have not yet been committed. The coordinating node obtains the target transaction's first start timestamp and a timestamp list from the TSO. The timestamp list includes the second start timestamps of transactions that were prepared but not yet committed before the first start timestamp. Based on the first start timestamp and the timestamp list, the coordinating node modifies the local active transaction information to obtain globally consistent active transaction information corresponding to the target transaction. The coordinating node then executes the target transaction based on the globally consistent active transaction information to achieve global transaction consistency. The local active transaction information can be a snapshot of the local active transaction list, which includes identification information for the local active transaction. The target transaction can be a distributed or non-distributed transaction. A transaction is a series of operations performed as a single logical unit of work. It can include multiple statements and is either fully executed or not executed at all. By combining a set of related operations into a unit that either succeeds or fails, error recovery is simplified and applications are more reliable. To qualify as a transaction, a logical unit of work must meet the properties of atomicity, consistency, isolation, and durability. A distributed transaction means that the transaction participants, transaction-supporting devices, resource devices, and transaction managers are located on different nodes of different distributed systems.

[0046] If the target transaction is a distributed transaction, DN receives the first start timestamp and timestamp list of the target transaction sent by CN. If the target transaction is a non-distributed transaction, CN or DN receives the first start timestamp and timestamp list of the target transaction sent by TSO. The timestamp list includes the second start timestamps of transactions that have been prepared but not submitted before the first start timestamp. CN or DN obtains local active transaction information; the transactions in the local active transaction information include transactions that have not been submitted; based on the first start timestamp and timestamp list, the local active transaction information is modified to obtain the globally consistent active transaction information corresponding to the target transaction; based on the globally consistent active transaction information, the target transaction is executed to achieve global transaction consistency. If the target transaction is a distributed transaction, after the target transaction is prepared, CN obtains the commit timestamp from TSO; sends a commit operation request to the data node DN in the database, the commit operation request carries the commit timestamp, and executes the commit operation after receiving the commit success notification message sent by DN.

[0047] The TSO receives a request for obtaining the start timestamp of a target transaction sent by a CN or DN; sends the first start timestamp and a timestamp list of the target transaction to the CN or DN, so that the CN or DN modifies the local active transaction information according to the first start timestamp and the timestamp list to obtain the globally consistent active transaction information corresponding to the target transaction; the timestamp list includes the second start timestamps of transactions that have been prepared but not committed before the first start timestamp; the globally consistent active transaction information is used by the CN or DN to execute the target transaction to achieve global transaction consistency.

[0048] In a related technology, a global transaction manager (GTM) centrally maintains the state of all transactions in the cluster through a global active transaction table and generates snapshots of the active transaction table for each transaction. Transactions on each node use snapshots to determine data visibility and maintain global transaction consistency. However, as the number of nodes increases, the number of globally active transactions increases, resulting in larger snapshot data. This in turn causes the central node network to become a bottleneck, restricting the scalability of the cluster and preventing the expansion of additional nodes, limiting the scale of distributed database clusters.

[0049] Another related technology uses TSO to provide monotonically increasing timestamps, implementing MVCC based on timestamps. If the database kernel uses MVCC based on the active transaction table, the MVCC mechanism must be redeveloped, which is highly invasive to the kernel and difficult to develop. Its compatibility and stability are also inferior to the original MVCC mechanism. Furthermore, in a timestamp-based MVCC solution, if the write timestamp is less than the latest read timestamp, the transaction will be aborted, increasing concurrency conflicts.

[0050] In addition, in the timestamp-based MVCC solution, TSO needs to assign a commit timestamp to each submitted transaction for visibility consistency judgment, which reduces transaction execution efficiency. This embodiment integrates MVCC of the active transaction table. When each non-distributed transaction commits, a global transaction identifier is assigned locally. Non-distributed transaction commits do not need to obtain a commit timestamp. Visibility consistency judgment can be completed based on the local active transaction table, improving transaction execution efficiency.

[0051] In this embodiment, TSO and local active transaction information are integrated, and the local active transaction information is modified according to the timestamp assigned by TSO to achieve global transaction consistency. Compared with related technologies, through the TSO global centralized timing service, the timestamp length is fixed and does not increase with the increase in transactions, which will not affect the scalability of the distributed cluster. Moreover, by modifying the local active transaction information, the MVCC based on the active transaction table in the stand-alone database kernel is retained, eliminating the need for timestamp-based MVCC development, reducing kernel modifications, and avoiding concurrency conflicts caused by the misalignment of write timestamps and read timestamps, thereby achieving high scalability, high compatibility, and high stability of the database kernel.

[0052] The present application embodiment provides a transaction execution method, such as Figure 2 FIG2 is a flow chart of a transaction execution method according to an embodiment of the present application. The method is applied to a coordination node CN in a database. The method includes:

[0053] Step S201: Receive an execution request for a target transaction and obtain local active transaction information; the transactions in the local active transaction information include uncompleted committed transactions.

[0054] Step S202: Obtain a first start timestamp and a timestamp list of the target transaction from the timing service node TSO in the database, where the timestamp list includes second start timestamps of transactions that have been prepared but not submitted before the first start timestamp.

[0055] Step S203: Modify the local active transaction information according to the first start timestamp and the timestamp list to obtain the globally consistent active transaction information corresponding to the target transaction.

[0056] Step S204: Execute the target transaction according to the globally consistent active transaction information to achieve global transaction consistency.

[0057] The coordinating node CN receives a target transaction execution request, which can be sent by an application or other means. After receiving the target transaction execution request, the CN obtains local active transaction information. The specific form of local active transaction information is not limited; for example, it can be a snapshot of the local active transaction list. The local active transaction list includes identification information of the active transaction.

[0058] The target transaction can be either a distributed transaction or a non-distributed transaction. A transaction is a series of operations performed as a single logical unit of work. It can include multiple statements and is either fully executed or not executed at all. By combining a set of related operations into a unit that either all succeeds or all fails, error recovery can be simplified and applications can be made more reliable. To qualify as a transaction, a logical unit of work must meet the properties of atomicity, consistency, isolation, and durability. A distributed transaction refers to a transaction in which the participants, transaction-supporting devices, resource devices, and transaction managers are located on different nodes in different distributed systems. Distributed transactions enable cross-node data queries, while non-distributed transactions complete data queries within a single node.

[0059] Transaction status information includes: Inprocess, Prepared, Committing, and Committed. Locally active transaction information includes the identifiers of uncommitted transactions. Uncommitted transactions include those with Inprocess, Prepared, and Committed status information.

[0060] The CN sends a request to the TSO for the timestamp of the target transaction and receives the start timestamp and timestamp list of the target transaction from the TSO. The TSO provides a global centralized timing service, providing a start timestamp for each transaction in a linearly increasing manner, and a commit timestamp for distributed transactions.

[0061] Exemplarily, the CN modifies the snapshot of the local active transaction list based on the start timestamp and timestamp list sent by the TSO, obtains the snapshot of the global consistency active transaction list corresponding to the target transaction, and executes the target transaction based on the snapshot of the global consistency active transaction list to achieve data consistency when multiple transactions are executed concurrently in at least one node.

[0062] The transaction execution method provided in this embodiment integrates TSO and local active transaction information, and modifies the local active transaction information according to the timestamp assigned by TSO to achieve global transaction consistency. Compared with related technologies, through the TSO global centralized timing service, the timestamp length is fixed and does not increase with the increase in transactions, which will not affect the scalability of the distributed cluster. Moreover, by modifying the local active transaction information, the MVCC based on the active transaction table in the kernel of the stand-alone database is retained, and the development of MVCC based on timestamps is not required, which reduces the modification of the kernel and avoids the concurrency conflicts caused by the misalignment of write timestamps and read timestamps, thereby achieving high scalability, high compatibility and high stability of the database kernel.

[0063] The specific implementation of step S203 is shown in the following embodiment:

[0064] In one possible implementation, modifying local active transaction information according to the first start timestamp and the timestamp list to obtain globally consistent active transaction information corresponding to the target transaction includes:

[0065] According to the transaction status information, the first start timestamp, and the timestamp list, the transaction is deleted and / or added to the local active transaction information to obtain the globally consistent active transaction information corresponding to the target transaction.

[0066] In actual applications, CN obtains transaction status information from the shared cache interval. The transaction status information includes: in process, prepared, committing, and committed. According to the transaction status information, the timestamp in the timestamp list, and the start timestamp of the target transaction, the transaction is filtered, and the identification information of the filtered transaction is deleted from the snapshot of the local active transaction list, and / or the identification information of the filtered transaction is added to the snapshot of the local active transaction list. The transaction identification information can be the global identifier xid of the transaction. In this embodiment, by deleting and / or adding transactions in the local active transaction information, the globally consistent active transaction information corresponding to the target transaction is obtained for the execution of the target transaction. By modifying the local active transaction information, the MVCC based on the active transaction table in the stand-alone database kernel is retained, and the development of MVCC based on timestamps is not required, which reduces the modification of the kernel. At the same time, it avoids the concurrency conflicts caused by the misalignment of write timestamps and read timestamps, and realizes the high scalability, high compatibility and high stability of the database kernel.

[0067] The transaction to be deleted is determined in the local active transaction information, as shown in the following embodiment:

[0068] In one possible implementation, based on the transaction status information, the first start timestamp, and the timestamp list, the transaction is deleted from the local active transaction information to obtain the globally consistent active transaction information corresponding to the target transaction, including:

[0069] In the local active transaction information, perform at least one of the following operations to obtain the globally consistent active transaction information corresponding to the target transaction: delete transactions whose status information is "Committing" and whose commit timestamp is less than the first start timestamp; the commit timestamp is obtained from the TSO; delete transactions whose status information is "Prepare Completed" and whose start timestamp is in the timestamp list.

[0070] Exemplarily, when traversing transaction status information in the shared memory, transactions deleted from a snapshot of a local active transaction list include at least one of the following: transaction status information is committing, and the commit timestamp is less than the start timestamp of the target transaction; transaction status information is prepared for completion, and the start timestamp of the transaction is in the timestamp list.

[0071] In a possible implementation, the method further includes:

[0072] Set the deleted transactions in the local active transaction information to be visible to the target transaction.

[0073] In actual applications, pre-visibility settings are performed for transactions deleted from the snapshot of the local active transaction list. This is because deletion from the snapshot means that the transaction is visible to the target transaction, but since it has not yet been committed, according to the global consistency judgment criteria, the data is considered visible, and the transaction is set to be visible to the target transaction in advance.

[0074] Exemplarily, the global transaction consistency determination criteria include: comparing the commit timestamp commit_ts of one transaction with the start timestamp start_ts of another transaction, performing visibility determination, and if transaction T1.commit_ts < transaction T2.start_ts, determining that transaction T1 is visible to transaction T2, otherwise it is not visible.

[0075] Through global consistency judgment, the transaction deleted from the active transaction table indicates that the transaction has been committed. However, due to the two-phase commit of the corresponding distributed transaction, its commit phase has not yet been executed on this node, so the local transaction is still in the active transaction table. After the global consistency judgment sets the uncommitted transaction to visible, the uncommitted transaction status is set to committed in advance. When the subsequent commit process of this uncommitted transaction arrives, it does not need to be set to visible again in the transaction commit process. In this embodiment, by pre-setting visible, the global consistent visibility judgment is satisfied while avoiding the inefficiency caused by waiting for commit.

[0076] The transaction to be added to the local active transaction information is determined, as shown in the following embodiment:

[0077] In one possible implementation, based on the transaction status information and the first start timestamp, the transaction is added to the local active transaction information to obtain the globally consistent active transaction information corresponding to the target transaction, including:

[0078] Determine the committed transaction whose status information is committed and whose commit timestamp is greater than the first start timestamp. If the identification number of the committed transaction is less than the minimum identification number in the local active transaction information and the old version data of the committed transaction has been cleared, terminate the execution of the target transaction. Otherwise, add the committed transaction to the local active transaction information to obtain the globally consistent active transaction information corresponding to the target transaction.

[0079] In actual applications, the transaction status information in shared memory is traversed, and committed transactions with a commit completion status and a commit timestamp greater than the start timestamp of the target transaction are filtered out. Since transaction identification numbers are assigned incrementally, if the identification number of the committed transaction is less than the minimum identification number in the snapshot of the local active transaction list, it means that the start time of the committed transaction is earlier than the transaction in the current local active transaction information. If the old version data of the committed transaction has been cleared, the execution of the target transaction is terminated. If it is added to the snapshot of the active transaction table, according to the MVCC mechanism of the active transaction table, the current version data is not visible to the target transaction, but the old version data has been cleared, which will cause data errors. Otherwise, the committed transaction is added to the snapshot of the local active transaction list.

[0080] In a possible implementation, the method further includes:

[0081] Determine the number of modifications to local active transaction information based on the isolation level.

[0082] In actual applications, if the target transaction is a distributed transaction, the CN needs to modify the local active transaction information multiple times.

[0083] The isolation level indicates the degree to which a transaction must be isolated from resource or data changes made by other transactions. In this embodiment, the isolation levels may include Read Commit (RC), Repeatable Read (RR), and Serializable Snapshot Isolation (SSI). The isolation level can be configured based on specific needs.

[0084] For example, for distributed and non-distributed transactions at the RR or SSI isolation level, the local active transaction information can be modified when executing the first statement of the transaction to obtain globally consistent active transaction information. When executing subsequent statements of the transaction, this globally consistent active transaction information is directly used without the need to generate it again. For distributed and non-distributed transactions at the RC isolation level, the local active transaction information must be modified and globally consistent active transaction information must be generated once for each statement of the transaction.

[0085] In a possible implementation, the target transaction is a distributed transaction, and the method further includes:

[0086] After the target transaction is prepared, the commit timestamp is obtained from the TSO; a commit operation request is sent to the data node DN in the database, and the commit operation request carries the commit timestamp. After receiving the commit success notification message sent by the DN, the commit operation is executed.

[0087] In actual applications, if the target transaction is a distributed transaction, when the transaction statement execution is completed and needs to be committed, a commit timestamp acquisition request is sent to TSO, the commit timestamp sent by TSO is received, and a commit operation request is sent to DN, with the commit operation request carrying the commit timestamp. DN records the commit timestamp and the identification information of the target transaction, executes the commit operation, and after the commit is completed, a commit success notification message is sent to CN. CN executes the commit operation and carries the first start timestamp, synchronously submits the status information of the target transaction to TSO, and TSO deletes the committed transaction from the cache.

[0088] In a possible implementation, the method further includes:

[0089] When obtaining the start timestamps or commit timestamps of multiple target transactions from the TSO at the same time, multiple timestamp acquisition requests are merged into one request and sent to the TSO, and the same start timestamp or commit timestamp of the multiple target transactions sent by the TSO is received.

[0090] In actual applications, when a transaction in CN wants to apply for a start timestamp, there may be other transactions applying for a start timestamp at the same time, or another transaction applying for a commit timestamp, or synchronously submitting status information to TSO. These operations can be merged into one request message and sent to TSO. When TSO responds to the merge request, it can send a unified start timestamp as the start timestamp of multiple transactions applied at the same time, and the commit timestamp is processed in the same way. In this embodiment, by merging applications, the application frequency can be reduced and the pressure on TSO can be alleviated. TSO does not need to assign a timestamp to each transaction, which can reduce the pressure on TSO and save network bandwidth.

[0091] The present application embodiment provides a transaction execution method, such as Figure 3 FIG2 is a flowchart of a transaction execution method according to an embodiment of the present application. The method is applied to a data node DN in a database. The method includes:

[0092] Step S301: Receive a first start timestamp and a timestamp list of a target transaction sent by a CN or TSO, where the timestamp list includes second start timestamps of transactions that have been prepared but not committed before the first start timestamp.

[0093] Step S302: Obtain local active transaction information; the transactions in the local active transaction information include uncompleted committed transactions.

[0094] Step S303: Modify the local active transaction information according to the first start timestamp and the timestamp list to obtain the globally consistent active transaction information corresponding to the target transaction.

[0095] Step S304: Execute the target transaction according to the globally consistent active transaction information to achieve global transaction consistency.

[0096] If the target transaction is a distributed transaction, the DN receives the target transaction's first start timestamp and timestamp list from the CN. The first start timestamp and timestamp list are obtained by the CN from the TSO. The TSO provides a global centralized timing service, providing a linearly increasing start timestamp for each transaction and a commit timestamp for distributed transactions. If the target transaction is a non-distributed transaction, the DN receives the target transaction's first start timestamp and timestamp list from the TSO.

[0097] After receiving the first start timestamp and the timestamp list, the DN obtains local active transaction information. The specific form of the local active transaction information is not limited, for example, it can be a snapshot of the local active transaction list. The local active transaction list includes identification information of the active transaction.

[0098] The target transaction can be either a distributed transaction or a non-distributed transaction. A transaction is a series of operations performed as a single logical unit of work. It can include multiple statements and is either fully executed or not executed at all. By combining a set of related operations into a unit that either all succeeds or all fails, error recovery can be simplified and applications can be made more reliable. To qualify as a transaction, a logical unit of work must meet the properties of atomicity, consistency, isolation, and durability. A distributed transaction refers to a transaction in which the participants, transaction-supporting devices, resource devices, and transaction managers are located on different nodes in different distributed systems. Distributed transactions enable cross-node data queries, while non-distributed transactions complete data queries within a single node.

[0099] Transaction status information includes: Inprocess, Prepared, Committing, and Committed. Locally active transaction information includes the identifiers of uncommitted transactions. Uncommitted transactions include those with Inprocess, Prepared, and Committed status information.

[0100] Exemplarily, DN modifies the snapshot of the local active transaction list based on the start timestamp and timestamp list sent by CN, obtains the snapshot of the global consistency active transaction list corresponding to the target transaction, and executes the target transaction based on the snapshot of the global consistency active transaction list to achieve data consistency when multiple transactions are executed concurrently in at least one node.

[0101] The transaction execution method provided in this embodiment integrates TSO and local active transaction information, and modifies the local active transaction information according to the timestamp assigned by TSO to achieve global transaction consistency. Compared with related technologies, through the TSO global centralized timing service, the timestamp length is fixed and does not increase with the increase in transactions, which will not affect the scalability of the distributed cluster. Moreover, by modifying the local active transaction information, the MVCC based on the active transaction table in the kernel of the stand-alone database is retained, and the development of MVCC based on timestamps is not required, which reduces the modification of the kernel and avoids the concurrency conflicts caused by the misalignment of write timestamps and read timestamps, thereby achieving high scalability, high compatibility and high stability of the database kernel.

[0102] The specific implementation of step S303 is shown in the following embodiment:

[0103] In one possible implementation, modifying local active transaction information according to the first start timestamp and the timestamp list to obtain globally consistent active transaction information corresponding to the target transaction includes:

[0104] According to the transaction status information, the first start timestamp, and the timestamp list, the transaction is deleted and / or added to the local active transaction information to obtain the globally consistent active transaction information corresponding to the target transaction.

[0105] In actual applications, DN obtains transaction status information from the shared cache interval. The transaction status information includes: in process, prepared, committing, and committed. According to the transaction status information, the timestamp in the timestamp list, and the start timestamp of the target transaction, the transaction is filtered, and the identification information of the filtered transaction is deleted from the snapshot of the local active transaction list, and / or the identification information of the filtered transaction is added to the snapshot of the local active transaction list. The transaction identification information can be the global identifier xid of the transaction. In this embodiment, by deleting and / or adding transactions in the local active transaction information, the globally consistent active transaction information corresponding to the target transaction is obtained for the execution of the target transaction. By modifying the local active transaction information, the MVCC based on the active transaction table in the stand-alone database kernel is retained, and the development of MVCC based on timestamps is not required, which reduces the modification of the kernel. At the same time, it avoids the concurrency conflicts caused by the misalignment of write timestamps and read timestamps, and realizes the high scalability, high compatibility and high stability of the database kernel.

[0106] The transaction to be deleted is determined in the local active transaction information, as shown in the following embodiment:

[0107] In one possible implementation, based on the transaction status information, the first start timestamp, and the timestamp list, the transaction is deleted from the local active transaction information to obtain the globally consistent active transaction information corresponding to the target transaction, including:

[0108] In the local active transaction information, perform at least one of the following operations to obtain the globally consistent active transaction information corresponding to the target transaction: delete transactions whose status information is "Committing" and whose commit timestamp is less than the first start timestamp; the commit timestamp is obtained from the TSO; delete transactions whose status information is "Prepare Completed" and whose start timestamp is in the timestamp list.

[0109] Exemplarily, when traversing transaction status information in the shared memory, transactions deleted from a snapshot of a local active transaction list include at least one of the following: transaction status information is committing, and the commit timestamp is less than the start timestamp of the target transaction; transaction status information is prepared for completion, and the start timestamp of the transaction is in the timestamp list.

[0110] In a possible implementation, the method further includes:

[0111] Set the deleted transactions in the local active transaction information to be visible to the target transaction.

[0112] In actual applications, pre-visibility settings are performed for transactions deleted from the snapshot of the local active transaction list. This is because deletion from the snapshot means that the transaction is visible to the target transaction. However, since it has not yet been committed, the data is considered visible based on the global consistent visibility judgment, and the transaction is set to be visible to the target transaction in advance.

[0113] Through global consistency judgment, the transaction deleted from the active transaction table indicates that the transaction has been committed. However, due to the two-phase commit of the corresponding distributed transaction, its commit phase has not yet been executed on this node, so the local transaction is still in the active transaction table. After the global consistency judgment sets the uncommitted transaction to visible, the uncommitted transaction status is set to committed in advance. When the subsequent commit process of this uncommitted transaction arrives, it does not need to be set to visible again in the transaction commit process. In this embodiment, by pre-setting visible, the global consistent visibility judgment is satisfied while avoiding the inefficiency caused by waiting for commit.

[0114] The transaction to be added to the local active transaction information is determined, as shown in the following embodiment:

[0115] In one possible implementation, based on the transaction status information and the first start timestamp, the transaction is added to the local active transaction information to obtain the globally consistent active transaction information corresponding to the target transaction, including:

[0116] Determine the committed transaction whose status information is committed and whose commit timestamp is greater than the first start timestamp. If the identification number of the committed transaction is less than the minimum identification number in the local active transaction information and the old version data of the committed transaction has been cleared, terminate the execution of the target transaction. Otherwise, add the committed transaction to the local active transaction information to obtain the globally consistent active transaction information corresponding to the target transaction.

[0117] In actual applications, the transaction status information in shared memory is traversed, and committed transactions with a commit completion status and a commit timestamp greater than the start timestamp of the target transaction are filtered out. Since transaction identification numbers are assigned incrementally, if the identification number of the committed transaction is less than the minimum identification number in the snapshot of the local active transaction list, it means that the start time of the committed transaction is earlier than the transaction in the current local active transaction information. If the old version data of the committed transaction has been cleared, the execution of the target transaction is terminated. If it is added to the snapshot of the active transaction table, according to the MVCC mechanism of the active transaction table, the current version data is not visible to the target transaction, but the old version data has been cleared, which will cause data errors. Otherwise, the committed transaction is added to the snapshot of the local active transaction list.

[0118] In a possible implementation, the method further includes:

[0119] Determine the number of modifications to local active transaction information based on the isolation level.

[0120] In actual applications, if the target transaction is a distributed transaction, the DN needs to modify the local active transaction information multiple times.

[0121] The isolation level indicates the degree to which a transaction must be isolated from resource or data changes made by other transactions. In this embodiment, the isolation levels may include Read Commit (RC), Repeatable Read (RR), and Serializable Snapshot Isolation (SSI). The isolation level can be configured based on specific needs.

[0122] For example, for distributed and non-distributed transactions at the RR or SSI isolation level, the local active transaction information can be modified when executing the first statement of the transaction to obtain globally consistent active transaction information. When executing subsequent statements of the transaction, this globally consistent active transaction information is directly used without the need to generate it again. For distributed and non-distributed transactions at the RC isolation level, the local active transaction information must be modified and globally consistent active transaction information must be generated once for each statement of the transaction.

[0123] In a possible implementation, the target transaction is a distributed transaction, and the method further includes:

[0124] Receive a commit operation request sent by the CN, which carries the commit timestamp of the target transaction, record the commit timestamp, perform the commit operation, and send a commit success notification message to the CN to enable the CN to perform the commit operation.

[0125] In actual applications, if the target transaction is a distributed transaction, when the transaction statement execution is completed and needs to be committed, CN sends a commit timestamp acquisition request to TSO, receives the commit timestamp sent by TSO, and sends a commit operation request to DN, with the commit operation request carrying the commit timestamp. DN receives the commit operation request sent by CN, records the commit timestamp and the identification information of the target transaction, executes the commit operation, and sends a commit success notification message to CN after the commit is completed. CN executes the commit operation and carries the first start timestamp, synchronously submits the status information of the target transaction to TSO, and TSO deletes the committed transaction from the cache.

[0126] In a possible implementation, the method further includes:

[0127] When obtaining the start timestamps or commit timestamps of multiple target transactions from the TSO at the same time, multiple timestamp acquisition requests are merged into one request and sent to the TSO, and the same start timestamp or commit timestamp of the multiple target transactions sent by the TSO is received.

[0128] In actual applications, when a transaction in DN wants to apply for a start timestamp, there may be other transactions applying for a start timestamp at the same time, or another transaction applying for a commit timestamp, or synchronously submitting status information to TSO. These operations can be merged into one request message and sent to TSO. When TSO responds to the merge request, it can send a unified start timestamp as the start timestamp of multiple transactions applied at the same time, and the commit timestamp is processed in the same way. In this embodiment, by merging applications, the application frequency can be reduced and the pressure on TSO can be alleviated. TSO does not need to assign a timestamp to each transaction, which can reduce the pressure on TSO and save network bandwidth.

[0129] The present application embodiment provides a transaction execution method, such as Figure 4 FIG2 is a flowchart of a transaction execution method according to an embodiment of the present application. The method is applied to a time service node TSO in a database. The method includes:

[0130] Step S401: Receive a request for obtaining the start timestamp of a target transaction sent by a CN or DN.

[0131] Step S402: Send the first start timestamp and timestamp list of the target transaction to the CN or DN, so that the CN or DN modifies the local active transaction information according to the first start timestamp and timestamp list to obtain the globally consistent active transaction information corresponding to the target transaction; the timestamp list includes the second start timestamps of the transactions that have been prepared but not submitted before the first start timestamp; the globally consistent active transaction information is used by the CN or DN to execute the target transaction to achieve global transaction consistency.

[0132] If the target transaction is a distributed transaction, the TSO receives a request from the CN to obtain the start timestamp of the target transaction and sends the first start timestamp and timestamp list of the target transaction to the CN. If the target transaction is a non-distributed transaction, the TSO receives a request from the CN or DN to obtain the start timestamp of the target transaction and sends the first start timestamp and timestamp list of the target transaction to the CN or DN.

[0133] The transaction execution method provided in this embodiment integrates TSO and local active transaction information, and modifies the local active transaction information according to the timestamp assigned by TSO to achieve global transaction consistency. Compared with related technologies, through the TSO global centralized timing service, the timestamp length is fixed and does not increase with the increase in transactions, which will not affect the scalability of the distributed cluster. Moreover, by modifying the local active transaction information, the MVCC based on the active transaction table in the kernel of the stand-alone database is retained, and the development of MVCC based on timestamps is not required, which reduces the modification of the kernel and avoids the concurrency conflicts caused by the misalignment of write timestamps and read timestamps, thereby achieving high scalability, high compatibility and high stability of the database kernel.

[0134] In a possible implementation, the target transaction is a distributed transaction, and the method further includes:

[0135] Receive the target transaction commit timestamp acquisition request sent by the CN, generate the target transaction commit timestamp and send it to the CN.

[0136] In actual applications, if the target transaction is a distributed transaction and the transaction statement execution is completed and needs to be committed, the CN sends a commit timestamp acquisition request to the TSO. The TSO generates the commit timestamp of the target transaction and sends it to the CN. The CN performs the commit operation and carries the first start timestamp, synchronously submits the status information of the target transaction to the TSO, and the TSO deletes the committed transaction from the cache.

[0137] In one example, the meaning of each field of TSO and its service functions are as follows:

[0138] i. Data structure:

[0139] 1.current_ts / / Used to record the current timestamp.

[0140] 2.tso_prepared / / Used to cache the start_ts that are ready to register transactions.

[0141] ii. Centralized timing service:

[0142] 1. TSO uniformly assigns the SQL statement start timestamp start_ts = current_ts++ to each SQL statement in a linearly increasing manner.

[0143] 2. TSO uniformly assigns a commit timestamp commit_ts=current_ts++ to each completed distributed transaction in a linearly increasing manner.

[0144] iii. Completed preparation of the transaction registration management services:

[0145] 1. TSO provides registration services for each prepared distributed transaction. That is, while assigning the commit timestamp commit_ts, it also records the transaction start timestamp start_ts (that is, the timestamp obtained by the first statement after the transaction starts) in tso_prepared.

[0146] 2. TSO provides a deregistration service for each distributed transaction that has been submitted. This service deregisters the start_ts recorded when applying for commit_ts, and clears the corresponding record of tso_prepared.

[0147] TSO provides a preparation transaction notification service for each transaction that applies for start_ts, that is, it returns all start_ts cached in tso_prepared as a timestamp list start_ts_plist to the transaction that applies for start_ts.

[0148] In one example, the meanings of the fields involved in the process of modifying the snapshot of the local active transaction list by CN or DN are as follows:

[0149] Data structure:

[0150] 1.tso_status / / is used to record the status information of transactions in TSO and the snapshot of the global consistency list after the transaction is started in each node.

[0151] 2.status. / / Used to record the current transaction status information, including Inprocess, Prepared, Committing, and Committed.

[0152] 3.current_start_ts / / Used to record the start timestamp of the current transaction.

[0153] 4.commit_ts / / Used to record the commit timestamp of the current transaction.

[0154] 5.snapshot / / Used to record a snapshot of the local global consistency active transaction table that conforms to the start timestamp start_ts and the timestamp list start_ts_plist.

[0155] 6.tso_commit / / Used to record transaction information after the completion of the commit, including the transaction commit_ts and the global identifier xid information of the corresponding transaction.

[0156] In a distributed transaction, each Structured Query Language (SQL) statement uses a unified start_ts and start_ts_plist on each participating node. These are the SQL statement start timestamp and the list of start timestamps of completed, prepared, but uncommitted transactions registered in the TSO at the current moment.

[0157] Corresponding to the above-mentioned method embodiments, an embodiment of the present application further provides a transaction execution method, which includes:

[0158] Step S11: The timing node TSO receives a request for obtaining the start timestamp of a target transaction sent by the coordinator node CN or the data node DN.

[0159] Step S12: The TSO sends the first start timestamp and a timestamp list of the target transaction to the CN or DN; the timestamp list includes the second start timestamps of transactions that have been prepared but not committed before the first start timestamp.

[0160] In step S13, the CN or DN modifies the local active transaction information according to the first start timestamp and the timestamp list to obtain the globally consistent active transaction information corresponding to the target transaction.

[0161] In step S14, the CN or DN executes the target transaction according to the globally consistent active transaction information to achieve global transaction consistency.

[0162] If the target transaction is a distributed transaction, the TSO receives a request from the CN to obtain the start timestamp of the target transaction and sends the first start timestamp and timestamp list of the target transaction to the CN. If the target transaction is a non-distributed transaction, the TSO receives a request from the CN or DN to obtain the start timestamp of the target transaction and sends the first start timestamp and timestamp list of the target transaction to the CN or DN.

[0163] The coordination node CN receives the execution request of the target transaction and obtains the local active transaction information; the transactions in the local active transaction information include the uncommitted transactions; the first start timestamp and timestamp list of the target transaction are obtained from the time service node TSO in the database, and the timestamp list includes the second start timestamps of the transactions that have been prepared but not yet committed before the first start timestamp; according to the first start timestamp and the timestamp list, the local active transaction information is modified to obtain the globally consistent active transaction information corresponding to the target transaction; according to the globally consistent active transaction information, the target transaction is executed to achieve the consistency of the global transaction.

[0164] The data node DN receives the first start timestamp and timestamp list of the target transaction sent by the CN or TSO, where the timestamp list includes the second start timestamps of transactions that have been prepared but not yet committed before the first start timestamp; obtains local active transaction information; the transactions in the local active transaction information include transactions that have not yet been committed; based on the first start timestamp and the timestamp list, the local active transaction information is modified to obtain the globally consistent active transaction information corresponding to the target transaction; based on the globally consistent active transaction information, the target transaction is executed to achieve consistency of the global transaction.

[0165] The specific working processes of the timing node TSO, the coordination node CN and the data node DN are the same as those of the above method embodiments, and will not be repeated here.

[0166] The transaction execution method provided in this embodiment integrates TSO and local active transaction information, and modifies the local active transaction information according to the timestamp assigned by TSO to achieve global transaction consistency. Compared with related technologies, through the TSO global centralized timing service, the timestamp length is fixed and does not increase with the increase in transactions, which will not affect the scalability of the distributed cluster. Moreover, by modifying the local active transaction information, the MVCC based on the active transaction table in the kernel of the stand-alone database is retained, and the development of MVCC based on timestamps is not required, which reduces the modification of the kernel and avoids the concurrency conflicts caused by the misalignment of write timestamps and read timestamps, thereby achieving high scalability, high compatibility and high stability of the database kernel.

[0167] In order to more clearly introduce the technical ideas of the technical solution of this application, the execution process of distributed transactions and non-distributed transactions will be introduced according to different isolation levels:

[0168] Figure 5 This is an interactive diagram of the distributed transaction execution process at the RR / SSI isolation level provided in the embodiment of the present application. Figure 5 As shown, the execution process includes:

[0169] Step 501: The coordinating node CN receives an execution request of a target transaction and starts executing a first SQL statement.

[0170] Step 502: The coordinating node CN obtains a snapshot of the local active transaction list.

[0171] Step 503: Send a request for obtaining the start timestamp of the target transaction to the timing node.

[0172] Step 504: Generate a start timestamp of the target transaction and obtain a timestamp list from the cache.

[0173] Step 505: Send the start timestamp and timestamp list of the target transaction.

[0174] Step 506: Set the state of the target transaction to being executed. Generate a global snapshot, ie, globally consistent active transaction information, based on the start timestamp of the target transaction, the timestamp list, and the snapshot of the local active transaction list.

[0175] Step 507: Send the start timestamp and timestamp list of the target transaction.

[0176] Step 508: Set the state of the target transaction to being executed. Generate a global snapshot based on the start timestamp of the target transaction, the timestamp list, and the snapshot of the local active transaction list.

[0177] Step 509: Send the first SQL statement.

[0178] Step 510: Execute the second SQL statement using the global snapshot as the snapshot of the target transaction.

[0179] Step 511: Send the second SQL statement.

[0180] Step 512: Execute the first SQL statement using the global snapshot as the snapshot of the target transaction.

[0181] Step 513: Execute the second SQL statement using the global snapshot as the snapshot of the target transaction.

[0182] Step 514: Send a prepare-to-submit request message.

[0183] Step 515 , executing the target transaction preparation process, and setting the target transaction status information to preparation completed after the execution is completed.

[0184] Step 516: Send a preparation success notification message.

[0185] Step 517: Set the status information of the target transaction to be ready.

[0186] Step 518: Carry the start timestamp of the target transaction and apply for the commit timestamp.

[0187] Step 519: Record the start timestamp of the target transaction and calculate the commit timestamp.

[0188] Step 520: Return the commit timestamp of the target transaction.

[0189] Step 521: Set the status of the target transaction to being submitted, and record the submission timestamp and identification information.

[0190] Step 522, carry the submission timestamp and apply for submission operation.

[0191] Step 523: Set the target transaction status information to "submitting." Record the target transaction's commit timestamp and identification information, perform a commit operation, and delete the target transaction status information.

[0192] Step 524: Send a submission success notification message.

[0193] Step 525: Execute the submit operation.

[0194] Step 526: Carry the start timestamp of the target transaction and submit the status information of the target transaction.

[0195] Step 527: Delete the committed transaction from the cache.

[0196] Step 528: Delete the status information of the target transaction from the cache.

[0197] Figure 6 This is an interactive diagram of the distributed transaction execution process at the RC isolation level provided in the embodiment of this application. Figure 6 As shown, the execution process includes:

[0198] Step 601: Receive an execution request for a target transaction and start executing a first SQL statement.

[0199] Step 602: Get a snapshot of the local active transaction list.

[0200] Step 603: Send a request to obtain the start timestamp of the target transaction to the timing node.

[0201] Step 604: Generate a start timestamp of the target transaction and obtain a timestamp list from the cache.

[0202] Step 605: Send the start timestamp and timestamp list of the target transaction.

[0203] Step 606: Set the state of the target transaction to being executed. Generate a global snapshot, ie, globally consistent active transaction information, based on the start timestamp of the target transaction, the timestamp list, and the snapshot of the local active transaction list.

[0204] Step 607: Send the start timestamp and timestamp list of the target transaction.

[0205] Step 608: Set the state of the target transaction to being executed. Generate a global snapshot based on the start timestamp of the target transaction, the timestamp list, and the snapshot of the local active transaction list.

[0206] Step 609: Send the first SQL statement.

[0207] Step 610: Execute the first SQL statement using the global snapshot as the snapshot of the target transaction.

[0208] Step 611: Execute the second SQL statement to obtain a snapshot of the local active transaction list.

[0209] Step 612: Send a request to obtain the start timestamp of the target transaction to the timing node.

[0210] Step 613: Generate the start timestamp of the target transaction and obtain a timestamp list from the cache.

[0211] Step 614: Send the start timestamp and timestamp list of the target transaction.

[0212] Step 615 : Generate a global snapshot based on the start timestamp of the target transaction, the timestamp list, and the snapshot of the local active transaction list.

[0213] Step 616: Send the start timestamp and timestamp list of the target transaction.

[0214] Step 617 : Generate a global snapshot based on the start timestamp of the target transaction, the timestamp list, and the snapshot of the local active transaction list.

[0215] Step 618: Send the second SQL statement.

[0216] Step 619: Execute the second SQL statement using the global snapshot as the snapshot of the target transaction.

[0217] Step 620: Send a submission preparation notification message.

[0218] Step 621: Execute the transaction preparation process and set the status information of the target transaction to complete preparation.

[0219] Step 622: Send a submission success notification message.

[0220] Step 623: Set the status information of the target transaction to be ready.

[0221] Step 624: Carry the start timestamp of the target transaction and apply for the commit timestamp.

[0222] Step 625: Record the start timestamp of the target transaction and calculate the commit timestamp.

[0223] Step 626: Return the commit timestamp of the target transaction.

[0224] Step 627: Set the target transaction status information to "submitting" and record the commit timestamp and identification information of the target transaction.

[0225] Step 628, carry the submission timestamp and apply for submission operation.

[0226] Step 629: Set the target transaction status information to "submitting." Record the target transaction's commit timestamp and identification information, execute a commit operation, and delete the target transaction status information.

[0227] Step 630: Send a submission success notification message.

[0228] Step 631, perform a submit operation.

[0229] Step 632: Carry the start timestamp of the target transaction and synchronize the commit status information.

[0230] Step 633: Delete the committed transaction from the cache.

[0231] Step 634: Delete the status information of the target transaction from the cache.

[0232] Figure 7 This is an interactive diagram of the non-distributed transaction execution process at the RR / SSI isolation level provided in the embodiment of the present application. Figure 7 As shown, the execution process includes:

[0233] Step 701: Receive an execution request for a target transaction and start executing a first SQL statement.

[0234] Step 702: Get a snapshot of the local active transaction list.

[0235] Step 703: Send a request for obtaining the start timestamp of the target transaction to the timing node.

[0236] Step 704: Generate a start timestamp of the target transaction and obtain a timestamp list from the cache.

[0237] Step 705: Send the start timestamp and timestamp list of the target transaction.

[0238] Step 706: Set the state of the target transaction to being executed. Generate a global snapshot, ie, globally consistent active transaction information, based on the start timestamp of the target transaction, the timestamp list, and the snapshot of the local active transaction list.

[0239] Step 707: Execute the second SQL statement using the global snapshot as the snapshot of the target transaction.

[0240] Step 708: Execute the target transaction commit operation and delete the target transaction status information.

[0241] Figure 8 This is an interactive diagram of the non-distributed transaction execution process at the RC isolation level provided in the embodiment of the present application. Figure 8 As shown, the execution process includes:

[0242] Step 801: Receive an execution request for a target transaction and start executing a first SQL statement.

[0243] Step 802: Get a snapshot of the local active transaction list.

[0244] Step 803: Send a request for obtaining the start timestamp of the target transaction to the timing node.

[0245] Step 804: Generate a start timestamp of the target transaction and obtain a timestamp list from the cache.

[0246] Step 805: Send the start timestamp and timestamp list of the target transaction.

[0247] Step 806: Set the state of the target transaction to being executed. Generate a global snapshot, ie, globally consistent active transaction information, based on the start timestamp of the target transaction, the timestamp list, and the snapshot of the local active transaction list.

[0248] Step 807: Execute the second SQL statement to obtain a snapshot of the local active transaction list.

[0249] Step 808: Send a request to obtain the start timestamp of the target transaction to the timing node.

[0250] Step 809: Generate the start timestamp of the target transaction and obtain a timestamp list from the cache.

[0251] Step 810: Send the start timestamp and timestamp list of the target transaction.

[0252] Step 811 : Generate a global snapshot based on the start timestamp of the target transaction, the timestamp list, and the snapshot of the local active transaction list.

[0253] Step 812: Execute the target transaction commit operation and delete the target transaction status information.

[0254] Corresponding to the method applied to CN provided in the embodiment of the present application, the embodiment of the present application also provides a transaction execution device. Figure 9 The structure block diagram of a transaction execution device according to an embodiment of the present application is shown, which may include:

[0255] Receiving module 901, configured to receive an execution request of a target transaction and obtain local active transaction information; the transactions in the local active transaction information include uncommitted transactions;

[0256] An acquisition module 902 is configured to acquire a first start timestamp and a timestamp list of a target transaction from a timing service node TSO in a database, where the timestamp list includes second start timestamps of transactions that have been prepared but not yet committed before the first start timestamp;

[0257] A modification module 903 is configured to modify the local active transaction information according to the first start timestamp and the timestamp list to obtain the globally consistent active transaction information corresponding to the target transaction;

[0258] The execution module 904 is configured to execute the target transaction according to the globally consistent active transaction information to achieve the consistency of the global transaction.

[0259] The transaction execution device provided in this embodiment integrates TSO and local active transaction information, modifies the local active transaction information according to the timestamp assigned by TSO, and achieves global transaction consistency. Compared with related technologies, through the TSO global centralized timing service, the timestamp length is fixed and does not increase with the increase in transactions, which will not affect the scalability of the distributed cluster. Moreover, by modifying the local active transaction information, the MVCC based on the active transaction table in the kernel of the stand-alone database is retained, and there is no need for MVCC development based on timestamps, which reduces the modification of the kernel and avoids the concurrency conflicts caused by the misalignment of write timestamps and read timestamps, thereby achieving high scalability, high compatibility and high stability of the database kernel.

[0260] In a possible implementation, the modification module 903 is configured to:

[0261] According to the transaction status information, the first start timestamp, and the timestamp list, the transaction is deleted and / or added to the local active transaction information to obtain the globally consistent active transaction information corresponding to the target transaction.

[0262] In one possible implementation, when the modification module 903 deletes the transaction from the local active transaction information based on the transaction status information, the first start timestamp, and the timestamp list, and obtains the globally consistent active transaction information corresponding to the target transaction, it is configured to:

[0263] In the local active transaction information, perform at least one of the following operations to obtain the globally consistent active transaction information corresponding to the target transaction: delete transactions whose status information is "Committing" and whose commit timestamp is less than the first start timestamp; the commit timestamp is obtained from the TSO; delete transactions whose status information is "Prepare Completed" and whose start timestamp is in the timestamp list.

[0264] In a possible implementation, the apparatus further includes a setting module, configured to:

[0265] Set the deleted transactions in the local active transaction information to be visible to the target transaction.

[0266] In one possible implementation, when the modification module 903 adds the transaction to the local active transaction information based on the transaction status information and the first start timestamp to obtain the globally consistent active transaction information corresponding to the target transaction, it is configured to:

[0267] Determine the committed transaction whose status information is committed and whose commit timestamp is greater than the first start timestamp. If the identification number of the committed transaction is less than the minimum identification number in the local active transaction information and the old version data of the committed transaction has been cleared, terminate the execution of the target transaction. Otherwise, add the committed transaction to the local active transaction information to obtain the globally consistent active transaction information corresponding to the target transaction.

[0268] In a possible implementation, the modification module 903 is further configured to:

[0269] Determine the number of modifications to local active transaction information based on the isolation level.

[0270] In a possible implementation, the target transaction is a distributed transaction, and the acquisition module 902 is further configured to:

[0271] After the target transaction is prepared, the commit timestamp is obtained from the TSO; a commit operation request is sent to the data node DN in the database, and the commit operation request carries the commit timestamp. After receiving the commit success notification message sent by the DN, the commit operation is executed.

[0272] In a possible implementation, the apparatus further includes a merging module, configured to:

[0273] When obtaining the start timestamps or commit timestamps of multiple target transactions from the TSO at the same time, multiple timestamp acquisition requests are merged into one request and sent to the TSO, and the same start timestamp or commit timestamp of the multiple target transactions sent by the TSO is received.

[0274] The functions of each module in each device in the embodiments of the present application can be found in the corresponding description in the above method, and have corresponding beneficial effects, which will not be repeated here.

[0275] Corresponding to the method applied to DN provided in the embodiment of the present application, the embodiment of the present application also provides a transaction execution device. Figure 10 The structure block diagram of a transaction execution device according to an embodiment of the present application is shown, which may include:

[0276] A receiving module 1001 is configured to receive a first start timestamp and a timestamp list of a target transaction sent by a CN or a TSO, where the timestamp list includes second start timestamps of transactions that have been prepared but not yet committed before the first start timestamp;

[0277] An acquisition module 1002 is configured to acquire local active transaction information; the transactions in the local active transaction information include uncompleted committed transactions;

[0278] A modification module 1003 is configured to modify the local active transaction information according to the first start timestamp and the timestamp list to obtain the globally consistent active transaction information corresponding to the target transaction;

[0279] The execution module 1004 is configured to execute the target transaction according to the globally consistent active transaction information to achieve the consistency of the global transaction.

[0280] The transaction execution device provided in this embodiment integrates TSO and local active transaction information, modifies the local active transaction information according to the timestamp assigned by TSO, and achieves global transaction consistency. Compared with related technologies, through the TSO global centralized timing service, the timestamp length is fixed and does not increase with the increase in transactions, which will not affect the scalability of the distributed cluster. Moreover, by modifying the local active transaction information, the MVCC based on the active transaction table in the kernel of the stand-alone database is retained, and there is no need for MVCC development based on timestamps, which reduces the modification of the kernel and avoids the concurrency conflicts caused by the misalignment of write timestamps and read timestamps, thereby achieving high scalability, high compatibility and high stability of the database kernel.

[0281] In a possible implementation, the modification module 1003 is configured to:

[0282] According to the transaction status information, the first start timestamp, and the timestamp list, the transaction is deleted and / or added to the local active transaction information to obtain the globally consistent active transaction information corresponding to the target transaction.

[0283] In one possible implementation, when the modification module 1003 deletes the transaction from the local active transaction information based on the transaction status information, the first start timestamp, and the timestamp list, and obtains the globally consistent active transaction information corresponding to the target transaction, it is configured to:

[0284] In the local active transaction information, perform at least one of the following operations to obtain the globally consistent active transaction information corresponding to the target transaction: delete transactions whose status information is "Committing" and whose commit timestamp is less than the first start timestamp; the commit timestamp is obtained from the TSO; delete transactions whose status information is "Prepare Completed" and whose start timestamp is in the timestamp list.

[0285] In a possible implementation, the apparatus further includes a setting module, configured to:

[0286] Set the deleted transactions in the local active transaction information to be visible to the target transaction.

[0287] In one possible implementation, when the modification module 1003 adds the transaction to the local active transaction information based on the transaction status information and the first start timestamp to obtain the globally consistent active transaction information corresponding to the target transaction, it is configured to:

[0288] Determine the committed transaction whose status information is committed and whose commit timestamp is greater than the first start timestamp. If the identification number of the committed transaction is less than the minimum identification number in the local active transaction information and the old version data of the committed transaction has been cleared, terminate the execution of the target transaction. Otherwise, add the committed transaction to the local active transaction information to obtain the globally consistent active transaction information corresponding to the target transaction.

[0289] In a possible implementation, the modification module 1003 is further configured to:

[0290] Determine the number of modifications to local active transaction information based on the isolation level.

[0291] In a possible implementation, the target transaction is a distributed transaction, and the receiving module 1001 is further configured to:

[0292] Receive a commit operation request sent by the CN, which carries the commit timestamp of the target transaction, record the commit timestamp, perform the commit operation, and send a commit success notification message to the CN to enable the CN to perform the commit operation.

[0293] The functions of each module in each device in the embodiments of the present application can be found in the corresponding description in the above method, and have corresponding beneficial effects, which will not be repeated here.

[0294] Corresponding to the method for TSO provided in the embodiment of the present application, the embodiment of the present application also provides a transaction execution device. Figure 11 The structure block diagram of a transaction execution device according to an embodiment of the present application is shown, which may include:

[0295] The receiving module 1101 is configured to receive a request for obtaining the start timestamp of a target transaction sent by a CN or a DN.

[0296] Sending module 1102 is used to send the first start timestamp and timestamp list of the target transaction to the CN or DN, so that the CN or DN modifies the local active transaction information according to the first start timestamp and timestamp list to obtain the globally consistent active transaction information corresponding to the target transaction; the timestamp list includes the second start timestamps of the transactions that have been prepared but not submitted before the first start timestamp; the globally consistent active transaction information is used by the CN or DN to execute the target transaction to achieve global transaction consistency.

[0297] The transaction execution device provided in this embodiment integrates TSO and local active transaction information, modifies the local active transaction information according to the timestamp assigned by TSO, and achieves global transaction consistency. Compared with related technologies, through the TSO global centralized timing service, the timestamp length is fixed and does not increase with the increase in transactions, which will not affect the scalability of the distributed cluster. Moreover, by modifying the local active transaction information, the MVCC based on the active transaction table in the kernel of the stand-alone database is retained, and there is no need for MVCC development based on timestamps, which reduces the modification of the kernel and avoids the concurrency conflicts caused by the misalignment of write timestamps and read timestamps, thereby achieving high scalability, high compatibility and high stability of the database kernel.

[0298] In a possible implementation, the target transaction is a distributed transaction, and the apparatus further includes a generating module configured to:

[0299] Receive the target transaction commit timestamp acquisition request sent by the CN, generate the target transaction commit timestamp and send it to the CN.

[0300] The functions of each module in each device in the embodiments of the present application can be found in the corresponding description in the above method, and have corresponding beneficial effects, which will not be repeated here.

[0301] The embodiment of the present application further provides a distributed database system, which includes the coordination node CN, data node DN and timing node TSO in any of the above embodiments.

[0302] The functions of each node in the system provided in the embodiment of the present application can be referred to the corresponding description in the above method, and have corresponding beneficial effects, which will not be repeated here.

[0303] Figure 12 FIG. 1 is a block diagram of an electronic device for implementing an embodiment of the present application. Figure 12 As shown, the electronic device includes: a memory 1210 and a processor 1220. The memory 1210 stores a computer program that can be run on the processor 1220. When the processor 1220 executes the computer program, the method in the above embodiment is implemented. The number of the memory 1210 and the processor 1220 can be one or more.

[0304] The electronic device also includes:

[0305] The communication interface 1230 is used to communicate with external devices and perform data exchange transmission.

[0306] If the memory 1210, the processor 1220, and the communication interface 1230 are implemented independently, the memory 1210, the processor 1220, and the communication interface 1230 can be connected to each other via a bus and communicate with each other. The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus. The bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 12 Only one thick line is used in the diagram, but this does not mean that there is only one bus or one type of bus.

[0307] Optionally, in a specific implementation, if the memory 1210, the processor 1220 and the communication interface 1230 are integrated on a chip, the memory 1210, the processor 1220 and the communication interface 1230 can communicate with each other through an internal interface.

[0308] An embodiment of the present application provides a computer-readable storage medium storing a computer program, which implements the method provided in the embodiment of the present application when the program is executed by a processor.

[0309] An embodiment of the present application also provides a chip, which includes a processor for calling and executing instructions stored in the memory from the memory, so that a communication device equipped with the chip executes the method provided in the embodiment of the present application.

[0310] An embodiment of the present application also provides a chip, including: an input interface, an output interface, a processor and a memory. The input interface, the output interface, the processor and the memory are connected through an internal connection path. The processor is used to execute the code in the memory. When the code is executed, the processor is used to execute the method provided in the embodiment of the application.

[0311] It should be understood that the processor may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor, etc. It is worth noting that the processor may be a processor that supports the Advanced RISC Machines (ARM) architecture.

[0312] Furthermore, optionally, the above-mentioned memory may include a read-only memory and a random access memory. The memory may be a volatile memory or a non-volatile memory, or may include both volatile and non-volatile memories. Among them, the non-volatile memory may include a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), or a flash memory. The volatile memory may include a random access memory (RAM), which is used as an external cache. By way of example but not limitation, many forms of RAM are available. For example, static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link DRAM (SLDRAM) and direct memory bus random access memory (DR RAM).

[0313] In the above embodiments, all or part of the embodiments may be implemented using software, hardware, firmware, or any combination thereof. When implemented using software, all or part of the embodiments may be implemented in the form of a computer program product. A computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the processes or functions according to the present application are generated in whole or in part. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transferred from one computer-readable storage medium to another.

[0314] In the description of this specification, the reference terms "one embodiment," "some embodiments," "example," "specific example," or "some examples" mean that the specific features, structures, materials, or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of the present application. Moreover, the specific features, structures, materials, or characteristics described may be combined in any appropriate manner in any one or more embodiments or examples. In addition, those skilled in the art may combine and combine different embodiments or examples described in this specification, as well as features of different embodiments or examples, unless they are mutually inconsistent.

[0315] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features being referred to. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one such feature. Throughout the description of this application, "plurality" means two or more, unless otherwise specifically defined.

[0316] Any process or method described in the flowchart or otherwise described herein can be understood to represent a module, segment or portion of code comprising one or more executable instructions for implementing the steps of a specific logical function or process. The scope of the preferred embodiments of the present application includes other implementations in which the functions may be performed in a different order than shown or discussed, including performing the functions substantially simultaneously or in reverse order depending on the functions involved.

[0317] The logic and / or steps described in the flowchart or otherwise described herein, for example, can be considered as an ordered list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by an instruction execution system, apparatus or device (such as a computer-based system, a system including a processor or other system that can fetch instructions from an instruction execution system, apparatus or device and execute instructions), or used in combination with such instruction execution systems, apparatuses or devices.

[0318] It should be understood that various parts of the present application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented using software or firmware stored in a memory and executed by a suitable instruction execution system. All or part of the steps of the above embodiment method can be completed by instructing the relevant hardware through a program, which can be stored in a computer-readable storage medium. When the program is executed, it includes one or a combination of the steps of the method embodiment.

[0319] In addition, the functional units in the various embodiments of the present application may be integrated into a single processing module, or each unit may exist physically separately, or two or more units may be integrated into a single module. The aforementioned integrated modules may be implemented in the form of hardware or in the form of software functional modules. If the aforementioned integrated modules are implemented in the form of software functional modules and sold or used as independent products, they may also be stored in a computer-readable storage medium. The storage medium may be a read-only memory, a magnetic disk, or an optical disk, etc.

[0320] The above is merely an exemplary embodiment of the present application, but the scope of protection of the present application is not limited thereto. Any person skilled in the art can easily conceive of various modifications or substitutions within the technical scope described in this application, and such modifications or substitutions should be included in the scope of protection of the present application. Therefore, the scope of protection of the present application should be based on the scope of protection of the claims.

Claims

1. A transaction execution method, characterized in that: The method is applied to a coordination node CN in a database, and includes: Receive an execution request for a target transaction and obtain local active transaction information; the transactions in the local active transaction information include uncommitted transactions; Obtaining a first start timestamp and a timestamp list of the target transaction from a timing service node TSO in the database, the timestamp list including second start timestamps of transactions that have been prepared but not submitted before the first start timestamp; Deleting and / or adding transactions from the local active transaction information according to the transaction status information, the first start timestamp, and the timestamp list to obtain globally consistent active transaction information corresponding to the target transaction, including: determining a committed transaction whose status information indicates that the commit is complete and whose commit timestamp is greater than the first start timestamp; if the identification number of the committed transaction is less than the minimum identification number in the local active transaction information and the old version data of the committed transaction has been cleared, terminating execution of the target transaction; otherwise, adding the committed transaction to the local active transaction information to obtain the globally consistent active transaction information; The target transaction is executed according to the globally consistent active transaction information to achieve consistency of the global transaction.

2. The method according to claim 1, characterized in that The deleting the transaction from the local active transaction information according to the transaction status information, the first start timestamp, and the timestamp list to obtain the globally consistent active transaction information corresponding to the target transaction includes: In the local active transaction information, perform at least one of the following operations to obtain the globally consistent active transaction information corresponding to the target transaction: Deleting transactions whose status information is "submitting" and whose commit timestamp is less than the first start timestamp; the commit timestamp is obtained from the TSO; The transaction whose status information is "preparation completed" and whose start timestamp is in the timestamp list is deleted.

3. The method according to claim 1 or 2, characterized in that The method further comprises: The deleted transaction in the local active transaction information is set to be visible to the target transaction.

4. The method according to claim 1 or 2, characterized in that The method further comprises: The number of times the local active transaction information is modified is determined according to the isolation level.

5. The method according to claim 1 or 2, characterized in that The target transaction is a distributed transaction, and the method further includes: After the target transaction completes preparation, obtaining a commit timestamp from the TSO; A commit operation request is sent to the data node DN in the database, wherein the commit operation request carries the commit timestamp, and a commit operation is performed after receiving a commit success notification message sent by the DN.

6. The method according to claim 5, characterized in that The method further comprises: When obtaining the start timestamps or commit timestamps of multiple target transactions from the TSO at the same time, multiple timestamp acquisition requests are merged into one request and sent to the TSO, and the same start timestamp or commit timestamp of the multiple target transactions sent by the TSO is received.

7. A transaction execution method, characterized in that: The method is applied to a data node DN in a database, and the method includes: Receive a first start timestamp and a timestamp list of a target transaction sent by a coordinating node CN or a timing node TSO, where the timestamp list includes second start timestamps of transactions that have been prepared but not submitted before the first start timestamp; Obtaining local active transaction information; wherein the transactions in the local active transaction information include uncompleted committed transactions; Deleting and / or adding transactions from the local active transaction information according to the transaction status information, the first start timestamp, and the timestamp list to obtain globally consistent active transaction information corresponding to the target transaction, including: determining a committed transaction whose status information indicates that the commit is complete and whose commit timestamp is greater than the first start timestamp; if the identification number of the committed transaction is less than the minimum identification number in the local active transaction information and the old version data of the committed transaction has been cleared, terminating execution of the target transaction; otherwise, adding the committed transaction to the local active transaction information to obtain the globally consistent active transaction information; The target transaction is executed according to the globally consistent active transaction information to achieve consistency of the global transaction.

8. The method according to claim 6 or 7, characterized in that The target transaction is a distributed transaction, and the method further includes: Receive a commit operation request sent by the CN, the commit operation request carrying the commit timestamp of the target transaction, record the commit timestamp, perform a commit operation, and send a commit success notification message to the CN, so that the CN performs the commit operation.

9. A transaction execution method, characterized in that: The method is applied to a timing node TSO in a database, and the method comprises: Receive a request for obtaining the start timestamp of a target transaction sent by the coordinating node CN or the data node DN; The first start timestamp and timestamp list of the target transaction are sent to the CN or the DN, so that the CN or the DN deletes and / or adds transactions in the local active transaction information according to the status information of the transaction, the first start timestamp and the timestamp list, and obtains the globally consistent active transaction information corresponding to the target transaction, including: determining a committed transaction whose status information is committed and whose commit timestamp is greater than the first start timestamp; if the identification number of the committed transaction is less than the minimum identification number in the local active transaction information and the old version data of the committed transaction has been cleared, terminating the execution of the target transaction; otherwise, adding the committed transaction to the local active transaction information to obtain the globally consistent active transaction information; the timestamp list includes the second start timestamps of transactions that have completed preparation but not completed submission before the first start timestamp; the globally consistent active transaction information is used by the CN or the DN to execute the target transaction to achieve global transaction consistency.

10. A transaction execution method, characterized in that: The method comprises: The timing node TSO receives a request for obtaining the start timestamp of the target transaction sent by the coordinating node CN or the data node DN; The TSO sends the first start timestamp and a timestamp list of the target transaction to the CN or the DN; the timestamp list includes the second start timestamps of transactions that have been prepared but not submitted before the first start timestamp; The CN or the DN deletes and / or adds transactions in the local active transaction information according to the transaction status information, the first start timestamp, and the timestamp list to obtain the globally consistent active transaction information corresponding to the target transaction, including: determining a committed transaction whose status information indicates that the transaction is committed and whose commit timestamp is greater than the first start timestamp; if the identification number of the committed transaction is less than the minimum identification number in the local active transaction information and the old version data of the committed transaction has been cleared, terminating execution of the target transaction; otherwise, adding the committed transaction to the local active transaction information to obtain the globally consistent active transaction information; The CN or the DN executes the target transaction according to the global consistency active transaction information to achieve global transaction consistency.

11. A distributed database system, characterized in that: The system comprises the coordination node CN according to any one of claims 1 to 6, the data node DN according to claim 7 or 8, and the timing node TSO according to claim 9.

12. An electronic device comprising a memory, a processor, and a computer program stored in the memory, wherein the processor implements the method according to any one of claims 1 to 10 when executing the computer program.

13. A computer-readable storage medium, wherein a computer program is stored in the computer-readable storage medium, and when the computer program is executed by a processor, the method according to any one of claims 1 to 10 is implemented.

Images