Transaction processing method and cloud native database system

Abstract

The embodiment of the invention discloses a transaction processing method and a cloud native database system, and belongs to the technical field of databases. The method comprises the steps that a first database computing node responds to a transaction request of a user and starts to process a target transaction; the first database computing node stores the state information of the target transaction to the database state node in the process of processing the target transaction; in the process that the first database computing node processes the target transaction, the first database computing node suspends processing of the target transaction; and the second database computing node obtains the state information of the target transaction from the database state node, and continues to process the target transaction based on the state information of the target transaction. According to the method and the device, after the database computing nodes are switched, breakpoint continuation can be performed on the transaction, so that the time resource overhead caused by the switching of the database computing nodes is reduced, and the switching of the database computing nodes is not perceived by a user.

Description

[0001] This application claims priority to Chinese patent application No. 202310693898.4 filed on June 12, 2023, with invention name “A database system and transaction processing method”, the entire contents of which are incorporated by reference into this application. Technical Field

[0002] The present application relates to the field of database technology, and in particular to a transaction processing method and a cloud-native database system. Background Art

[0003] When applying a cloud-native database system, in many cases, a transaction may be switched from one database computing node to another for execution. For example, when expanding capacity, a new database computing node will be directly added, and then some transactions that are not currently processed in some congested database computing nodes may be switched to the new computing node for execution. At the same time, if there is a downtime or network failure, the problematic database computing node in the cloud-native database system will be offline, and the currently unprocessed transactions in the offline database computing node will also be switched to other database computing nodes for execution. It can be seen that when applying a cloud-native database system, the database computing node may be switched in a planned scenario or an unplanned scenario. How to make the switching of database computing nodes not perceived by users and how to make the time and resource overhead caused by the switching of database computing nodes not affect the user experience are major challenges currently faced. Summary of the invention

[0004] The present application provides a transaction processing method and a cloud native database system, which can ensure that the time resource overhead caused by the switching of database computing nodes does not affect the user's experience, and the switching of database computing nodes is not perceived by the user. The technical solution is as follows:

[0005] In a first aspect, a transaction processing method is provided, which is applied to a cloud native database system, wherein the cloud native database system includes a first database computing node, a second database computing node, a database status node and a database storage node; the first database computing node and the second database computing node are used to process transactions requested by users, the database status node is used to store transaction status information, and the database storage node is used to store database data; the method includes: the first database computing node responds to the user's transaction request and starts processing a target transaction, the target transaction is used to perform a read operation and / or a write operation on data in the database storage node; the first database computing node stores the status information of the target transaction to the database status node during the process of processing the target transaction; during the process of the first database computing node processing the target transaction, the first database computing node suspends processing the target transaction; the second database computing node obtains the status information of the target transaction from the database status node, and continues to process the target transaction based on the status information of the target transaction.

[0006] The state information of the target transaction may include the lock table state of the write operation being executed, the log of the target transaction, the query plan tree and intermediate results of the read operation statements in the target transaction, etc.

[0007] Among them, the lock table state of the write operation means that the data table being used by the write operation is in a locked state, and other transactions cannot operate on the data table being used by the write operation; the log of the target transaction records the operation status of the write operation in the target transaction; the query plan tree of a read operation statement is used to guide the execution steps of the statement, and the intermediate result refers to the results obtained by some execution steps of the query plan tree of the statement (excluding the final execution result).

[0008] By storing the state information of the target transaction in the database state node and the second database computing node obtaining the state information of the target transaction from the database state node, the second database computing node can continue to process the target transaction in the state before the target transaction was suspended, thereby realizing breakpoint continuation at the transaction granularity. In this way, compared with rollback or redo, the time and resource overhead caused by the switching of database computing nodes can be reduced, and the user experience can be improved.

[0009] Optionally, the target transaction includes at least one structured query language (SQL) statement, and the state information of the target transaction is used to record the execution state of the SQL statement being executed before the target transaction is suspended; the second database computing node continues to process the target transaction based on the state information of the target transaction, including: the second database computing node continues to execute the SQL statement being executed in the target transaction based on the execution state of the SQL statement being executed before the target transaction is suspended.

[0010] The execution status of an SQL statement in the target transaction, that is, the status information related to the SQL statement in the status information of the target transaction. If an SQL statement is a write operation statement, the execution status of the SQL statement may include the operation status of the write operation corresponding to the SQL statement (recorded in the log of the target transaction), the lock table status of the write operation corresponding to the SQL statement, etc. If an SQL statement is a read operation statement, the execution status of the SQL statement may include the query plan tree and intermediate results corresponding to the SQL statement, etc.

[0011] By storing the execution status of the SQL statement being executed before the suspension in the target transaction in the database status node, and the second database computing node continuing to execute the SQL statement based on the execution status of the SQL statement, breakpoint resumption at the statement granularity is actually achieved.

[0012] Optionally, the first database computing node stores the status information of the target transaction to a database status node during processing of the target transaction, including: the first database computing node stores the log of the target transaction to the database status node; the second database computing node continues to process the target transaction based on the status information of the target transaction, including: the second database computing node continues to execute the write operation being executed before the pause in the target transaction based on the log of the target transaction in the database status node.

[0013] It should be noted that, during the process of the first database computing node executing the target transaction, the operation status of each write operation will be recorded in the log of the target transaction and stored in the database status node. In this way, the second database computing node can obtain the location of the write operation being executed before the suspension in the target transaction, the operation status of the write operation, etc., based on the log of the target transaction, so as to continue to execute the write operation being executed before the suspension in the target transaction.

[0014] Therefore, even if the first database computing node suddenly fails during the execution of a write operation, the operation status of the write operation has been recorded in the log of the target transaction and stored in the database status node. Therefore, for the case where the write operation is being executed before the target transaction is suspended, whether it is a node switch in an unplanned scenario or a node switch in an unplanned scenario, the embodiments of the present application can achieve breakpoint resumption at the transaction granularity or even the statement granularity.

[0015] Optionally, the first database computing node stores status information of the target transaction to a database status node during processing of the target transaction, further comprising: the first database computing node stores a lock table status of a write operation being executed before the target transaction is paused to the status node; the second database computing node continues to process the target transaction based on the status information of the target transaction, comprising: the second database computing node continues to execute the write operation being executed before the target transaction is paused based on the log of the target transaction in the database status node and the lock table status of the write operation being executed before the target transaction is paused.

[0016] It should be noted that the lock table state corresponding to a write operation is actually generated before the write operation is executed, and the first database computing node actually stores the lock table state corresponding to a write operation immediately after it is generated to the database state node. Therefore, even if the first database computing node suddenly fails during the execution of a write operation, the lock table state of the write operation has been stored in the database state node.

[0017] Optionally, the first database computing node stores status information of the target transaction to a database status node during processing of the target transaction, including: the first database computing node stores a query execution plan tree and intermediate results of the SQL statement corresponding to the read operation being executed before the pause in the target transaction to the database status node; the second database computing node continues to process the target transaction based on the status information of the target transaction, including: the second database computing node continues to execute the read operation being executed before the pause in the target transaction based on the query execution plan tree and intermediate results of the SQL statement corresponding to the read operation being executed before the pause in the target transaction in the database status node.

[0018] It should be noted that the above-mentioned stored intermediate results are the latest intermediate results before the target transaction is suspended.

[0019] Because the first database computing node is required to save the SQL statement and the latest intermediate result corresponding to the read operation being executed before the target transaction is suspended to the database status node before switching, the first database needs to be able to know the switching plan. It can be seen that the above method is applicable to the switching of database computing nodes in the planned scenario. That is, for the case where the read operation is being executed before the target transaction is suspended, after switching the database computing node in the planned scenario, the method can also be used to resume the work at the transaction granularity or even the statement granularity.

[0020] Optionally, the first database computing node stores status information of the target transaction to a database status node during processing of the target transaction, including: the first database computing node stores a SQL statement corresponding to a read operation currently being executed in the target transaction to the database status node during processing of the target transaction; the second database computing node continues to process the target transaction based on the status information of the target transaction, including: the second database computing node re-executes the SQL statement corresponding to the read operation being executed in the target transaction before being paused.

[0021] Since the first database computing node does not know when the database computing node will be switched in an unplanned scenario, it is impossible to know when the latest intermediate results should be stored. If the read operation is to be resumed as in the planned scenario, the intermediate results need to be saved regularly, but this will bring about a large resource overhead. Therefore, in this application, the first database computing node can store a SQL statement being executed at each moment in the process of processing the target transaction to the database status node. After the database computing node is switched in an unplanned scenario, the second database computing node can obtain the SQL statement being executed before the target transaction is suspended, so as to redo the statement.

[0022] Optionally, the first database computing node stores status information of the target transaction to a database status node during processing of the target transaction, further comprising: the first database computing node stores execution results of SQL statements corresponding to read operations that have been executed in the target transaction to the database status node during processing of the target transaction; the second database computing node continues to process the target transaction based on the status information of the target transaction, further comprising: the second database computing node continues to process the target transaction based on the execution results of SQL statements corresponding to read operations that have been executed in the target transaction in the database status node after re-executing the SQL statements corresponding to the read operations currently being executed in the target transaction.

[0023] In this way, if the execution result of the SQL statement corresponding to the previous read operation is needed in the subsequent processing of the target transaction, it can be used directly, which helps to achieve breakpoint resumption at the transaction granularity.

[0024] Optionally, the database status node uses persistent memory to store transaction status information.

