Database tuple searching method and device, computer device and storage medium

Abstract

This invention relates to the field of data querying and discloses a method, apparatus, computer device, and storage medium for searching database tuples to solve the problem of being unable to find database tuples based on the allocation time of a transaction identifier. The method includes: executing a pending transaction to obtain a first tuple corresponding to the pending transaction; writing the transaction identifier corresponding to the pending transaction into the first tuple to obtain a second tuple; initializing a transaction page directory corresponding to the pending transaction; adding a data page corresponding to the transaction identifier to the transaction page directory and storing the transaction identifier in the data page; obtaining the time when the second tuple was written with the transaction identifier to obtain the allocation time; adding a time slot containing the allocation time to the end of the data page to obtain a target page directory; when receiving an instruction to find a tuple corresponding to an expected time, traversing the time slots in the target page directory, filtering out target allocation times that match the expected time in the time slots to obtain the target transaction identifier corresponding to the target allocation time; and filtering out the transaction identifier corresponding to the target transaction identifier from the second tuple to obtain the target tuple.

Description

Technical Field

[0001] This invention relates to the field of data querying, and in particular to a method, apparatus, computer device, and storage medium for searching database tuples. Background Technology

[0002] In most applications, different databases are used for data storage. Many database implementations employ MVCC (Multi-Version Concurrency Control). Therefore, when developers execute SQL (Structured Query Language) statements in the database that are actually DML (Data Manipulation Language) operations, a basic unit of concurrency control exists: the transaction. A transaction is a sequence of operations where all SQL statements are either executed or none are executed; it is an indivisible unit of work. Each SQL statement execution affects one or more tuples in the database. During transaction execution, the database automatically assigns a transaction identifier (XID) to each transaction. This transaction identifier is stored in the header of each tuple, and the database kernel uses the XID to determine the visibility of the tuple. The XID is automatically assigned by the database based on the time the developer submits and executes the SQL statement, incrementing sequentially, and is used for subsequent tuple addressing.

[0003] When a database executes SQL statements, it involves two steps: first, entering the SQL statements required for the transaction; and second, committing and executing the transaction, i.e., committing the previously entered SQL statements. During transaction execution, each tuple affected by the SQL statement is assigned a corresponding XID. Because there is a time difference between the commit operation and XID assignment, and each XID only identifies the time the transaction was committed, not the time the tuple was assigned its XID, developers can only find the corresponding tuple based on the XID value, the order in which the tuples were generated, or the transaction commit time when performing operations such as querying, comparing, rolling back, or freezing tuples. They cannot find the tuple based on the XID's assignment time, leading to excessively high complexity in subsequent tuple operations and low development efficiency. Summary of the Invention

[0004] This invention provides a method, apparatus, computer device, and storage medium for searching database tuples, in order to solve the problem that database tuples cannot be found based on the allocation time of transaction identifiers.

[0005] A method for searching database tuples includes:

[0006] Upon receiving the commit instruction for the pending transaction, the pending transaction is executed to obtain the first tuple corresponding to the pending transaction;

[0007] Write the transaction identifier corresponding to the transaction to be processed into the first tuple to obtain the second tuple;

[0008] Initialize the transaction page directory corresponding to the transaction to be processed;

[0009] In the transaction page directory, add the data page corresponding to the transaction identifier, and save the transaction identifier in the data page;

[0010] Obtain the time when the second tuple is written to the transaction identifier to get the allocation time;

[0011] At the end of the data page, a time slot containing the allocated time is added to obtain the target page directory;

[0012] When an instruction is received to find the tuple corresponding to the expected time, the time slots in the target page directory are traversed, and the target allocation time that matches the expected time is selected from the time slots to obtain the target transaction identifier corresponding to the target allocation time.

[0013] In the second tuple, the transaction identifier corresponding to the target transaction identifier is selected to obtain the target tuple.

[0014] In one possible design, after obtaining the first tuple corresponding to the transaction to be processed, the method further includes:

[0015] Determine whether the first tuple needs to be written with the transaction identifier;

[0016] If the transaction identifier needs to be written, determine whether the transaction page directory already exists;

[0017] If it exists, the transaction identifier corresponding to the transaction to be processed is directly written into the first tuple.

[0018] In one possible design, initializing the transaction page directory corresponding to the transaction to be processed includes:

[0019] Initialize the buffer pool corresponding to the transaction page directory;

[0020] Allocate corresponding shared memory to the buffer pool;

[0021] Activate the buffer pool in the shared memory to initialize the transaction page directory.

[0022] In one possible design, after activating the buffer pool in the shared memory, the method further includes:

[0023] Obtain the transaction identifier corresponding to the transaction to be processed from the shared memory.

[0024] In one possible design, adding the data page corresponding to the transaction identifier to the transaction page directory and storing the transaction identifier in the data page includes:

[0025] Determine whether the transaction identifier corresponds to the data page;

[0026] If it exists, the data page is located, and the transaction identifier is saved into the data page;

[0027] If it does not exist, the data page is allocated from the buffer pool of the transaction page directory and the data page is initialized;

[0028] Add the pending transaction to the data page.

[0029] In one possible design, after adding a time slot containing the allocation time to the end of the data page to obtain the target page directory, the method further includes:

[0030] Determine whether there are dirty data pages in the transaction page directory;

[0031] If it exists, the dirty data page is written to disk.

[0032] In one possible design, the transaction identifier consists of a 32-bit integer, where the first 16 bits are used to record the name of the transaction page directory, the middle bits are used to record the number of the data page, and the last 16 bits are the time slot.

[0033] A database tuple lookup device, comprising:

[0034] An execution module is used to execute the pending transaction after receiving a commit instruction for the pending transaction, and obtain the first tuple corresponding to the pending transaction;

[0035] The writing module is used to write the transaction identifier corresponding to the transaction to be processed into the first tuple to obtain the second tuple;

[0036] An initialization module is used to initialize the transaction page directory corresponding to the transaction to be processed;

[0037] The storage module is used to add the data page corresponding to the transaction identifier to the transaction page directory and store the transaction identifier in the data page;

[0038] The acquisition module is used to obtain the time when the second tuple is written to the transaction identifier, and thus obtain the allocation time;

[0039] An add module is used to add a time slot containing the allocated time to the end of the data page to obtain the target page directory;

[0040] The first filtering module is used to, when receiving an instruction to find the tuple corresponding to the expected time, traverse the time slots in the target page directory, filter out the target allocation time in the time slot that is consistent with the expected time, and obtain the target transaction identifier corresponding to the target allocation time;

[0041] The second filtering module is used to filter out the transaction identifier corresponding to the target transaction identifier from the second tuple to obtain the target tuple.

[0042] A computer device includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the above-described database tuple lookup method.

[0043] A computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the above-described database tuple lookup method.

[0044] The aforementioned database tuple lookup method, apparatus, computer device, and storage medium, upon receiving a commit instruction for a pending transaction, first execute the pending transaction to obtain a first tuple corresponding to the pending transaction. Then, write the transaction identifier corresponding to the pending transaction into the first tuple to obtain a second tuple. Next, initialize the transaction page directory corresponding to the pending transaction. Add the data page corresponding to the transaction identifier to the transaction page directory and record the tuple in the data page. Then, obtain the time when the second tuple was written to the transaction identifier to obtain the allocation time. Then, add a time slot containing the allocation time to the end of the data page to obtain a target page directory. Finally, when receiving an instruction to find the tuple corresponding to the expected time, traverse the time slots in the target page directory, filter out the target allocation time that matches the expected time, and obtain the target transaction identifier corresponding to the target allocation time. Then, filter out the transaction identifier corresponding to the target transaction identifier in the second tuple to obtain the target tuple. This method records the transaction identifier (XID) separately in the newly added data page of the database and forms a target page directory containing the allocation time. This directory is specifically used to record the allocation time of the transaction identifier. This allows the target page directory to be directly traversed when searching for tuples based on the expected time, so as to obtain the target transaction identifier. Then, the corresponding second tuple, which is the target tuple, can be found through the target transaction identifier. This enriches the method of searching for tuples, speeds up the search for the corresponding tuple based on the expected time, simplifies the complexity of searching for tuples based on the expected time, and speeds up development efficiency. Attached Figure Description

