Database transaction execution method and device, storage medium and electronic equipment

Abstract

The embodiment of the invention discloses a database transaction execution method, which comprises the following steps that: a coordinator in a distributed database system generates a log stream corresponding to more than two partitions, a database node screens log records corresponding to the partitions stored in the database node after obtaining the log stream, and the log records are stored in the partitions; assembling database transactions according to the screened log records, determining an execution sequence of the database transactions, and finally executing the database transactions in sequence according to the execution sequence. Through the method, the log stream is no longer a single log stream corresponding to one partition, but multiple partitions share one log stream, so that the possibility that the same database transaction needs to cross the log stream can be greatly reduced, the number of times of two-stage submission of one database transaction can be effectively reduced, and the workload of the database transaction is reduced. Therefore, database transactions can be executed more quickly and efficiently.

Description

TECHNICAL FIELD

[0001] The present specification relates to the technical field of computer technology, and particularly relates to a database transaction execution method and device, a storage medium and an electronic equipment. BACKGROUND

[0002] At present, distributed database systems have been widely applied in various industries, and how to improve the performance of database systems is an eternal topic in the field of database technology.

[0003] In accordance with the Write-Ahead Logging (WAL) principle of a modern database system storage engine, a log stream is usually used to operate data in a database instance stored by the database system.

[0004] Specifically, when a distributed database system receives a SQL statement for operating data, the distributed database system first generates a log record according to the SQL statement, adds the log record to a log stream, assembles a database transaction according to the log records in the log stream, and finally submits the database transaction under the premise of ensuring atomicity, so as to execute the database transaction according to the log records in the database transaction and complete the operation on the data.

[0005] How to more efficiently execute a database transaction based on a log stream is a problem to be solved. SUMMARY

[0006] Embodiments of the present specification provide a database transaction execution method and device, a storage medium and an electronic equipment to partially solve the problems existing in the prior art.

[0007] Embodiments of the present specification adopt the following technical solutions:

[0008] The present specification provides a database transaction execution method, which comprises:

[0009] The database node obtains a log stream generated by a coordinator in a distributed database system in which the database node is located, and the log stream corresponds to two or more partitions in a same database instance stored by the distributed database system;

[0010] In each log record included in the log stream, a log record in which a required operation partition is a partition stored by the database node itself is selected as a target log record;

[0011] A database transaction is assembled according to each target log record selected;

[0012] An execution order of each database transaction assembled is determined;

[0013] Each database transaction assembled is executed in sequence according to the execution order.

[0014] This specification provides a database transaction execution apparatus, the apparatus comprising:

[0015] The acquisition module is used to acquire the log stream generated by the coordinator in the distributed database system in which the device itself resides, wherein the log stream corresponds to two or more partitions in the same database instance stored in the distributed database system;

[0016] The filtering module is used to filter log records from the log records contained in the log stream that are partitions stored by the device itself and are the partitions to be operated on, as the target log records.

[0017] The assembly module is used to assemble database transactions based on the selected target log records.

[0018] The sequencing module is used to determine the execution order of the assembled database transactions;

[0019] The execution module is used to execute the assembled database transactions sequentially according to the execution order.

[0020] This specification provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described database transaction execution method.

[0021] This specification provides an electronic device including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the program, it implements the above-described database transaction execution method.

[0022] The above-described at least one technical solution adopted in the embodiments of this specification can achieve the following beneficial effects:

[0023] This specification discloses a method for executing database transactions. In this method, a coordinator in a distributed database system generates log streams corresponding to two or more partitions. After obtaining the log streams, database nodes filter log records corresponding to their own stored partitions, assemble database transactions based on the filtered log records, determine the execution order of each database transaction, and finally execute the database transactions sequentially according to this order. Through this method, the log stream is no longer a single stream corresponding to a single partition, but rather multiple partitions share a single log stream. This significantly reduces the likelihood of the same database transaction needing to cross log streams, thereby effectively reducing the number of times a database transaction needs to undergo two-phase commit, and thus enabling faster and more efficient execution of database transactions. Attached Figure Description

[0024] The accompanying drawings, which are included to provide a further understanding of this specification and form part of this specification, illustrate exemplary embodiments and are used to explain this specification, but do not constitute an undue limitation thereof. In the drawings:

[0025] Figure 1 This is a schematic diagram of the distributed database system architecture provided in the embodiments of this specification;

[0026] Figure 2 A flowchart illustrating a database transaction execution method provided in an embodiment of this specification;

