Query method and device for database operation history, electronic equipment and storage medium

Abstract

The embodiment of the invention provides a database operation history query method and device, electronic equipment and a storage medium, and belongs to the technical field of databases. The method comprises the steps that an operation history query request is obtained, the operation history query request is used for querying an operation record of a target data row in a preset database under a target transaction, and the operation history query request comprises a page number of a data page where target data is located, a target data row identifier and a transaction submission number of the target transaction; performing transaction slot screening on a preset database according to the data page number and the target data row identifier to obtain a target transaction slot of the target data row; and according to the transaction submission number, carrying out jumping query on the target transaction slot to obtain a target operation record of the target transaction. According to the embodiment, the query efficiency of the database operation history can be improved.

Description

Technical Field

[0001] This application relates to the field of database technology, and in particular to a method and apparatus, electronic device and storage medium for querying database operation history. Background Technology

[0002] In the in-place update storage engine of the MogDB database, heap table pages use transaction slots to manage the historical versions of tuples. When performing insert, delete, or update operations on tuples on a heap table page, a transaction slot is first retrieved from the page, and the historical records generated by the insert, delete, query, and update operations are inserted into the transaction slot as nodes. When a transaction is committed, its historical records are still retained, and new transactions reuse the transaction slots occupied by committed transactions and generate new historical records. Thus, each transaction slot on the heap table page forms a version chain, which records the modification records of different transactions in the order in which the transaction slots were reused.

[0003] When retrieving the target historical version of a tuple, MogDB queries the transaction slot corresponding to the tuple and then traverses the version chain on the transaction slot until the target historical version is found, resulting in low query efficiency. Therefore, improving the query efficiency of database operation history has become an urgent problem to be solved. Summary of the Invention

[0004] The main objective of this application is to provide a method, apparatus, electronic device, and storage medium for querying database operation history, aiming to improve the efficiency of querying database operation history.

[0005] To achieve the above objectives, a first aspect of this application proposes a method for querying database operation history, the method comprising: Obtain an operation history query request, wherein the operation history query request is used to query the operation records of the target data row in the preset database under the target transaction, and the operation history query request includes the data page number where the target data is located, the target data row identifier, and the transaction commit number of the target transaction; The target transaction slot of the target data row is obtained by filtering the preset database based on the data page number and the target data row identifier. A skip query is performed on the target transaction slot based on the transaction commit number to obtain the target operation record of the target transaction.

[0006] In some embodiments, the step of filtering the preset database for transaction slots based on the data page number and the target data row identifier to obtain the target transaction slot for the target data row includes: The target data page is obtained by filtering the stacked table pages of the preset database according to the data page number; Information is extracted from the target data page based on the target data row identifier to obtain the metadata information of the target data row; The metadata information is parsed to determine the target transaction slot of the target data row.

[0007] In some embodiments, the target transaction slot includes a transaction node pointer and an index node pointer, wherein the transaction node pointer points to the head node of a node linked list consisting of transaction nodes and index nodes, the node linked list contains a group of consecutive transaction nodes with the same transaction number, and the index node pointer points to the node after the last transaction node in the group of consecutive transaction nodes with the same transaction number. The step of performing a skip query on the target transaction slot based on the transaction commit number to obtain the target operation record of the target transaction includes: The transaction read operation is determined by comparing the transaction number of the node pointed to by the index node pointer with the transaction commit number. Based on the transaction read operation, the target transaction slot is read to obtain the target operation record.

[0008] In some embodiments, the step of comparing the transaction number of the node pointed to by the inode pointer with the transaction commit number to determine the transaction read operation includes: If the transaction number of the node pointed to by the index node pointer is less than the transaction commit number, then starting from the head node of the node linked list, the transaction nodes are traversed sequentially until the node pointed to by the index node pointer is reached. If the transaction number of the node pointed to by the index node pointer is equal to the transaction commit number, then starting from the next transaction node pointed to by the index node pointer, the transaction nodes are traversed sequentially until the next index node or the end of the node list is reached. If the transaction number of the node pointed to by the index node pointer is greater than the transaction commit number, then the index node continues to jump backward along the index node pointer until the transaction number of the node pointed to by the index node pointer is equal to the transaction commit number. Then, starting from the next transaction node of the node pointed to by the index node pointer, the transaction nodes are traversed sequentially until the next index node or the end of the node list is reached.