[0025] The database status node uses persistent memory to store the status information of the transaction. After the log of the transaction is written from the first database computing node to the database status node, the transaction can be committed without waiting for the log of the transaction to be flushed to the database storage node. In this way, the increase in the response time of the target transaction to the client can be avoided, and the performance degradation of the cloud native database system can be avoided because the log of the target transaction needs to go through two layers of network links to complete the submission.

[0026] Optionally, the method also includes: the first database computing node pushes down the target operator of the SQL statement being executed in the target transaction before being suspended to the database storage node for execution, the target operator being a partial operator included in the query execution plan tree of the SQL statement being executed; the database storage node stores the execution result of the target operator; when the first database computing node suspends processing of the target transaction, the second database computing node obtains the status information of the target transaction from the database status node, and continues to process the target transaction based on the status information of the target transaction, including: when the first database computing node suspends processing of the target transaction, the second database computing node obtains the status information of the target transaction from the database status node, and obtains the execution result of the target operator from the database storage node; the second database computing node continues to execute the SQL statement being executed in the target transaction before being suspended based on the status information of the target transaction and the execution result of the target operator.

[0027] By pushing down some operators to let the database storage node execute and save the execution results, the amount of data transmitted between the database storage node and the first database computing node can be reduced, and the speed at which the entire cloud native database system processes the target transaction can also be accelerated.

[0028] Optionally, the state information of the target transaction also includes the session state of the target transaction. That is, the first database computing node may store the session state of the target transaction to the database state node during processing of the target transaction.

[0029] In this way, taking the implementation environment including a scheduling node as an example, when the target transaction needs to be switched to other database computing nodes for execution, the scheduling node can obtain the session status of the target transaction from the database status node, and the scheduling node can know the client identifier of the transaction request that initiated the target transaction, the identifier of the target transaction and other information. Therefore, the scheduling node can switch the target transaction from the first database computing node to other database computing nodes without switching the wrong transaction or switching to an inappropriate computing node. The client does not need to resend the transaction request to successfully establish a connection with the database computing node to which the target transaction is switched, so that the user is unaware of the node switching.

[0030] Optionally, the method includes: the first database computing node stores the status information of the target transaction to the database status node based on remote direct memory access (RDMA) or compute express link (CXL) technology; and / or, the second database computing node obtains the status information of the target transaction from the database status node based on RDMA or CXL technology.

[0031] RDMA technology allows user programs to bypass the operating system kernel and directly interact with the network card for network communication. CXL technology also has the characteristics of high bandwidth and low latency, and is often used in high-performance computing, cloud computing and other fields. Transmitting state information through RDMA technology or CXL technology can increase the network bandwidth and reduce the latency in the process of transmitting state information, thereby improving the performance of the cloud-native database system.

[0032] Optionally, the first database computing node suspends processing of the target transaction when cross-node expansion or cross-node reduction is required or a failure occurs.

[0033] Among them, the switching of database computing nodes caused by cross-node expansion and contraction is the switching of database computing nodes in a planned scenario, and the switching of database computing nodes caused by a failure is the switching of database computing nodes in an unplanned scenario.

[0034] In a second aspect, a cloud native database system is provided, the cloud native database system comprising a first database computing node, a second database computing node, a database status node, and a database storage node; the first database computing node and the second database computing node are used to process transactions requested by users, the database status node is used to store transaction status information, and the database storage node is used to store database data. The cloud native database system has the function of implementing the transaction processing method behavior in the first aspect.

[0035] In a third aspect, a computer device cluster is provided, the computer device cluster comprising at least one computing device, each computing device comprising a processor and a memory, the processor of the at least one computing device being used to execute instructions stored in the memory of the at least one computing device, so that the computing device cluster executes the transaction processing method provided in the first aspect above.

[0036] In a fourth aspect, a computer-readable storage medium is provided, wherein the storage medium includes computer program instructions. When the computer program instructions are executed by a computer device cluster, the computer device cluster executes the transaction processing method described in the first aspect.

[0037] In a fifth aspect, a computer program product comprising instructions is provided, and when the instructions are executed by a computing device cluster, the computing device cluster executes the steps of the transaction processing method described in the first aspect. In other words, a computer program is provided, and when the computer program is executed on a computing device cluster, the computer executes the transaction processing method described in the first aspect.

[0038] The technical effects obtained by the above-mentioned second, third, fourth and fifth aspects are similar to the technical effects obtained by the corresponding technical means in the first aspect, and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0039] Figure 1 It is a structural diagram of a traditional database system provided in an embodiment of the present application;

[0040] Figure 2 It is a structural diagram of a database system with storage and computing separation provided in an embodiment of the present application;

[0041] Figure 3 It is a schematic diagram of an implementation environment provided by an embodiment of the present application;

[0042] Figure 4 It is a structural diagram of a cloud native database system provided in an embodiment of the present application;

[0043] Figure 5 is a flow chart of a transaction processing method provided by an embodiment of the present application;

[0044] Figure 6 It is a schematic diagram of a database computing node switching process provided by an embodiment of the present application;

[0045] Figure 7 is a schematic diagram of another database computing node switching process provided by an embodiment of the present application;

[0046] Figure 8It is a schematic diagram of a process of executing multiple operators when processing a target transaction provided by an embodiment of the present application;

[0047] Fig. 9 is a schematic diagram of another database computing node switching process provided by an embodiment of the present application;

[0048] Fig.10 is a schematic diagram of another database computing node switching process provided by an embodiment of the present application;

[0049] Fig.11 is a structural schematic diagram of a computer device provided in an embodiment of the present application;

[0050] Fig.12 It is a structural diagram of a computer device cluster provided in an embodiment of the present application;

[0051] Fig.13 It is a schematic diagram of a connection method between two computer devices provided in an embodiment of the present application. DETAILED DESCRIPTION

[0052] In order to make the objectives, technical solutions and advantages of the embodiments of the present application clearer, the implementation methods of the present application will be further described in detail below in conjunction with the accompanying drawings.

[0053] First, the application scenarios and implementation environments involved in the embodiments of the present application are introduced.

[0054] Traditional database system architecture usually adopts a tightly coupled design approach, where computing and storage are not separated. Figure 1 As shown in the figure, each database computing node has its own corresponding database storage node, and these database storage nodes are not shared. This leads to a very long expansion process for traditional database systems, and a very difficult reduction process after the peak of business, which often results in a huge waste of resources. This is one of the biggest drawbacks of the traditional database system architecture. Unlike the traditional database architecture, the database system architecture with storage and computing separation separates computing and storage. The storage layer uses distributed shared storage, and each database computing node in the computing layer shares the storage content of the storage layer. Therefore, it is easier to expand and shrink the database system architecture with storage and computing separation than the traditional database architecture.

[0055] Current cloud-native database systems often use a database system architecture that separates storage and computing, such as Figure 2 As shown, under this architecture, the cloud native database system includes a computing layer and a storage layer. The computing layer may include multiple database computing nodes, and the storage layer may include multiple database storage nodes (not shown in the figure). All database computing nodes of the computing layer share the storage content of the storage layer. When necessary, the computing layer and the storage layer can be quickly expanded or reduced in capacity.

[0056] In this cloud-native database system, database storage nodes are used to store databases, and database computing nodes are used to analyze and execute SQL statements included in transactions. The local storage space of database computing nodes can temporarily store the query execution plan tree of SQL statements, intermediate results of SQL statements, execution results of SQL statements, and so on.

[0057] The cloud native database system can expand or shrink the computing layer by directly adding or deleting database computing nodes. Assuming that the computing layer is to be shrunk, if the database computing node to be deleted has an ongoing transaction, the ongoing transaction will be suspended and switched to other database computing nodes to continue execution. When expanding the computing layer, it is also possible that a transaction is suspended and then switched to other database computing nodes for continued execution. In addition, when this cloud native database system suddenly encounters a downtime, network disconnection, etc., it will directly offline the database computing node with the problem, and switch the transaction currently being processed by the database computing node to other database computing nodes for execution. In other words, when the database computing node is expanded or shrunk or encounters a downtime, network disconnection, etc., it may be possible that the transaction is switched from one database computing node to another database computing node for processing. In this application, for the convenience of description, the switching caused by cross-node expansion or cross-node shrinkage of the database computing node will be referred to as switching in the planned scenario; the switching caused by unexpected downtime or failure of the database computing node or network disconnection will be referred to as switching in the unplanned scenario.

[0058] In the current cloud-native database system, the database computing node switched to after the transaction is suspended needs to roll back or redo the write operation. For read operations, some cloud-native database systems will redo, and some cloud-native database systems can resume after the database computing node is switched in the planned scenario, but can only redo after the database computing node is switched in the unplanned scenario. However, with the increase in user business volume and business complexity, the proportion of long transactions in the transactions that cloud-native database systems need to process is increasing. For these long transactions, the time to roll back or redo may be very long, which will cause the client to be unable to obtain the latest SQL statement execution results for a long time. Therefore, how to reduce the additional overhead caused by transaction rollback or redo, so that the node switch is not perceived by the user, and the time and resource overhead caused by the node switch does not affect the user's experience is a major challenge currently faced.

