A method, apparatus, device and medium for processing cross-engine transactions

Abstract

The application discloses a processing method of cross-engine transactions, which can be applied to a database system, the database system can at least include a first database engine and a second database engine, and the method comprises the following steps: acquiring timing information, the timing information can indicate that a first sub-transaction of a first cross-engine transaction is not later than a first sub-transaction of a second cross-engine transaction in performing a target operation, the target operation can be accessing data in the first database engine, and according to the acquired timing information, it can be determined that data first accessed by a second sub-transaction of the first cross-engine transaction in the second database engine is not later than data first accessed by a second sub-transaction of the second cross-engine transaction in the second database engine in timing, so that the data accessed by the two cross-engine transactions is consistent in timing. In addition, the application also discloses a processing device, equipment and medium of cross-engine transactions.

Description

Technical Field

[0001] The present application relates to the field of database technology, and in particular to a method, apparatus, device, and medium for processing cross-engine transactions. Background Art

[0002] Currently, mainstream database engines are categorized as main-memory engines and disk-based engines, each suited to different user scenarios. When a transaction accesses data in only one engine, the transaction's atomicity, consistency, isolation, and durability (ACID) properties can be achieved.

[0003] However, due to the often complex and ever-changing nature of user scenarios, it's inevitable that a single transaction may need to access data from two different engines. This type of transaction is often referred to as a cross-container transaction. When multiple cross-engine transactions access data from two database engines during the same time period, the data accessed by the two cross-engine transactions may become inconsistent in timing. Summary of the Invention

[0004] Embodiments of the present application provide a method, apparatus, device, and medium for processing cross-engine transactions, so that data accessed by multiple cross-engine transactions in two engines remains consistent in timing.

[0005] In a first aspect, an embodiment of the present application provides a method for processing cross-engine transactions, which can be applied to a database system, which may include at least a first database engine and a second database engine. The method may include: first obtaining timing information, which timing information may indicate that a first sub-transaction of a first cross-engine transaction executes a target operation no later than a first sub-transaction of a second cross-engine transaction, where the executed target operation may be, for example, accessing data in the first database engine; then, based on the obtained timing information, it may be determined that the data first accessed by the second sub-transaction of the first cross-engine transaction in the second database engine is no later in timing than the data first accessed by the second sub-transaction of the second cross-engine transaction in the second database engine.

[0006] The first database engine and the second database engine can be two different database engines, for example, the first database engine can be an in-memory database engine, and the second database engine can be a disk database engine, etc. Alternatively, the first database engine and the second database engine can be different database engines of the same type, for example, the first database engine and the second database engine are both in-memory database engines, etc.

[0007] Since the data accessed by the first cross-engine transaction in the two database engines is not later than the data accessed by the second cross-engine transaction in the two database engines in terms of time sequence, the data accessed by the two cross-engine transactions in the two database engines is consistent in terms of time sequence, thereby avoiding the "skewed snapshot" phenomenon of the data accessed by the two cross-engine transactions in terms of time sequence, so that the isolation level of the cross-engine transaction is not affected by the "skewed snapshot" phenomenon. Accordingly, the cross-engine transaction in the database system can achieve an isolation level higher than RC, such as RR, SI, and Serializable. Of course, the database system can also be applicable to the RC isolation level, so that the database system can provide global transaction isolation level services. In addition, from the user side, the cross-engine transaction can be executed by the database service side as a single-engine transaction, which ensures that there is no two different isolation levels in a cross-engine transaction, thereby ensuring the correct isolation level semantics.

[0008] In a first implementation manner of the first aspect, the time sequence information can be a time sequence value, so that the time sequence value can be used to determine which first sub-transaction of the cross-engine transaction accesses the first database engine first. For example, the time sequence value can be a log sequence number (LSN) value or a read view value. Generally, for the sub-transaction that accesses the first database engine first, the LSN value or the read view value corresponding to the data accessed by the sub-transaction can be smaller, and for the sub-transaction that accesses the first database engine later, the LSN value or the read view value corresponding to the data accessed by the sub-transaction can be larger. In this way, by comparing the values, it can be determined which first sub-transaction of the two cross-engine transactions accesses the data in the first database engine earlier in terms of time sequence.

[0009] For example, in a further possible implementation, the timing information can include a first timing value corresponding to data accessed by the first sub-transaction of the first cross-engine transaction in the first database engine, and a second timing value corresponding to data accessed by the first sub-transaction of the second cross-engine transaction in the first database engine. For the first timing value and the second timing value, the first timing value can be no greater than the second timing value, since the first sub-transaction of the first cross-engine transaction accesses data in the first database engine no later than the first sub-transaction of the second cross-engine transaction.

[0010] In the second implementation of the first aspect, when the second sub-transaction of the first cross-engine transaction accesses the second database engine before the second sub-transaction of the second cross-engine transaction accesses the second database engine, indicating that the second sub-transaction of the first cross-engine transaction is the first to access the second database engine, the timing value corresponding to data accessed by the second sub-transaction of the first cross-engine transaction in the second database engine can be the current timing value in the second database engine. In this way, even if the second sub-transaction of the second cross-engine transaction also accesses the second database engine, and the timing value corresponding to the accessed data is the timing value corresponding to the second database engine when accessed, the data accessed by the two cross-engine transactions in the two database engines will not have a "skewed snapshot" phenomenon in the end.

[0011] When the second sub-transaction of the second cross-engine transaction has accessed the second database engine before the second sub-transaction of the first cross-engine transaction accesses the second database engine, indicating that the second sub-transaction of the second cross-engine transaction has accessed the second database engine before the second sub-transaction of the first cross-engine transaction, in order to avoid a "skewed snapshot" phenomenon, the timing value corresponding to data accessed by the second sub-transaction of the first cross-engine transaction in the second database engine can be no greater than the timing value corresponding to data accessed by the second sub-transaction of the second cross-engine transaction in the second database engine. In this way, the data accessed by the first cross-engine transaction in the two database engines is ultimately no later than the data accessed by the second cross-engine transaction in the two database engines in terms of timing, thereby ensuring that the data accessed by different cross-engine transactions in the two cross-engine transactions is consistent in terms of timing.

[0012] In a second aspect, the embodiments of the present application further provide another method for processing cross-engine transactions. The method can be applied to a database system, which can include at least a first database engine and a second database engine. The method can include: obtaining timing information, which can indicate that a first sub-transaction of a first cross-engine transaction is not later than a first sub-transaction of a second cross-engine transaction in performing a target operation, for example, committing a transaction in the first database engine; and determining, according to the timing information, that a second sub-transaction of the first cross-engine transaction is not later than a second sub-transaction of the second cross-engine transaction in committing a transaction in the second database engine.

[0013] The first database engine and the second database engine can be two different database engines, for example, the first database engine can be an in-memory database engine, and the second database engine can be a disk database engine, etc. Alternatively, the first database engine and the second database engine can be different database engines of the same type, for example, the first database engine and the second database engine can both be in-memory database engines, etc.

[0014] Because the order of committing the first sub-transaction and the second sub-transaction of the first cross-engine transaction in the two database engines is not later than the order of committing the first sub-transaction and the second sub-transaction of the second cross-engine transaction in the two database engines, respectively, the order of committing the two sub-transactions of the first cross-engine transaction and the two sub-transactions of the second cross-engine transaction in the two database engines is consistent, thereby avoiding the phenomenon of “skewed commit” when the first cross-engine transaction and the second cross-engine transaction commit transactions.

[0015] In a first implementation of the second aspect, the timing information can include a first transaction commit sequence number of a first sub-transaction of the first cross-engine transaction committing a transaction in the first database engine, and a second transaction commit sequence number of a second sub-transaction of the second cross-engine transaction committing a transaction in the first database engine. A smaller value of the transaction commit sequence number can represent an earlier transaction commit in the database engine. When it is determined that the first transaction commit sequence number has a smaller value than the second transaction commit sequence number, and the second sub-transaction of the second cross-engine transaction has already committed a transaction in the second database engine, it is represented that the first sub-transaction of the first cross-engine commits a transaction earlier than the first sub-transaction of the second cross-engine transaction, but the second sub-transaction of the first cross-engine commits a transaction later than the second sub-transaction of the second cross-engine. At this time, in order to ensure that the two sub-transactions of the two cross-engine transactions remain consistent in the timing of committing a transaction, the second sub-transaction of the second cross-engine transaction can be rolled back, and the second sub-transaction of the first cross-engine and the second sub-transaction of the second cross-engine can be sequentially committed. In this way, the two sub-transactions of the first cross-engine commit a transaction no later than the two sub-transactions of the second cross-engine, thereby avoiding the "skewed commit" phenomenon.

