CN113505114B - Multi-version concurrent control method for database and database system - Google Patents

Abstract

The embodiment of the present application provides a multi-version concurrency control method and database system for a database, and relates to the field of database technology. The method includes: when a target transaction is started, generating a transaction ID for the target transaction, the transaction ID includes the thread number of the working thread that starts the target transaction and the current local count value of the working thread; obtaining a logical snapshot of the database, and searching for the target visible version of the target transaction on the version chain corresponding to the target data record to be operated according to the logical snapshot; and performing a read or update operation on the version chain of the target data record based on the target visible version. The technical solution can provide an isolation level of snapshot isolation and improve the operating efficiency of transactions. Compared with existing methods, the concurrency control method has lower overhead and can significantly increase the transaction processing capability of the database, with a speedup ratio of up to 4.24 times.

Description

Multi-version concurrent control method for database and database system

Technical Field

The present application relates to the field of database technology, and in particular to a multi-version concurrency control method for a database and a database system.

Background technique

The database system is one of the important software that modern computer applications rely on. The database system has a transaction processing interface. When running transactions, it needs to use a concurrency control algorithm to provide a certain degree of isolation guarantee. The design of the concurrency control algorithm will greatly affect the transaction processing performance of the database system.

Traditional databases use a two-tier storage architecture based on memory and disk, where memory is used to provide runtime access to data and disk is used to ensure data persistence. Non-volatile memory (NVM) is a new type of storage medium that can support byte addressing like memory and store data persistently like disk. With the help of NVM, a new generation of databases with a single-tier storage structure can be realized. However, since the access speed of NVM is faster than that of disk, disk is no longer the performance bottleneck factor of NVM single-tier database system, so a more efficient concurrency control algorithm is needed to give full play to the performance of NVM.

Using a multi-version concurrency control algorithm is a common method to improve the performance of database transaction processing. Multi-version concurrency control can provide the isolation level of snapshot isolation and increase the concurrency of transaction processing. However, traditional concurrency control algorithms that support snapshot isolation often use a global counter to assign transaction IDs to transactions. Each worker thread needs to operate this global counter when starting a transaction, which will become a performance bottleneck factor of the database system and affect the performance of the database. In particular, when the number of worker threads is large, the efficiency of transaction processing is reduced.

Summary of the invention

The embodiments of the present application provide a database multi-version concurrency control method and a database system to solve the above technical problems.

In a first aspect, an embodiment of the present application provides a multi-version concurrency control method for a database, comprising: when a target transaction is started, generating a transaction ID for the target transaction, the transaction ID including the thread number of a working thread that starts the target transaction and a current local count value of the working thread, and after the transaction ID is generated, the local count value of the working thread is incremented by i, where i is a positive integer not less than 1; obtaining a logical snapshot of the database, and searching for a target visible version of the target transaction on a version chain corresponding to a target data record to be operated according to the logical snapshot; wherein the logical snapshot includes the transaction ID of the latest completed transaction corresponding to each working thread running in the database, and the version chain includes multiple versions of the target data record; based on the target visible version, performing a read or update operation on a data record on the version chain of the target data record through the target transaction.

In a second aspect, an embodiment of the present application provides a database system, including: a transaction ID allocation module, used to generate a transaction ID for a target transaction when a target transaction is started, the transaction ID including the thread number of a working thread that starts the target transaction and a current local count value of the working thread, after the transaction ID is generated, the local count value of the working thread is incremented by i, i is a positive integer not less than 1; a logical snapshot acquisition module, used to acquire a logical snapshot of a database; wherein the logical snapshot includes the transaction ID of the latest completed transaction corresponding to each working thread running in the database, and the version chain includes multiple versions of a target data record; a data record operation module, used to search for a target visible version of the target transaction on a version chain corresponding to a target data record to be operated according to the logical snapshot, and based on the target visible version, perform a read or update operation on a data record on the version chain of the target data record through the target transaction.