[0059] Based on this, an embodiment of the present application provides a cloud native database system, which separates the state information generated by the database computing node in the process of processing a transaction on the basis of the existing cloud native database system separating computing and storage, that is, the architecture of the cloud native database system is a storage, computing, and state separation architecture, and the cloud native database system includes a database state node in addition to the database computing node and the database storage node. In the cloud native database system, after the first database computing node generates state information in the process of executing a transaction, it will send the state information to the database state node, and the database state node will store the state information. In this way, when the first database computing node suspends the execution of the transaction and the transaction is switched to the second database computing node for execution, the second database computing node can obtain the state information of the transaction from the database state node, such as the query execution plan tree and intermediate results of the SQL statement being executed before the transaction is suspended, and the log of the transaction (recording the operation of the SQL statement being executed before the transaction is suspended) and so on. In this way, for read operations, after completing the database computing node switch in the planned scenario, the second database computing node can continue to execute the SQL statement currently being executed by the transaction, that is, to resume the transaction or even the SQL statement being executed before the pause. For write operations, there is no need to roll back or redo after completing the database computing node switch in various scenarios, but to resume the transaction or even the SQL statement being executed before the pause. In this way, the extra time overhead caused by node switching can be saved to a large extent, improving the user experience.

[0060] Please refer to Figure 3 , Figure 3 It is a schematic diagram of an implementation environment according to an embodiment of the present application, which includes at least one client 301, a scheduling node 302, and a cloud native database system 303. The client 301 can establish a communication connection with the cloud native database system 303 through the scheduling node 302. The communication connection can be a wired or wireless connection, which is not limited in the embodiment of the present application.

[0061] The client 301 is used to send the SQL statement included in the target transaction to the cloud native database system 303 through the scheduling node 302.

[0062] The scheduling node 302 is used to receive a transaction processing request sent by the client 301 and establish a communication connection between the client 301 and the cloud native database system 303 .

[0063] The cloud native database system 303 is used to process the target transaction, execute the SQL statements included in the target transaction, and return the intermediate results obtained in the process of processing the target transaction, the final results obtained in processing the target transaction, etc. to the client 303 through the scheduling node 302.

[0064] like Figure 4 As shown, the cloud native database system 303 may include a first database computing node 3031, a second database computing node 3032, a database status node 3033, and a database storage node 3034. The first database computing node 3031 and the second database computing node 3032 are used to process transactions requested by users, the database status node 3033 is used to store transaction status information, and the database storage node 3034 is used to store database data.

[0065] For example, Figure 4 As shown, the first database computing node 3031 , the second database computing node 3032 and the database storage node 3034 may be directly connected through a bypass in addition to being indirectly connected through the intermediate database status node 3032 .

[0066] The client 301 may be any electronic product that can interact with a user through one or more methods such as a keyboard, a touchpad, a touch screen, a remote control, voice interaction or a handwriting device, such as a personal computer (PC), a mobile phone, a smart phone, a personal digital assistant (PDA), a wearable device, a pocket PC (PPC), a tablet computer, a smart car machine, a smart TV, a smart speaker, etc.

[0067] The above-mentioned scheduling node 302, database status node 3033, and database storage node 3034 can all be a server, a virtual machine, a container, etc.

[0068] The first database computing node 3031 and the second database computing node 3032 are servers, virtual machines, containers, etc. capable of deploying database instances.

[0069] In actual applications, the database status node 3032 can be deployed in the same computing device cluster (the computing device cluster is, for example, a server cluster, a virtual machine cluster, or a container cluster) in combination with the first database computing node 3031, or the second database computing node 3032, or the database storage node 3034, or can be independently deployed in a separate computing device cluster. Those skilled in the art should understand that the above-mentioned client, scheduling node, database status node, database storage node, first database computing node, and second database computing node are only examples, and any other existing or future forms that may appear, if applicable to the embodiments of the present application, should also be included in the protection scope of the embodiments of the present application, and are included here by reference.

[0070] It should be noted that the application scenarios and implementation environments described in the embodiments of the present application are intended to more clearly illustrate the technical solutions of the embodiments of the present application, and do not constitute a limitation on the technical solutions provided by the embodiments of the present application. It is known to those skilled in the art that with the emergence of new application scenarios and the evolution of implementation environments, the technical solutions provided by the embodiments of the present application are also applicable to similar technical problems. For example, the above implementation environment may not include a scheduling node.

[0071] Figure 5 This is a flowchart of a transaction processing method provided by an embodiment of the present application. The method is applied to a cloud native database system. The cloud native database system may be the cloud native database system introduced above, that is, the cloud native database system includes a first database computing node, a second database computing node, a database status node and a database storage node; the first database computing node and the second database computing node are used to process transactions requested by users, the database status node is used to store transaction status information, and the database storage node is used to store database data. Please refer to Figure 5 , the method comprises the following steps.

[0072] Step 501: A first database computing node responds to a transaction request from a user and starts processing a target transaction, where the target transaction is used to perform a read operation and / or a write operation on data in a database storage node.

[0073] A database storage node can store multiple databases, and a database can include one or more data tables. A target transaction usually performs read and / or write operations on data in one or more data tables.

[0074] In some embodiments, when a user initiates a transaction request for a target transaction on a client, the scheduling node receives the transaction request and sends the transaction request to the first database computing node, which responds to the transaction request and starts processing the target transaction. Optionally, in the case where the above implementation environment does not include a scheduling node, the client can also send the transaction request to the first database computing node in other ways. Next, the above implementation environment including the scheduling node is used as an example for introduction.

[0075] The database computing nodes in a cloud native database system are usually of two types: read-only nodes and read-write nodes. In the embodiment of the present application, when the operation type corresponding to the target transaction is a read-only operation, the first database computing node can be a read-only node or a read-write node. When the operation type corresponding to the target transaction includes a write operation, the first database computing node is a read-write node.

[0076] The target transaction includes at least one SQL statement. The process of the first database computing node processing the target transaction is the process of the first database computing node executing the SQL statement included in the target transaction. The SQL statement included in the target transaction will be sent by the client to the scheduling node, and then sent by the scheduling node to the first database computing node.

[0077] In addition, the target transaction may be a deterministic load or an uncertain load, which is not limited in the embodiments of the present application.

[0078] When the target transaction is a deterministic load, the SQL statements included in the target transaction are determined. At this time, the first database computing node can receive all the SQL statements included in the target transaction at one time; when the target transaction is an uncertain load, the SQL statements included in the target transaction are uncertain. For example, the user can input the statements instantly through the interactive interface of the client. At this time, the first database computing node can receive the SQL statements one by one. Obviously, whether receiving multiple SQL statements at one time or receiving SQL statements one by one, the first database computing node executes the SQL statements one by one in the order of the SQL statements included in the target transaction.

[0079] In addition, a data page is a basic unit of database storage. When the first database computing node executes an SQL statement, the entire data page where the data to be operated by the SQL statement is located is read from the database storage node, and the read data page is placed in the buffer pool of the local memory of the first database computing node. When executing the target transaction, the first database computing node actually performs a read operation and / or a write operation on the corresponding data page in the buffer pool. In this way, the number of visits of the first database computing node to the database storage node can be reduced, and the efficiency of data processing can be improved.

[0080] Step 502: The first database computing node stores the state information of the target transaction to the database state node during the process of processing the target transaction.

[0081] As can be seen from the above description, the process of the first database computing node processing the target transaction is the process of sequentially executing the SQL statements included in the target transaction. The SQL statements included in the target transaction may include write operation statements (such as addition, deletion, and modification) and / or read operation statements (such as query). When the SQL statement executed by the first database computing node is a read operation statement, the first database computing node performs a read operation, which can also be said to be the target transaction performing a read operation; when the SQL statement executed by the first database computing node is a write operation statement, the first database computing node performs a write operation, which can also be said to be the target transaction performing a write operation.

[0082] In some embodiments, the state information of the target transaction includes the lock table state of the write operation being executed, the log of the target transaction, the query plan tree and intermediate results of the read operation statement in the target transaction, etc.

[0083] When the target transaction performs a write operation, it will lock the data table that the write operation is using, and record the lock table status on the data table in the local buffer pool, so that other transactions except the target transaction cannot operate on the data table that the write operation is using. At the same time, when performing a write operation, the first database computing node will also record the write operation status on the data in the log of the target transaction.

[0084] When the first database computing node is preparing to execute the read operation statement, it will generate a query plan tree for the read operation statement, and then the first database computing node will execute the read operation statement according to the query plan tree. In the process of the first database computing node executing the read operation statement according to the query plan tree, some intermediate results will be generated, such as the current data cursor (i.e., the position of which data page the record is read to), the index result obtained at the end of the index (i.e., when searching for data, you can first index and then determine the specific data), etc.

[0085] The storage of the above-mentioned status information will be described below step 404 and will not be expanded here.

[0086] Optionally, the state information of the target transaction also includes a session state of the target transaction.

[0087] Each time a client opens a transaction, it initiates a transaction request, thereby establishing a connection with the database computing node through the scheduling node. Each connection corresponds to a session state. For a target transaction, the session state of the target transaction may include the target transaction's identifier, some execution parameters, the target transaction's isolation level, the client identifier that initiated the transaction request for the target transaction, and language preferences.

[0088] In some embodiments, the first database computing node stores the session state of the target transaction to the database state node during processing of the target transaction.

[0089] In this way, when the target transaction needs to be switched to other database computing nodes for execution, the scheduling node can obtain the session status of the target transaction from the database status node, and the scheduling node can obtain information such as the client identifier of the transaction request that initiated the target transaction and the identifier of the target transaction. Therefore, the scheduling node can switch the target transaction from the first database computing node to other database computing nodes without switching the wrong transaction or switching to an inappropriate computing node. The client does not need to resend the transaction request to successfully establish a connection with the database computing node to which the target transaction is switched, which can make the user unaware of the node switching.