[0016] In the first implementation of the second aspect, in a second implementation of the second aspect, the first log corresponding to the first sub-transaction of the second cross-engine transaction can include a transaction commit sequence number or an identifier of the second sub-transaction of the second cross-engine transaction. In this way, based on the transaction commit sequence number or the identifier, the second sub-transaction in the second database engine can be quickly located, so that when the second sub-transaction of the second cross-engine transaction is rolled back, the second sub-transaction of the second cross-engine transaction can be rolled back according to the transaction commit sequence number or the identifier of the second sub-transaction of the second cross-engine transaction included in the first log.

[0017] In a third aspect, the present application provides a processing apparatus for cross-engine transactions, the processing apparatus comprising various modules for executing the processing method for cross-engine transactions in the first aspect or any possible implementation of the first aspect.

[0018] In a fourth aspect, the present application provides a processing apparatus for cross-engine transactions, the processing apparatus comprising various modules for executing the processing method for cross-engine transactions in the second aspect or any possible implementation of the second aspect.

[0019] In a fifth aspect, the present application provides a computer comprising a processor and a memory. The processor and the memory are in communication with each other. The processor is configured to execute instructions stored in the memory to execute the processing method for cross-engine transactions in the first aspect or any implementation of the first aspect.

[0020] In a sixth aspect, the present application provides a computer comprising a processor and a memory. The processor and the memory communicate with each other. The processor is configured to execute instructions stored in the memory to perform the method for processing cross-engine transactions as described in the second aspect or any implementation of the second aspect.

[0021] In the seventh aspect, the present application provides a computer-readable storage medium, which stores instructions. When the computer-readable storage medium is run on a computer, it enables the computer to execute the cross-engine transaction processing method in the above-mentioned first aspect or any implementation of the first aspect.

[0022] In an eighth aspect, the present application provides a computer-readable storage medium, which stores instructions. When the computer-readable storage medium is run on a computer, it enables the computer to execute the cross-engine transaction processing method in the above-mentioned second aspect or any implementation of the second aspect.

[0023] In a ninth aspect, the present application provides a computer program product comprising instructions, which, when executed on a computer, enables the computer to execute the method for processing cross-engine transactions in the first aspect or any one of the implementations of the first aspect.

[0024] In a tenth aspect, the present application provides a computer program product comprising instructions, which, when executed on a computer, enables the computer to execute the method for processing cross-engine transactions in the above-mentioned second aspect or any one of the implementations of the second aspect.

[0025] Based on the implementation methods provided in the above aspects, this application can also be further combined to provide more implementation methods. BRIEF DESCRIPTION OF THE DRAWINGS

[0026] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments recorded in the present application. For ordinary technicians in this field, other drawings can also be obtained based on these drawings.

[0027] Figure 1 Schematic diagram of two cross-engine transactions T0 and T1 accessing two database engines;

[0028] Figure 2 This figure shows the "skewed snapshot" phenomenon in the data accessed by the two cross-engine transactions T0 and T1.

[0029] Figure 3A schematic diagram of data accessed by two cross-engine transactions T0 and T1 after the "skewed snapshot" problem is avoided in an embodiment of the present application;

[0030] Figure 4 A schematic diagram of an architecture of an exemplary database system in an embodiment of the present application;

[0031] Figure 5 A flowchart of a processing method of a cross-engine transaction in an embodiment of the present application;

[0032] Figure 6 A flowchart of another processing method of a cross-engine transaction in an embodiment of the present application;

[0033] Figure 7 A schematic diagram of an exemplary log structure;

[0034] Figure 8 A schematic diagram of a processing apparatus of a cross-engine transaction in an embodiment of the present application;

[0035] Figure 9 A schematic diagram of another processing apparatus of a cross-engine transaction in an embodiment of the present application;

[0036] Figure 10 A schematic diagram of a computer in an embodiment of the present application;

[0037] Figure 11 A schematic diagram of another computer in an embodiment of the present application. DETAILED DESCRIPTION

[0038] A transaction refers to a program execution unit that accesses and possibly updates various data items in a database. Threads in a database system can access and / or update data in the database when executing the transaction.

[0039] At present, two database engines can exist in a database system simultaneously, and the database system can include a main-memory engine and a disk-based engine simultaneously. A user side does not need to perceive which database engine is accessed by a transaction when operating the transaction and accessing data in the database system, while at a database service side, a transaction accessing a database engine can include the following three kinds:

[0040] The first kind is a transaction that only accesses data in the main-memory engine;

[0041] The second kind is a transaction that only accesses data in the disk-based engine;

[0042] The third kind is a transaction that accesses data in both the in-memory database engine and the disk database engine.

[0043] The first and second kinds of transactions can be generally referred to as single-engine transactions (single-engine transaction or single-side transaction), and the third kind can be generally referred to as a cross-container transaction.

[0044] For single-engine transactions, the ACID properties of database transactions can be implemented, but in many practical application scenarios, cross-engine transactions that need to access both the in-memory database engine and the disk database engine will inevitably occur. When the isolation level of a transaction (i.e., the degree of isolation of a single transaction from resource or data changes made by other transactions) is set to RC (Read Committed, i.e., reading already committed data, allowing non-repeatable reads) on the user side, if the cross-engine transaction accesses the database engine in the database system, the database service side will return an error to the user side. To solve this problem, the user side usually needs to add a hint or set a system variable to improve the isolation level of the sub-transaction of the cross-engine transaction accessing the in-memory database engine to SI (Snapshot Isolation), while the isolation level of the sub-transaction of the cross-engine transaction accessing the disk database engine remains RC. This is equivalent to having two different isolation levels in a cross-engine transaction, which cannot be consistent with the RC isolation level set by the user side, i.e., cannot guarantee the correct isolation level semantics, and the user side needs to modify the database (such as SQL) standard statement or set the system variable to provide normal service to avoid database service side errors, which cannot be achieved without the user side being aware. The sub-transaction of the cross-engine transaction refers to the transaction created in the database engine when the cross-engine transaction accesses different database engines.

[0045] In addition, when multiple cross-engine transactions access both database engines of the database system, the time sequence inconsistency problem of the data accessed by multiple cross-engine transactions in the two database engines may occur, for example, the data accessed by cross-engine transaction 1 in the in-memory database engine is newer than the data accessed by cross-engine transaction 2 in the in-memory database engine, but the data accessed by cross-engine transaction 1 in the disk database engine is older than the data accessed by cross-engine transaction 2 in the disk database engine.

[0046] The following is an example (assuming that the transaction isolation level set on the user side is RC):

[0047] Referring to Figure 1At time-A, a cross-engine transaction T0 accesses data in the in-memory database engine, and the current log sequence number (LSN) in the in-memory database engine is 10. The cross-engine transaction T0 accesses data corresponding to the LSN 10 in the in-memory database engine.

[0048] At time-B, a single-engine transaction accesses and updates data in the in-memory database engine, and the LSN in the in-memory database engine is advanced from 10 to 100.

[0049] At time-C, a cross-engine transaction T1 accesses data in the in-memory database engine and data in the disk database engine, and T1 accesses data corresponding to the LSN 100 in the in-memory database engine and data corresponding to the LSN 1000 in the disk database engine.

[0050] At time-D, another single-engine transaction accesses and updates data in the in-memory database engine, and the LSN in the in-memory database engine is advanced from 100 to 200.

[0051] At time-E, still another single-engine transaction accesses and updates data in the disk database engine, and the LSN in the disk database engine is advanced from 1000 to 2000. At this time, T0 does not access data in the disk database engine.

[0052] At time-F, T0 accesses data in the disk database engine, and the accessed data is data corresponding to the LSN 2000 in the disk database engine. Then, the data finally accessed by T0 is data corresponding to (2000, 10), i.e., data corresponding to the LSN 2000 in the disk database engine and data corresponding to the LSN 10 in the in-memory database engine; the data finally accessed by T1 is data corresponding to (1000, 100), i.e., data corresponding to the LSN 1000 in the disk database engine and data corresponding to the LSN 100 in the in-memory database engine. That is, in the disk database engine, the data accessed by T0 is newer than the data accessed by T1 (i.e., 2000>1000), and in the in-memory database engine, the data accessed by T0 is older than the data accessed by T1 (i.e., 10<100), as shown in the following table: Figure 2As shown, the time series consistency of the data accessed by the cross-engine transactions T0 and T1 in the two engines is inconsistent. This phenomenon can be referred to as a "skewed snapshot" phenomenon. From the user side, the existence of the "skewed snapshot" phenomenon causes some of the data accessed by T0 to be more updated than the corresponding part of the data accessed by T1, while at the same time, another part of the data accessed by T0 is older than the corresponding part of the data accessed by T1, so that the data accessed by the two cross-engine transactions T0 and T1 does not satisfy the serialization time series, which makes the isolation level of the transaction cannot be higher than RC, such as the isolation level of the transaction cannot reach RR (Repeatable Read), SI, and Serializable.

