A version query method and device in a database, equipment, medium and product

Abstract

The application discloses a version query method and device in a database, equipment, a medium and a product, relates to the technical field of data processing, and comprises the following steps: obtaining a target primary key, a query type and query attribute information of a target query transaction; determining a target version index block matched with the target primary key in a first version index block in a cache and / or a second version index block in a main memory according to the target primary key of the target query transaction; obtaining a version chain head memory pointer matched with the target primary key according to an indirect layer pointer in the target version index block, and obtaining a version prefetch queue matched with the target primary key according to a memory pointer of the version prefetch queue in the target version index block; the version prefetch queue comprises memory pointers of at least one version; and querying a version matched with the target query transaction according to the query type and the query attribute information, the version chain head memory pointer and the version prefetch queue. The application improves the query efficiency of the version in the multi-version memory database.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and in particular to a method, apparatus, device, medium, and product for version querying in a database. Background Technology

[0002] Versions are the basic unit for data storage and management in a multi-version in-memory database. All versions are maintained in global memory space. Suppose that for any time t, there exists a time-ordered set of versions V(A) = {V1, V2, ..., V...}. n}, where V i Let t(V1) represent the i-th version of data object A, satisfying the time order constraint. <t(V2)<···<t(V n ), where t(V i (Represents version V) i The creation time of a version is the commit time of the transaction that created that version, and this time usually satisfies global consistency constraints. A version chain is an ordered linked list C(A) used to connect all versions of a data object A, such that it satisfies the following definition: C(A) = (V... n →V n−1 →...→V1),V i ∈V(A), where "→" represents the memory pointer connection relationship in the linked list.

[0003] In existing technologies, when transaction T is at time point t i To query data object A, the multi-version in-memory database engine iterates through the index from the root to the leaf node based on the query primary key of transaction T, then through the indirection layer and the memory block mapping table, and finally traverses to the version chain until it finds the i-th historical version of data object A that is visible to transaction T.

[0004] However, in scenarios with frequent transaction updates, versions accumulate in large numbers, causing the version chain length to continuously increase. For query operations, when encountering a long version chain, in order to find a version visible within the time range, a large number of versions must be traversed, leading to memory pointer chasing problems. This results in a large number of missing cache lines, which in turn increases pipeline stalls, reduces CPU execution efficiency, and ultimately leads to increased query latency, resulting in longer query times and low query efficiency. Summary of the Invention

[0005] This invention provides a method, apparatus, device, medium, and product for querying versions in a database, so as to improve the query efficiency of versions in a multi-version in-memory database.

[0006] In a first aspect, the present invention provides a version query method for a database, comprising:

[0007] Retrieve the target primary key, query type, and query attribute information of the target query transaction;

[0008] Based on the target primary key of the target query transaction, determine the target version index block that matches the target primary key from the first version index block in the cache and / or the second version index block in main memory; the first version index block is a data block pre-stored in the cache; the second version index block is a data block stored in main memory;

[0009] Based on the indirection layer pointer in the target version index block, obtain the memory pointer of the version chain head that matches the target primary key, and based on the memory pointer of the version prefetch queue in the target version index block, obtain the version prefetch queue that matches the target primary key; the version prefetch queue includes memory pointers of at least one version.

[0010] Based on the query type and query attribute information, as well as the version chain head memory pointer and the version prefetch queue, query the version that matches the target query transaction.

[0011] Secondly, the present invention also provides a version query device in a database, comprising:

[0012] The first acquisition module is used to acquire the target primary key, query type, and query attribute information of the target query transaction.

[0013] The determining module is configured to determine, based on the target primary key of the target query transaction, a target version index block that matches the target primary key in a first version index block in the cache and / or a second version index block in main memory; the first version index block is a data block pre-stored in the cache; the second version index block is a data block stored in main memory;

[0014] The second acquisition module is used to acquire a version chain head memory pointer that matches the target primary key based on the indirect layer pointer in the target version index block, and to acquire a version prefetch queue that matches the target primary key based on the memory pointer of the version prefetch queue in the target version index block; the version prefetch queue includes memory pointers of at least one version.

[0015] The query module is used to query the version that matches the target query transaction based on the query type, the query attribute information, the version chain head memory pointer, and the version prefetch queue.

[0016] Thirdly, the present invention also provides an electronic device, comprising:

[0017] At least one processor; and

[0018] A memory that is communicatively connected to at least one processor; wherein

[0019] The memory stores instructions that can be executed by at least one processor, which enables the at least one processor to perform the version query method in the database provided in any embodiment of the present invention.

[0020] Fourthly, the present invention also provides a computer-readable storage medium storing computer instructions for causing a processor to execute and implement the version query method in the database of any embodiment of the present invention.

[0021] Fifthly, the present invention also provides a computer program product, characterized in that the computer program product includes a computer program, which, when executed by a processor, implements the version query method in the database of any embodiment of the present invention.

[0022] The technical solution of this invention, for a target query transaction, prioritizes reading pre-stored index data from the cache, and only reads index data from main memory when the cache misses. This avoids repeatedly loading index data from main memory into the cache and then reading it, reducing the read latency of index data and thus improving the efficiency of determining the target version index block. By using a version prefetch queue pointer, multiple pre-stored version pointers are read, and versions are prefetched into the cache. This avoids the situation where memory pointer chase caused by long version chains requires repeatedly waiting for versions to be loaded from main memory into the cache. This allows the processor to quickly obtain the required data from the cache, reduces the cache miss rate, and improves the efficiency of version queries in a multi-version in-memory database.

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

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

[0025] Figure 1 This is a flowchart of a version query method in a database according to Embodiment 1 of the present invention;

[0026] Figure 2A This is a flowchart of a version query method in a database according to Embodiment 2 of the present invention;

[0027] Figure 2B This is a schematic diagram of a version query method framework in a database according to Embodiment 2 of the present invention;

[0028] Figure 3A This is a flowchart of a version query method in a database according to Embodiment 3 of the present invention;

[0029] Figure 3B This is a schematic diagram of a version query method in a database according to Embodiment 3 of the present invention;

[0030] Figure 4 This is a schematic diagram of the structure of a version query device in a database according to Embodiment 4 of the present invention;

[0031] Figure 5 This is a structural diagram of an electronic device that implements a version query method in a database according to an embodiment of the present invention. Detailed Implementation

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

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

[0034] In the technical solutions of the embodiments of the present invention, the acquisition, storage and application of target primary keys, query types and query attribute information, etc., all comply with the provisions of relevant laws and regulations and do not violate public order and good morals.

[0035] Example 1

[0036] Figure 1This is a flowchart of a version query method in a database provided in Embodiment 1 of the present invention. This embodiment is applicable to the situation of querying versions in a multi-version memory database. The method can be executed by a version query device in the database. The version query device in the database can be implemented in hardware and / or software and specifically configured in an electronic device.

[0037] See Figure 1 The version query methods shown in the database include:

[0038] S101. Obtain the target primary key, query type, and query attribute information of the target query transaction.

[0039] S102. Based on the target primary key of the target query transaction, determine the target version index block that matches the target primary key in the first version index block in the cache and / or the second version index block in the main memory.

[0040] S103. Based on the indirect layer pointer in the target version index block, obtain the version chain head memory pointer that matches the target primary key, and based on the memory pointer of the version prefetch queue in the target version index block, obtain the version prefetch queue that matches the target primary key.

[0041] S104. Based on the query type and the query attribute information, as well as the version chain head memory pointer and the version prefetch queue, query the version that matches the target query transaction.

[0042] In this embodiment, the target query transaction can be a query transaction that queries versions of data objects in a multi-version in-memory database. The primary key can be used to uniquely identify a data object; the query type can include, but is not limited to, point query type and range query type; a point query type can refer to querying a single data object; a range query type can refer to querying at least two data objects. In an optional embodiment, if the query type is a point query, the target primary key can be used to uniquely identify the data object to be queried; if the query type is a range query, the target primary key can be a starting primary key; the starting primary key can be the primary key with the smallest primary key value among the data objects to be queried; the query attribute information can be the attribute information of the target query transaction, which can include, but is not limited to, at least one of query time and query range; wherein, the query time can be the time when the target query transaction initiates the query; the query range can be the range of primary keys to be queried; in an optional embodiment, if the query type is a range query, the query attribute information can include the query range, and the target primary key can be the starting primary key of the query range; for example, if the target primary key is 74 and the query range is 5, then the target query transaction corresponds to 5 primary keys, namely 74, 75, 76, 77 and 78; the target query transaction queries the version of the data object corresponding to these 5 primary keys respectively.

[0043] In this embodiment, the cache can be a high-speed cache, specifically an L3 cache. The first version index block can be a data block pre-stored in the cache; the second version index block can be a data block stored in main memory. Each version index block corresponds one-to-one with a node in the version index tree. The version index tree can specifically be a B+ index tree, including a root node, intermediate nodes, and leaf nodes. Correspondingly, the version index block includes the version index block corresponding to the root node, the version index block corresponding to the intermediate node, and the version index block corresponding to the leaf node. The version index blocks corresponding to the root node and the intermediate nodes store memory pointers to the version index blocks of at least one lower-level node corresponding to the primary key range. The version index blocks corresponding to the leaf nodes store the primary key, the indirection layer pointer corresponding to the primary key, and the version queue memory pointer corresponding to the primary key. Each leaf node stores a different primary key. The indirection layer pointer corresponding to the primary key points to the memory block mapping table identifier corresponding to the primary key stored in the indirection layer. The memory block mapping table identifier can be converted into a version chain head memory pointer corresponding to the primary key through the memory block mapping table. The version chain head pointer can point to the head version of the version chain of the data object corresponding to the primary key, where the head version is the latest version of the data object corresponding to the primary key. The version queue memory pointer can point to the version prefetch queue of the data object corresponding to the primary key, where the version prefetch queue includes memory pointers to at least one version of the data object corresponding to the primary key.

[0044] Specifically, the process involves: obtaining the target primary key, query type, and query attribute information of the target query transaction; accessing the first version index block corresponding to the root node of the version index tree pre-stored in the cache to obtain at least one primary key range and memory pointers to the version index blocks corresponding to each primary key range; determining the primary key range to which the target primary key belongs; querying the cache for the existence of a version index block corresponding to the primary key range of the target primary key based on the memory pointers to the version index blocks corresponding to the primary key range of the target primary key; if it exists, accessing the first version index block corresponding to the primary key range of the target primary key in the cache; if it does not exist, accessing the second version index block corresponding to the primary key range of the target primary key in main memory; repeating the above process to query and access the version index blocks corresponding to the finer-grained primary key ranges to which the target primary key belongs in the cache and / or main memory, until... The process involves: identifying a version index block that stores only the target primary key (i.e., the version index block corresponding to the leaf node in the version index tree) and defining it as the target version index block; obtaining the indirection layer pointer stored in the target version index block and, based on the indirection layer pointer, obtaining the memory block mapping table identifier corresponding to the target primary key stored in the indirection layer; converting the memory block mapping table identifier into a version chain head memory pointer matching the target primary key; obtaining the version prefetch queue matching the target primary key based on the version prefetch queue memory pointer in the target version index block; and using a specific algorithm, querying for a version matching the target query transaction based on the query type, the query attribute information, the version chain head memory pointer, and the version prefetch queue.

[0045] Optionally, the first version index block is stored in the cache in the following manner: collecting the historical index access paths of at least one historical query transaction in the version index tree; according to each historical index access path, counting the access frequency of the version index block corresponding to each node in the version index tree; for each level in the version index tree, determining the level prefetch quantity of the level according to the prefetch ratio, version index block size and cache space size corresponding to the level; and prefetching the version index blocks with higher access frequency in each level into the cache as the first version index block.

[0046] Among them, the historical query transaction can be a query transaction that has been completed before the target query transaction occurs; the historical index access path can be the path traversed in the process of determining the target version index block that matches the historical query transaction; the version index tree hierarchy includes the root node layer, the leaf node layer and at least one intermediate node layer.

[0047] Specifically, at least one historical query transaction within a historical time slice is collected, representing its historical index access path in the version index tree. The end time of the historical time slice is before the query time corresponding to the target query transaction. Based on each version index block in each historical index access path, the access frequency of the version index block corresponding to each node in the version index tree is calculated. For each level in the version index tree, the level prefetch quantity is determined based on the prefetch ratio, version index block size, and cache space size corresponding to that level. For example, the level prefetch quantity can be determined using the following formula:

[0048] ;

[0049] in, Indicates the number of levels to prefetch; Indicates the prefetch ratio; Indicates the size of the cache space; Indicates the version index block size.

[0050] It should be noted that the level prefetch ratio of each level can be set independently by technical personnel according to actual needs or practical experience. This invention does not limit this. It is sufficient to satisfy the following: the level prefetch ratio of the root node level is relatively small, the level prefetch ratio of each intermediate node level gradually increases, and the level prefetch ratio of the leaf node level is relatively high.

[0051] The pointers of the most frequently accessed version index blocks in each level are stored in the index path prefetch table; and the corresponding version index blocks are prefetched from main memory into the cache as the first version index blocks according to the pointers of each version index block recorded in the index path prefetch table; this makes it easier to adjust the version index blocks prefetched into the cache by updating the index path prefetch table in real time.

[0052] Understandably, by adopting the above technical solution, the access frequency of the version index block corresponding to each node in each layer can be counted, and the version index blocks with higher access frequency can be prefetched into the cache. This prioritizes ensuring that the version index blocks that are easily accessed later can be accessed quickly, further improving the access efficiency of the version index blocks. According to the hierarchical architecture of the B+ index tree, the index traversal process is to traverse from the root node level to the leaf node level. The access frequency of the upper-level nodes is higher than that of the lower-level nodes. A certain number of version index blocks are selected from each level and cached in memory to ensure that the version index blocks corresponding to each node in each level are prefetched into the cache. This avoids storing too many version index blocks of the upper-level nodes in the cache, ensuring the validity of the version index blocks in the cache and improving the cache utilization rate.

[0053] The technical solution of this invention, for a target query transaction, prioritizes reading pre-stored index data from the cache, and only reads index data from main memory when the cache misses. This avoids repeatedly loading index data from main memory into the cache and then reading it, reducing the read latency of index data and thus improving the efficiency of determining the target version index block. By using a version prefetch queue pointer, multiple pre-stored version pointers are read, and versions are prefetched into the cache. This avoids the situation where memory pointer chase caused by long version chains requires repeatedly waiting for versions to be loaded from main memory into the cache. This allows the processor to quickly obtain the required data from the cache, reduces the cache miss rate, and improves the efficiency of version queries in a multi-version in-memory database.

[0054] Example 2

[0055] Figure 2A This is a flowchart of a version query method in a database provided in Embodiment 2 of the present invention. The present invention is an optimization and improvement based on the technical solution of the above embodiments.

[0056] Furthermore, the step of "querying the version that matches the target query transaction based on the query type, the query attribute information, the version chain head memory pointer, and the version prefetch queue" is refined to: "If the query type is a point query type, then the last position in the version prefetch queue is taken as the first position, and the position above the last position in the version prefetch queue is taken as the second position; the version chain head memory pointer is taken as the first memory pointer; the version corresponding to the first position is prefetched into the cache, and the version corresponding to the second position is prefetched into the cache; based on the first memory pointer, the version corresponding to the first position in the cache is obtained; and it is verified whether the query time of the target query transaction is within the lifecycle of the version corresponding to the first position." If the query time of the target query transaction is within the lifecycle of the version corresponding to the first position, then the version corresponding to the first position is determined as the version matching the target primary key; if the query time of the target query transaction is outside the lifecycle of the version corresponding to the first position, then the first position is updated to the second position, the second position is updated to the previous position of the second position, and the first memory pointer is updated to the predecessor memory pointer in the version corresponding to the first position; return to the step of prefetching the version corresponding to the second position until the query time of the target query transaction is within the lifecycle of the version corresponding to the first position; the version matching the target primary key is determined as the version matching the target query transaction.

[0057] It should be noted that for any parts not described in detail in the embodiments of the present invention, please refer to the description in the foregoing embodiments.

[0058] See Figure 2A The version query methods shown in the database include:

[0059] S201. Obtain the target primary key, query type, and query attribute information of the target query transaction.

[0060] S202. Based on the target primary key of the target query transaction, determine the target version index block that matches the target primary key in the first version index block in the cache and / or the second version index block in the main memory.

[0061] S203. Based on the indirect layer pointer in the target version index block, obtain the memory pointer of the version chain head that matches the target primary key, and based on the memory pointer of the version prefetch queue in the target version index block, obtain the version prefetch queue that matches the target primary key.

[0062] S204. If the query type is a point query type, then the last position in the version prefetch queue is taken as the first position, and the previous position in the version prefetch queue adjacent to the last position is taken as the second position.

[0063] S205. Use the memory pointer at the head of the version chain as the first memory pointer.

[0064] S206. Prefetch the version corresponding to the first position into the cache, and prefetch the version corresponding to the second position into the cache.

[0065] S207. Based on the first memory pointer, obtain the version corresponding to the first position in the cache.

[0066] S208. Verify whether the query time of the target query transaction is within the lifecycle of the version corresponding to the first position.

[0067] S209. If the query time of the target query transaction is within the lifecycle of the version corresponding to the first position, then the version corresponding to the first position is determined as the version that matches the target primary key.

[0068] S210. If the query time of the target query transaction is outside the lifecycle of the version corresponding to the first position, then update the first position to the second position, update the second position to the previous position of the second position, and update the first memory pointer to the predecessor memory pointer in the version corresponding to the first position.

[0069] S211. Return to the step of prefetching the version corresponding to the second position until the query time of the target query transaction is within the lifecycle of the version corresponding to the first position.

[0070] S212. The version that matches the target primary key is determined as the version that matches the target query transaction.

[0071] In this embodiment, the last position is the end position of the version prefetch queue; the last position of the version prefetch queue stores the memory pointer of the latest version of the data object corresponding to the primary key; the version prefetch queue is arranged in the order of version age, with the older version at the head and the latest version at the tail; the length of the version prefetch queue can be set independently by technical personnel based on practical experience or actual needs. The predecessor memory pointer can be a pointer to the previous older version of a certain version and can be stored in the version; for example, the third version of data object A stores a pointer to the second version of data object A, and this pointer to the third version of data object A is the predecessor memory pointer of the second version.

[0072] Each version has a lifecycle; the lifecycle is a left-closed, right-open interval, with the lower limit being the creation time of the corresponding version and the upper limit being the creation time of the next version. For example, suppose the creation time of the second version of data object A is 'a'; the latest version is the third version, with a creation time of 'b'. Then the lifecycle of the second version of data object A is [a, b), and the lifecycle of the third version is [b, INF), where INF can represent infinity.

[0073] Specifically, if the query type is a point query, then the last position in the version prefetch queue is taken as the first position, and the position preceding the last position in the version prefetch queue is taken as the second position; the memory pointer of the version chain head is taken as the first memory pointer; the latest version pointed to by the memory pointer stored at the first position is prefetched into the cache, and the candidate version pointed to by the memory pointer stored at the second position is prefetched into the cache; the candidate version is the version preceding the latest version; based on the first memory pointer, the version corresponding to the first position in the cache is obtained, that is, the latest version already stored in the cache; and it is verified whether the query time of the target query transaction is within the lifecycle of the latest version.

[0074] If the query time of the target query transaction is within the lifecycle of the latest version, then the latest version is determined as the version matching the target primary key; if the query time of the target query transaction is outside the lifecycle of the latest version, then the first position is updated to the second position, that is, the position above the last position is taken as the first position; the second position is updated to the position above the second position; and the first memory pointer is updated to the predecessor memory pointer in the latest version, wherein the predecessor memory pointer points to the alternative version.

[0075] Re-fetch the previous version of the candidate version and retrieve the candidate version from the cache; verify whether the query time of the target query transaction is within the lifecycle of the candidate version; if the query time of the target query transaction is within the lifecycle of the candidate version, then determine the candidate version as the version matching the target primary key; otherwise, continue to update the first position, the second position, and the first memory pointer until the query time of the target query transaction is within the lifecycle of the version corresponding to the first position; determine the version matching the target primary key as the version matching the target query transaction.

[0076] For example, if the latest version is V100, then V100 and V99 are prefetched into the cache; V100 is read, and it is verified whether the query time of the target query transaction is within the lifecycle of V100; if so, V100 is determined as the version that matches the target primary key; if not, V98 is prefetched into the cache, and V99 is read; it is verified whether the query time of the target query transaction is within the lifecycle of V99; before reading each version, its previous version is prefetched into the cache until a version whose query time of the target query transaction is within its lifecycle is found, and it is determined as the version that matches the target query transaction.

[0077] Optional, Figure 2B This is a schematic diagram of a version query method framework in a database. For example... Figure 2B As shown, there exists a B+ tree index data structure based on the primary key; Figure 2B The B+ tree index data structure shown has three layers, from top to bottom: the root node layer, the intermediate node layer, and the leaf node layer, corresponding to layers 0, 1, and 2, respectively. The access frequency of data blocks corresponding to each node in the B+ tree can be counted to construct an index path prefetch table. Based on this table, version index blocks in main memory are prefetched into the cache. Each node in the leaf node layer stores a memory pointer to the version prefetch queue corresponding to the primary key and an indirection layer pointer. The version prefetch queue can be accessed through its memory pointer, facilitating subsequent prefetching of versions into the cache. The CPU cores can read the pre-stored first version index block and version from the cache, thereby improving query efficiency.

[0078] The indirection pointers stored in the leaf node layer point to memory block mapping table identifiers in the indirection layer. These identifiers can then be converted into version chain head memory pointers corresponding to the primary key, thus obtaining the latest version of the data object corresponding to the primary key. Figure 2BAs shown, the version chain head memory pointer points to the latest version V100; each version also has a predecessor memory pointer pointing to the previous version, thus forming a version chain; the version chain also includes older versions V0, V1, V2 and V3; the lifecycle of version V0 is [1,3); the lifecycle of version V1 is [3,5); the lifecycle of version V2 is [5,7); the lifecycle of version V3 is [7,15); and the lifecycle of version V100 is [150,INF).

[0079] In this embodiment of the invention, when the target query transaction is a point query type, before reading the latest version of the data object corresponding to the primary key through the version chain head pointer, the latest version and the previous version of the latest version are prefetched into the cache by using the memory pointer of the latest version prefetch queue stored in the version prefetch queue. This makes it easier to hit the latest version in the cache when reading the latest version through the version chain head pointer, avoiding waiting for the latest version to be loaded from main memory into the cache, thus improving the version reading efficiency under the point query type. By prefetching the previous version of the version from main memory into the cache before reading each version, the situation where the life cycle of the version does not match the query time of the target query transaction, still requires reading the previous version from main memory, further improving the version reading efficiency.

[0080] Example 3

[0081] Figure 3A This is a flowchart of a version query method in a database provided in Embodiment 3 of the present invention. The present invention is an optimization and improvement based on the technical solutions of the above embodiments.

[0082] Furthermore, the phrase "based on the query type and the query attribute information, as well as the version chain head memory pointer and the version prefetch queue, query the version that matches the target query transaction" is refined to: "If the query type is a range query type, then based on the query range of the target query transaction and the target primary key, determine at least one range primary key of the target query transaction; based on the query time, as well as the version chain head memory pointer and the version prefetch queue, determine the version that matches the target primary key; in the version prefetch queue, query the neighboring version memory pointer associated with the memory pointer of the first version; based on the neighboring version memory pointer and the query time, determine the second version; the primary key corresponding to the first version is adjacent to the primary key corresponding to the second version and is less than the primary key corresponding to the second version; the version that matches the target primary key and the versions that match each of the range primary keys are determined as the versions that match the target query transaction."

[0083] It should be noted that for any parts not described in detail in the embodiments of the present invention, please refer to the description in the foregoing embodiments.

[0084] See Figure 3A The version query methods shown in the database include:

[0085] S301. Obtain the target primary key, query type, and query attribute information of the target query transaction.

[0086] S302. Based on the target primary key of the target query transaction, determine the target version index block that matches the target primary key in the first version index block in the cache and / or the second version index block in the main memory.

[0087] S303. Based on the indirect layer pointer in the target version index block, obtain the memory pointer of the version chain head that matches the target primary key, and based on the memory pointer of the version prefetch queue in the target version index block, obtain the version prefetch queue that matches the target primary key.

[0088] S304. If the query type is a range query type, then determine at least one range primary key of the target query transaction based on the query range of the target query transaction and the target primary key.

[0089] S305. Based on the query time, the version chain head memory pointer, and the version prefetch queue, determine the version that matches the target primary key.

[0090] S306. In the version prefetch queue, query the neighboring version memory pointers associated with the memory pointer of the first version.

[0091] S307. Determine the second version based on the neighbor version memory pointer and the query time.

[0092] S308. The version that matches the target primary key and the version that matches each of the range primary keys are determined as the version that matches the target query transaction.

[0093] In this embodiment, the range primary key can be the primary key corresponding to the data object to be queried, excluding the target primary key, under the range query type. The neighbor version memory pointer can point to the second version corresponding to the first version; the primary key corresponding to the first version is adjacent to the primary key corresponding to the second version and is less than the primary key corresponding to the second version; for example, if the primary key corresponding to the first version is 74, then the primary key corresponding to the second version is 75. The version prefetch queue stores memory pointers of at least one version, as well as neighbor version memory pointers of each version.

[0094] Specifically, if the query type is a range query type, the target primary key is used as the starting primary key within the query range, and the range primary key is determined according to the query range; for example, if the target primary key is 74 and the query range is 5, the range primary key includes 75, 76, 77 and 78.

[0095] Based on the query time, the version chain head memory pointer, and the version prefetch queue, the version matching the target primary key is determined. It should be noted that the process of determining the version matching the target primary key in this embodiment is similar to the process of determining the version matching the target primary key when the query type is a dot query type in the above embodiment, and will not be repeated here.

[0096] In the version prefetch queue, query the neighboring version memory pointers associated with the memory pointer of the first version; using a certain algorithm, determine the second version based on the neighboring version memory pointers and the query time; determine the version that matches the target primary key and the versions that match each range primary key as the versions that match the target query transaction.

[0097] Optionally, determining the second version based on the neighbor version memory pointer and the query time includes: determining the neighbor version memory pointer as an auxiliary memory pointer and obtaining the auxiliary version pointed to by the auxiliary memory pointer; verifying whether the query time of the target query transaction is within the lifecycle of the auxiliary version; if the query time of the target query transaction is within the lifecycle of the auxiliary version, then determining the auxiliary version as the second version; if the query time of the target query transaction is outside the lifecycle of the auxiliary version, then updating the auxiliary memory pointer to the predecessor or successor memory pointer of the auxiliary version according to the temporal relationship between the query time and the lifecycle; returning to the step of obtaining the auxiliary version pointed to by the auxiliary memory pointer, until the query time of the target query transaction is within the lifecycle of the auxiliary version.

[0098] The successor memory pointer can be a pointer to the next newer version of each version; for example, the successor memory pointer of the second version of data object A points to the third version of data object A.

[0099] Specifically, if the query time of the target query transaction is outside the lifecycle of the auxiliary version, the temporal relationship between the query time and the lifecycle is determined; if the query time is earlier than the lifecycle, the auxiliary memory pointer is updated to the predecessor memory pointer of the auxiliary version; if the query time is later than the lifecycle, the auxiliary memory pointer is updated to the successor memory pointer of the auxiliary version; the step of obtaining the auxiliary version pointed to by the auxiliary memory pointer is returned until the query time of the target query transaction is within the lifecycle of the auxiliary version, and the auxiliary version is determined as the second version.

[0100] Understandably, by adopting the above technical solution, after reading the version of the adjacent primary key pointed to by the neighbor version memory pointer specified in the version prefetch queue of a certain primary key, it is possible to verify whether the lifecycle of the version matches the query time of the target query transaction; even if the query time of the target query transaction is outside the lifecycle of the version, it is possible to continue traversing the version chain of the adjacent primary keys according to the chronological order until a version whose lifecycle covers the query time is found, thus ensuring the accuracy of version queries.

[0101] Optionally, the method further includes: for a version update transaction of the first data object, obtaining the memory pointer of the latest version of the second data object, and using the memory pointer of the latest version of the second data object as the neighbor version memory pointer of the current update version of the first data object; the primary key corresponding to the second data object is adjacent to the primary key of the first data object and is greater than the primary key of the first data object; establishing an association relationship between the neighbor version memory pointer and the memory pointer of the current update version, and storing the association at the end of the version prefetch queue corresponding to the primary key of the first data object.

[0102] The current update version can be the version that the first data object's version update transaction needs to update.

[0103] For example, the primary key of data object A is 12, and the latest version of data object A is V100; the primary key of data object B is 13, and the latest version of data object B is V10; when data object A is updated, the current updated version is V101, and the memory pointer of the V10 version of data object B is obtained; the memory pointer of the V10 version of data object B is used as the neighbor version memory pointer of the V101 version of data object A; the association relationship between the memory pointer of the V10 version of data object B and the neighbor version memory pointer of the V101 version of data object A is established, and the association is stored at the end of the version prefetch queue corresponding to the primary key of data object A.

[0104] It is understandable that by adopting the above technical solution, when the version of each data object is updated, the memory pointer of the latest version of the data object adjacent to its primary key can be used as the neighbor version memory pointer of the memory pointer of the current updated version, and stored in the version prefetch queue. This makes it easier to directly obtain the neighbor version memory pointer from the version prefetch queue when performing a query transaction of type range query, thereby improving the version reading efficiency.

[0105] Optional, Figure 3B This is a schematic diagram illustrating the process of a version query method in a database. For example... Figure 3B As shown, the target query transaction T6 is a point query type query transaction. Figure 3B The left side of the region includes the target version index block corresponding to the primary key 75 of the target query transaction T6, where key represents the primary key; the version pointer can refer to the version chain head pointer in this embodiment; and the Vque pointer can refer to the version prefetch queue pointer in this embodiment.

[0106] like Figure 3B As shown, the maximum length of the version prefetch queue with primary key 75 is 128; the version prefetch queue actually contains memory pointers for 100 versions, i.e. Figure 3B The symbols “&V0”, “&V1”, and “&V100” shown, as well as the neighboring version memory pointers associated with each version's memory pointer, are “##”. It should be noted that “##” is an example, and the neighboring version memory pointers associated with each memory pointer may be different. “tail” is the tail pointer of the version prefetch queue, pointing to the memory address of the latest version in the version prefetch queue, i.e., “&V100”.

[0107] When the target query transaction T6 is executed, the latest version V100 corresponding to primary key 75 is found through the version pointer; it is verified whether the query time of the target query transaction T6 is within the lifecycle of version V100; if not, version V99 is found through the predecessor memory pointer in version V100, and the above process is repeated until version V0, whose query time of the target query transaction T6 is within its lifecycle, is found and determined as the query result; it should be noted that V0 refers to the version that satisfies the requirement that the query time of the target query transaction T6 is within its lifecycle, not the oldest version.

[0108] like Figure 3B As shown, the target query transaction T4 is a range query type, with the starting primary key being 74 and the query range being 5. Therefore, the primary keys to be queried are 74, 75, 76, 77, and 78. Figure 3B The left side of the region includes the target version index block corresponding to primary key 74 of the target query transaction T4. Figure 3BThe version prefetch queue for primary key 74 is also shown, where the first row at the top of the queue contains the memory addresses of each version of the dataset object corresponding to primary key 74, and the second row at the bottom of the queue contains the memory addresses of each version of the data object corresponding to primary key 75; for example... Figure 3B As shown, the memory pointer "&V0" of version V0 corresponding to primary key 74 is associated with the memory pointer "&V1" of version V1 corresponding to primary key 75; the memory pointer "&V3" of version V3 corresponding to primary key 74 is associated with the memory pointer "&V99" of version V99 corresponding to primary key 75.

[0109] When the target query transaction T4 is executed, version V0 corresponding to primary key 74 is found and used as the query result for primary key 74. In the version prefetch queue, the neighboring version memory pointer associated with the memory pointer of version V0 corresponding to primary key 74 is determined, which is version V1 corresponding to primary key 75. It is verified whether the query time of the target query transaction T4 is within the lifecycle of version V1 corresponding to primary key 75. If the query time of the target query transaction T4 is within the lifecycle of version V1 corresponding to primary key 75, then version V1 corresponding to primary key 75 is used as the query result for primary key 75. The version prefetch queue corresponding to primary key 75 is obtained, and in the version prefetch queue corresponding to primary key 75, the neighboring version memory address associated with the memory address of version V1 is found, and then the query result for primary key 76 is determined through the neighboring version memory address. The above process is repeated until the query result corresponding to primary key 78 is determined. The query results of primary keys 74, 75, 76, 77, and 78 are determined as the query results of the target query transaction T4.

[0110] This invention enables the retrieval of neighbor version memory pointers from the version prefetch queue of each primary key when the query type of the target query transaction is a range query. Based on the neighbor version memory pointers, the version of the adjacent primary key can be directly obtained, thereby avoiding the repeated traversal of the primary key index in order to obtain the latest version of each primary key to be queried, and improving the query efficiency under the range query type.

[0111] Example 4

[0112] Figure 4 This is a schematic diagram of a version query device in a database according to Embodiment 4 of the present invention. This embodiment of the invention is applicable to querying versions in a multi-version in-memory database. The device can execute version query methods in the database. This version query device can be implemented in hardware and / or software, and can be configured in an electronic device.

[0113] See Figure 4The version query device in the database shown includes a first acquisition module 401, a determination module 402, a second acquisition module 403, and a query module 404, wherein...

[0114] The first acquisition module 401 is used to acquire the target primary key, query type and query attribute information of the target query transaction;

[0115] The determining module 402 is configured to determine, based on the target primary key of the target query transaction, a target version index block that matches the target primary key in a first version index block in the cache and / or a second version index block in main memory; the first version index block is a data block pre-stored in the cache; the second version index block is a data block stored in main memory;

[0116] The second acquisition module 403 is used to acquire a version chain head memory pointer that matches the target primary key based on the indirect layer pointer in the target version index block, and to acquire a version prefetch queue that matches the target primary key based on the memory pointer of the version prefetch queue in the target version index block; the version prefetch queue includes memory pointers of at least one version.

[0117] The query module 404 is used to query the version that matches the target query transaction based on the query type, the query attribute information, the version chain head memory pointer, and the version prefetch queue.

[0118] The technical solution of this invention, for a target query transaction, prioritizes reading pre-stored index data from the cache, and only reads index data from main memory when the cache misses. This avoids repeatedly loading index data from main memory into the cache and then reading it, reducing the read latency of index data and thus improving the efficiency of determining the target version index block. By using a version prefetch queue pointer, multiple pre-stored version pointers are read, and versions are prefetched into the cache. This avoids the situation where memory pointer chase caused by long version chains requires repeatedly waiting for versions to be loaded from main memory into the cache. This allows the processor to quickly obtain the required data from the cache, reduces the cache miss rate, and improves the efficiency of version queries in a multi-version in-memory database.

[0119] Optionally, the device further includes:

[0120] The acquisition module is used to acquire the historical index access path of at least one historical query transaction in the version index tree;

[0121] The statistics module is used to count the access frequency of the version index block corresponding to each node in the version index tree based on the access paths of each historical index.

[0122] The quantity determination module is used to determine the level prefetch quantity for each level in the version index tree based on the prefetch ratio, version index block size and cache space size corresponding to the level.

[0123] The first prefetch module is used to prefetch the most frequently accessed version index blocks in each level into the cache as the first version index blocks.

[0124] Optionally, the query attribute information includes the query time;

[0125] The query module 404 includes:

[0126] The first position determination unit is used to determine the last position in the version prefetch queue as the first position and the previous position in the version prefetch queue adjacent to the last position as the second position if the query type is a point query type.

[0127] The first memory pointer determination unit is used to use the version chain head memory pointer as the first memory pointer;

[0128] The first prefetch unit is used to prefetch the version corresponding to the first position into the cache, and to prefetch the version corresponding to the second position into the cache;

[0129] The first acquisition unit is used to acquire the version corresponding to the first position in the cache based on the first memory pointer;

[0130] The first verification unit is used to verify whether the query time of the target query transaction is within the lifecycle of the version corresponding to the first position;

[0131] The first determining unit is configured to determine the version corresponding to the first position as the version that matches the target primary key if the query time of the target query transaction is within the lifecycle of the version corresponding to the first position.

[0132] The first update unit is configured to update the first position to the second position, update the second position to the previous position, and update the first memory pointer to the predecessor memory pointer in the version corresponding to the first position if the query time of the target query transaction is outside the lifecycle of the version corresponding to the first position.

[0133] The first return unit is used to return the step of prefetching the version corresponding to the second position until the query time of the target query transaction is within the lifecycle of the version corresponding to the first position;

[0134] The second determining unit is used to determine the version that matches the target primary key as the version that matches the target query transaction.

[0135] Optionally, the query attribute information includes query time and query range;

[0136] The query module 404 includes:

[0137] A primary key determination unit is configured to determine at least one range primary key of the target query transaction based on the query range of the target query transaction and the target primary key if the query type is a range query type.

[0138] The first version determination unit is used to determine the version that matches the target primary key based on the query time, the version chain head memory pointer, and the version prefetch queue.

[0139] The query unit is used to query the memory pointers of neighboring versions associated with the memory pointer of the first version in the version prefetch queue;

[0140] The second version determination unit is used to determine the second version based on the neighbor version memory pointer and the query time; the primary key corresponding to the first version is adjacent to the primary key corresponding to the second version and is smaller than the primary key corresponding to the second version.

[0141] The third determining unit is used to determine the version that matches the target primary key and the version that matches each of the range primary keys as the version that matches the target query transaction.

[0142] Optionally, the second version determining unit is specifically used for:

[0143] The neighbor version memory pointer is identified as an auxiliary memory pointer, and the auxiliary version pointed to by the auxiliary memory pointer is obtained;

[0144] Verify whether the query time of the target query transaction is within the lifecycle of the auxiliary version;

[0145] If the query time of the target query transaction is within the lifecycle of the auxiliary version, then the auxiliary version is determined as the second version;

[0146] If the query time of the target query transaction is outside the lifecycle of the auxiliary version, then the time sequence between the query time and the lifecycle will be used;

[0147] Based on the timing relationship, the auxiliary memory pointer is updated to the predecessor or successor memory pointer of the auxiliary memory pointer;

[0148] Return to the step of obtaining the auxiliary version pointed to by the auxiliary memory pointer, until the query time of the target query transaction is within the lifecycle of the auxiliary version.

[0149] Optionally, the device further includes:

[0150] The latest version acquisition module is used to acquire the memory pointer of the latest version of the second data object for the version update transaction of the first data object, and use the memory pointer of the latest version of the second data object as the neighbor version memory pointer of the current update version of the first data object; the primary key of the second data object is adjacent to the primary key of the first data object and is greater than the primary key of the first data object;

[0151] The association module is used to establish the association relationship between the neighbor version memory pointer and the memory pointer of the current updated version, and store the association at the end of the version prefetch queue corresponding to the primary key of the first data object.

[0152] The version query device in the database provided in this embodiment of the invention can execute the version query method in the database provided in any embodiment of the invention, and has the corresponding functional modules and beneficial effects of executing the version query method in the database.

[0153] Example 5

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

[0155] like Figure 5As shown, the data query device 510 includes at least one processor 511 and a memory, such as a read-only memory (ROM) 512 or a random access memory (RAM) 513, communicatively connected to the at least one processor 511. The memory stores computer programs executable by the at least one processor. The processor 511 can perform various appropriate actions and processes based on the computer program stored in the ROM 512 or loaded from storage unit 518 into the RAM 513. The RAM 513 can also store various programs and data required for the operation of the data query device 510. The processor 511, ROM 512, and RAM 513 are interconnected via a bus 514. An input / output (I / O) interface 515 is also connected to the bus 514.

[0156] Multiple components in the data query device 510 are connected to the I / O interface 515, including: an input unit 516, such as a keyboard, mouse, etc.; an output unit 517, such as various types of displays, speakers, etc.; a storage unit 518, such as a disk, optical disk, etc.; and a communication unit 519, such as a network card, modem, wireless transceiver, etc. The communication unit 519 allows the data query device 510 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0157] Processor 511 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 511 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. Processor 511 performs the various methods and processes described above, such as version query methods in a database.