The present invention proposes a multi-version concurrency control method supporting snapshot isolation, which uses the local counter of each thread to assign a transaction ID to a transaction, and uses the transaction ID of the latest completed transaction corresponding to each thread to represent a logical snapshot. Compared with the existing concurrency control method supporting snapshot isolation, the method proposed by the present invention does not need to maintain a global counter, and each working thread only needs to operate its corresponding local counter, which reduces resource competition, can effectively improve transaction processing efficiency, and transaction throughput can be well expanded as the number of threads increases.

BRIEF DESCRIPTION OF THE DRAWINGS

The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings:

FIG1 shows a flow chart of a multi-version concurrency control method provided by an embodiment of the present application;

FIG2 shows a flowchart of a transaction at various stages in a multi-version concurrency control method provided in an embodiment of the present application;

FIG3 shows a schematic diagram of a specific implementation of a transaction ID in an embodiment of the present application;

FIG4 shows a schematic diagram of a specific implementation of a logical snapshot in an embodiment of the present application;

FIG5 shows a flowchart of obtaining a logical snapshot in step S12 in an embodiment of the present application;

FIG6 shows a structural diagram of a version chain in an embodiment of the present application;

FIG7 shows a flow chart of a transaction reading data records on a version chain during the transaction execution phase;

FIG8 shows a flow chart of a transaction updating data records on a version chain during the transaction execution phase;

FIG9 shows a schematic diagram of a database system provided in an embodiment of the present application;

FIG10 shows another schematic diagram of a database system provided in an embodiment of the present application;

FIG11 is a comparison chart showing experimental results obtained by comparing the N2DB-M system with the N2DB system in an embodiment of the present application;

FIG. 12 shows another comparison chart of experimental results obtained by comparing the N2DB-M system with the N2DB system according to an embodiment of the present application.

Detailed ways

The following is a detailed description of the exemplary embodiments of the present application in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present application, rather than an exhaustive list of all the embodiments. It should be noted that the embodiments and features in the embodiments of the present application can be combined with each other without conflict.

The embodiment of the present application provides a multi-version concurrency control method for a database. FIG1 shows a flow chart of the multi-version concurrency control method, and the flow includes:

S100: When a target transaction is started, a transaction ID is generated for the target transaction.

S200: Acquire a logical snapshot of the database, wherein the logical snapshot includes the transaction ID of the latest completed transaction corresponding to each working thread running in the database.

S300: Search the target visible version of the target transaction on the version chain corresponding to the target data record to be operated according to the acquired logical snapshot. The database includes several data records, and the data record to be operated by the target transaction is the target data record. Multiple versions of the same data record form a version chain.

S400: Based on the target visible version, a data record is read or updated on the version chain of the target data record through a target transaction.

In a specific embodiment, the life cycle of a transaction includes three stages: start, execute, and end. As shown in FIG2 , in the multi-version concurrency control method, the specific implementation methods of each stage include:

S1, transaction startup phase.

There are multiple worker threads running in the database. When a worker thread starts a transaction, it enters the transaction start phase. Taking the start of a target transaction as an example, the execution steps of the transaction start phase include:

S11. When the target transaction is started, a transaction ID is generated for the target transaction. The transaction ID includes the thread number of the working thread that starts the target transaction and the current local count value of the working thread. After the transaction ID is generated, the local count value of the working thread is incremented by i; i is a positive integer not less than 1. Optionally, i is 1.

The transaction ID of the target transaction is globally unique. FIG3 shows a specific implementation diagram of the transaction ID. As shown in FIG3 , the length of the transaction ID is 64 bits, of which the upper 8 bits are the thread number of the working thread, and the lower 56 bits are the value of the local counter of the working thread. After each transaction ID is allocated, the local counter of the working thread will be incremented by 1.

S12: Obtain a logical snapshot of the database, where the logical snapshot includes the transaction ID of the latest transaction completed by each working thread running in the database.

