Concurrent access control method, data processing method, device, storage medium, and program product

Abstract

Embodiments of the present disclosure provide a concurrent access control method, a data processing method, a device, a storage medium, and a program product. In the embodiments of the present disclosure, a concurrent access control scheme based on snapshot isolation technology is provided for a database. In the concurrent access control scheme, the concept of two-level timestamps is introduced: system-level timestamps and user-level timestamps; the user-level timestamps are applied to data items in a memory of a database, and concurrent access control is performed in a memory mode on the basis of the user-level timestamps; and the system-level timestamps are applied to data nodes in a persistent storage of the database, and concurrent access control is performed in a kernel mode on the basis of the system-level timestamps. In the embodiments of the present disclosure, the integration of the dual-level timestamps with the snapshot isolation technology can simplify the implementation of concurrent access control on the basis of the dual-level timestamps while the advantages of the snapshot isolation technology are exerted, and concurrent access control can be realized in both the memory mode and the kernel mode, thereby improving the concurrency performance of databases.

Description

[0001] Concurrent Access Control and Data Processing Method, Device, Storage Medium, and Program Product This disclosure claims priority to Chinese patent application number 202410371872.2, filed with the China Patent Office on March 28, 2024, and entitled "Concurrent Access Control and Data Processing Method, Device, Storage Medium, and Program Product," the entire contents of which are incorporated herein by reference. Technical Field This disclosure relates to the field of database technology, and more particularly to a concurrent access control and data processing method, device, storage medium, and program product. Background: To ensure transaction consistency, various storage products, such as databases, provide concurrent access control mechanisms for multiple readers and writers. Multiversion Concurrency Control (MVCC) is a widely used concurrent access control mechanism based on snapshot isolation technology. Currently, MVCC implementations vary across different database structures. In particular, concurrency control implementation is relatively complex in databases that use B-trees or their variants as indexes, leading to poor concurrency performance in some scenarios. Therefore, there is an urgent need for a simple concurrency control implementation that can guarantee snapshot isolation semantics, thereby improving database concurrency performance. Various aspects of the present disclosure provide a concurrent access control and data processing method, device, storage medium, and program product to simplify concurrent access control implementation and improve database concurrency performance. An embodiment of the present disclosure provides a multi-version concurrent access control method for a database, comprising: maintaining user-level timestamps for data items in memory of the database, where each user-level timestamp corresponds to a snapshot version of the data item in memory; maintaining system-level timestamps for data nodes in external memory of the database, where each system-level timestamp corresponds to a snapshot version of the data node in external memory, wherein the data node corresponds to at least one data item; and performing concurrent access control on transactions accessing the data items in memory using the user-level timestamps, and performing concurrent access control on transactions accessing the data nodes in external memory using the system-level timestamps.An embodiment of the present disclosure further provides a data processing method, comprising: generating a user-level read-only transaction in response to a data read request, the user-level read-only transaction including a query condition; determining a first read timestamp corresponding to the user-level read-only transaction from a user-level timestamp currently maintained for a data item in a database located in a memory; searching for target data that meets the query condition in a snapshot version in the memory having a user-level timestamp less than or equal to the first read timestamp; if the target data is not found in the memory, determining a second read timestamp corresponding to the user-level read-only transaction from a system-level timestamp currently maintained for a data node in the database located in an external memory; and searching for the target data that meets the query condition in a snapshot version in the external memory having a system-level timestamp less than or equal to the second read timestamp. An embodiment of the present disclosure further provides a data processing method, comprising: generating, in response to a data write request, a user-level write-only transaction, the user-level write-only transaction being used to indicate writing to-be-written data into a database, the to-be-written data corresponding to a target data item; executing the user-level write-only transaction to write the to-be-written data into a memory of the database to generate a new snapshot version corresponding to the target data item; assigning a user-level timestamp to the user-level write-only transaction upon committing the user-level read-only transaction, and recording the user-level timestamp and the new snapshot version corresponding to the target data item; executing a persistence transaction upon satisfying a persistence condition corresponding to the memory to persistently store each data item in the memory in at least one target data node in external memory of the database to generate a new snapshot version corresponding to the at least one target data node; and assigning a system-level timestamp to the persistence transaction upon committing the persistence transaction, and recording the system-level timestamp and the new snapshot version corresponding to the at least one target data node. An embodiment of the present disclosure also provides a multi-version concurrent access control device for a database, comprising: a first maintenance module, configured to maintain user-level timestamps for data items in the database located in memory, where one user-level timestamp corresponds to a snapshot version of the data item in memory; a second maintenance module, configured to maintain system-level timestamps for data nodes in the database located in external memory, where one system-level timestamp corresponds to a snapshot version of the data node in external memory, where the data node corresponds to at least one data item; and a concurrent access control module, configured to perform concurrent access control on transactions accessing data items in memory using user-level timestamps, and to perform concurrent access control on transactions accessing data nodes in external memory using system-level timestamps.An embodiment of the present disclosure further provides a data processing device, comprising: a generation module, configured to generate a user-level read-only transaction in response to a data read request, wherein the user-level read-only transaction includes a query condition; a first determination module, configured to determine a first read timestamp corresponding to the user-level read-only transaction from a user-level timestamp currently maintained for a data item in a database located in a memory; a first query module, configured to query a snapshot version in the memory having a user-level timestamp less than or equal to the first read timestamp for target data that meets the query condition; a second determination module, configured to determine a second read timestamp corresponding to the user-level read-only transaction from a system-level timestamp currently maintained for a data node in the database located in an external memory, if the target data is not found; and a second query module, configured to query a snapshot version in the external memory having a system-level timestamp less than or equal to the second read timestamp for the target data that meets the query condition. An embodiment of the present disclosure further provides a data processing device, comprising: a generation module, configured to generate, in response to a data write request, a user-level write-only transaction, the user-level write-only transaction being used to indicate writing to-be-written data into a database, the to-be-written data corresponding to a target data item; a first execution module, configured to execute the user-level write-only transaction to write the to-be-written data into the database's memory to generate a new snapshot version corresponding to the target data item; a first allocation module, configured to, upon the user-level read-only transaction being committed, assign a user-level timestamp to the user-level write-only transaction and record the new snapshot version corresponding to the user-level timestamp and the target data item; a second execution module, configured to, upon the persistence condition corresponding to the memory being met, execute the persistence transaction to persistently store each data item in the memory in at least one target data node in the database's external memory to generate a new snapshot version corresponding to the at least one target data node; and a second allocation module, configured to, upon the persistence transaction being committed, assign a system-level timestamp to the persistence transaction and record the new snapshot version corresponding to the system-level timestamp and the at least one target data node. The embodiments of the present disclosure further provide a computer-readable storage medium, including a computer program / instruction. When the computer program / instruction is executed by a processor, the steps in the multi-version concurrent access control method for a database and the data processing method are executed.Embodiments of the present disclosure also provide a computer program product, including a computer program / instructions. When executed by a processor, the computer program / instructions perform the steps of the multi-version concurrent access control method for a database and the data processing method. Embodiments of the present disclosure also provide an electronic device, including a memory and a processor. The memory is configured to store one or more computer instructions, and the processor is configured to execute the one or more computer instructions to perform the steps of the multi-version concurrent access control method for a database and the data processing method. Embodiments of the present disclosure provide a concurrent access control scheme for a database based on snapshot isolation technology. This concurrent access control scheme proposes the concepts of two levels of timestamps: system-level timestamps and user-level timestamps. User-level timestamps are used for concurrent access control in memory state for data items in database memory based on user-level timestamps. System-level timestamps are used for concurrent access control in system state for data nodes in database external memory based on system-level timestamps. In the embodiments of the present disclosure, two-layer timestamps are integrated with snapshot isolation technology. While leveraging the advantages of snapshot isolation technology, the two-layer timestamps simplify the implementation of concurrent access control and enable concurrent access control in both memory and system states, which helps improve database concurrency performance. BRIEF DESCRIPTION OF THE DRAWINGS The accompanying drawings described herein are provided to provide a further understanding of the present disclosure and constitute a part of the present disclosure. The illustrative embodiments of the present disclosure and their descriptions are intended to explain the present disclosure and are not intended to unduly limit the present disclosure.In the accompanying drawings: FIG1 is a schematic diagram of the logical data organization within a database provided by an exemplary embodiment of the present disclosure; FIG2 is a schematic diagram of the relationship between different timestamps and system-level transactions provided by an exemplary embodiment of the present disclosure; FIG3 is a schematic diagram of the flow of a multi-version concurrency control method provided by an exemplary embodiment of the present disclosure; FIG4 is a schematic diagram of the logical organization structure of a mapping table provided by an exemplary embodiment of the present disclosure; FIG5a is a schematic diagram of suffix compression of a node update list provided by an exemplary embodiment of the present disclosure; FIG5b is a schematic diagram of prefix compression of a node update list provided by an exemplary embodiment of the present disclosure; FIG6 is a schematic diagram of a situation in which a system-level merge (Compaction / GC) transaction and a persistence transaction occur successively according to an exemplary embodiment of the present disclosure; FIG7a-7c are schematic diagrams of a situation in which a system-level overwrite transaction and a persistence transaction occur successively and concurrently according to an exemplary embodiment of the present disclosure; FIG8a-8c are schematic diagrams of a situation in which a system-level split (Split) transaction, a system-level overwrite (Overwrite) transaction, and a persistence transaction occur successively and concurrently under an SMO provided by an exemplary embodiment of the present disclosure; FIG9 is a schematic diagram of the flow of a data processing method provided by an exemplary embodiment of the present disclosure; Figure 10 is another flow chart of a data processing method provided by an exemplary embodiment of the present disclosure; Figure 11 is a schematic diagram of the structure of a multi-version concurrent access control device for a database provided by an exemplary embodiment of the present disclosure; Figure 12 is a schematic diagram of the structure of a database data processing device provided by an exemplary embodiment of the present disclosure; Figure 13 is a schematic diagram of the structure of another database data processing device provided by an exemplary embodiment of the present disclosure; and Figure 14 is a schematic diagram of the structure of an electronic device provided by an exemplary embodiment of the present disclosure. DETAILED DESCRIPTION To further clarify the objectives, technical solutions, and advantages of the present disclosure, the technical solutions of the present disclosure will be described clearly and completely below in conjunction with specific embodiments of the present disclosure and the corresponding drawings. Obviously, the described embodiments are only some of the embodiments of the present disclosure, and are not exhaustive. All other embodiments derived by persons of ordinary skill in the art based on the embodiments of the present disclosure without inventive effort are within the scope of protection of the present disclosure.It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, storage, and display) involved in this disclosure are all authorized by the user or fully authorized by all parties. The collection, use, and processing of relevant data must comply with relevant laws, regulations, and standards in the relevant region, and corresponding operation portals are provided for users to choose to authorize or deny. In addition, the various models involved in this disclosure (including but not limited to language models or large models) comply with relevant laws and standards. Snapshot isolation is an isolation mechanism whereby each transaction reads data from a database snapshot. The transaction sees all data submitted before it begins. Even if some data is modified later, the transaction is not affected; the transaction only reads the old data version before the modification. With the emergence of the snapshot isolation mechanism, some databases that support it have emerged. In the embodiments of this disclosure, databases that support the snapshot isolation mechanism are described, and these databases use MVCC to implement concurrent access control between read and write transactions. There are no restrictions on the product implementation form of a database; it can be a variety of cloud storage systems, data warehouses, or databases that provide data storage capabilities. A database has a database engine, which is responsible for processing various read and write transactions and controlling concurrent access to the database. In a database that supports snapshot isolation, each piece of data has at least one historical version, and each historical version records a corresponding commit timestamp (ct). A transaction (denoted as T1) obtains a start timestamp (st) at the start of the transaction. If transaction T1 reads data A, it can read historical versions of data A where ct < st. Since these historical versions are not locked by write operations again, read-write conflicts will not occur. If transaction T1 modifies data A, when it commits the modified data A, it obtains a Ct value. This Ct value is greater than any existing timestamps in the database at that time (including st and ct). When the modified data A is persisted, this ct value is stored as the data item's version timestamp.That is to say, in the database, each time a transaction that modifies data is submitted, a row of snapshot data will be generated. The database engine will record the snapshot data of this row of data. The logical state of a row of snapshot data can be regarded as a tuple: ({k, v}, [begin-ts, end-ts), readers); where {k, v} is a key-value pair, representing user data stored on the storage medium. The key-value pair here is only an example of user data, and the implementation of user data is not limited to the key-value pair structure: begin-ts represents the timestamp (begin-timestamp) when the key-value pair becomes effective after the write transaction is submitted, that is, the ct assigned when the write transaction is submitted; end-ts represents the timestamp (end-timestamp) when the key-value pair is effective. [begin-ts, end-ts) represents the timestamp range in which the key-value pair is effective; readers represent the objects that read the key-value pair and are used to track transactions that are still accessing a row of snapshot data. In a database, when a database engine receives a transaction requesting to read data (referred to as a read transaction), it assigns a read timestamp (read-ts) to each read transaction. This read timestamp determines the snapshot data visible to the read transaction. For a read transaction, it is necessary to determine within which time period (begin-ts, end-ts) its read timestamp falls. The row {k, v} corresponding to the time period (begin-ts, end-ts) that the read timestamp falls within will be visible. In actual physical implementations, a linked list is often used to maintain different versions of snapshot data corresponding to the same user data (such as a key). Depending on the implementation, the timestamps (timestamp, ts) of these versions may be in ascending order (i.e., sorted from smallest to largest timestamp) or descending order (i.e., sorted from largest to smallest timestamp). If the order is ascending, the end-ts of the previous version equals the begin-ts of the next version. Generally, the end-ts can be ignored in the previous version, and only the begin-ts is used to distinguish snapshots of different versions corresponding to the same user data. If the order is descending, the begin-ts of the previous version equals the end-ts of the next version. Generally, the end-ts can be ignored in the next version, and only the begin-ts is used to distinguish snapshots of different versions corresponding to the same user data. Table 1 below shows the logical data organization relationship under the MVCC mechanism: Table 1. In Table 1, key k1 corresponds to three versions of snapshot data, and key k2 corresponds to two versions of snapshot data. The different versions of snapshot data are arranged in ascending timestamp order. Furthermore, for the second version of key k1, there is a reader:tx1: and for the second version of key k2, there is a reader:tx1. It should be noted that the linked list merely logically describes the relationship between different versions of snapshot data corresponding to the same key. In actual storage, the data in the linked list can be stored in memory or on a persistent storage medium, such as a disk, without limitation. In the database provided in the embodiments of the present disclosure, a database index is used to locate the location of a row of snapshot data in the linked list or storage medium. From the perspective of actual storage, a row of snapshot data in a linked list can be stored using a portion of the storage space in a physical storage medium (such as memory or disk). In the disclosed embodiments, the object in the physical storage medium used to store snapshot data is referred to as a data node. In specific implementations, a data node can be a page or a file (such as a std file), depending on the storage structure and data organization granularity used by the database. Generally speaking, a file typically contains multiple pages. If a row of snapshot data has no readers and the read-ts currently allocated by the database exceeds the end-ts corresponding to that row of data, this indicates that the row of data has expired. A garbage collection (GC) operation can be triggered to free up the storage space occupied by the expired data. The logic of the GC operation is to delete expired data, such as the first and third rows of data in Table 1. The specific execution of the GC operation varies depending on the storage medium where the data resides.If the linked list is in memory (i.e., stored in memory), performing a GC operation involves deleting rows from the linked list that have no readers and whose end-ts are less than the current read-ts. If the linked list is in disk (i.e., stored on disk), performing a GC operation involves deleting rows from the linked list that have no readers and whose end-ts are less than the current read-ts. If the in-place write method is used, subsequent writes can fill the vacated storage space, and the GC operation is completed. If the append-only write method is used, after deleting the rows, the valid data must be migrated to achieve continuous storage. Finally, the GC operation is completed and the database index is updated to reflect the new physical location of the valid data. It should be noted that in addition to performing GC operations on linked lists that store data, compaction operations can also be performed. Compaction and garbage collection are essentially similar. Compaction involves selecting some data nodes, bulk-deleting old versions of snapshot data on these nodes, and merging the latest versions into new data nodes on append-only storage. A detailed definition of compaction is provided below. Garbage collection does not involve bulk-deleting old versions of snapshot data (such as key-value data). Instead, it moves only valid data from certain data nodes and then bulk-deletes the data from these nodes. Transactions involving write operations (referred to as write transactions) can be implemented using locks to avoid conflicts. These can be based on optimistic concurrency control (OCC) or pessimistic locking, such as two-phase locking (2PL) write locks. Lock granularity can be row-level (user) or database-level (system). Write transactions are assigned new timestamps in commit order. These timestamps are logically increasing and are used to determine the logical time order and visibility of different write transactions.The above description only provides the concept of timestamps from a logical perspective, without defining their meaning or specific implementation. In the disclosed embodiments, two concepts, memory state and system state, are provided for databases. Two sets of timestamps are provided for these two states: user-level timestamps for the memory state and system-level timestamps for the system state. Based on these two sets of timestamps, a database index-based multi-version concurrent access control method is provided to resolve conflicts between read and write transactions in the database at both the memory and system state levels. Memory state and system state are defined based on the data storage state in the database. In a database, memory refers to the database's internal memory, while external memory refers to the database's external memory. Memory offers faster read and write speeds, but has a relatively smaller capacity and higher cost. External memory offers slower read and write speeds, but has a larger capacity and lower cost. Database memory generally stores currently used or active data. The storage state of this data is called the memory state. Database external memory primarily stores data that requires persistence. The storage state of this data is called the system state. In database memory, data is organized and managed at the data item granularity; in database external memory, data is organized and managed at the data node granularity. Data nodes have a larger granularity than data items. Data nodes that actually store user data typically contain multiple data items. An explanation of data nodes is provided below. The following first explains conflicts between user-level timestamps, system-level timestamps, database index structures, and read and write transactions in this disclosed solution.Defining user-level timestamps from user-level transactions to implement snapshot isolation semantics: In the disclosed embodiments, a database implementation that complies with snapshot isolation semantics is provided to users and supports user-level timestamps (user ts) for sequencing user-level transactions. User-level transactions refer to transactions that perform read and write operations on in-memory data items, including user-initiated read-only transactions and write-only transactions, referred to as user-level read-only transactions and user-level write-only transactions, respectively. A user-level timestamp is a timestamp concept provided by in-memory data items and is also a timestamp assigned to a transaction accessing an in-memory data item when a user-level write-only transaction commits. The user-level timestamp corresponding to a user-level write-only transaction is recorded together with the new version of snapshot data generated by the user-level write-only transaction, forming the row of snapshot data mentioned above. The user-level timestamp can be implemented as the begin-ts in the row of snapshot data mentioned above. In the disclosed embodiments, user-level timestamps are used in kernel mode to achieve snapshot semantic isolation between user-level read-only transactions (i.e., concurrent execution), and snapshot semantic isolation between user-level read-only transactions and user-level write-only transactions (i.e., concurrent execution). Row locks, such as 2PL, can be used to achieve snapshot semantic isolation between user-level write-only transactions, but this locking mechanism is not limited to this. As shown in Figure 1, user-level timestamps include 0-999, 1000-1999, 2000-2999, and 3000-3999, indicating that a user submitted a user-level write-only transaction to the database at the time corresponding to user-level timestamps 0-3999. When a user-level write-only transaction is submitted, a user-level timestamp is assigned to each submitted user-level write-only transaction in an ascending order. The purpose of the user-level timestamp is to provide the corresponding version of snapshot data to the read-only transaction when the read-only transaction accesses the in-memory data item. This is based on the user-level timestamp of each snapshot data. The read-only transaction can then access the snapshot data of that version. At the same time, the write-only transaction is allowed to modify the same data item simultaneously. This allows the data item to be modified while being read, preventing read-write conflicts and ensuring the correctness of read and write operations.In the disclosed embodiments, the method of assigning user-level timestamps to user-level write-only transactions is not limited. For example, a global timestamp can be provided as a user-level timestamp using a mechanism similar to the epoch mechanism. The user-level timestamp gradually increases during the database lifecycle and also increases across databases. This ensures efficiency while also ordering transactions within the redo log. The epoch mechanism is used in garbage collection algorithms. Each operation is registered with an epoch at the start. Based on physical time, every 10 milliseconds can be considered an epoch. The epoch count is incremented when an operation begins and decremented when it ends. When all operations in an epoch are completed, that is, when the count reaches 0, all resources in that epoch are released. In the disclosed embodiments, the principle of allocating epochs using the epoch mechanism is used to assign user-level timestamps in this case. Of course, the principle of allocating epochs using the epoch mechanism can also be used to assign system-level timestamps in this case. However, unlike epochs, both user-level and system-level timestamps in this case correspond to logical time, not physical time. Epoch literally means era. In the disclosed embodiments, for user-level write-only transactions, as shown in Figure 1, data is first written to a memtable. When each memtable meets the persistence condition, the data in the memtable is persisted to disk. In Figure 1, the circled numbers 11, 12, 13, and 14 represent different persistence operations and their corresponding persistence timestamps. The persistence condition can be, without limitation, that the memtable is full or that the amount of data in the memtable reaches a set percentage. In the disclosed embodiments, the operation of persisting the data in the memtable to disk when the memtable meets the persistence condition is called a checkpoint operation. In the disclosed embodiments, each persistence operation is assigned a timestamp, referred to as a persistence timestamp and expressed as a Checkpoint Timestamp (cp ts). As shown in Figure 1, user-level timestamps start at 0, while persistence timestamps start at 10. This may be due to a process restart (other persistence operations were performed before the restart; these operations also have timestamps assigned and are not cleared by the process restart) or other operations triggering a persistence operation before the user-level write-only transaction. This is not a limitation.As can be seen, persistent timestamps and user-level timestamps can have their own timestamp mechanisms and can be independent of each other. The starting values ​​and interval steps of the timestamps can be different, or they can be the same, without limitation. In the embodiments of the present disclosure, the interval steps of various timestamps are not limited; they can differ by 1, 2, 3, or 5, for example. In the various embodiments of the present disclosure, the interval between adjacent timestamps is 1 as an example for illustration and description, but the present disclosure is not limited to this. Of course, persistent timestamps also gradually increase or are sequentially numbered during the database lifecycle. In the embodiments of the present disclosure, persistent timestamps can be viewed as a stage summary of user-level timestamps over a period of time, and each persistently stored data can be used as a version for snapshot isolation. During each persistence operation, historical versions of the same key in a memtable are merged and written to persistent storage (such as disk). This is possible because, after a memtable is persisted, it can only be deleted if no user-level timestamps of the data in the memtable are directly referenced. New snapshot data can reference the first user-level timestamp in the memtable. Under the database's MVCC mechanism, which represents the logical state of snapshot data as a tuple ({k, v}, [begin-ts, end-ts), readers), snapshot isolation between transactions across the database is implemented based on user-level timestamps. However, this implementation of snapshot isolation based on user-level timestamps is limited to accessing data within the memtable. Specifically, when the data being accessed is located in the memtable, user-level timestamps can be used for lookups. When the data being accessed has been persisted to persistent storage (i.e., external memory), such as when accessing data in a physical page or file list, the persistent timestamp corresponding to the last persist operation preceding the user-level timestamp corresponding to the current access operation is used for access. Based on this, the logical state of the snapshot data can also be expressed as a tuple: ({k, v}, [begin-cp-ts, end-cp-ts), readers), where begin-cp-ts represents the timestamp when the key-value pair represented by the persistence timestamp begins to take effect, that is, the persistence timestamp assigned after the persistence operation is submitted; end-cp-ts represents the timestamp when the key-value pair represented by the persistence timestamp ends to take effect, which may be the persistence timestamp after the next persistence operation is submitted.With reference to Figure 1, the following example illustrates user access operations. In Figure 1, assume that a user txl currently initiates a user-level read-only transaction. Based on the relevant conditions of the user-level read-only transaction, the user-level read-only transaction is assigned a read timestamp of read-ts=2444. The read timestamp is any user-level timestamp maintained in the system. read-ts=2444 corresponds to a persistent timestamp of cpts=13. The database engine first searches the memory table corresponding to the persistent timestamp cpts=13 for the data required by user txl, where the user-level timestamp corresponding to this memory table is between 2000 and 2999. If the data required by user txl is not found, or if data with a user-level timestamp greater than 2444 is found, the database engine searches for the data required by user txl in persistently stored data with a cpts less than 13. In Figure 1, the logical data organization relationship under the MVCC mechanism is still represented by a linked list. Introduction to Database Indexes: In the database of this embodiment, data is stored on a persistent storage medium such as a disk (i.e., external memory) at the node level. This can also be simply understood as data storage in pages. For ease of distinction and description, the nodes that actually store user data are referred to as base nodes. The user data stored in each base node belongs to a set of user data defined by [begin-cp-ts, end-cp-ts], such as key-value pairs. Furthermore, database indexes are used to organize and manage user data in base nodes within the database. Accessing user data in the database's external memory is the same as accessing the database index. In this disclosed embodiment, a database index is a variant of a B-tree, consisting of a root node, an inner node, and leaf nodes. An index node contains a set of index key ranges and the address information of the next-level index nodes or leaf nodes corresponding to these index key ranges. Leaf nodes are base nodes that store user data. An index key refers to the key used to construct the index in the key-value pairs stored in the database. The index node does not point to the user data in the base node, but rather to index information such as the index node or base node address that facilitates locating the user data. User data can be retrieved from the base node on the persistent storage medium. Queries within the base node are determined by its format. When the amount of data stored in the base node is large, user data can be organized and managed within the base node using a B-tree approach, but this is not limited to this approach.Based on the database index, for any user-level read-only transaction, the address information of the underlying nodes that overlap with the index key range and persistence timestamp can be found from the database index based on an index key range and persistence timestamp. This allows for the effective reorganization of data on the persistent storage medium, thereby improving the performance of subsequent operations or recovering storage space through garbage collection (GC). The disclosed embodiments do not limit the specific implementation of the database index. In terms of implementation, the database index in the disclosed embodiments can refer to designs such as Bw-tree and Bepsilon-tree. Any index structure designed for append-only storage scenarios (especially high-concurrency storage scenarios) that can utilize a mapping mechanism is applicable to the disclosed embodiments. For ease of description, the database index in the disclosed embodiments may also be referred to as an index tree. In the following embodiments, the terms index tree and database index refer to the same object. In the disclosed embodiments, index nodes and leaf nodes in the index tree are collectively referred to as data nodes. Accessing user data in database external storage specifically refers to accessing data nodes in the index tree. The index tree assigns a unique identifier to each data node (including index nodes and leaf nodes). Data nodes are elastic and resilient, and a node update list is added to each data node. Modifications to a data node, including insertions, modifications, and deletions, are incrementally appended to the node update list. A mapping table records the physical address of each data node and its corresponding node update list. Therefore, on the write path, when a data node is modified, the modification is not performed in-place. Instead, the modification is recorded in the node update list corresponding to the data node. Furthermore, since the unique identifier of the data node remains unchanged, the modification does not need to be propagated to the root node of the index tree layer by layer. Accordingly, on the read path, the physical address of the data node can be obtained through index tree conversion. Querying involves merging the modifications recorded in the data node and its corresponding node update list, and searching within the merged content rather than searching directly within the data node. In the embodiment of the present disclosure, the data node may be an index node in the index tree or a leaf node.The persistence operations mentioned above typically involve operations on leaf nodes, while the system-level transactions mentioned below may involve operations on both index nodes and leaf nodes. Furthermore, when a data node's node update list contains too many modification operations, a compaction operation can be performed on this data node to improve read efficiency and reduce read operation costs. In the disclosed embodiments, compaction operations performed on data nodes include: Compaction operations that do not require the data node's participation, i.e., only the modification operations recorded in the node update list are consolidated. This type of compaction operation is called a partial compaction, or simply a merge operation; and Compaction operations that require the data node's participation, i.e., consolidating the modification operations recorded in the data node's node update list. This type of compaction operation is called a compaction with overwrite, or an overwrite operation. In addition to compaction operations, SMOs (Structure Modification Operations) can also be performed on the index tree, such as node splits and merges. A node split operation refers to splitting a data node into two or more data nodes; a node merge operation refers to merging two or more data nodes into one data node. The nodes involved in the Split and Merge operations are base nodes (i.e., leaf nodes). Of course, during the splitting or merging of base nodes, the modification operations recorded in the node update list must be considered. In other words, both the base node and its corresponding node update list must be considered. This will be described in detail later. As can be seen from the above analysis, in the disclosed embodiments, database transactions include, but are not limited to, user-level read-only transactions, user-level write-only transactions, and non-user-initiated checkpoints, garbage collection / compactions, and storage management operations (SMOs). In the disclosed embodiments, database transactions are divided into two categories: user-level transactions and system-level transactions. User-level transactions include user-level write-only transactions and user-level read-only transactions. System-level transactions are transactions that are not initiated by users but are automatically initiated by the system for optimization, management, and other reasons, such as checkpoints, garbage collection / compactions, and storage management operations.Furthermore, based on the read and write characteristics of various system-level transactions, system-level transactions are divided into system-level write-only transactions and system-level read-write transactions. System-level write-only transactions refer to transactions that only perform write operations, while system-level read-write transactions refer to transactions that perform both read and write operations. System-level write-only transactions include persistence operations (i.e., checkpoints), while system-level read-write transactions include, but are not limited to, garbage collection / compaction and storage mechanism operations (SMO). Furthermore, in the disclosed embodiments, concepts such as system state and system-level timestamps (systs) are proposed for system-level transactions. Based on user-level and system-level timestamps, a database index-based MVCC method is provided to address the challenges of effectively implementing MVCC in the aforementioned database index structure, ensuring the full implementation of snapshot isolation semantics for both user-level and system-level transactions. The following describes the system-level timestamps proposed based on system-level transactions. Defining system states and system-level timestamps based on system-level transactions to implement snapshot isolation semantics: This embodiment also proposes the concept of system-level transactions for databases, and also the concept of system-level timestamps for these transactions. A system-level timestamp is assigned to a system-level transaction upon its commit. The system-level timestamp monotonically increases with each commit, serving to sequence system-level transactions. Each system-level transaction generates a snapshot version upon commit. In this embodiment, the read and write states generated by system-level transactions for data in external memory (or index trees) are referred to as system states. Each system state corresponds to a system-level timestamp. This system-level timestamp allows different transactions to modify the same data simultaneously without conflict. In this embodiment, a checkpoint can be considered a system-level write-only transaction corresponding to a user-level write-only transaction, or a conversion or mapping from a user-level write-only transaction to a system-level write-only transaction. In practical applications, multiple transactions may simultaneously access the same data node in external memory. This is called system-level concurrent transactions. Using system-level timestamp and snapshot isolation technology, we can implement concurrent access control for system-level concurrent transactions. System-level concurrent transactions include user-level read-only transactions, system-level write-only transactions, and concurrency between system-level read-write transactions.When using system-level timestamp and snapshot isolation technology, user-level read-only transactions can execute concurrently with user-level read-only transactions, user-level read-only transactions with system-level write-only transactions, user-level read-only transactions with system-level read-write transactions, system-level write-only transactions with system-level write-only transactions, and system-level write-only transactions with system-level read-write transactions. In the event of conflicts between system-level read-write transactions, in the embodiments of the present disclosure, a locking mechanism can be used to control concurrency between system-level read-write transactions. Specifically, only one system-level read-write transaction is allowed to perform read or write operations on a data node at a time. Concurrency control is based on system-level timestamps. Details of how this is performed can be found in the following embodiments. In the embodiments of the present disclosure, the method for assigning system-level timestamps to system-level transactions is not limited to this method; a method similar to the epoch mechanism can also be used to assign system-level timestamps. In this embodiment, the system-level timestamp represents logical time, not physical time. Furthermore, system-level timestamps, persistent timestamps, and user-level timestamps can have their own timestamp mechanisms and be independent of each other. The starting values ​​and interval steps of the timestamps can be different, or they can be the same, without limitation. Both system-level transactions and user-level read-only transactions involve operations on nodes in the index tree. Therefore, in the disclosed embodiments, greater emphasis is placed on providing strict transactional semantics for the indexes of each node (including data nodes and index nodes) in the database index. Specifically, adding, deleting, modifying, and querying each node in the database index will not violate the snapshot isolation of various transactions. Therefore, in the disclosed embodiments, the index tree and its corresponding mapping table are considered a sub-database within the database, and the system state is defined for this sub-database. This sub-database can be considered a database for serializable snapshot isolation (SSI). All accesses to data in the database's external memory can be converted into accesses to this sub-database. The MVCC state within this sub-database is maintained independently of user-level timestamps and can be maintained uniformly using system-level timestamps, or using both system-level and persistent timestamps. In an alternative embodiment, the persistent timestamp can be implemented using a system-level timestamp assigned at the time of a persistent operation submission. That is, when a persistent operation is submitted, the persistent timestamp and the system-level timestamp use the same timestamp, unifying the timestamps and simplifying management. The following, with reference to Figure 2, illustrates the relationship between user-level timestamps, persistent timestamps, and system-level timestamps in this embodiment of the present disclosure.In Figure 2, from top to bottom, the boxes in the first row represent the system-level snapshot versions (also called system states) corresponding to system-level transactions. The numbers in the boxes represent system-level timestamps. Boxes with single solid lines represent CPK operations (i.e., persistence operations), boxes with dashed lines represent GC operations, and boxes with double solid lines represent SMO operations. The circles in the second row represent persistence operations, and the numbers in the circles represent persistence timestamps. The numbers in the third row represent user-level timestamps, and each user-level timestamp represents a user-level transaction. Specifically, in Figure 2, the user successfully writes data to the memory table at the time corresponding to user-level timestamps 0-3999 (i.e., the write operation is successfully committed); the system executes and successfully commits the persistence operation at the time corresponding to persistence timestamps 11-14. The system state after the persistence operation is visible to user-level transactions. Furthermore, the system executes system-level transactions, such as CPK operations, GC operations, and SMO operations, at system-level timestamps 101-108. Persistence timestamps 11-14 correspond to system-level timestamps 101, 103, 104, and 107. Persistence operations are completed sequentially. Therefore, since the concept of system-level timestamps is introduced in the embodiments of this disclosure, the previously mentioned persistent timestamp cpts can be represented by its corresponding system-level timestamp systs, but this is not a limitation. Replacing persistent timestamps with system-level timestamps is a preferred implementation method that simplifies timestamp management. In Figure 2, readers include system-level read operations (a system-level read operation may be a step in a system-level transaction) and user-level read-only transactions, which are read transactions initiated based on a system timestamp on the system state (i.e., system-level snapshot data). In the disclosed embodiment, a system-level timestamp is assigned to each reader based on the reader's conditions, serving as the system-level read timestamp and recorded as sysreadts. The system-level timestamp assigned as the system-level read timestamp can be a currently valid system timestamp, preferably the most recently submitted system-level timestamp at that time; however, it can also be a system-level timestamp submitted at an earlier time, and this can be flexibly set based on the application scenario and requirements.For snapshot data, if its system-level timestamp is T, only when all readers with a sys read ts less than or equal to T are completed, does this snapshot data or system state (such as pages rewritten by compaction / GC or index tree structures rewritten by SMO) expire and become garbage data, and can eventually be released. As shown in FIG2 , for a user-level read-only transaction, a user-level timestamp can be assigned as the read timestamp corresponding to the user-level read-only transaction, denoted as user read ts=2444. The current user read ts=2444 corresponds to cp ts=13. The current cp ts=13 is invisible to the user, while the currently visible cp ts<12 is visible to the user. The system-level read timestamp sys read ts=103 is corresponding to cp ts=12. Based on this, user read ts=2444 can be used to search the memory table for the data required by the user. If the required data is not found in the memory table or the data found has a user-level timestamp greater than 2444, sys read ts=103 can be used to search the system status with the system-level timestamp M103 for the required data. The process of searching in the system state includes: searching the index tree based on the key range to be searched contained in the user-level read-only transaction, determining a base node P1 that overlaps with the key range to be searched, and using the unique identifier of base node P1 to find the node update list corresponding to base node P1 in the mapping table; after obtaining this node update list, querying the user's desired data from the merged result of the node update list and base node P1 using sys read ts=103. The above analysis shows that, based on the system-level timestamp proposed in the embodiments of the present disclosure, the user-level write-only transaction can be converted into a system-level transaction, namely, a checkpoint, by using the correspondence between the user-level timestamp and the persistent timestamp, as well as the persistent timestamp and the system-level timestamp, and the relationship between the persistent operation and the user-level write-only transaction. Accordingly, the system-level timestamp corresponding to the user-level read-only transaction can be determined by using the correspondence between the user-level timestamp and the persistent timestamp, as well as the persistent timestamp and the system-level timestamp.Based on this, in the disclosed embodiments, database read and write operations ultimately rely on system-level snapshot data. Specifically, transactions involving read operations are performed on system-level snapshot data with system-level timestamps. Transactions involving write operations are also performed on system-level snapshot data with system-level timestamps. Concurrency control based on system-level timestamps allows for both read-write and write-write conflicts. A read-write conflict refers to a conflict between a user-level read-only transaction and a system-level write-only transaction; a write-write conflict refers to a conflict between a system-level write-only transaction and another, between a system-level write-only transaction and another system-level read-write transaction, and between another system-level read-write transaction and another. In the disclosed embodiments, in the event of a conflict between system-level read-write transactions, a concurrency control list can be used to ensure that, among the mapping-table-based system-level read-write transactions, at most one system-level read-write transaction (such as compaction, garbage collection, or storage management operation) is committed at any given time. Multiple system-level write-only transactions (such as checkpoints) can be committed simultaneously. This concurrency control list can be implemented as a list of busy nodes (busy node list). When a system-level read / write transaction accesses a data node, a row of flag information corresponding to the data node is added to the busy node list to indicate that other system-level read / write transactions are not allowed to access the node. When the system-level read / write transaction accessing the data node ends, the row of flag information is cleared, indicating that other system-level read / write transactions are allowed to access the data node. If read / write conflicts occur, such as conflicts between system-level write-only transactions and system-level write-only transactions, or conflicts between system-level write-only transactions and system-level read / write transactions, these conflicts can be resolved based on system timestamps, allowing these transactions to execute concurrently. In the above embodiments of the present disclosure, the various concepts and principles involved in the technical solutions of the present disclosure have been detailed. Based on this, a multi-version concurrency control method based on database indexes is proposed. As shown in Figure 3, the method includes the following steps: Step 31: Maintaining user-level timestamps for data items in the database memory, where each user-level timestamp corresponds to a snapshot version of the data item in memory. Step 32: Maintain a system-level timestamp for each data node in the database's external memory. Each system-level timestamp corresponds to a snapshot version of the data node in the external memory, and each data node corresponds to at least one data item. Step 33: Use the user-level timestamp to perform concurrent access control on transactions accessing the data items in the internal memory, and use the system-level timestamp to perform concurrent access control on transactions accessing the data nodes in the external memory.In this embodiment, external memory refers to storage space that loses data during power outages, with faster read and write speeds but higher costs. External memory refers to persistent storage media, which can be any type of storage medium that does not lose data during power outages, such as hard disks, floppy disks, optical disks, or USB flash drives. It has slower read and write speeds but is also lower costs. Data can be stored in external memory using data pages, which are the smallest storage unit supported by external memory. The size of a data page can be 16KB or 32KB, for example, but this embodiment does not limit this. Additionally, data can be stored in external memory using data files, each of which can contain multiple data pages. The database engine can maintain user-level timestamps for data items in the database residing in memory. Each user-level timestamp corresponds to a snapshot version of the data item in memory, which can record incremental data in the database. For example, when a data item is written to the database, the user-level write-only transaction generates a snapshot version. This data item represents incremental data and is recorded in the snapshot version. Accordingly, the database engine can maintain system-level timestamps for data nodes in the database located in external memory. A system-level timestamp corresponds to a snapshot version of the data node in external memory, and a data node can correspond to at least one data item. Both system-level and user-level timestamps are monotonically increasing, i.e., they gradually increase. For example, user-level timestamps can range from 0-999, or 1000-1999, and so on, all increasing gradually. System-level timestamps can range from 101-108, or 109-110, and so on, also increasing gradually. Based on this, the database engine can use user-level timestamps to control concurrent access for transactions accessing data items in memory, and use system-level timestamps to control concurrent access for transactions accessing data nodes in external memory. This approach integrates two-layer timestamps with snapshot isolation technology, leveraging the advantages of snapshot isolation technology while simplifying the implementation of concurrent access control based on the two-layer timestamps. Concurrent access control can be implemented simultaneously in both memory and system states, improving the database's concurrency performance. In some optional embodiments, when a database engine maintains system-level timestamps for data nodes in a database located in external memory, this can be achieved in the following manner: the database engine can construct a mapping table for the database's index tree. The data nodes located in external memory may include leaf nodes and index nodes in the index tree. The mapping table can be used to store the address of each data node and its corresponding snapshot version at different system-level timestamps.For example, a database index tree includes four data nodes, data nodes P1 through P4. A mapping table constructed for this index tree may store the address of data node P1 and its snapshot version at system-level timestamps 101 and 102, the address of data node P2 and its snapshot version at system-level timestamps 103 and 104, the address of data node P3 and its snapshot version at system-level timestamps 105, 106, and 107, and the address of data node P4 and its snapshot version at system-level timestamps 108 and 109. After the mapping table is constructed for the database index tree, whenever a system-level transaction accessing a data node commits, the database engine may assign a system-level timestamp to the system-level transaction and write the assigned system-level timestamp and the snapshot version generated by the system-level transaction into the mapping table. For example, when a system-level transaction accessing data node P1 commits, the database engine may assign a system-level timestamp 110 to the system-level transaction, and the snapshot version of data node P1 at system-level timestamp 110 will be written into the mapping table. Specifically, the mapping table in the aforementioned embodiment may store the addresses of each data node and their corresponding snapshot versions at different system-level timestamps using a linked list, an array, or a data row. This embodiment does not limit the implementation of the mapping table. In some optional embodiments, the mapping table may store the addresses of each data node and their corresponding snapshot versions at different system-level timestamps using the following methods: the mapping table may include multiple data rows, each of which may be used to store the address of a data node and its corresponding node update list. The node update list may be used to record the snapshot versions of the corresponding data node at different system-level timestamps. Optionally, the node update list may record each system-level timestamp and its corresponding snapshot version in a linked manner, in ascending order of system-level timestamps. Optionally, the node update list corresponding to any data node can be used to store the update node corresponding to any data node. Whenever a system-level transaction accessing any data node commits, an update node is added to record the system-level timestamp and snapshot version generated when the system-level transaction accessing the data node commits. Optionally, as shown in FIG4 , the update node may also include a persistent timestamp, which indicates the timestamp when the persistence operation successfully executes to persist the data item corresponding to the snapshot version recorded in the update node from memory to external storage. Preferably, these timestamps and snapshot version remain unchanged within an update node. Once a change occurs, a new snapshot version, persistent timestamp, and system-level timestamp appear and are stored in another update node.During operations such as merges and rewrites, the persistent timestamp changes to the timestamp of the most recent persistent operation. Correspondingly, these changed timestamps and their corresponding snapshot versions are stored in another update node. During a split operation, the persistent timestamp remains unchanged, but the system-level timestamp changes. Persistence operations are system-level transactions. Optionally, the persistent timestamp can be implemented using the system-level timestamp assigned when the persistence operation is committed. Alternatively, the database engine can set the persistent timestamp using a persistent timestamp setting rule independent of the system-level timestamp. In other words, directly using the system-level timestamp assigned when the persistence operation is committed is more convenient and concise. It should be noted that when a persistence operation is committed, the database engine can add an update node, which records the persistent timestamp, the system-level timestamp assigned when the persistence operation is committed, and the current snapshot version. As other operations that modify base nodes continue to occur, the persistent timestamp may not necessarily be the system timestamp assigned when the persistence operation is committed. The following will continue with the above examples and take FIG. 4, FIG. 5a and FIG. 5b as examples to schematically illustrate the mapping table and the node update list provided in the embodiment of the present disclosure.FIG4 takes any data row in the mapping table as an example for explanation. The data node contained in the data row is denoted as P1. Data node P1 is a leaf node or a base node. Data node P1 is persisted to the database's external memory when the persistence timestamp cp ts = 7. At this time, the system-level timestamp corresponding to data node P1 is sys ts = 0. When the persistence timestamp cp ts = 1 0, a persistence operation is performed on data node P1 and snapshot data U1 is generated. For the system-level timestamp sys ts = 101 corresponding to this persistence transaction, as shown in FIG4 , when the system-level timestamp sys ts = 101, the mapping table contains data node P1 and snapshot version U1. Snapshot version U1 forms the node update list L11 corresponding to data node P1 at this time. Then, when the persistence timestamp cp ts = 1 2, a persistence operation is performed again on data node P1 and snapshot data U3 is generated. For the system-level timestamp sys ts = 103 corresponding to this persistence transaction, As shown in Figure 4 , when the system-level timestamp systs=103, the mapping table contains data node P1, snapshot version U1, and snapshot version U3. Snapshot versions U1 and U3 form the node update list L12 corresponding to data node P1 at that time. Then, when the persistence timestamp cpts=13, a persistence operation is performed again on data node P1, generating snapshot data U4. For the system-level timestamp systs=104 corresponding to this persistence transaction, as shown in Figure 4 , when the system-level timestamp systs=104, the mapping table contains data node P1, snapshot version U1, snapshot version U3, and snapshot version U4. Snapshot versions U1, U3, and U4 form the node update list L13 corresponding to data node P1 at that time. Note that the persistence timestamp and system-level timestamp in each snapshot version have a corresponding relationship. It should be noted that in Figure 4, snapshot versions are shown from the bottom up, with arrows pointing to the previous historical version. Furthermore, Figure 4 uses persistent transactions as an example to illustrate the logical organization of the mapping table. The generation of snapshot versions in the mapping table is not limited to persistent transactions; other system-level transactions can also generate snapshot versions.In Figure 4, the node update list corresponding to a persistent transaction is submitted to a mapping table in descending order of system-level timestamps. In Figure 4, the mapping table sorts the moments corresponding to the same system-level timestamp in descending order of the persistent timestamp. Each persistent transaction commit generates a mapping table, each containing a node update list. Each entry in the node update list has its own persistent timestamp, cp ts, but the entire node update list shares a common system-level timestamp, sys tso. The persistent timestamp, cp ts, also corresponds to the user-level timestamp. Entries in the node update list can be referred to as update nodes. Specifically, the node update list includes a series of update nodes, each of which records a snapshot version, its system-level timestamp, and its persistent timestamp. Figure 4 illustrates the logical organization of the mapping table. In practical implementation, the mapping table shown in Figure 4 can be compressed and represented as a linked list. The first node in a mapping table is the mapping list head. In Figure 4, using data node P1 as the head node as an example, the mapping table records various modifications to each head node, along with the corresponding user-level timestamp or persistent timestamp, as well as the system-level timestamp. In the disclosed embodiments, a persistent timestamp represents a user-level timestamp. Furthermore, in the following embodiments and accompanying figures, the persistent timestamp is replaced with the corresponding system-level timestamp. Specifically, the persistent timestamp can be implemented as a system-level timestamp. In some optional embodiments, the node update list can be organized using various organizational methods for the continuously increasing update nodes, as described in detail below. Optionally, suffix compression can be employed in the node update list, where the subordinate relationship pointer of the next added update node points to the previously added update node. Figure 5a shows a schematic diagram of a mapping table and node update list compressed using suffix compression based on Figure 4 . Specifically, data node P1 points to its node update list. In its node update list, the update node containing the new snapshot version points to the common suffix of the update node containing the old snapshot version. The arrows in Figure 5a represent subordinate relationship pointers, namely, Next pointers. In the node update list, the system-level timestamps, systs, decrease from left to right. The last data node, P1, is a logical representation and is therefore indicated by a dashed arrow. Optionally, prefix compression can be used in the node update list, where the subordinate relationship pointer of the last added update node points to the common prefix of the next added update node.Figure 5b shows a schematic diagram of a mapping table and node update list compressed using prefix compression based on Figure 4. Specifically, data node P1 points to its node update list. In its node update list, the update node containing the old snapshot version points to the common prefix of the update node containing the new snapshot version. The arrows in Figure 5b represent subordinate relationship pointers, namely, Next pointers. In the node update list, the system-level timestamp systs increases gradually from left to right. Using this approach, the database engine can construct a mapping table for the database's index tree and set a node update list for each data node in the mapping table. This allows for relatively accurate and efficient storage of the address of each data node and the snapshot version corresponding to different system-level timestamps, thereby maintaining the system-level timestamp with high accuracy and efficiency. In some optional embodiments, step 33 in the aforementioned embodiment, i.e., using system-level timestamps to perform concurrent access control on transactions accessing data nodes in external memory, can be implemented in the following manner: When system-level concurrent transactions access the same target data node in external memory, the database engine can perform concurrent access control on the system-level concurrent transactions based on the transaction type of each transaction in the system-level concurrent transactions and the snapshot versions of the target data node corresponding to different system-level timestamps. System-level concurrent transactions can include at least one of the following: system-level write-only transactions, system-level read-write transactions, and user-level read-only transactions. System-level concurrent transactions accessing the target data node must include system-level transactions and may also include user-level transactions, specifically user-level read-only transactions. Based on this, when the database engine performs concurrent access control on the system-level concurrent transactions based on the transaction type of each transaction in the system-level concurrent transactions and the snapshot versions of the target data node corresponding to different system-level timestamps, the following two scenarios can be considered: Scenario 1: Non-read-write transactions and any other type of transactions are present in the system-level concurrent transactions. Non-read-write transactions include at least one of user-level read-only transactions and system-level write-only transactions; any other type of transaction may include at least one of user-level read-only transactions, system-level write-only transactions, and system-level read-write transactions. That is, in scenario 1, the system-level concurrent transactions in this embodiment may specifically include the following multiple concurrent scenarios: concurrent user-level read-only transactions with user-level read-only transactions; concurrent user-level read-only transactions with system-level write-only transactions; concurrent user-level read-only transactions with system-level read-write transactions; concurrent system-level write-only transactions with system-level write-only transactions; and concurrent system-level write-only transactions with system-level read-write transactions.In the aforementioned scenario 1, the database engine can perform lock-free concurrent access control for non-read-write transactions and any other type of transactions based on the snapshot versions corresponding to different system-level timestamps of the target data node. In scenario 2, there are at least two system-level read-write transactions among the system-level concurrent transactions. A system-level read-write transaction refers to a transaction that accesses a data node in external memory and involves both read and write operations. In other words, scenario 2 involves the concurrency of a read-write transaction with another read-write transaction. Concurrency between two read-write transactions is not supported in the disclosed embodiments. Therefore, in scenario 2, the database engine can perform lock-based concurrent access control for the at least two system-level read-write transactions based on the snapshot versions corresponding to different system-level timestamps of the target data node. Lock-based concurrent access control requires that only one system-level read-write transaction perform read or write operations at a time. The following details each of these two scenarios. In the above scenario 1, when the database engine performs lock-free concurrent access control on non-read-write transactions and any other type of transactions based on the snapshot versions corresponding to different system-level timestamps of the target data node, this can be specifically implemented based on the following steps R1-R2: Step R1: Concurrently execute the non-read-write transactions and any other type of transactions based on the snapshot versions corresponding to different system-level timestamps of the target data node. Step R2: Assign a system-level timestamp to the non-read-only transactions based on the commit order of the non-read-write transactions and any other type of transactions, and store the new snapshot versions generated by the non-read-only transactions and the assigned system-level timestamps in a mapping table. Non-read-only transactions may include at least one of system-level read-write transactions and system-level write-only transactions. The earlier a non-read-only transaction commits, the smaller the assigned system-level timestamp; the later a non-read-only transaction commits, the larger the assigned system-level timestamp. For example, among non-read-write transactions and any other type of transactions, there are three non-read-only transactions, namely transaction 1, transaction 2, and transaction 3. The commit order, from earliest to latest, is transaction 1 - transaction 2 - transaction 3. Based on this commit order, the database engine can assign system-level timestamps 101, 102, and 103 to transaction 1, transaction 2, and transaction 3, respectively. Through the aforementioned "concurrent execution (i.e., step R1) + sequential commit (i.e., step R2)" approach, the database engine can more accurately perform lock-free concurrent access control on non-read-write transactions and any other type of transactions based on the snapshot versions corresponding to different system-level timestamps on the target data node.In some optional embodiments, in step R1, the concurrent existence of non-read-write transactions and any other type of transactions includes: user-level read-only transactions, system-level write-only transactions, and any two or more of the system-level read-write transactions, then the non-read-write transactions and any other type of transactions are executed concurrently. This can be specifically implemented as a process of executing each of the following two or more transactions: User-level read-only transactions: For the non-read-write transactions and the user-level read-only transactions among any other type of transactions, a first read timestamp is determined, and a read operation is performed in a snapshot version whose system-level timestamp corresponding to the target data node is less than or equal to the first read timestamp, where the first read timestamp is any system-level timestamp corresponding to the target data node. Further, optionally, if an overwritten snapshot version exists in the snapshot version whose system-level timestamp corresponding to the target data node is less than or equal to the first read timestamp, the read operation is performed in a snapshot version whose system timestamp is greater than or equal to the system timestamp of the overwritten snapshot version and less than or equal to the first read timestamp. The snapshot version corresponding to the target data node with a system-level timestamp less than or equal to the first read timestamp may contain only one rewritten snapshot version, or it may contain one rewritten snapshot version plus at least one other snapshot version. In either case, as long as the rewritten snapshot version exists, the database engine can perform the read operation on the snapshot version with a system timestamp greater than or equal to the system timestamp of the rewritten snapshot version and less than or equal to the first read timestamp. Furthermore, if the snapshot version corresponding to the target data node with a system-level timestamp less than or equal to the first read timestamp does not contain the rewritten snapshot version, the read operation is performed on the target data node and its corresponding snapshot version with a system-level timestamp less than or equal to the first read timestamp. It should be noted that the full data set is required for the read operation, and methods for obtaining the full data set include the following: If the target data node, serving as the base node, has not been rewritten, the base data stored on the target data node and the incremental data in the relevant snapshot versions must be read to form the full data set; if the target node has been rewritten, this indicates that the base data has been merged into the rewritten snapshot version. Therefore, the database engine can directly start from this snapshot version. The full data can be obtained by adding incremental data to subsequent snapshot versions. Optionally, if a rewrite transaction exists in a concurrent transaction, after the rewrite to the target storage node is successfully committed, and if no other transactions need to read or write to the target data node, the database engine can perform a garbage collection (GC) operation on the target data node.System-level write-only transactions: For non-read-write transactions and any other type of system-level write-only transactions, a second read timestamp is determined. A write operation is performed on the snapshot version corresponding to the target data node whose system-level timestamp is equal to the second read timestamp to obtain a new snapshot version. The second read timestamp is any system-level timestamp corresponding to the target data node. System-level read-write transactions: For non-read-write transactions and any other type of system-level read-write transactions, a third read timestamp is determined. A read-write operation is performed on the snapshot version corresponding to the target data node whose system-level timestamp is less than or equal to the third read timestamp to obtain a new snapshot version. The third read timestamp is any system-level timestamp corresponding to the target data node. In the disclosed embodiments, user-level read-write transactions include, but are not limited to, system-level compaction transactions, system-level overwrite transactions, system-level split transactions, and system-level merge transactions. The read and write processes of different system-level read-write transactions are described in detail below. If the system-level read / write transaction is a system-level compaction transaction, performing a read / write operation on the snapshot version corresponding to the target data node whose system-level timestamp is less than or equal to the third read timestamp to obtain a new snapshot version includes: reading the snapshot version corresponding to the target data node whose system-level timestamp is less than or equal to the third read timestamp, merging the read snapshot versions into a new snapshot version, writing the new snapshot version into the mapping table, and assigning a new system-level timestamp to the new snapshot version. The Next pointer of the new snapshot version points to the merged snapshot versions, and the persistent timestamp in the new snapshot version is the latest persistent timestamp among the merged snapshot versions. The system-level timestamp of the new snapshot version is the newly assigned system-level timestamp. Furthermore, the new snapshot version is written into the mapping table. Specifically, the new snapshot version may be written into the node update list corresponding to the target data node in the mapping table. More specifically, a new update node (or entry) may be created in the node update list corresponding to the target data node, and the new snapshot version may be written into the newly created update node. In addition, when the suffix compression method is adopted, the Next pointer of the new update node is pointed to the previous update node, or when the prefix compression method is adopted, the Next pointer of the previous update node is pointed to the new update node.If the system-level read / write transaction is a system-level overwrite transaction, performing a read / write operation on the snapshot version corresponding to the target data node and having a system-level timestamp less than or equal to the third read timestamp to obtain a new snapshot version includes: reading the target data node and the snapshot version corresponding to the target data node and having a system-level timestamp less than or equal to the third read timestamp, merging the target data node and the read snapshot version into a new snapshot version, writing the new snapshot version into a mapping table, and assigning a new system-level timestamp to the new snapshot version, wherein the Next pointer of the new snapshot version points to the merged snapshot versions, the persistent timestamp in the new snapshot version is the latest persistent timestamp among the merged snapshot versions, and the system-level timestamp of the new snapshot version is the newly assigned system-level timestamp. Furthermore, the new snapshot version is written into the mapping table. Specifically, the new snapshot version may be written into the node update list corresponding to the target data node in the mapping table. More specifically, a new update node (or entry) may be created in the node update list corresponding to the target data node. The new snapshot version is written into the newly created update node. If suffix compression is used, the Next pointer of the new update node is set to point to the previous update node. Alternatively, if prefix compression is used, the Next pointer of the previous update node is set to point to the new update node. Furthermore, optionally, if the target data node is not accessed by other transactions, the target data node may be deleted. If the system-level read / write transaction is a system-level split transaction, performing a read / write operation on the snapshot version corresponding to the target data node whose system-level timestamp is less than or equal to the third read timestamp to obtain a new snapshot version includes: reading a snapshot version corresponding to the target data node whose system-level timestamp is less than or equal to the third read timestamp, splitting the read snapshot version into two or more new snapshot versions, writing the two or more new snapshot versions into a mapping table, and assigning the same new system-level timestamp and the same new persistence timestamp to the two or more new snapshot versions.Furthermore, for any new snapshot version among the two or more new snapshot versions, the new snapshot version is written into the mapping table. Specifically, the new snapshot version may be written into the node update list corresponding to the target data node in the mapping table. More specifically, a new update node (or entry) may be created in the node update list corresponding to the target data node. The new snapshot version is written into the newly created update node. When suffix compression is used, the next pointer of the new update node is set to point to the previous update node. When prefix compression is used, the next pointer of the previous update node is set to point to the new update node. Furthermore, optionally, the system-level read and write transaction may be implemented as a system-level merge transaction. The system-level merge transaction corresponds to the system-level split transaction. The execution process of the system-level merge transaction can be found in the execution process of the system-level split transaction described above and will not be further described here. It should be noted that in the above embodiments, the order of the first read timestamp, the second read timestamp, and the third read timestamp is not limited and may be determined based on the transaction. Preferably, the first read timestamp, second read timestamp, and third read timestamp described above can be the same system-level timestamp, and can be the latest system-level timestamp corresponding to the target data node. The latest system-level timestamp refers to the system-level timestamp assigned to the most recently submitted transaction. Furthermore, the database engine can determine a preset number of recently submitted transactions, and from among the system-level timestamps of these transactions, determine the system-level timestamp that is in the middle, and use it as the first read timestamp, second read timestamp, and third read timestamp. The preset number can be any natural number greater than 1. In this way, in scenario 1, the database engine can relatively accurately execute non-read-write transactions and any other type of transactions concurrently based on the snapshot versions corresponding to different system-level timestamps of the target data node. The following examples illustrate possible scenarios in which transaction order and transaction concurrency may occur in the system state. Among them, Compaction / GC, persistence transactions, Overwrite transactions, and Split transactions are involved. For ease of illustration, in the figures shown in Figures 6 to 8c, the persistence transaction is abbreviated as "Add", the system-level timestamp systs is abbreviated as "sys", and the persistence timestamp cpts is abbreviated as "cp". As shown in Figure 6, the system-level merge (Compaction / GC) transaction and the persistence transaction occur successively. Compaction / GC is a merge operation that does not require the participation of data nodes (or infrastructure nodes).As shown in Figure 6, data node P1 (data node P1 is the basic node) corresponds to snapshot versions U1, U3, and U4. Snapshot version U1 has a persistent timestamp cp ts=101 and a system-level timestamp sys ts=101. Snapshot version U3 has a persistent timestamp cp ts=103 and a system-level timestamp sys ts=103. Snapshot version U4 has a persistent timestamp cp ts=104 and a system-level timestamp sys ts=104. In this example, the persistent timestamp is implemented as the corresponding system-level timestamp. At a certain moment, a compaction transaction (compaction U5) is executed against snapshot versions U1, U3, and U4 corresponding to data node P1, resulting in snapshot version U5. This replaces snapshot versions U1, U3, and U4 with snapshot version U5. The compaction transaction is a read-write transaction. The read timestamp corresponding to the compaction transaction is Rd sys ts = 104. When the compaction transaction commits, it is assigned a system-level timestamp of sys ts = 105. Snapshot version U5 is also assigned a persistent timestamp of cp ts = 104, which is the latest persistent timestamp among the merged snapshot versions U1, U3, and U4. As shown in Figure 6, the origin pointer of version U5 points to the replaced old snapshot version {U1, U3, U4}. When the compaction transaction commits, a search is performed along the Next pointer in the node update list corresponding to data node P1. No system-level timestamp newer than its read timestamp is found, so the Next pointer of snapshot version U5 is null. After the compaction transaction is committed, a new persistent transaction occurs for data node P1. A read timestamp is assigned to the persistent transaction. For example, the read timestamp Rdsysts can be a system-level timestamp 105, 104, or other timestamp, without limitation. After the persistent transaction is committed, a new snapshot version U6 is generated. A new system-level timestamp systs=106 and a persistence timestamp cpts=106 are assigned to snapshot version U6. Because the persistence operation is a system-level transaction involving only write operations, snapshot version U6 only needs to be appended to the end of the node update list corresponding to data node P1 in the mapping table. That is, the Next pointer of snapshot version U5 points to snapshot version U6. In this example, the read timestamp corresponding to the persistent transaction does not need to be considered.Figures 7a-7c illustrate the sequential and concurrent occurrences of system-level overwrite transactions and persistent transactions. Overwrite is a merge operation that requires the participation of data nodes (or base nodes). In Figures 7a-7c, taking data node P1 (data node P1 being the base node) as an example, snapshot versions U1, U3, and U4 are associated with snapshot versions U1. Snapshot version U1 has a persistent timestamp of cp ts = 101 and a system-level timestamp of sys ts = 101. Snapshot version U3 has a persistent timestamp of cp ts = 103 and a system-level timestamp of sys ts = 103. Snapshot version U4 has a persistent timestamp of cp ts = 104 and a system-level timestamp of sys ts = 104. In this example, the persistent timestamps are implemented as corresponding system-level timestamps. Figure 7a illustrates the sequential occurrences of system-level overwrite transactions and persistent transactions. At a certain moment, an Overwrite transaction (Overwrite P3 in Figure 7a) is executed on data node P1 and its corresponding snapshot versions U1, U3, and U4, resulting in snapshot version P3. This replaces data node P1 and snapshot versions U1, U3, and U4 with snapshot version P3. The Overwrite transaction is a read-write transaction. The read timestamp corresponding to the Overwrite transaction is Rd sys ts = 104. When the Overwrite transaction commits, it is assigned a system-level timestamp of sys ts = 105, and snapshot version P3 is assigned a persistence timestamp of cp ts = 104, which is the latest persistence timestamp among the merged snapshot versions U1, U3, and U4. As shown in Figure 7a, the original (orig) pointer of snapshot version P3 points to the replaced old snapshot version {U1, U3, U4}. When the Overwrite transaction commits, a downward search along the Next pointer in the node update list corresponding to data node P1 reveals no system-level timestamp newer than its read timestamp. Therefore, the Next pointer of snapshot version P3 is empty.After the Overwrite transaction commits, a new persistent transaction occurs for data node P1. A read timestamp is assigned to the persistent transaction. For example, the read timestamp Rdsysts can be a system-level timestamp of 105, 104, or another value, without limitation. After the persistent transaction commits, a new snapshot version U6 is generated, and a new system-level timestamp systs=106 and a persistence timestamp cpts=106 are assigned to snapshot version U6. Because the persistence operation is a system-level transaction involving only writes, snapshot version U6 is simply appended to the end of the node update list corresponding to data node P1 in the mapping table. That is, the Next pointer of snapshot version P3 points to snapshot version U6, and in this example, the read timestamp corresponding to the persistent transaction is not considered. Figure 7b shows a case where a system-level Overwrite transaction and a persistent transaction occur concurrently. In this case, the system-level Overwrite transaction is committed before the persistent transaction. At a certain moment, an Overwrite transaction (Overwrite P3 in Figure 7b) is executed on data node P1 and its corresponding snapshot versions U1, U3, and U4, resulting in snapshot version P3. This replaces data node P1 and snapshot versions U1, U3, and U4 with snapshot version P3. The Overwrite transaction is a read-write transaction. The read timestamp corresponding to the Overwrite transaction is Rd sys ts = 104. When the Overwrite transaction commits, it is assigned a system-level timestamp sys ts = 105, and snapshot version P3 is assigned a persistence timestamp cp ts = 104, which is the latest persistence timestamp among the merged snapshot versions U1, U3, and U4. As shown in Figure 7b, the original (orig) pointer of snapshot version P3 points to the replaced old snapshot versions {U1, U3, U4}. When the Overwrite transaction commits, a search is performed along the Next pointer in the node update list corresponding to data node P1. No system-level timestamp newer than its read timestamp is found, so the Next pointer of snapshot version P3 is empty.Before the Overwrite transaction commits, a new persistent transaction occurs for data node P1. This persistent transaction is assigned a read timestamp of Rdsysts=104. In the example shown in Figure 7b, assuming that this persistent transaction is committed later than the Overwrite transaction, a new snapshot version U6 is generated after the persistent transaction commits. Snapshot version U6 is also assigned a new system-level timestamp of systs=106 and a new persistence timestamp of cpts=106. Because persistent operations are system-level transactions involving only writes, if the persistent transaction commits later than the Overwrite transaction, snapshot version U6 is simply appended to the end of the node update list corresponding to data node P1 in the mapping table. That is, the Next pointer of snapshot version P3 points to snapshot version U6. Figure 7c shows another scenario where a system-level Overwrite transaction and a persistent transaction occur concurrently. In this scenario, the system-level Overwrite transaction is committed later than the persistent transaction. At some point, a new persistent transaction occurs for data node P1. The persistent transaction is assigned a read timestamp of Rdsysts=104. After the persistent transaction is committed, a new snapshot version U6 is generated. Snapshot version U6 is also assigned a new system-level timestamp of systs=105 and a persistence timestamp of cpts=105. Because the persistent operation is a system-level transaction involving only writes, if the persistent transaction commits before the Overwrite transaction, snapshot version U6 is simply appended to the end of the node update list corresponding to data node P1 in the mapping table. That is, the Next pointer of snapshot version U4 points to snapshot version U6. When the persistent transaction commits, a search is performed along the Next pointers in the node update list corresponding to data node P1. No system-level timestamp newer than its read timestamp is found, so the Next pointer of snapshot version U6 is null.Before the persistence transaction commits, an overwrite transaction (Overwrite P3 in Figure 7c) is executed against data node P1 and its corresponding snapshot versions U1, U3, and U4, resulting in snapshot version P3. This replaces data node P1 and snapshot versions U1, U3, and U4 with snapshot version P3. The overwrite transaction is both a read and write transaction. The read timestamp corresponding to the overwrite transaction is Rd sys ts = 104. When the overwrite transaction commits, it is assigned a system-level timestamp of sys ts = 106. Snapshot version P3 is also assigned a persistence timestamp of cp ts = 104, the latest of the merged snapshot versions U1, U3, and U4. As shown in Figure 7c, the original pointer of snapshot version P3 points to the replaced old snapshot versions {U1, U3, U4}. When the Overwrite transaction commits, the Next pointer in the node update list corresponding to data node P1 is searched downward to see if there is a system-level timestamp newer than its read timestamp. If a snapshot version U6 with a system-level timestamp newer than its read timestamp is found, the Next pointer of snapshot version P3 is set to snapshot version U6. This ensures that subsequent transactions with read timestamps greater than the system-level timestamp 106 can see the latest snapshot version while not affecting access to transactions before the system-level timestamp 105. Figures 8a-8c illustrate the sequential and concurrent occurrences of a system-level split transaction, a system-level overwrite transaction, and a persistence transaction under SMO. In Figures 8a-8c, data node P1 (data node P1 is the base node) corresponds to snapshot versions U1, U3, and U4. Snapshot version U1 has a persistent timestamp of cp ts = 101 and a system-level timestamp of sys ts = 101. Snapshot version U3 has a persistent timestamp of cp ts = 103 and a system-level timestamp of sys ts = 103. Snapshot version U4 has a persistent timestamp of cp ts = 104 and a system-level timestamp of sys ts = 104. In this example, the persistent timestamps are implemented as corresponding system-level timestamps. Figure 8a shows the sequential occurrence of a system-level split transaction and a system-level overwrite transaction.At a certain moment, an overwrite transaction (Overwrite P3 in Figure 8a) is executed against data node P1 and its corresponding snapshot versions U1, U3, and U4, resulting in snapshot version P3. This replaces data node P1 and snapshot versions U1, U3, and U4 with snapshot version P3. The overwrite transaction is both a read and write transaction. The read timestamp corresponding to the overwrite transaction is Rd sys ts = 104. When the overwrite transaction commits, it is assigned a system-level timestamp of sys ts = 105. Snapshot version P3 is also assigned a persistent timestamp of cp ts = 104, which is the latest persistent timestamp among the merged snapshot versions U1, U3, and U4. As shown in Figure 8a, the original pointer of snapshot version P3 points to the replaced old snapshot versions {U1, U3, U4}. When the Overwrite transaction commits, a search down the Next pointer in the node update list corresponding to data node P1 reveals no system-level timestamp newer than its read timestamp. Therefore, the Next pointer for snapshot version P3 is null. After the Overwrite transaction commits, a Split transaction occurs for data node P1. This split transaction is both a read and write transaction, and is assigned a read timestamp of Rd sys ts = 105. This Split transaction splits snapshot version P3 into snapshot versions P4 and P5. When the Split transaction commits, new snapshot versions P4 and P5 are generated. These new snapshot versions are assigned a system-level timestamp of sys ts = 106 and a persistence timestamp of cp ts = 104, which represents the persistence timestamp of the split snapshot version P3.As further shown in FIG8a, after the Split transaction with the system-level timestamp systs=106 is committed, the node update list corresponding to the data node P1 (i.e., the snapshot version before snapshot versions P4 and P5) no longer needs to be accessed by read transactions with a read timestamp greater than 106, and will no longer accept new write transactions. In other words, various transactions with a read timestamp greater than the system-level timestamp 106 will be transferred to snapshot versions P4 and P5. In this way, the entire node update list can be recycled after no longer receiving transactions with a read timestamp less than or equal to the system-level timestamp 106. As shown in FIG8a, "Recycle 106" means recycling snapshot versions and data node P1 with a system-level timestamp of 106 and earlier. Furthermore, as shown in FIG8a, in the case of a persistent transaction with a read timestamp Rd systs=104 for data node P1, since the snapshot version P3 before the system-level timestamp 106 has been split into snapshot versions P4 and P5, the persistent transaction only needs to be executed on snapshot versions P4 and P5. After the persistence transaction is committed, a new snapshot version U6 is generated and assigned a new system-level timestamp, systs=107, and a persistence timestamp, cpts=107. Because persistence operations are system-level transactions involving only writes, if the persistence transaction is committed later than the split transaction, snapshot version U6 is simply appended to the end of the node update list corresponding to data node P1 in the mapping table. That is, the Next pointers of snapshot versions P4 and P5 point to snapshot version U6. Figure 8b shows a system-level overwrite transaction occurring concurrently with a persistence transaction, followed by a subsequent system-level split transaction. In this case, the system-level overwrite transaction is committed later than the persistence transaction. At some point, a new persistent transaction occurs for data node P1. The persistent transaction is assigned a read timestamp of Rdsysts=104. After the persistent transaction is committed, a new snapshot version U6 is generated. Snapshot version U6 is also assigned a new system-level timestamp of systs=105 and a persistence timestamp of cpts=105. Because persistent operations are system-level transactions involving only writes, if the persistent transaction is committed before the Overwrite transaction, snapshot version U6 is simply appended to the end of the node update list corresponding to data node P1 in the mapping table. That is, the Next pointer of snapshot version U4 points to snapshot version U6.When the persistent transaction commits, a search along the Next pointer in the node update list corresponding to data node P1 finds no system-level timestamp newer than its read timestamp, so the Next pointer for snapshot version U6 is null. Before the persistent transaction commits, an Overwrite transaction (Overwrite P3 in Figure 8b) is executed on data node P1 and its corresponding snapshot versions U1, U3, and U4, resulting in snapshot version P3. This replaces data node P1 and snapshot versions U1, U3, and U4 with snapshot version P3. The Overwrite transaction is both a read and write transaction. The read timestamp associated with the Overwrite transaction is Rd sys ts = 104. When the Overwrite transaction commits, it is assigned a system-level timestamp of sys ts = 106, and snapshot version P3 is assigned a persistent timestamp of cp ts = 104, which is the latest persistent timestamp among the merged snapshot versions U1, U3, and U4. As shown in Figure 8b, the original pointer of snapshot version P3 points to the replaced old snapshot versions {U1, U3, U4}. When the Overwrite transaction commits, the next pointer in the node update list corresponding to data node P1 is searched downward to see if there is a system-level timestamp newer than its read timestamp. If a snapshot version U6 with a system-level timestamp newer than its read timestamp is found, the next pointer of snapshot version P3 is set to snapshot version U6. This ensures that subsequent transactions with read timestamps greater than the system-level timestamp 106 can see the latest snapshot version, while not affecting access to data prior to the system-level timestamp 105. Furthermore, after the Overwrite transaction commits, a Split transaction occurs for data node P1. This Split transaction is a read-write transaction and is assigned a read timestamp of Rd sys ts = 106. The snapshot versions seen by the Split transaction include P3 and U6, which are used to split snapshot versions P3 and U6 into new snapshot versions P4 and P5. When the Split transaction commits, new snapshot versions P4 and P5 are generated and assigned a system-level timestamp of sys ts = 107 and a persistence timestamp of cp ts = 105, which is the latest persistence timestamp of the split snapshot versions P3 and U6.Furthermore, after the Split transaction with system-level timestamp systs=106 is committed, the node update list corresponding to data node P1 (i.e., snapshot versions prior to snapshot versions P4 and P5) no longer needs to be accessed by read transactions with read timestamps greater than 106, nor will it accept new write transactions. In other words, transactions with read timestamps greater than the system-level timestamp 106 will be transferred to snapshot versions P4 and P5. Thus, after the entire node update list no longer receives transactions with read timestamps less than or equal to the system-level timestamp 106, it can be recycled. As shown in Figure 8b, "Recycle 106" indicates the recycling of snapshot versions with system-level timestamps 107 and earlier, as well as data node P1. Figure 8c illustrates the situation where a system-level overwrite transaction occurs concurrently with a persistent transaction, followed by a subsequent system-level split transaction. In this scenario, the system-level overwrite transaction commits before the persistent transaction. At a certain moment, an Overwrite transaction (Overwrite P3 in Figure 8c) is executed on data node P1 and its corresponding snapshot versions U1, U3, and U4, resulting in snapshot version P3. This replaces data node P1 and snapshot versions U1, U3, and U4 with snapshot version P3. The Overwrite transaction is a read-write transaction. The read timestamp corresponding to the Overwrite transaction is Rd sys ts = 104. When the Overwrite transaction commits, it is assigned a system-level timestamp of sys ts = 105, and snapshot version P3 is assigned a persistent timestamp of cp ts = 104, which is the latest persistent timestamp among the merged snapshot versions U1, U3, and U4. As shown in Figure 8c, the original (orig) pointer of snapshot version P3 points to the replaced old snapshot version {U1, U3, U4}. When the Overwrite transaction commits, a downward search along the Next pointer in the node update list corresponding to data node P1 reveals no system-level timestamp newer than its read timestamp. Therefore, the Next pointer of snapshot version P3 is empty.Before the Overwrite transaction is committed, a new persistent transaction occurs for data node P1. The persistent transaction is assigned a read timestamp Rdsysts=104. In the example shown in FIG8c , the persistent transaction is committed later than the Overwrite transaction. After the persistent transaction is committed, a new snapshot version U6 is generated and a new system-level timestamp systs=106 and persistence timestamp cpts=106 are assigned to snapshot version U6. Because the persistence operation is a system-level transaction involving only write operations, if the persistent transaction is committed later than the Overwrite transaction, snapshot version U6 is simply appended to the end of the node update list corresponding to data node P1 in the mapping table. That is, the Next pointer of snapshot version P3 points to snapshot version U6. After the persistence transaction commits, a Split transaction occurs for data node P1. This Split transaction is a read-write transaction and is assigned a read timestamp of Rd sys ts = 105. This Split transaction is used to split snapshot version P3 into snapshot versions P4 and P5. When the Split transaction commits, new snapshot versions P4 and P5 are generated. These new snapshot versions P4 and P5 are assigned a system-level timestamp of sys ts = 107 and a persistence timestamp of cp ts = 104, which is the persistence timestamp of the split snapshot version P3. Snapshot version U6 is committed later than snapshot version P3. Therefore, the system-level timestamp systs of snapshot version U6 is greater than the read timestamp 105 of the Split transaction. Therefore, after snapshot version P3 is split into snapshot versions P4 and P5, snapshot version U6 needs to be added to snapshot versions P4 and P5. Persistence transactions targeting snapshot version U6 can be executed for snapshot versions P4 and P5, respectively, to obtain a new snapshot version U6 pointed to by snapshot versions P4 and P5, respectively. A new system-level timestamp 107 is assigned to the new snapshot version U6, while the persistence timestamp remains at 106. Optionally, in actual implementation, this scenario can be simplified by merging the Overwrite transaction and the Split transaction. This ensures that snapshot version U6 sees the snapshot versions P4 and P5 generated by the Split transaction when it is committed, allowing it to be directly committed to snapshot versions P4 and P5, thereby degenerating into the scenario shown in Figure 8a.In some optional embodiments, if the system-level read / write transaction is a system-level rewrite transaction, and if the system-level rewrite transaction commits later than the system-level write-only transaction, the subordinate relationship pointer of the second snapshot version generated by the later-committed system-level rewrite transaction is set to point to the first snapshot version generated by the earlier-committed system-level write-only transaction. If the system-level read / write transaction is a system-level split transaction, and if the system-level split transaction commits later than the system-level write-only transaction, the subordinate relationship pointer of the fourth snapshot version generated by the later-committed system-level split transaction is set to point to the third snapshot version generated by the earlier-committed system-level write-only transaction. Optionally, when a system-level split transaction is executed for the second snapshot version, the first snapshot version and the second snapshot version are merged to split the snapshot version into at least two new snapshot versions. When the system-level split transaction commits, a system-level timestamp is assigned to each snapshot version. The at least two new snapshot versions and the assigned system-level timestamps are stored in a mapping table in a corresponding manner. The following further describes Case 2 above. In Case 2 above, when the database engine performs locked concurrent access control on at least two system-level read / write transactions based on the snapshot versions corresponding to the target data node at different system-level timestamps, this can be specifically implemented in the following manner: For the first system-level read / write transaction, the database engine may add concurrency marking information corresponding to the target data node to the concurrency control list. The concurrency marking information may be used to prohibit other system-level read / write transactions from concurrently accessing the target data node. Optionally, the concurrency marking information may include identification information of read / write transactions with access rights to the target data node. After the first system-level read / write transaction commits, the concurrency marking information is cleared to allow other system-level read / write transactions to access the target data node. The first system-level read / write transaction is one of the at least two system-level read / write transactions. The first system-level read / write transaction may be any one of the at least two system-level read / write transactions, the earliest transaction of the at least two system-level read / write transactions, or the latest transaction of the at least two system-level read / write transactions, without limitation in this embodiment. For example, when a system-level read / write transaction accesses a data node, the database engine can add the data node's concurrency marker information to the concurrency control list for the system-level read / write transaction. This concurrency marker information prohibits other system-level read / write transactions from accessing the data node simultaneously with the system-level read / write transaction. After the first system-level read / write transaction commits, the database engine can clear the concurrency marker information, allowing other system-level read / write transactions to access the data node.In some optional embodiments, the database engine may determine a fourth read timestamp for the first system-level read-write transaction. Preferably, the fourth read timestamp may be the latest system-level timestamp corresponding to the target data node. The latest system-level timestamp refers to the system-level timestamp assigned to the most recently committed transaction. Subsequently, the database engine may read the pending data from the snapshot version corresponding to the target data node whose system-level timestamp is less than or equal to the fourth read timestamp, and perform a write operation on the pending data to generate a new snapshot version. When the first read-write type system transaction commits, the database engine may assign a system-level timestamp to it and store the generated new snapshot version and the assigned system-level timestamp in a mapping table. Specifically, the database engine may assign a system-level timestamp based on the type of the first read-write type system transaction: If the system transaction is a merge, the database engine may merge multiple snapshot versions into a new snapshot version and assign a new system-level timestamp to the new snapshot version. If the system transaction is an overwrite, the database engine may overwrite multiple snapshot versions and the base node into a new snapshot version and assign a new system-level timestamp. In some optional embodiments, step 31 in the aforementioned embodiment, i.e., maintaining user-level timestamps for in-memory data items in the database, can be implemented based on the following steps 311-312: Step 311: Whenever a user-level write-only transaction accessing an in-memory data item commits, assign a user-level timestamp to the user-level write-only transaction. Step 312: Write the assigned user-level timestamp and the snapshot version generated by the user-level write-only transaction to the memory and transaction log, respectively. Based on the above, step 33 in the aforementioned embodiment, "Using user-level timestamps to perform concurrent access control on transactions accessing in-memory data items," can be implemented based on the following: When concurrent in-memory transactions access the same target data item in memory, the database engine can perform concurrent access control on the in-memory concurrent transactions based on the transaction type of each transaction and the snapshot versions of the target data item corresponding to different user-level timestamps. Specifically, this includes the following scenarios: Scenario 3: If at least two user-level write-only transactions exist within concurrent memory-state transactions, lock-based concurrent access control is performed on the at least two user-level write-only transactions based on the snapshot versions of the target data items corresponding to different user-level timestamps. Lock-based concurrent access control requires that only one user-level write-only transaction perform a write operation at a time. Scenario 4: If at least two user-level read-only transactions exist within concurrent memory-state transactions, lock-free concurrent access control is performed on the at least two user-level read-only transactions based on the snapshot versions of the target data items corresponding to different user-level timestamps.Case 5: If user-level read-only transactions and user-level write-only transactions exist among the concurrent in-memory transactions, lock-free concurrent access control is performed on the user-level read-only and write-only transactions based on the snapshot versions of the target data items corresponding to different user-level timestamps. In this way, the database engine can use user-level timestamps to more accurately control concurrent access for transactions accessing in-memory data items. It should be noted that embodiments of the present disclosure may also provide a runtime checking mechanism for checking the concurrent access control logic during its execution to determine whether it is correct or has errors. In actual implementation, the mapping table may be a directed acyclic graph (DAG). The persistent timestamps in the mapping table and the system-level timestamps have the following relationship, including but not limited to the following. This relationship enables runtime checking of the concurrent access control logic:

