A predicate index method supporting batch multi-version transactions of a key-value database

Abstract

The application discloses a predicate index method supporting batch multi-version transaction of a key-value database, and the method is used in a multi-version concurrent control memory database system. The mechanism maintains a predicate index table for the minimum centralized storage unit of the memory database, and the table stores the mapping from a predicate function and its result to a data version physical address. For transaction execution of the database, the transaction is divided into batches by using periodic update, the multi-version concurrent control algorithm of the old version pointing to the new version is used to maintain that the main version physical address is unchanged in a batch, and thus the predicate index table does not need to be modified when the transaction is concurrently executed. Meanwhile, the predicate index mapping value when the transaction is submitted is cached to obtain a cache index table, and the cache can support direct access of the query request in the batch on one hand, and can be combined into the main predicate index table when the batch is incremented on the other hand, so that the index query response speed is improved and the index table update frequency is reduced.

Description

Technical Field

[0001] This invention relates to the field of database kernel and its application technology, and in particular to a predicate indexing method that supports batch multi-version transactions in key-value databases. Background Technology

[0002] Today, internet applications have become an integral part of people's lives. To meet diverse data storage and retrieval needs, more and more applications are choosing key-value databases, which offer flexible data storage formats and diverse storage strategies. However, on the one hand, unstructured or semi-structured key-value databases have long faced performance bottlenecks due to their inability to fully utilize indexing techniques to accelerate queries. On the other hand, key-value databases deeply integrated into business scenarios, especially memory-based key-value databases, need to support database transactions that meet ACID properties to a certain extent to better support business scenarios.

[0003] Transaction support in key-value databases has significant application implications. On one hand, robust transaction support, especially distributed transaction support, enables key-value databases to be more effectively integrated into various application scenarios, including but not limited to OLTP, stream computing system state backends, and caching engines, while maintaining high availability and partition tolerance. This significantly improves the robustness and reliability of business applications in these scenarios. On the other hand, snapshot-isolated in-memory key-value databases naturally provide a data fault tolerance and disaster recovery mode that can efficiently implement periodic persistent backups. This provides excellent data security support for scenarios requiring this feature, such as caching engines and stream computing state backends. Google's closed-source stream computing engine, MilWheel, uses a transactional model to achieve operator state fault tolerance. This feature allows the stream computing engine to achieve good fault tolerance, disaster recovery, and fault recovery capabilities without sacrificing excessive throughput.

[0004] The construction of predicate indexes in key-value databases has significant application implications. A predicate index is an auxiliary index that supports deep optimization of specialized queries such as regular expression matching or checksum matching. Essentially, it is implemented by pre-compiling the results of the predicate function on the data records and caching them. Using predicate indexes can significantly reduce the number of full table scans, greatly increase query processing throughput, and reduce response latency. This has a significant positive impact on business scenarios such as the state backend of stream processing systems and caching engines that frequently use specialized queries.

[0005] Currently, most mainstream database and storage applications that support full transaction support are structured relational databases, and their index types are mostly B-tree indexes and hash indexes. These types of indexes cannot be deeply optimized for specialized queries. On the other hand, key-value database products that support predicate indexes that are deeply optimized for specialized queries mostly do not have comprehensive transaction support capabilities, especially distributed transaction support capabilities. Summary of the Invention

[0006] The purpose of this invention is to address the shortcomings of existing technologies by proposing a predicate indexing method that supports batched multi-version transactions in key-value databases. This invention focuses on solving the problem of specialized query optimization in scenarios supporting batched multi-version transactions in key-value databases, and designs a predicate indexing method that supports batched multi-version transactions. This method adapts to the database's transaction control protocol, caches write set data in a transaction batch, and incrementally updates the cached index to the primary index at the batch edge, thereby supporting database transaction characteristics. This ensures that the predicate index has a high optimization capability for specialized queries while maintaining transaction characteristics.

[0007] The objective of this invention is achieved through the following technical solution:

[0008] A predicate indexing method that supports batch multi-version transactions in key-value databases, the method comprising the following steps:

[0009] During database transaction execution, a periodically increasing batch is maintained and a tag is assigned to each transaction. The transaction ID is determined based on the batch and tag. In the data storage area, a version chain is maintained with the oldest version as the primary version and the older versions pointing to the newer versions. Reachability analysis is performed on transactions, and two concurrently safe hash tables are maintained for the smallest centralized storage unit of the database: a subject-predicate index table and a write set index table.