[0090] In some embodiments, the first database computing node stores the state information of the target transaction to the database state node based on RDMA or CXL technology.

[0091] RDMA technology allows user programs to bypass the operating system kernel and directly interact with the network card to communicate over the network. CXL technology also has the characteristics of high bandwidth and low latency, and is often used in high-performance computing, cloud computing and other fields. Transmitting status information through RDMA technology or CXL technology can increase the network bandwidth and reduce the latency in the process of transmitting status information, thereby improving the efficiency of transmitting the status information of the target transaction from the first database computing node to the database status node, thereby improving the performance of the cloud native database system.

[0092] In some embodiments, the first database computing node stores the state information of the target transaction to the database state node based on RDMA write.

[0093] There are two transmission modes when transmitting information through RDMA technology, one is RDMA write mode and the other is RDMA read mode. The RDMA write mode has a higher throughput than the RDMA read mode, that is, it has a higher network bandwidth. Therefore, in the process of the first database computing node storing the status information of the target transaction to the database status node through RDMA technology, the status information of the target transaction is transmitted through RDMA write mode, so that the network bandwidth in the process of transmitting the status information can be further improved, thereby further improving the efficiency of transmitting the status information of the target transaction from the first database computing node to the database status node.

[0094] The state information is transmitted from the first database computing node to the database state node through RDMA technology or CXL technology. For the database state node, it can be implemented through an application program interface including an RDMA library or a CXL library, and the application program interface can be called a state disaggregated application program interface (state disaggregated API).

[0095] In some embodiments, the database status node uses persistent memory to store transaction status information.

[0096] In current cloud-native database technology, when a transaction is ready to be committed, the transaction log needs to be written to the disk of the database storage node for persistent storage before the transaction can be committed. If the database status node uses volatile memory, then when a transaction is committed, the transaction log will be written to the database storage node before the transaction is committed. In this way, during the processing of the transaction, the transaction log is equivalent to being written from the first database computing node to the database status node, and then from the database status node to the database storage node. The transaction log needs to go through two layers of network links, which will cause the performance of the cloud-native database system to degrade.

[0097] Therefore, the database status node uses persistent memory to store the status information of the transaction. After the first database computing node writes the transaction log to the status layer, the transaction log will be asynchronously flushed to the database status node at a later time. After the transaction log is written from the first database computing node to the database status node, the transaction can be committed without waiting for the transaction log to be flushed to the database storage node. In this way, the increase in the response time of the target transaction to the client can be avoided, and the performance degradation of the cloud native database system can be avoided because the log of the target transaction needs to go through two layers of network links to complete the submission.

[0098] In addition, if the database status node uses volatile memory (i.e., non-persistent memory) to save the status information of the transaction, the first database computing node can also directly store the transaction log to the database storage node from a bypass, so that the transaction can also be committed after the transaction log only passes through one layer of network link. It should be noted that in this implementation, at a later time, the transaction log will be transmitted from the database storage node to the database status node, so that the switched computing node can also obtain the transaction log status information from the status node.

[0099] Step 503: While the first database computing node is processing the target transaction, the first database computing node suspends processing the target transaction.

[0100] The first database computing node may suspend processing the target transaction when cross-node expansion or contraction is required or a failure occurs, and then the target transaction will be switched to the second database computing node by the scheduling node. In addition, in some cases, in order to balance the usage resources of various database computing nodes, the scheduling node may switch the target transaction from the first database computing node to other database computing nodes for processing. In this case, the first database computing node will also suspend processing the target transaction.

[0101] Among them, the switching of database computing nodes caused by cross-node expansion and contraction and the switching of database computing nodes caused by scheduling nodes to balance the usage resources of each database computing node are the switching of database computing nodes in the planned scenario, and the switching of database computing nodes caused by failures are the switching of database computing nodes in the unplanned scenario. In other words, the scenario in the plan refers to the scenario in which the first database computing node knows the switching plan of the database computing node in advance, and the scenario out of the plan refers to the scenario in which the first database computing node does not know the switching plan of the database computing node in advance.

[0102] It should be noted that the node type of the second database computing node may be the same as or different from that of the first database computing node. When the operation type corresponding to the target transaction is a read-only operation, the second database computing node may be a read-only node or a read-write node. When the operation type corresponding to the target transaction includes a write operation, the first database computing node is a read-write node.

[0103] In some embodiments, when switching the database computing node in a planned scenario, the scheduling node disconnects the connection with the first database computing node and establishes a connection with the second database computing node, thereby establishing a connection between the client and the second database computing node.

[0104] In some embodiments, if the scheduling node detects that the first database computing node fails, the scheduling node will also disconnect from the first database computing node and establish a connection with the second database computing node, thereby establishing a connection between the client and the second database computing node. This section describes the switching of database computing nodes in an unplanned scenario.

[0105] Step 504: The second database computing node obtains the state information of the target transaction from the database state node, and continues to process the target transaction based on the state information of the target transaction.

[0106] In some embodiments, the second database computing node obtains the state information of the target transaction from the database state node based on RDMA or CXL technology. In this way, the network bandwidth in the process of transmitting the state information can be improved, the delay of transmitting the state information can be reduced, and the efficiency of the second database computing node in obtaining the state information of the target transaction can be improved, thereby reducing the additional time overhead caused by the switching of the database computing node and improving the user experience.

[0107] In some embodiments, the second database computing node obtains the state information of the target transaction from the database state node based on RDMA write. In this way, the network bandwidth in the process of transmitting the state information can be further improved, and the efficiency of the second database computing node in obtaining the state information of the target transaction can be further improved, thereby further reducing the additional time overhead caused by the switching of the database computing node and improving the user experience.

[0108] The state information is transmitted from the database state node to the second database computing node through RDMA technology or CXL technology. For the database state node, it can also be implemented through the state disaggregated API described above.

[0109] In some embodiments, before switching the database computing node, the scheduling node records the pause position cursor of the target transaction, and the pause position cursor indicates the SQL statement being executed before the pause in the target transaction. After the scheduling node establishes a connection between the client and the second database computing node, the scheduling node sends the SQL statement being executed before the pause in the target transaction and the SQL statement to be executed in the target transaction to the second database computing node according to the pause position cursor, so that the second database computing node continues to execute the target transaction.

[0110] By storing the status information of the target transaction in the database status node and the second database computing node obtaining the status information of the target transaction from the database status node, the second database computing node can continue to process the target transaction according to the state before the target transaction was suspended. In other words, the embodiment of the present application can achieve breakpoint resumption at the transaction granularity.

[0111] In some embodiments, the status information of the target transaction is used to record the execution status of the SQL statement being executed in the target transaction before being paused; the second database computing node continues to process the target transaction based on the status information of the target transaction, including: the second database computing node continues to execute the SQL statement being executed in the target transaction based on the execution status of the SQL statement being executed in the target transaction before being paused.

[0112] The execution status of an SQL statement in the target transaction, that is, the status information related to the SQL statement in the status information of the target transaction. If an SQL statement is a write operation statement, the execution status of the SQL statement may include the operation status of the write operation corresponding to the SQL statement (recorded in the log of the target transaction), the lock table status of the write operation corresponding to the SQL statement, etc. If an SQL statement is a read operation statement, the execution status of the SQL statement may include the query plan tree and intermediate results corresponding to the SQL statement, etc.

[0113] Among them, an SQL statement is a read operation statement, and the query plan tree of the SQL statement is the tree structure of the query plan of the SQL statement, which is used to guide the execution steps of the SQL statement. The intermediate result of the SQL statement corresponding to a read operation refers to the result obtained by some execution steps of the query plan tree of the SQL statement (excluding the final execution result of the SQL statement).

[0114] By storing the execution status of the SQL statement being executed before the suspension in the target transaction in the database status node, and the second database computing node continuing to execute the SQL statement based on the execution status of the SQL statement, breakpoint resumption at the statement granularity is actually achieved.

[0115] The SQL statement being executed before the target transaction is suspended may be a write operation statement or a read operation statement. In these two cases, the possible implementation methods of step 502 and step 503 are different. The following introduces three implementation methods of the above step 502 and step 504:

[0116] In a first implementation, step 502 includes: the first database computing node stores the log of the target transaction to the database status node; and step 504 includes: the second database computing node continues to execute the write operation being executed before the suspension in the target transaction based on the log of the target transaction in the database status node.

[0117] It should be noted that, during the process of the first database computing node executing the target transaction, the operation status of each write operation will be recorded in the log of the target transaction and stored in the database status node. In this way, the second database computing node can obtain the location of the write operation being executed before the suspension in the target transaction, the operation status of the write operation, etc., based on the log of the target transaction, so as to continue to execute the write operation being executed before the suspension in the target transaction.

[0118] Optionally, the database storage node includes a log buffer, which is used to store transaction logs. In this case, step 502 includes: the first database computing node stores the log of the target transaction in the log buffer of the database status node.

[0119] In addition, if the SQL statement being executed before the target transaction is suspended is a statement for creating an index, step 502 may also include: the first database computing node also stores the index file corresponding to the data table involved in the SQL statement being executed before the target transaction is suspended in the database status node; step 504 may also include: the second database computing node continues to execute the write operation being executed before the target transaction is suspended based on the log of the target transaction in the database status node and the index file corresponding to the data table involved in the SQL statement being executed before the target transaction is suspended. In this way, it is possible to continue to construct and merge the index after switching the database computing node.