[0002] (1) For any update node, its persistence timestamp W is its system-level timestamp; (2) For a persistence operation, its persistence timestamp = its system-level timestamp; (3) For a read-write transaction, its persistence timestamp < its system-level timestamp; (4) In the case of the related transaction relationship in Figures 8a-8c, the relationship between the persistence timestamp and the system-level timestamp shown in Figures 8a-8c. In the embodiment of the present disclosure, by simultaneously tracking and saving the persistence timestamp and the system-level timestamp in each update node in the mapping table corresponding to the index tree, multi-version concurrent access control, garbage collection, and continuous error checking at runtime based on the index tree can be performed to ensure correctness. Compared with traditional solutions, the MVCC mechanism is directly provided in the data structure, which simplifies the implementation of upper-layer applications and saves the space overhead of maintaining too many user versions. The implementation complexity is low, and runtime correctness checking is easy to implement. FIG9 is a flow diagram of a data processing method provided by another exemplary embodiment of the present disclosure. The method may include the steps shown in FIG9 : Step 91: In response to a data read request, generate a user-level read-only transaction, the user-level read-only transaction including a query condition. Step 92: Determine a first read timestamp corresponding to the user-level read-only transaction from the currently maintained user-level timestamps for data items in the database located in memory. Step 93: Search for target data that meets the query condition from snapshot versions in memory whose user-level timestamps are less than or equal to the first read timestamp. Step 94: If the target data is not found in memory, determine a second read timestamp corresponding to the user-level read-only transaction from the currently maintained system-level timestamps for data nodes in the database located in external memory. Step 95: Search for target data that meets the query condition from snapshot versions in external memory whose system-level timestamps are less than or equal to the second read timestamp. Optionally, determining a first read timestamp corresponding to a user-level read-only transaction from user-level timestamps currently maintained for data items in the database located in memory includes: using the most recently submitted user-level timestamp before the user-level read-only transaction among the user-level timestamps currently maintained for the data items in the database located in memory as the first read timestamp; determining a second read timestamp corresponding to the user-level read-only transaction from system-level timestamps currently maintained for data nodes in the database located in external memory includes: using the most recently submitted system-level timestamp before the user-level read-only transaction among the system-level timestamps currently maintained for data nodes in the database located in external memory as the second read timestamp.Optionally, searching for target data that meets the query criteria in snapshot versions in external memory with system-level timestamps less than or equal to the second read timestamp includes: querying the database index tree according to the query criteria to determine target data nodes that overlap with the key range in the query criteria, where data nodes in external memory include leaf nodes and index nodes in the index tree; querying a mapping table corresponding to the index tree to obtain the address of the target data node and its corresponding snapshot versions at different system-level timestamps; the mapping table stores the address of each data node and its corresponding snapshot versions at different system-level timestamps; and querying for the target data in snapshot versions corresponding to the target data node with a system-level timestamp less than or equal to the second read timestamp. It should be noted that the target data nodes that overlap with the key range in the query criteria in this embodiment are leaf nodes. The specific implementation of the above embodiment has been described in the related embodiments of the "Multi-version Concurrent Access Control Method for a Database" previously described and will not be repeated here. FIG10 is a flow diagram of a data processing method provided by another exemplary embodiment of the present disclosure. The method may include the steps shown in FIG10 : Step 101: In response to a data write request, generate a user-level write-only transaction. The user-level write-only transaction indicates writing the data to be written to the database, where the data to be written corresponds to a target data item. Step 102: Execute the user-level write-only transaction to write the data to be written to the database memory to generate a new snapshot version corresponding to the target data item. Step 103: If the user-level read-only transaction commits, assign a user-level timestamp to the user-level write-only transaction and record the new snapshot version corresponding to the user-level timestamp and the target data item. Step 104: If the corresponding persistence conditions for the memory are met, execute the persistence transaction to persistently store each data item in the memory to at least one target data node in the database's external memory to generate a new snapshot version corresponding to the at least one target data node. Step 105: If the persistence transaction commits, assign a system-level timestamp to the persistence transaction and record the new snapshot version corresponding to the system-level timestamp and the at least one target data node.Optionally, executing a user-level write-only transaction to write to-be-written data into the database's memory to generate a new snapshot version corresponding to a target data item includes: determining a first read timestamp corresponding to the user-level write-only transaction from user-level timestamps currently maintained for the data item in the database's memory; writing the to-be-written data item into a snapshot version whose user-level timestamp corresponding to the target data item is equal to the first read timestamp, to generate a new snapshot version corresponding to the target data item; correspondingly, executing a persistence transaction to persistently store each data item in the memory in at least one target data node in the database's external memory to generate a new snapshot version corresponding to the at least one target data node, including: determining a second read timestamp corresponding to the persistence transaction from system-level timestamps currently maintained for the data node in the database's external memory; and persistently storing each data item in the memory in at least one target data node in the external memory whose system-level timestamp is less than or equal to the second read timestamp, to generate a new snapshot version corresponding to the at least one target data node. The specific implementations of the above embodiments have been described in the related embodiments of the "Multi-version Concurrent Access Control Method for a Database" previously described and will not be repeated here. It should be noted that the execution entity of each step of the method provided in the above embodiments can be the same device, or the method can be executed by different devices. For example, the execution entity of steps 31 to 33 can be device A; for another example, the execution entity of steps 31 to 32 can be device A, and the execution entity of step 33 can be device B, and so on. Furthermore, some of the processes described in the above embodiments and the accompanying drawings include multiple operations that appear in a specific order. However, it should be understood that these operations may be executed in a different order than the order in which they appear herein or in parallel. Operation sequence numbers, such as 31 and 32, are merely used to distinguish between different operations and do not represent any specific execution order. Furthermore, these processes may include more or fewer operations, and these operations may be executed sequentially or in parallel. It should be noted that the terms "first" and "second" herein are used to distinguish different messages, devices, modules, and the like, and do not represent a sequential order, nor do they limit "first" and "second" to different types. FIG11 is a schematic diagram of the structure of a multi-version concurrent access control device for a database, provided in another exemplary embodiment of the present disclosure.As shown in FIG11 , the apparatus includes: a first maintenance module 1101, configured to maintain user-level timestamps for data items in a database located in memory, where one user-level timestamp corresponds to a snapshot version of the data item in memory; a second maintenance module 1102, configured to maintain system-level timestamps for data nodes in a database located in external memory, where one system-level timestamp corresponds to a snapshot version of the data node in external memory, where the data node corresponds to at least one data item; and a concurrent access control module 1103, configured to perform concurrent access control on transactions accessing data items in memory using user-level timestamps, and to perform concurrent access control on transactions accessing data nodes in external memory using system-level timestamps. Further optionally, when maintaining system-level timestamps for data nodes in the database located in external memory, maintenance module 1102 is specifically configured to: construct a mapping table for the database's index tree, where the data nodes in the external memory include leaf nodes and index nodes in the index tree; the mapping table is configured to store the address of each data node and its corresponding snapshot version at different system-level timestamps; and whenever a system-level transaction accessing a data node commits, assign a system-level timestamp to the system-level transaction and write the assigned system-level timestamp and the snapshot version generated by the system-level transaction into the mapping table. Further optionally, the mapping table includes multiple data rows, where each data row is configured to store the address of a data node and its corresponding node update list; the node update list is configured to record the snapshot versions corresponding to the corresponding data node at different system-level timestamps. Further optionally, the node update list corresponding to any data node is used to store the update node corresponding to the data node. Each time a system-level transaction accessing the data node commits, an update node is added to record the system-level timestamp and snapshot version generated when the system-level transaction accessing the data node commits. The update node also includes a persistence timestamp, which indicates the timestamp when a persistence operation is successfully performed to persist the data item corresponding to the snapshot version recorded in the update node from memory to external memory. Further optionally, the persistence operation is a system-level transaction, and the persistence timestamp is implemented using the system-level timestamp assigned when the persistence operation commits. Further optionally, in the node update list, a suffix compression method is used to set the subordinate relationship pointer of the next added update node to point to the previously added update node; or, in the node update list, a prefix compression method is used to set the subordinate relationship pointer of the previously added update node to point to the common prefix of the next added update node.Further optionally, when concurrent access control module 1103 uses system-level timestamps to perform concurrent access control on transactions accessing data nodes in external memory, it is specifically configured to: In the event of concurrent system-level transactions accessing the same target data node in external memory, perform concurrent access control on the concurrent system-level transactions based on the transaction type of each transaction in the concurrent system-level transactions and the snapshot versions of the target data node corresponding to different system-level timestamps. Further optionally, the concurrent system-level transactions include system-level write-only transactions, system-level read-write transactions, and / or user-level read-only transactions. The concurrent access control module 1103 performs concurrent access control on the system-state concurrent transactions based on the transaction type of each transaction in the system-state concurrent transactions and the snapshot versions of the target data node corresponding to different system-level timestamps. Specifically, the concurrent access control module 1103 is used to: if there are at least two system-level read-write transactions in the system-state concurrent transactions, perform locked concurrent access control on the at least two system-level read-write transactions based on the snapshot versions of the target data node corresponding to different system-level timestamps, where the locked concurrent access control requires that only one system-level read-write transaction performs read and write operations at the same time; if there are non-read-write transactions and any other type of transactions in the system-state concurrent transactions, perform lock-free concurrent access control on the non-read-write transactions and any other type of transactions based on the snapshot versions of the target data node corresponding to different system-level timestamps; wherein the non-read-write transactions include user-level read-only transactions and / or system-level write-only transactions. Further optionally, when the concurrent access control module 1103 performs lock-free concurrent access control on the non-read-write transaction and any type of other transaction according to the snapshot versions of the target data node corresponding to different system-level timestamps, the concurrent access control module 1103 is specifically used to: concurrently execute the non-read-write transaction and any type of other transaction according to the snapshot versions of the target data node corresponding to different system-level timestamps; assign a system-level timestamp to the non-read-only transaction according to the commit order of non-read-only transactions among the non-read-write transaction and any type of other transaction, and store the new snapshot version generated by the non-read-only transaction and the assigned system-level timestamp in the mapping table in correspondence; wherein the non-read-only transaction includes system-level read-write transaction and / or system-level write-only transaction.Further optionally, when concurrently executing the non-read-write transaction and any other type of transaction based on snapshot versions corresponding to different system-level timestamps of the target data node, the concurrent access control module 1103 is specifically configured to: determine a first read timestamp for user-level read-only transactions among the non-read-write transaction and any other type of transaction, and perform a read operation in a snapshot version whose system-level timestamp corresponding to the target data node is less than or equal to the first read timestamp, where the first read timestamp is any system-level timestamp corresponding to the target data node; determine a second read timestamp for system-level write-only transactions among the non-read-write transaction and any other type of transaction, and perform a write operation on a snapshot version whose system-level timestamp corresponding to the target data node is equal to the second read timestamp to obtain a new snapshot version, where the second read timestamp is any system-level timestamp corresponding to the target data node; and determine a third read timestamp for system-level read-write transactions among the non-read-write transaction and any other type of transaction. Performing read and write operations on a snapshot version corresponding to the target data node whose system-level timestamp is less than or equal to the third read timestamp to obtain a new snapshot version, where the third read timestamp is any system-level timestamp corresponding to the target data node. Further optionally, the first read timestamp, the second read timestamp, and the third read timestamp are the same system-level timestamp and are the latest system-level timestamp corresponding to the target data node. Further optionally, when performing a read operation on a snapshot version corresponding to the target data node whose system-level timestamp is less than or equal to the first read timestamp, the concurrent access control module 1103 is specifically configured to: If an overwrite occurs in the snapshot version corresponding to the target data node whose system-level timestamp is less than or equal to the first read timestamp.