[0009] In some embodiments, the method further includes: Obtain a database operation request; wherein, the database operation request includes an operation transaction number; If the operation transaction number is greater than the recorded transaction number in the preset database, an index node and a transaction node are created according to the operation transaction number, and the preset transaction slot is updated according to the transaction node and the index node; If the operation transaction number is less than or equal to the recorded transaction number in the preset database, a transaction node is created based on the operation transaction number, and the preset transaction slot is updated based on the transaction node.

[0010] In some embodiments, updating the preset transaction slot based on the transaction node and the index node includes: Insert the index node at the head of the node list corresponding to the preset transaction slot; Insert the transaction node at the head of the node linked list corresponding to the preset transaction slot; The transaction node pointer of the preset transaction slot is set to point to the transaction node, and the index node pointer of the preset transaction slot is set to point to the index node.

[0011] In some embodiments, updating the preset transaction slot according to the transaction node includes: Insert the transaction node at the head of the node linked list corresponding to the preset transaction slot; Set the transaction node pointer of the preset transaction slot to point to the transaction node.

[0012] To achieve the above objectives, a second aspect of this application provides a database operation history query apparatus, the apparatus comprising: The data acquisition module is used to acquire operation history query requests, wherein the operation history query requests are used to query the operation records of the target data row in the preset database under the target transaction, and the operation history query requests include the data page number where the target data is located, the target data row identifier, and the transaction commit number of the target transaction; The transaction slot filtering module is used to filter the preset database for transaction slots based on the data page number and the target data row identifier to obtain the target transaction slot of the target data row. The skip query module is used to perform a skip query on the target transaction slot based on the transaction commit number to obtain the target operation record of the target transaction.

[0013] To achieve the above objectives, a third aspect of this application provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the method described in the first aspect.

[0014] To achieve the above objectives, a fourth aspect of the present application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the method described in the first aspect.

[0015] This application proposes a method, apparatus, electronic device, and storage medium for querying database operation history. It receives an operation history query request containing a data page number, a target data row identifier, and a transaction commit number. Then, based on the data page number and the target data row identifier, it filters out the transaction slot where the target data row is located, thereby locking the range of the version chain to be traversed. Finally, through skip-style traversal, it avoids sequential traversal of irrelevant transaction records in the entire version chain, quickly skipping nodes unrelated to the target transaction and directly locating the operation record corresponding to the target transaction. This improves the efficiency of obtaining the target historical version in the MogDB database and solves the problems of long version chain traversal paths and low query performance. Attached Figure Description

[0016] Figure 1 This is a flowchart of a database operation history query method provided in an embodiment of this application; Figure 2 yes Figure 1 The flowchart of step S102 in the document; Figure 3 yes Figure 1 The flowchart of step S103 in the process; Figure 4 yes Figure 3 The flowchart of step S301 in the process; Figure 5 This is a flowchart of a database operation history query method provided in another embodiment of this application; Figure 6 yes Figure 5 The flowchart of step S502 in the document; Figure 7 yes Figure 5 The flowchart of step S503 in the process; Figure 8 This is a schematic diagram of the structure of the database operation history query device provided in the embodiments of this application; Figure 9 This is a schematic diagram of the hardware structure of the electronic device provided in the embodiments of this application; Figure 10 This is a schematic diagram of the transaction slot node linked list provided in the embodiments of this application; Figure 11 This is a schematic diagram of a transaction slot node linked list provided in another embodiment of this application. Detailed Implementation

[0017] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0018] It should be noted that although functional modules are divided in the device schematic diagram and a logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than the module division in the device or the order in the flowchart. The terms "first," "second," etc., in the specification, claims, and the aforementioned drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence.

[0019] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0020] First, let's analyze some of the terms used in this application: MogDB: MogDB is an open-source relational database management system (RDBMS) designed for enterprise applications, supporting SQL query language and parallel data processing. Widely used in industries such as artificial intelligence, finance, and the internet, MogDB offers high availability, flexible data backup and recovery options, and efficient concurrent processing capabilities. Furthermore, MogDB supports high-performance data replication and distributed database architecture, allowing enterprises to build scalable database solutions. MogDB not only emphasizes performance optimization but also prioritizes data security and privacy protection, providing multi-layered security measures, including data encryption, access control, and audit logs, to ensure secure and reliable data processing. This makes MogDB an ideal choice for enterprise systems requiring high data security and processing efficiency.

[0021] In the in-place update storage engine of the MogDB database, heap table pages use transaction slots to manage the historical versions of tuples. When performing insert, delete, or update operations on tuples on a heap table page, a transaction slot is first retrieved from the page, and the historical records generated by the insert, delete, query, and update operations are inserted into the transaction slot as nodes. When a transaction is committed, its historical records are still retained, and new transactions reuse the transaction slots occupied by committed transactions and generate new historical records. Thus, each transaction slot on the heap table page forms a version chain, which records the modification records of different transactions in the order in which the transaction slots were reused.