In this embodiment, the logical snapshot is represented by a vector clock. The vector clock is usually considered to be a set of clock values Vi[1], Vi[2], ..., Vi[n] from different nodes. This method uses it to represent the logical snapshot. The logical snapshot contains the transaction ID of the latest completed transaction of each working thread running in the database, which can represent the range of completed transactions in the database system when the snapshot is generated. FIG4 shows a specific implementation diagram of the logical snapshot, where S=[3,2,7,5] is a vector clock representation of the logical snapshot, which represents: the transaction ID of the latest completed transaction of all four working threads in the database. As shown in FIG4, the transaction ID of the latest completed transaction of thread 0 is T(0,3), where 0 represents the "thread number" and 3 represents the "local count value", the transaction ID of the latest completed transaction of thread 1 is T(1,2), the transaction ID of the latest completed transaction of thread 2 is T(2,7), the transaction ID of the latest completed transaction of thread 3 is T(3,5), and _tsi represents the "local count value" in the transaction ID of the latest completed transaction of working thread i.

In one embodiment, when the number of working threads in the database is fixed, the thread number of each working thread is continuous, and the logical snapshot can be represented by a fixed-length array, and each value in the array represents a local count value in the transaction ID, and the thread number in the transaction ID is implicit in the position relationship of each array. For example, if the value of the first position in the array is 3, the corresponding transaction ID is thread number "0" + local count value "3". In other embodiments, when the number of working threads in the database is variable, the thread numbers between the working threads are not necessarily continuous, and the snapshot can be represented in the form of a hash table.

FIG5 shows a flow chart of obtaining a logical snapshot in step S12. As shown in FIG5, S12 includes:

S121, determine whether there is a non-target transaction generating a logical snapshot; if not, jump to S122; if yes, jump to S124.

S122: Generate a new logical snapshot according to the transaction ID of the latest transaction completed by each working thread running in the database.

S123: Write the newly generated logical snapshot into the snapshot buffer.

S124: Use the latest snapshot in the snapshot buffer as the logical snapshot obtained this time.

In the above steps S121-S124, it is necessary to first determine whether other transactions are generating logical snapshots, and determine how to obtain the logical snapshots based on the determination results to ensure the correctness of snapshot isolation. As mentioned above, the snapshot actually describes the scope of completed transactions in the entire database system. For two different snapshots A and B, the scope of completed transactions they describe needs to satisfy an inclusion relationship, that is, either or In this embodiment, concurrent generation of snapshots is not allowed (ie, when a transaction generates a snapshot, other transactions cannot generate snapshots). This is to ensure that any two snapshots satisfy the above-mentioned inclusion relationship, thereby ensuring the correctness of snapshot isolation.

S2: Transaction execution phase.

After completing all the above operations, the transaction enters the execution phase. If the transaction is a read transaction, the transaction will read the data records in the database; if the transaction is a write transaction, the transaction will update the data records in the database. In any database, when a transaction reads/writes data, the database will define an isolation level, which describes what data the transaction can see (especially: whether/when it can see the data written by other concurrent transactions). Snapshot isolation is one of the isolation levels. In this embodiment, the operation results of the transaction reading/updating data records meet the requirements of snapshot isolation.

In this embodiment, the one-way linked list formed by multiple versions of the same data record is the version chain of the data record, and the structure of the version chain is shown in Figure 6. The version chain includes a head node and multiple version nodes. The head node includes the ID of the target data record and a pointer to the latest version (latest_version). The version node includes the transaction ID of the creator of the version, the payload data of the version, and a pointer to the previous version (prev_version).

In S2, the operations in the transaction execution phase are divided into transaction reading data records (S21) and transaction updating data records (S22). When a transaction reads a target data record in the database, it will find the target visible version along the version chain of the target data record in the multi-version storage based on the logical snapshot it holds and certain visibility rules, and read the content in the target visible version. Please refer to Figure 7, the specific process of a transaction reading a data record on the version chain includes:

S211. Obtain a version chain of the target data record in a database according to the ID of the target data record to be operated.

S212. Set the latest version in the version chain as the target version currently being examined.

S213. Obtain the transaction ID of the creator of the target version.

In S213, the transaction ID corresponding to the version node of the target version is obtained from the version chain.

S214 . According to the thread number in the creator's transaction ID, determine the local count value corresponding to the corresponding thread number from each transaction ID in the acquired logical snapshot.

The thread number and the local count value are extracted from the obtained transaction ID, and the local count value of the corresponding thread number is found from the logical snapshot according to the thread number, and the two local count values are compared.