[0003] If there is no overwritten snapshot version among the snapshot versions corresponding to the target data node and whose system-level timestamp is less than or equal to the first read timestamp, then the read operation is performed on the target data node and its corresponding snapshot version with a system-level timestamp less than or equal to the first read timestamp. Further optionally, when the concurrency between the non-read-write transaction and any other type of transaction is implemented as concurrency between a system-level write-only transaction and a system-level read-write transaction, the concurrent access control module 1103 is further configured to: if the system-level read-write transaction is a system-level rewrite transaction, and if the system-level rewrite transaction is committed later than the system-level write-only transaction, set the subordinate relationship pointer of the second snapshot version generated by the later-committed system-level rewrite transaction to point to the first snapshot version generated by the earlier-committed system-level write-only transaction; and if the system-level read-write transaction is a system-level split transaction, and if the system-level split transaction is committed later than the system-level write-only transaction, set the subordinate relationship pointer of the fourth snapshot version generated by the later-committed system-level split transaction to point to the third snapshot version generated by the earlier-committed system-level write-only transaction. Further optionally, the concurrent access control module 1103 is further configured to: when executing a system-level split transaction for the second snapshot version, merge the first snapshot version and the second snapshot version to split them into at least two new snapshot versions; assign system-level timestamps to the new snapshot versions when the system-level split transaction commits; and store the at least two new snapshot versions and the assigned system-level timestamps in the mapping table. Further optionally, when performing locked concurrent access control on the at least two system-level read / write transactions based on the snapshot versions corresponding to different system-level timestamps of the target data node, the concurrent access control module 1103 is specifically configured to: for the first system-level read / write transaction, add concurrency flag information corresponding to the target data node to a concurrency control list, the concurrency flag information being used to prohibit other system-level read / write transactions from accessing the target data node simultaneously; and after the first system-level read / write transaction commits, clear the concurrency flag information to allow other system-level read / write transactions to access the target data node. The first system-level read / write transaction is one of the at least two system-level read / write transactions.Further optionally, the concurrent access control module 1103 is further configured to: determine a fourth read timestamp for the first system-level read / write transaction, read the to-be-processed data from the snapshot version corresponding to the target data node whose system-level timestamp is less than or equal to the fourth read timestamp, and perform a write operation on the to-be-processed data to generate a new snapshot version; when the system transaction of the first read / write type commits, assign a system-level timestamp to it, and store the generated new snapshot version and the assigned system-level timestamp in the mapping table in a corresponding manner. Further optionally, when the first maintenance module 1101 maintains user-level timestamps for data items in memory in the database, it is specifically configured to: assign a user-level timestamp to the user-level write-only transaction whenever a user-level write-only transaction accessing the data items in memory commits; and write the assigned user-level timestamp and the snapshot version generated by the user-level write-only transaction in the memory and the transaction log in a corresponding manner. Further optionally, when the concurrent access control module 1103 uses user-level timestamps to perform concurrent access control on transactions that access data items in memory, it is specifically used to: in the event of memory-state concurrent transactions that access the same target data item in memory, concurrent access control is performed on the memory-state concurrent transactions based on the transaction type of each transaction in the memory-state concurrent transactions and the snapshot versions of the target data items corresponding to different user-level timestamps. Further optionally, when performing concurrent access control on the memory-state concurrent transactions based on the transaction type of each transaction in the memory-state concurrent transactions and the snapshot versions of the target data items corresponding to different user-level timestamps, the concurrent access control module 1103 is specifically configured to: if there are at least two user-level write-only transactions in the memory-state concurrent transactions, perform locked concurrent access control on the at least two user-level write-only transactions based on the snapshot versions of the target data items corresponding to different user-level timestamps, wherein the locked concurrent access control requires that only one user-level write-only transaction performs a write operation at the same time; if there are at least two user-level read-only transactions in the memory-state concurrent transactions, perform lock-free concurrent access control on the at least two user-level read-only transactions based on the snapshot versions of the target data items corresponding to different user-level timestamps; and if there are both user-level read-only transactions and user-level write-only transactions in the memory-state concurrent transactions, perform lock-free concurrent access control on the user-level read-only transactions and the user-level write-only transactions based on the snapshot versions of the target data items corresponding to different user-level timestamps.This embodiment provides a concurrent access control scheme for databases based on snapshot isolation technology. This concurrent access control scheme proposes two-level timestamp concepts: system-level timestamps and user-level timestamps. User-level timestamps are used to control concurrent access in the memory state for data items in the database memory, based on user-level timestamps. System-level timestamps are used to control concurrent access in the system state for data nodes in the database's external memory, based on system-level timestamps. This embodiment integrates these two levels of timestamps with snapshot isolation technology. While leveraging the advantages of snapshot isolation technology, the two-level timestamps simplify the implementation of concurrent access control and enable concurrent access control in both the memory state and the system state, facilitating improved database concurrency performance. Figure 12 is a schematic structural diagram of a data processing device provided by yet another exemplary embodiment of the present disclosure. As shown in FIG12 , the apparatus includes: a generation module 1201, configured to generate a user-level read-only transaction in response to a data read request, wherein the user-level read-only transaction includes a query condition; a first determination module 1202, configured to determine a first read timestamp corresponding to the user-level read-only transaction from user-level timestamps currently maintained for data items in a database located in memory; a first query module 1203, configured to query for target data that meets the query condition from snapshot versions in the memory having a user-level timestamp less than or equal to the first read timestamp; a second determination module 1204, configured to determine, if the target data is not found in the memory, a second read timestamp corresponding to the user-level read-only transaction from system-level timestamps currently maintained for data nodes in the database located in external memory; and a second query module 1205, configured to query for target data that meets the query condition from snapshot versions in the external memory having a system-level timestamp less than or equal to the second read timestamp. Optionally, when the first determination module 1202 determines the first read timestamp corresponding to the user-level read-only transaction from the user-level timestamp currently maintained for the data item in the database located in the memory, it is specifically used to: use the user-level timestamp currently maintained for the data item in the database located in the memory that is the most recently submitted user-level timestamp before the user-level read-only transaction as the first read timestamp; when the second determination module 1204 determines the second read timestamp corresponding to the user-level read-only transaction from the system-level timestamp currently maintained for the data node in the database located in the external memory, it is specifically used to: use the system-level timestamp currently maintained for the data node in the database located in the external memory that is the most recently submitted system-level timestamp before the user-level read-only transaction as the second read timestamp.Optionally, when searching for target data that meets the query criteria in snapshot versions in the external memory whose system-level timestamps are less than or equal to the second read timestamp, the second query module 1205 is specifically configured to: query the index tree of the database according to the query criteria to determine target data nodes that overlap with the key range in the query criteria, where the data nodes in the external memory include leaf nodes and index nodes in the index tree; query a mapping table corresponding to the index tree to obtain the address of the target data node and its corresponding snapshot versions at different system-level timestamps; the mapping table stores the address of each data node and its corresponding snapshot versions at different system-level timestamps; and query the target data in snapshot versions corresponding to the target data node whose system-level timestamps are less than or equal to the second read timestamp. Figure 13 is a schematic structural diagram of another data processing device provided by yet another exemplary embodiment of the present disclosure. As shown in FIG13 , the apparatus includes: a generation module 1301, configured to generate, in response to a data write request, a user-level write-only transaction, wherein the user-level write-only transaction indicates writing data to be written into a database, the data to be written corresponding to a target data item; a first execution module 1302, configured to execute the user-level write-only transaction to write the data to be written into the memory of the database to generate a new snapshot version corresponding to the target data item; a first allocation module 1303, configured to, when the user-level read-only transaction is committed, assign a user-level timestamp to the user-level write-only transaction and record the user-level timestamp and the new snapshot version corresponding to the target data item; a second execution module 1304, configured to, when a persistence condition corresponding to the memory is met, execute a persistence transaction to persistently store each data item in the memory in at least one target data node in the external memory of the database to generate a new snapshot version corresponding to the at least one target data node; and a second allocation module 1305, configured to, when the persistence transaction is committed, A system-level timestamp is assigned to the persistent transaction, and a new snapshot version corresponding to the system-level timestamp and the at least one target data node is recorded accordingly.Optionally, when the first execution module 1302 executes the user-level write-only transaction to write the to-be-written data into the memory of the database to generate a new snapshot version corresponding to the target data item, the first execution module 1302 is specifically configured to: determine a first read timestamp corresponding to the user-level write-only transaction from the user-level timestamp currently maintained for the data item in the memory of the database; and write the to-be-written data item into the snapshot version whose user-level timestamp corresponding to the target data item is equal to the first read timestamp to generate a new snapshot version corresponding to the target data item. Correspondingly, when the second execution module 1304 executes the persistence transaction to persistently store each data item in the memory in at least one target data node in the external memory of the database to generate a new snapshot version corresponding to the at least one target data node, the second execution module 1304 is specifically configured to: determine a second read timestamp corresponding to the persistence transaction from the system-level timestamp currently maintained for the data node in the external memory of the database; and persistently store each data item in the memory in at least one target data node in the external memory whose system-level timestamp is less than or equal to the second read timestamp. To generate a new snapshot version corresponding to the at least one target data node. The above describes the internal functions and structure of the multi-version concurrent access control device for a database. As shown in FIG14 , in practice, the multi-version concurrent access control device for a database can be implemented as an electronic device including a memory 1401, a processor 1402, and a communication component 1403. oMemory 1401 is used to store computer programs and can be configured to store various other data to support operations on the computing platform. Examples of such data include instructions for any application or method operating on the computing platform, contact data, phone book data, messages, images, videos, etc. Memory 1401 can be implemented using any type of volatile or non-volatile storage device, or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic disk, or optical disk. A processor 1402 is coupled to the memory 1401 and is configured to execute a computer program in the memory 1401 to: maintain a user-level timestamp for a data item in a database located in the memory, where one user-level timestamp corresponds to a snapshot version of the data item in the memory; maintain a system-level timestamp for a data node in the database located in the external memory, where one system-level timestamp corresponds to a snapshot version of the data node in the external memory, where the data node corresponds to at least one data item; and perform concurrent access control on transactions accessing the data item in the memory using the user-level timestamp and perform concurrent access control on transactions accessing the data node in the external memory using the system-level timestamp. Further optionally, when maintaining system-level timestamps for data nodes in the database located in external memory, processor 1402 is specifically configured to: construct a mapping table for the database's index tree, where the data nodes in the external memory include leaf nodes and index nodes in the index tree, the mapping table being configured to store the address of each data node and its corresponding snapshot version at different system-level timestamps; and, whenever a system-level transaction accessing a data node commits, assign a system-level timestamp to the system-level transaction, and write the assigned system-level timestamp and the snapshot version generated by the system-level transaction into the mapping table. Further optionally, the mapping table includes multiple data rows, each data row being configured to store the address of a data node and its corresponding node update list, the node update list being configured to record the snapshot versions of the corresponding data node at different system-level timestamps.Further optionally, the node update list corresponding to any data node is used to store the update node corresponding to the data node. Each time a system-level transaction accessing the data node commits, an update node is added to record the system-level timestamp and snapshot version generated when the system-level transaction accessing the data node commits. The update node also includes a persistence timestamp, which indicates the timestamp when a persistence operation is successfully performed to persist the data item corresponding to the snapshot version recorded in the update node from memory to external memory. Further optionally, the persistence operation is a system-level transaction, and the persistence timestamp is implemented using the system-level timestamp assigned when the persistence operation commits. Further optionally, in the node update list, a suffix compression method is used to set the subordinate relationship pointer of the next added update node to point to the previously added update node; or, in the node update list, a prefix compression method is used to set the subordinate relationship pointer of the previously added update node to point to the common prefix of the next added update node. Further optionally, when processor 1402 uses system-level timestamps to perform concurrent access control on transactions accessing data nodes in external memory, the processor 1402 is specifically configured to: when system-level concurrent transactions accessing the same target data node in external memory occur, perform concurrent access control on the system-level concurrent transactions based on the transaction type of each transaction in the system-level concurrent transactions and the snapshot versions of the target data node corresponding to different system-level timestamps. Further optionally, the system-level concurrent transactions include system-level write-only transactions, system-level read-write transactions, and / or user-level read-only transactions. When performing concurrent access control on the system-state concurrent transactions based on the transaction type of each transaction in the system-state concurrent transactions and the snapshot versions of the target data nodes corresponding to different system-level timestamps, the processor 1402 is specifically configured to: if there are at least two system-level read-write transactions in the system-state concurrent transactions, perform locked concurrent access control on the at least two system-level read-write transactions based on the snapshot versions of the target data nodes corresponding to different system-level timestamps, where the locked concurrent access control requires that only one system-level read-write transaction performs a read or write operation at the same time; if there are non-read-write transactions and any other type of transactions in the system-state concurrent transactions, perform lock-free concurrent access control on the non-read-write transactions and any other type of transactions based on the snapshot versions of the target data nodes corresponding to different system-level timestamps; wherein the non-read-write transactions include user-level read-only transactions and / or system-level write-only transactions.Further optionally, when the processor 1402 performs lock-free concurrent access control on the non-read-write transaction and any type of other transaction according to the snapshot versions of the target data node corresponding to different system-level timestamps, the processor 1402 is specifically configured to: concurrently execute the non-read-write transaction and any type of other transaction according to the snapshot versions of the target data node corresponding to different system-level timestamps; assign a system-level timestamp to the non-read-only transaction according to a commit order of non-read-only transactions among the non-read-write transaction and any type of other transaction, and store a new snapshot version generated by the non-read-only transaction and the assigned system-level timestamp in the mapping table in correspondence; wherein the non-read-only transaction includes a system-level read-write transaction and / or a system-level write-only transaction. Further optionally, when concurrently executing the non-read-write transaction and any type of other transaction based on snapshot versions corresponding to different system-level timestamps of the target data node, the processor 1402 is specifically configured to: determine a first read timestamp for a user-level read-only transaction among the non-read-write transaction and any type of other transaction, and perform a read operation in a snapshot version whose system-level timestamp corresponding to the target data node is less than or equal to the first read timestamp, where the first read timestamp is any system-level timestamp corresponding to the target data node; determine a second read timestamp for a system-level write-only transaction among the non-read-write transaction and any type of other transaction, and perform a write operation on a snapshot version whose system-level timestamp corresponding to the target data node is equal to the second read timestamp to obtain a new snapshot version, where the second read timestamp is any system-level timestamp corresponding to the target data node; determine a third read timestamp for a system-level read-write transaction among the non-read-write transaction and any type of other transaction, A read and write operation is performed on a snapshot version corresponding to the target data node whose system-level timestamp is less than or equal to the third read timestamp to obtain a new snapshot version, where the third read timestamp is any system-level timestamp corresponding to the target data node. Further optionally, the first read timestamp, the second read timestamp, and the third read timestamp are the same system-level timestamp and are the most recent system-level timestamp corresponding to the target data node.Further optionally, when the processor 1402 performs a read operation in the snapshot version whose system-level timestamp corresponding to the target data node is less than or equal to the first read timestamp, it is specifically used to: if there is an overwritten snapshot version in the snapshot version whose system-level timestamp corresponding to the target data node is less than or equal to the first read timestamp, then perform the read operation in the snapshot version whose system timestamp is greater than or equal to the system timestamp of the overwritten snapshot version and less than or equal to the first read timestamp; if there is no overwritten snapshot version in the snapshot version whose system-level timestamp corresponding to the target data node is less than or equal to the first read timestamp, then perform the read operation in the snapshot version whose system-level timestamp corresponding to the target data node is less than or equal to the first read timestamp and the target data node and its corresponding snapshot version are less than or equal to the first read timestamp. Further optionally, when the concurrency between the non-read-write transaction and any other type of transaction is implemented as a system-level write-only transaction concurrently with a system-level read-write transaction, the processor 1402 is further configured to: if the system-level read-write transaction is a system-level rewrite transaction, and if the system-level rewrite transaction commits later than the system-level write-only transaction, set the subordinate relationship pointer of the second snapshot version generated by the later-committed system-level rewrite transaction to point to the first snapshot version generated by the earlier-committed system-level write-only transaction; and if the system-level read-write transaction is a system-level split transaction, and if the system-level split transaction commits later than the system-level write-only transaction, set the subordinate relationship pointer of the fourth snapshot version generated by the later-committed system-level split transaction to point to the third snapshot version generated by the earlier-committed system-level write-only transaction. Further optionally, the processor 1402 is further configured to: when executing a system-level split transaction for the second snapshot version, merge the first snapshot version and the second snapshot version to split them into at least two new snapshot versions, assign a system-level timestamp to each of the snapshot versions when the system-level split transaction commits, and store the at least two new snapshot versions and the assigned system-level timestamps in the mapping table in correspondence with each other. Further optionally, when the processor 1402 performs locked concurrent access control on the at least two system-level read-write transactions based on snapshot versions of the target data node corresponding to different system-level timestamps, it is specifically used to: for a first system-level read-write transaction, add concurrency marking information corresponding to the target data node to a concurrency control list, where the concurrency marking information is used to prohibit other system-level read-write transactions from accessing the target data node at the same time; after the first system-level read-write transaction is committed, clear the concurrency marking information to allow other system-level read-write transactions to access the target data node; the first system-level read-write transaction is one of the at least two system-level read-write transactions.Further optionally, the processor 1402 is further configured to: determine a fourth read timestamp for the first system-level read / write transaction, read the to-be-processed data from a snapshot version corresponding to the target data node whose system-level timestamp is less than or equal to the fourth read timestamp, and perform a write operation on the to-be-processed data to generate a new snapshot version; when the system transaction of the first read / write type commits, assign a system-level timestamp to it, and store the generated new snapshot version and the assigned system-level timestamp in the mapping table in a corresponding manner. Further optionally, when maintaining user-level timestamps for data items in the database located in memory, the processor 1402 is specifically configured to: assign a user-level timestamp to the user-level write-only transaction whenever a user-level write-only transaction accessing the data items in memory commits; and write the assigned user-level timestamp and the snapshot version generated by the user-level write-only transaction in the memory and the transaction log in a corresponding manner. Further optionally, when the processor 1402 uses user-level timestamps to perform concurrent access control on transactions accessing data items in memory, it is specifically used to: in the event of memory-state concurrent transactions accessing the same target data item in memory, perform concurrent access control on the memory-state concurrent transactions according to the transaction type of each transaction in the memory-state concurrent transactions and the snapshot versions of the target data items corresponding to different user-level timestamps. Further optionally, when performing concurrent access control on the memory-state concurrent transactions based on the transaction type of each transaction in the memory-state concurrent transactions and the snapshot versions of the target data items corresponding to different user-level timestamps, the processor 1402 is specifically configured to: if there are at least two user-level write-only transactions in the memory-state concurrent transactions, perform locked concurrent access control on the at least two user-level write-only transactions based on the snapshot versions of the target data items corresponding to different user-level timestamps, wherein the locked concurrent access control requires that only one user-level write-only transaction performs a write operation at a time; if there are at least two user-level read-only transactions in the memory-state concurrent transactions, perform lock-free concurrent access control on the at least two user-level read-only transactions based on the snapshot versions of the target data items corresponding to different user-level timestamps; and if there are both user-level read-only transactions and user-level write-only transactions in the memory-state concurrent transactions, perform lock-free concurrent access control on the user-level read-only transactions and the user-level write-only transactions based on the snapshot versions of the target data items corresponding to different user-level timestamps. Furthermore, as shown in Figure 14, the electronic device also includes other components such as a display 1404 and a power supply component 1405. Figure 14 only schematically shows some components, which does not mean that the electronic device only includes the components shown in Figure 14.In addition, the components within the dashed box in Figure 14 are optional, not mandatory, components, and may depend on the product form factor of the worker node. The worker node of this embodiment can be implemented as a terminal device such as a desktop computer, laptop computer, smartphone, or IoT device, or as a server-side device such as a conventional server, cloud server, or server array. If the worker node of this embodiment is implemented as a terminal device such as a desktop computer, laptop computer, or smartphone, it may include the components within the dashed box in Figure 14; if the worker node of this embodiment is implemented as a server-side device such as a conventional server, cloud server, or server array, it may not include the components within the dashed box in Figure 14. Accordingly, embodiments of the present disclosure also provide a computer-readable storage medium storing a computer program. When executed, the computer program can implement the steps that can be performed by an electronic device in the above-described method embodiments. Embodiments of the present disclosure also provide a computer program product comprising: a computer program / instructions. When executed by a processor, the computer program / instructions cause the processor to implement the steps of the method for multi-version concurrent access control of a database. This embodiment provides a concurrent access control solution for databases based on snapshot isolation technology. This concurrent access control solution proposes the concepts of two levels of timestamps: system-level timestamps and user-level timestamps. User-level timestamps are used to control concurrent access in the memory state for data items in the database memory, based on user-level timestamps. System-level timestamps are used to control concurrent access in the system state for data nodes in the database's external memory, based on system-level timestamps. In this disclosed embodiment, the two-level timestamps are integrated with snapshot isolation technology. While leveraging the advantages of snapshot isolation technology, the two-level timestamps simplify the implementation of concurrent access control and enable concurrent access control in both the memory state and the system state, thereby improving the concurrency performance of the database.The aforementioned memory can be implemented by any type of volatile or non-volatile memory device, or a combination thereof, such as static random-access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The aforementioned communication component is configured to facilitate wired or wireless communication between the device containing the communication component and other devices. The device containing the communication component can access a wireless network based on a communication standard, such as WiFi, 2G, 3G, 4G / LTE, 5G, or other mobile communication networks, or a combination thereof. In one exemplary embodiment, the communication component receives broadcast signals or broadcast-related information from an external broadcast management system via a broadcast channel. In one exemplary embodiment, the communication component also includes a near-field communication (NFC) module to facilitate short-range communication. For example, the NFC module can be implemented based on radio frequency identification (RFID), infrared data association (IrDA), ultra-wideband (UWB), Bluetooth (BT), and other technologies. The aforementioned display includes a screen, which can include a liquid crystal display (LCD) and a touch panel (TP). OIf the screen includes a touch panel, the screen can be implemented as a touch screen to receive input signals from the user. The touch panel includes one or more touch sensors to sense touches, slides, and gestures on the touch panel. The touch sensors can not only sense the boundaries of a touch or slide action, but also detect the duration and pressure associated with the touch or slide action. The power supply assembly described above provides power to various components of the device in which the power supply assembly is located. The power supply assembly may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power to the device in which the power supply assembly is located. Those skilled in the art will appreciate that embodiments of the present disclosure may be provided as methods, systems, or computer program products. Therefore, the present disclosure may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present disclosure may take the form of a computer program product embodied on one or more computer-readable storage media (including but not limited to magnetic disk storage, compact disc read-only memory (CD-ROM), optical storage, etc.) containing computer-usable program code. The present disclosure is described with reference to flowcharts and / or block diagrams of methods, devices (systems), and computer program products according to embodiments of the present disclosure. It should be understood that each process flow and / or block in the flowcharts and / or block diagrams, as well as combinations of processes and / or blocks in the flowcharts and / or block diagrams, can be implemented 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, such that the instructions, when executed by the processor of the computer or other programmable data processing device, produce a device for implementing the functions specified in one or more processes in the flowcharts and / or one or more blocks in the block diagrams. These computer program instructions can also be stored in a computer-readable memory capable of directing the computer or other programmable data processing device to operate in a specific manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means that implement the functions specified in one or more processes in the flowcharts and / or one or more blocks in the block diagrams. These computer program instructions can also be loaded onto a computer or other programmable data processing device, so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, so that 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.In a typical configuration, a computing device includes one or more processors (CPUs), input / output interfaces, network interfaces, and memory. Memory may include non-persistent storage in computer-readable media, random access memory (RAM), and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. O Memory is an example of computer-readable media. Computer-readable media includes both permanent and non-permanent, removable and non-removable media, and can be implemented using any method or technology to store information. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change random access memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassettes, magnetic disk storage or other magnetic storage devices, or any other non-transmitting media that can be used to store information that can be accessed by a computing device. As defined herein, computer-readable media does not include transient computer-readable media (transmitting media), such as modulated data signals and carrier waves. It should also be noted that the terms "comprise," "include," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, product, or apparatus comprising a list of elements may include not only those elements but also other elements not explicitly listed, or elements inherent to such process, method, product, or apparatus. Without further limitation, the phrase "comprising a..." does not preclude the presence of additional identical elements in the process, method, product, or apparatus comprising the elements. The foregoing are merely examples of the present disclosure and are not intended to limit the present disclosure. Those skilled in the art will readily appreciate that various modifications and variations of the present disclosure are possible. Any modifications, equivalent substitutions, improvements, and the like made within the spirit and principles of the present disclosure are intended to be encompassed by the claims of the present disclosure.