[0158] In some embodiments, the version query method in the database may be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 518. In some embodiments, part or all of the computer program may be loaded and / or installed on the data query device 510 via ROM 512 and / or communication unit 519. When the computer program is loaded into RAM 513 and executed by processor 511, one or more steps of the version query method in the database described above may be performed. Alternatively, in other embodiments, processor 511 may be configured to perform the version query method in the database by any other suitable means (e.g., by means of firmware).

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

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

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

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

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

[0164] A computing system can include clients and servers. Clients and servers are generally geographically separated and typically interact via communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system. It addresses the shortcomings of traditional physical hosts and VPS (Virtual Private Server) services, such as high management difficulty and weak business scalability.

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

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

Claims

1. A version query method in a database, characterized in that, The method includes: Retrieve the target primary key, query type, and query attribute information of the target query transaction; Based on the target primary key of the target query transaction, a target version index block matching the target primary key is determined from the first version index block in the cache and / or the second version index block in main memory; the first version index block is a data block pre-stored in the cache; the second version index block is a data block stored in main memory; Based on the indirection layer pointer in the target version index block, obtain the memory pointer of the version chain head that matches the target primary key, and based on the memory pointer of the version prefetch queue in the target version index block, obtain the version prefetch queue that matches the target primary key; the version prefetch queue includes memory pointers of at least one version. Based on the query type and query attribute information, as well as the version chain head memory pointer and the version prefetch queue, query the version that matches the target query transaction.