[0053] If the user side is forced to set an isolation level higher than RC, the services that the database engine can provide are usually limited. For example, when the user side sets the RR isolation level, the in-memory database engine can only provide insert operations for cross-engine transactions, and cannot provide select operations and other operations; when the user side sets the SI isolation level, the entire in-memory database engine cannot provide services for cross-engine transactions; when the user side sets the Serializable isolation level, the in-memory database engine and the disk database engine cannot provide services for cross-engine transactions.

[0054] At the same time, when there are multiple cross-engine transactions in the two engines, the "skewed commit" phenomenon can also occur, that is, the time series inconsistency of the commit of the sub-transactions of multiple cross-engine transactions in the two database engines. For example, the commit time of the sub-transaction of T0 in the in-memory database engine can be earlier than the commit time of the sub-transaction of T1 in the in-memory database engine, but due to contention or scheduling, etc., the commit time of the sub-transaction of T0 in the disk database engine can be later than the commit time of the sub-transaction of T1 in the disk database engine.

[0055] Based on this, an embodiment of the present application provides a method for processing cross-engine transactions, which can at least ensure that the timing of the data accessed by the cross-engine transactions T0 and T1 in the two database engines is consistent. Specifically, the order in which the first sub-transaction of T0 and the first sub-transaction of T1 access data in the memory database engine (or disk database engine) can be determined first. Taking the case where the first sub-transaction of T0 first accesses data in the memory database engine as an example, at this time, it can be determined that the data first accessed by the second sub-transaction of T0 in the disk database engine (or memory database engine) is not later than the data first accessed by the second sub-transaction of T1 in the disk database engine (or memory database engine) in terms of timing. In this way, for the data accessed in the memory database engine, T0 is not later than T1 in terms of timing. At the same time, for the data accessed in the disk database engine, T0 is not later than T1 in terms of timing, thereby achieving consistency in the timing of the data accessed by the cross-engine transactions T0 and T1 in the two database engines, avoiding the "skewed snapshot" phenomenon.

[0056] For example, the time series of data accessed by T0 and T1 in two database engines can be as follows: Figure 3 As shown, in the in-memory database engine, the data accessed by T1 is newer than the data accessed by T0 (i.e., 10<100). At the same time, in the disk database engine, the data accessed by T1 is the same as the data accessed by T0 (i.e., the LSN is 1000) and is no older than the data accessed by T0.

[0057] This allows cross-engine transactions to maintain isolation levels unaffected by the "skewed snapshot" phenomenon, achieving isolation levels such as RR (Repeatable Read), SI, and Serializable. Furthermore, since cross-engine transactions T0 and T1 maintain consistent timing when accessing data or committing transactions in the two database engines, from the user's perspective, cross-engine transactions executed by the database server behave like single-engine transactions. This prevents the existence of two different isolation levels within a single cross-engine transaction, ensuring correct isolation level semantics. Furthermore, the user does not need to add hints or set system variables to enable cross-engine transactions to access two different database engines. Furthermore, the database server will not return errors to the user, allowing different global transaction isolation levels to be provided without the user's awareness.

[0058] At the same time, the embodiment of the present application also provides a method for processing cross-engine transactions, which can at least ensure that the timing of cross-engine transactions T0 and T1 submitting transactions in the two database engines remains consistent. Specifically, the order in which the first sub-transaction of T0 and the first sub-transaction of T1 submit transactions in the memory database engine (or disk database engine) can be determined first. Taking the first sub-transaction of T0 submitting transactions first in the memory database engine as an example, at this time, it can be determined that the second sub-transaction of T0 submits transactions in the disk database engine no later than the second sub-transaction of T1. In this way, for submitting transactions in the memory database engine, T0 is not later than T1 in timing. At the same time, for submitting transactions in the disk database engine, T0 is not later than T1 in timing, thereby achieving consistency in the timing of cross-engine transactions T0 and T1 submitting transactions in the two database engines, avoiding the "skewed commit" phenomenon.

[0059] To make the above-mentioned purposes, features, and advantages of the present application more clearly understood, various non-limiting embodiments of the embodiments of the present application will be exemplified below with reference to the accompanying drawings. Obviously, the described embodiments are only some of the embodiments of the present application, not all of them. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0060] The terms "first," "second," and the like in the specification and claims of this application and the accompanying drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or precedence. It should be understood that the terms used in this manner are interchangeable where appropriate and are merely used to describe the manner in which objects with the same attributes are described in the embodiments of this application.

[0061] First, see Figure 4 The structural diagram of an exemplary database system is shown. The database system may include an SQL (structured query language) layer and a storage engine layer. The storage engine layer may include at least two database engines, hereinafter referred to as a first database engine and a second database engine. Each database engine may support transactions to access data or submit transactions in the database engine. When the SQL layer transmits a cross-engine transaction, the storage engine layer may generate two transactions for the two database engines respectively for the cross-engine transaction, and each generated transaction is used to access its corresponding database engine. For ease of description, the transaction generated when the cross-engine transaction accesses the first database engine is referred to as a first sub-transaction, and the transaction generated when accessing the second database engine is referred to as a second sub-transaction.

[0062] The first database engine and / or the second database engine may include a processing module. Figure 4 Taking the configuration of a processing module in the second database engine as an example, the processing module can be used to manage the data accessed by the second sub-transactions of multiple cross-engine transactions in the second database engine, so as to maintain consistency in the timing of the data accessed by the first sub-transactions of the multiple cross-engine transactions in the first database engine, and / or to manage the timing of transaction submissions by the second sub-transactions of the multiple cross-engine transactions in the second database engine, so as to maintain consistency in the timing of transaction submissions by the first sub-transactions of the multiple cross-engine transactions in the first database engine. Exemplarily, the processing module can be implemented as a thread for executing the second sub-transactions.

[0063] Specifically, when the first subtransaction of the first cross-engine transaction and the first subtransaction of the second cross-engine transaction access the first database engine successively in the first database engine, the processing module in the second database engine can use the timing information of the two first subtransactions accessing the first database engine, and determine the timing of the data accessed by the second subtransaction of the first cross-engine transaction and the second subtransaction of the second cross-engine transaction in the second database engine based on the timing information, so that the data accessed by the first cross-engine transaction and the second cross-engine transaction in the two database engines remain consistent in timing.

[0064] In addition, the processing module can also obtain the timing information of the two first sub-transactions submitting transactions in the first database engine, and determine the timing of the second sub-transaction of the first cross-engine transaction and the second sub-transaction of the second cross-engine transaction submitting transactions in the second database engine based on the timing information, so that the timing of the first cross-engine transaction and the second cross-engine transaction submitting transactions in the two database engines remains consistent.

[0065] certainly, Figure 4 The database system shown is only an exemplary illustration and is not intended to limit the architecture of the database system to which the embodiments of the present application can be applied. For example, in other possible database systems, more than three (including three) database engines may be included; or, each database engine may be configured with multiple processing modules, and different processing modules are used to implement different functions, for example, one processing module is used to control the timing of data accessed by a sub-transaction, and another processing module is used to control the timing of transaction submission, etc.; or, the processing module may also be deployed independently of the database engine, etc. In short, the embodiments of the present application can be applied to any applicable scenario.

[0066] Next, we describe in detail how the processing module handles cross-engine transactions:

[0067] See Figure 5 , Figure 5The flowchart of a method for processing cross-engine transactions in an embodiment of the present application is shown. The first cross-engine transaction in this embodiment may be, for example, the above-mentioned T0, and the second cross-engine transaction may be, for example, the above-mentioned T1. The method for processing cross-engine transactions may be applied to a database system, and the database system includes at least a first database engine and a second database engine, for example, Figure 5 In this embodiment, how the processing module manages the timing of the data accessed by the second sub-transaction of two cross-engine transactions in the second database engine will be specifically described. The method may specifically include:

[0068] S501: The processing module obtains timing information of a first sub-transaction of a first cross-engine transaction and a first sub-transaction of a second cross-engine transaction respectively executing a target operation, wherein the target operation includes accessing data in a first database engine.

[0069] In this embodiment, the first database engine and the second database engine in the database system can be any two database engines currently available or potentially available in the future. For example, the first database engine and the second database engine can be two different database engines, such as an in-memory database engine and a disk-based database engine, respectively. Alternatively, they can be the same type of database engine, such as both in-memory database engines, both disk-based database engines, or other types of database engines.