Claims

32 Claims 1. A multi-version concurrent access control method for a database, wherein: include: Maintain user-level timestamps for data items in the database that are in memory. A user-level timestamp corresponds to a snapshot version of the data item in memory. Maintaining a system-level timestamp for a data node in an external memory in a database, where one system-level timestamp corresponds to a snapshot version of the data node in the external memory, and the data node corresponds to at least one data item; User-level timestamps are used to control concurrent access to transactions that access data items in memory, and system-level timestamps are used to control concurrent access to transactions that access data nodes in external memory.

2. The method according to claim 1, wherein: Maintaining a system-level timestamp for data nodes in an external memory of a database includes: constructing a mapping table for an index tree of the database, wherein the data nodes in the external memory include leaf nodes and index nodes in the index tree, and the mapping table is used to store the address of each data node and its snapshot version corresponding to different system-level timestamps; whenever a system-level transaction accessing a data node is committed, assigning a system-level timestamp to the system-level transaction, and writing the assigned system-level timestamp and the snapshot version generated by the system-level transaction into the mapping table accordingly.

3. The method according to claim 2, wherein: The mapping table includes multiple data rows, one data row is used to store the address of a data node and its corresponding node update list, and the node update list is used to record snapshot versions corresponding to the corresponding data node at different system-level timestamps.