2. The method according to claim 1, characterized in that, The first version of the index block is stored in the cache in the following manner: Collect the historical index access path of at least one historical query transaction in the version index tree; Based on the historical index access paths described above, the access frequency of the version index block corresponding to each node in the version index tree is counted. For each level in the version index tree, the number of level prefetches is determined based on the prefetch ratio, version index block size, and cache space size corresponding to the level. The most frequently accessed version index blocks in each level are prefetched into the cache and used as the first version index blocks.

3. The method according to claim 1, characterized in that, The query attribute information includes the query time; The step of querying the version that matches the target query transaction based on the query type, the query attribute information, the version chain head memory pointer, and the version prefetch queue includes: If the query type is a point query type, then the last position in the version prefetch queue is taken as the first position, and the previous position in the version prefetch queue adjacent to the last position is taken as the second position. Use the memory pointer at the head of the version chain as the first memory pointer; Prefetch the version corresponding to the first position into the cache, and prefetch the version corresponding to the second position into the cache; Based on the first memory pointer, obtain the version corresponding to the first position in the cache; Verify whether the query time of the target query transaction is within the lifecycle of the version corresponding to the first position; If the query time of the target query transaction is within the lifecycle of the version corresponding to the first position, then the version corresponding to the first position is determined as the version that matches the target primary key; If the query time of the target query transaction is outside the lifecycle of the version corresponding to the first position, then the first position is updated to the second position, the second position is updated to the previous position of the second position, and the first memory pointer is updated to the predecessor memory pointer in the version corresponding to the first position. Return to the step of prefetching the version corresponding to the second position until the query time of the target query transaction is within the lifecycle of the version corresponding to the first position; The version that matches the target primary key is determined as the version that matches the target query transaction.