[0120] For example, assume that the SQL statement being executed before the target transaction is suspended is "Create Index index_1On R(A)", that is, before the target transaction is suspended, the operation of creating index index_1 on the data in column A of table R is being executed. Figure 6 As shown, it is assumed that the index file corresponding to the data table is the index file INDEX( Figure 6 The first database node needs to store the log of the target transaction ( Figure 6In this way, after the database computing node is switched, the second database computing node can pull out the index file INDEX and the log of the target transaction recording the execution status of the SQL statement from the database status node, so as to continue to execute the SQL statement and complete the continuation and merging of the index.

[0121] In some embodiments, step 502 also includes: the first database computing node stores the lock table status of the write operation being executed before the pause in the target transaction to the database status node; step 504 includes: the second database computing node continues to execute the write operation being executed before the pause in the target transaction based on the log of the target transaction in the database status node and the lock table status of the write operation being executed before the pause in the target transaction.

[0122] It should be noted that the lock table state corresponding to a write operation is actually generated before the write operation is executed, and the first database computing node actually stores the lock table state corresponding to a write operation to the database state node immediately after the lock table state is generated.

[0123] Optionally, the database storage node includes an active transaction list (active tran list), which is used to store transaction logs. In this case, step 502 includes: the first database computing node stores the lock table state of the write operation being executed before the suspension in the target transaction in the active tranlist of the database status node.

[0124] The second database computing node will record the lock table status of the write operation being executed before the target transaction is suspended in the corresponding data table of the buffer pool of the second database computing node. In this way, the second database computing node does not need to lock the data table again, saving the time of another table lock operation. At the same time, it can also ensure that when the second database computing node continues to execute the target transaction, other transactions executed by the second database computing node cannot operate on the data table being used by the write operation of the target transaction, which can prevent multiple transactions from concurrently writing to a data table, thereby ensuring the consistency and validity of the data.

[0125] For example, assume that the SQL statements included in the target transaction are as follows:

[0126] BEGIN TRANSACTION;

[0127] INSERT INTO R VALUES(100,'xxx');

[0128] COMMIT;

[0129] Assume that the second database computing node also executes another transaction, and the SQL statements included in the transaction are as follows:

[0130] BEGIN TRANSACTION;

[0131] INSERT INTO R VALUES(200,'aaa');

[0132] COMMIT;

[0133] It can be seen that these two transactions need to insert certain content into table R, and both include write operations on table R. Figure 7 As shown, assuming that the statement being executed before the target transaction is suspended is INSERT INTO R VALUES (100, 'xxx'), that is, the write operation to table R is being executed before the target transaction is suspended, the first database computing node will store the lock table state of table R to the database state node. Then, after the target transaction is switched to the second database computing node, the second database computing node can obtain the lock table state from the database state node. When the second database computing node continues to execute the write operation, it is not necessary to lock the table R again. At the same time, it can also ensure that when the second database computing node continues to execute the write operation, the above-mentioned other transaction executed by the second database computing node cannot write to table R, thereby ensuring the consistency and validity of the data in table R.

[0134] In the first implementation, since the log of the target transaction is recorded in real time and stored in the database status node during the entire process of executing the target transaction, and the lock table state corresponding to a write operation is actually generated and stored in the database status node before the write operation is performed, even if the first database computing node suddenly fails during the execution of a write operation, the operation status of the write operation has been recorded in the log of the target transaction and stored in the database status node, and the lock table state of the write operation has also been stored in the database status node. Therefore, for the case where the write operation is being executed before the target transaction is suspended, whether it is a node switch in an unplanned scenario or a node switch in an unplanned scenario, the embodiments of the present application can achieve breakpoint continuation at the transaction granularity or even the statement granularity.

[0135] The second implementation method, step 502 includes: the first database computing node stores the query execution plan tree and intermediate results of the SQL statement corresponding to the read operation being executed in the target transaction before the pause to the database status node; step 504 includes: the second database computing node continues to execute the read operation being executed before the pause in the target transaction based on the query execution plan tree and intermediate results of the SQL statement corresponding to the read operation being executed in the target transaction before the pause in the database status node.

[0136] It should be noted that the above-mentioned stored intermediate results are the latest intermediate results before the target transaction is suspended.

[0137] Optionally, the active tran list included in the database status node is also used to store the query plan tree and intermediate results of the SQL statement corresponding to the write operation being executed before the target transaction is suspended. In this case, step 502 includes: the first database computing node stores the query execution plan tree and intermediate results of the SQL statement corresponding to the read operation being executed before the suspension in the target transaction in the active tran list of the database status node.

[0138] That is to say, in the planned scenario, before switching the database computing node, the first database computing node will save the query plan tree and the latest intermediate result of the SQL statement corresponding to the read operation being executed in the target transaction to the database storage node. In this way, after switching the node, the second database computing node does not need to regenerate the query plan tree by itself, nor does it need to re-execute the SQL statement corresponding to the read operation. Instead, it can directly continue to execute the read operation being executed before the target transaction was suspended based on the query plan tree and the latest intermediate result obtained from the database storage node. In this way, the time and resource overhead of regenerating the query plan tree and redoing is avoided, which can improve the user experience.

[0139] For example, assume that the target transaction includes the following SQL statements:

[0140] BEGIN TRANSACTION;

[0141] SELECT RB,sum(SD)

[0142] FROM R,S

[0143] WHERE RA=SC AND RB>10AND SD>20

[0144] GROUP BY RB;

[0145] COMMIT;

[0146] like Figure 8 As shown, Figure 8 It shows the process of executing each operator in sequence according to the query plan tree of the SELECT statement. These operators mainly include the selection operator (select), hash join operator (hash join) and group-by operator (group-by). Figure 8 The triangles in the figure represent some intermediate results obtained by executing various operators. Assume that before the database computing node is switched, the first database computing node has just completed Figure 8 , and is executing operator 83. The first database computing node will combine the query plan tree of the SELECT statement and Figure 8 The intermediate result 82 in the database state node is stored in the database state node. In this way, after the database computing node is switched, the second database computing node can directly obtain the query plan tree and the query plan tree of the SELECT statement from the database state node. Figure 8 The intermediate result 82 in the second database computing node can continue to execute Figure 8 Operator 83 in the target transaction is executed, thereby continuing the read operation that was being executed before the suspension in the target transaction.

[0147] In the second implementation, since the first database computing node is required to save the SQL statement and the latest intermediate result corresponding to the read operation being executed before the suspension of the target transaction to the database status node before switching, the first database needs to be able to know the switching plan. It can be seen that the above method is applicable to the switching of database computing nodes in the planned scenario. That is, for the case where the read operation is being executed before the target transaction is suspended, after the database computing node is switched in the planned scenario, the embodiment of the present application can also resume the work at the transaction granularity or even the statement granularity.

[0148] In a third implementation, step 502 includes: the first database computing node stores the SQL statement corresponding to the read operation currently being executed in the target transaction to the status node during processing of the target transaction; step 504 includes: the second database computing node re-executes the SQL statement corresponding to the read operation being executed before the pause in the target transaction.

[0149] Optionally, the active tran list included in the database status node is also used to store the SQL statement corresponding to the read operation currently being executed in the target transaction. In this case, step 502 includes: the first database computing node stores the SQL statement corresponding to the read operation currently being executed in the target transaction in the active tran list of the database status node.

[0150] As can be seen from the above description, the scheduling node can record the pause cursor position of the target transaction, so that after the database computing node is switched, the SQL statement being executed before the pause in the target transaction and the SQL statement to be executed in the target transaction are sent to the second database computing node. Therefore, the first database computing node may not store the SQL statement corresponding to the read operation currently being executed in the target transaction. After the database computing node is switched, the second database computing node directly obtains the SQL statement being executed before the pause in the target transaction sent by the scheduling node, so as to re-execute the SQL statement corresponding to the read operation currently being executed in the target transaction.

[0151] Since the first database computing node does not know when the database computing node will be switched in an unplanned scenario, it is impossible to know when the latest intermediate results should be stored, so the second implementation method mentioned above cannot be used. In an unplanned scenario, if you want to be able to resume the breakpoint of the read operation as in the planned scenario, you need to save the intermediate results regularly, but this will bring about a large resource overhead. Therefore, in an embodiment of the present application, the first database computing node stores a SQL statement being executed at each moment in the process of processing the target transaction to the database status node, so that the subsequent second database computing node can obtain the SQL statement being executed before the target transaction is suspended, thereby redoing the statement. In other words, for the situation where a read operation is being performed before the target transaction is suspended, after the database computing node is switched in an unplanned scenario, the embodiment of the present application can redo the SQL statement corresponding to the read operation.

[0152] like Fig. 9 As shown, Fig. 9 A possible case of switching in a planned scenario is shown in Figure 1, when the target transaction is performing a read operation before being suspended. Fig. 9 In the figure, the dotted triangle in the first database computing node represents some operators that were not executed before the target transaction was suspended. From the figure, it can be seen that after the second database computing node obtains the query plan tree and intermediate results stored in the active transaction list in the database status node, it can continue to execute some unfinished operators, thereby realizing the breakpoint resumption of the SQL statement corresponding to the query plan tree. Fig.10 As shown, Fig.10 Shows a possible case of a switch in an unplanned scenario when the target transaction was performing a read operation before being suspended. Fig.10In the figure, the dotted triangles in the first database computing node represent some operators that were not executed before the target transaction was suspended. It can be seen from the figure that before the target transaction was suspended, the first database computing node only sent statement 1 to the database status node. After obtaining statement 1 stored in the active transaction list in the database status node, the second database computing node can re-execute statement 1.

[0153] In some embodiments, step 502 also includes: the first database computing node stores the execution result of the SQL statement corresponding to the read operation that has been executed in the target transaction to the database status node during processing of the target transaction; step 504 also includes: the second database computing node continues to process the target transaction based on the execution result of the SQL statement corresponding to the read operation that has been executed in the target transaction in the database status node after re-executing the SQL statement corresponding to the read operation currently being executed in the target transaction.

[0154] In this way, if the execution result of the SQL statement corresponding to the previous read operation is needed in the subsequent processing of the target transaction (which is rare), it can be used directly, which helps to achieve breakpoint resumption at the transaction granularity.

[0155] In summary, in the embodiment of the present application, the status information of the target transaction that the database status node needs to maintain may include: the log of the target transaction, the lock table status of the write operation being executed before the suspension of the target transaction, the query plan tree and intermediate results of the SQL statement corresponding to the read operation being executed before the suspension of the target transaction, the SQL statement being executed before the suspension of the target transaction, the execution result of the SQL statement corresponding to the read operation that has been executed by the target transaction, and the session status of the target transaction. The following Table 1 summarizes the functions / definitions, application scenarios and common application statements of these status information:

[0156] Table 1

[0157]

[0158] In some embodiments, the first database computing node pushes down the target operator of the SQL statement being executed before the suspension in the target transaction to the database storage node for execution, and the target operator is a partial operator included in the query execution plan tree of the SQL statement being executed.

[0159] By pushing down some operators to the database storage node for execution, the amount of data transmitted between the database storage node and the first database computing node can be reduced, and the speed at which the entire cloud-native database system processes the target transaction can also be accelerated.

[0160] In some embodiments, after the database storage node completes the execution of the target operator, it will store the execution result of the target operator. In this way, when the second database computing node needs the execution results of these target operators, it can directly obtain them from the database storage node, avoiding the process of transmitting the state information from the database storage node to the database state node.

[0161] In this case, after the first database computing node suspends processing of the target transaction, the second database computing node obtains the status information of the target transaction from the database status node, and obtains the execution result of the target operator from the database storage node; the second database computing node continues to execute the SQL statement being executed before the suspension in the target transaction based on the status information of the target transaction and the execution result of the target operator.

[0162] For example, for the statement "select xx from t1, t2 where t1.c = t2.c", a selection operation can be performed on the database storage node to select the two data tables t1 and t2, and then a join operation can be performed on the data in the two tables on the first database computing node.

[0163] Finally, it should be noted that the embodiment of the present application can realize the recovery of SQL statements when the database computing node is switched through the fault-tolerant daemon process in the database state node, and the fault-tolerant daemon process is located in the application program interface of the database state node. For example, the fault-tolerant daemon process is located in the above-mentioned state disaggregated API.

[0164] It should be understood that in various embodiments of the present application, the size of the serial numbers of the above-mentioned processes does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present application.

[0165] In an embodiment of the present application, during the execution of the target transaction, the first database computing node will send some status information of the target transaction to the database status node, and the database status node will store the status information. In this way, when the first database computing node suspends the execution of the target transaction and the target transaction is switched to the second database computing node for execution, the second database computing node can obtain the status information of the target transaction from the database status node. In this way, through the corresponding status information, when the operation being executed before the suspension in the target transaction is a write operation, no rollback or redo is required after completing the node switch in the planned and unplanned scenarios, but the breakpoint continuation of the transaction granularity or even the statement granularity can be achieved; when the operation being executed before the suspension in the target transaction is a read operation, after completing the node switch in the planned scenario, the second database computing node can continue to execute the read operation, and if it is a node switch in an unplanned scenario, the second database computing node can re-execute the SQL statement corresponding to the read operation. In this way, the extra time overhead caused by node switching can be saved to a large extent, and the user experience can be improved. In addition, since the session state of the target transaction is also stored in the database state node, the scheduling node can directly switch the node. The client does not need to resend the transaction request to successfully establish a connection with the database computing node to which the target transaction switches, which allows the user to be unaware of the node switching.

[0166] An embodiment of the present application also provides a cloud-native database system, which includes a first database computing node, a second database computing node, a database status node and a database storage node; the first database computing node and the second database computing node are used to process transactions requested by users, the database status node is used to store transaction status information, and the database storage node is used to store database data.

[0167] Among them, the first database computing node is specifically used to respond to the user's transaction request and start processing the target transaction, and the target transaction is used to perform read operations and / or write operations on the data in the database storage node; the first database computing node is also specifically used to store the status information of the target transaction to the database status node during the process of processing the target transaction; during the process of the first database computing node processing the target transaction, the first database computing node is also specifically used to suspend the processing of the target transaction; the second database computing node is specifically used to obtain the status information of the target transaction from the database status node, and continue to process the target transaction based on the status information of the target transaction.

[0168] Optionally, the target transaction includes at least one structured query language SQL statement, and the status information of the target transaction is used to record the execution status of the SQL statement being executed before the target transaction is paused; the second database computing node is specifically used to continue executing the SQL statement being executed in the target transaction based on the execution status of the SQL statement being executed before the target transaction is paused.

[0169] Optionally, the first database computing node is specifically used to store the log of the target transaction to the database status node; the second database computing node is specifically used to continue executing the write operation being executed before the pause in the target transaction based on the log of the target transaction in the database status node.

[0170] Optionally, the first database computing node is further specifically used to store the lock table status of the write operation being executed before the pause in the target transaction to the status node; the second database computing node is further specifically used to continue executing the write operation being executed before the pause in the target transaction based on the log of the target transaction in the database status node and the lock table status of the write operation being executed before the pause in the target transaction.

[0171] Optionally, the first database computing node is specifically used to store the query execution plan tree and intermediate results of the SQL statement corresponding to the read operation being executed before the pause in the target transaction to the database status node; the second database computing node is specifically used to continue executing the read operation being executed before the pause in the target transaction based on the query execution plan tree and intermediate results of the SQL statement corresponding to the read operation being executed before the pause in the target transaction in the database status node.

[0172] Optionally, the first database computing node is specifically used to store the SQL statement corresponding to the read operation currently being executed in the target transaction to the database status node during processing of the target transaction; the second database computing node is specifically used to re-execute the SQL statement corresponding to the read operation being executed in the target transaction before being paused.

[0173] Optionally, the first database computing node is further specifically used to store, in the process of processing the target transaction, the execution result of the SQL statement corresponding to the read operation that has been executed in the target transaction to the database status node; the second database computing node is further specifically used to continue processing the target transaction based on the execution result of the SQL statement corresponding to the read operation that has been executed in the target transaction in the database status node after re-executing the SQL statement corresponding to the read operation currently being executed in the target transaction.

[0174] Optionally, the database status node uses persistent memory to store transaction status information.

[0175] Optionally, the first database computing node is further specifically used to push down the target operator of the SQL statement being executed in the target transaction before being paused to the database storage node for execution, and the target operator is a partial operator included in the query execution plan tree of the SQL statement being executed; the database storage node is further specifically used to store the execution result of the target operator; when the first database computing node suspends processing of the target transaction, the second database computing node is further specifically used to obtain the status information of the target transaction from the database status node, and obtain the execution result of the target operator from the database storage node; the second database computing node is further specifically used to continue executing the SQL statement being executed in the target transaction before being paused based on the status information of the target transaction and the execution result of the target operator.

[0176] Optionally, the state information of the target transaction also includes a session state of the target transaction.

[0177] Optionally, the first database computing node is specifically used to store the state information of the target transaction to the database state node based on RDMA or CXL technology;

[0178] And / or, the second database computing node is specifically used to obtain the status information of the target transaction from the database status node based on RDMA or CXL technology.

[0179] Optionally, the first database computing node is specifically used to suspend processing of the target transaction when cross-node expansion or cross-node reduction is required or a failure occurs.

[0180] Technical personnel in the relevant field can clearly understand that, for the convenience and conciseness of description, the specific working process of the cloud native database system described above and the specific implementation of various operations of the transaction processing method in the execution method embodiment can refer to the corresponding process in the aforementioned method embodiment, and will not be repeated here.

[0181] In the embodiment of the present application, the architecture of the cloud native database system is a storage, calculation, and state separation architecture. In addition to the database computing node and the database storage node, the cloud native database system also includes a database status node. In the process of executing the target transaction, the first database computing node will send some status information of the target transaction to the database status node, and the database status node will store this status information; when the first database computing node suspends the execution of the target transaction and the target transaction is switched to the second database computing node for execution, the second database computing node can obtain the status information of the target transaction from the database status node. In this way, through the corresponding status information, when the operation being executed before the suspension in the target transaction is a write operation, it does not need to be rolled back or redone after the node switching is completed, but can achieve breakpoint continuation of the transaction granularity or even the statement granularity; when the operation being executed before the suspension in the target transaction is a read operation, after the node switching is completed, the second database computing node can continue to execute the read operation or re-execute the SQL statement corresponding to the read operation. In this way, the extra time overhead caused by node switching can be saved to a large extent, and the user experience can be improved.

[0182] The first database computing node, the second database computing node, the database status node, and the database storage node can all be implemented by software or by hardware. As an example, the implementation of the first database computing node is described below. Similarly, the implementation of other nodes can refer to the implementation of the first database computing node.

[0183] As an example of a software functional unit, the first database computing node may include code running on a computing instance. The computing instance may be at least one of a physical host (computing device), a virtual machine, a container, and other computing devices. Furthermore, the computing device may be one or more. For example, the first database computing node may include code running on multiple hosts / virtual machines / containers. It should be noted that the multiple hosts / virtual machines / containers used to run the application may be distributed in the same region or in different regions. The multiple hosts / virtual machines / containers used to run the code may be distributed in the same AZ or in different AZs, each AZ including a data center or multiple data centers with close geographical locations. Typically, a region may include multiple AZs.

[0184] Similarly, multiple hosts / virtual machines / containers used to run the code can be distributed in the same VPC or in multiple VPCs. Usually, a VPC is set up in a region. For cross-region communication between two VPCs in the same region and between VPCs in different regions, a communication gateway must be set up in each VPC to achieve interconnection between VPCs through the communication gateway.

[0185] As an example of a hardware functional unit, the first database computing node may include at least one computing device, such as a server, etc. Alternatively, the first database computing node may also be a device implemented using ASIC or PLD, etc. The PLD may be implemented using CPLD, FPGA, GAL or any combination thereof.

[0186] The multiple computing devices included in the first database computing node can be distributed in the same region or in different regions. The multiple computing devices included in the first database computing node can be distributed in the same AZ or in different AZs. Similarly, the multiple computing devices included in the first database computing node can be distributed in the same VPC or in multiple VPCs. The multiple computing devices can be any combination of computing devices such as servers, ASICs, PLDs, CPLDs, FPGAs, and GALs.

[0187] This embodiment of the application also provides a computing device 1100. Please refer to Fig.11 , the computing device 1100 includes: a bus 1102, a processor 1104, a memory 1106, and a communication interface 1108. The processor 1104, the memory 1106, and the communication interface 1108 communicate with each other through the bus 1102. The computing device 1100 can be a server or a terminal device. It should be understood that the present application does not limit the number of processors and memories in the computing device 1100.

[0188] The bus 1102 may be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus. The bus may be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Fig.11 The bus 1102 may include a path for transmitting information between various components of the computing device 1100 (eg, the memory 1106, the processor 1104, and the communication interface 1108).

[0189] The processor 1104 may include any one or more of a central processing unit (CPU), a graphics processing unit (GPU), a microprocessor (MP), or a digital signal processor (DSP).

[0190] The memory 1106 may include a volatile memory, such as a random access memory (RAM). The processor 1104 may also include a non-volatile memory, such as a read-only memory (ROM), a flash memory, a hard disk drive (HDD), or a solid state drive (SSD).

[0191] The memory 1106 stores executable program codes, and the processor 1104 executes the executable program codes to respectively implement the functions of the first database computing node, the second database computing node, the database status node, and the database storage node, thereby implementing the transaction processing method. That is, the memory 1106 stores instructions for executing the transaction processing method.

[0192] Alternatively, the memory 1106 stores executable codes, and the processor 1104 executes the executable codes to respectively implement the functions of any of the aforementioned nodes, thereby implementing the aforementioned transaction processing method. That is, the memory 1106 stores instructions for executing the aforementioned transaction processing method.

[0193] The communication interface 1108 uses a transceiver module such as, but not limited to, a network interface card or a transceiver to implement communication between the computing device 1100 and other devices or a communication network.

[0194] The embodiment of the present application also provides a computing device cluster. The computing device cluster includes at least one computing device. The computing device can be a server, such as a central server, an edge server, or a local server in a local data center. In some embodiments, the computing device can also be a terminal device such as a desktop computer, a laptop computer, or a smart phone.

[0195] like Fig.12As shown, the computing device cluster includes at least one computing device 1100. The memory 1106 in one or more computing devices 1100 in the computing device cluster may store the same instructions for executing the aforementioned transaction processing method.

[0196] In some possible implementations, the memory 1106 of one or more computing devices 1100 in the computing device cluster may also store some instructions for executing the aforementioned transaction processing method. In other words, the combination of one or more computing devices 1100 may jointly execute instructions for executing the aforementioned transaction processing method.

[0197] It should be noted that the memory 1106 in different computing devices 1100 in the computing device cluster can store different instructions, which are respectively used to execute part of the functions of any of the aforementioned nodes. That is, the instructions stored in the memory 1106 in different computing devices 1100 can implement one or more node functions of the first database computing node, the second database computing node, the database state node, and the database storage node.

[0198] In some possible implementations, one or more computing devices in the computing device cluster may be connected via a network, which may be a wide area network or a local area network. Fig.13 A possible implementation is shown. Fig.13 As shown, two computing devices 1100A and 1100B are connected via a network. Specifically, the network is connected via a communication interface in each computing device. In this type of possible implementation, the memory 1106 in the computing device 1100A stores instructions for executing the functions of the first database computing node and the second database computing node. At the same time, the memory 1106 in the computing device 1100B stores instructions for executing the functions of the database status node and the database storage node. Alternatively, the memory 1106 in the computing device 1100A stores instructions for executing the functions of the database status node and the database storage node. At the same time, the memory 1106 in the computing device 1100B stores instructions for executing the functions of the first database computing node.

[0199] Fig.13 The connection method between the computing device clusters shown can be that considering that the transaction processing method provided in the present application requires a large amount of data storage and calculation execution, etc., it is considered that the functions implemented by the above-mentioned first database computing node and the second database computing node are handed over to the computing device 1100B for execution, or the functions implemented by the above-mentioned database status node and database storage node are handed over to the computing device 1100B for execution.

[0200] It should be understood that Fig.13The functions of the computing device 1100A shown in FIG. 1100A may also be completed by multiple computing devices 1100. Similarly, the functions of the computing device 100B may also be completed by multiple computing devices 1100.

[0201] The present application embodiment also provides another computing device cluster. The connection relationship between the computing devices in the computing device cluster can be similar to that of Fig.13 The connection mode of the computing device cluster is shown in FIG. The difference is that the memory 1106 in one or more computing devices 1100 in the computing device cluster may store the same instructions for executing the aforementioned transaction processing method.

[0202] In some possible implementations, the memory 1106 of one or more computing devices 1100 in the computing device cluster may also store some instructions for executing the aforementioned transaction processing method. In other words, the combination of one or more computing devices 1100 may jointly execute instructions for executing the aforementioned transaction processing method.

[0203] It should be noted that the memory 1106 in different computing devices 1100 in the computing device cluster can store different instructions for executing some functions of the cloud native database system provided in the embodiment of the present application. That is, the instructions stored in the memory 1106 in different computing devices 1100 can implement the functions of one or more of the aforementioned first database computing node, second database computing node, database status node, and database storage node.

[0204] The embodiment of the present application also provides a computer program product including instructions. The computer program product may be software or a program product including instructions that can be run on a computing device or stored in any available medium. When the instructions are run by a computing device cluster, the computing device cluster executes the aforementioned transaction processing method.

[0205] The embodiment of the present application also provides a computer-readable storage medium. The computer-readable storage medium can be any available medium that can be stored by a computing device or a data storage device such as a data center that contains one or more available media. The available medium can be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid-state hard disk). The computer-readable storage medium includes computer program instructions, and when the computer program instructions are executed by a computing device cluster, the computing device cluster executes the aforementioned transaction processing method.

[0206] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When implemented using software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer instructions are loaded and executed on a computer, the process or function described in the embodiment of the present application is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network or other programmable device. The computer instructions can be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions can be transmitted from a website site, computer, server or data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) mode to another website site, computer, server or data center. The computer-readable storage medium can be any available medium that a computer can access, or a data storage device such as a server or data center that includes one or more available media integrated. The available medium may be a magnetic medium (e.g., a floppy disk, a hard disk, a magnetic tape), an optical medium (e.g., a digital versatile disc (DVD)), or a semiconductor medium (e.g., a solid state disk (SSD)). It is worth noting that the computer-readable storage medium mentioned in the embodiment of the present application may be a non-volatile storage medium, in other words, a non-transient storage medium.