[0010] The key type of the subject-predicate index table is a tuple of <predicate function, predicate result>, and the value type is a list of physical addresses of the data major version that satisfy this result; the key type of the write set index table is a tuple of <predicate function, predicate result>, and the value type is a list of tuples of <data version number, data version physical address>; the data version number is the transaction ID at the time of transaction commit;

[0011] When a database transaction performs a write operation, the data version with primary key K is added to the version chain. The <predicate function, predicate result> tuples corresponding to all effective predicate indexes of the new version data are calculated, and the <data version number, current version physical address> tuple is added to the corresponding position in the write set index table with this tuple as the key.

[0012] When performing a transactional read operation, the given <predicate function, predicate result> tuple will be used to look up the latest reachable version of all data in the write set index table and the subject-predicate index table, and reachability analysis will be used to determine whether a version matching the result can be read.

[0013] After batch increments, the database performs version garbage collection and index maintenance.

[0014] Furthermore, the reachability analysis is implemented using write timestamps and read timestamps, where the write timestamp is the time a transaction IDT is written upon transaction commit. commit The write timestamp (wts) is used as the commit timestamp in the version; the last read transaction ID for each version is the read timestamp.

[0015] Furthermore, the transaction requirement is to provide a reachability analysis function, which is a function that, given a version's WTS, RTS, transaction isolation level, and executing transaction ID, determines whether the version is visible to the transaction operation: f:T wts ×T rts ×L T ×T tid →{True,False}: where T is the transaction ID value range and L is the optional isolation level space.

[0016] Furthermore, the predicate function is the unit for creating and managing the predicate index, and the predicate function is declared as f:D key ×D value →D R ; where D key D value ,D R These represent the primary key of the database record, the value of the database record, and the value range of the predicate function calculation result, respectively. The predicate function accepts the key and value of a data entry and calculates a result. Read and write operations based on the predicate function use the given predicate calculation result to find the physical address of the data entry from which the calculation result can be obtained.

[0017] Furthermore, the smallest centralized processing unit is the logical centralized storage unit of the database. For a non-partitioned database, the smallest centralized processing unit is a database unit, and for a partitioned database, the smallest centralized processing unit is a database partition.

[0018] Furthermore, the latest reachable version is the latest version of the data record in which it is located at the time of version check, or a version that is reachable to the current transaction at the time of this check and whose next version is not reachable to the current transaction; the latest reachable version is unique for a data entry, and when a transaction selects to read the version and update the predicate index, it will always look for the latest reachable version.

[0019] Furthermore, if a transaction is aborted, simply record the aborted transaction ID and remove the aborted data version in the next step of the main index update.

[0020] Furthermore, the specific steps for version garbage collection and index maintenance in the database are as follows:

[0021] Traverse the write set index table to find the latest available version of each data entry with primary key K in the current batch. Then, find the primary version through the version chain and calculate the list of all <predicate function, predicate result> pairs for the primary version and the new version data. Finally, copy the selected version to the primary version. During garbage collection, delete the original records in the primary predicate index table of the primary version and insert the new primary version index table entries. After completing the above steps, clear the write set index table and proceed with the next batch of transaction processing.

[0022] Furthermore, in the database's version garbage collection and index maintenance, the batch value is managed by a separate management thread and is periodically incremented. At the edge of the batch increment, the transaction set performs centralized version data garbage collection and distributed system synchronization operations such as overall batch two-phase commit and transaction resolution.

[0023] According to another aspect of the specification, a predicate indexing device supporting batched multi-version transactions in a key-value database is provided, including a memory and one or more processors. The memory stores executable code, and when the processor executes the executable code, it implements a predicate indexing method supporting batched multi-version transactions in a key-value database.

[0024] The beneficial effects of this invention are:

[0025] (1) This invention constructs an incremental-merge write mode and integrates transaction version information into the predicate index implementation, thereby enabling the predicate index to adapt to key-value databases that support multi-version concurrent transactions. This invention enables the database system to support distributed transactions, supports deep customized query optimization while maintaining ACID properties, and improves the performance of specialized queries while ensuring the relative high availability and fault tolerance of the distributed database system.

[0026] (2) The present invention can cache the predicate index update introduced by the transaction version update by writing cache in batches, thereby reducing the update frequency of the subject-predicate index table, greatly improving the throughput of reading and writing operations using the predicate index, reducing response latency, and reducing the additional overhead brought by the index. Attached Figure Description

[0027] Figure 1 This is a schematic diagram of the data in the database and the contents of the initial subject-predicate index table in the initial state.

