A multi-version concurrency control method, apparatus, device and storage medium

Abstract

This invention discloses a multi-version concurrency control method, apparatus, device, and storage medium. The method includes: during the read phase of the current transaction, finding the latest tuple version of the target tuple that the current transaction needs to access; if the latest tuple version is an uncommitted version, recording the dependency attribute information of the current transaction and adding the latest tuple version to the read-write set of the current transaction; if it is determined that all dependent transactions of the current transaction have been committed, the current transaction enters the read-write conflict detection phase, detecting whether there is a read-write conflict based on the dependency attribute information; if there is no read-write conflict, the current transaction enters the write phase, updating the target tuple corresponding to the tuple version in the write set of the current transaction, and notifying the dependent transactions of the current transaction to release their dependencies. Compared with existing concurrency control mechanisms, this invention does not require prior knowledge or static analysis of the workload, supports general transactions and interactive workloads, has a wider range of applicable scenarios, and fewer limitations.

Description

Technical Field

[0001] This invention relates to the field of multi-version database technology, and in particular to a multi-version concurrency control method, apparatus, device, and storage medium. Background Technology

[0002] In the database field, transactional, highly competitive workloads typically include hotspots—one or more database records that are frequently accessed by a large number of concurrent transactions. Typical examples include university course registration, e-commerce platform flash sales, and train ticket rushes during the Spring Festival travel season.

[0003] For such highly competitive workloads that include hotspots, the database field has corresponding concurrency control mechanisms, which mainly include: transaction hopping and multi-version concurrency control (MVCC).

[0004] The aforementioned concurrency control mechanisms for high-concurrency workloads with hotspots, while improving transaction concurrency and throughput to some extent, each still have drawbacks: transaction partitioning techniques are only applicable to deterministic database systems, require prior knowledge of the entire workload and static analysis, do not support random transactions, and do not support interactive workloads; once a new transaction is added to the workload, the entire workload needs to be re-analyzed, resulting in significant overhead. Existing multi-version concurrency control (MV2PL) techniques are often combined with lock-based two-phase locking (2PL) and optimistic concurrency control (OCC) mechanisms. However, due to the inherent limitations of 2PL and OCC strategies, neither MV2PL nor MVOCC can achieve optimal scheduling of hotspots. Summary of the Invention

[0005] This invention provides a multi-version concurrency control method, apparatus, device, and storage medium to solve the problem that existing concurrency control mechanisms require prior analysis of workload or have limitations. It does not require prior knowledge or static analysis of the workload, supports general transactional and interactive workloads, has a wider range of applicable scenarios, fewer limitations, and improves the concurrency of transaction processing, achieves higher throughput, and improves the overall performance of the database in high-concurrency scenarios with hotspots.

[0006] According to one aspect of the present invention, a multi-version concurrency control method is provided, comprising:

[0007] After the current transaction starts, during the read phase of the current transaction, the latest version of the target tuple that the current transaction needs to access is found; if the latest tuple version is an uncommitted version, the dependency attribute information of the current transaction is recorded, and the latest tuple version is recorded in the read-write set of the current transaction; the read-write set includes: a read set and a write set;

[0008] If it is determined from the dependency attribute information that all dependent transactions of the current transaction have been committed, the current transaction enters the read-write conflict detection phase, in which the read-write conflict detection phase is performed to detect whether there is a read-write conflict in the current transaction based on the dependency attribute information.

[0009] If there is no read / write conflict, the current transaction enters the write phase, during which the target tuple corresponding to the tuple version in the write set of the current transaction is updated, and the dependent transactions of the current transaction are notified to release the dependency.

[0010] According to another aspect of the present invention, a multi-version concurrency control device is provided, comprising:

[0011] The read module is used to find the latest version of the target tuple that the current transaction needs to access during the read phase of the current transaction after the current transaction starts; if the latest tuple version is an uncommitted version, the dependency attribute information of the current transaction is recorded, and the latest tuple version is recorded in the read-write set of the current transaction; the read-write set includes: a read set and a write set;

[0012] The conflict detection module is used to detect whether there is a read-write conflict in the current transaction if it is determined from the dependency attribute information that all dependent transactions of the current transaction have been committed.

[0013] The write module is used to allow the current transaction to enter the write phase if there is no read-write conflict. In the write phase, the target tuple corresponding to the tuple version in the write set of the current transaction is updated, and the dependent transactions of the current transaction are notified to release the dependency.

[0014] According to another aspect of the present invention, an electronic device is provided, the electronic device comprising:

[0015] At least one processor; and

[0016] A memory communicatively connected to the at least one processor; wherein,

[0017] The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the multi-version concurrency control method described in any embodiment of the present invention.

[0018] According to another aspect of the present invention, a computer-readable storage medium is provided, the computer-readable storage medium storing computer instructions for causing a processor to execute and implement the multi-version concurrency control method described in any embodiment of the present invention.

[0019] The technical solution of this invention involves, after the current transaction starts, during the read phase of the current transaction, finding the latest tuple version of the target tuple that the current transaction needs to access; if the latest tuple version is an uncommitted version, then recording the dependency attribute information of the current transaction and recording the latest tuple version in the read-write set of the current transaction; the read-write set includes a read set and a write set; if it is determined from the dependency attribute information that all dependent transactions of the current transaction have been committed, then the current transaction enters the read-write conflict detection phase, in which the current transaction checks whether there is a read-write conflict based on the dependency attribute information; if there is no read-write conflict, then the current transaction enters the write phase, in which the target tuple corresponding to the tuple version in the write set of the current transaction is updated, and the dependent transactions of the current transaction are notified to release the dependency. Compared to existing concurrency control mechanisms for high-concurrency workloads with hotspots, this mechanism does not require prior knowledge or static analysis of the workload. It supports general transactional and interactive workloads, has a wider range of applicable scenarios, and fewer limitations. It solves the problem that existing concurrency control mechanisms require prior analysis of the workload or have limitations. Furthermore, in high-concurrency scenarios with hotspots, it improves the concurrency of transaction processing, achieves higher throughput, and improves the overall performance of the database.

[0020] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description

[0021] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0022] Figure 1A This is a schematic diagram of a two-phase locking concurrency control mechanism based on locks, an optimistic concurrency control mechanism, and an ideal transaction scheduling mechanism in scenarios with hotspots.

[0023] Figure 1B This is a flowchart of a multi-version concurrency control method provided in Embodiment 1 of the present invention;

[0024] Figure 2A This is a flowchart of a multi-version concurrency control method provided in Embodiment 2 of the present invention;

[0025] Figure 2B This is a flowchart of the execution process of the current transaction's read operation during the read phase;

[0026] Figure 2C This is a flowchart of the execution process of the current transaction's write operation during the read phase;

[0027] Figure 3 This is a flowchart of a multi-version concurrency control method provided in Embodiment 3 of the present invention;

[0028] Figure 4 This is a schematic diagram of the structure of a multi-version concurrency control device provided in Embodiment 4 of the present invention;

[0029] Figure 5 This is a schematic diagram of the structure of an electronic device that implements the multi-version concurrent control method of the present invention. Detailed Implementation

[0030] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0031] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0032] Concurrency control mechanisms in the database field can be mainly divided into the following two categories:

[0033] I. Transaction Chopping Techniques: Techniques such as IC3 and Runtime Pipelining decompose each transaction into a series of atomic sub-transactions through static analysis of the entire workload, and execute these sub-transactions in parallel according to certain rules. In transaction chopping, update operations within a sub-transaction are immediately visible to other transactions after the sub-transaction ends, allowing for dirty reads. Fine-grained transaction chopping, allowing for dirty reads, and parallel execution enable transaction chopping techniques to achieve high throughput and allow for greater transaction concurrency under highly competitive workloads with hotspots. Transaction chopping techniques have the following drawbacks:

[0034] (1) It is only applicable to deterministic database systems and requires prior knowledge of the entire workload and static analysis.

[0035] (2) It does not support random transactions or interactive workloads;

[0036] (3) Once a new transaction is added to the workload, the entire workload needs to be re-analyzed, which is very costly;

[0037] (4) This static analysis cannot determine the final execution result and operation object of a database statement (Structured Query Language, SQL). To avoid potential loops / deadlocks, a more conservative conflict detection method is usually chosen, causing some unnecessary waiting. For example, in IC3, if two transactions need to access attribute 'a' of some records in table A, IC3 may ultimately determine that there is a conflict between the two transactions and process them serially. However, in actual execution, the two transactions access attributes a1 and a2 of two different records in table A, which are not conflicting and can be executed in parallel.

[0038] II. Multi-Version Concurrency Control (MVCC): In MVCC, the database maintains multiple versions (tuple versions) for each record. The locks required to read a record do not conflict with the locks required to write data, avoiding mutual blocking between read-write transactions and read-only transactions. It can significantly improve the concurrency of transaction processing under high-contention workloads with hotspots without sacrificing serializability. MVCC is often used in conjunction with lock-based two-phase locking (2PL) or optimistic concurrency control (OCC) mechanisms. Typical examples include MV2PL and HEKATON in MySQL. Existing MVCC has the following drawbacks: MVCC is often used in conjunction with 2PL and OCC. Figure 1A This diagram illustrates a two-phase locking concurrency control mechanism based on locks, an optimistic concurrency control mechanism, and an ideal transaction scheduling mechanism in scenarios with hotspots. For example... Figure 1A As shown, due to the inherent limitations of the 2PL and OCC strategies, neither MV2PL nor MVOCC can achieve optimal scheduling of hotspots.

[0039] (1) MV2PL: When multiple transactions access a record simultaneously, MV2PL only allows one transaction to successfully access the record, blocking the execution of other transactions. These blocked transactions can only be woken up and executed in turn after the transaction that has obtained access rights commits. Therefore, in scenarios with hot data, MV2PL will block the execution of transactions for a long time, resulting in large waiting overhead and low transaction concurrency.

[0040] (2) MVOCC: MVOCC assumes that there is little data contention between transactions, so it does not impose any restrictions on the execution of transactions until conflict detection is performed during transaction verification. Therefore, in scenarios with hot data, MVOCC will cause more transaction rollbacks, wasting a lot of computing resources and resulting in lower throughput.

[0041] This invention proposes a concurrency control mechanism based on dependency attributes. It does not require prior knowledge or static analysis of the workload, supports general transactional and interactive workloads, has a wider range of applicable scenarios, and fewer limitations. It solves the problem that existing concurrency control mechanisms require prior analysis of the workload or have limitations. Furthermore, in high-concurrency scenarios with hotspots, it improves the concurrency of transaction processing, achieves higher throughput, and improves the overall performance of the database.

[0042] Example 1

[0043] Figure 1B This is a flowchart illustrating a multi-version concurrency control method provided in Embodiment 1 of the present invention. This embodiment is applicable to the concurrency control of multi-version databases with high-contention workloads and hotspots. The method can be executed by a multi-version concurrency control device, which can be implemented in hardware and / or software and can be configured in an electronic device. Figure 1B As shown, the method includes:

[0044] S110. After the current transaction starts, during the read phase of the current transaction, find the latest version of the target tuple that the current transaction needs to access; if the latest tuple version is an uncommitted version, record the dependency attribute information of the current transaction and record the latest tuple version in the read-write set of the current transaction; the read-write set includes: the read set and the write set.

[0045] The current transaction refers to one of the transactions currently being executed in the database management system. Database operations include read, update, insert, and delete operations. Since insert operations do not involve data concurrency control and do not require special handling, they are not the focus of this invention. Update and delete operations both add a new tuple version; however, delete operations add a special tuple version to represent the deletion of the current tuple version. Therefore, update and delete operations can be categorized as write operations. Thus, the access operations of the current transaction can be summarized as read and write operations. The target tuple is the tuple that the current transaction's access operations aim to access.

[0046] This invention addresses multi-version databases, allowing multiple transactions to access the same tuple within the database management system. Modifications to the tuple by different transactions create new versions of the tuple, and dirty reads and dirty writes are permitted. Based on multi-version databases, this invention's database management system references pessimistic locking and adopts the three-phase transaction processing model of MVOCC, including a read phase, a conflict detection phase, and a write phase. A read-write set is maintained for each current transaction to record all tuples accessed by the transaction. The read-write set can include a read set and a write set; the read set records tuples read by the transaction, and the write set records tuples written by the transaction.

[0047] Because multi-version databases allow dirty reads and dirty writes (a dirty read occurs when a transaction reads data modified by another transaction before it has been committed, and a dirty write occurs when a transaction modifies data modified by another transaction before it has been committed), when a current transaction accesses tuples in the database, it may encounter dependencies on tuple versions written or read by other transactions. Therefore, to ensure the safety and correctness of dirty reads and dirty writes, and the orderly execution of transaction commits, it is necessary to record the dependency attribute information of the current transaction. The dependency attribute information of the current transaction can be understood as recording information about the transactions that the current transaction depends on and the transactions that are depended upon. The dependent transaction refers to other transactions that accessed the version of the tuple created by the current transaction, and the dependent transaction refers to the version of the tuple created by other transactions accessed by the current transaction. For the dependency relationship between two transactions, it can be understood that if the access operation of transaction T1 depends on the access operation of transaction T2, then transaction T1 is the dependent transaction, and transaction T2 is the dependent transaction; conversely, if the access operation of transaction T2 depends on the access operation of transaction T1, then transaction T2 is the dependent transaction, and transaction T1 is the dependent transaction.

[0048] Optionally, dependency attribute information may include: the identifier and number of the dependent transaction, the identifier and number of the dependent transaction, and the dependency type. The dependency type can be understood as the type of dependency relationship between two transactions. For example, dependency types may include write-read dependency type, write-write dependency type, and read-write dependency type.

[0049] (1) Write-read dependency type means that the read operation of transaction T1 depends on the write operation of transaction T2. ​​That is, after transaction T2 performs a write operation on tuple A, transaction T1 performs a read operation on tuple A; transaction T1 is a dependent transaction and transaction T2 is a dependent transaction.

[0050] (2) Write-write dependency type means that the write operation of transaction T1 depends on the write operation of transaction T2. ​​That is, after transaction T2 performs a write operation on tuple A, transaction T1 performs a write operation on tuple A again; transaction T1 is the dependent transaction and transaction T2 is the dependent transaction.

