Data storage method and device, data query method and device

Abstract

The embodiments of this specification provide a data storage method and device, a data query method and device, wherein the data storage method includes: when the target transaction is started, a corresponding transaction information row can be allocated to the target transaction in the transaction description information table, and the address of the transaction information row can be recorded in the transaction operation record; when the target transaction is committed, the transaction description information related to the target transaction can be backfilled into the transaction information row allocated to it, so that the transaction information to be queried can be found in the transaction description information table based on the address in the transaction operation record. In this way, the transaction description information of the target transaction can be persistently saved in the transaction description information table, and the relevant transaction information of the required historical version data can be directly queried based on the transaction description information table. In the case of a user's erroneous operation, the accurate historical version information can be quickly queried for recovery, which greatly reduces the complexity of use.

Description

Technical Field

[0001] The embodiments of the present specification relate to the field of database technology, and in particular to a data storage method and device, and a data query method and device. Background Art

[0002] With the rapid development of computer technology and Internet technology, online tasks are becoming more and more common, and with it comes a surge in data storage needs, which has led to the emergence of various databases. Databases have a large user base and a complete community ecosystem. Many users may make some mistakes in the process of online database operation and maintenance. Common examples include update operations or deletion statements without restrictions or specifying incorrect restrictions, which lead to data being destroyed or discarded due to human errors. At this time, it is often necessary to quickly query the historical version of data before the operation for recovery, so a faster or more reliable data query solution is needed. Summary of the invention

[0003] In view of this, the present specification provides a data storage method. One or more embodiments of the present specification also relate to a data query method, a data storage device, a data query device, a computing device, a computer-readable storage medium and a computer program to solve the technical defects existing in the prior art.

[0004] According to a first aspect of an embodiment of this specification, a data storage method is provided, including:

[0005] receiving a start request of a target transaction, wherein the target transaction is an operation set for performing data operations on target data;

[0006] In response to the start request, a corresponding transaction information row is allocated to the target transaction in the transaction description information table, and the address of the transaction information row is recorded in a transaction operation record, wherein the transaction operation record is a record generated for each data operation included in the target transaction;

[0007] In response to a commit operation of the target transaction, the transaction description information of the target transaction is backfilled into the transaction information row.

[0008] According to a second aspect of an embodiment of this specification, a data query method is provided, including:

[0009] Receiving a data query request, wherein the data query request carries a query user identifier and a version tag to be queried;

[0010] Obtaining the target transaction information row address included in the transaction operation record corresponding to the query user identifier;

[0011] According to the target transaction information row address, query the corresponding reference transaction information in the transaction description information table, wherein the reference transaction information includes a version mark;

[0012] When the version mark in the reference transaction information is inconsistent with the version mark to be queried, the target transaction information corresponding to the version mark to be queried is searched in the historical data record.

[0013] According to a third aspect of an embodiment of this specification, there is provided a data storage device, including:

[0014] A first receiving module is configured to receive a start request of a target transaction, wherein the target transaction is an operation set for performing data operations on target data;

[0015] a recording module configured to, in response to the start request, allocate a corresponding transaction information row to the target transaction in a transaction description information table, and record the address of the transaction information row in a transaction operation record, wherein the transaction operation record is a record generated for each data operation included in the target transaction;

[0016] The backfill module is configured to, in response to a commit operation of the target transaction, backfill the transaction description information of the target transaction into the transaction information row.

[0017] According to a fourth aspect of the embodiments of this specification, a data query device is provided, including:

[0018] A second receiving module is configured to receive a data query request, wherein the data query request carries a query user identifier and a to-be-queried version tag;

[0019] An acquisition module configured to acquire a target transaction information row address included in the transaction operation record corresponding to the query user identifier;

[0020] A query module, configured to query corresponding reference transaction information in a transaction description information table according to the row address of the target transaction information, wherein the reference transaction information includes a version mark;

[0021] The search module is configured to search for target transaction information corresponding to the version mark to be queried in the historical data record when the version mark in the reference transaction information is inconsistent with the version mark to be queried.

[0022] According to a fifth aspect of an embodiment of this specification, a computing device is provided, including:

[0023] Memory and processor;

[0024] The memory is used to store computer executable instructions, and the processor is used to execute the computer executable instructions. When the computer executable instructions are executed by the processor, the steps of the above-mentioned data storage method or data query method are implemented.

[0025] According to a sixth aspect of the embodiments of this specification, a computer-readable storage medium is provided, which stores computer-executable instructions, and when the instructions are executed by a processor, the steps of the above-mentioned data storage method or data query method are implemented.

[0026] According to a seventh aspect of the embodiments of this specification, a computer program is provided, wherein when the computer program is executed in a computer, the computer is caused to execute the steps of the above-mentioned data storage method or data query method.

[0027] An embodiment of the present specification provides a data storage method, which can receive a start request of a target transaction, wherein the target transaction is an operation set for performing data operations on target data; in response to the start request, a corresponding transaction information row is allocated to the target transaction in a transaction description information table, and the address of the transaction information row is recorded in a transaction operation record, wherein the transaction operation record is a record generated for each data operation included in the target transaction; in response to the commit operation of the target transaction, the transaction description information of the target transaction is backfilled into the transaction information row. In this case, when the target transaction is started, a corresponding transaction information row can be allocated to the target transaction in the transaction description information table, and the address of the transaction information row can be recorded in the transaction operation record. When the target transaction is committed, the transaction description information related to the target transaction can be backfilled into the transaction information row allocated to it, so that the transaction information to be queried can be found in the transaction description information table based on the address in the transaction operation record. In this way, the transaction description information of the target transaction can be persisted and saved in the transaction description information table. Subsequently, the relevant transaction information of the required historical version data can be queried directly based on the transaction description information table. In the event that the user makes an erroneous operation, the accurate historical version information can be quickly queried for recovery, which greatly reduces the complexity of use and allows users to better use and manage the database without worrying about data damage caused by erroneous operations, thereby improving the product strength of the database.

[0028] An embodiment of the present specification provides a data query method, which can receive a data query request, wherein the data query request carries a query user identifier and a version mark to be queried; then the target transaction information row address included in the transaction operation record corresponding to the query user identifier can be obtained; according to the target transaction information row address, the corresponding reference transaction information is queried in the transaction description information table, wherein the reference transaction information includes a version mark; thereafter, in the case where the version mark in the reference transaction information is inconsistent with the version mark to be queried, the target transaction information corresponding to the version mark to be queried can also be searched in the historical data record. In this case, a data query request initiated by a user can be received, and then the target transaction information row address included in the transaction operation record corresponding to the user is obtained. Based on the target transaction information row address, the corresponding transaction information can be found in the transaction description information table. Through a simple comparison, it is determined whether the transaction information is the transaction information required by the user query. If not, the historical data record can be further traced back to find the relevant transaction information of the historical version data required by the user in the historical data record. In this way, the transaction description information of the target transaction can be persisted and saved in the transaction description information table. Later, with the help of the persistently stored transaction description information and the historical version information retained in the historical data records, the relevant transaction information of the required historical version data can be directly queried in the transaction description information table and the historical data records based on simple query statements. In the event of a user's erroneous operation, the accurate historical version information can be quickly queried for recovery without relying on and parsing logs, saving the overhead of constructing reverse operations and greatly reducing the complexity of use. This allows users to better use and manage the database without worrying about data damage caused by erroneous operations, thereby improving the product strength of the database. BRIEF DESCRIPTION OF THE DRAWINGS

[0029] Figure 1 is a flow chart of a data storage method provided by an embodiment of this specification;

[0030] Figure 2 is a flow chart of a data query method provided by an embodiment of this specification;

[0031] Figure 3 is a schematic diagram of a data query link provided by an embodiment of this specification;

[0032] Figure 4 is a structural schematic diagram of a data storage device provided by an embodiment of this specification;

[0033] Figure 5 It is a structural schematic diagram of a data query device provided by an embodiment of this specification;

[0034] Figure 6It is a structural block diagram of a computing device provided by an embodiment of this specification. DETAILED DESCRIPTION