[0207] It should be understood that the "multiple" mentioned herein refers to two or more. In the description of the embodiments of the present application, unless otherwise specified, " / " means or, for example, A / B can mean A or B; "and / or" in this article is only a description of the association relationship of the associated objects, indicating that there can be three relationships, for example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone. In addition, in order to facilitate the clear description of the technical solution of the embodiments of the present application, in the embodiments of the present application, the words "first", "second" and the like are used to distinguish between the same items or similar items with basically the same functions and effects. Those skilled in the art can understand that the words "first", "second" and the like do not limit the quantity and execution order, and the words "first", "second" and the like do not limit them to be necessarily different.

[0208] It should be noted that the information (including but not limited to user device information, user personal information, etc.), data (including but not limited to data used for analysis, stored data, displayed data, etc.) and signals involved in the embodiments of the present application are all authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data need to comply with relevant laws, regulations and standards of relevant countries and regions.

[0209] The above-mentioned embodiments are provided for the present application and are not intended to limit the present application. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present application shall be included in the protection scope of the present application.

Claims

1. A transaction processing method, characterized in that: Applied to a cloud native database system, the cloud native database system includes a first database computing node, a second database computing node, a database status node and a database storage node; the first database computing node and the second database computing node are used to process transactions requested by users, the database status node is used to store transaction status information, and the database storage node is used to store database data; the method includes: The first database computing node responds to a transaction request from a user and starts processing a target transaction, wherein the target transaction is used to perform a read operation and / or a write operation on data in the database storage node; The first database computing node stores the state information of the target transaction to the database state node during processing of the target transaction; During the process of the first database computing node processing the target transaction, the first database computing node suspends processing the target transaction; The second database computing node obtains the status information of the target transaction from the database status node, and continues to process the target transaction based on the status information of the target transaction.