[0027] Figure 3 A schematic diagram of a database transaction execution device provided for an embodiment of this specification;

[0028] Figure 4 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this specification. Detailed Implementation

[0029] To make the objectives, technical solutions, and advantages of this specification clearer, the technical solutions of this specification will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this specification, and not all of them. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this specification.

[0030] The technical solutions provided in the various embodiments of this specification are described in detail below with reference to the accompanying drawings.

[0031] Figure 1 This is a schematic diagram of the distributed database system architecture provided in the embodiments of this specification, such as... Figure 1 As shown in the embodiments of this specification, the distributed database system mainly includes two roles: coordinator and database node.

[0032] The coordinator is user-facing, communicating with user devices and receiving SQL statements from them. These SQL statements are used to manipulate data stored in the distributed database system. Upon receiving an SQL statement, the coordinator generates a log stream based on that statement. Specifically, the coordinator can generate a log record based on the received SQL statement and add that log record to the log stream corresponding to the partition where the data being manipulated resides.

[0033] The coordinator can be implemented through proxy nodes. In actual deployment of a distributed database system, this proxy node and a database node can be hosted on the same hardware device (such as a server). Moreover, there can be more than one proxy node. In extreme cases, each database node can simultaneously act as a proxy node to generate log streams. Of course, the proxy node can also be independent of any database node and hosted on a separate hardware device.

[0034] Database nodes are used to store data. The following is a brief introduction to database nodes from two perspectives.

[0035] First, from a data perspective, a database node can store data from ordinary tenants and data from system tenants.

[0036] A tenant is a database instance. In the embodiments of this specification, a regular tenant is a database instance, which can be of various types, such as MySQL or other types of database instances.

[0037] A database instance consists of several tables. To facilitate the management of these tables, each table is typically divided into partitions. This partitioning can be based on the primary key of the data, or by the first letter of the primary key, a number, or the number of records. For example, data starting with the primary key "AJ" can be partitioned into one partition, and data starting with "KZ" into another. Alternatively, data starting with the primary key numbers 0-5 can be partitioned into one partition, and data starting with 6-9 into another. Or, partitioning the table into partitions for every million records, etc. This specification does not limit the specific partitions used in this embodiment.

[0038] A database node can store replicas of several partitions in a database instance. Each partition has at least one primary replica and may also have several secondary replicas. The primary and secondary replicas of a partition are identical. For a given partition, if the database node stores the primary replica of that partition, then the database node is the primary node of that partition; if the database node stores a secondary replica of that partition, then the database node is the secondary node of that partition.

[0039] System tenants differ from ordinary tenants. The data in a system tenant is metadata about all partitions in that database instance. The metadata mainly records how many data tables and partitions there are in the database instance, and the data tables to which each partition belongs.

[0040] Based on the two types of tenants mentioned above, when a database node executes a database transaction, it needs to first query the metadata stored in the system tenant to find the partition where the data to be operated on by the database transaction is located, based on the log records in the database transaction, and then operate on the data in the target partition according to the log records.

[0041] Typically, a log stream corresponds to only one partition. The master node of that partition subscribes to and pulls the log stream corresponding to that partition, assembles it into a database transaction, commits and executes it, and then synchronizes the updated copy of that partition to the slave nodes of that partition. Only when the master node of that partition is under too much pressure will the master node forward the log stream corresponding to that partition to the slave nodes of that partition. The slave nodes will then execute the database transaction corresponding to that partition based on the log stream, and will also synchronize the updated copy of that partition to the master node and other slave nodes of that partition.

[0042] However, a database transaction typically involves multiple log records, or multiple SQL statements, rather than just one. These different log records may operate on different data, and the partitions where this data resides may also differ. This creates a situation where the same database transaction needs to be processed across log streams. For example, if user A pays user B 100 yuan, this database transaction requires two SQL statements: one to decrease user A's balance by 100 yuan, and the other to increase user B's balance by 100 yuan. User A's balance data resides in partition 1, and user B's balance data resides in partition 2. The master node for partition 1 is node a, and the master node for partition 2 is node b. Since both SQL statements belong to the same database transaction, both nodes a and b need to participate in this transaction. Typically, based on a pre-defined consensus method (such as Raft), a coordinator and these two participants need to perform a two-phase commit for the database transaction. This ensures that nodes a and b either both successfully operate on the data in their respective partitions, or both fail and roll back to their pre-operation state, thus guaranteeing data atomicity.