[0051] (3) Read-write dependency type means that the write operation of transaction T2 depends on the read operation of transaction T1, or the read operation of transaction T1 is dependent on transaction T2. ​​That is, after transaction T1 reads tuple A, transaction T2 performs a write operation on tuple A. Transaction T1 is the dependent transaction and transaction T2 is the dependent transaction.

[0052] Specifically, after the current transaction in the database management system starts, it enters the read phase. During the read phase, based on the current transaction's access operations, the target tuple accessed by the current transaction is located, and the latest tuple version of the target tuple at the current moment is obtained. It is then determined whether the latest tuple version of the accessed target tuple is an uncommitted version. If it is an uncommitted version, there may be a dependency relationship between the current transaction and the transaction that created the uncommitted version. Therefore, the dependency attribute information of the current transaction is recorded, and the latest tuple version accessed is recorded in the read / write set corresponding to the current transaction.

[0053] For example, the latest tuple version A read by the current transaction T1's read operation ReadTuple(T1, tuple A) is... x Record the latest tuple version Bx written by the write operation WriteTuple(T1,tuple B) of the current transaction into the read set T1.write_set.

[0054] S120. If it is determined from the dependency attribute information that all dependent transactions of the current transaction have been committed, the current transaction enters the read-write conflict detection phase. In the read-write conflict detection phase, the current transaction is checked for read-write conflicts based on the dependency attribute information.

[0055] The read-write conflict detection phase is used to detect whether the current transaction is experiencing read-write conflicts with other transactions. Dependent transaction commit refers to all operations of a transaction that depends on the commit of that transaction.

[0056] Specifically, the dependency attribute information recorded in the read phase determines whether all dependent transactions of the current transaction have been committed. If all have been committed, then write operations performed earlier by other transactions will not conflict with write / read operations performed later by the current transaction. However, it cannot be guaranteed whether read operations performed earlier by the current transaction will conflict with write operations performed later by other transactions; that is, read-write conflict detection is ignored. Therefore, read-write conflict detection is still required. Only after it is determined that all dependent transactions of the current transaction have been committed can the current transaction enter the read-write conflict detection phase, ensuring that transactions are committed in order.

[0057] During the read-write conflict detection phase, read-write conflict detection is performed on the current transaction. Based on the dependency attribute information recorded in the read-write set, it is determined whether read-write conflicts exist in the current transaction. If read-write conflicts exist in the current transaction, the current transaction needs to be rolled back.

[0058] S130. If there is no read-write conflict, the current transaction enters the write phase. In the write phase, the target tuple corresponding to the tuple version in the write set of the current transaction is updated, and the dependent transactions of the current transaction are notified to release the dependency.

[0059] Specifically, if there are no read-write conflicts in the current transaction, the current transaction can enter the write phase of the access operation. For the write operation performed by the current transaction, the metadata contained in the target tuple of the corresponding tuple version in the current transaction's write set is updated based on the write operation, enabling access operations such as deletion or update of the target tuple. After the current transaction commits, it notifies the dependent transactions that this transaction has completed its commit, allowing the dependent transactions to release their dependencies on this transaction.

[0060] The technical solution of this invention involves, after the current transaction starts, finding the latest tuple version of the target tuple that the current transaction needs to access during the read phase. If the latest tuple version is an uncommitted version, the dependency attribute information of the current transaction is recorded, and the latest tuple version is recorded in the read-write set of the current transaction. The read-write set includes a read set and a write set. If it is determined from the dependency attribute information that all dependent transactions of the current transaction have been committed, the current transaction enters the read-write conflict detection phase. In the read-write conflict detection phase, the existence of read-write conflicts in the current transaction is detected based on the dependency attribute information. If no read-write conflicts exist, the current transaction enters the write phase. In the write phase, the target tuple corresponding to the tuple version in the write set of the current transaction is updated, and the dependent transactions of the current transaction are notified to release their dependencies. Compared with existing concurrency control mechanisms for high-contention workloads with hotspots, this invention does not require prior knowledge or static analysis of the workload, supports general transactions and interactive workloads, has a wider range of applicable scenarios, and fewer limitations. In addition, the feature of allowing dirty reads and dirty writes, combined with multi-version concurrency, greatly improves the throughput of transactions and enhances the overall performance of the database in high-contention scenarios with hotspots.

[0061] Example 2

[0062] Figure 2A This is a flowchart of a multi-version concurrency control method provided in Embodiment 2 of the present invention. This embodiment further refines the read phase of the current transaction in the above embodiment.

[0063] In this embodiment, the dependency attribute information of the current transaction is recorded using a dependent linked list and a verification semaphore;

[0064] The dependent linked list is used to record the identifier and dependency type of the dependent transaction; the verification semaphore is used to indicate the number of uncommitted dependent transactions of the current transaction.

[0065] The dependency type includes at least one of the following: write-read dependency type, write-write dependency type, and read-write dependency type.

[0066] In this embodiment, the dependency list `dependency_list` is used to identify the dependent transactions of the current transaction, and to define the dependency types between the current transaction and the dependent transactions. A dependent transaction refers to another transaction that accesses the tuple version created by the current transaction. The dependency types between the dependent and current transactions can include: write-write dependency type WW, write-read dependency type WR, and read-write dependency type RW. The validation semaphore `validation_semaphore` represents the number of uncommitted dependent transactions of the current transaction.

[0067] like Figure 2A As shown, the method includes:

[0068] S210. After the current transaction starts, during the read phase of the current transaction, for the read operation of the current transaction, it is determined whether the current transaction has accessed the first target tuple; if not, the first latest tuple version of the first target tuple that the current transaction needs to read is found; for the write operation of the current transaction, the second latest tuple version of the second target tuple that the current transaction needs to write is found.

[0069] Here, the first target tuple is the tuple that the current transaction's read operation will read; the first latest tuple version is the latest version of the first target tuple at the current moment. The second target tuple is the tuple that the current transaction's write operation will update or delete; the second latest tuple version is the latest version of the second target tuple at the current moment.

[0070] Specifically, after the current transaction starts, it enters the read phase, where it reads the latest version of the target tuple for the current transaction's read or write operations. For a read operation of the current transaction T1, such as ReadTuple(T1, tuple A), it first needs to determine whether the current transaction has accessed (read or modified) the first target tuple A. If so, the tuple version corresponding to the first target tuple A exists in the read / write set (write set / read set), and the tuple version corresponding to the first target tuple A in the read / write set is returned. If not, the tuple version corresponding to the first target tuple A does not exist in the read / write set (write set / read set), and the latest version A of the first target tuple A that the current transaction wants to read needs to be found in the database. x For a write operation in the current transaction T1, such as WriteTuple(T1, tuple B), it is necessary to find the second latest version B of the second target tuple B to be written in the database. x .

[0071] S220. If the latest tuple version is being modified by other transactions, continue to wait until the latest tuple version is no longer being modified by other transactions.

[0072] Specifically, determine whether the latest tuple version found (including the first latest tuple version or the second latest tuple version) is being modified by other transactions. If so, continue to wait until the latest tuple version is not being modified by any transactions, and then execute step S230.