[0035] Many specific details are described in the following description to facilitate a full understanding of this specification. However, this specification can be implemented in many other ways than those described herein, and those skilled in the art can make similar generalizations without violating the connotation of this specification, so this specification is not limited to the specific implementation disclosed below.

[0036] The terms used in one or more embodiments of this specification are only for the purpose of describing specific embodiments, and are not intended to limit one or more embodiments of this specification. The singular forms of "a", "said" and "the" used in one or more embodiments of this specification and the appended claims are also intended to include plural forms, unless the context clearly indicates other meanings. It should also be understood that the term "and / or" used in one or more embodiments of this specification refers to and includes any or all possible combinations of one or more associated listed items.

[0037] It should be understood that although the terms first, second, etc. may be used to describe various information in one or more embodiments of this specification, this information should not be limited to these terms. These terms are only used to distinguish the same type of information from each other. For example, without departing from the scope of one or more embodiments of this specification, the first may also be referred to as the second, and similarly, the second may also be referred to as the first. Depending on the context, the word "if" as used herein may be interpreted as "at the time of" or "when" or "in response to determining".

[0038] First, the terms involved in one or more embodiments of this specification are explained.

[0039] MySQL: A widely used open source database management system, it is a relational database management system that stores data in different tables instead of putting all data in a large warehouse, which increases speed and flexibility. The language used by MySQL is the most commonly used standardized language for accessing databases. It adopts a dual licensing policy and is divided into community edition and commercial edition. Due to its small size, fast speed, low total cost of ownership, and especially the open source feature, the development of small and medium-sized websites generally chooses MySQL as the website database, which can help users manage relational databases.

[0040] Transaction (Trx): Generally refers to something to be done or done. In computer terms, it refers to a program execution unit that accesses and possibly updates various data items in a database. Transactions are usually caused by the execution of user programs written in high-level database manipulation languages ​​or programming languages ​​(such as SQL, C++, or Java), and are defined by statements such as begin transaction and end transaction (or function calls). A transaction consists of all operations performed between the start of a transaction and the end of a transaction, that is, a transaction is a collection of a series of strict operations in a database system. From the user's perspective, generally speaking, the begin statement marks the start of a transaction, and the commit statement commits the transaction and completes the transaction.

[0041] Generally speaking, transactions need to meet four characteristics: Atomicity: When operating the instructions in a transaction, either all are executed successfully or none are executed. As long as one of the instructions fails, all instructions fail, and the data is rolled back to the data state before the execution of the instruction; Consistency: The execution of a transaction causes the data to be converted from one state to another, but the integrity of the entire data remains stable; Isolation: If multiple transactions are executed concurrently, the changes made by each transaction must be isolated from other transactions; Durability: After the transaction is completed, the changes to the database data are persistently stored.

[0042] Active Transaction: An ongoing transaction that has not yet been committed.

[0043] InnoDB: A transaction engine system of MySQL, which is widely used.

[0044] Undo: The historical versions of database data are saved in Undo. Through Undo, users can query past versions of data or roll back data to a certain historical version.

[0045] Trx ID: The unique identification number of the transaction, a globally unique incrementing number assigned when the transaction is started.

[0046] ReadView: View, which is used to determine the key memory structure of transaction visibility. Through it, the database can know the historical version data that the user wants to query.

[0047] MVCC (Multi version concurrency control): Multi version concurrency control is a common concurrency control used in database management systems. MVCC aims to solve the problem of multiple and long read operations starving write operations caused by read-write locks. Under the MVCC mechanism, read operations read historical versions and can be executed concurrently without blocking write operations.

[0048] PK (primary key): PK is the primary key field of the MySQL InnoDB data table. Each data row in the table has a unique PK.

[0049] Rollptr: Rollback segment pointer. It exists on each InnoDB data row. Through the rollback segment pointer, the most recent historical version of the data row (that is, the previous image of the data row) can be traced back.

[0050] Purge Sys: Purge system, there will be no need for historical versions to be queried, and the Purge system will regularly clean up these historical version data as needed.

[0051] Binlog: A MySQL operation log. The biggest feature of Binlog is that it is a logical log. Tools can easily parse Binlog to obtain the user's update operation statements.

[0052] DBA (Database Administrator): A general term for staff engaged in the management and maintenance of database management systems (DBMS), which is a branch of operation and maintenance engineers.

[0053] Flash back Query: Flash back query is a special query in the database field. It can specify a certain point in the past and find the database data at that point in time.

[0054] Lizard: A transaction system. Compared with the transaction system mechanism of MySQL InnoDB, Lizard persists transaction status information and adopts a more efficient multi-version read-write concurrency mechanism.

[0055] Vision: To distinguish it from the native ReadView of MySQL, the view in the Lizard transaction system is renamed Vision. Compared with ReadView and the operating mechanism behind it, Vision is more concise and efficient.

[0056] Transaction Table: Transaction description information table. Persistent transaction description information will be saved in the transaction description information table.

[0057] TSA (Transaction Status Address): Transaction status address. It exists on each row of records generated by a transaction operation. Through it, the status information of the transaction that modified the row can be found.

[0058] TCN: Transaction commit number, a globally unique incrementing number assigned when a transaction is committed.

[0059] Undo Reservation: The Purge mechanism of MySQL is to push forward as much as possible and in a timely manner. Undo Reservation is a mechanism that tries to block the Purge according to a certain strategy to retain more historical version data.

[0060] It should be noted that MySQL is one of the most popular database management systems, with a large user base and a complete community ecosystem. However, many users may make some mistakes when operating MySQL databases online. Common examples include update operations or delete statements without restrictions or specifying incorrect restrictions, which can cause data to be destroyed or discarded due to human errors. Especially if the operation is on important configuration information, it will seriously affect the operation of the database. At this time, the DBA often needs to quickly roll back the data for recovery.

[0061] However, MySQL tries its best and promptly to clean up data that is no longer needed for querying, so MySQL actually does not have the ability to save and search for past historical version data (PS: This specifically refers to historical version data that is not queried by the current read transaction. If the historical version is still needed by the current query, MySQL can ensure that this data will not be cleaned up). That is, MySQL's Purge system is responsible for cleaning up historical version data that is no longer needed in Undo. The current promotion strategy of MySQL's Purge system is to try its best and promptly, resulting in the possibility that historical version data will be cleaned up immediately once it is no longer needed. Therefore, in this case, the measures that the DBA can take are very limited. In the worst case, the entire database may even have to be rebuilt, which will cause the database to be unavailable for a long time.

[0062] When data is lost or damaged due to a user's misoperation, if the data version before the misoperation can be checked back, the data can be quickly restored. Although MySQL's Undo saves all historical versions of the data, it is difficult for users to retrieve these historical versions through Undo. The main reasons are: these historical versions of data will be cleaned up in time by the Purge system, causing users to permanently lose the historical versions before the misoperation; the historical versions of the data do not have timestamp information, that is, if the user needs to find the data at 10:00, it is impossible to know which historical versions were generated before 10:00 and which historical versions were generated after 10:00 just from Undo itself.

[0063] Currently, the flashback function of MySQL requires the use of Binlog. Binlog is a logical log generated by MySQL, which records all operations that occur on the database and is widely used to build a disaster recovery cluster with one master and one backup. Through MySQL supporting tools, such as MySQLBinlog, it is easy to parse the operations that MySQL has performed in the past. Specifically, by parsing the Binlog log, you can perceive the operations that have been performed in the past, and then generate the opposite operation statement and execute it again on the MySQL database to achieve the purpose of flashback or rollback.

[0064] However, the biggest disadvantage of the above solution is that it strongly relies on Binlog logs, which severely limits its scope of use. In fact, some MySQL instances do not have the Binlog generation function enabled. Secondly, the Binlog Flashback method has complex operation steps, is error-prone and time-consuming. In addition, restoring using backup sets requires additional resources, and if the database is large, the time is very uncontrollable. For the above reasons, MySQL's flashback function is not widely used.