[0022] When retrieving the target historical version of a tuple, MogDB queries the transaction slot corresponding to the tuple and then traverses the version chain on the transaction slot until the target historical version is found, resulting in low query efficiency. Therefore, improving the query efficiency of database operation history has become an urgent problem to be solved.

[0023] Based on this, embodiments of this application provide a method and apparatus, electronic device and storage medium for querying database operation history, aiming to improve the query efficiency of database operation history.

[0024] This application provides a method, apparatus, electronic device, and storage medium for querying database operation history, which will be specifically described through the following embodiments. First, the method for querying database operation history in this application embodiment is described.

[0025] The embodiments of this application can acquire and process relevant data based on artificial intelligence technology. Artificial intelligence (AI) refers to the theories, methods, technologies, and application systems that use digital computers or machines controlled by digital computers to simulate, extend, and expand human intelligence, perceive the environment, acquire knowledge, and use that knowledge to obtain optimal results.

[0026] Foundational technologies for artificial intelligence generally include sensors, dedicated AI chips, cloud computing, distributed storage, big data processing, operating / interactive systems, and mechatronics. AI software technologies mainly encompass computer vision, robotics, biometrics, speech processing, natural language processing, and machine learning / deep learning.

[0027] The database operation history query method provided in this application relates to the field of database technology. This database operation history query method can be applied to a terminal, a server, or software running on either a terminal or a server. In some embodiments, the terminal can be a smartphone, tablet, laptop, desktop computer, etc.; the server can be configured as an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms; the software can be an application implementing the database operation history query method, but is not limited to the above forms.

[0028] This application can be used in a wide variety of general-purpose or special-purpose computer system environments or configurations. Examples include: personal computers, server computers, handheld or portable devices, tablet devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, and distributed computing environments including any of the above systems or devices. This application can be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform specific tasks or implement specific abstract data types. This application can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0029] It should be noted that in all specific embodiments of this application, when processing data related to user identity or characteristics, such as user information, user behavior data, user historical data, and user location information, user permission or consent is obtained first. Furthermore, the collection, use, and processing of this data comply with relevant laws, regulations, and standards. In addition, when embodiments of this application require access to sensitive personal information of users, separate permission or consent from the user is obtained through pop-ups or redirection to confirmation pages. Only after obtaining the user's separate permission or consent is the necessary user-related data required for the proper functioning of these embodiments acquired.

[0030] Figure 1 This is an optional flowchart of a database operation history query method provided in the embodiments of this application. Figure 1 The method may include, but is not limited to, steps S101 to S103.

[0031] Step S101: Obtain an operation history query request, wherein the operation history query request is used to query the operation records of the target data row in the preset database under the target transaction. The operation history query request includes the data page number where the target data is located, the target data row identifier, and the transaction commit number of the target transaction. Step S102: Filter the preset database for transaction slots based on the data page number and the target data row identifier to obtain the target transaction slot for the target data row; Step S103: Perform a skip query on the target transaction slot based on the transaction commit number to obtain the target operation record of the target transaction.

[0032] Steps S101 to S103, as illustrated in this embodiment, involve receiving an operation history query request containing a data page number, a target data row identifier, and a transaction commit number. Then, based on the data page number and the target data row identifier, the transaction slot where the target data row is located is filtered out, thereby locking the range of the version chain to be traversed. Finally, by skipping traversal, the sequential traversal of irrelevant transaction records in the entire version chain is avoided, allowing for quick skipping of nodes unrelated to the target transaction and direct location of the operation record corresponding to the target transaction. This improves the efficiency of obtaining the target historical version in the MogDB database and solves the problems of long version chain traversal paths and low query performance.

[0033] In step S101 of some embodiments, the operation history query request refers to an information request used to obtain records of modifications, deletions, or insertions of a target data row in the database within a specific transaction scope. The operation history query request includes at least the following elements: the page number of the data page containing the target data, the identifier of the target data row, and the transaction commit number of the target transaction. Through this request, the operation content performed by a specified transaction on a specified data row and its context information can be accurately located and retrieved.

[0034] For example, the target data is an order record in a database table named "Orders Table", such as order number "ORD123456"; the order data is stored in a data page with physical page number "9832", and its row identifier (i.e. logical position) in that page is "5"; the target transaction is an order status update transaction with the number "TXN20240321001", and the commit number of this transaction is "CMID789456", which is used to identify the time sequence of its commit in the database system and version control.