[0073] For example, when a transaction modifies a tuple, it needs to acquire a lock on the latest tuple version. Therefore, the state of the lock on the latest tuple version can be used to determine whether the latest tuple version is being modified by another transaction. For example, the latest tuple version of the target tuple A is Ai. x The lock state is adopted using A x .latch status information determined, A x `.latch == true` means that the latest tuple version A is obtained. x The lock indicates that the latest tuple version is being modified by another transaction.

[0074] S230. For the read operation of the current transaction, determine whether the first latest tuple version is an uncommitted version; for the read operation of the current transaction, acquire the lock of the second latest tuple version, and determine whether the second latest tuple version is an uncommitted version.

[0075] Specifically, if the latest tuple version accessed by the current transaction has not been modified by any transaction, then it is further determined whether the latest tuple version is an uncommitted version. For the current transaction's write operation, it is necessary to first obtain the second latest tuple version B. x The lock, and determine the version of the second latest tuple B. x Is it an uncommitted version? For read operations in the current transaction, it is not necessary to acquire a lock on the first latest tuple version; the first latest tuple version A can be determined directly. x Is it an unsubmitted version?

[0076] For example, determining whether the latest tuple version is an uncommitted version can be based on the timestamp information representing the latest tuple version. For instance, the start timestamp of an uncommitted tuple version could be set to a preset character such as MAX, while the start timestamp of a committed tuple version could be set to the commit time. Alternatively, it can be determined based on predefined attribute information representing a committed version. For example, setting the attribute value `retire` to represent the attribute information of a committed version, such as B... x .retire = NULL means B x The latest tuple version is the commit version if B x .retire is a non-empty value (generally, it can be the first and most recent tuple version A). x(Transaction ID), representing B x The latest version of the tuple is an uncommitted version.

[0077] S240. For the read operation of the current transaction, if the first latest tuple version is an uncommitted version, record the write-read dependency information of the current transaction, record the first latest tuple version in the read set of the current transaction, and return the first latest tuple version in the read set; for the write operation of the current transaction, if the second latest tuple version is an uncommitted version, record the write-write dependency information of the current transaction, create a new tuple version, acquire the lock of the new tuple version; generate a version chain between the second latest tuple version and the newly created tuple version, release the locks of the second latest tuple version and the new tuple version, and record the second latest tuple version in the write set of the current transaction.

[0078] The write-read dependency information refers to the information representing the write-read dependencies of the current transaction T1 with other transactions T2. For example, it may include the dependency type (such as write-write dependency WW, write-read dependency WR), the number of dependent transactions of the current transaction, and the transaction ID of the dependent transactions.

[0079] Specifically, if the latest tuple version to be accessed by the current transaction is determined to be an uncommitted version, then the dependency attribute information of the current transaction is recorded. For the read operation of the current transaction, if the first latest tuple version A... x If it is an uncommitted version, it means that the first latest tuple version A that the current transaction T1 needs to read is A. x If a data point has been written to by another transaction but not yet committed, then the current transaction T1 and the transaction that wrote the first latest tuple version A... x Transaction T2 has a write-read dependency on WR, therefore, record the write-read dependency information of the current transaction.

[0080] Optionally, the write / read dependency information for the current transaction can be recorded as follows:

[0081] The verification semaphore of the current transaction is incremented by one, and the identifier and write / read dependency type of the current transaction, which are the dependent transactions, are recorded in the dependent list of the dependent transactions that the current transaction depends on.

[0082] Specifically, for the read operation of the current transaction, if the first latest tuple version A... x For uncommitted versions, the current transaction T1 writes the first latest tuple version A. x Transaction T2 has a write-read dependency relationship (WR), meaning that the read operation of the current transaction T1 depends on the write operation of transaction T2, and the current transaction T1 is the dependent transaction of transaction T2. ​​Therefore, the validation semaphore of the current transaction T1.validation_semaphore is incremented by 1; and (T1, WR) is recorded in the dependent list T2.validation_semaphore of the first dependent transaction.

[0083] For the write operation of the current transaction, if the second latest tuple version B x If it is an uncommitted version, it means that the second most recent tuple version B to be written by the current transaction T1 is B. x If a data point has been written to by another transaction but not yet committed, then the current transaction T1 and the transaction that wrote the second most recent tuple version B... x Transaction T3 has a write-write dependency WW; therefore, the write-write dependency information of the current transaction is recorded. Simultaneously, since the write operation of the current transaction causes a change in the tuple version of the second target tuple, a new tuple version B of the second target tuple needs to be created. x+1 And obtain the new tuple version B x+1 The lock. To ensure other transactions can correctly access the new tuple version, a second, more up-to-date tuple version B also needs to be generated. x and the new tuple version B x+1 The version chain makes the second most recent tuple version B x and the new tuple version B x+1 Connected. Finally, the second latest tuple version B can be released. x and the new tuple version B x+1 The lock will be the second latest tuple version B. x Recorded in the write set of the current transaction.

[0084] Optionally, the write dependency information for the current transaction can be recorded as follows:

[0085] Incrementing the verification semaphore of the current transaction by one will serve as the identifier of the current transaction of the dependent transaction, and the write dependency type will be recorded in the dependent chain of the dependent transactions that the current transaction depends on.

[0086] Specifically, for the write operation of the current transaction, if the second latest tuple version B... x For the uncommitted version, the current transaction T1 writes the second latest tuple version B. x Transaction T3 has a write-read dependency relationship WW, meaning that the write operation of the current transaction T1 depends on the write operation of transaction T3, and the current transaction T1 is the dependent transaction of transaction T3. Therefore, the validation semaphore of the current transaction T1.validation_semaphore is incremented by 1; and (T1, WW) is recorded in the dependent list T3.validation_semaphore of the second dependent transaction.

[0087] This embodiment provides an early release mechanism. For the write operation of the current transaction, locks are acquired on the second latest tuple version and the newly created tuple version before the operation, preventing other transactions from accessing the second latest tuple version and the new tuple version. After the operation, the locks on the second latest tuple version and the newly created tuple version are released immediately, making the newly created tuple version visible to other transactions immediately. This can achieve optimal scheduling of hotspots, thereby mitigating the blocking problem caused by 2PL and allowing for greater concurrency.

[0088] S250. If it is determined from the dependency attribute information that all dependent transactions of the current transaction have been committed, the current transaction enters the read-write conflict detection phase. In the read-write conflict detection phase, the current transaction is checked for read-write conflicts based on the dependency attribute information.

[0089] S260. If there is no read-write conflict, the current transaction enters the write phase. In the write phase, the target tuple corresponding to the tuple version in the write set of the current transaction is updated, and the dependent transactions of the current transaction are notified to release the dependency.

[0090] The technical solution of this invention provides an early lock release mechanism. For read operations of the current transaction, it is not necessary to acquire a lock on the latest tuple version. For write operations of the current transaction, locks on the second latest tuple version and the newly created tuple version are acquired before the operation, preventing other transactions from accessing these versions. After the operation, the locks on the second latest tuple version and the newly created tuple version are immediately released, making the newly created tuple version immediately visible to other transactions. This improves the concurrency of transaction processing under high-contention workloads, achieves higher throughput, and improves the overall performance of the database, while further realizing optimal scheduling of hotspots.