[0045] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the description of the embodiments of the present invention will be briefly introduced below. Obviously, the 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.

[0046] Figure 1 This is a schematic diagram of an application environment for a database tuple lookup method according to an embodiment of the present invention;

[0047] Figure 2 This is a flowchart illustrating a database tuple lookup method according to an embodiment of the present invention;

[0048] Figure 3 This is a flowchart illustrating a database tuple lookup method according to an embodiment of the present invention;

[0049] Figure 4 This is a flowchart illustrating a database tuple lookup method according to an embodiment of the present invention;

[0050] Figure 5This is a flowchart illustrating a database tuple lookup method according to an embodiment of the present invention;

[0051] Figure 6 This is a flowchart illustrating a database tuple lookup method according to an embodiment of the present invention;

[0052] Figure 7 This is a schematic diagram of a database tuple lookup device according to an embodiment of the present invention;

[0053] Figure 8 This is a schematic diagram of a computer device according to an embodiment of the present invention. Detailed Implementation

[0054] 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, not all, of the embodiments of the present invention. Based on the 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.

[0055] The database tuple lookup method provided in this embodiment of the invention can be applied to, for example... Figure 1 In this application environment, terminal devices communicate with the server via a network, sending commit instructions for pending transactions and instructions to locate target transactions based on target events to the server's database. These terminal devices can be, but are not limited to, various personal computers, laptops, smartphones, tablets, and portable wearable devices. The server can be a standalone server or a server cluster consisting of multiple servers.

[0056] In one embodiment, in applications related to smart hospital medical processes, emergency procedures, drug management, and medical guidance, medical administrators often need to issue documents from the management backend. Issuing a document is essentially sending a data operation instruction to the server. However, due to human error, document issuance errors occasionally occur, such as sending medication to the wrong department or errors in editing the drug ingredients before issuance, requiring retraction. In such cases, it is necessary to find the data operation instruction that was issued the medication and retract it. This requires a database tuple lookup method to identify the database tuples affected by the medication issuance, perform rollback and redo operations on these tuples, and thus retract the issued medication. Therefore, this invention provides a database tuple lookup method, such as... Figure 2 As shown, this method is applied to Figure 1 Taking the server in the example, the following steps are included:

[0057] S10: After receiving the commit instruction for the pending transaction, execute the pending transaction to obtain the first tuple corresponding to the pending transaction.

[0058] Developers combine multiple DML operations on a terminal device to construct a transaction to be processed, and then submit the transaction to the server. Upon receiving the commit instruction for the transaction, the server executes it, which means executing the SQL statements within the transaction, i.e., performing the DML operations. Since executing DML operations will affect one or more tuples in the database, after execution, all affected tuples after the transaction are obtained, forming the first tuple. The transaction consists of multiple different SQL statements sequentially, the commit instruction refers to the commit operation instruction of the transaction, and a tuple is a data structure in a database. A tuple refers to the underlying data record generated by the database when executing DML operations, typically composed of multiple fields or attributes. Tuples are one of the most basic data structures in a database and the smallest unit in a database management system. In this embodiment, the database can be one or more databases already existing in the art, including but not limited to DB2, Microsoft Access, Microsoft SQL Server, Oracle, and MySQL. This embodiment preferably uses a PostgreSQL database, where a tuple refers to a row of data in a relation. Each tuple contains the values ​​of all attributes in the relation; that is, each tuple represents a complete data record in the relation. For example, in a PostgreSQL student relation table, each tuple represents a student record, and the tuple will consist of attributes such as name, student ID, gender, and age.