[0028] Figure 2 This is a schematic diagram of the time-series swimlanes for the transactions executed within the analyzed epoch=2 phase.

[0029] Figure 3 This is a diagram showing the contents of the database, predicate index table, and write set index table after epoch=2 has been completed.

[0030] Figure 4 This diagram illustrates the database data and predicate index table content after the management thread completes version cleanup and index merging following the epoch increment.

[0031] Figure 5 This is a structural diagram of a predicate indexing device that supports batch multi-version transactions in a key-value database, provided in an embodiment of the present invention. Detailed Implementation

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

[0033] The present invention will now be described in further detail with reference to the accompanying drawings and specific embodiments.

[0034] A predicate indexing method that supports batch multi-version transactions in key-value databases, the method comprising the following steps:

[0035] S1. When the database transaction described in this patent is executed, a periodically increasing batch epoch is maintained. When a transaction arrives, a tag value is assigned to it, and the ID of the transaction is obtained by concatenating the epoch and the tag. When the transaction is committed, a transaction ID t is written. commit The write timestamp (wts) for each committed version is used in the version list, while the last transaction ID read in each version is maintained as the read timestamp (rts). Version reachability analysis is performed using these two timestamps. At the version chain management level, a version chain is maintained with the oldest version as the primary version and older versions pointing to newer versions.

[0036] S2. Maintain two concurrently safe hash tables for the smallest centralized storage unit of the database: a subject-predicate index table and a write set index table. The key type of the subject-predicate index table is a tuple of <predicate function F, predicate result R>, and the value type is a list of physical addresses of the data master version that satisfy this result. The key type of the write set index table is also a tuple of <predicate function F, predicate result R>, but the value type is a list of tuples of <data version number wts, data version physical address>.

[0037] S3. Transaction write operations take effect during the transaction commit phase, when the transaction... commit After adding the data version with primary key K to the version chain for WTS, the indexes of all effective predicates corresponding to this version of data should be calculated.<F,R> Binaries, and add new ones using them as keys. <T commit The current version's physical address > the corresponding position in the write set index table of the tuple: Transactional read operations using predicate indexes will use the given...<F,R> The binary search uses the write set index table and subject-predicate index table to find the latest reachable version of all data, and uses the reachability analysis of version WTS to determine whether the matching version can be read; if the transaction is aborted, simply record the aborted transaction ID and remove the aborted data version in the next step of the main index update.

[0038] S4. After each epoch increments, the database will perform version garbage collection and index maintenance. Specifically, it will traverse the write set index table, find the latest version of each data entry with primary key K in the current epoch, find the major version through the version chain, and calculate all the major version and new version data.<F,R> The list of binary tuples is used to copy the selected version to the primary version. If necessary, existing records in the primary version's subject-predicate index table are deleted, and new primary version index table entries are inserted. After completing these steps, the write set index table is cleared, and transaction processing for the next epoch can begin.

[0039] Furthermore:

[0040] The S1 step is not fixed to a specific transaction implementation method. This method is compatible with transaction mechanisms implemented using two-phase locking, sequential locking, and optimistic concurrency control, as long as the transaction implementation method can provide its reachability analysis function. The reachability analysis function is a function that, given a version's WTS, RTS, transaction isolation level, and executing transaction ID, determines whether the version is visible to the transaction operation: f:T wts ×T rts ×L T ×T tid →{True,False}: where T is the transaction ID space and L is the optional isolation level space;

[0041] The S1 step does not fix the transaction implementation method. The method provided in this patent is compatible with mainstream transaction mechanisms such as two-phase locking, sequential locking, and optimistic concurrency control, as long as the transaction mechanism can provide its reachability analysis function. The reachability analysis function is a function that determines whether a given version is visible to the transaction operation, given its WTS, RTS, transaction isolation level, and executing transaction ID: f:T wts ×T rts ×L T ×T tid →{True,False}: where T is the transaction ID value range and L is the optional isolation level space;

[0042] The predicate function in step S2 is the unit for creating the predicate index. The predicate function can be declared as f:D key ×D value →D R ; where D key D value ,D R These represent the primary key of the database record, the value of the database record, and the value range of the predicate function calculation result, respectively. The predicate function accepts the key and value of a data entry and calculates a result. Read and write operations based on the predicate function use the given predicate calculation result to find the physical address of the data entry from which this result can be calculated.