[0070] Different database engines can be used to store different data. In this way, when the user side needs to access data stored in different database engines, a cross-engine transaction can be generated. For example, the first database engine of the database system can store the employment information of "Zhang San", and the second database engine can store the past educational experience information of "Zhang San". The client on the user side can send a request to the database system to obtain all relevant information of "Zhang San", that is, to generate a cross-engine transaction that needs to access the two database engines at the same time, for accessing all relevant information of "Zhang San" stored in the two database engines. Exemplarily, accessing data in a database engine can, for example, be any one or more of the following operations on the data in the database engine: query (select), update (update), insert (insert), delete (delete) data, etc.

[0071] For a cross-engine transaction, the database system may create a first sub-transaction and a second sub-transaction for it, respectively. The first sub-transaction is used to access the first database engine, and the second sub-transaction is used to access the second database engine.

[0072] When multiple cross-engine transactions access two database engines within the same time period, the data accessed by these transactions in the two database engines may be inconsistent in timing. This embodiment uses the example of a first cross-engine transaction and a second cross-engine transaction accessing two database engines simultaneously to illustrate a technical solution to this problem.

[0073] The processing module can obtain the timing information of the first sub-transaction of the first cross-engine transaction and the first sub-transaction of the second cross-engine transaction executing the target operation. The timing information can indicate which cross-engine transaction's first sub-transaction executes the target operation first, so that the order in which the two sub-transactions execute the target operations can be determined based on the timing information.

[0074] In this embodiment, the target operation may specifically be an operation of accessing data in the first database engine. The above-mentioned timing information may not only indicate the order in which the first sub-transactions of different cross-engine transactions access the first database engine, but also indicate which first sub-transaction of a cross-engine transaction accesses newer data in the first database engine and which first sub-transaction of a cross-engine transaction accesses older data in the first database engine.

[0075] Regarding the timing information, in one example, it can specifically be a numerical value representing the data timing (hereinafter referred to as the timing value), and the magnitude of the timing values ​​corresponding to different first subtransactions can indicate the order in which the different first subtransactions access the first database engine. For example, the timing value can be a numerical value that increases over time, and a smaller timing value corresponding to a first subtransaction can indicate an earlier time at which the first subtransaction accessed the first database engine, while a larger timing value corresponding to the first subtransaction can indicate a later time at which the first subtransaction accessed the first database engine.

[0076] In an exemplary embodiment, the obtained timing information can be a log sequence number for the first database engine, such as the timing information can specifically include the log sequence number of the first subtransaction of the first cross-engine transaction executing the target operation (hereinafter referred to as the first log sequence number), and the log sequence number of the first subtransaction of the second cross-engine transaction executing the target operation (hereinafter referred to as the second log sequence number). In addition, the size of the log sequence number can indicate the order in which the target operations are executed for the first database engine. For example, when the value of the first log sequence number is less than the value corresponding to the second log sequence number, it can indicate that the first subtransaction of the first cross-engine transaction executes the target operation before the first subtransaction of the second cross-engine transaction; conversely, when the value of the first log sequence number is greater than the value corresponding to the second log sequence number, it can indicate that the first subtransaction of the first cross-engine transaction executes the target operation later than the first subtransaction of the second cross-engine transaction; of course, when the value of the first log sequence number is equal to the value of the second log sequence number, it indicates that the first subtransaction of the first cross-engine transaction and the first subtransaction of the second cross-engine transaction execute the target operation at the same time, or that the data accessed by the two first subtransactions in the first database engine are at the same time point.

[0077] Of course, in addition to the aforementioned log sequence number, the timing information can also be any other form of information representing the order in which target operations are executed by different transactions. For example, the timing information can also be a read view corresponding to the log sequence number, and the numerical value of the read view can also be similar to the log sequence number size, which can be used to indicate the order in which target operations are executed for the first database engine. For example, for the first transaction accessing the first database engine, an access sequence number of 1 can be added to it, and the second transaction accessing the first database engine can be added to it. Access sequence number 2 can be added to it, and so on. In this way, the order in which sub-transactions of different cross-engine transactions execute target operations can be determined based on the numerical value of the access sequence number (the smaller the value, the earlier the target operation is executed). The specific implementation method of the timing information is not limited in this embodiment.

[0078] S502: Based on the acquired timing information, the processing module determines that the data first accessed by the second subtransaction of the first cross-engine transaction in the second database engine is no later than the data first accessed by the second subtransaction of the second cross-engine transaction in the second database engine in terms of timing.

[0079] Since the acquired timing information indicates that the first sub-transaction of the first cross-engine transaction does not execute the target operation later than the first sub-transaction of the second cross-engine transaction, the data accessed by the first sub-transaction of the first cross-engine transaction in the first database engine is generally not later in timing than the data accessed by the first sub-transaction of the second cross-engine transaction in the first database engine. Therefore, in order to keep the data accessed by the two cross-engine transactions in the two database engines consistent in timing, the processing module can determine that the data first accessed by the second sub-transaction of the first cross-engine transaction in the second database engine also needs to be no later than the data first accessed by the second sub-transaction of the second cross-engine transaction in the second database engine. In this way, when the first cross-engine transaction and the second cross-engine transaction access the data in the two database engines, the problem of inconsistency in timing of the data accessed by the two cross-engine transactions can be avoided, and the phenomenon of “skewed snapshot” can also be avoided. In this way, the isolation level of the cross-engine transaction can not be affected by the phenomenon of “skewed commit”, so that a transaction isolation level higher than RC (such as RR, SI, Serializable, etc.) can be achieved. Of course, the embodiment can also be applicable to the RC transaction isolation level.

[0080] In an exemplary specific embodiment, a global timing table can be established to record the timing values of the data accessed by the sub-transactions in the database engine. For ease of understanding, the timing value is specifically taken as the value of read view in the following exemplary description. A global readview table can be established for the first database engine and the second database engine. When a sub-transaction accesses data in the database engine, the value of the read view corresponding to the data accessed by the sub-transaction can be recorded in the table.

[0081] When the first sub-transaction of the first cross-engine transaction accesses the first database engine, the first timing value (the value of read view-1) in the first database engine can be acquired, which can be 10 for example, and recorded in the read view table. The data accessed by the first sub-transaction of the first cross-engine transaction is the data corresponding to read view-1. Then, when the first sub-transaction of the second cross-engine transaction accesses the first database engine, the second timing value (the value of read view-2) in the first database engine can be acquired, which can be 100 for example (for example, one or more single-engine transactions can push the value of read view from 10 to 100 before the first sub-transaction accesses the first database engine), and recorded in the read view table. At this time, the global readview table can be as shown in Table 1 below:

[0082] Table 1

[0083]

[0084]

[0085] "NA" indicates that the read view value is empty, indicating that the read view values ​​accessed by the second subtransaction of the first cross-engine transaction and the second subtransaction of the second cross-engine transaction are unknown (for example, the second subtransaction has not yet accessed the second database engine). Therefore, because the value of read view-1 (10) recorded in the read view table is less than the value of read view-2 (100), it can be determined that the first subtransaction of the first cross-engine transaction first accessed data in the first database engine.

[0086] Then, when the second subtransaction of the first cross-engine transaction accesses the second database engine, if the second subtransaction of the second cross-engine transaction does not access the second database engine, that is, the read view value corresponding to the second subtransaction of the second cross-engine transaction accessing the second database engine is not recorded in the read view table, this indicates that the second subtransaction of the first cross-engine transaction first accessed the data in the second database engine. In this case, the timing value corresponding to the data accessed by the second subtransaction of the first cross-engine transaction in the second database engine (hereinafter referred to as the third timing value) can be the current timing value in the second database engine. When the second subtransaction of the second cross-engine transaction subsequently accesses the second database engine, the timing value corresponding to the data accessed by it in the second database engine (hereinafter referred to as the fourth timing value) can be the timing value in the second database engine at the time of its access. In this case, the data accessed by the first cross-engine transaction and the second cross-engine transaction in the two engines generally do not experience the "skewed snapshot" phenomenon.

[0087] However, when the second subtransaction of the first cross-engine transaction accesses the second database engine, if the second subtransaction of the second cross-engine transaction has already accessed the second database engine, and the read view table already contains the fourth timing value (read view-3) corresponding to the second subtransaction of the second cross-engine transaction accessing the second database engine, assuming that the value of readview-3 is 1000, then the read view table may be as shown in Table 2 below:

[0088] Table 2

[0089]