2. The method according to claim 1, characterized in that The target transaction includes at least one structured query language SQL statement, and the state information of the target transaction is used to record the execution state of the SQL statement being executed before being suspended in the target transaction; The second database computing node continues to process the target transaction based on the state information of the target transaction, including: The second database computing node continues to execute the SQL statement being executed in the target transaction based on the execution status of the SQL statement being executed before being suspended in the target transaction.

3. The method according to claim 1 or 2, characterized in that: The first database computing node stores the state information of the target transaction to the database state node during processing of the target transaction, including: the first database computing node stores the log of the target transaction to the database state node; The second database computing node continues to process the target transaction based on the status information of the target transaction, including: the second database computing node continues to execute the write operation being executed before the suspension in the target transaction based on the log of the target transaction in the database status node.

4. The method according to claim 3, characterized in that The first database computing node stores the state information of the target transaction to the database state node during processing of the target transaction, further comprising: the first database computing node stores the lock table state of the write operation being executed before the suspension in the target transaction to the state node; The second database computing node continues to process the target transaction based on the status information of the target transaction, including: the second database computing node continues to execute the write operation being executed before the suspension in the target transaction based on the log of the target transaction in the database status node and the lock table status of the write operation being executed before the suspension in the target transaction.

5. The method according to claim 1 or 2, characterized in that: The first database computing node stores the state information of the target transaction to the database state node during the process of processing the target transaction, including: the first database computing node stores the query execution plan tree and intermediate results of the SQL statement corresponding to the read operation being executed before the suspension in the target transaction to the database state node; The second database computing node continues to process the target transaction based on the status information of the target transaction, including: the second database computing node continues to execute the read operation being executed before the suspension in the target transaction based on the query execution plan tree and intermediate results of the SQL statement corresponding to the read operation being executed in the target transaction before the suspension in the database status node.