4. The method according to claim 1, characterized in that, The query attribute information includes query time and query range; The step of querying the version that matches the target query transaction based on the query type, the query attribute information, the version chain head memory pointer, and the version prefetch queue includes: If the query type is a range query type, then at least one range primary key of the target query transaction is determined based on the query range of the target query transaction and the target primary key; Based on the query time, the version chain head memory pointer, and the version prefetch queue, determine the version that matches the target primary key; In the version prefetch queue, query the memory pointers of neighboring versions associated with the memory pointer of the first version; The second version is determined based on the neighbor version memory pointer and the query time; the primary key corresponding to the first version is adjacent to the primary key corresponding to the second version, and is less than the primary key corresponding to the second version. The version that matches the target primary key, and the versions that match each of the range primary keys, are determined as the versions that match the target query transaction.

5. The method according to claim 4, characterized in that, The step of determining the second version based on the neighbor version memory pointer and the query time includes: The neighbor version memory pointer is identified as an auxiliary memory pointer, and the auxiliary version pointed to by the auxiliary memory pointer is obtained; Verify whether the query time of the target query transaction is within the lifecycle of the auxiliary version; If the query time of the target query transaction is within the lifecycle of the auxiliary version, then the auxiliary version is determined as the second version; If the query time of the target query transaction is outside the lifecycle of the auxiliary version, the auxiliary memory pointer is updated to the predecessor or successor memory pointer of the auxiliary version according to the temporal relationship between the query time and the lifecycle. Return to the step of obtaining the auxiliary version pointed to by the auxiliary memory pointer, until the query time of the target query transaction is within the lifecycle of the auxiliary version.