[0065] There is no good solution for the above situation in the MySQL ecosystem. In the most serious cases, the entire database may even need to be rebuilt to restore data, causing the database to be unavailable for a long time. Therefore, an embodiment of this specification proposes a flashback query solution based on the Lizard transaction system TCN, which uses the capabilities of MySQL Undo and the Lizard transaction system, introduces the Undo Reservation mechanism, provides users with the ability of flashback query, and persists transaction submission time and other information, allowing users to check back to data at a certain point in the past in time, so that the database can be quickly rolled back to a certain version in the past according to the table dimension, and the data can be rolled back to save the database.

[0066] In this specification, a data storage method is provided. This specification also relates to a data query method, a data storage device, a data query device, a computing device, and a computer-readable storage medium, which are described in detail one by one in the following embodiments.

[0067] See also Figure 1 , Figure 1 A flow chart of a data storage method provided according to an embodiment of the present specification is shown. The data storage method can be applied to a database and specifically includes the following steps.

[0068] Step 102: Receive a start request for a target transaction, wherein the target transaction is an operation set for performing data operations on target data.

[0069] The target data is the data in the database that the user wants to operate on, and the data operation can be modification, deletion, addition, etc. The target transaction refers to a collection of a series of data operations on the target data.

[0070] In practical applications, a transaction generally refers to something to be done or done. In computer terms, it refers to a program execution unit that accesses and possibly updates various data items in a database. Transactions are usually caused by the execution of user programs written in high-level database manipulation languages ​​or programming languages ​​(such as SQL, C++, or Java), and are defined by statements such as begintransaction and endtransaction (or function calls). A transaction consists of all operations performed between the start of a transaction and the end of a transaction, that is, a transaction is a collection of a series of strict operations in a database system. From the user's perspective, generally speaking, the begin statement marks the start of a transaction, and the commit statement commits the transaction and completes the transaction.

[0071] It should be noted that when a user wants to perform a data operation on data in a database, a corresponding target transaction can be started. At this time, a start request of the target transaction can be received, and the start request is used to instruct the execution of each data operation included in the target transaction.

[0072] Step 104: In response to the start request, a corresponding transaction information row is allocated to the target transaction in the transaction description information table, and the address of the transaction information row is recorded in the transaction operation record, wherein the transaction operation record is a record generated for each data operation included in the target transaction.

[0073] It should be noted that the transaction description information table may include transaction description information of each transaction, and the transaction description information may be various information related to the transaction, such as the transaction description information may include the active state of the transaction, the operation information of each data operation, the unique identification number of the transaction, the version mark and other information related to the transaction. Among them, the active state of the transaction may be an active transaction (Active Trx) or a committed transaction; the operation information of each data operation may include information of each data operation performed on the target data; the unique identification number of the transaction may refer to the Trx ID, which is a globally unique incrementing number assigned when the transaction is started; the version mark may be a transaction commit number (TCN), which is a globally unique incrementing number assigned when the transaction is committed, to indicate the commit order of the transaction, or it may also be the transaction commit time, etc.

[0074] In actual applications, Lizard can persist transaction status information, so with the help of the capabilities of the Lizard transaction system, a transaction description information table (TransactionTable) is introduced to persist the transaction description information related to the target transaction. In one embodiment of this specification, when the target transaction is started, a transaction information row (Transaction Slot) will be assigned to the target transaction on the Transaction Table, and the address of the transaction information row can also be recorded in the transaction operation record, so that the transaction description information of the target transaction can be persisted and saved in the transaction information row assigned to it in the transaction description information table, and the corresponding transaction information can be found in the transaction description information table based on the address recorded in the transaction operation record.

[0075] In an optional implementation of this embodiment, the corresponding address may be recorded in the transaction operation record by adding an address field, that is, the address of the transaction information row is recorded in the transaction operation record. The specific implementation process may be as follows:

[0076] Generate corresponding transaction operation records for each data operation included in the target transaction;

[0077] An address field is added to the transaction operation record, wherein the address field is used to record the address of the transaction information row corresponding to the target transaction in the transaction description information table.

[0078] The address of the transaction information row corresponding to the target transaction in the transaction description information table may be TSA (Transaction Status Address), which may be used to indicate in which row of the transaction description table the transaction description information of the target transaction is stored.

[0079] It should be noted that the target transaction can be an operation set for performing data operations on the target data, that is, the target transaction includes multiple data operations on the target data, and when each data operation is executed, a corresponding transaction operation record can be generated. Therefore, the address of the transaction information row corresponding to the target transaction in the transaction description information table can be recorded in the transaction operation record generated by each data operation included in the target transaction, which is convenient for subsequent query. In other words, the transaction operation record corresponding to each data operation included in the target transaction has the same address recorded, and all point to the transaction information row corresponding to the target transaction in the transaction description information table.

[0080] In actual applications, in addition to the two system fields of Trx ID field and Rollptr field, transaction operation records can also introduce two additional system fields, version tag field and TSA field. Among them, the version tag field can be TCN, which indicates the submission order of the transaction, or it can be the timestamp of the transaction submission. In addition, the TSA field records the address of the Transaction Slot corresponding to the target transaction corresponding to the transaction operation record, which is convenient for finding the required transaction information based on the Transaction Slot corresponding to the address in the transaction description information table during subsequent queries.

[0081] In one embodiment of the present specification, the address of the transaction information row allocated to the target transaction in the transaction description information table can be recorded in the transaction operation record, so that the corresponding transaction information can be found in the transaction description information table based on the address recorded in the transaction operation record, and then it is convenient to directly query the transaction description information table and the historical data record for the relevant transaction information of the required historical version data based on a simple query statement. In the event of a user's erroneous operation, accurate historical version information can be quickly queried for recovery, which greatly reduces the complexity of use and allows users to better use and manage the database without worrying about data damage caused by erroneous operations, thereby improving the product strength of the database.

[0082] Step 106: In response to the commit operation of the target transaction, the transaction description information of the target transaction is backfilled into the transaction information row.

[0083] It should be noted that after all data operations included in the target transaction are executed, the target transaction can be submitted through the commit operation, and the target transaction is completed after it is submitted. Therefore, when the commit operation of the target transaction is received, it means that all data operations included in the target transaction are executed, that is, the target transaction is completed. At this time, the transaction description information of the target transaction can be filled back into the transaction information row allocated to the target transaction in the transaction description information table, so that the transaction description information of the target transaction can be persistently stored in the transaction description information table for subsequent query.

[0084] In one embodiment of the present specification, the capabilities of the Lizard transaction system are utilized to persist the transaction description information of the target transaction, such as the transaction commit number or transaction commit time, and provide the ability to trace back from the transaction operation record itself to the related transaction information when the record was generated, laying the foundation for subsequent flashback queries.

[0085] In an optional implementation of this embodiment, corresponding cleaning rules may be pre-set for historical data records, that is, the data storage method may further include:

[0086] Get preset cleanup rules that are pre-set for historical data records;

[0087] Based on the preset cleaning rule, the data to be cleaned in the historical data record is determined and cleaned.

[0088] Specifically, the historical data record may be a record storing historical versions of database data, such as Undo. Historical versions of database data are stored in Undo. Through Undo, users can query past versions of data or roll back data to a certain historical version.

[0089] It should be noted that the Undo Reservation mechanism can be introduced to block the advancement of Purge as much as possible according to a certain strategy, so as to achieve a mechanism to retain more historical version data. In other words, the preset cleanup rules can be customized in advance for Undo (historical data records), so that the cleanup of historical version data in Undo can be independent of data query, that is, data that is not currently queried can also be stored in Undo, thereby retaining more historical version data for subsequent data queries, so that the data in the database can be rolled back to a certain historical version.

[0090] In actual applications, the Undo Reservation mechanism is introduced, which can block the advancement of the Purge system in MySQL, so that historical version data can be retained in Undo for a long enough period of time, so that users can retrieve the data version before the erroneous operation when an error occurs. However, if all historical version data is retained, the Undo space will expand very quickly. Therefore, users can adjust the degree to which Undo Reservation blocks the Purge system according to actual needs, that is, they can pre-set cleanup rules and clean up the data in Undo on a regular basis. The setting of preset cleanup rules can comprehensively consider two dimensions: time and space.