[0035] The target data is the data row "ORD123456", corresponding to specific business entity information. The data page number "9832" numerically represents the physical location of this data in the database file storage structure and is the basic unit in the database page management mechanism. The target data row identifier "5" indicates the specific offset position of this data row within the data page, facilitating quick location. The target transaction "TXN20240321001" represents an operation on the target data, and the transaction commit number "CMID789456" reflects its final commit node that was persisted by the database system.

[0036] The target data and the target transaction have an operational relationship, meaning that the target transaction modifies, deletes, or adds rows to the target data during its execution. The target data and the transaction commit number have a version tracking relationship, meaning that the transaction commit number can uniquely pinpoint the impact of a specific commit operation on the target data, thereby enabling precise backtracking and version auditing of historical operations.

[0037] Please see Figure 2 In some embodiments, step S102 may include, but is not limited to, steps S201 to S203: Step S201: Filter the stacked table pages of the preset database according to the data page number to obtain the target data page; Step S202: Extract information from the target data page based on the target data row identifier to obtain the metadata information of the target data row; Step S203: Parse the metadata information to determine the target transaction slot for the target data row.

[0038] Steps S201 to S203 as shown in the embodiments of this application involve filtering the target data page in the stack table page by the data page number, then accurately extracting the metadata information of the corresponding data row in the target data page based on the target data row identifier, and finally parsing the extracted metadata information to locate the target transaction slot corresponding to the target data row, thereby obtaining the target transaction slot.

[0039] In step S201 of some embodiments, the preset database is MogDB. MogDB is a relational database system that supports Multi-Version Concurrency Control (MVCC) and has the ability to support row-level version information storage and transaction visibility management. A stacked table page is the basic physical structural unit in MogDB used to store table data. It exists in the form of fixed-size data pages, each containing multiple logical data rows. The data rows in the stacked table page are not arranged in a specific order, therefore precise filtering is required based on the page number. The filtering method involves reading the mapping relationship between page numbers and storage paths in the system metadata structure, and selecting pages in physical storage whose page numbers match the input page number as the target data pages.

[0040] In step S202 of some embodiments, the information extraction method involves locating the specific position of the corresponding data row in the page based on the offset indicated by the target data row identifier, and parsing the stored content at that position to obtain the metadata information of the data row. The metadata information includes, but is not limited to, the insertion transaction number, the deletion transaction number, the row visibility status, the update chain pointer, etc., which are used to characterize the version status of the target data row and its visibility control information in different transaction contexts.

[0041] In step S203 of some embodiments, the information parsing method is structure field parsing, that is, based on the preset format of the data row metadata in MogDB, the extracted metadata information is read and parsed item by item in the field order to obtain the transaction slot number. MogDB includes multiple transaction slots, and the target transaction slot is determined by comparing the transaction slot number with the sequence number of each transaction slot in MogDB, and the transaction slot with the same sequence number is taken as the target transaction slot.

[0042] Please see Figure 11 The target transaction slot includes a transaction node pointer and an index node pointer. The transaction node pointer points to the head node of a linked list of nodes consisting of multiple transaction nodes and index nodes. This linked list is arranged in the order of transaction commits and stores the operation information of each transaction on data rows. Within the linked list, there exists a group of consecutive transaction nodes with the same transaction commit number, representing the multi-step operation records performed on data rows during the execution of a specific transaction. The index node pointer points to the node following the last transaction node in this consecutive sequence of transaction nodes, thus identifying the end point of the same transaction and facilitating the distinction between the operation boundaries of different transactions.

[0043] Please see Figure 3 In some embodiments, the target transaction slot includes a transaction node pointer and an index node pointer, wherein the transaction node pointer points to the head node of a node linked list composed of transaction nodes and index nodes, and the node linked list contains a group of transaction nodes with the same transaction number arranged consecutively, and the index node pointer points to the node after the last transaction node in the group of consecutive transaction nodes with the same transaction number. Step S103 may include, but is not limited to, steps S301 to S302: Step S301: Compare the transaction number of the node pointed to by the index node pointer with the transaction commit number to determine the transaction read operation; Step S302: Read the target transaction slot according to the transaction read operation to obtain the target operation record.

[0044] Steps S301 to S302, as illustrated in this embodiment, avoid traversing irrelevant transaction nodes by matching the transaction number of the node pointed to by the index node pointer with the transaction commit number of the target transaction. Then, based on the determined transaction read operation, the target transaction slot is read in a targeted manner to directly locate and extract the target operation information recorded in the transaction slot. This improves the filtering efficiency of the database system during historical operation querying, thereby increasing the reading efficiency of the database system during historical operation querying.