[0059] S20: Write the transaction identifier corresponding to the transaction to be processed into the first tuple to obtain the second tuple.

[0060] After obtaining the first tuple, the transaction identifier corresponding to the transaction to be processed is written into it, resulting in a second tuple consisting of the transaction identifier and the first tuple. The transaction identifier refers to the transaction number (XID) within the database. For example, in a PostgreSQL database, each transaction is assigned an XID, and the header of each tuple stores this XID for writes or deletions. During the execution of each transaction, the headers of all affected tuples will be written with the XID, which is the second tuple.

[0061] S30: Initialize the transaction page directory corresponding to the transaction to be processed.

[0062] Initialize the transaction page directory corresponding to the transactions to be processed. Here, the transaction page directory refers to the Page Directory, which is the database's storage space, i.e., the data page structure. For example, in this embodiment, in a PostgreSQL database, the pg_assign_ts page directory, which is the transaction page directory, is initialized.

[0063] S40: In the transaction page directory, add the data page corresponding to the transaction identifier, and save the transaction identifier in the data page.

[0064] After initializing the transaction page directory, the data page corresponding to the transaction identifier is added to the directory. This data page is called a Page, which is a fixed-size data block and is the basic unit of interaction between disk and memory. A data page occupies 8192 bytes of space. A Page can store any data, including but not limited to tuples, metadata, indexes, log records, etc.

[0065] After adding a data page, the transaction identifier corresponding to the transaction to be processed is stored in that data page.

[0066] S50: Obtain the time when the second tuple was written to the transaction identifier to get the allocation time.

[0067] After saving the transaction identifier into the data page, the allocation time of the transaction identifier corresponding to the pending transaction is obtained, which is the server's system time when the second tuple was written to the transaction identifier. Once the transaction identifier is written to the second tuple, it can be used for subsequent addressing of the second tuple. The allocation time can be represented by a timestamp or a specific numerical format; no restriction is placed here.

[0068] S60: At the end of the data page, add a time slot containing the allocated time to obtain the target page directory.

[0069] After obtaining the allocation time, a time slot is added to the end of the data page. This time slot records the allocation time obtained in step S50. Finally, a target page directory containing the allocation time is obtained. Compared to the initial transaction page directory, all data pages in the target page directory have an additional time slot containing the allocation time. Here, the time slot refers to slots, i.e., a slot array, which is the offset of the data page. In the database, this offset can be used to find the transaction identifier stored in the corresponding data page.

[0070] S70: When an instruction is received to find the tuple corresponding to the expected time, the time slots in the target page directory are traversed, and the target allocation time that matches the expected time in the time slot is selected to obtain the target transaction identifier corresponding to the target allocation time.

[0071] When developers need to operate on tuples, they can send a tuple lookup command to the server via a terminal device. This command can specify the desired allocation time (expected time) for the tuples to be found. When the database on the server receives the tuple lookup command containing the expected time, the server iterates through the time slots in the target page directory, filtering the allocation times within each slot to obtain all target allocation times that match the expected time. Finally, based on the target allocation time and the data page offset, the target transaction identifier corresponding to the target allocation time is obtained.

[0072] S80: In the second tuple, filter out the transaction identifier corresponding to the target transaction identifier to obtain the target tuple.

[0073] After obtaining the target transaction identifier, the transaction identifiers in the second tuple are filtered out based on the target transaction identifier, so as to filter out the second tuple corresponding to the target transaction identifier, which is the target tuple.

[0074] It should be noted that in steps S10-S80, the transaction identifier (XID) is recorded separately in the newly added data page of the database, and a target page directory containing the allocation time is formed. This directory is specifically used to record the allocation time of the transaction identifier. This allows the target page directory to be directly traversed to obtain the target transaction identifier when searching for tuples based on the expected time. Then, the corresponding second tuple, i.e., the target tuple, can be found through the target transaction identifier. This enriches the method of searching for tuples, speeds up the search for the corresponding tuple based on the expected time, simplifies the complexity of searching for tuples based on the expected time, and speeds up development efficiency.