[0043] The smallest centralized processing unit in step S2 is the logical centralized storage unit of the database. For a non-partitioned database, it is a database unit; for a partitioned database, it is a database partition.

[0044] In steps S3 and S4, "latest reachable version" refers to a version that satisfies one of the following two conditions: 1) it is the latest version of the data record in which it is located at the time of version check, or 2) it is reachable to the current transaction at the time of this check, and its next version is not reachable to the current transaction. "Latest reachable version" is unique for a data entry, and when a transaction selects to read the version and update the predicate index, it will always look for the latest reachable version.

[0045] In step S4, the epoch value is managed by a separate management thread and is periodically incremented. At the edge of the epoch increment, the transaction set performs centralized version data garbage collection and batch-wide two-phase commit, transaction resolution, and other distributed system synchronization operations.

[0046] Specifically, in this implementation:

[0047] A single-machine, non-partitioned key-value database is used as a simplified demonstration object; a multi-version optimistic control protocol is used as the transaction concurrency control protocol; repeatable read (i.e., reading new values ​​generated after the start of a transaction is not allowed) is used as the transaction isolation level; and two predicate functions, F1 and F2, are used as examples to build a predicate index.

[0048] The main contents of the transaction concurrency control protocol are: 1) When a transaction arrives, T is obtained. id Used to determine reachability, during the transaction execution phase, it checks whether the version is locked by a write lock and T. id Whether a version is reachable depends on whether it is within [wts,rts], and read operations are not locked; 2) During the verification phase, the read set is verified at the read committed isolation level or above to see if it has been modified. After passing the verification, a new T is obtained. commit Lock the key sequence for write sets, and initialize the [wts,rts] of new data versions of all write sets to [T]. commit [,INF], set the RTS of all read sets to min(rts,T) commit ).

[0049] The predicate function F1 represents "the prefix substring of the key-value pair's value before the character '-'", and returns a string; the predicate function F2 represents "whether the length of the key-value pair's value as a string is greater than 10", and returns a boolean value.

[0050] To simplify the representation, the transaction timestamp is set as a three-digit decimal number, where the third digit is the epoch value and the lower two digits are the transaction tag. In this example, the database has just finished the epoch=1 phase and entered the epoch=2 phase.

[0051] Table 1 shows the key-value pair table stored in the database in its initial state.

[0052]

[0053] As shown in Table 1, after the previous epoch, the database contained 5 records. At this point, the database had already built predicate indexes for the two existing predicate functions, and the results of the indexing are as follows: Figure 1 As shown. The values ​​marked with *() are the physical addresses of the data versions.

[0054] After entering epoch=2, a total of 5 transactions were initiated. These transactions executed a series of read and write operations as shown in Table 2, according to the actual time sequence. The timeline swimlane diagram, including the transaction initiation, commit, and termination processes, is shown below. Figure 2 As shown. After completing this series of operations, the database version storage and the data status of the write set index table are as follows. Figure 3 As shown. Analysis of transaction read / write actions:

[0055] Transaction ID 201 (hereinafter referred to as Transaction 201, and so on) performs read, modify, and write operations on the data with primary keys k3 and k2 respectively, and is eventually committed. After commit, the RTS of the two versions read on the version chain will be set to their T. coimmit (i.e., 202) represents the time when the transaction writes the update to the version chain. Since there are two predicate functions, each write operation adds two entries to the write set index table. The first write operation adds <202,6> to the two corresponding entries.<F,R> The key, the second write operation added <202,7> to the two corresponding keys.<F,R> key;

[0056] Transaction 204 performs read, modify, and write operations on the data with primary key k2 and is eventually committed. Similarly, when transaction 204 commits, it uses the timeline T. commit =205 updates the read version's RTS, installs its own write version into the version chain, and adds <205,9> to the two corresponding versions.<F,R> key;

[0057] Transaction 203 performed three predicate index operations:

[0058] First predicate index read, according to<F1,prefix2> This key searches the subject-predicate index table and the write set index table respectively. It can be seen that four versions' addresses can be found at this node: versions with addresses 3 and 4 can be found in the subject-predicate index table, and versions with addresses 6 and 9 can be found in the write set index table (at this point, transaction 204 has committed, so version 9 can be found in the write set index table). The version read from the write set index table should continue searching downstream until the latest reachable version is found. At this point, transaction 203 is not within the [wts,rts] range of version 9, while 6 meets the requirements; therefore, version 6 is the latest reachable version. Version 3 is no longer reachable, and subsequent reachable versions do not meet the requirements.<F1,prefix2> The condition is that the first predicate index read will retrieve two data entries, located at addresses 4 and 9 respectively.