[0090] Before the second sub-transaction of the first cross-engine transaction accesses the second database engine, if other single-engine transactions promote the read view in the second database engine from read view-3 to read view-4 (the value of which is greater than the value of read view-3, such as 2000), and if the data corresponding to read view-4 is accessed by the second sub-transaction of the first cross-engine transaction in the second database engine, a "skewed snapshot" phenomenon will occur. Therefore, in the case where the value of read view-1 (10) is less than the value of read view-2 (100), the processing module can determine that the third time sequence value corresponding to the second sub-transaction of the first cross-engine transaction when accessing the second database engine is not greater than the fourth time sequence value (the value of read view-3), such as the third time sequence value being equal to the value of read view-3, and records it in the read view table. At this time, the read view table can be as shown in Table 3:

[0091] Table 3

[0092]

[0093] As can be seen from Table 3, not only is the data accessed by the first sub-transaction of the second cross-engine transaction in the first database engine newer (the value of read view is greater) than the data accessed by the first sub-transaction of the first cross-engine transaction in the first database engine, but also the data accessed by the second sub-transaction of the second cross-engine transaction in the second database engine is not older (the value of read view is equal) than the data accessed by the second sub-transaction of the first cross-engine transaction in the second database engine, thereby avoiding the "skewed snapshot" phenomenon.

[0094] It is worth noting that in the above embodiments, two cross-engine transactions are taken as an example, and the specific implementation of keeping the data accessed by the two cross-engine transactions in the two database engines consistent in time sequence is exemplarily illustrated. When there are more than three (including three) cross-engine transactions, for any one of the cross-engine transactions, when the first sub-transaction of the cross-engine transaction accesses the data in the first database engine, the data accessed by the first sub-transaction of the cross-engine transaction is the data corresponding to the current read view in the first database engine, and the read view corresponding to the first sub-transaction of the cross-engine transaction is recorded in the read view table, and when the second sub-transaction of the cross-engine transaction accesses the second database engine, in order to avoid the "skewedsnapshot" phenomenon between the data accessed by the cross-engine transaction and the data accessed by other cross-engine transactions, the read view corresponding to the data accessed by the second sub-transaction in the second database engine can be determined according to the following rules:

[0095] 1. If the read view values recorded in the read view table are all the read views corresponding to the data accessed by the multiple cross-engine transactions in the first database engine, it indicates that the cross-engine transaction currently accessing the second database engine is the first to access the second database engine among the multiple cross-engine transactions, and at this time, the read view corresponding to the data accessed by the second sub-transaction of the cross-engine transaction in the second database engine can be the current read view in the second database engine.

[0096] 2. If the read view values recorded in the read view table include the read views corresponding to the data accessed by the other one or more cross-engine transactions (hereinafter referred to as target cross-engine transactions) in the first database engine and the read views corresponding to the data accessed by the other one or more cross-engine transactions in the second database engine, at this time, it is necessary to keep the cross-engine transaction currently accessing the second database engine consistent with the target cross-engine transaction in time sequence of the accessed data, and therefore, it can be determined whether there is a read view corresponding to the data accessed by a certain target cross-engine transaction in the first database engine, which is greater than the read view corresponding to the data accessed by the cross-engine transaction in the first database engine, if yes, it indicates that the cross-engine transaction accesses the first database engine earlier than the target cross-engine transaction, so that the data accessed by the cross-engine transaction in the second database engine is not later than the data accessed by the target cross-engine transaction in the second database engine in time sequence, and accordingly, the read view corresponding to the data accessed by the second sub-transaction of the cross-engine transaction in the second database engine is the minimum value of the read views corresponding to the data accessed by the target cross-engine transactions in the second database engine.

[0097] 3. Based on the preceding 2, if there is no read view corresponding to the data accessed by the target cross-engine transaction in the first database engine, which is greater than the read view corresponding to the data accessed by the cross-engine transaction in the first database engine, but there is a read view corresponding to the data accessed by the target cross-engine transaction in the first database engine, which is less than the read view corresponding to the data accessed by the cross-engine transaction in the first database engine, it indicates that the cross-engine transaction is the last one to access the first database engine among the target cross-engine transactions, so the data accessed by the cross-engine transaction in the second database engine is not earlier in time sequence than the data accessed by the target cross-engine transaction in the second database engine, and accordingly, the read view corresponding to the data accessed by the second sub-transaction of the cross-engine transaction in the second database engine can be the current read view in the second database engine.

[0098] In the above embodiments, the time sequence value is taken as an example of the value of the read view, which is optional. The time sequence value can also be an LSN, and the specific implementation process of determining the time sequence of the data accessed by the second sub-transaction of the first cross-engine transaction and the second sub-transaction of the second cross-engine transaction in the second database engine using the LSN is similar to the above embodiments, and the difference is only that the global record table established is an LSN table for recording the LSN corresponding to the data accessed by the transaction in the database engine. The specific implementation process can be described with reference to the related description of the foregoing embodiments, which is not repeated here.

[0099] In an example, in addition to the above embodiment of establishing and maintaining a global read view table or LSN table for two database engines, a read view table or LSN table can also be established and maintained in each of the two database engines, and when the data corresponding to the cross-engine transaction recorded in the read view table or LSN table of one of the database engines is changed, it can be synchronized to the read view table or LSN table of the other database engine. Accordingly, when determining the read view or LSN corresponding to the data accessed by the sub-transactions of the two cross-engine transactions in the same database engine, the data recorded in the read view table or LSN table maintained in the database engine can be determined.

[0100] In the above embodiment, a processing module is introduced in which the processing module determines the timing of data accessed by the second sub-transactions of the two cross-engine transactions in the second database engine based on the timing of data accessed by the first sub-transactions of the two cross-engine transactions in the first database engine, so that the data ultimately accessed by the two cross-engine transactions remain consistent in timing, that is, the data accessed by one cross-engine transaction is no later than the data accessed by the other cross-engine transaction in timing, thereby avoiding the "skewed snapshot" phenomenon, and further, a transaction isolation level higher than RC, such as RR, SI, and Serializable, can be set on the user side.

[0101] In other embodiments, the processing module determines the timing of committing the second sub-transactions of the two cross-engine transactions in the second database engine based on the timing of committing the first sub-transactions of the two cross-engine transactions in the first database engine, so as to avoid the "skewed commit" phenomenon.

[0102] See Figure 6 , Figure 6 A flow chart of another cross-engine transaction processing method in an embodiment of the present application is shown. This cross-engine transaction processing method can also be applied to a database system, and the database system includes at least a first database engine and a second database engine. In this embodiment, how the processing module controls the timing of the second sub-transaction of two cross-engine transactions to submit transactions in the second database engine will be specifically described. The method may specifically include:

[0103] S601: The processing module obtains timing information of a first sub-transaction of a first cross-engine transaction and a first sub-transaction of a second cross-engine transaction respectively executing a target operation, wherein the target operation includes committing a transaction in a first database engine.

[0104] and Figure 5 Similar to the embodiment shown, in this embodiment, the first database engine and the second database engine in the database system can be any two database engines currently available or potentially available in the future. Furthermore, the first database engine and the second database engine can be different database engines or the same database engine, which is not limited in this embodiment.

[0105] The processing module can obtain timing information of the target operation executed by the first sub-transaction of the first cross-engine transaction and the first sub-transaction of the second cross-engine transaction. The timing information can indicate which cross-engine transaction's first sub-transaction executes the target operation first, thereby determining the order in which the two sub-transactions execute the target operations based on the timing information. The target operation can specifically be an operation of submitting a transaction in the first database engine.

[0106] In one example, the obtained timing information may be a transaction commit sequence number (commit LSN) for the first database engine. For example, the timing information may specifically include a transaction commit sequence number (hereinafter referred to as the first transaction commit sequence number) of a first subtransaction of a first cross-engine transaction submitted in the first database engine, and a transaction commit sequence number (hereinafter referred to as the second transaction commit sequence number) of a first subtransaction of a second cross-engine transaction submitted in the first database engine. Furthermore, the size of the transaction commit sequence number can indicate the order in which different transactions are submitted in the first database engine. For example, when the value of the first transaction commit sequence number is greater than the value corresponding to the second transaction commit sequence number, it can indicate that the first subtransaction of the first cross-engine transaction is submitted in the first database engine before the first subtransaction of the second cross-engine transaction; conversely, when the value of the first transaction commit sequence number is less than the value corresponding to the second transaction commit sequence number, it can indicate that the first subtransaction of the first cross-engine transaction is submitted in the first database engine later than the first subtransaction of the second cross-engine transaction; of course, when the value of the first log sequence number is equal to the value of the second log sequence number, it can indicate that the first subtransaction of the first cross-engine transaction and the first subtransaction of the second cross-engine transaction are submitted in the first database engine at the same time.