S215. Determine whether the local count value in the creator's transaction ID is not greater than the local count value determined according to the logical snapshot; if greater, jump to S216; if not, jump to S217.

In S215 , the transaction ID of the creator of the target version is compared with the transaction ID of the latest completed transaction of the corresponding thread in the acquired snapshot, so as to determine whether the target version is created before the logical snapshot is generated.

S216, setting the previous version of the current target version as the new target version, and then jumping to S213.

S217, determine whether the creator's submission status is submitted; if it is submitted, jump to S218, if not submitted, jump to S216.

In this embodiment, each worker thread in the database maintains its own commit log, and the commit logs of each worker thread are decoupled. Each commit log records the commit status of all transactions on the corresponding thread (including running, committed, and rolled back). In S217, the transaction ID of the creator of the target version is used to query the commit log of the corresponding thread to obtain the commit status of the creator.

S218. Determine the current target version as the target visible version.

S219: The target transaction reads the payload data of the target visible version from the version chain.

When searching along the version chain, the transaction will select the first version created before the snapshot is generated and whose creator is in a committed state as the visible version to itself, that is, the target visible version. If there is no such version, the read operation will fail. For example, after examining a target version, if the examined version does not meet the requirements, the target version will be set to the previous version pointed to by the pointer of the current target version. The previous version may exist (prev_version pointer is not null) or may not exist (prev_version is a null pointer). When the target version does not exist, it indicates that the visible version cannot be found and the read operation fails.

After the target transaction determines the target visible version, it reads the payload data of the target visible version from the version chain to complete the data record reading operation.

Furthermore, when a transaction updates a target data record in the database, it needs to lock the data record and perform conflict detection based on the logical snapshot held. After the conflict detection passes, the data record update operation is performed. Please refer to Figure 8, the specific process of a transaction updating a data record on the version chain includes:

S221. Add a record lock to the version chain of the target data record; if the lock is successful, jump to S222; if the lock fails, jump to S225.

First, add a record lock to the version chain of the target data record that needs to be updated. If the lock fails, it means that a concurrent transaction is modifying the same data record. The update operation of the current target transaction fails and needs to enter the rollback process.

S222. Search for the target visible version of the target transaction on the version chain according to the logical snapshot.

S223. Check whether there is a version on the version chain that is newer than the target visible version of the target transaction, and the submission status of the creator of the newer version is submitted or running; if not, jump to S224; if so, jump to S226.

In S222-223, conflict detection is performed. Before updating the data record, it is necessary to determine whether the current target data record has been updated by a concurrent transaction to prevent write conflicts. The method for determining the visible version of the transaction on the version chain has been provided in the aforementioned steps S212-218. In S222, the same method is used to determine the target visible version of the target transaction based on the logical snapshot held by the target transaction, and conflict detection is performed based on the target visible version in S223. The principle of conflict detection is: there cannot be a version on the version chain that is newer than the visible version of the current transaction and is in the committed or running state. If such a version exists, the visible version has been modified by a concurrent transaction, the conflict detection fails, the current transaction cannot continue to update the data record, it will release the record lock, and execute the rollback process.

S224: The target transaction performs an update operation on the data record on the version chain.

After the conflict detection passes, the target transaction can continue to update the data record. The specific process is as follows:

1) Create a new version node for the target data record in the storage layer of the database;

2) Write the ID and payload data of the target transaction on the newly created version node;

3) Maintain the version chain pointer so that the pointer of the newly created version node points to the latest version in the current version chain, and the pointer of the head node of the current version chain points to the newly created version node;

4) Release the record lock on the version chain.

S225: Execute the rollback process for the target transaction.

S226. Release the record lock on the version chain and execute the rollback process for the target transaction.

After the target transaction completes the read/write operation of the data record in the transaction execution phase, it enters the transaction end process.

S3: Transaction end stage.

The end of a transaction includes two situations: commit and rollback. The concurrency control method in this embodiment handles these two situations uniformly. The steps for ending a transaction are:

S31. In the commit log of the working thread that starts the target transaction, the commit status of the target transaction is updated, and the commit status of the target transaction is recorded as committed or rolled back.

S32: Update the transaction ID of the latest completed transaction corresponding to the working thread to the transaction ID of the target transaction for use in subsequent snapshot generation processes.

Based on the above embodiment, the present application also provides a database system, which can be a database system based on non-volatile memory (NVM) or a database system based on a traditional disk or memory. The multi-version concurrency control method in this embodiment requires that the storage layer of the database adopts multi-version storage, as shown in FIG9 , and the database system includes:

(1) Commit log. In this embodiment, each worker thread in the database maintains its own commit log. The commit logs of each worker thread are decoupled. Each commit log records the commit status of all transactions on the corresponding thread (including running, committed, and rolled back).

(2) Snapshot buffer: The snapshot buffer is used to save logical snapshots of the database generated in the recent period of time.

(3) Version chain storage area. The version chain storage area stores multiple version chains, each of which corresponds to multiple versions of a data record. The version chain includes a head node and multiple version nodes. The head node includes the ID of the target data record and a pointer to the latest version. The version node includes the transaction ID of the creator of the version, the payload data of the version, and a pointer to the previous version.

As shown in FIG10 , the database system provided in the embodiment of the present application includes the following modules:

The transaction ID allocation module 410 is used to generate a transaction ID for the target transaction when the target transaction is started. The transaction ID includes the thread number of the working thread that starts the target transaction and the current local count value of the working thread. After the transaction ID is generated, the local count value of the working thread is incremented by i; i is a positive integer not less than 1;

The logical snapshot acquisition module 420 is used to acquire a logical snapshot of the database, wherein the logical snapshot includes the transaction ID of the latest transaction completed by each work thread running in the database, and the version chain includes multiple versions of the target data record;

The data record operation module 430 is used to search for the target visible version of the target transaction on the version chain corresponding to the target data record to be operated according to the logical snapshot; and based on the target visible version, perform a data record read or update operation on the version chain of the target data record through the target transaction.

It can be understood that the implementation principle and technical effects of the database system in this embodiment have been introduced in the aforementioned method embodiment. For the sake of brief description, the parts not mentioned in the database system can refer to the corresponding description in the aforementioned method embodiment and will not be repeated here.

In order to verify the actual use effect of the multi-version concurrency control method proposed in the present invention, the NVM database system using the multi-version concurrency control method provided by the embodiment of the present invention is recorded as "N2DB-M", and the NVM system using the PostgreSQL concurrency control method is recorded as "N2DB", and the performance of N2DB-M is compared with that of N2DB. The experimental environment is a single machine equipped with an 18-core CPU and 6 Optane non-volatile memory (NVM). The transaction throughput of the two systems is measured under different numbers of working threads, and the experimental results obtained are shown in Figures 11 and 12. Figure 11 shows the transaction throughput of the two systems under different numbers of threads when using load A, load B, and load C for experiments. Figure 12 shows the transaction throughput of the two systems under different numbers of threads when using TPC-C load and the TPC-C load parameter "number of warehouses" is equal to 1, equal to 4, and equal to the number of threads. Under these load experiments, N2DB-M has achieved a higher maximum transaction throughput than N2DB, and can obtain a nearly three-fold acceleration ratio.

The advantage of the multi-version concurrency control method provided by the present invention is that the performance of transaction processing can be expanded when the number of worker threads increases. From the experimental results, it can be seen that since the PostgreSQL concurrency control method adopted by N2DB uses a global counter to assign timestamps to transactions, the global counter needs to be locked when generating snapshots. Therefore, when the number of worker threads is large, the transaction throughput will decrease due to the global lock. However, the transaction throughput of N2DB-M can be well expanded as the number of worker threads increases.