[0045] Please see Figure 4In some embodiments, step S301 may include, but is not limited to, steps S401 to S403: Step S401: If the transaction number of the node pointed to by the index node pointer is less than the transaction commit number, then start from the head node of the node linked list and traverse the transaction nodes sequentially until the node pointed to by the index node pointer is reached. Step S402: If the transaction number of the node pointed to by the index node pointer is equal to the transaction commit number, then start from the next transaction node pointed to by the index node pointer and traverse the transaction nodes sequentially until the next index node or the end of the node list is reached. Step S403: If the transaction number of the node pointed to by the index node pointer is greater than the transaction commit number, then continue to jump backward along the index node pointer to traverse the index nodes until the transaction number of the node pointed to by the index node pointer is equal to the transaction commit number. Then start from the next transaction node of the node pointed to by the index node pointer to traverse the transaction nodes sequentially until the next index node or the end of the node list is reached.

[0046] Steps S401 to S403 of this embodiment construct optimal node traversal paths based on the relationship between different transaction commit numbers and the transaction numbers of nodes pointed to by index node pointers. In the transaction node read path selection part, when the transaction number of the node pointed to by the index node pointer is less than the transaction commit number of the target transaction, the system traverses sequentially from the head node of the transaction node linked list until the node pointed to by the index node pointer. When the transaction number of the node pointed to by the index node pointer is equal to the transaction commit number of the target transaction, the system traverses from the next transaction node of that index node until the next index node or the end of the node linked list. When the transaction number of the node pointed to by the index node pointer is greater than the transaction commit number, the system traverses backward along the index nodes in a skip manner until a node position matching the transaction commit number is reached, and then sequentially enters the operation range of the corresponding transaction for traversal. This improves the positioning efficiency of traversing the transaction node linked list, avoids the efficiency bottleneck caused by the traditional full-linked list linear scan method, and ultimately achieves accurate extraction of the target transaction operation information, thereby solving the problems of long node positioning paths, unstable response times, and high system load.

[0047] In step S401 of some embodiments, if the transaction number of the node pointed to by the index node pointer is less than the transaction commit number, then starting from the head node of the node linked list, the transaction nodes are traversed sequentially until the node pointed to by the index node pointer is reached. For example, please refer to... Figure 11 When the transaction commit number is 3, the node pointed to by the index node pointer has a transaction number of 2. Therefore, the transaction nodes are traversed from the head node of the node linked list until the index node is reached, which is the leftmost node in transaction 2, and transaction 3 is obtained.

[0048] In step S402 of some embodiments, if the transaction number of the node pointed to by the index node pointer is equal to the transaction commit number, then starting from the next transaction node pointed to by the index node pointer, the transaction nodes are traversed sequentially until the next index node or the end of the node list is reached. For example, please refer to... Figure 11 When the transaction commit number is 2, the transaction number 2 of the node pointed to by the index node pointer is equal to the transaction commit number 2. Starting from the next transaction node of this index node, the transaction nodes are traversed sequentially until the next index node is reached, and transaction 2 can be obtained.

[0049] In step S403 of some embodiments, if the transaction number of the node pointed to by the index node pointer is greater than the transaction commit number, then the index nodes are traversed backwards along the index node pointer until the transaction number of the node pointed to by the index node pointer is equal to the transaction commit number. Then, the transaction nodes are traversed sequentially starting from the next transaction node pointed to by the index node pointer until the next index node or the end of the node list is reached. For example, please refer to... Figure 11 When the transaction commit number is 1, the search jumps backward along the index node. When the index node with transaction number 1 is found, the transaction nodes are traversed sequentially until the end of the node list is reached, and transaction 1 can be obtained.

[0050] In step S302 of some embodiments, the method of reading the target operation record is described, for example, see [link to relevant documentation]. Figure 11 When the transaction commit number is 2, the transaction read operation is determined to be to read backwards along the index node of transaction 2 until the index node of transaction 1 is read.

[0051] Please see Figure 5 In some embodiments, the method for querying database operation history may also include, but is not limited to, steps S501 to S503: Step S501: Obtain a database operation request; wherein, the database operation request includes the operation transaction number; Step S502: If the operation transaction number is greater than the preset database record transaction number, create an index node and a transaction node according to the operation transaction number, and update the preset transaction slot according to the transaction node and index node. Step S503: If the operation transaction number is less than or equal to the recorded transaction number in the preset database, create a transaction node according to the operation transaction number, and update the preset transaction slot according to the transaction node.