[0107] S602: Based on the acquired timing information, the processing module determines that the second sub-transaction of the first cross-engine transaction is committed in the second database engine no later than the second sub-transaction of the second cross-engine transaction.

[0108] Because the acquired timing information indicates that the first subtransaction of the first cross-engine transaction commits to the first database engine no later than the first subtransaction of the second cross-engine transaction, to ensure consistent timing when the two cross-engine transactions commit in the two database engines, it can be determined that the second subtransaction of the first cross-engine transaction commits to the second database engine no later than the second subtransaction of the second cross-engine transaction. This prevents inconsistent timing when the first and second cross-engine transactions commit in the two database engines, thus avoiding the "skewed commit" phenomenon.

[0109] In an exemplary embodiment, the timing information may specifically be a transaction commit sequence number when the transaction is committed in the database engine, and a global transaction commit record table may be established. When a subtransaction is committed in the database engine, the transaction commit sequence number of the subtransaction may be recorded in the table.

[0110] When the first sub-transaction of the first cross-engine transaction commits the transaction in the first database engine, the current transaction commit sequence number in the first database engine can be obtained as the first transaction commit sequence number corresponding to the first sub-transaction, which can be 200 for example, and recorded in the transaction commit sequence number table. Then, when the first sub-transaction of the second cross-engine transaction commits the transaction in the first database engine, the current transaction commit sequence number in the first database engine can be continuously obtained as the second transaction commit sequence number corresponding to the first sub-transaction of the second cross-engine transaction, which can be 300 for example, and recorded in the transaction commit sequence number table. At this time, the global transaction commit sequence number table can be as shown in Table 4:

[0111] Table 4

[0112]

[0113]

[0114] Wherein, “NA” indicates that the value of the transaction commit sequence number is empty, representing that the second sub-transaction of the first cross-engine transaction and the second sub-transaction of the second cross-engine transaction are unknown in the transaction commit sequence number of the second database engine at this time (i.e., have not committed the transaction in the second database engine).

[0115] Then, when the second sub-transaction of the first cross-engine transaction attempts to commit in the second database engine, if the second sub-transaction of the second cross-engine transaction has not committed the transaction in the second database engine, for example, when the transaction commit sequence number of the second sub-transaction of the second cross-engine transaction in the second database engine is not queried in the transaction commit sequence number table, it indicates that the second sub-transaction of the first cross-engine transaction will be prioritized to commit the transaction in the second database engine than the second sub-transaction of the second cross-engine transaction. At this time, the second sub-transaction of the first cross-engine transaction and the second sub-transaction of the second cross-engine transaction are committed in the second database engine in sequence, and the time sequence of committing the transaction in the two database engines of the first cross-engine transaction and the second cross-engine transaction remains consistent.

[0116] And if the second sub-transaction of the second cross-engine transaction is prioritized to complete the commit in the second database engine before the second sub-transaction of the first cross-engine transaction commits the transaction in the second database engine, for example, the transaction commit sequence number of the second sub-transaction of the second cross-engine transaction in the second database engine is queried in the transaction commit sequence number table, which is 200 as shown in Table 5:

[0117] Table 5

[0118]

[0119] At this time, if the second sub-transaction of the first cross-engine transaction continues to be committed in the second database engine, the transaction commit sequence number of the second sub-transaction in the second database engine will be greater than 2000, which is inconsistent with the order of the first sub-transactions of the two cross-engine transactions in the first database engine, i.e., a "skewed commit" phenomenon occurs.

[0120] To this end, in the embodiment, the processing module can roll back the second sub-transaction of the second cross-engine transaction which has been completed in the second database engine, and determine, according to the order of the first sub-transactions of the two cross-engine transactions in the first database engine, that the second sub-transaction of the first cross-engine transaction is prior to be committed in the second database engine, while the second sub-transaction of the second cross-engine transaction is committed later in the second database engine, or the two second sub-transactions are committed together in the second database engine, so that the time sequence of the transactions of the two cross-engine transactions in the two database engines is consistent. After the second sub-transactions of the two cross-engine transactions are committed in the second database engine, the global transaction commit sequence number table can be as shown in Table 6 (the second sub-transaction of the first cross-engine transaction is committed first) or Table 7 (the second sub-transactions of the two cross-engine transactions are committed together) below:

[0121] Table 6

[0122]

[0123]

[0124] Table 6

[0125]

[0126] Optionally, in the embodiment, the transaction commit sequence number table can also be established and maintained in the two database engines respectively, and when the data in the transaction commit sequence number table in one of the database engines is updated, the data can be synchronized to the transaction commit sequence number table in the other database engine. Further, the transaction commit sequence number table in the embodiment can be combined with the read view table (or LSN table) as described above into one table, as shown in Table 8 below:

[0127] Table 8

[0128]

[0129] As an example implementation of a rollback transaction, a transaction commit serial number of another sub-transaction of the cross-engine transaction or an identification of the another sub-transaction can be added in a log corresponding to one of the sub-transactions of the cross-engine transaction, so that based on the transaction commit serial number or the identification, the sub-transaction corresponding to the transaction commit serial number can be rolled back in the corresponding database engine. For example, when the first sub-transaction of the second cross-engine transaction is committed in the first database engine, a corresponding first log can be generated, and in particular, the first log can record a transaction commit serial number of the second sub-transaction of the second cross-engine transaction or an identification of the second sub-transaction (if the second sub-transaction of the second cross-engine transaction is not completed in the second database engine, the transaction commit serial number recorded in the first log can be empty or not recorded). When it is determined through the query of the transaction commit serial number table that the transaction commit order of the second cross-engine transaction in the two database engines does not satisfy the consistency requirement in time sequence with the transaction commit order of the first cross-engine transaction in the two database engines, it can be further determined that the second sub-transaction of the second cross-engine transaction needs to be rolled back. At this time, the second sub-transaction of the second cross-engine transaction corresponding to the transaction commit serial number or the identification recorded in the first log can be rolled back in the second database engine according to the transaction commit serial number or the identification, so that the second sub-transaction of the first cross-engine transaction and the second sub-transaction of the second cross-engine transaction are sequentially committed in the second database engine.

[0130] Correspondingly, when the second sub-transaction of the second cross-engine transaction is committed in the second database engine, a second log generated in the second database engine can record a transaction commit serial number of the first sub-transaction of the second cross-engine transaction committed in the first database engine. For example, the transaction commit serial number can be a transaction commit serial number obtained after the first sub-transaction of the second cross-engine transaction is successfully committed, or can be a transaction commit serial number allocated in advance for the first sub-transaction of the second cross-engine transaction, that is, at this time, the first sub-transaction of the second cross-engine transaction has not been truly committed (in a pre-commit state), and the first sub-transaction of the second cross-engine transaction can be committed in the first database engine based on the allocated transaction commit serial number (the first sub-transaction of each cross-engine transaction can be committed according to the allocated transaction commit serial number).

[0131] As Figure 7As shown, a field (such as other-engine-commit-lsn) can be added in the header of the log and defined to indicate the transaction commit sequence number or transaction identification of another sub-transaction of the cross-engine transaction in another database engine by using the added field. Wherein, "txn-id" is the identification of the current transaction, "begin-ts" indicates the timestamp of the beginning of the current transaction, "end-ts" indicates the timestamp of the end of the current transaction, "pointer" is the log version pointer, and "data" is the data recorded in the log.

[0132] If the field is an illegal value, it can be used to indicate that the current transaction is a single-engine transaction, rather than a sub-transaction of a cross-engine transaction. If the field is a valid value, it can be used to indicate the transaction commit sequence number or transaction identification of another sub-transaction of the cross-engine transaction in another database engine. If the field is "NA", it can indicate that another sub-transaction of the cross-engine transaction is committed in another database engine, or be used to indicate that the current transaction is a single-engine transaction.

[0133] Of course, Figure 7 Only the specific implementation of the transaction commit sequence number or transaction identification of the first log record is exemplarily described. In other possible implementations, an existing field in the first log can also be redefined to indicate the transaction commit sequence number or transaction identification. Alternatively, a field can be added or a field can be redefined at another position of the first log, and the present embodiment does not limit this.

[0134] When the cross-engine transaction is completed, the information about the cross-engine transaction in the global transaction commit sequence table (such as the tables shown in Tables 4 to 8) can be deleted. However, to avoid the cross-engine transaction and other cross-engine transactions being inconsistent in the time sequence of transaction commit, the cross-engine transaction to be committed can be added to a commit queue. If the cross-engine transaction in the commit queue does not have a "skewed commit" problem with the commit sequence of other cross-engine transactions, the cross-engine transaction can be deleted from the commit queue and the transaction commit sequence number of the cross-engine transaction can be deleted from the global transaction commit sequence table after the cross-engine transaction is successfully committed. If the commit sequence of the cross-engine transaction in the database engine can cause a "skewed commit" problem with the commit sequence of other cross-engine transactions, the related information of the two cross-engine transactions can be deleted from the commit queue and the global transaction commit sequence table after the two cross-engine transactions are successfully committed and the "skewed commit" problem is solved.