[0091] Next, combine Figure 2B and Figure 2C This section details the execution process of the current transaction's access operation during the read phase. Figure 2B This is a flowchart illustrating the execution process of the current transaction's read operation during the read phase. For example... Figure 2B As shown, for the read operation of the current transaction T1, such as ReadTuple(T1, tuple A), during the read phase, it first determines whether the current transaction T1 has accessed (read or modified) the first target tuple A by sequentially checking whether the write set T1.write_set and the read set T1.read_set contain the target tuple A. If the write set T1.write_set contains the target tuple A, then the tuple version A of the target tuple A in the write set T1.write_set is returned. j If the read set T1.read_set contains the target tuple A, then return the tuple version A of the target tuple A in the read set T1.read_set.i If neither the write set T1.write_set nor the read set T1.read_set contains the target tuple A, it means that the current transaction has not accessed the target tuple A, and the latest tuple version A of the target tuple A is found. x Then, by judging A x To determine if .latch = TRUE, check if the latest tuple version A is true. x Is it being modified by other transactions? If A x `.latch = TRUE` indicates that the latest tuple version is being modified by another transaction. Return to the search for the latest tuple version of target tuple A and continue waiting; until A... x .latch ≠ TRUE (e.g., A) x `.latch=FALSE)` indicates that the latest tuple version has not been modified by other transactions. Secondly, by checking A... x To determine the latest tuple version A, check if .retire = NULL. x Is it an unsubmitted version? If A x .retire = NULL indicates the latest tuple version A. x For the submitted version, A x Record it in the read set T1.read_set. If A x .retire ≠ NULL (e.g., A) x .retire=T2) represents the latest tuple version A. x For uncommitted versions and creation of A x If transaction T2 is a write-read dependency (WR) with the current transaction T1, then transaction T2 has a write-read dependency relationship (WR) with the current transaction T1. The current transaction T1 is a dependent transaction of transaction T2. ​​Therefore, the value of the validation semaphore T1.validation_semaphore of the current transaction is incremented by 1, and (T1,WR) is written to the dependent list T2.dependency_list of the dependent transaction T2. ​​Then, the process continues to execute the process of adding A... x The data is recorded in the read set T1.read_set. Finally, the data A read by the read operation ReadTuple(T1, tuple A) is returned. x . Figure 2C This is a flowchart illustrating the execution process of the current transaction's write operation during the read phase. For example... Figure 2C As shown, for a write operation in the current transaction T1, such as WriteTuple(T1, tuple B), the read phase first searches for the latest version B of the target tuple B to be written by the current transaction. x Then, by judging B x To determine if .latch = TRUE, check if the latest tuple version A is true. x Is it being modified by other transactions? If Bx If `.latch = TRUE`, it means that the latest tuple version is being modified by another transaction. The system will return to find the latest tuple version of the target tuple B and continue waiting until B is found. x .latch ≠ TRUE (e.g., B) x `.latch=FALSE)` indicates that the latest tuple version has not been modified by other transactions. This is achieved by setting `B`. x Set `.latch = TRUE` to acquire the lock for the latest tuple version; secondly, check B... x To determine the latest tuple version B, check if .retire = NULL. x Is it an unsubmitted version? If B x .retire = NULL indicates the latest tuple version B. x Create a new tuple version B for the committed version. x+1 If B x .retire ≠ NULL (e.g., B) x .retire=T3) represents the latest tuple version B. x For uncommitted versions and created B x If transaction T3 is a write-write dependency (WW) with the current transaction T1, then transaction T3 has a write-write dependency (WW) relationship with the current transaction T1. The current transaction T1 is a dependent transaction of transaction T3. Therefore, the value of the current transaction's validation semaphore T1.validation_semaphore is incremented by 1, and (T1, WW) is written to the dependent list T3.dependency_list of the dependent transaction T3. A new tuple version B is then created. x+1 Again, by setting B x `.latch=TRUE` acquires the lock for the new tuple version, by setting B x+ 1. `retire = T1` records the transaction T1 creating a new tuple version B. x+1 The latest tuple version B is connected by a version chain between the generated second latest tuple version and the newly created tuple version. x and the new tuple version B x+1 By setting B x .latch=FALSE,B x+1 .latch=FALSE releases the latest tuple version B x and the new tuple version B x+1 The lock. Finally, B. x Record it in the read set T1.write_set.

[0092] Example 3

[0093] Figure 3This is a flowchart of a multi-version concurrency control method provided in Embodiment 3 of the present invention. Based on the advance locking mechanism disclosed in Embodiment 2 above, this embodiment further optimizes and ensures the security and correctness of dirty reads and dirty writes, as well as the orderliness of transaction commits.

[0094] like Figure 3 As shown, the method includes:

[0095] S301. After the current transaction starts, during the read phase of the current transaction, find the latest version of the target tuple that the current transaction needs to access; if the latest tuple version is an uncommitted version, record the dependency attribute information of the current transaction and record the latest tuple version in the read-write set of the current transaction; the read-write set includes: the read set and the write set.

[0096] S302. If the verification semaphore in the dependency attribute information is zero, it is determined that all dependent transactions of the current transaction have been committed, and the current transaction enters the read-write conflict detection phase.

[0097] Specifically, if the validation semaphore in the dependency attribute information is zero, i.e. T1.validation_semaphore = 0, it means that the number of uncommitted dependent transactions of the current transaction is zero. In this case, it is determined that all dependent transactions of the current transaction have been committed, and the current transaction is allowed to enter the read-write conflict detection phase.

[0098] S303. During the read-write conflict detection phase, calculate the current serialization execution order of the current transaction.

[0099] In multi-version databases, to ensure the orderly execution of each transaction, each transaction has a defined serialization execution order. The current serialization execution order refers to the serialization execution order of the current transaction, used to represent the execution order of the current transaction.

[0100] Specifically, after entering the read-write conflict detection phase, the current serialization execution order T1.serial_ID of the current transaction is calculated. This embodiment of the invention does not limit the method for calculating the current serialization execution order of the current transaction; existing methods for calculating serialization execution order can be used.

[0101] S304. Determine if the latest tuple version has a next tuple version, and whether the next tuple version is an uncommitted version.

[0102] Specifically, it checks whether a next version of the target tuple accessed (read / write) by the current transaction exists, i.e., whether the target tuple accessed by the current transaction has been modified by other transactions. If not, there is no read-write conflict in the current transaction, and the current transaction enters the write phase. If it does exist, it continues to check whether the next tuple version is an uncommitted version.

[0103] S305. If there is a next tuple version for the latest tuple version, and the next tuple version is an uncommitted version, then the transaction that creates the next tuple version of the latest tuple version is determined to be the dependent transaction of the current transaction, and the identifier of the dependent transaction and the read / write dependency type are recorded in the dependent list of the current transaction.

[0104] Specifically, if the next tuple version is an uncommitted version, it indicates that there is a read-write dependency between the current transaction and the transaction creating the next tuple version, but no read-write conflict has yet occurred. Therefore, the current transaction T1 is determined to be the dependent transaction, and the transaction creating the next tuple version T4 is the dependent transaction. The read-write dependency relationship RW exists between the current transaction and the dependent transaction, and (T4, RW) is recorded in the dependent list T1.dependency_list of the current transaction T1.