In summary, the present invention designs a multi-version concurrency control method that supports snapshot isolation. The method uses the local counter of the working thread to assign a transaction ID to the transaction, removes the original global counter, and replaces the global counter with the local counter of each thread. Further, based on "multiple counters replace global counters", the present invention designs the operation process of the transaction, so as to correctly implement the isolation level of snapshot isolation. Since the prior art usually needs to lock the global counter in order to ensure the correctness of the snapshot, resulting in a bottleneck in its performance, in the present technical solution, each working thread only needs to operate its corresponding local counter, and each local counter does not need to be locked, which reduces resource competition and makes the present solution have better scalability. In addition, the commit log of each working thread in the present technical solution is decoupled, so there will be no write competition on the commit log, and the performance is better than the solution using the global commit log.

It should be noted that the concurrency control algorithm proposed in the present invention is universal and is applicable not only to NVM databases, but also to traditional disk or memory databases.

Those skilled in the art will appreciate that the embodiments of the present application may be provided as methods, systems, or computer program products. Therefore, the present application may adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment in combination with software and hardware. Moreover, the present application may adopt the form of a computer program product implemented in one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) that contain computer-usable program code.

The present application is described with reference to the flowchart and/or block diagram of the method, device (system) and computer program product according to the embodiment of the present application. It should be understood that each process and/or box in the flowchart and/or block diagram, and the combination of the process and/or box in the flowchart and/or block diagram can be realized by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device produce a device for realizing the function specified in one process or multiple processes in the flowchart and/or one box or multiple boxes in the block diagram.

These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer-readable memory produce a manufactured product including an instruction device that implements the functions specified in one or more processes in the flowchart and/or one or more boxes in the block diagram.

These computer program instructions may also be loaded onto a computer or other programmable data processing device so that a series of operational steps are executed on the computer or other programmable device to produce a computer-implemented process, whereby the instructions executed on the computer or other programmable device provide steps for implementing the functions specified in one or more processes in the flowchart and/or one or more boxes in the block diagram.

Although the preferred embodiments of the present application have been described, those skilled in the art may make other changes and modifications to these embodiments once they have learned the basic creative concept. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments and all changes and modifications falling within the scope of the present application.

Obviously, those skilled in the art can make various changes and modifications to the present application without departing from the spirit and scope of the present application. Thus, if these modifications and variations of the present application fall within the scope of the claims of the present application and their equivalents, the present application is also intended to include these modifications and variations.

Claims (11)

1. A multi-version concurrency control method for a database, comprising:

when a target transaction is started, generating a transaction ID for the target transaction, wherein the transaction ID comprises a thread number of a working thread for starting the target transaction and a current local count value of the working thread, and after the transaction ID is generated, the local count value of the working thread is incremented by i, wherein i is a positive integer not less than 1;

Obtaining a logic snapshot of a database, and searching a target visible version of the target transaction on a version chain corresponding to a target data record to be operated according to the logic snapshot; the logical snapshot comprises a transaction ID of a latest completed transaction corresponding to each working thread running in the database, and the version chain comprises a plurality of versions of a target data record;

based on the target visible version, performing reading or updating operation of the data record on a version chain of the target data record through the target transaction;

The version chain comprises a head node and a plurality of version nodes, the head node comprises an ID of a target data record and a pointer pointing to the latest version, the version nodes comprise a transaction ID of a version creator, load data of the version and a pointer pointing to the previous version, and the searching of the target visible version of the target transaction on the version chain corresponding to the target data record to be operated according to the logical snapshot comprises the following steps:

Acquiring a version chain of the target data record in the database according to the ID of the target data record to be operated; setting the latest version in the version chain as the currently inspected target version; acquiring a transaction ID of a creator of the target version; according to the thread number in the transaction ID of the creator, determining a local count value corresponding to the corresponding thread number from each acquired transaction ID in the logical snapshot; judging whether the local count value in the transaction ID of the creator is not more than the local count value determined according to the logical snapshot; if not, judging whether the submitted state of the creator is submitted; if so, determining the current target version as the target visible version.

2. The method of claim 1, wherein the obtaining a logical snapshot of the database comprises:

judging whether a non-target transaction is generating a logic snapshot or not;

if no non-target transaction is generating a logic snapshot, generating a new logic snapshot according to the latest transaction ID of the completed transaction of each working thread running in the database;

writing the newly generated logical snapshot into a snapshot buffer area;

and taking the latest snapshot in the snapshot buffer area as a logic snapshot of the database.