[0043] Second, from a system perspective, a database node has three main engines: the SQL engine, the transaction engine, and the storage engine.

[0044] The SQL engine is primarily used to parse SQL statements. For example, when a database node acts as a coordinator to generate a log stream, it can parse the SQL statement sent by the user device after receiving it, to determine the operation type of the SQL statement, including adding, deleting, modifying, and querying data, creating or deleting data tables, creating or deleting partitions, etc., and generate corresponding log records accordingly, adding them to the log stream. It can also generate log record IDs, database transaction IDs, etc. for these log records.

[0045] The transaction engine is primarily used to commit and execute transactions. For example, when a database node obtains an assembled database transaction, it determines the partition containing the data to be operated on in the log record based on the log records in the database transaction and the system tenants in the database node, and then performs operations on the data in that partition according to the log record.

[0046] Storage engines are primarily used to manage data tables and data partitions. This includes creating or deleting data tables and partitions.

[0047] In this embodiment of the specification, to reduce the likelihood of a two-phase commit being required for the same database transaction across log streams, the log stream generated by the coordinator no longer corresponds to only one partition, but rather to two or more partitions within the database instance. Regardless of whether the database node stores a primary or secondary copy of a partition, as long as it stores a copy of the partition containing all the data required for a database transaction, it can execute the database transaction locally. This minimizes the possibility of needing a two-phase commit and speeds up database transaction execution. Figure 2 As shown.

[0048] Figure 2 A flowchart illustrating a database transaction execution method provided in this specification includes the following steps:

[0049] S200: Database nodes obtain the log stream generated by the coordinator in their distributed database system.

[0050] In the embodiments described in this specification, the log stream generated by the coordinator corresponds to two or more partitions within the same database instance stored in the distributed database system. It is worth noting that, in these embodiments, different partitions within the same database instance can share the same log stream, but different partitions in different database instances cannot share the same log stream.

[0051] Specifically, the coordinator receives SQL statements sent by user devices and parses them using an SQL engine to determine the operation type, the partition where the data to be operated on resides, the timestamp, and the transaction ID. Based on this, a log record is generated, and then the log record is added to the corresponding log stream for distribution according to the partition where the data to be operated on resides. Different SQL statements belonging to the same database transaction will have the same transaction ID in their corresponding log records.

[0052] Furthermore, a database transaction often contains more than one log record, meaning that a database transaction often needs to operate on more than one piece of data. These operations are divided into Data Manipulation Language (DML) operations and Data Definition Language (DDL) operations. DML operations are used to manipulate data without changing the structure of the database instance, while DDL operations are used to change the structure of the database instance, such as adding or creating a data table.

[0053] The log records corresponding to DML operations and DDL operations may belong to the same database transaction. For example, a table may be created first, and then a record may be inserted into that table. In this case, the coordinator can store all log records in a pre-defined multi-source transaction cache that contain log records corresponding to at least one DDL operation.

[0054] The database node can use its own Fetcher component to obtain the log stream generated and distributed by the coordinator without DDL operations through Remote Procedure Call (RPC). At the same time, it can also obtain the log records stored by the coordinator from the multi-source transaction cache mentioned above.

[0055] S202: Among the log records contained in the log stream, filter the log records of the partition to be operated on as the partition stored by the database node itself, and use them as the target log records.

[0056] After the database node obtains each log record in the log stream through the Fetcher component, it can filter out the log records of the partition where the data to be operated is located as the partition to be stored as the target log records, so that the corresponding database transactions can be executed according to these target log records in the future.

[0057] It's important to note that this database node may store replicas of multiple partitions within the database instance. Regardless of whether the stored replica is a primary or secondary replica of that partition, as long as a replica of the partition is stored, the database node can use the Fetcher component to filter out the log records of the partition containing the data to be operated on in the log stream, using these as target log records. For log records directly obtained from the aforementioned multi-source transaction cache, the database node can use all log records obtained from the multi-source transaction cache as target log records. This is because the log records stored in the database multi-source transaction cache must contain database transactions that require DDL operations to change the database instance structure. Furthermore, each system tenant of every database node used to store at least one piece of data in the database instance needs to completely record the metadata of the database instance. This is because, for a data table or partition within the database instance, even if the database node does not currently store a replica of that data table or partition, it is still very likely that the database node will store a replica of that data table or partition during subsequent data migration or the addition and creation of partition replicas. Therefore, all log records contained in the aforementioned multi-source transaction cache are target log records for any database node.

[0058] S204: Assemble database transactions based on the selected target log records.