[0052] In the embodiments of this application, steps S501 to S503 firstly involve obtaining a database operation request. If the operation transaction number is greater than the preset database record transaction number, an index node and a transaction node are created based on the operation transaction number, and the preset transaction slot is updated based on the transaction node and the index node. If the operation transaction number is less than or equal to the preset database record transaction number, a transaction node is created based on the operation transaction number, and the preset transaction slot is updated based on the transaction node. This constructs a transaction slot data structure that can accelerate the query when querying the database operation history, thereby improving the query efficiency of the database operation history.

[0053] In step S501 of some embodiments, the database operation request is an instruction to add, delete, query, or modify a target data object in a preset database, which includes an operation type field and an operation transaction number field.

[0054] Please see Figure 6 In some embodiments, step S502 includes, but is not limited to, steps S601 to S603: Step S601: Insert the index node into the head of the node linked list corresponding to the preset transaction slot; Step S602: Insert the transaction node into the head of the node linked list corresponding to the preset transaction slot; Step S603: Point the transaction node pointer of the preset transaction slot to the transaction node, and point the index node pointer of the preset transaction slot to the index node.

[0055] Steps S601 to S603 as shown in the embodiments of this application involve inserting the index node at the head of the node linked list corresponding to the preset transaction slot, then inserting the transaction node at the head of the node linked list corresponding to the preset transaction slot, and finally pointing the transaction node pointer of the preset transaction slot to the transaction node and pointing the index node pointer of the preset transaction slot to the index node. This constructs a transaction slot data structure that can accelerate the query when querying the database operation history, thereby improving the query efficiency of the database operation history.

[0056] It should be noted that steps S601 to S602 can only be executed sequentially. After steps S601 to S602 are completed, the transaction node becomes the head node, and the next node after this batch of transaction nodes becomes the index node. For example, please refer to [link to example]. Figure 11 When inserting transaction 3, first create the index node of transaction 2 and insert it into the node list. Then create transaction nodes for transaction 3 (there can be multiple nodes, not shown in the figure) and insert them into the node list. Finally, in step S603, point the transaction node to the transaction node of transaction 3 and point the index node to the index node of transaction 2.

[0057] Please see Figure 7In some embodiments, step S503 may include, but is not limited to, steps S701 to S702: Step S701: Insert the transaction node into the head of the node linked list corresponding to the preset transaction slot; Step S702: Point the transaction node pointer of the preset transaction slot to the transaction node.

[0058] Steps S701 to S702, as shown in the embodiments of this application, involve inserting a transaction node into the head of the node linked list corresponding to a preset transaction slot, and then pointing the transaction node pointer of the preset transaction slot to the transaction node. This constructs a transaction slot data structure that can accelerate the query when querying the database operation history, thereby improving the query efficiency of the database operation history.

[0059] In steps S701 to S702 of some embodiments, since transaction nodes may not all be completed at once, when there is a time delay among the nodes of the same batch of transaction nodes, the operation transaction number is less than or equal to the recorded transaction number of the preset database. Therefore, it is only necessary to insert a new transaction node and then point the transaction node pointer of the preset transaction slot to the transaction node to complete the update of the preset transaction slot.

[0060] Please see Figure 10 and Figure 11 .exist Figure 10 middle, Figure 10 The structure shown represents the case where there is no index node in the node linked list. Figure 10 In the structure shown, all transaction nodes are arranged sequentially, with the starting position of the linked list directly pointing to the most recently inserted transaction node, "Transaction 3". To find the transaction node corresponding to a specific transaction number (such as "Transaction 1"), it is necessary to start from the head node and traverse the entire linked list sequentially until the node corresponding to the target transaction number is reached. This traversal method results in a long traversal path and low access efficiency when the number of transaction nodes is large, especially in scenarios with multiple densely distributed transaction operations, significantly impacting performance. Figure 11 The structure shown illustrates the case where an index node is introduced into the node linked list. A skip-access path is formed through the index node pointers. Figure 11 In the structure shown, the starting position of the linked list still points to the most recently inserted transaction node, "Transaction 3," but it is also equipped with multiple index nodes, such as index nodes pointing to "Transaction 2" and "Transaction 1." Jump connections can be established between these index nodes, allowing for quick location of the target segment directly via the index path when reading the target transaction node (such as "Transaction 1"), thereby reducing unnecessary traversal times. In summary, compared to... Figure 10 The structure shown. Figure 11By introducing index nodes to optimize skip-based access to the transaction node linked list, the average traversal length is reduced, transaction read performance is improved, and the ability to locate transactions in high-concurrency or high-volume transaction environments is enhanced. This helps to build a transaction tracing mechanism with structural stability and efficient access.