[0091] In one embodiment of the present specification, an Undo Reservation mechanism is introduced, which takes into account the dimensions of time and space, pre-sets cleaning rules, blocks the advancement of the Purge system, and allows historical version data to be retained in Undo as needed. In this way, when the user makes an erroneous operation, accurate historical version information can be quickly queried for recovery, greatly reducing the complexity of use, allowing users to better use and manage the database without worrying about data damage caused by erroneous operations, thereby improving the product strength of the database.

[0092] In an optional implementation of this embodiment, the data in the historical data records may be cleaned based on space, that is, based on a preset cleaning rule, the data to be cleaned in the historical data records is determined and cleaned. The specific implementation process may be as follows:

[0093] Determining occupied space in the historical data record;

[0094] Determining whether the occupied space exceeds a space threshold;

[0095] If the space threshold is exceeded, a preset number of historical version information with a version mark at the front in the historical data record is cleared.

[0096] Among them, the occupied space is the space occupied by the historical version information stored in the historical data record; the space threshold may refer to a pre-set threshold, which is used to determine whether there is too much historical version information stored in the historical data record, such as the space threshold may be 10G, 15G, 20G, etc.; the preset value may refer to the pre-set number of historical version information that needs to be cleaned up, such as the preset value may be 100, 500, 1000, etc.

[0097] It should be noted that the preset cleanup rule can be to clean up the data to be cleaned up in the historical data record based on the occupied space. At this time, the occupied space in the historical data record can be determined first, that is, the space occupied by the historical version information recorded in the historical data record. If the occupied space is greater than the space threshold, it means that too much historical version information is stored in the historical data record. The preset number of historical version information with the previous version mark in the historical data record can be cleaned up, that is, the older historical version information in the historical data record is cleaned up first. For example, the user can require that the historical version information can be kept as long as the Undo space does not exceed 10G. If the update volume of a database within a year is very small, the historical data from one year ago can be retrieved later through the flashback query function.

[0098] In addition, in addition to the above-mentioned cleaning of the historical version information with a preset number of version marks in front of the historical data records, a mark threshold can also be pre-set to clean up the historical version information in the historical data records with a version mark less than the mark threshold, such as cleaning up the historical version information in the historical data records with a TCN less than 80.

[0099] In another possible implementation, the data in the historical data records may be cleaned up based on time, that is, based on a preset cleaning rule, the data to be cleaned up in the historical data records may be determined and cleaned up. The specific implementation process may also be as follows:

[0100] Determine the earliest historical version information according to the timestamp of each historical version information in the historical data record;

[0101] Determine the time difference between the timestamp of the earliest historical version information and the current time;

[0102] When the time difference exceeds a difference threshold, historical version information earlier than the time threshold in the historical data record is cleared.

[0103] The difference threshold may refer to a preset threshold used to determine whether the earliest historical version information in the historical data record is too old, such as a difference threshold of 1 day, 1 month, 1 year, etc. The time threshold may refer to a preset threshold used to determine which historical version information in the historical data record is older and needs to be cleaned up, such as a time threshold of XX month XX day, XX year, etc. Of course, in actual applications, a preset number of historical version information with a version mark at the front in the historical data record may also be cleaned up, and this description embodiment does not specifically limit the cleaning process.

[0104] An embodiment of the present specification provides a data storage method, which can persist the transaction description information of the target transaction in a transaction description information table. Subsequently, with the help of the persistently stored transaction description information and the historical version information retained in the historical data record, the transaction description information table and the historical data record can be used to directly query the relevant transaction information of the required historical version data based on a simple query statement. In the event of a user's erroneous operation, the accurate historical version information can be quickly queried for recovery without relying on or parsing logs, thus saving the overhead of constructing reverse operations and greatly reducing the complexity of use. This allows users to better use and manage the database without worrying about data damage caused by erroneous operations, thereby improving the product strength of the database.

[0105] See also Figure 2 , Figure 2 A flow chart of a data query method provided according to an embodiment of the present specification is shown. The data query method can be applied to a database and specifically includes the following steps.

[0106] Step 202: Receive a data query request, wherein the data query request carries a query user identifier and a tag of a version to be queried.

[0107] It should be noted that the data query request may refer to a request initiated by a user for querying the required historical version information, such as a Flash back Query request. Specifically, the data query request may carry a query user identifier and a version tag to be queried, wherein the query user identifier may refer to an identifier that can obtain transaction information related to the user who initiated the query request, which may be a user name or a table name of a table storing transaction operation records corresponding to the user, and based on the query user identifier, each transaction operation record corresponding to the transaction executed by the user may be obtained later; the version tag to be queried may refer to a tag of the historical version information that the user wants to query, such as a transaction commit number (TCN) or a transaction commit time.

[0108] In actual applications, if the mark to be queried is a transaction commit number, then before initiating a data query request, the user can also determine the transaction commit number of the historical version information that he wants to obtain based on the mapping relationship table between the operation information and the transaction commit number, and then the user can input a flashback query statement based on the determined transaction commit number to initiate the data query request. Among them, the mapping relationship table between the operation information and the transaction commit number can show the user the transaction commit number corresponding to each data operation after execution or each transaction after submission, so that the user can determine the transaction commit number of the historical version information that he wants to obtain based on the mapping relationship table.

[0109] For example, the flashback query statement input by the user may be SELECT*FROM t1 AS OF TCN 150, where t1 may represent the table name of the table storing the transaction operation records corresponding to the user, and SELECT*FROM t1 indicates returning each transaction operation record in the t1 table, that is, returning the transaction operation records of each transaction executed by the user. AS OF TCN 150 indicates that the version that the user wants to query (that is, the version mark to be queried) is TCN equal to 150.

[0110] In addition, the database can provide multi-version concurrency control (MVCC). Under the MVCC mechanism, read operations reading historical versions and write operations can be executed concurrently, that is, initiating data query requests and write operations can be executed concurrently without blocking write operations.

[0111] In one embodiment of the present specification, a data query request initiated by a user can be received, and the data query request carries a query user identifier and a version tag to be queried. Subsequently, transaction information related to the user can be obtained based on the query user identifier. In this way, a flashback query function is provided, and the user can check back the desired historical version data through a simple database operation statement. The user does not need to change the usage habits and the experience is smooth.

[0112] In an optional implementation of this embodiment, before receiving the data query request, the following may also be included:

[0113] receiving a start request of a target transaction, wherein the target transaction is an operation set for performing data operations on target data;

[0114] In response to the start request, a corresponding transaction information row is allocated to the target transaction in the transaction description information table, and the address of the transaction information row is recorded in a transaction operation record, wherein the transaction operation record is a record generated for each data operation included in the target transaction;

[0115] In response to a commit operation of the target transaction, the transaction description information of the target transaction is backfilled into the transaction information row.

[0116] It should be noted that the above process of persistently storing transaction description information is the same as the above process of persistently storing transaction description information. Figure 1 The data storage process is the same as shown above. Figure 1 The detailed contents shown in the embodiments of this specification will not be repeated here.

[0117] In an optional implementation of this embodiment, the corresponding address may be recorded in the transaction operation record by adding an address field, that is, the address of the transaction information row is recorded in the transaction operation record. The specific implementation process may be as follows:

[0118] For each data operation included in the target transaction, generating a corresponding transaction operation record;

[0119] An address field is added to the transaction operation record, wherein the address field is used to record the address of the transaction information row corresponding to the target transaction in the transaction description information table.

[0120] It should be noted that the target transaction can be an operation set for performing data operations on the target data, that is, the target transaction includes multiple data operations on the target data, and when each data operation is executed, a corresponding transaction operation record can be generated. Therefore, the address of the transaction information row corresponding to the target transaction in the transaction description information table can be recorded in the transaction operation record generated by each data operation included in the target transaction, which is convenient for subsequent query. In other words, the transaction operation record corresponding to each data operation included in the target transaction has the same address recorded, and all point to the transaction information row corresponding to the target transaction in the transaction description information table.