4. The method according to claim 3, wherein: The node update list corresponding to any data node is used to store the update node corresponding to the data node. The update node is added each time a system-level transaction accessing the data node is committed. The node update list is used to record the system-level timestamp assigned and the snapshot version generated when the system-level transaction currently accessing the data node is committed. The update node further includes: a persistence timestamp, where the persistence timestamp indicates the timestamp when a persistence operation is performed to successfully persist the data item corresponding to the snapshot version recorded in the update node from the memory to the external memory.

5. The method according to claim 4, wherein: In the node update list, a suffix compression method is used to point the subordinate relationship pointer of the next added update node to the last added update node; or in the node update list, a prefix compression method is used to point the subordinate relationship pointer of the last added update node to the common prefix of the next added update node.

6. The method according to any one of claims 2 to 5, wherein: The method utilizes system-level timestamps to perform concurrent access control on transactions accessing data nodes in external memory, including: in the event of concurrent system-level transactions accessing the same target data node in external memory, performing concurrent access control on the concurrent system-level transactions based on the transaction type of each transaction in the concurrent system-level transactions and snapshot versions of the target data node corresponding to different system-level timestamps.

7. The method according to claim 6, wherein: The system-level concurrent transactions include system-level write-only transactions, system-level read-write transactions, and / or user-level read-only transactions. Concurrent access control is performed on the system-level concurrent transactions based on the transaction type of each transaction in the system-level concurrent transactions and the snapshot versions of the target data node corresponding to different system-level timestamps, including: if there are at least two system-level read-write transactions in the system-level concurrent transactions, performing locked concurrent access control on the at least two system-level read-write transactions based on the snapshot versions of the target data node corresponding to different system-level timestamps, wherein the locked concurrent access control requires that only one system-level read-write transaction performs read and write operations at the same time; if there are non-read-write transactions and any other type of transactions in the system-level concurrent transactions, performing lock-free concurrent access control on the non-read-write transactions and any other type of transactions based on the snapshot versions of the target data node corresponding to different system-level timestamps; wherein the non-read-write transactions include user-level read-only transactions and / or system-level write-only transactions.