[0135] Further, after the cross-engine transaction is successfully completed, the database system can generate a corresponding notification message and send the notification message to the user side to notify the user side that the cross-engine transaction is successfully completed.

[0136] Since the processing module determines the time sequence of the second sub-transactions of the two cross-engine transactions in the second database engine according to the time sequence of the first sub-transactions of the two cross-engine transactions in the first database engine, the time sequence of the two cross-engine transactions in the two database engines can be consistent, that is, the time point at which one of the cross-engine transactions is committed in the two database engines is not later than the time point at which the other cross-engine transaction is committed in the two database engines, and thus the "skewed commit" phenomenon can be avoided.

[0137] The above describes the cross-engine transaction processing method provided by the embodiments of the present application. Figures 1 to 7 The cross-engine transaction processing method provided by the embodiments of the present application is introduced, and then the cross-engine transaction processing device provided by the embodiments of the present application and the computing device for implementing the cross-engine transaction processing function are introduced in combination with the drawings.

[0138] As shown in Figure 8 The embodiments of the present application also provide a cross-engine transaction processing device. The device 800 can be used to execute the cross-engine transaction processing method described above. Figure 5 The device 800 can be applied to a database system, and the database system at least includes a first database engine and a second database engine. The device 800 can include:

[0139] The acquisition unit 801 is configured to acquire time sequence information, and the time sequence information indicates that the first sub-transaction of the first cross-engine transaction is not later than the first sub-transaction of the second cross-engine transaction in performing a target operation, and the target operation includes accessing data in the first database engine.

[0140] The determination unit 802 is configured to determine, according to the time sequence information, that the data first accessed by the second sub-transaction of the first cross-engine transaction in the second database engine is not later than the data first accessed by the second sub-transaction of the second cross-engine transaction in the second database engine in time sequence.

[0141] In a possible implementation, the time sequence information is a time sequence value, and the time sequence value includes a value of a log sequence number or a value of a read view.

[0142] In a possible implementation, when the second subtransaction of the second cross-engine transaction does not access the second database engine before the second subtransaction of the first cross-engine transaction accesses the second database engine, the time series value corresponding to the data accessed by the second subtransaction of the first cross-engine transaction in the second database engine is the current time series value in the second database engine;

[0143] However, when the second sub-transaction of the second cross-engine transaction has accessed the second database engine before the second sub-transaction of the first cross-engine transaction accesses the second database engine, the timing value corresponding to the data accessed by the second sub-transaction of the first cross-engine transaction in the second database engine is not greater than the timing value corresponding to the data accessed by the second sub-transaction of the second cross-engine transaction in the second database engine.

[0144] The cross-engine transaction processing device 800 according to the embodiment of the present application may correspond to the execution of the embodiment of the present application. Figure 5 The method described in the embodiment shown, and the above and other operations and / or functions of each unit of the cross-engine transaction processing device 800 are respectively to achieve Figure 5 For the sake of brevity, the corresponding processes of each method in are not repeated here.

[0145] In addition, the embodiment of the present application also provides another cross-engine transaction processing device. Figure 9 As shown, the device 900 can be used to perform the aforementioned Figure 6 The method for processing cross-engine transactions, apparatus 900, can be applied to a database system, and the database system includes at least a first database engine and a second database engine. The apparatus 900 may include:

[0146] An acquiring unit 901 is configured to acquire timing information, where the timing information indicates that a first subtransaction of a first cross-engine transaction executes a target operation no later than a first subtransaction of a second cross-engine transaction, where the target operation includes committing a transaction in the first database engine.

[0147] The determining unit 902 is configured to determine, based on the timing information, that the second subtransaction of the first cross-engine transaction is committed in the second database engine no later than the second subtransaction of the second cross-engine transaction.

[0148] In a possible implementation, the timing information includes a first transaction commit sequence number of a first subtransaction of the first cross-engine transaction submitted in the first database engine, and a second transaction commit sequence number of a second subtransaction of the second cross-engine transaction submitted in the first database engine;

[0149] The apparatus 900 further includes:

[0150] The rollback unit 903 is configured to roll back the second sub-transaction of the second cross-engine transaction when it is determined that the value of the first transaction commit sequence number is less than the value of the second transaction commit sequence number and the second sub-transaction of the second cross-engine transaction has been committed in the second database engine;

[0151] The committing unit 904 is configured to commit the second sub-transaction of the first cross-engine transaction and the second sub-transaction of the second cross-engine transaction in sequence.

[0152] In a possible implementation, the first log corresponding to the first sub-transaction of the second cross-engine transaction includes a transaction commit sequence number or identifier of the second sub-transaction of the second cross-engine transaction;

[0153] The rollback unit 903 is specifically configured to roll back the second sub-transaction of the second cross-engine transaction according to the transaction commit sequence number or identifier of the second sub-transaction of the second cross-engine transaction in the first log.

[0154] The cross-engine transaction processing device 900 according to the embodiment of the present application may correspond to the execution of the embodiment of the present application. Figure 6 The method described in the embodiment shown, and the above and other operations and / or functions of each unit of the cross-engine transaction processing device 900 are respectively to achieve Figure 6 For the sake of brevity, the corresponding processes of each method in are not repeated here.

[0155] Figures 10 and 11 A computer is provided. Figure 10 The computer 1000 shown can be used to implement the above Figure 8 The function of the cross-engine transaction processing device in the embodiment shown is as follows: Figure 11 The computer 1100 shown can be used to implement the above Figure 9 The functions of the cross-engine transaction processing device in the illustrated embodiment.

[0156] Computer 1000 includes bus 1001, processor 1002, and memory 1003. Processor 1002 and memory 1003 communicate via bus 1001. Bus 1001 can be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus. Buses can be divided into address buses, data buses, control buses, etc. For ease of representation, Figure 10 Only one thick line is used in the diagram, but this does not mean that there is only one bus or one type of bus.

[0157] The processor 1002 may be a central processing unit (CPU). The memory 1003 may include a volatile memory, such as a random access memory (RAM). The memory 1003 may also include a non-volatile memory, such as a read-only memory (ROM), a flash memory, a HDD, or an SSD.

[0158] The memory 1003 stores executable code, and the processor 1002 executes the executable code to perform the aforementioned cross-engine transaction processing method.

[0159] Specifically, in the implementation Figure 8 In the case of the embodiment shown, execution Figure 8 The software or program code required for the functions of the acquisition unit 801 and the determination unit 802 is stored in the memory 1003, and the processor 1002 is used to execute the instructions in the memory 1003 and execute the cross-engine transaction processing method applied to the device 800.

[0160] Computer 1100 includes bus 1101, processor 1102, and memory 1103. Processor 1102 and memory 1103 communicate via bus 1101. Bus 1101 can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus. Buses can be divided into address buses, data buses, control buses, etc. For ease of representation, Figure 11 Only one thick line is used in the diagram, but this does not mean that there is only one bus or one type of bus.

[0161] The processor 1102 may be a central processing unit (CPU). The memory 1103 may include a volatile memory, such as a random access memory (RAM). The memory 1103 may also include a non-volatile memory, such as a read-only memory (ROM), a flash memory, a HDD, or an SSD.

[0162] The memory 1103 stores executable code, and the processor 1102 executes the executable code to perform the aforementioned cross-engine transaction processing method.

[0163] Specifically, in the implementation Figure 9 In the case of the embodiment shown, execution Figure 9 The software or program code required for the functions of the acquisition unit 901, determination unit 902, rollback unit 903, and submission unit 904 are stored in the memory 1103, and the processor 1102 is used to execute the instructions in the memory 1103 and execute the cross-engine transaction processing method applied to the device 900.

[0164] An embodiment of the present application also provides a computer-readable storage medium, including instructions, which, when executed on a computer, enables the computer to execute the above-mentioned cross-engine transaction processing method applied to the device 800.

[0165] An embodiment of the present application also provides a computer-readable storage medium, including instructions, which, when executed on a computer, enables the computer to execute the above-mentioned cross-engine transaction processing method applied to the device 900.

[0166] The present application also provides a computer program product. When the computer executes the computer, the computer executes any of the aforementioned methods for processing cross-engine transactions. The computer program product may be a software installation package. When any of the aforementioned methods for processing cross-engine transactions is required, the computer program product may be downloaded and executed on the computer.