[0075] In one embodiment, such as Figure 3 As shown, after step S10, that is, after obtaining the first tuple corresponding to the transaction to be processed, the method for finding the database tuple further includes the following steps:

[0076] S11: Determine whether the first tuple needs to be written with the transaction identifier.

[0077] S12: If it is necessary to write the transaction identifier, determine whether the transaction page directory already exists.

[0078] S13: If it exists, then directly write the transaction identifier corresponding to the transaction to be processed into the first tuple.

[0079] After the SQL statements in a pending transaction are executed in the database, the first tuple associated with the SQL statement is generated. Then, based on the type of the SQL statement, it is determined whether a transaction identifier needs to be written to the first tuple. Generally, DML operations, that is, SQL statements centered around the insert, update, and delete commands, require writing a transaction identifier to the first tuple. Query-related SQL statements, however, do not require writing a transaction identifier.

[0080] Therefore, in step S11, it is necessary to determine whether the transaction identifier needs to be written into the first tuple based on the SQL statement in the transaction to be processed. If so, it is determined whether a transaction page directory already exists. If it exists, step S30 is skipped, and the transaction identifier corresponding to the transaction to be processed is directly written into the first tuple.

[0081] It should be noted that checking whether a transaction page directory already exists is to prevent duplicate initialization from causing data anomalies, and also to prevent the performance consumption caused by repeated operations.

[0082] In one embodiment, such as Figure 4 As shown, step S30, which initializes the transaction page directory corresponding to the transaction to be processed, specifically includes the following steps:

[0083] S31: Initialize the buffer pool corresponding to the transaction page directory.

[0084] S32: Allocate corresponding shared memory for the buffer pool.

[0085] S33: Activate the buffer pool in the shared memory to initialize the transaction page directory.

[0086] In step S31, the buffer pool corresponding to the transaction page directory is initialized. For example, in this embodiment, an SLRU (Segmented LRU, where LRU is a cache eviction algorithm, short for Least Recently Used) buffer pool control center is initialized in memory to control the persistent storage of data pages on physical storage.

[0087] In steps S32-S33, shared memory is allocated to the buffer pool, which can be accessed by multiple databases. Next, the buffer pool in the shared memory is activated to complete the initialization of the transaction page directory.

[0088] It should be noted that using shared memory to initialize the transaction page directory allows different databases to access the data pages and transaction page directory in the buffer pool, improving the utilization of data pages and transaction page directories, reducing memory pressure, and improving database performance.

[0089] In one embodiment, after step S33, i.e. after activating the buffer pool in the shared memory, the database tuple lookup method further includes the following steps:

[0090] S21: Obtain the transaction identifier corresponding to the transaction to be processed from the shared memory.

[0091] After activating the SLRU buffer pool, a transaction identifier is allocated from shared memory for the transaction to be processed. In other words, the transaction identifier of the transaction to be processed is obtained from shared memory.

[0092] It should be noted that obtaining the transaction identifier from shared memory facilitates accessing and sharing the transaction identifier across different databases, thereby improving memory utilization.

[0093] In one embodiment, after step S20, i.e., after writing the transaction identifier corresponding to the transaction to be processed into the first tuple and obtaining the second tuple, a log (xlog) record for allocating the transaction identifier can be inserted into the second tuple so that the transaction to be processed can be found later, which is convenient for subsequent redo operations on the transaction to be processed.

[0094] In one embodiment, such as Figure 5 As shown, step S40, which involves adding the data page corresponding to the transaction identifier to the transaction page directory and storing the transaction identifier in the data page, specifically includes the following steps:

[0095] S41: Determine whether the transaction identifier corresponds to the data page.

[0096] S42: If it exists, locate the data page and save the transaction identifier into the data page.

[0097] S43: If it does not exist, allocate the data page from the buffer pool of the transaction page directory and initialize the data page.

[0098] S44: Add the pending transaction to the data page.