[0059] The second predicate index read-modify-write operation, through<F1,prefix3> Searching the two tables yields two records with addresses 5 and 7 respectively. Using a verification method similar to the one described above, both are the latest available versions. Therefore, a new version is created based on these versions, and finally, the new version is added to the write set index table upon commit.

[0060] The third predicate index read operation, through<F2,false> A search of the two tables yields two records with addresses 5 and 9 respectively. The version at address 9 is unreachable for transaction 203, while the version at address 5 has been overwritten by its previous write and is therefore not the latest reachable version. Consequently, this predicate index read cannot find matching data.

[0061] Transaction 204 with T commit =206 commits. After committing, it will update the RTS for the corresponding read version, the written version will be installed, and the write set index table will also be updated.

[0062] Table 2: Overview of Read and Write Operations for Each Transaction

[0063]

[0064] After epoch=2, the management thread will increment the epoch and initiate garbage collection to clean up historical versions left in the database and cached data in the write set index table from the previous epoch. In this step, the management thread will iterate through the write set index table, copying the latest version to the primary version. Afterward, it will delete overwritten version entries in the subject-predicate index table and add new entries copied to the primary version. The result after processing is as follows: Figure 4 As shown. At this point, transaction processing for the next epoch can officially begin. It should be noted that the final RTS value for the data with primary key k4 is 206 (because it was read by a predicate index read operation in transaction 203). When a transaction in the next epoch reads it, it will find that its TID is definitely not within the [wts,rts] range of this version. However, since this RTS does not belong to the next epoch, this indicates that the transaction reading this version has already committed and will not need to be rolled back due to writes by transactions in the next epoch. Therefore, it can also be treated as INF and processed normally.

[0065] Corresponding to the aforementioned embodiment of a predicate indexing method supporting batched multi-version transactions in key-value databases, the present invention also provides an embodiment of a predicate indexing method apparatus supporting batched multi-version transactions in key-value databases.

[0066] See Figure 5 The present invention provides a predicate indexing device that supports batch multi-version transactions in key-value databases, comprising a memory and one or more processors. The memory stores executable code, and when the processor executes the executable code, it is used to implement a predicate indexing method for supporting batch multi-version transactions in key-value databases as described in the above embodiments.

[0067] The predicate indexing device supporting batch multi-version transactions in key-value databases provided by this invention can be applied to any device with data processing capabilities, such as a computer. The device embodiment can be implemented in software, hardware, or a combination of both. Taking software implementation as an example, as a logical device, it is formed by the processor of any data processing device loading the corresponding computer program instructions from non-volatile memory into memory for execution. From a hardware perspective, such as... Figure 5 The diagram shown illustrates a hardware structure of any data processing-capable device, including a predicate indexing device supporting batch multi-version transactions in key-value databases provided by this invention. (Except for...) Figure 5 In addition to the processor, memory, network interface, and non-volatile memory shown, any data processing device in the embodiment may also include other hardware depending on the actual function of the data processing device, which will not be described in detail here.

[0068] The specific implementation process of the functions and roles of each unit in the above device can be found in the implementation process of the corresponding steps in the above method, and will not be repeated here.

[0069] For the device embodiments, since they basically correspond to the method embodiments, the relevant parts can be referred to in the description of the method embodiments. The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of the present invention according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0070] This invention also provides a computer-readable storage medium storing a program that, when executed by a processor, implements a predicate indexing method supporting batch multi-version transactions in a key-value database as described in the above embodiments.

[0071] The computer-readable storage medium can be an internal storage unit of any data processing device as described in any of the foregoing embodiments, such as a hard disk or memory. The computer-readable storage medium can also be an external storage device of any data processing device, such as a plug-in hard disk, smart media card (SMC), SD card, flash card, etc., equipped on the device. Furthermore, the computer-readable storage medium can include both internal storage units and external storage devices of any data processing device. The computer-readable storage medium is used to store the computer program and other programs and data required by the data processing device, and can also be used to temporarily store data that has been output or will be output.

[0072] The above embodiments are used to explain and illustrate the present invention, but not to limit the present invention. Any modifications and changes made to the present invention within the spirit and scope of the claims shall fall within the protection scope of the present invention.

Claims