[0121] In one embodiment of the present specification, the address of the transaction information row allocated to the target transaction in the transaction description information table can be recorded in the transaction operation record, so that the corresponding transaction information can be found in the transaction description information table based on the address recorded in the transaction operation record, and then it is convenient to directly query the transaction description information table and the historical data record for the relevant transaction information of the required historical version data based on a simple query statement. In the event of a user's erroneous operation, accurate historical version information can be quickly queried for recovery, which greatly reduces the complexity of use and allows users to better use and manage the database without worrying about data damage caused by erroneous operations, thereby improving the product strength of the database.

[0122] In an optional implementation of this embodiment, corresponding cleaning rules may be pre-set for historical data records, that is, before receiving the data query request, the following may also be included:

[0123] Get preset cleanup rules that are pre-set for historical data records;

[0124] Based on the preset cleaning rule, the data to be cleaned in the historical data record is determined and cleaned.

[0125] In one embodiment of the present specification, an Undo Reservation mechanism is introduced, which takes into account the dimensions of time and space, pre-sets cleaning rules, blocks the advancement of the Purge system, and allows historical version data to be retained in Undo as needed. In this way, when the user makes an erroneous operation, accurate historical version information can be quickly queried for recovery, greatly reducing the complexity of use, allowing users to better use and manage the database without worrying about data damage caused by erroneous operations, thereby improving the product strength of the database.

[0126] In an optional implementation of this embodiment, the data in the historical data record may be cleaned based on the space, that is, based on the preset cleaning rule, the data to be cleaned in the historical data record is determined and cleaned. The specific implementation process may be as follows:

[0127] Determining occupied space in the historical data record;

[0128] Determining whether the occupied space exceeds a space threshold;

[0129] If the space threshold is exceeded, a preset number of historical version information with a version mark at the front in the historical data record is cleared.

[0130] It should be noted that the preset cleanup rule can be to clean up the data to be cleaned up in the historical data record based on the occupied space. At this time, the occupied space in the historical data record can be determined first, that is, the space occupied by the historical version information recorded in the historical data record. If the occupied space is greater than the space threshold, it means that too much historical version information is stored in the historical data record. The preset number of historical version information with the previous version mark in the historical data record can be cleaned up, that is, the older historical version information in the historical data record is cleaned up first. For example, the user can require that the historical version information can be kept as long as the Undo space does not exceed 10G. If the update volume of a database within a year is very small, the historical data from one year ago can be retrieved later through the flashback query function.

[0131] Step 204: Obtain the target transaction information row address included in the transaction operation record corresponding to the query user identifier.

[0132] It should be noted that based on the query user identifier, the transaction operation record corresponding to the user who initiated the query request can be obtained, and then the target transaction information row address can be obtained from the transaction operation record. Subsequently, based on the target transaction information row address, the corresponding transaction information can be found in the transaction description information table.

[0133] In an optional implementation of this embodiment, when initiating a data query request, the user may also specify the range of transaction operation records to be queried, that is, the data query request may also carry a query parameter. In this case, the target transaction information row address is obtained in the transaction operation record corresponding to the query user identifier. The specific implementation process may be as follows:

[0134] Obtaining the transaction operation record corresponding to the query user identifier;

[0135] Scan the transaction operation record to determine the target transaction record corresponding to the query parameter;

[0136] Comparing the version mark in the target transaction record with the version mark to be queried;

[0137] When the version mark in the target transaction record is inconsistent with the version mark to be queried, the target transaction information row address is obtained from the target transaction record.

[0138] In actual applications, the query parameter may refer to the range of transaction operation records to be queried, which is specified by the user when initiating a data query request. For example, the query parameter may be the Trx ID (unique identification number of the transaction) range corresponding to the transaction operation record, such as specifying the query parameter as Trx ID is 50-100; or, the query parameter may also be the PK (primary key field) range of the transaction operation record, and each transaction operation record has a unique PK, such as specifying the query parameter as PK is X1-X5; or, the query parameter may also be the number range of the transaction operation record, such as executing the query parameter as the transaction operation record number 1-10.

[0139] It should be noted that when the data query request carries query parameters, you can first obtain all transaction operation records corresponding to the query user identifier, and then scan the obtained transaction operation records to determine the target transaction record corresponding to the query parameters. Then, you can first compare the version mark in the target transaction record with the version mark to be queried. When the version mark in the target transaction record is inconsistent with the version mark to be queried, it means that the determined target transaction record is not the historical version information that the user wants to query. Therefore, at this time, you can obtain the target transaction information row address from the target transaction record, that is, the storage address of the transaction description information of the target transaction in the transaction description information table, so as to facilitate subsequent searches in the transaction description information table, thereby using the persistently stored transaction description information to query the required historical version information.

[0140] Step 206: According to the target transaction information row address, query the corresponding reference transaction information in the transaction description information table, wherein the reference transaction information includes a version mark.

[0141] It should be noted that the target transaction information row address can indicate the storage address of the transaction description information of the target transaction in the transaction description information table. Therefore, after obtaining the target transaction information row address, the corresponding reference transaction information can be queried in the transaction description information table according to the target transaction information row address. The reference transaction information is the transaction description information recorded in the transaction information row indicated by the target transaction information row address in the transaction description information. The reference transaction information may include a version mark.

[0142] In an optional implementation of this embodiment, after obtaining the reference transaction information from the transaction description information table, it is also possible to determine whether the obtained reference transaction information is the historical version information that the user wants to query, that is, according to the target transaction information row address, after querying the corresponding reference transaction information in the transaction description information table, it may also include:

[0143] Comparing the version mark in the reference transaction information with the version mark to be queried;

[0144] When the version mark in the reference transaction information is consistent with the version mark to be queried, the reference transaction information is returned.

[0145] It should be noted that after obtaining the reference transaction information from the transaction description information table, the version mark in the reference transaction information can be compared with the version mark to be queried. When the version mark in the reference transaction information is consistent with the version mark to be queried, it means that the reference transaction information obtained from the transaction description information table is the historical version information that the user wants to query. At this time, the reference transaction information can be directly returned to the user.

[0146] In actual applications, the MySQL view mechanism ReadView can be upgraded to Vision, and the mechanism of using Trx id to make visibility judgment on ReadView can be discarded, and the version mark of the transaction (TCN or transaction commit timestamp) can be used as the visibility judgment mechanism. In this way, through the Lizard transaction system, the transaction description information (such as the version mark of the transaction, TCN or transaction commit timestamp, etc.) can be persisted to the Transaction Table. When the user specifies a version mark in the past, the historical version information of the version mark in the database can be requested to be queried. When the query request is sent to the storage engine, the Transaction Slot of the target transaction in the Transaction Table can be found through the TSA field on the transaction operation record, and finally the reference transaction information when the transaction operation record is generated can be found. By simply comparing the version mark in the reference transaction information with the version mark to be queried provided by the user, it can be determined whether the reference transaction information is the historical version information required for this flashback query.

[0147] In the embodiments of the present specification, a data query request initiated by a user can be received, and then the target transaction information row address included in the transaction operation record corresponding to the user can be obtained. Based on the target transaction information row address, the corresponding reference transaction information can be found in the transaction description information table. Through a simple comparison, it is determined whether the reference transaction information is the transaction information required by the user query. If so, the reference transaction information is directly returned. With the help of the persistently stored transaction description information, the transaction description information table can be directly queried for the relevant transaction information of the required historical version data based on a simple query statement. In the event that the user performs an erroneous operation, the accurate historical version information can be quickly queried for recovery without relying on and parsing logs, saving the overhead of constructing reverse operations, greatly reducing the complexity of use, allowing users to better use and manage the database without worrying about data damage caused by erroneous operations, and improving the product strength of the database.

[0148] Step 208: When the version mark in the reference transaction information is inconsistent with the version mark to be queried, search for target transaction information corresponding to the version mark to be queried in the historical data record.

[0149] It should be noted that, when the version mark in the reference transaction information is inconsistent with the version mark to be queried, it means that the reference transaction information obtained from the transaction description information table is not the historical version information that the user wants to query. Since as much historical version information as possible is stored in the historical data record, when the version mark in the reference transaction information is inconsistent with the version mark to be queried, you can continue to search for the target transaction information corresponding to the version mark to be queried in the historical data record.