8. The method according to claim 7, wherein: According to the target data node at different system level timestamps 33, performing lock-free concurrent access control on the non-read-write transaction and any other type of transaction based on the snapshot version corresponding to the target data node at different system-level timestamps, including: concurrently executing the non-read-write transaction and any other type of transaction based on the snapshot versions corresponding to the target data node at different system-level timestamps; assigning a system-level timestamp to the non-read-only transaction based on a commit order of non-read-only transactions among the non-read-write transaction and any other type of transaction, and storing a new snapshot version generated by the non-read-only transaction and the assigned system-level timestamp in the mapping table in correspondence; wherein the non-read-only transaction includes a system-level read-write transaction and / or a system-level write-only transaction.

9. The method according to claim 8, wherein: Concurrently executing the non-read-write transaction and any other type of transaction based on snapshot versions corresponding to different system-level timestamps of the target data node, including: determining a first read timestamp for user-level read-only transactions among the non-read-write transaction and any other type of transaction, and performing a read operation on a snapshot version whose system-level timestamp corresponding to the target data node is less than or equal to the first read timestamp, where the first read timestamp is any system-level timestamp corresponding to the target data node; determining a second read timestamp for system-level write-only transactions among the non-read-write transaction and any other type of transaction, and performing a write operation on a snapshot version whose system-level timestamp corresponding to the target data node is equal to the second read timestamp to obtain a new snapshot version, where the second read timestamp is any system-level timestamp corresponding to the target data node; determining a third read timestamp for system-level read-write transactions among the non-read-write transaction and any other type of transaction, and performing a read-write operation on a snapshot version whose system-level timestamp corresponding to the target data node is less than or equal to the third read timestamp to obtain a new snapshot version. The third read timestamp is any system-level timestamp corresponding to the target data node.