[0059] Specifically, database nodes can use their own Fetcher component to assemble target log records corresponding to the same transaction ID into the same database transaction based on the transaction ID in each target log record.

[0060] S206: Determine the execution order of the assembled database transactions.

[0061] Since each log record in the log stream generated by the coordinator has a corresponding timestamp, the database node can use its own Fetcher component to determine the execution order of the assembled database transactions based on the timestamps of the target log records in each database transaction. Specifically, the Fetcher component can use the latest timestamp of the log record corresponding to each assembled database transaction as the timestamp of that database transaction. Then, based on the order of the timestamps of each database transaction, the execution order of the database transactions is determined.

[0062] S208: Execute each database transaction assembled in the order described above.

[0063] After the database node determines the execution order of each database transaction through the above step S206, it can use its own transaction engine to sequentially determine the partition to be operated on for each assembled database transaction, based on the log records contained in the database transaction and the metadata of each partition in the database instance stored in the system tenant carried by the database node itself, as the target partition, and then operate on the data required for each log record in the target partition according to the log records contained in the database transaction.

[0064] The metadata of each partition in the aforementioned database instance is only a part of the metadata of the database instance within the system tenant. The metadata of each partition mainly records the number of partitions in the database instance, the log stream corresponding to each partition, the database nodes where the primary and secondary replicas of each partition reside, and the data tables to which each partition belongs. The metadata of the entire database instance, however, includes not only the metadata of each partition but also the metadata of the data tables.

[0065] Database nodes can use their own transaction engine to query the metadata of each partition in their own system tenants based on the log records contained in the database transaction, in order to locate the replica of the partition where the data to be operated on by the database transaction is located (whether the replica is a primary replica or a secondary replica), that is, the replica of the target partition, and operate on the data in the replica of the target partition according to the log records contained in the database transaction.

[0066] For example, let's continue with the example of user A paying user B 100 yuan. User A's balance data is located in partition 1, and user B's balance data is located in partition 2. The primary replica of partition 1 is on node a, and the primary replica of partition 2 is on node b, but the secondary replica is on node a. Since the replicas of both partitions are on node a, in this embodiment, node a does not need to participate in the database transaction as a participant along with node b, nor does it need to initiate a two-phase commit with the collaborators. Instead, it directly operates on the data in the two replicas based on the two log records in the database transaction. However, atomicity still needs to be guaranteed locally on node a; that is, either the data in both replicas is successfully operated on, or the data in both replicas fails and rolls back to the state before the operation. This effectively reduces the number of two-phase commits and speeds up the execution of database transactions.

[0067] In addition, after a database node operates on the data in a copy of the target partition, it can also synchronize the locally updated copy of the target partition to other database nodes that store copies of the target partition. The specific synchronization method is not limited in the embodiments of this specification.

[0068] In the embodiments described in this specification, even if a log record is just a regular DML operation and not a DDL operation, it may still cause changes to the metadata of each partition in the database instance within the system tenant. For example, when a data table in the database instance is divided into partitions with each partition consisting of 1 million rows of data, if the data table currently has 2 million rows of data written to it and there are currently 2 partitions, and a DML operation needs to insert another row of data into the data table, then a new partition needs to be added after the data is inserted, which will cause changes to the metadata of each partition in the database instance.

[0069] Therefore, when the database node commits and executes each database transaction according to the execution order determined in step S206 through the transaction engine, for the currently executing database transaction, it is also necessary to determine, based on the log record contained in the database transaction and the metadata of each partition in the database instance stored in the system tenant, whether operating on the data required by the log record in the target partition will cause a change in the metadata of at least one partition in the database instance. If so, the metadata of each partition in the database instance stored in the system tenant needs to be updated through the storage engine of the database node; otherwise, the database transaction can be executed normally through the transaction engine in the above manner.

[0070] Specifically, when updating the metadata of each partition in the database instance stored in the system tenant, if it is necessary to add a partition in the database instance, the database node can determine the database node to be used to store the partition to be added as the target node through its own storage engine, and notify the target node to create and store a copy of the partition to be added and determine the log stream corresponding to the partition to be added, and update the metadata of each partition in the database instance stored in the system tenant of the database node itself.