[0061] Please see Figure 8 This application also provides a database operation history query device, which can implement the above-mentioned database operation history query method. The device includes: The data acquisition module 801 is used to acquire an operation history query request, wherein the operation history query request is used to query the operation record of the target data row in the preset database under the target transaction, and the operation history query request includes the data page number where the target data is located, the target data row identifier, and the transaction commit number of the target transaction; The transaction slot filtering module 802 is used to filter the transaction slots of the preset database according to the data page number and the target data row identifier to obtain the target transaction slot of the target data row. The skip query module 803 is used to perform a skip query on the target transaction slot based on the transaction commit number to obtain the target operation record of the target transaction.

[0062] The specific implementation of the database operation history query device is basically the same as the specific implementation of the database operation history query method described above, and will not be repeated here.

[0063] This application also provides an electronic device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the aforementioned method for querying database operation history. This electronic device can be any smart terminal, including tablet computers, in-vehicle computers, etc.

[0064] Please see Figure 9 , Figure 9 The hardware structure of an electronic device according to another embodiment is illustrated. The electronic device includes: The processor 901 can be implemented using a general-purpose CPU (Central Processing Unit), microprocessor, application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of this application. The memory 902 can be implemented as a read-only memory (ROM), static storage device, dynamic storage device, or random access memory (RAM). The memory 902 can store the operating system and other application programs. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the relevant program code is stored in the memory 902 and is called and executed by the processor 901 to execute the database operation history query method of the embodiments of this application. The input / output interface 903 is used to implement information input and output; The communication interface 904 is used to enable communication and interaction between this device and other devices. Communication can be achieved through wired means (such as USB, Ethernet cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.). Bus 905 transmits information between various components of the device (e.g., processor 901, memory 902, input / output interface 903, and communication interface 904); The processor 901, memory 902, input / output interface 903, and communication interface 904 are connected to each other within the device via bus 905.

[0065] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described method for querying database operation history.

[0066] Memory, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs and non-transitory computer-executable programs. Furthermore, memory may include high-speed random access memory, and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, memory may optionally include memory remotely located relative to the processor, and these remote memories can be connected to the processor via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0067] The database operation history query method, device, electronic device, and storage medium provided in this application receive an operation history query request containing a data page number, a target data row identifier, and a transaction commit number. Then, based on the data page number and the target data row identifier, the transaction slot where the target data row is located is filtered out, thereby locking the range of the version chain to be traversed. Finally, by skipping traversal, the sequential traversal of irrelevant transaction records in the entire version chain is avoided, and nodes unrelated to the target transaction can be quickly skipped to directly locate the operation record corresponding to the target transaction. This improves the efficiency of obtaining the target historical version in the MogDB database and solves the problems of long version chain traversal paths and low query performance.

[0068] The embodiments described in this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided by the embodiments of this application. As those skilled in the art will know, with the evolution of technology and the emergence of new application scenarios, the technical solutions provided by the embodiments of this application are also applicable to similar technical problems.

[0069] Those skilled in the art will understand that the technical solutions shown in the figures do not constitute a limitation on the embodiments of this application, and may include more or fewer steps than shown, or combine certain steps, or different steps.

[0070] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate; 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 this embodiment according to actual needs.

[0071] Those skilled in the art will understand that all or some of the steps in the methods disclosed above, as well as the functional modules / units in the systems and devices, can be implemented as software, firmware, hardware, or suitable combinations thereof.

[0072] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification and accompanying drawings of this application 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 this application 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 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.

[0073] It should be understood that in this application, "at least one (item)" means one or more, and "more than" means two or more. "And / or" is used to describe the relationship between related objects, indicating that three relationships can exist. For example, "A and / or B" can represent three cases: only A exists, only B exists, and both A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one (item) of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one (item) of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.

[0074] In the several embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of the units described above is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0075] The units described above as separate components may or may not be physically separate. 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 units can be selected to achieve the purpose of this embodiment according to actual needs.

[0076] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0077] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes multiple instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing programs, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0078] The preferred embodiments of the present application have been described above with reference to the accompanying drawings, but this does not limit the scope of the claims of the present application. Any modifications, equivalent substitutions, and improvements made by those skilled in the art without departing from the scope and substance of the embodiments of the present application shall be within the scope of the claims of the present application.

Claims