1. A predicate indexing method supporting batched multi-version transactions in key-value databases, characterized in that, The method includes the following steps: During database transaction execution, a periodically increasing batch is maintained and a tag is assigned to each transaction. The transaction ID is determined based on the batch and tag. In the data storage area, a version chain is maintained with the oldest version as the primary version and the older versions pointing to the newer versions. Reachability analysis is performed on transactions, and two concurrently safe hash tables are maintained for the smallest centralized storage unit of the database: a subject-predicate index table and a write set index table. The key type of the subject-predicate index table is a tuple of <predicate function, predicate result>, and the value type is a list of physical addresses of the data major version that satisfy this result; the key type of the write set index table is a tuple of <predicate function, predicate result>, and the value type is a list of tuples of <data version number, data version physical address>; the data version number is the transaction ID at the time of transaction commit; When performing a write operation in a database transaction, the data version with primary key 𝐾 is added to the version chain. The <predicate function, predicate result> tuple corresponding to all effective predicate indexes of the new version data is calculated, and the <predicate function, predicate result> tuple is added as the key to the corresponding position of the write set index table as <data version number, current version physical address> tuple. When performing a transactional read operation, the given < , The binary search uses the write set index table and subject-predicate index table to find the latest reachable version of all data, and uses reachability analysis to determine whether the matching version of the result can be read. After batch increments, the database performs version garbage collection and index maintenance.

2. The predicate indexing method supporting batch multi-version transactions in key-value databases according to claim 1, characterized in that, The reachability analysis is implemented using write timestamps and read timestamps, where the write timestamp is a transaction ID written when the transaction is committed. Add it to the commit timestamp in the version. The last transaction ID read in each version is the read timestamp.

3. The predicate indexing method supporting batched multi-version transactions in key-value databases according to claim 1, characterized in that, The transaction requirement is the ability to provide a reachability analysis function, which is applicable to a given version. , The transaction isolation level and the executing transaction ID determine whether this version is visible to the transaction operation. Where T is the transaction ID value range and L is the optional isolation level space.

4. The predicate indexing method supporting batch multi-version transactions in key-value databases according to claim 1, characterized in that, The predicate function is the unit for creating and managing the predicate index, and the predicate function is declared as follows: ;in These represent the value ranges of the database record primary key, the database record value, and the predicate function calculation result, respectively. A predicate function takes a key and a value from a data entry and calculates a result. Read and write operations based on predicate functions use the given predicate calculation result to find the physical address of the data entry from which the calculation result can be obtained.

5. A predicate indexing method supporting batched multi-version transactions in key-value databases according to claim 1, characterized in that, The smallest centralized storage unit is the logical centralized storage unit of the database. For a non-partitioned database, the smallest centralized storage unit is a database unit, and for a partitioned database, the smallest centralized storage unit is a database partition.

6. The predicate indexing method supporting batch multi-version transactions in key-value databases according to claim 1, characterized in that, The latest reachable version is the latest version of the data record in which it is located at the time of version check, or a version that is reachable for the current transaction at the time of this check and whose next version is not reachable for the current transaction. The latest reachable version is unique for a data entry, and the latest reachable version will always be searched when the transaction selects the read version and updates the predicate index.

7. A predicate indexing method supporting batch multi-version transactions in key-value databases according to claim 1, characterized in that, If a transaction is aborted, simply record the aborted transaction ID and remove the aborted data version in the next step of the main index update.

8. A predicate indexing method supporting batched multi-version transactions in key-value databases according to claim 6, characterized in that, The specific steps for version garbage collection and index maintenance in the database are as follows: Traverse the write set index table to find each data primary key. The data entry is the latest available version in the current batch, and the main version is found through the version chain. The list of all <predicate function, predicate result> pairs of the main version and the new version data is calculated. Finally, the selected version is copied to the main version, and during garbage collection, the original records in the main version in the subject-predicate index table are deleted and the new main version index table entries are inserted. After completing the above steps, clear the write set index table and proceed with the next batch of transaction processing.

9. A predicate indexing method supporting batch multi-version transactions in key-value databases according to claim 1, characterized in that, In the database's version garbage collection and index maintenance, batch values ​​are managed by a separate management thread and are periodically incremented. The transaction set performs centralized version data garbage collection and distributed system synchronization operations at the edge of batch increment.

10. A predicate indexing device supporting batch multi-version transactions in key-value databases, characterized in that, The system includes a memory and one or more processors, wherein the memory stores executable code, and the processor, when executing the executable code, implements a predicate indexing method for supporting batch multi-version transactions in a key-value database as described in any one of claims 1-9.

Images