6. The method according to any one of claims 4-5, characterized in that, The method further includes: For the version update transaction of the first data object, obtain the memory pointer of the latest version of the second data object, and use the memory pointer of the latest version of the second data object as the neighbor version memory pointer of the current update version of the first data object; the primary key of the second data object is adjacent to the primary key of the first data object and is greater than the primary key of the first data object; Establish an association between the neighbor version memory pointer and the memory pointer of the current updated version, and store the association at the end of the version prefetch queue corresponding to the primary key of the first data object.

7. A version query device in a database, characterized in that, The device includes: The first acquisition module is used to acquire the target primary key, query type, and query attribute information of the target query transaction. The determining module is configured to determine, based on the target primary key of the target query transaction, a target version index block that matches the target primary key in a first version index block in the cache and / or a second version index block in main memory; the first version index block is a data block pre-stored in the cache; the second version index block is a data block stored in main memory; The second acquisition module is used to acquire a version chain head memory pointer that matches the target primary key based on the indirect layer pointer in the target version index block, and to acquire a version prefetch queue that matches the target primary key based on the memory pointer of the version prefetch queue in the target version index block; the version prefetch queue includes memory pointers of at least one version. The query module is used to query the version that matches the target query transaction based on the query type, the query attribute information, the version chain head memory pointer, and the version prefetch queue.

8. An electronic device, characterized in that, The electronic device includes: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores a computer program executable by the at least one processor, which enables the at least one processor to perform the version query method in the database according to any one of claims 1-6.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that, when executed by a processor, implement the version query method in the database according to any one of claims 1-6.

10. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the version query method in the database according to any one of claims 1-6.

Images