6. The method according to claim 1, characterized in that The first database computing node stores the state information of the target transaction to the database state node during the process of processing the target transaction, including: the first database computing node stores the SQL statement corresponding to the read operation currently being executed in the target transaction to the database state node during the process of processing the target transaction; The second database computing node continues to process the target transaction based on the state information of the target transaction, including: the second database computing node re-executes the SQL statement corresponding to the read operation being executed before the suspension in the target transaction.

7. The method according to claim 6, characterized in that The first database computing node stores the state information of the target transaction to the database state node during processing of the target transaction, further comprising: the first database computing node stores the execution result of the SQL statement corresponding to the read operation that has been executed in the target transaction to the database state node during processing of the target transaction; The second database computing node continues to process the target transaction based on the status information of the target transaction, and also includes: after the second database computing node re-executes the SQL statement corresponding to the read operation currently being executed in the target transaction, the second database computing node continues to process the target transaction based on the execution result of the SQL statement corresponding to the read operation that has been executed in the target transaction in the database status node.

8. The method according to any one of claims 1 to 7, characterized in that The database status node uses persistent memory to store transaction status information.

9. The method according to any one of claims 1 to 8, characterized in that The method further comprises: The first database computing node pushes down the target operator of the SQL statement being executed before the suspension in the target transaction to the database storage node for execution, wherein the target operator is a partial operator included in the query execution plan tree of the SQL statement being executed; The database storage node stores the execution result of the target operator; After the first database computing node suspends processing of the target transaction, the second database computing node obtains the status information of the target transaction from the database status node, and continues to process the target transaction based on the status information of the target transaction, including: After the first database computing node suspends processing of the target transaction, the second database computing node obtains the status information of the target transaction from the database status node, and obtains the execution result of the target operator from the database storage node; The second database computing node continues to execute the SQL statement being executed before the suspension in the target transaction based on the state information of the target transaction and the execution result of the target operator.

10. The method according to any one of claims 1 to 9, characterized in that The state information of the target transaction also includes the session state of the target transaction.

11. The method according to any one of claims 1 to 10, characterized in that The method comprises: The first database computing node stores the state information of the target transaction to the database state node based on remote direct data access RDMA or memory interconnect CXL technology; And / or, the second database computing node obtains the status information of the target transaction from the database status node based on RDMA or CXL technology.

12. The method according to claim 1, characterized in that The first database computing node suspends processing of the target transaction when cross-node expansion or cross-node reduction is required or a failure occurs.

13. A cloud native database system, characterized in that: The cloud native database system includes a first database computing node, a second database computing node, a database status node and a database storage node; the first database computing node and the second database computing node are used to process transactions requested by users, the database status node is used to store transaction status information, and the database storage node is used to store database data; The first database computing node is specifically used to respond to a transaction request of a user and start processing a target transaction, wherein the target transaction is used to perform a read operation and / or a write operation on data in the database storage node; The first database computing node is further configured to store the state information of the target transaction to the database state node during processing of the target transaction; During the process of the first database computing node processing the target transaction, the first database computing node is further configured to suspend processing of the target transaction; The second database computing node is specifically configured to obtain the status information of the target transaction from the database status node, and continue to process the target transaction based on the status information of the target transaction.

14. The system according to claim 13, characterized in that The target transaction includes at least one structured query language SQL statement, and the state information of the target transaction is used to record the execution state of the SQL statement being executed before being suspended in the target transaction; The second database computing node is specifically configured to continue executing the SQL statement being executed in the target transaction based on the execution status of the SQL statement being executed before being suspended in the target transaction.

15. The system according to claim 13 or 14, characterized in that The first database computing node is specifically used to store the log of the target transaction to the database status node; The second database computing node is specifically configured to continue executing the write operation being executed before the suspension in the target transaction based on the log of the target transaction in the database status node.

16. The system according to claim 15, characterized in that The first database computing node is further specifically configured to store the lock table state of the write operation being executed before the target transaction is suspended in the state node; The second database computing node is further specifically configured to continue executing the write operation being executed before the target transaction is suspended based on the log of the target transaction in the database status node and the lock table status of the write operation being executed before the target transaction is suspended.

17. The system according to claim 13 or 14, characterized in that The first database computing node is specifically used to store the query execution plan tree and intermediate results of the SQL statement corresponding to the read operation being executed before the suspension in the target transaction to the database status node; The second database computing node is specifically used to continue executing the read operation being executed before the suspension in the target transaction based on the query execution plan tree and intermediate results of the SQL statement corresponding to the read operation being executed before the suspension in the target transaction in the database status node.

18. The system according to claim 13, characterized in that The first database computing node is specifically configured to store, in the process of processing the target transaction, the SQL statement corresponding to the read operation currently being executed in the target transaction to the database status node; The second database computing node is specifically used to re-execute the SQL statement corresponding to the read operation being executed before the suspension in the target transaction.

19. The system according to claim 18, characterized in that The first database computing node is further configured to store, in the process of processing the target transaction, the execution result of the SQL statement corresponding to the read operation that has been executed in the target transaction to the database status node; The second database computing node is also specifically used to continue processing the target transaction based on the execution results of the SQL statements corresponding to the read operations that have been executed in the target transaction in the database status node after re-executing the SQL statements corresponding to the read operations currently being executed in the target transaction.

20. The system according to any one of claims 13 to 19, characterized in that The database status node uses persistent memory to store transaction status information.

21. The system according to any one of claims 13 to 20, characterized in that The first database computing node is further specifically used to push down the target operator of the SQL statement being executed before being suspended in the target transaction to the database storage node for execution, wherein the target operator is a partial operator included in the query execution plan tree of the SQL statement being executed; The database storage node is specifically further used to store the execution result of the target operator; When the first database computing node suspends processing of the target transaction, the second database computing node is further configured to obtain status information of the target transaction from the database status node, and obtain an execution result of the target operator from the database storage node; The second database computing node is further specifically configured to continue executing the SQL statement being executed before the suspension in the target transaction based on the state information of the target transaction and the execution result of the target operator.

22. A system according to any one of claims 13 to 21, characterized in that The state information of the target transaction also includes the session state of the target transaction.

23. The system according to any one of claims 13 to 22, characterized in that The first database computing node is specifically used to store the state information of the target transaction to the database state node based on remote direct data access RDMA or memory interconnect CXL technology; And / or, the second database computing node is specifically used to obtain the status information of the target transaction from the database status node based on RDMA or CXL technology.

24. The system according to claim 13, characterized in that The first database computing node is specifically used to suspend processing of the target transaction when cross-node expansion or cross-node reduction is required or a failure occurs.

25. A computing device cluster, characterized in that: comprising at least one computing device, each computing device comprising a processor and a memory; The processor of the at least one computing device is configured to execute instructions stored in the memory of the at least one computing device, so that the computing device cluster executes the method according to any one of claims 1 to 12.

26. A computer-readable storage medium, characterized in that: The method comprises computer program instructions, and when the computer program instructions are executed by a computing device cluster, the computing device cluster performs the method according to any one of claims 1 to 12.

27. A computer program product comprising instructions, characterized in that When the instructions are executed by a computing device cluster, the computing device cluster is caused to perform the method according to any one of claims 1 to 12.

Images