[0150] In an optional implementation of this embodiment, the previous historical version information can be searched forward along the historical link of the historical data record, and it can be determined whether the historical version information is the historical version information that the user needs to query, that is, the target transaction information corresponding to the version mark to be queried is searched in the historical data record. The specific implementation process can be as follows:

[0151] Searching for the previous historical version information of the reference transaction information in the historical data record;

[0152] Compare the version mark in the historical version information with the version mark to be queried to see if they are consistent;

[0153] When the version mark in the historical version information is consistent with the version mark to be queried, the historical version information is used as the target transaction information corresponding to the version mark to be queried.

[0154] In actual applications, the reference transaction information may include a Trx ID field. Based on the unique identification number of the transaction recorded in the Trx ID field, the previous historical version information of the TrxID in the reference transaction information can be found in the historical data record through a pointer in a programming language, such as finding the previous historical version information of the reference transaction information in the historical data record based on a rollback segment pointer (Rollptr). After obtaining the previous historical version information, the version mark in the historical version information can be compared with the version mark to be queried to see if they are consistent. If the version mark in the historical version information is consistent with the version mark to be queried, it means that the historical version information obtained from the historical data record is the historical version information that the user wants to query. At this time, the historical version information is returned to the user as the target transaction information corresponding to the version mark to be queried.

[0155] For example, Figure 3 is a schematic diagram of a data query link provided by an embodiment of this specification, such as Figure 3As shown, the user inputs the query statement: SELECT*FROM t1 AS OF TCN 150 to initiate a flashback query request. Based on the query parameter t1 carried in the flashback query request, a row of target transaction records is scanned from each transaction operation record (RecordFormat), and the target transaction record includes "PK, TCN: NULL, TSA, Trx_ID: 101, Rollptr, UserCols", where PK represents the primary key field, TCN represents the transaction commit number, NULL represents an invalid value, TSA represents the transaction information row address, Trx_ID represents the transaction unique identification number 101, Rollptr represents the rollback segment pointer, and User Cols represents the user ID.

[0156] Since the TCN in the scanned target transaction record is an invalid value, the transaction information description table (Transaction Table) is checked through the TSA in the target transaction record to obtain the corresponding reference transaction information, such as Figure 3 As shown, TCN=200 in the reference transaction information is not the version TCN=150 required for this flashback query. Therefore, the previous historical version in the historical data record (Undo Previous Version) is found through Rollptr. The historical version includes "PK, TCN: 150, TSA, Trx_ID: 100, Rollptr, User Cols". It is found that TCN=150 in the historical version information found. Obviously, the historical version information is required for this flashback query, and the historical version information is returned to the user.

[0157] In an optional implementation of this embodiment, when the version mark in the historical version information is inconsistent with the version mark to be queried, the previous historical version information can be searched forward in sequence along the historical link of the historical data record, and it can be determined whether it is the historical version information that the user needs to query, until the last historical version information in the historical data record is queried, that is, after comparing whether the version mark in the historical version information is consistent with the version mark to be queried, the following can also be included:

[0158] When the version mark in the historical version information is inconsistent with the version mark to be queried, the historical version information is used as the reference transaction information, and the operation step of searching the historical data record for the previous historical version information of the reference transaction information is returned;

[0159] When the version mark of the last historical version information in the historical data record is inconsistent with the version mark to be queried, a query failure reminder is returned.

[0160] In actual applications, when the version mark in the previous historical version information is inconsistent with the version mark to be queried, it means that the previous historical version information queried in the historical data record is not the historical version information that the user needs to query. Therefore, the previous historical version information can be used as reference transaction information, and the operation steps of searching the previous historical version information of the reference transaction information in the historical data record are returned to execute, and the version mark in the historical version information found is compared with the version mark to be queried for consistency, until the version mark of the last historical version information in the historical data record is inconsistent with the version mark to be queried, and a query failure reminder is returned.

[0161] It should be noted that Flashback Query cannot always find the historical version information required by the user from the historical data records. If the historical version information that Flashback Query wants to query has been cleared by the Purge system, the historical version information required by the user cannot be queried. At this time, a query failure reminder can be returned to the user, such as a "Snapshot too old" error reminder.

[0162] Using the above example, Figure 3 As shown in the figure, suppose the user enters the query statement: SELECT * FROM t1 AS OF TCN 60 to initiate a flashback query request. If the historical version information that the query request wants to query is not found along the historical version link in the historical data record (Undo Previous Version), it means that the historical version information has been cleared by the Purge system, and the "ERROR: Snapshot too old" error is returned.

[0163] An embodiment of the present specification provides a data query method, which can receive a data query request initiated by a user, and then obtain the target transaction information row address included in the transaction operation record corresponding to the user, and based on the target transaction information row address, the corresponding transaction information can be found in the transaction description information table, and through a simple comparison, it is determined whether the transaction information is the transaction information required by the user query, and if not, the historical data record can be further traced back to find the relevant transaction information of the historical version data required by the user in the historical data record. In this way, the transaction description information of the target transaction can be persistently saved in the transaction description information table, and subsequently, with the help of the persistently stored transaction description information and the historical version information retained in the historical data record, the relevant transaction information of the required historical version data can be directly queried in the transaction description information table and the historical data record based on a simple query statement. In the case of a user's misoperation, the accurate historical version information can be quickly queried for recovery, without relying on and parsing logs, saving the overhead of constructing reverse operations, greatly reducing the complexity of use, allowing users to better use and manage the database, without worrying about data damage caused by misoperation, and improving the product strength of the database.

[0164] Corresponding to the above method embodiment, this specification also provides a data storage device embodiment, Figure 4 FIG. 1 is a schematic diagram showing a structure of a data storage device provided by an embodiment of the present specification. Figure 4 As shown, the device comprises:

[0165] A first receiving module 402 is configured to receive a start request of a target transaction, wherein the target transaction is an operation set for performing data operations on target data;

[0166] The recording module 404 is configured to, in response to the start request, allocate a corresponding transaction information row for the target transaction in the transaction description information table, and record the address of the transaction information row in a transaction operation record, wherein the transaction operation record is a record generated for each data operation included in the target transaction;

[0167] The backfill module 406 is configured to, in response to a commit operation of the target transaction, backfill the transaction description information of the target transaction into the transaction information row.

[0168] Optionally, the recording module 404 is further configured to:

[0169] For each data operation included in the target transaction, generating a corresponding transaction operation record;

[0170] An address field is added to the transaction operation record, wherein the address field is used to record the address of the transaction information row corresponding to the target transaction in the transaction description information table.

[0171] Optionally, the data storage device further includes a cleaning module configured to:

[0172] Get preset cleanup rules that are pre-set for historical data records;

[0173] Based on the preset cleaning rule, the data to be cleaned in the historical data record is determined and cleaned.

[0174] Optionally, the cleaning module is further configured to:

[0175] Determining occupied space in the historical data record;

[0176] Determining whether the occupied space exceeds a space threshold;

[0177] If the space threshold is exceeded, a preset number of historical version information with a version mark at the front in the historical data record is cleared.

[0178] An embodiment of the present specification provides a data storage device that can persistently save the transaction description information of the target transaction in a transaction description information table. Subsequently, with the help of the persistently stored transaction description information and the historical version information retained in the historical data record, the transaction description information table and the historical data record can be used to directly query the relevant transaction information of the required historical version data based on a simple query statement. In the event of a user's erroneous operation, accurate historical version information can be quickly queried for recovery without relying on or parsing logs, thus saving the overhead of constructing reverse operations and greatly reducing the complexity of use. This allows users to better use and manage the database without worrying about data damage caused by erroneous operations, thereby improving the product strength of the database.

[0179] The above is a schematic scheme of a data storage device of this embodiment. It should be noted that the technical scheme of the data storage device and the technical scheme of the data storage method described above are of the same concept, and the details of the technical scheme of the data storage device that are not described in detail can be found in the description of the technical scheme of the data storage method described above.

[0180] Corresponding to the above method embodiment, this specification also provides a data query device embodiment, Figure 5 FIG. 1 shows a schematic diagram of a data query device provided by an embodiment of the present specification. Figure 5 As shown, the device comprises:

[0181] The second receiving module 502 is configured to receive a data query request, wherein the data query request carries a query user identifier and a to-be-queried version tag;

[0182] An acquisition module 504 is configured to acquire a target transaction information row address included in the transaction operation record corresponding to the query user identifier;

[0183] A query module 506 is configured to query the corresponding reference transaction information in the transaction description information table according to the row address of the target transaction information, wherein the reference transaction information includes a version mark;

[0184] The search module 508 is configured to search for target transaction information corresponding to the version mark to be queried in the historical data record when the version mark in the reference transaction information is inconsistent with the version mark to be queried.

[0185] Optionally, the data query request also carries query parameters; the acquisition module 504 is further configured to:

[0186] Obtaining the transaction operation record corresponding to the query user identifier;

[0187] Scan the transaction operation record to determine the target transaction record corresponding to the query parameter;

[0188] Comparing the version mark in the target transaction record with the version mark to be queried;

[0189] When the version mark in the target transaction record is inconsistent with the version mark to be queried, the target transaction information row address is obtained from the target transaction record.

[0190] Optionally, the search module 508 is further configured to:

[0191] Searching for the previous historical version information of the reference transaction information in the historical data record;

[0192] Compare the version mark in the historical version information with the version mark to be queried to see if they are consistent;

[0193] When the version mark in the historical version information is consistent with the version mark to be queried, the historical version information is used as the target transaction information corresponding to the version mark to be queried.

[0194] Optionally, the search module 508 is further configured to:

[0195] When the version mark in the historical version information is inconsistent with the version mark to be queried, the historical version information is used as the reference transaction information, and the operation step of searching the historical data record for the previous historical version information of the reference transaction information is returned;

[0196] When the version mark of the last historical version information in the historical data record is inconsistent with the version mark to be queried, a query failure reminder is returned.

[0197] Optionally, the data query device further includes a return module configured to:

[0198] Comparing the version mark in the reference transaction information with the version mark to be queried;

[0199] When the version mark in the reference transaction information is consistent with the version mark to be queried, the reference transaction information is returned.

[0200] Optionally, the data query device further includes a response module configured to:

[0201] receiving a start request of a target transaction, wherein the target transaction is an operation set for performing data operations on target data;

[0202] In response to the start request, a corresponding transaction information row is allocated to the target transaction in the transaction description information table, and the address of the transaction information row is recorded in a transaction operation record, wherein the transaction operation record is a record generated for each data operation included in the target transaction;

[0203] In response to a commit operation of the target transaction, the transaction description information of the target transaction is backfilled into the transaction information row.

[0204] Optionally, the response module is further configured as follows:

[0205] For each data operation included in the target transaction, generating a corresponding transaction operation record;

[0206] An address field is added to the transaction operation record, wherein the address field is used to record the address of the transaction information row corresponding to the target transaction in the transaction description information table.

[0207] Optionally, the data query device further includes a cleaning module configured to:

[0208] Get preset cleanup rules that are pre-set for historical data records;

[0209] Based on the preset cleaning rule, the data to be cleaned in the historical data record is determined and cleaned.

[0210] Optionally, the cleaning module is further configured to:

[0211] Determining occupied space in the historical data record;

[0212] Determining whether the occupied space exceeds a space threshold;

[0213] If the space threshold is exceeded, a preset number of historical version information with a version mark at the front in the historical data record is cleared.

[0214] An embodiment of the present specification provides a data query device, which can receive a data query request initiated by a user, and then obtain the target transaction information row address included in the transaction operation record corresponding to the user. Based on the target transaction information row address, the corresponding transaction information can be found in the transaction description information table. Through simple comparison, it is determined whether the transaction information is the transaction information required by the user query. If not, the historical data record can be further traced back to find the relevant transaction information of the historical version data required by the user in the historical data record. In this way, the transaction description information of the target transaction can be persistently saved in the transaction description information table. Subsequently, with the help of the persistently stored transaction description information and the historical version information retained in the historical data record, the relevant transaction information of the required historical version data can be directly queried in the transaction description information table and the historical data record based on a simple query statement. In the case of a user's misoperation, the accurate historical version information can be quickly queried for recovery without relying on and parsing logs, saving the overhead of constructing reverse operations, greatly reducing the complexity of use, allowing users to better use and manage the database without worrying about data damage caused by misoperation, and improving the product strength of the database.

[0215] The above is a schematic scheme of a data query device of this embodiment. It should be noted that the technical scheme of the data query device and the technical scheme of the above data query method belong to the same concept, and the details not described in detail in the technical scheme of the data query device can be referred to the description of the technical scheme of the above data query method.

[0216] Figure 6 The block diagram of a computing device according to an embodiment of the present specification is shown. The components of the computing device 600 include but are not limited to a memory 610 and a processor 620. The processor 620 is connected to the memory 610 via a bus 630, and the database 650 is used to store data.

[0217] The computing device 600 also includes an access device 640 that enables the computing device 600 to communicate via one or more networks 660. Examples of these networks include a public switched telephone network (PSTN), a local area network (LAN), a wide area network (WAN), a personal area network (PAN), or a combination of communication networks such as the Internet. The access device 640 may include one or more of any type of network interface (e.g., a network interface card (NIC)) whether wired or wireless, such as an IEEE 802.11 wireless local area network (WLAN) wireless interface, a World Wide Interoperability for Microwave Access (Wi-MAX) interface, an Ethernet interface, a universal serial bus (USB) interface, a cellular network interface, a Bluetooth interface, a near field communication (NFC) interface, and the like.

[0218] In one embodiment of the present specification, the above components of the computing device 600 and Figure 6 Other components not shown in the figure may also be connected to each other, for example, via a bus. It should be understood that Figure 6 The computing device structure block diagram shown is only for the purpose of illustration, and is not intended to limit the scope of this specification. Those skilled in the art can add or replace other components as needed.

[0219] The computing device 600 may be any type of stationary or mobile computing device, including a mobile computer or mobile computing device (e.g., a tablet computer, a personal digital assistant, a laptop computer, a notebook computer, a netbook, etc.), a mobile phone (e.g., a smart phone), a wearable computing device (e.g., a smart watch, smart glasses, etc.), or other types of mobile devices, or a stationary computing device such as a desktop computer or PC. The computing device 600 may also be a mobile or stationary server.

[0220] The processor 620 is used to execute the following computer executable instructions, which, when executed by the processor, implement the steps of the above-mentioned data storage method or data query method.

[0221] The above is a schematic scheme of a computing device of this embodiment. It should be noted that the technical scheme of the computing device and the technical scheme of the above-mentioned data storage method or data query method belong to the same concept, and the details not described in detail in the technical scheme of the computing device can be referred to the description of the technical scheme of the above-mentioned data storage method or data query method.

[0222] An embodiment of the present specification further provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the steps of the above-mentioned data storage method or data query method.

[0223] The above is a schematic scheme of a computer-readable storage medium of this embodiment. It should be noted that the technical scheme of the storage medium and the technical scheme of the above-mentioned data storage method or data query method belong to the same concept, and the details not described in detail in the technical scheme of the storage medium can be referred to the description of the technical scheme of the above-mentioned data storage method or data query method.

[0224] An embodiment of the present specification further provides a computer program, wherein when the computer program is executed in a computer, the computer is caused to execute the steps of the above-mentioned data storage method or data query method.

[0225] The above is a schematic scheme of a computer program of this embodiment. It should be noted that the technical scheme of the computer program and the technical scheme of the above-mentioned data storage method or data query method belong to the same concept, and the details not described in detail in the technical scheme of the computer program can be referred to the description of the technical scheme of the above-mentioned data storage method or data query method.

[0226] The above is a description of a specific embodiment of the specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recorded in the claims can be performed in an order different from that in the embodiments and still achieve the desired results. In addition, the processes depicted in the drawings do not necessarily require the specific order or continuous order shown to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0227] The computer instructions include computer program codes, which may be in source code form, object code form, executable files or some intermediate forms, etc. The computer-readable medium may include: any entity or device capable of carrying the computer program code, recording medium, USB flash drive, mobile hard disk, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electric carrier signal, telecommunication signal and software distribution medium, etc. It should be noted that the content contained in the computer-readable medium may be appropriately increased or decreased according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, computer-readable media do not include electric carrier signals and telecommunication signals.