10. The method according to claim 9, wherein: The first read timestamp, the second read timestamp, and the third read timestamp are the same system-level timestamp, and are the latest system-level timestamp corresponding to the target data node.

11. The method according to claim 9, wherein: Performing a read operation in the snapshot version whose system-level timestamp corresponding to the target data node is less than or equal to the first read timestamp, including: if there is an overwritten snapshot version in the snapshot version whose system-level timestamp corresponding to the target data node is less than or equal to the first read timestamp, performing a read operation in a snapshot version whose system timestamp is greater than or equal to the system timestamp of the overwritten snapshot version and less than or equal to the first read timestamp; if there is no overwritten snapshot version in the snapshot version whose system-level timestamp corresponding to the target data node is less than or equal to the first read timestamp, performing a read operation on the target data node and its corresponding snapshot version whose system-level timestamp is less than or equal to the first read timestamp.

12. The method according to claim 8, wherein: In a case where the concurrency between the non-read-write transaction and any other type of transaction is implemented as concurrency between a system-level write-only transaction and a system-level read-write transaction, the method further includes: if the system-level read-write transaction is a system-level rewrite transaction, and if the system-level rewrite transaction is committed later than the system-level write-only transaction, setting a subordinate relationship pointer of a second snapshot version generated by the later-committed system-level rewrite transaction to point to a first snapshot version generated by the earlier-committed system-level write-only transaction; and if the system-level read-write transaction is a system-level split transaction, and if the system-level split transaction is committed later than the system-level write-only transaction, setting a subordinate relationship pointer of a fourth snapshot version generated by the later-committed system-level split transaction to point to a third snapshot version generated by the earlier-committed system-level write-only transaction.