[0105] Furthermore, for transaction T4, which creates the next tuple version, a validation semaphore still exists to represent the number of uncommitted transactions that T4 depends on. Since transaction T4 is dependent on the current transaction T1 (T4 is a dependent transaction of the current transaction T1, and the current transaction T1 is a dependent transaction of transaction T4), and the current transaction T1 has not yet committed during the conflict detection phase, incrementing the value of T4.validation_semaphore by 1 indicates that the number of uncommitted transactions dependent on transaction T4 is incremented by 1.

[0106] S306. If there is a next tuple version for the latest tuple version, and the next tuple version is a committed version, then obtain the read-write conflict detection parameters and update the read-write conflict detection parameters based on the start timestamp of the next tuple version. The read-write conflict detection parameters are used to record the minimum serialization execution order of write transactions that depend on the current transaction for read and write operations and have been committed.

[0107] The read-write conflict detection parameter min_next_begin is used to record the minimum serialization execution order of the write transactions that depend on the current transaction for read and write operations and have been committed, which is the minimum start timestamp of the next uncommitted tuple version of the current transaction.

[0108] Specifically, if the next tuple version is a committed version (meaning the latest tuple version has a next tuple version that is also a committed version), then it's necessary to further determine if the current transaction has read-write conflicts. Determining if the current transaction has read-write conflicts first requires obtaining the read-write conflict detection parameter `min_next_begin`. The start timestamp of the next tuple version is then assigned to the read-write conflict detection parameter, updating the parameter accordingly.

[0109] S307. Compare the current serialization execution order and read / write conflict detection parameters of the current transaction.

[0110] Specifically, the current serialization execution order of the current transaction is compared with the minimum serialization execution order of the committed write transactions that are dependent on the current transaction's read / write operations in the read / write conflict detection parameters to determine whether the current transaction has read / write conflicts.

[0111] S308. If the current serialization execution order is greater than or equal to the read-write conflict detection parameter, then the current transaction has a read-write conflict.

[0112] Specifically, if the current serialization execution order is greater than or equal to the read-write conflict detection parameter, it means that the execution order of the latest tuple version is greater than the execution order of the transaction that creates the next tuple version. Therefore, the current transaction has a read-write conflict, and step S309 is executed to roll back the current transaction.

[0113] S310. If the current serialization execution order is less than the read-write conflict detection parameter, then there is no read-write conflict in the current transaction, and the current transaction enters the write phase.

[0114] Specifically, if the current serialization execution order is less than the read-write conflict detection parameter, it means that the execution order of the latest tuple version is less than or equal to the execution order of the transaction that creates the next tuple version. Therefore, there is no read-write conflict in the current transaction, and the current transaction can enter the write phase.

[0115] S311. During the write phase, update the target tuple corresponding to the tuple version in the write set of the current transaction; traverse each dependent transaction in the dependent list, notify each dependent transaction to modify the dependent transaction information recorded in its own dependent list, and decrement its own transaction's verification semaphore by one.

[0116] Specifically, after the current transaction enters the write phase, it updates the target tuple corresponding to the tuple version in the write set of the current transaction, completing the write operation (modification or deletion) on the target tuple in the write set, and committing the current transaction. Simultaneously, it iterates through each dependent transaction in the dependent list T1.dependency_list, notifying each dependent transaction that its current transaction has been committed and its dependencies can be released. Upon receiving the dependency release notification, each dependent transaction modifies the dependent transaction information recorded in its own dependent list, deleting the dependency information of the current transaction, thus releasing its dependencies.

[0117] Since the current transaction is a dependent transaction of the dependent transaction, and the current transaction has been committed, the value of the validation semaphore of the dependent transaction itself is decremented by 1, which means that the number of uncommitted transactions of the dependent transaction (i.e., the current transaction) is reduced by 1.

[0118] S312. Obtain the dependency type between each dependent transaction in the dependent list and the current transaction; if the dependency type is read-write dependency, update the serialization execution order of the dependent transactions based on the serialization execution order of the current transaction.

[0119] Specifically, the dependency type between each dependent transaction in the dependent list and the current transaction is obtained. It is determined whether the dependency type is a read-write dependency. If so, for the dependent transaction that creates the next tuple version of the latest tuple version accessed by the current transaction, the serialization execution order of the dependent transaction must be after the serialization execution order of the current transaction. Therefore, the serialization execution order of the dependent transactions is updated based on the serialization execution order of the current transaction, thereby ensuring the correctness of transaction execution.

[0120] In this invention, each transaction maintains two attributes: a dependent linked list and a verification semaphore. This records the dependencies between the current transaction and other transactions. By recording dependencies during transaction execution, this invention allows transactions to release locks early, achieving optimal scheduling of hotspots, mitigating transaction blocking issues caused by pessimistic locking, allowing for higher transaction concurrency, and ensuring the safety and correctness of dirty reads and writes, as well as the orderly execution of transactions. Furthermore, by recording write-read dependencies and write-write dependencies between transactions during the read phase, this invention only needs to check for read-write conflicts during the transaction verification phase, resulting in a lower transaction rollback rate compared to OCC.

[0121] Example 4

[0122] Figure 4 This is a schematic diagram of a multi-version concurrency control device provided in Embodiment 4 of the present invention. Figure 4 As shown, the device includes:

[0123] The read module 410 is used to find the latest version of the target tuple that the current transaction needs to access during the read phase of the current transaction after the current transaction starts; if the latest tuple version is an uncommitted version, the dependency attribute information of the current transaction is recorded, and the latest tuple version is recorded in the read-write set of the current transaction; the read-write set includes: a read set and a write set;

[0124] The conflict detection module 420 is used to detect whether there is a read-write conflict in the current transaction if it is determined from the dependency attribute information that all dependent transactions of the current transaction have been committed.

[0125] The write module 430 is used to, if there is no read-write conflict, enter the write phase of the current transaction, update the target tuple corresponding to the tuple version in the write set of the current transaction, and notify the dependent transactions of the current transaction to release the dependency.

[0126] Optionally, the read module 410 includes:

[0127] The read lookup unit is used to determine whether the current transaction has accessed the first target tuple for the read operation of the current transaction; if not, it finds the first latest tuple version of the first target tuple that the current transaction needs to read.

[0128] The write lookup unit is used to find the second latest version of the second target tuple that the current transaction needs to write for the write operation of the current transaction.

[0129] Optional, also includes:

[0130] The waiting module is used to find the latest version of the target tuple that the current transaction needs to access, and if the latest tuple version is an uncommitted version, record the dependency attribute information of the current transaction and before recording the latest tuple version in the read-write set of the current transaction. If the latest tuple version is being modified by other transactions, continue to wait until the latest tuple version is not being modified by other transactions.

[0131] The read judgment module is used to determine whether the first latest tuple version is an uncommitted version for the read operation of the current transaction;

[0132] The write judgment module is used to obtain the lock of the second latest tuple version for the read operation of the current transaction, and to determine whether the second latest tuple version is an uncommitted version.

[0133] Optionally, the read module 410 includes:

[0134] The read record unit is used for the read operation of the current transaction. If the first latest tuple version is an uncommitted version, the write-read dependency information of the current transaction is recorded, the first latest tuple version is recorded in the read set of the current transaction, and the first latest tuple version in the read set is returned.