[0071] There may be more than one target node for storing the partition to be added. This includes a target node for storing the primary replica of the partition to be added, as well as a target node for storing the secondary replica of the partition to be added. The target node may or may not include the database node itself. Specifically, the database node can notify all database nodes in the distributed database system through the storage engine. All database nodes, including the database node itself, elect target nodes for storing the primary and secondary replicas of the partition to be added according to a preset consensus rule. The elected target nodes create and store the replicas of the partition to be added locally. The database node then updates the metadata of each partition of the database instance in the system tenant based on the primary replica, secondary replica, and each target node.

[0072] If a partition in a database instance needs to be deleted, the database node can use its own storage engine to determine whether all database transactions currently pending execution on all database nodes depend on the partition to be deleted. If there are database transactions that depend on the partition to be deleted, it needs to wait until there are no more database transactions that depend on the partition to be deleted. Then, the database node can notify the database node storing a copy of the partition to be deleted to delete the partition and update the metadata of each partition in the database instance stored in the system tenant of the database node itself.

[0073] After updating the metadata of each partition of the database instance in its own system tenant, the database node can also synchronize the updated metadata of each partition of the database instance to other database nodes that store at least one partition of the database instance, so as to achieve the purpose of complete synchronization of the metadata stored in the system tenant in all database nodes.

[0074] It should be noted that the above is only an example of a regular database transaction that only contains DML operations. For database transactions that contain DDL operations and are used to change the database instance structure, the database node can directly obtain them from the preset multi-source transaction cache and can prioritize the execution of database transactions that contain DDL operations.

[0075] Specifically, the database node can determine whether a database transaction containing DDL operations depends on other database transactions pending execution on all current database nodes. If not, then... Figure 2 In step S206, when determining the execution order of each database transaction, the database transaction containing DDL operations can be determined to be executed first. If there is a dependency, it can wait until the other database transactions it depends on have been executed before prioritizing the scheduling of the database transaction containing DDL operations.

[0076] The database transaction execution methods described in the embodiments of this specification can all be implemented through the Change Data Capture (CDC) service of the database node. Specifically, the database node can start its own CDC service process, and through this CDC service process, through the SQL engine, transaction engine and storage engine of the database node, operate on the data in the database instance and / or system tenant hosted by the database node, and synchronize with other database nodes.

[0077] The above is an example of a database transaction execution method provided in this specification. Based on the same idea, this specification also provides corresponding devices, storage media, and electronic devices.

[0078] Figure 3This is a schematic diagram of a database transaction execution device provided in an embodiment of this specification. The device includes:

[0079] The acquisition module 301 is used to acquire the log stream generated by the coordinator in the distributed database system in which the device itself is located, wherein the log stream corresponds to two or more partitions in the same database instance stored in the distributed database system;

[0080] The filtering module 302 is used to filter log records from the log records contained in the log stream that are partitions stored by the device itself and are to be operated on, as target log records.

[0081] Assembly module 303 is used to assemble database transactions based on the selected target log records;

[0082] Sequencing module 304 is used to determine the execution order of the assembled database transactions;

[0083] The execution module 305 is used to execute each assembled database transaction sequentially according to the execution order.

[0084] Optionally, the execution module 305 is specifically configured to sequentially determine, for each assembled database transaction, the partition to be operated on as the target partition based on the log records contained in the database transaction and the metadata of each partition in the database instance stored in the system tenant carried by the database node itself; and operate on the data to be operated on for each log record in the target partition based on the log records contained in the database transaction.

[0085] Optionally, the execution module 305 is further configured to, for each log record contained in the database transaction, determine, based on the log record and the metadata of each partition in the database instance stored in the system tenant, whether operating on the data required by the log record in the target partition will cause a change in the metadata of at least one partition in the database instance; if so, update the metadata of each partition in the database instance stored in the system tenant carried by the database node itself.

[0086] Optionally, the execution module 305 is further configured to synchronize the updated metadata of each partition in the database instance to other database nodes used to store at least one partition of the database instance.

[0087] Optionally, the execution module 305 is specifically configured to, when it is necessary to add a partition in the database instance, determine the database node used to store the partition to be added as the target node, notify the target node to create and store the partition to be added and determine the log stream corresponding to the partition to be added, and update the metadata of each partition in the database instance stored in the system tenant carried by the database node itself; and / or, when it is necessary to delete a partition in the database instance, if none of the database transactions to be executed depend on the partition to be deleted, notify the database node storing the partition to be deleted to delete the partition to be deleted, and update the metadata of each partition in the database instance stored in the system tenant carried by the database node itself.

[0088] Optionally, the acquisition module 301 is specifically used for the database node to acquire the log stream generated by the coordinator in its distributed database system via Remote Procedure Call (RPC).