[0228] It should be noted that, for the above-mentioned method embodiments, for the sake of simplicity of description, they are all expressed as a series of action combinations, but those skilled in the art should be aware that the embodiments of this specification are not limited by the order of the actions described, because according to the embodiments of this specification, some steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also be aware that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily required by the embodiments of this specification.

[0229] In the above embodiments, the description of each embodiment has its own emphasis. For parts that are not described in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0230] The preferred embodiments of this specification disclosed above are only used to help explain this specification. The optional embodiments do not describe all the details in detail, nor do they limit the invention to only the specific implementation methods described. Obviously, many modifications and changes can be made according to the content of the embodiments of this specification. This specification selects and specifically describes these embodiments in order to better explain the principles and practical applications of the embodiments of this specification, so that technicians in the relevant technical field can well understand and use this specification. This specification is only limited by the claims and their full scope and equivalents.

Claims

1. A data storage method, comprising: receiving a start request of a target transaction, wherein the target transaction is an operation set for performing data operations on target data; In response to the start request, a corresponding transaction information row is allocated to the target transaction in the transaction description information table, and the address of the transaction information row is recorded in the transaction operation record, wherein the transaction operation record is a record generated for each data operation included in the target transaction, the transaction operation record includes a target transaction record, the target transaction record corresponds to a query parameter, the target transaction record includes a version tag and a target transaction information row address, the target transaction information row address indicates a storage address of the transaction description information of the target transaction in the transaction description information table, the transaction description information is persistently stored in the transaction description information table, and the target transaction information row address is used to query the transaction description information of the corresponding historical version in the transaction description information table; In response to a commit operation of the target transaction, the transaction description information of the target transaction is backfilled into the transaction information row.

2. The data storage method according to claim 1, wherein recording the address of the transaction information row in the transaction operation record comprises: For each data operation included in the target transaction, generating a corresponding transaction operation record; An address field is added to the transaction operation record, wherein the address field is used to record the address of the transaction information row corresponding to the target transaction in the transaction description information table.

3. The data storage method according to claim 1, further comprising: Get preset cleanup rules that are pre-set for historical data records; Based on the preset cleaning rule, the data to be cleaned in the historical data record is determined and cleaned.

4. The data storage method according to claim 3, wherein the step of determining and clearing the data to be cleared in the historical data records based on the preset clearing rule comprises: Determining occupied space in the historical data record; Determining whether the occupied space exceeds a space threshold; If the space threshold is exceeded, a preset number of historical version information with a version mark at the front in the historical data record is cleared.

5. A data query method, comprising: Receive a data query request, wherein the data query request carries a query parameter, a query user identifier, and a version tag to be queried; Obtaining the target transaction information row address included in the transaction operation record corresponding to the query user identifier, wherein obtaining the target transaction information row address included in the transaction operation record corresponding to the query user identifier comprises: obtaining the transaction operation record corresponding to the query user identifier; scanning the transaction operation record to determine the target transaction record corresponding to the query parameter; comparing the version mark in the target transaction record with the version mark to be queried; and obtaining the target transaction information row address from the target transaction record when the version mark in the target transaction record is inconsistent with the version mark to be queried; According to the target transaction information row address, query the corresponding reference transaction information in the transaction description information table, wherein the reference transaction information includes a version mark; When the version mark in the reference transaction information is inconsistent with the version mark to be queried, the target transaction information corresponding to the version mark to be queried is searched in the historical data record.

6. The data query method according to claim 5, wherein searching the historical data records for target transaction information corresponding to the version tag to be queried comprises: Searching for the previous historical version information of the reference transaction information in the historical data record; Compare the version mark in the historical version information with the version mark to be queried to see if they are consistent; When the version mark in the historical version information is consistent with the version mark to be queried, the historical version information is used as the target transaction information corresponding to the version mark to be queried.

7. The data query method according to claim 6, after comparing whether the version mark in the historical version information is consistent with the version mark to be queried, further comprising: When the version mark in the historical version information is inconsistent with the version mark to be queried, the historical version information is used as the reference transaction information, and the operation step of searching the historical data record for the previous historical version information of the reference transaction information is returned; When the version mark of the last historical version information in the historical data record is inconsistent with the version mark to be queried, a query failure reminder is returned.

8. The data query method according to claim 5, after searching the transaction description information table for corresponding reference transaction information according to the target transaction information row address, further comprising: Comparing the version mark in the reference transaction information with the version mark to be queried; When the version mark in the reference transaction information is consistent with the version mark to be queried, the reference transaction information is returned.

9. The data query method according to any one of claims 5 to 8, before receiving the data query request: Receive a start request for a target transaction, where: The target transaction is an operation set for performing data operations on target data; In response to the start request, a corresponding transaction information row is allocated to the target transaction in the transaction description information table, and the address of the transaction information row is recorded in a transaction operation record, wherein the transaction operation record is a record generated for each data operation included in the target transaction; In response to a commit operation of the target transaction, the transaction description information of the target transaction is backfilled into the transaction information row.

10. The data query method according to claim 9, wherein recording the address of the transaction information row in the transaction operation record comprises: For each data operation included in the target transaction, generating a corresponding transaction operation record; An address field is added to the transaction operation record, wherein the address field is used to record the address of the transaction information row corresponding to the target transaction in the transaction description information table.

11. The data query method according to any one of claims 5 to 8, before receiving the data query request, further comprising: Get preset cleanup rules that are pre-set for historical data records; Based on the preset cleaning rule, the data to be cleaned in the historical data record is determined and cleaned.

12. The data query method according to claim 11, wherein determining and cleaning the data to be cleaned in the historical data records based on the preset cleaning rule comprises: Determining occupied space in the historical data record; Determining whether the occupied space exceeds a space threshold; If the space threshold is exceeded, a preset number of historical version information with a version mark at the front in the historical data record is cleared.

13. A data storage device, comprising: A first receiving module is configured to receive a start request of a target transaction, wherein the target transaction is an operation set for performing data operations on target data; a recording module, configured to, in response to the start request, allocate a corresponding transaction information row for the target transaction in a transaction description information table, and record the address of the transaction information row in a transaction operation record, wherein the transaction operation record is a record generated for each data operation included in the target transaction, the transaction operation record includes a target transaction record, the target transaction record corresponds to a query parameter, the target transaction record includes a version tag and a target transaction information row address, the target transaction information row address indicates a storage address of the transaction description information of the target transaction in the transaction description information table, the transaction description information is persistently stored in the transaction description information table, and the target transaction information row address is used to query the transaction description information of the corresponding historical version in the transaction description information table; The backfill module is configured to, in response to a commit operation of the target transaction, backfill the transaction description information of the target transaction into the transaction information row.

14. A data query device, comprising: A second receiving module is configured to receive a data query request, wherein the data query request carries a query parameter, a query user identifier, and a version mark to be queried; an acquisition module, configured to acquire a target transaction information row address included in a transaction operation record corresponding to the query user identifier, wherein the acquisition module is further configured to: acquire the transaction operation record corresponding to the query user identifier; scan the transaction operation record to determine a target transaction record corresponding to the query parameter; compare a version mark in the target transaction record with the version mark to be queried; and when the version mark in the target transaction record is inconsistent with the version mark to be queried, acquire the target transaction information row address from the target transaction record; A query module, configured to query corresponding reference transaction information in a transaction description information table according to the row address of the target transaction information, wherein the reference transaction information includes a version mark; The search module is configured to search for target transaction information corresponding to the version mark to be queried in the historical data record when the version mark in the reference transaction information is inconsistent with the version mark to be queried.

15. A computing device comprising: Memory and processor; The memory is used to store computer executable instructions, and the processor is used to execute the computer executable instructions. When the computer executable instructions are executed by the processor, the steps of the data storage method according to any one of claims 1 to 4 or the data query method according to any one of claims 5 to 12 are implemented.

16. A computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the steps of the data storage method according to any one of claims 1 to 4 or the data query method according to any one of claims 5 to 12.

Images