[0099] In step S41, it is determined whether a data page associated with the transaction identifier exists in the transaction page directory. Next, in steps S42-S44, the determination result is processed: if it exists, the corresponding data page is located, and the transaction identifier is stored in the data page; if it does not exist, a data page is allocated from the SLUR, that is, from the buffer pool of the transaction page directory, to store the allocation time, and the allocated data page is initialized to clear the data stored in the data page.

[0100] It should be noted that, since this embodiment stores the transaction identifier in a separate data page, there is a possibility that a transaction identifier has already been allocated a data page. Therefore, it is necessary to determine this situation to prevent the duplicate generation of data pages, which would result in wasted performance and data anomalies.

[0101] In one embodiment, such as Figure 6 As shown, after step S60, that is, after adding a time slot containing the allocation time to the end of the data page to obtain the target page directory, the method for finding the database tuple further includes:

[0102] S51: Determine whether there are dirty data pages in the transaction page directory.

[0103] S52: If it exists, write the dirty data page to the disk.

[0104] In one embodiment, after obtaining the target page directory, it is first determined whether a checkpoint operation needs to be performed. This checkpoint operation is used to persist data pages in the buffer pool to the backend physical storage to ensure database consistency; that is, it writes dirty data pages to disk, ensuring that the data in memory and on disk are consistent.

[0105] Then, in step S51, it is determined whether there are dirty pages (that is, data pages that have been written to but not persisted) in the transaction page directory of the buffer pool.

[0106] Next, in steps S52-S54, in the path where dirty data pages exist, a dirty data page that needs to be buffered before being written to the disk is selected, and the dirty data page is written to the buffer until the buffer is full, and then written to the hard disk. That is, a flush operation is performed on the dirty data page, and then the fsync operation is executed.

[0107] The `fsync` operation is performed to persist the data in the transaction page directory of the database instance. The `fsync` operation is a system call: it requires passing a function descriptor (FD) to the transaction page directory as an input parameter, and then the system call will apply the changes to the transaction page directory pointed to by this FD. `fsync` will ensure that it does not return until the disk write operation is complete.

[0108] It should be noted that dirty data pages are used to speed up data processing. Therefore, dirty data pages are first written to a buffer so that disk write operations can be performed all at once, reducing write overhead. However, this also leads to data inconsistency issues. Therefore, this embodiment checks whether dirty data pages exist in the transaction page directory. If they do, synchronization is performed promptly to prevent anomalies caused by data inconsistency.

[0109] In one embodiment, after step S52, i.e., after the dirty data page is written to the disk, the database tuple lookup method further includes the following steps:

[0110] S61: Determine if there are expired data pages.

[0111] S62: If it exists, select an expired data page and generate a log (xlog) record corresponding to the expired data page for redo operations.

[0112] S63: Perform a data clearing operation (truncate) on the selected expired data page.

[0113] S64: Repeat steps S62-S63 until there are no more expired data pages.

[0114] It should be noted that in this embodiment, since transaction identifiers are frozen and reused, it is necessary to identify and clean up expired data pages to prevent data anomalies caused by failure to clean up expired data pages. Additionally, corresponding log records are generated for subsequent retrieval of the expired data page, allowing for redoing or freezing of the expired data page.

[0115] In one embodiment, the transaction identifier consists of a 32-bit integer, where the first 16 bits record the name of the transaction page directory, the middle bits record the number of the data page, and the last 16 bits represent the timestamp. The timestamp is the offset of the data page, and it is used to address the transaction identifier within the transaction page directory.

[0116] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0117] In one embodiment, a database tuple lookup device is provided, which corresponds one-to-one with the database tuple lookup methods described in the above embodiments. For example... Figure 7 As shown, the database tuple lookup device includes an execution module 10, a writing module 20, an initialization module 30, a saving module 40, a retrieval module 50, an adding module 60, a first filtering module 70, and a second filtering module 80. Detailed descriptions of each functional module are as follows:

[0118] The execution module 10 is used to execute the pending transaction after receiving the submission instruction of the pending transaction, and obtain the first tuple corresponding to the pending transaction;

[0119] The writing module 20 is used to write the transaction identifier corresponding to the transaction to be processed into the first tuple to obtain the second tuple;

[0120] Initialization module 30 is used to initialize the transaction page directory corresponding to the transaction to be processed;

[0121] The storage module 40 is used to add the data page corresponding to the transaction identifier in the transaction page directory and store the transaction identifier in the data page;

[0122] The acquisition module 50 is used to acquire the time when the second tuple is written to the transaction identifier, and obtain the allocation time;

[0123] Add module 60, used to add a time slot containing the allocation time to the end of the data page to obtain the target page directory;

[0124] The first filtering module 70 is used to, when receiving an instruction to find the tuple corresponding to the expected time, traverse the time slots in the target page directory, filter out the target allocation time in the time slot that is consistent with the expected time, and obtain the target transaction identifier corresponding to the target allocation time;

[0125] The second filtering module 80 is used to filter out the transaction identifier corresponding to the target transaction identifier from the second tuple to obtain the target tuple.

[0126] For specific limitations regarding the database tuple lookup device, please refer to the limitations on the database tuple lookup method above, which will not be repeated here. Each module in the aforementioned database tuple lookup device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in hardware or independent of the processor in the computer device, or stored in software in the memory of the computer device, so that the processor can call and execute the operations corresponding to each module.

[0127] In one embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 8 As shown, the computer device includes a processor, memory, network interface, and database connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and database. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The network interface is used for communication with external terminals via a network connection. When the computer program is executed by the processor, it implements a method for searching database tuples.

[0128] In one embodiment, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to perform the following steps:

[0129] Upon receiving the commit instruction for the pending transaction, the pending transaction is executed to obtain the first tuple corresponding to the pending transaction;

[0130] Write the transaction identifier corresponding to the transaction to be processed into the first tuple to obtain the second tuple;

[0131] Initialize the transaction page directory corresponding to the transaction to be processed;

[0132] In the transaction page directory, add the data page corresponding to the transaction identifier, and save the transaction identifier in the data page;

[0133] Obtain the time when the second tuple is written to the transaction identifier to get the allocation time;

[0134] At the end of the data page, a time slot containing the allocated time is added to obtain the target page directory;

[0135] When an instruction is received to find the tuple corresponding to the expected time, the time slots in the target page directory are traversed, and the target allocation time that matches the expected time is selected from the time slots to obtain the target transaction identifier corresponding to the target allocation time.

[0136] In the second tuple, the transaction identifier corresponding to the target transaction identifier is selected to obtain the target tuple.

[0137] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, the computer program performing the following steps when executed by a processor:

[0138] Upon receiving the commit instruction for the pending transaction, the pending transaction is executed to obtain the first tuple corresponding to the pending transaction;

[0139] Write the transaction identifier corresponding to the transaction to be processed into the first tuple to obtain the second tuple;

[0140] Initialize the transaction page directory corresponding to the transaction to be processed;

[0141] In the transaction page directory, add the data page corresponding to the transaction identifier, and save the transaction identifier in the data page;

[0142] Obtain the time when the second tuple is written to the transaction identifier to get the allocation time;

[0143] At the end of the data page, a time slot containing the allocated time is added to obtain the target page directory;

[0144] When an instruction is received to find the tuple corresponding to the expected time, the time slots in the target page directory are traversed, and the target allocation time that matches the expected time is selected from the time slots to obtain the target transaction identifier corresponding to the target allocation time.

[0145] In the second tuple, the transaction identifier corresponding to the target transaction identifier is selected to obtain the target tuple.

[0146] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), Rambus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0147] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is used as an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.

[0148] The above-described embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included within the protection scope of the present invention.

Claims