3. The method of claim 2, wherein after determining whether a non-target transaction is generating a logical snapshot, the method further comprises: if a non-target transaction is generating a logical snapshot, the latest snapshot in the snapshot buffer is obtained as the logical snapshot of the database.

4. The method according to claim 1, wherein the method further comprises:

If the local count value in the transaction ID of the creator is greater than the local count value determined according to the logical snapshot, or the commit status of the creator is not committed, setting the previous version of the current target version as a new target version, and then jumping to the transaction ID of the creator of the acquired target version.

5. The method of claim 1, wherein the performing a read or update operation of a data record on a version chain of a target data record by the target transaction based on the target visible version comprises: and if the target transaction is a read transaction, reading the load data of the target visible version from the version chain through the target transaction.

6. The method of claim 1, wherein the performing a read or update operation of a data record on a version chain of a target data record by the target transaction based on the target visible version comprises:

if the target transaction is a write transaction, adding a record lock for a version chain of the target data record through the target transaction;

detecting whether a version newer than the target visible version exists on the version chain and the commit status of the creator of the updated version is committed or running;

And if the version which meets the conditions does not exist on the version chain, carrying out updating operation of data record on the version chain through the target transaction.

7. The method of claim 6, wherein the updating of the data record on the version chain by the target transaction comprises:

creating a new version node for the target data record in a storage layer of the database;

writing the ID and the load data of the target transaction on the newly created version node;

maintaining a version chain pointer, enabling a pointer of a newly created version node to point to the latest version in a current version chain, and enabling a pointer of a head node of the current version chain to point to the newly created version node;

releasing the record lock on the version chain.

8. The method according to claim 6 or 7, characterized in that the method further comprises:

and if the record lock is failed to be added for the version chain of the target data record, executing a rollback flow for the target transaction.

9. The method of claim 6 or 7, wherein after detecting whether there is a version newer than the target visible version on the version chain and the commit status of the creator of the updated version is committed or running, the method further comprises:

And if the version which meets the conditions exists on the version chain, releasing the record lock on the version chain, and executing a rollback flow on the target transaction.

10. The method of claim 1, wherein after performing a read or update operation of a data record on a version chain of a target data record by the target transaction based on the target visible version, the method further comprises:

and updating the commit status of the target transaction in a commit log of a working thread which starts the target transaction, and updating the transaction ID of the latest completed transaction corresponding to the working thread to the transaction ID of the target transaction.

11. A database system, comprising:

the transaction ID distribution module is used for generating a transaction ID for a target transaction when the target transaction is started, wherein the transaction ID comprises a thread number of a working thread for starting the target transaction and a current local count value of the working thread, and after the transaction ID is generated, the local count value of the working thread is increased by i, wherein i is a positive integer not less than 1;

The logic snapshot acquisition module is used for acquiring a logic snapshot of the database; the logical snapshot comprises a transaction ID of a latest completed transaction corresponding to each working thread running in the database, and a version chain comprises a plurality of versions of a target data record;

the data record operation module is used for searching a target visible version of the target transaction on a version chain corresponding to the target data record to be operated according to the logic snapshot, and carrying out reading or updating operation of the data record on the version chain of the target data record through the target transaction based on the target visible version;

The version chain comprises a head node and a plurality of version nodes, the head node comprises an ID of a target data record and a pointer pointing to the latest version, the version nodes comprise a transaction ID of a version creator, load data of the version and a pointer pointing to the previous version, and the searching of the target visible version of the target transaction on the version chain corresponding to the target data record to be operated according to the logical snapshot comprises the following steps:

Acquiring a version chain of the target data record in the database according to the ID of the target data record to be operated; setting the latest version in the version chain as the currently inspected target version; acquiring a transaction ID of a creator of the target version; according to the thread number in the transaction ID of the creator, determining a local count value corresponding to the corresponding thread number from each acquired transaction ID in the logical snapshot; judging whether the local count value in the transaction ID of the creator is not more than the local count value determined according to the logical snapshot; if not, judging whether the submitted state of the creator is submitted; if so, determining the current target version as the target visible version.