[0167] It should also be noted that the device embodiments described above are merely illustrative, wherein the units described as separate components may or may not be physically separate, that is, they may be located in one place, or they may be distributed across multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the present embodiment. In addition, in the drawings of the device embodiments provided in this application, the connection relationship between the units indicates that there is a communication connection between them, which may be implemented as one or more communication buses or signal lines.

[0168] Those skilled in the art can clearly understand that the application can be implemented by means of software plus necessary universal hardware, and of course can also be implemented by means of dedicated hardware including special integrated circuit, special CPU, special memory, special component, etc. Generally, any function completed by computer program can be easily implemented by corresponding hardware, and the specific hardware structure for implementing the same function can also be various, such as analog circuit, digital circuit or special circuit, etc. However, for the application, software program implementation is a better embodiment. Based on such understanding, the technical solution of the application or the part of the application which makes contribution to the prior art can be embodied in the form of software product, which is stored in readable storage medium, such as computer floppy disk, U disk, mobile hard disk, ROM, RAM, magnetic disk or optical disk, etc., and includes a plurality of instructions for making a computer device (which can be personal computer, training device or network device, etc.) execute the method described in various embodiments of the application.

[0169] In the above embodiments, the implementation can be achieved by software, hardware, firmware or any combination thereof, entirely or partially. When implemented by software, the implementation can be achieved in the form of a computer program product, entirely or partially.

[0170] The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the flow or function described in the embodiments of the application is generated entirely or partially. 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, for example, the computer instructions can be transmitted from one website, computer, training device or data center to another website, computer, training device or data center through wired (such as coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (such as infrared, wireless, microwave, etc.) mode. The computer-readable storage medium can be any available medium that can be stored by the computer or a data storage device such as training device, data center, etc. integrated with one or more available media sets. The available medium can be magnetic medium (such as floppy disk, hard disk, magnetic tape), optical medium (such as DVD) or semiconductor medium (such as solid state disk (SSD)) etc.

Claims

1. A method for processing cross-engine transactions, characterized in that: The method is applied to a database system, the database system including at least a first database engine and a second database engine, and the method includes: Acquire timing information, where the timing information indicates that a first subtransaction of a first cross-engine transaction executes a target operation no later than a first subtransaction of a second cross-engine transaction, where the target operation includes accessing data in the first database engine, and the timing information is a timing value, where the timing value is a numerical value representing a timing of data; According to the timing information, it is determined that the data first accessed by the second sub-transaction of the first cross-engine transaction in the second database engine is no later than the data first accessed by the second sub-transaction of the second cross-engine transaction in the second database engine in terms of timing.

2. The method according to claim 1, characterized in that The time sequence value includes a value of a log sequence number or a value of a read view.

3. The method according to claim 2, characterized in that When the second sub-transaction of the second cross-engine transaction does not access the second database engine before the second sub-transaction of the first cross-engine transaction accesses the second database engine, the timing value corresponding to the data accessed by the second sub-transaction of the first cross-engine transaction in the second database engine is the current timing value in the second database engine; When the second sub-transaction of the second cross-engine transaction has accessed the second database engine before the second sub-transaction of the first cross-engine transaction accesses the second database engine, the timing value corresponding to the data accessed by the second sub-transaction of the first cross-engine transaction in the second database engine is not greater than the timing value corresponding to the data accessed by the second sub-transaction of the second cross-engine transaction in the second database engine.

4. A method for processing cross-engine transactions, characterized in that: The method is applied to a database system, the database system including at least a first database engine and a second database engine, and the method includes: Acquire timing information, where the timing information indicates that a first subtransaction of a first cross-engine transaction executes a target operation no later than a first subtransaction of a second cross-engine transaction, where the target operation includes committing a transaction in the first database engine. The timing information is a timing value, where the timing value is a numerical value representing a data timing sequence. According to the timing information, it is determined that the second sub-transaction of the first cross-engine transaction is committed in the second database engine no later than the second sub-transaction of the second cross-engine transaction.

5. The method according to claim 4, characterized in that The timing information includes a first transaction commit sequence number of a first subtransaction of the first cross-engine transaction submitted in the first database engine, and a second transaction commit sequence number of a second subtransaction of the second cross-engine transaction submitted in the first database engine; The method further comprises: When it is determined that the value of the first transaction commit sequence number is less than the value of the second transaction commit sequence number, and the second subtransaction of the second cross-engine transaction has been committed in the second database engine, rolling back the second subtransaction of the second cross-engine transaction; The second sub-transaction of the first cross-engine transaction and the second sub-transaction of the second cross-engine transaction are committed in sequence.

6. The method according to claim 5, characterized in that The first log corresponding to the first sub-transaction of the second cross-engine transaction includes a transaction commit sequence number or identifier of the second sub-transaction of the second cross-engine transaction; The rolling back of the second sub-transaction of the second cross-engine transaction includes: The second sub-transaction of the second cross-engine transaction is rolled back according to the transaction commit sequence number or identifier of the second sub-transaction of the second cross-engine transaction included in the first log.

7. A cross-engine transaction processing device, characterized in that: The device is applied to a database system, the database system including at least a first database engine and a second database engine, and the device includes: an acquiring unit, configured to acquire timing information, the timing information indicating that a first subtransaction of a first cross-engine transaction executes a target operation no later than a first subtransaction of a second cross-engine transaction, the target operation including accessing data in the first database engine, the timing information being a timing value, the timing value being a numerical value representing a timing of data; A determining unit is configured to determine, based on the timing information, that data first accessed by the second subtransaction of the first cross-engine transaction in the second database engine is no later than data first accessed by the second subtransaction of the second cross-engine transaction in the second database engine in terms of timing.

8. The device according to claim 7, characterized in that When the second subtransaction of the second cross-engine transaction does not access the second database engine before the second subtransaction of the first cross-engine transaction accesses the second database engine, the timing value corresponding to the data accessed by the second subtransaction of the first cross-engine transaction in the second database engine is the current timing value in the second database engine; When the second sub-transaction of the second cross-engine transaction has accessed the second database engine before the second sub-transaction of the first cross-engine transaction accesses the second database engine, the timing value corresponding to the data accessed by the second sub-transaction of the first cross-engine transaction in the second database engine is not greater than the timing value corresponding to the data accessed by the second sub-transaction of the second cross-engine transaction in the second database engine.

9. A cross-engine transaction processing device, characterized in that: The device is applied to a database system, the database system including at least a first database engine and a second database engine, and the device includes: an acquiring unit, configured to acquire timing information, the timing information indicating that a first subtransaction of a first cross-engine transaction executes a target operation no later than a first subtransaction of a second cross-engine transaction, the target operation including committing a transaction in the first database engine, the timing information being a timing value, the timing value being a numerical value representing a data timing; A determining unit is configured to determine, based on the timing information, that the second subtransaction of the first cross-engine transaction is committed in the second database engine no later than the second subtransaction of the second cross-engine transaction.

10. The device according to claim 9, characterized in that The timing information includes a first transaction commit sequence number of a first subtransaction of the first cross-engine transaction submitted in the first database engine, and a second transaction commit sequence number of a second subtransaction of the second cross-engine transaction submitted in the first database engine; The device further comprises: a rollback unit, configured to roll back the second sub-transaction of the second cross-engine transaction when it is determined that the value of the first transaction commit sequence number is less than the value of the second transaction commit sequence number and the second sub-transaction of the second cross-engine transaction has been committed in the second database engine; A committing unit is configured to commit the second sub-transaction of the first cross-engine transaction and the second sub-transaction of the second cross-engine transaction in sequence.

11. The device according to claim 10, characterized in that The first log corresponding to the first sub-transaction of the second cross-engine transaction contains a transaction commit sequence number or identifier of the second sub-transaction of the second cross-engine transaction; The rollback unit is specifically configured to roll back the second sub-transaction of the second cross-engine transaction according to the transaction commit sequence number or identifier of the second sub-transaction of the second cross-engine transaction in the first log.

12. A computer, characterized in that: including processor and memory; The processor and the memory communicate with each other; The processor is configured to execute instructions stored in the memory to perform the method according to any one of claims 1 to 3.

13. A computer, characterized in that: including processor and memory; The processor and the memory communicate with each other; The processor is configured to execute instructions stored in the memory and perform the method according to any one of claims 4 to 6.

14. A computer-readable storage medium comprising instructions, which, when executed on a computer, causes the computer to perform the method according to any one of claims 1 to 3.

15. A computer-readable storage medium comprising instructions, which, when executed on a computer, causes the computer to perform the method according to any one of claims 4 to 6.

Images