1. A method of querying a database operation history, characterized by, The method comprises: an operation history query request is acquired, wherein the operation history query request is used to query operation records of a target data row in a target transaction in a preset database, the operation history query request comprises a data page number of a data page where the target data is located, a target data row identifier, and a transaction commit number of the target transaction; transaction slot screening is performed on the preset database according to the data page number and the target data row identifier, to obtain a target transaction slot of the target data row; jump query is performed on the target transaction slot according to the transaction commit number, to obtain a target operation record of the target transaction.

2. The method of claim 1, wherein, The transaction slot screening on the preset database according to the data page number and the target data row identifier to obtain the target transaction slot of the target data row comprises: a heap table page of the preset database is screened according to the data page number, to obtain a target data page; metadata information of the target data row is extracted from the target data page according to the target data row identifier; the metadata information is parsed, to determine the target transaction slot of the target data row.

3. The method of claim 1, wherein, The target transaction slot comprises a transaction node pointer and an index node pointer, wherein the transaction node pointer points to a head node of a node linked list composed of transaction nodes and index nodes, a batch of transaction nodes with the same transaction number are arranged continuously in the node linked list, the index node pointer points to a next node of a last transaction node in the batch of continuous transaction nodes with the same transaction number, and the jump query on the target transaction slot according to the transaction commit number to obtain the target operation record of the target transaction comprises: the transaction number of a node pointed to by the index node pointer is compared with the transaction commit number, to determine a transaction read operation; the target transaction slot is read according to the transaction read operation, to obtain the target operation record.

4. The method of claim 3, wherein, The comparison of the transaction number of the node pointed to by the index node pointer with the transaction commit number to determine the transaction read operation comprises: if the transaction number of the node pointed to by the index node pointer is less than the transaction commit number, the transaction nodes are sequentially traversed from the head node of the node linked list until the node pointed to by the index node pointer is reached; if the transaction number of the node pointed to by the index node pointer is equal to the transaction commit number, the transaction nodes are sequentially traversed from a next transaction node of the node pointed to by the index node pointer until a next index node or the end of the node linked list is reached; if the transaction number of the node pointed to by the index node pointer is greater than the transaction commit number, the index nodes are sequentially traversed along the index node pointer until the transaction number of the node pointed to by the index node pointer is equal to the transaction commit number, and then the transaction nodes are sequentially traversed from a next transaction node of the node pointed to by the index node pointer until a next index node or the end of the node linked list is reached.

5. The method of claim 1, wherein, The method further comprises: a database operation request is acquired; wherein the database operation request comprises an operation transaction number. If the operation transaction number is greater than the recorded transaction number of the preset database, an index node and a transaction node are created according to the operation transaction number, and a preset transaction slot is updated according to the transaction node and the index node; If the operation transaction number is less than or equal to the recorded transaction number of the preset database, a transaction node is created according to the operation transaction number, and a preset transaction slot is updated according to the transaction node.

6. The method of claim 5, wherein, The updating of the preset transaction slot according to the transaction node and the index node comprises: inserting the index node into the head of a node chain table corresponding to the preset transaction slot; inserting the transaction node into the head of a node chain table corresponding to the preset transaction slot; pointing a transaction node pointer of the preset transaction slot to the transaction node, and pointing an index node pointer of the preset transaction slot to the index node.

7. The method of claim 5, wherein, The updating of the preset transaction slot according to the transaction node comprises: inserting the transaction node into the head of a node chain table corresponding to the preset transaction slot; pointing a transaction node pointer of the preset transaction slot to the transaction node.

8. An apparatus for querying a database operation history, characterized by: The apparatus comprises: an acquisition data module configured to acquire an operation history query request, wherein the operation history query request is used to query an operation record of a target data row in a target transaction in a preset database, and the operation history query request comprises a data page page number of the target data, a target data row identifier and a transaction commit number of the target transaction; a transaction slot screening module configured to perform transaction slot screening on the preset database according to the data page page number and the target data row identifier, to obtain a target transaction slot of the target data row; a jump query module configured to perform jump query on the target transaction slot according to the transaction commit number, to obtain a target operation record of the target transaction.

9. An electronic device, comprising: The electronic device comprises a memory and a processor, the memory stores a computer program, and the processor implements the database operation history query method in any one of claims 1 to 7 when executing the computer program.

10. A computer-readable storage medium storing a computer program, the computer program comprising instructions that, when executed by a computer, cause the computer to perform the method of any one of claims 1 to 9. The computer program is executed by the processor to implement the database operation history query method in any one of claims 1 to 7.

Images