[0135] The write record unit is used for write operations of the current transaction. If the second latest tuple version is an uncommitted version, the write dependency information of the current transaction is recorded, a new tuple version is created, and the lock of the new tuple version is acquired. A version chain is generated between the second latest tuple version and the newly created tuple version, the locks of the second latest tuple version and the new tuple version are released, and the second latest tuple version is recorded in the write set of the current transaction.

[0136] Optionally, the dependency attribute information of the current transaction is recorded using a dependent linked list and a verification semaphore;

[0137] The dependent linked list is used to record the identifier and dependency type of the dependent transaction; the verification semaphore is used to indicate the number of uncommitted dependent transactions of the current transaction.

[0138] The dependency type includes at least one of the following: write-read dependency type, write-write dependency type, and read-write dependency type.

[0139] Optionally, the record reading unit includes;

[0140] The first recording subunit is used to increment the verification semaphore of the current transaction by one, and to record the identifier and write / read dependency type of the current transaction, which is the dependent transaction, into the dependent linked list of the dependent transactions that the current transaction depends on.

[0141] The write recording unit includes:

[0142] The second recording subunit is used to increment the verification semaphore of the current transaction by one, and will be used as the identifier of the current transaction of the dependent transaction, and the write dependency type will be recorded in the dependent chain list of the dependent transactions of the current transaction.

[0143] Optionally, the collision detection module 420 includes:

[0144] The conflict detection entry unit is used to determine that all dependent transactions of the current transaction have been committed if the verification semaphore in the dependency attribute information is zero, and then the current transaction enters the read-write conflict detection stage.

[0145] Optionally, the collision detection module 420 includes:

[0146] An execution order calculation unit is used to calculate the current serialization execution order of the current transaction during the read-write conflict detection phase.

[0147] The detection parameter acquisition unit is used to acquire read-write conflict detection parameters if there is a next tuple version for the latest tuple version and the next tuple version is a committed version, and update the read-write conflict detection parameters based on the start timestamp of the next tuple version; the read-write conflict detection parameters are used to record the minimum serialization execution order of write transactions that depend on the current transaction for read and write and have been committed.

[0148] The comparison unit is used to compare the current serialization execution order of the current transaction with the read-write conflict detection parameters;

[0149] The first comparison result determination unit is used to determine if the current serialization execution order is greater than or equal to the read-write conflict detection parameter, then the current transaction has a read-write conflict;

[0150] The second comparison result determination unit is used to determine that if the current serialization execution order is less than the read-write conflict detection parameter, then the current transaction does not have a read-write conflict.

[0151] Optional, also includes:

[0152] The read-write dependency determination module is used in the read-write conflict detection phase to calculate the current serialization execution order of the current transaction. If the latest tuple version has a next tuple version and the next tuple version is an uncommitted version, then the transaction that created the next tuple version of the latest tuple version is determined to be the dependent transaction of the current transaction, and the identifier of the dependent transaction and the read-write dependency type are recorded in the dependent list of the current transaction.

[0153] Optionally, the write module 430 includes:

[0154] The dependency release notification unit is used to traverse each dependent transaction in the dependent list, notify each dependent transaction to modify the dependent transaction information recorded in its own dependent list, and decrement its own transaction's verification semaphore by one.

[0155] Optional, also includes:

[0156] The dependency type acquisition module is used to acquire the dependency type between each dependent transaction in the dependent list and the current transaction after the dependent transaction of the current transaction is notified to release its dependency.

[0157] The execution order update module is used to update the serialization execution order of the dependent transaction based on the serialization execution order of the current transaction if the dependency type is a read-write dependency type.

[0158] The multi-version concurrency control device provided in the embodiments of the present invention can execute the multi-version concurrency control method provided in any embodiment of the present invention, and has the corresponding functional modules and beneficial effects of the execution method.

[0159] Example 5

[0160] Figure 5 A schematic diagram of an electronic device 10 that can be used to implement embodiments of the present invention is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices (e.g., helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0161] like Figure 5 As shown, the electronic device 10 includes at least one processor 11 and a memory, such as a read-only memory (ROM) 12 or a random access memory (RAM) 13, communicatively connected to the at least one processor 11. The memory stores computer programs executable by the at least one processor. The processor 11 can perform various appropriate actions and processes based on the computer program stored in the ROM 12 or loaded from storage unit 18 into the RAM 13. The RAM 13 may also store various programs and data required for the operation of the electronic device 10. The processor 11, ROM 12, and RAM 13 are interconnected via a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.

[0162] Multiple components in electronic device 10 are connected to I / O interface 15, including: input unit 16, such as keyboard, mouse, etc.; output unit 17, such as various types of displays, speakers, etc.; storage unit 18, such as disk, optical disk, etc.; and communication unit 19, such as network card, modem, wireless transceiver, etc. Communication unit 19 allows electronic device 10 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks. Processor 11 can be various general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 11 include, but are not limited to, central processing unit (CPU), graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. Processor 11 executes the various methods and processes described above, such as multi-version concurrency control methods.

[0163] In some embodiments, the multi-version concurrency control method may be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 18. In some embodiments, part or all of the computer program may be loaded and / or installed on electronic device 10 via ROM 12 and / or communication unit 19. When the computer program is loaded into RAM 13 and executed by processor 11, one or more steps of the multi-version concurrency control method described above may be performed. Alternatively, in other embodiments, processor 11 may be configured to execute the multi-version concurrency control method by any other suitable means (e.g., by means of firmware).

[0164] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0165] Computer programs used to implement the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be performed. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0166] In the context of this invention, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination thereof. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0167] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0168] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or computing systems that include middleware components (e.g., application servers), or computing systems that include frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0169] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and VPS services, such as high management difficulty and weak business scalability.

[0170] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.

[0171] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A multi-version concurrency control method, characterized in that, include: After the current transaction starts, during the read phase of the current transaction, find the latest version of the target tuple that the current transaction needs to access; If the latest tuple version is an uncommitted version, then the dependency attribute information of the current transaction is recorded, and the latest tuple version is recorded in the read-write set of the current transaction; the read-write set includes: a read set and a write set; If it is determined from the dependency attribute information that all dependent transactions of the current transaction have been committed, the current transaction enters the read-write conflict detection phase, in which the read-write conflict detection phase is performed to detect whether there is a read-write conflict in the current transaction based on the dependency attribute information. If there is no read / write conflict, the current transaction enters the write phase, during which the target tuple corresponding to the tuple version in the write set of the current transaction is updated, and the dependent transactions of the current transaction are notified to release the dependency. The step of finding the latest version of the target tuple that the current transaction needs to access includes: For the read operation of the current transaction, determine whether the current transaction has accessed the first target tuple; if not, find the first latest tuple version of the first target tuple that the current transaction needs to read. For the write operation of the current transaction, find the second latest version of the second target tuple that the current transaction needs to write; Wherein, the first target tuple is the tuple to be read by the read operation of the current transaction, the first latest tuple version is the latest tuple version of the first target tuple at the current moment, the second target tuple is the tuple to be updated or deleted by the write operation of the current transaction, and the second latest tuple version is the latest tuple version of the second target tuple at the current moment. After finding the latest version of the target tuple that the current transaction needs to access, and if the latest tuple version is an uncommitted version, recording the dependency attribute information of the current transaction, and before recording the latest tuple version in the read / write set of the current transaction, the method further includes: If the latest tuple version is being modified by other transactions, continue to wait until the latest tuple version is not being modified by other transactions; For the read operation of the current transaction, determine whether the first latest tuple version is an uncommitted version; For the read operation of the current transaction, acquire the lock of the second latest tuple version, and determine whether the second latest tuple version is an uncommitted version; If the latest tuple version is an uncommitted version, then the dependency attribute information of the current transaction is recorded, and the latest tuple version is recorded in the read / write set of the current transaction, including: For the read operation of the current transaction, if the first latest tuple version is an uncommitted version, then the write-read dependency information of the current transaction is recorded, the first latest tuple version is recorded in the read set of the current transaction, and the first latest tuple version in the read set is returned. For the write operation of the current transaction, if the second latest tuple version is an uncommitted version, then record the write dependency information of the current transaction, create a new tuple version, acquire the lock of the new tuple version; generate a version chain between the second latest tuple version and the newly created tuple version, release the locks of the second latest tuple version and the new tuple version, and record the second latest tuple version in the write set of the current transaction.