1. A method for searching database tuples, characterized in that, include: Upon receiving the commit instruction for the pending transaction, the pending transaction is executed to obtain the first tuple corresponding to the pending transaction; Write the transaction identifier corresponding to the transaction to be processed into the first tuple to obtain the second tuple; Initialize the transaction page directory corresponding to the transaction to be processed; In the transaction page directory, add the data page corresponding to the transaction identifier, and save the transaction identifier in the data page; Obtain the time when the second tuple is written to the transaction identifier to get the allocation time; At the end of the data page, a time slot containing the allocated time is added to obtain the target page directory; When an instruction is received to find the tuple corresponding to the expected time, the time slots in the target page directory are traversed, and the target allocation time that matches the expected time is selected from the time slots to obtain the target transaction identifier corresponding to the target allocation time. In the second tuple, the tuple corresponding to the target transaction identifier is selected to obtain the target tuple; The transaction identifier consists of a 32-bit integer. The first 16 bits are used to record the name of the transaction page directory, the middle bits are used to record the number of the data page, and the last bits are the time slot, which is the offset of the data page. The time slot is used to address the transaction identifier in the transaction page directory.

2. The database tuple lookup method as described in claim 1, characterized in that, After obtaining the first tuple corresponding to the transaction to be processed, the method further includes: Determine whether the first tuple needs to be written with the transaction identifier; If the transaction identifier needs to be written, determine whether the transaction page directory already exists; If it exists, the transaction identifier corresponding to the transaction to be processed is directly written into the first tuple.

3. The database tuple lookup method as described in claim 1, characterized in that, The initialization of the transaction page directory corresponding to the transaction to be processed includes: Initialize the buffer pool corresponding to the transaction page directory; Allocate corresponding shared memory to the buffer pool; Activate the buffer pool in the shared memory to initialize the transaction page directory.

4. The database tuple lookup method as described in claim 3, characterized in that, After activating the buffer pool in the shared memory, the method further includes: Obtain the transaction identifier corresponding to the transaction to be processed from the shared memory.

5. The database tuple lookup method as described in claim 1, characterized in that, The step of adding the data page corresponding to the transaction identifier in the transaction page directory and storing the transaction identifier in the data page includes: Determine whether the transaction identifier corresponds to the data page; If it exists, the data page is located, and the transaction identifier is saved into the data page; If it does not exist, the data page is allocated from the buffer pool of the transaction page directory and the data page is initialized; Add the pending transaction to the data page.

6. The database tuple lookup method as described in claim 1, characterized in that, After adding a time slot containing the allocation time to the end of the data page to obtain the target page directory, the method further includes: Determine whether there are dirty data pages in the transaction page directory; If it exists, the dirty data page is written to disk.

7. A database tuple lookup device, characterized in that, include: An execution module is used to execute the pending transaction after receiving a commit instruction for the pending transaction, and obtain the first tuple corresponding to the pending transaction; The writing module is used to write the transaction identifier corresponding to the transaction to be processed into the first tuple to obtain the second tuple; An initialization module is used to initialize the transaction page directory corresponding to the transaction to be processed; The storage module is used to add the data page corresponding to the transaction identifier to the transaction page directory and store the transaction identifier in the data page; The acquisition module is used to obtain the time when the second tuple is written to the transaction identifier, and thus obtain the allocation time; An add module is used to add a time slot containing the allocated time to the end of the data page to obtain the target page directory; The first filtering module is used to, when receiving an instruction to find the tuple corresponding to the expected time, traverse the time slots in the target page directory, filter out the target allocation time in the time slot that is consistent with the expected time, and obtain the target transaction identifier corresponding to the target allocation time; The second filtering module is used to filter out the tuple corresponding to the target transaction identifier from the second tuple to obtain the target tuple; The transaction identifier consists of a 32-bit integer. The first 16 bits are used to record the name of the transaction page directory, the middle bits are used to record the number of the data page, and the last bits are the time slot, which is the offset of the data page. The time slot is used to address the transaction identifier in the transaction page directory.

8. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the database tuple lookup method as described in any one of claims 1 to 6.

9. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the database tuple lookup method as described in any one of claims 1 to 6.

Images