13. The method according to claim 12, wherein: Also includes: When a system-level split transaction is executed for the second snapshot version, the first snapshot version and the second snapshot version are merged and split into at least two new snapshot versions. When the system-level split transaction is committed, a system-level timestamp is assigned to each of the two new snapshot versions. The at least two new snapshot versions and the assigned system-level timestamps are stored in the mapping table in a corresponding manner.

14. The method according to claim 7, wherein: According to the snapshot version of the target data node corresponding to different system-level timestamps, the at least two system-level read and write transactions are locked concurrent access control, including: for the first system-level read and write transaction, adding the concurrency marking information corresponding to the target data node in the concurrency control list, the concurrency marking information is used to prohibit other system-level read and write transactions from accessing the target data node at the same time; After the first system-level read-write transaction is committed, the concurrency mark information is cleared to allow other system-level read-write transactions to access the target data node; the first system-level read-write transaction is one of the at least two system-level read-write transactions.

15. The method according to any one of claims 1 to 5 and 7 to 14, wherein: Maintaining user-level timestamps for data items in memory of a database includes: assigning a user-level timestamp to a user-level write-only transaction that accesses the data items in memory whenever the transaction is committed; and writing the assigned user-level timestamp and a snapshot version generated by the user-level write-only transaction into the memory and a transaction log, respectively.

16. The method according to claim 15, wherein: The method utilizes user-level timestamps to perform concurrent access control on transactions that access data items in memory, including: in the event of concurrent memory-state transactions that access the same target data item in memory, performing concurrent access control on the concurrent memory-state transactions based on the transaction type of each transaction in the concurrent memory-state transactions and snapshot versions of the target data item corresponding to different user-level timestamps.

17. The method according to claim 16, wherein: The concurrent access control is performed on the memory-state concurrent transactions based on the transaction type of each transaction in the memory-state concurrent transactions and the snapshot versions of the target data items corresponding to different user-level timestamps, including: if there are at least two user-level write-only transactions in the memory-state concurrent transactions, performing locked concurrent access control on the at least two user-level write-only transactions based on the snapshot versions of the target data items corresponding to different user-level timestamps, wherein the locked concurrent access control requires that only one user-level write-only transaction performs a write operation at a time; if there are at least two user-level read-only transactions in the memory-state concurrent transactions, performing lock-free concurrent access control on the at least two user-level read-only transactions based on the snapshot versions of the target data items corresponding to different user-level timestamps; and if there are both user-level read-only transactions and user-level write-only transactions in the memory-state concurrent transactions, performing lock-free concurrent access control on the user-level read-only transactions and the user-level write-only transactions based on the snapshot versions of the target data items corresponding to different user-level timestamps.

18. A data processing method, wherein: include: In response to a data read request, generating a user-level read-only transaction, wherein the user-level read-only transaction includes a query condition; Determining a first read timestamp corresponding to the user-level read-only transaction from user-level timestamps currently maintained for the data item in the memory of the database; Searching for target data that meets the query condition in the snapshot versions in the memory whose user-level timestamp is less than or equal to the first read timestamp; If the target data is not found in the memory, a second read timestamp corresponding to the user-level read-only transaction is determined from the system-level timestamp currently maintained for the data node in the database located in the external memory; and a snapshot version in the external memory whose system-level timestamp is less than or equal to the second read timestamp is searched for the target data that meets the query condition.

19. The method according to claim 18, wherein: Determining a first read timestamp corresponding to the user-level read-only transaction from user-level timestamps currently maintained for data items in the database located in the memory includes: using the most recently submitted user-level timestamp before the user-level read-only transaction among the user-level timestamps currently maintained for the data items in the database located in the memory as the first read timestamp; determining a second read timestamp corresponding to the user-level read-only transaction from system-level timestamps currently maintained for data nodes in the database located in the external memory includes: using the most recently submitted system-level timestamp before the user-level read-only transaction among the system-level timestamps currently maintained for the data nodes in the database located in the external memory as the second read timestamp.

20. The method according to claim 18 or 19, wherein: Querying target data that meets the query condition in a snapshot version in the external memory whose system-level timestamp is less than or equal to the second read timestamp, including: querying an index tree of the database according to the query condition to determine target data nodes that overlap with a key range in the query condition, where the data nodes in the external memory include leaf nodes and index nodes in the index tree; Query the mapping table corresponding to the index tree to obtain the address of the target data node and its snapshot versions corresponding to different system-level timestamps; the mapping table stores the address of each data node and its snapshot versions corresponding to different system-level timestamps; query the target data in the snapshot version whose system-level timestamp corresponding to the target data node is less than or equal to the second read timestamp.

21. A data processing method, wherein: include: In response to a data write request, generating a user-level write-only transaction, wherein the user-level write-only transaction is used to indicate writing data to be written into a database, wherein the data to be written corresponds to a target data item; Executing the user-level write-only transaction to write the data to be written into the memory of the database to generate a new snapshot version corresponding to the target data item; When the user-level read-only transaction is committed, a user-level timestamp is assigned to the user-level write-only transaction, and a new snapshot version corresponding to the user-level timestamp and the target data item is recorded accordingly; when a persistence condition corresponding to the memory is met, a persistence transaction is executed to persistently store each data item in the memory in at least one target data node in the external memory of the database, thereby generating a new snapshot version corresponding to the at least one target data node; When the persistent transaction is committed, a system-level timestamp is assigned to the persistent transaction, and a new snapshot version corresponding to the system-level timestamp and the at least one target data node is recorded accordingly.

22. The method according to claim 21, wherein: Executing the user-level write-only transaction to write the to-be-written data into the database's memory to generate a new snapshot version corresponding to the target data item includes: determining a first read timestamp corresponding to the user-level write-only transaction from user-level timestamps currently maintained for the data item in the database's memory; writing the to-be-written data item into a snapshot version whose user-level timestamp corresponding to the target data item is equal to the first read timestamp to generate a new snapshot version corresponding to the target data item; and correspondingly executing a persistence transaction to persistently store each data item in the memory in at least one target data node in the database's external memory to generate a new snapshot version corresponding to the at least one target data node. This includes: determining a second read timestamp corresponding to the persistence transaction from system-level timestamps currently maintained for the data node in the database's external memory; and persistently storing each data item in the memory in at least one target data node in the external memory whose system-level timestamp is less than or equal to the second read timestamp to generate a new snapshot version corresponding to the at least one target data node.

23. An electronic device, wherein: include: A memory and a processor; the memory stores one or more computer instructions, and the processor is used to execute the one or more computer instructions to implement the steps in the method according to any one of claims 1 to 22.

24. A computer-readable storage medium storing a computer program, wherein: When the computer program is executed by a processor, the processor is enabled to implement the steps of the method according to any one of claims 1 to 22.

25. A computer program product, wherein: The computer program product comprises a computer program / instructions, and when the computer program / instructions are executed by a processor, the processor is enabled to implement the steps in the method according to any one of claims 1 to 22.

Images