2. The method according to claim 1, characterized in that, The dependency attribute information of the current transaction is recorded using a dependent linked list and a verification semaphore; The dependent linked list is used to record the identifier and dependency type of the dependent transaction; the verification semaphore is used to indicate the number of uncommitted dependent transactions of the current transaction. The dependency type includes at least one of the following: write-read dependency type, write-write dependency type, and read-write dependency type.

3. The method according to claim 2, characterized in that, Record the write-read dependency information of the current transaction, including: The verification semaphore of the current transaction is incremented by one, and the identifier and write / read dependency type of the current transaction, which are the dependent transactions, are recorded in the dependent list of the dependent transactions that the current transaction depends on. Record the write-write dependency information of the current transaction, including: Incrementing the verification semaphore of the current transaction by one will serve as the identifier of the current transaction of the dependent transaction, and the write dependency type will be recorded in the dependent chain of the dependent transactions that the current transaction depends on.

4. The method according to claim 2, characterized in that, If, based on the dependency attribute information, it is determined that all dependent transactions of the current transaction have been committed, then the current transaction enters the read-write conflict detection phase, including: If the verification semaphore in the dependency attribute information is zero, it is determined that all dependent transactions of the current transaction have been committed, and the current transaction enters the read-write conflict detection phase.

5. The method according to claim 2, characterized in that, In the read-write conflict detection phase, the detection of whether a read-write conflict exists in the current transaction based on the dependency attribute information includes: In the read-write conflict detection phase, the current serialization execution order of the current transaction is calculated; If the latest tuple version has a next tuple version, and the next tuple version is a committed version, then the read-write conflict detection parameters are obtained, and the read-write conflict detection parameters are updated based on the start timestamp of the next tuple version; the read-write conflict detection parameters are used to record the minimum serialization execution order of the write transactions that depend on the current transaction for read and write operations and have been committed. Compare the current serialization execution order of the current transaction with the read-write conflict detection parameters; If the current serialization execution order is greater than or equal to the read-write conflict detection parameter, then the current transaction has a read-write conflict. If the current serialization execution order is less than the read-write conflict detection parameter, then the current transaction does not have a read-write conflict.

6. The method according to claim 5, characterized in that, In the read-write conflict detection phase, after calculating the current serialization execution order of the current transaction, the following steps are also included: If there is a next tuple version for the latest tuple version, and the next tuple version is an uncommitted version, then the transaction that creates the next tuple version for the latest tuple version is determined to be the dependent transaction of the current transaction, and the identifier and read / write dependency type of the dependent transaction are recorded in the dependent list of the current transaction.

7. The method according to claim 2, characterized in that, Notify the dependent transactions of the current transaction to release their dependencies, including: Iterate through each dependent transaction in the dependent list of the current transaction, notify each dependent transaction to modify the dependent transaction information recorded in its own dependent list, and decrement its own transaction's verification semaphore by one.

8. The method according to claim 7, characterized in that, After notifying the dependent transactions of the current transaction to release their dependencies, the process also includes: Get the dependency type between each dependent transaction in the dependent list and the current transaction; If the dependency type is a read-write dependency type, then the serialization execution order of the dependent transaction is updated based on the serialization execution order of the current transaction.

9. A multi-version concurrency control device, characterized in that, include: The read module is used to find the latest version of the target tuple that the current transaction needs to access during the read phase of the current transaction after the current transaction starts. If the latest tuple version is an uncommitted version, then the dependency attribute information of the current transaction is recorded, and the latest tuple version is recorded in the read-write set of the current transaction; the read-write set includes: a read set and a write set; The conflict detection module is used to detect whether there is a read-write conflict in the current transaction if it is determined from the dependency attribute information that all dependent transactions of the current transaction have been committed. The write module is used to enter the write phase if there is no read-write conflict. In the write phase, the target tuple corresponding to the tuple version in the write set of the current transaction is updated, and the dependent transactions of the current transaction are notified to release the dependency. The read module includes: a read lookup unit, used for determining whether the current transaction has accessed the first target tuple during a read operation of the current transaction; if not, finding the first latest tuple version of the first target tuple that the current transaction needs to read; and a write lookup unit, used for finding the second latest tuple version of the second target tuple that the current transaction needs to write during a write operation of the current transaction; wherein the first target tuple is the tuple to be read by the read operation of the current transaction, the first latest tuple version is the latest tuple version of the first target tuple at the current moment, the second target tuple is the tuple to be updated or deleted by the write operation of the current transaction, and the second latest tuple version is the latest tuple version of the second target tuple at the current moment; The device further includes: a waiting module, configured to, after finding the latest tuple version of the target tuple that the current transaction needs to access, and if the latest tuple version is an uncommitted version, record the dependency attribute information of the current transaction and before recording the latest tuple version into the read / write set of the current transaction; if the latest tuple version is being modified by other transactions, continue to wait until the latest tuple version is not being modified by other transactions; a read judgment module, configured to, for the read operation of the current transaction, determine whether the first latest tuple version is an uncommitted version; and a write judgment module, configured to, for the read operation of the current transaction, acquire the lock of the second latest tuple version and determine whether the second latest tuple version is an uncommitted version. The read module includes: a read record unit, used for read operations on the current transaction; if the first latest tuple version is an uncommitted version, then record the write-read dependency information of the current transaction, record the first latest tuple version in the read set of the current transaction, and return the first latest tuple version in the read set; and a write record unit, used for write operations on the current transaction; if the second latest tuple version is an uncommitted version, then record the write-write dependency information of the current transaction, create a new tuple version, acquire the lock of the new tuple version; generate a version chain between the second latest tuple version and the newly created tuple version, release the locks of the second latest tuple version and the new tuple version, and record the second latest tuple version in the write set of the current transaction.

10. An electronic device, characterized in that, The electronic device includes: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the multi-version concurrency control method according to any one of claims 1-8.

11. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that cause a processor to execute the multi-version concurrency control method according to any one of claims 1-8.

Images