[0089] Optionally, the acquisition module 301 is specifically used to acquire the log stream generated and distributed by the coordinator according to the received SQL statement; and / or to acquire the database transaction containing several log records stored by the coordinator in a preset multi-source transaction cache, wherein the database transaction stored in the multi-source transaction cache contains at least the log record corresponding to the Data Definition Language (DDL) operation.

[0090] This specification also provides a computer-readable storage medium storing a computer program that, when executed by a processor, can be used to perform the database transaction execution method described above.

[0091] based on Figure 1 The database transaction execution method shown in this specification is further illustrated in the embodiments. Figure 4 The diagram shows the structure of the electronic device. Figure 4 At the hardware level, the electronic device includes a processor, internal bus, network interface, memory, and non-volatile storage, and may also include other hardware required for business operations. The processor reads the corresponding computer program from the non-volatile storage into memory and then runs it to implement the database transaction execution method described above.

[0092] The above description is merely an embodiment of this specification and is not intended to limit this specification. Various modifications and variations can be made to this specification by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this specification should be included within the scope of the claims of this specification.

Claims

1. A method for executing a database transaction, the method comprising: Database nodes obtain log streams generated by the coordinator in their distributed database system, where the log streams correspond to two or more partitions in the same database instance stored in the distributed database system. Among the log records contained in the log stream, the log records of the partition to be operated on are those of the partition stored by the database node itself, and these are used as the target log records. Assemble database transactions based on the selected target log records; Determine the execution order of the assembled database transactions; The assembled database transactions are executed sequentially according to the execution order described.

2. The method as described in claim 1, wherein the assembled database transactions are executed sequentially, specifically including: For each assembled database transaction, the partition for which the operation is required to be performed is determined based on the log records contained in the database transaction and the metadata of each partition in the database instance stored in the system tenant carried by the database node itself, and is taken as the target partition. Based on the log records contained in the database transaction, operate on the data required for each log record in the target partition.

3. The method of claim 2, further comprising: For each log record contained in the database transaction, based on the log record and the metadata of each partition in the database instance stored in the system tenant, it is determined whether operating on the data required by the log record in the target partition will cause changes to the metadata of at least one partition in the database instance. If so, update the metadata of each partition in the database instance stored in the system tenant carried by the database node itself.

4. The method of claim 3, further comprising: The updated metadata of each partition in the database instance is synchronized to other database nodes used to store at least one partition of the database instance.

5. The method as described in claim 3, wherein updating the metadata of each partition in the database instance stored in the system tenant hosted by the database node itself, specifically includes: When it is necessary to add a partition in the database instance, the database node to be used to store the partition to be added is determined as the target node. The target node is notified to create and store the partition to be added and to determine the log stream corresponding to the partition to be added. The metadata of each partition in the database instance stored in the system tenant carried by the database node itself is updated. and / or When it is necessary to delete a partition in the database instance, if none of the database transactions to be executed depend on the partition to be deleted, the database node storing the partition to be deleted is notified to delete the partition to be deleted, and the metadata of each partition in the database instance stored in the system tenant carried by the database node itself is updated.

6. The method as described in claim 1, wherein the database node obtains the log stream generated by the coordinator in its distributed database system, specifically including: Database nodes obtain log streams generated by the coordinator in their distributed database system via Remote Procedure Call (RPC).

7. The method as described in claim 6, specifically including: obtaining the log stream generated by the coordinator in the distributed database system in which it resides, further comprising: Obtain the log stream generated and distributed by the coordinator based on the received SQL statements; and / or The coordinator retrieves a database transaction containing several log records stored in a preset multi-source transaction cache. The database transactions stored in the multi-source transaction cache contain at least log records corresponding to Data Definition Language (DDL) operations.

8. A database transaction execution apparatus, the apparatus comprising: The acquisition module is used to acquire the log stream generated by the coordinator in the distributed database system in which the device itself resides, wherein the log stream corresponds to two or more partitions in the same database instance stored in the distributed database system; The filtering module is used to filter log records from the log records contained in the log stream that are partitions stored by the device itself and are the partitions to be operated on, as the target log records. The assembly module is used to assemble database transactions based on the selected target log records. The sequencing module is used to determine the execution order of the assembled database transactions; The execution module is used to execute the assembled database transactions sequentially according to the execution order.

9. A computer-readable storage medium storing a computer program that, when executed by a processor, implements the method described in any one of claims 1-7.

10. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the program, implements the method described in any one of claims 1-7.

Images