Multi-version concurrent control method, device, equipment and medium for database

Abstract

The present invention provides a multi-version concurrency control method for a database, which can be applied to the field of database technology. The multi-version concurrency control method for a database includes: determining the difference information of a target data row according to a first version and a second version of the target data row, wherein the second version of the target data row is obtained by modifying the first version through a first transaction; writing the difference information as the latest row version information into an uncommitted version data chain corresponding to the target data row, wherein the uncommitted version data chain includes at least one row version information, and the at least one row version information is obtained by executing a first transaction; upon receiving a feedback signal indicating that the first transaction is successfully committed, generating the committed row version information corresponding to the target data row according to the uncommitted version data chain, and writing the committed row version information into the committed row version chain corresponding to the target data row.

Description

Technical Field

[0001] The present invention relates to the field of database technology, and in particular to a method, device, equipment and medium for multi-version concurrency control of a database. Background Art

[0002] Transactions are used to perform a series of operations that are executed as a whole to ensure the integrity and consistency of the database state. In database management, in order to ensure that transactions can read and write databases concurrently, undo logs are usually used to record the state of the data before the transaction begins, so that changes can be undone when a rollback is required. When transaction A updates a certain data, other transactions can obtain the data version before transaction A's operation through the undo log.

[0003] In the process of implementing the concept of the present invention, there are at least the following problems in the related art: the undo log needs to be saved in the form of pages to the external memory to prevent data loss. When other transactions read the data operated by transaction A, the undo log corresponding to the operated data needs to be loaded into the memory in the form of pages. Since the loaded one or more pages include other unnecessary undo logs in addition to the undo logs required for transaction reading, the reading of the required data will be magnified into the reading and writing of the entire page of data, thereby generating a larger granularity of contention, affecting the transaction processing efficiency. Summary of the invention

[0004] In view of the above problems, the present invention provides a method, apparatus, device and medium for multi-version concurrency control of a database.

[0005] According to a first aspect of the present invention, a multi-version concurrency control method for a database is provided, comprising: determining difference information of the target data row according to a first version and a second version of the target data row, wherein the second version of the target data row is obtained by modifying the first version through a first transaction; writing the difference information into an uncommitted version data chain corresponding to the target data row as the latest row version information, wherein the uncommitted version data chain includes at least one row version information, and the at least one row version information is obtained by executing the first transaction; upon receiving a feedback signal indicating that the first transaction is successfully committed, generating committed row version information corresponding to the target data row according to the uncommitted version data chain, and writing the committed row version information into the committed row version chain corresponding to the target data row.

[0006] According to an embodiment of the present invention, the above-mentioned generation of committed row version information corresponding to the above-mentioned target data row based on the above-mentioned uncommitted version data chain includes: in a case where the above-mentioned uncommitted version data chain includes multiple row version information, merging the multiple row version information according to the writing order of the multiple row version information in the above-mentioned uncommitted version data chain; and generating the above-mentioned committed row version information based on the first timestamp of committing the above-mentioned first transaction and the merged row version information.

[0007] According to an embodiment of the present invention, the method further includes: in response to a data read request received from a second transaction to read a target data row, determining at least one row version information to be rolled back from the committed row version chain based on the second timestamp of the second transaction; and performing data rollback based on the row version information to be rolled back and a third version of the target data row to obtain a target data row of a target version, wherein the third version of the target data row is a version obtained after the target transaction is committed, and the target transaction is the latest committed transaction among multiple committed transactions for the target data row.

[0008] According to an embodiment of the present invention, the above-mentioned determining at least one row version information to be rolled back from the above-mentioned committed row version chain based on the second timestamp of the above-mentioned second transaction includes: determining target row version information from the above-mentioned committed row version chain based on the above-mentioned second timestamp, wherein the above-mentioned target row version information is the latest committed row version information in the above-mentioned committed row version chain that is located before the above-mentioned second timestamp; and determining at least one of the above-mentioned row version information to be rolled back based on the above-mentioned target row version information and the above-mentioned committed row version information whose first timestamp is greater than the above-mentioned second timestamp.

[0009] According to an embodiment of the present invention, the above-mentioned writing of the committed row version information into the committed row version chain corresponding to the above-mentioned target data row includes: in the case that there is at least one historical committed row version information in the above-mentioned committed row version chain, updating the read pointer of the above-mentioned committed row version chain to the memory address corresponding to the above-mentioned committed row version information; wherein the above-mentioned historical committed row version information is the row version information committed through at least one transaction; and using the node corresponding to the above-mentioned historical committed row version information as the successor node of the node corresponding to the above-mentioned committed row version information to ensure the storage order of the above-mentioned historical committed row version information and the above-mentioned committed row version information.

[0010] According to an embodiment of the present invention, the method further includes: upon receiving a feedback signal indicating successful submission of the first transaction, obtaining a transaction start timestamp of each active transaction; and cleaning up the committed row version chain based on each transaction start timestamp.

[0011] According to an embodiment of the present invention, the method further includes: determining the modification type of the target data row modified by the first transaction; and generating the committed row version information based on the first timestamp, the modification type, and the merged row version information.

[0012] A second aspect of the present invention provides a multi-version concurrency control device for a database, the device comprising: a difference determination module, for determining difference information of the target data row according to a first version and a second version of the target data row, wherein the second version of the target data row is obtained by modifying the first version through a first transaction; an information writing module, for writing the difference information as the latest row version information into an uncommitted version data chain corresponding to the target data row, wherein the uncommitted version data chain includes at least one row version information, and the at least one row version information is obtained by executing the first transaction; a version writing module, for generating committed row version information corresponding to the target data row according to the uncommitted version data chain upon receiving a feedback signal indicating that the first transaction was successfully committed, and writing the committed row version information into the committed row version chain corresponding to the target data row.

[0013] A third aspect of the present invention provides an electronic device, comprising: one or more processors; a memory for storing one or more computer programs, wherein the one or more processors execute the one or more computer programs to implement the steps of the above method.

[0014] The fourth aspect of the present invention further provides a computer-readable storage medium on which a computer program or instruction is stored, and the steps of the above method are implemented when the above computer program or instruction is executed by a processor.

[0015] According to an embodiment of the present invention, the difference caused by the modification of the target data row by the first transaction when the first transaction is not committed is recorded through the uncommitted version data chain, so that when the first transaction fails to commit, data can be rolled back based on the row version information in the uncommitted version data chain to ensure the atomicity of the first transaction on the target data row. In addition, when the first transaction is successfully committed, the committed row version information corresponding to the target data row is generated according to the uncommitted version data chain, and the committed row version information is written into the committed row version chain corresponding to the target data row to save multiple versions of the target data row. Both the uncommitted version data chain and the committed row version chain are stored in the memory, and there is no need to use undolog to obtain the data of the target data row before modification by different transactions, which reduces the number of times the database management system accesses the external memory, thereby improving the transaction processing efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] The above contents and other objects, features and advantages of the present invention will become more apparent through the following description of the embodiments of the present invention with reference to the accompanying drawings, in which:

[0017] Figure 1 An application scenario diagram of a multi-version concurrency control method, apparatus, device, and medium for a database according to an embodiment of the present invention is shown.

[0018] Figure 2 A flowchart of a multi-version concurrency control method for a database according to an embodiment of the present invention is shown.

[0019] Figure 3 A schematic diagram of an uncommitted version data chain and a committed row version chain according to an embodiment of the present invention is shown.

[0020] Figure 4 A schematic diagram of a committed row version chain according to an embodiment of the present invention is shown.

[0021] Figure 5 A structural block diagram of a multi-version concurrency control device for a database according to an embodiment of the present invention is shown.

[0022] Figure 6 A block diagram of an electronic device suitable for implementing a multi-version concurrency control method for a database according to an embodiment of the present invention is shown. DETAILED DESCRIPTION

[0023] Below, embodiments of the present invention will be described with reference to the accompanying drawings. However, it should be understood that these descriptions are exemplary only and are not intended to limit the scope of the present invention. In the following detailed description, for ease of explanation, many specific details are set forth to provide a comprehensive understanding of embodiments of the present invention. However, it is apparent that one or more embodiments may also be implemented without these specific details. In addition, in the following description, descriptions of known structures and technologies are omitted to avoid unnecessary confusion of concepts of the present invention.

[0024] The terms used herein are only for describing specific embodiments and are not intended to limit the present invention. The terms "comprise", "include", etc. used herein indicate the existence of the features, steps, operations and / or components, but do not exclude the existence or addition of one or more other features, steps, operations or components.

[0025] All terms (including technical and scientific terms) used herein have the meanings commonly understood by those skilled in the art unless otherwise defined. It should be noted that the terms used herein should be interpreted as having a meaning consistent with the context of this specification and should not be interpreted in an idealized or overly rigid manner.

[0026] When using expressions such as "at least one of A, B, and C, etc.", they should generally be interpreted according to the meaning of the expression commonly understood by those skilled in the art (for example, "a system having at least one of A, B, and C" should include but is not limited to a system having A alone, B alone, C alone, A and B, A and C, B and C, and / or A, B, C, etc.).

[0027] In the technical solution of the present invention, the user information (including but not limited to user personal information, user image information, user device information, such as location information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved are all information and data authorized by the user or fully authorized by all parties, and the collection, storage, use, processing, transmission, provision, disclosure and application of the relevant data comply with relevant laws, regulations and standards, take necessary confidentiality measures, do not violate public order and good morals, and provide corresponding operation entrances for users to choose to authorize or refuse.

[0028] In the scenario of using personal information for automated decision-making, the methods, devices, and systems provided by the embodiments of the present invention provide users with corresponding operation portals for users to choose to agree or reject the automated decision-making results; if the user chooses to reject, the expert decision-making process will be entered. The expression "automated decision-making" here refers to the activity of automatically analyzing and evaluating an individual's behavioral habits, interests and hobbies, or economic, health, credit status, etc. through computer programs, and making decisions. The expression "expert decision-making" here refers to the activity of making decisions by people who specialize in a certain field, have specialized experience, knowledge and skills, and have reached a certain level of professionalism.

[0029] In a database system, data is usually stored in external memory in the form of pages, which is the basic unit for data exchange between external memory and internal memory in a database management system. In related technologies, data versions of Multi-Version Concurrency Control (MVCC) are usually saved through undo logs. Since MVCC needs to access the information in the undo log by row, the undo log cannot be simply persisted sequentially like the redo log. Instead, it needs to retain a structure that can be searched by row in the external memory like regular data, such as 8 kilobyte (KB) or 16KB pages. In order to ensure the correct persistence of this structure, the redo log must be recorded for it. All of these increase the system's input and output overhead.

[0030] In addition, in the concurrent scenario of multiple transactions, the page retrieved or modified by a transaction from the external memory includes not only the target data row to be read or modified, but also other data in addition to the target data row to be read or modified. Therefore, under the current reading method, the transaction's access to a certain data row may be magnified into access to the entire page, resulting in contention for a larger data granularity, affecting the overall processing efficiency of concurrent transactions.

[0031] An embodiment of the present invention provides a multi-version concurrency control method for a database, which determines difference information of a target data row according to a first version and a second version of the target data row, wherein the second version of the target data row is obtained by modifying the first version through a first transaction; writes the difference information into an uncommitted version data chain corresponding to the target data row as the latest row version information, wherein the uncommitted version data chain includes at least one row version information, and the at least one row version information is obtained by executing the first transaction; upon receiving a feedback signal indicating that the first transaction is successfully committed, generates committed row version information corresponding to the target data row according to the uncommitted version data chain, and writes the committed row version information into the committed row version chain corresponding to the target data row.

[0032] Figure 1 An application scenario diagram of a multi-version concurrency control method, apparatus, device, and medium for a database according to an embodiment of the present invention is shown.

[0033] like Figure 1 As shown, the application scenario 100 according to this embodiment may include a first terminal device 101, a second terminal device 102, a third terminal device 103, a network 104, and a server 105. The network 104 is used to provide a medium for a communication link between the first terminal device 101, the second terminal device 102, the third terminal device 103, and the server 105. The network 104 may include various connection types, such as wired, wireless communication links, or optical fiber cables, etc.

[0034] The user can use the first terminal device 101, the second terminal device 102, and the third terminal device 103 to interact with the server 105 through the network 104 to receive or send messages, etc. Various communication client applications can be installed on the first terminal device 101, the second terminal device 102, and the third terminal device 103, such as shopping applications, web browser applications, search applications, instant messaging tools, email clients, social platform software, etc. (only for example).

[0035] The first terminal device 101, the second terminal device 102, and the third terminal device 103 may be various electronic devices having display screens and supporting web browsing, including but not limited to smart phones, tablet computers, laptop computers, desktop computers, and the like.

[0036] The server 105 may be a server that provides various services and may include a database management system, such as a background management server (only as an example) that provides support for websites browsed by users using the first terminal device 101, the second terminal device 102, and the third terminal device 103. The background management server may analyze and process the received data such as Structured Query Language (SQL) requests, and feed back the processing results (such as web pages, information, or data obtained or generated according to user requests) to the terminal device.

[0037] It should be noted that the multi-version concurrency control method for a database provided in the embodiment of the present invention can generally be executed by the database management system of the server 105. Accordingly, the multi-version concurrency control device for a database provided in the embodiment of the present invention can generally be arranged in the server 105. The multi-version concurrency control method for a database provided in the embodiment of the present invention can also be executed by a server or server cluster that is different from the server 105 and can communicate with the first terminal device 101, the second terminal device 102, the third terminal device 103 and / or the server 105. Accordingly, the multi-version concurrency control device for a database provided in the embodiment of the present invention can also be arranged in a server or server cluster that is different from the server 105 and can communicate with the first terminal device 101, the second terminal device 102, the third terminal device 103 and / or the server 105.

[0038] It should be understood that Figure 1 The number of the first terminal device, the second terminal device, the third terminal device, the network and the server in the embodiment is only . According to the implementation requirements, there can be any number of the first terminal device, the second terminal device, the third terminal device, the network and the server.

[0039] The following will be based on Figure 1 The scene described by Figure 2~Figure 4 The multi-version concurrency control method of the database in the disclosed embodiment is described in detail.

[0040] Figure 2 A flowchart of a multi-version concurrency control method for a database according to an embodiment of the present invention is shown.

[0041] like Figure 2 As shown, the multi-version concurrency control method of a database in this embodiment includes operations S210 to S230.

[0042] In operation S210 , difference information of a target data row is determined according to a first version and a second version of the target data row.

[0043] The second version of the target data row is obtained by modifying the first version through the first transaction.

[0044] In operation S220, the difference information is written into the uncommitted version data chain corresponding to the target data row as the latest row version information.

[0045] The uncommitted version data chain includes at least one row version information, and the at least one row version information is obtained by executing the first transaction.

[0046] In operation S230, upon receiving a feedback signal indicating successful submission of the first transaction, committed row version information corresponding to the target data row is generated according to the uncommitted version data chain, and the committed row version information is written into the committed row version chain corresponding to the target data row.

[0047] According to an embodiment of the present invention, the target data row may be any one of multiple data rows in a database, and a data row is a single data item in a database table, that is, a horizontal piece of data in a database table. The first version of the target data row is a version before the data row is modified by the first transaction. The second version of the target data row is a version after the data is modified once by the first transaction.

[0048] According to an embodiment of the present invention, the first transaction modifies the target data row, which may include updating the data of the target data row. The information difference of the target data row may be determined with the assistance of a tool or a function in a data analysis and operation library, for example, the difference information between the first version and the second version of the target data row may be determined by a diff() function.

[0049] According to an embodiment of the present invention, the target data row may have two chain-stored data, including an uncommitted version data chain and a committed row version chain, wherein the uncommitted version data chain is used to save the row version information of the target data row during modification, and the committed row version chain is used to save multiple committed row version information of the target data row.

[0050] According to an embodiment of the present invention, during the execution of the first transaction, the first transaction can modify the target data row multiple times, and make data differences between the version of the target data row before each modification and the version after the modification, so as to obtain difference information corresponding to each modification, wherein each difference information records the difference between the target data row before and after the modification. After each modification, the corresponding difference information is used as the latest row version information and written into the committed version chain corresponding to the target data row. For example, if the target data row is modified twice in the first transaction, two row version information are included in the uncommitted version data chain of the target data row.

[0051] According to an embodiment of the present invention, by saving the difference information between the first version and the second version of the target data row, compared with directly storing the modified second version of the target data, the used storage space is smaller, thereby improving the use efficiency of the storage space.

[0052] According to an embodiment of the present invention, after the operations in the first transaction are executed, the data after the transaction execution is completed needs to be persisted to the external memory of the database, and after the transaction is successfully committed, a message or response indicating that the transaction has been successfully committed will be returned, usually a status code or success message, for example, "COMMIT SUCCESS" or a specific status code indicates success.

[0053] According to an embodiment of the present invention, when a feedback signal indicating that the first transaction has been successfully committed is received, committed row version information corresponding to the target data row is generated based on at least one row version information in the uncommitted version data chain, wherein the committed row version information includes data recording the difference between the target data row before the first transaction starts executing and after the first transaction is committed. Before the first transaction is executed, there may be other committed transactions that have modified the target data row, so the committed row version chain may include multiple committed row version information. The committed row version information corresponding to the first transaction is stored in units of data rows to facilitate data search.

[0054] According to an embodiment of the present invention, the difference caused by the modification of the target data row by the first transaction when the first transaction is not committed is recorded through the uncommitted version data chain, so that when the first transaction fails to commit, data can be rolled back based on the row version information in the uncommitted version data chain to ensure the atomicity of the first transaction on the target data row. In addition, when the first transaction is successfully committed, the committed row version information corresponding to the target data row is generated according to the uncommitted version data chain, and the committed row version information is written into the committed row version chain corresponding to the target data row to save multiple versions of the target data row. Both the uncommitted version data chain and the committed row version chain are stored in the memory, and there is no need to use undolog to obtain the data of the target data row before modification by different transactions, which reduces the number of times the database management system accesses the external memory, thereby improving the transaction processing efficiency.

[0055] Figure 3 A schematic diagram of an uncommitted version data chain and a committed row version chain according to an embodiment of the present invention is shown.

[0056] like Figure 3As shown, in the case where the target data row includes an uncommitted version data chain and a committed row version chain, the uncommitted version data chain and the committed row version chain of the target data row can be organized in a tree index. The tree index can include a root node and two child nodes, wherein the root node 310 is the starting index of the tree index; the two child nodes include a child node 320 and a child node 330, respectively, the child node 320 can be the starting address of the uncommitted version data chain, and the child node 330 can be the starting address of the committed row version chain.

[0057] According to an embodiment of the present invention, committed row version information corresponding to a target data row is generated based on an uncommitted version data chain, including: in a case where the uncommitted version data chain includes multiple row version information, merging the multiple row version information according to the writing order of the multiple row version information in the uncommitted version data chain; and generating the committed row version information based on the first timestamp of committing the first transaction and the merged row version information.

[0058] According to an embodiment of the present invention, the row version information is used to store the difference information of a modification made by the first transaction to the target data row. In the case where the first transaction modifies the target row data multiple times, the multiple row version information on the uncommitted version data chain are merged to obtain the difference between the target data row before the first transaction modifies the target data and the target data row after the first transaction modifies the target data.

[0059] According to an embodiment of the present invention, the writing order of multiple row version information on the uncommitted version data chain is written in time order. According to the writing order of the multiple row version information, the order of occurrence of the multiple row version information can be determined, and the multiple row version information can be merged in sequence according to the order of occurrence of the multiple row version information. The first timestamp when the first transaction is committed and the merged row version information are used to generate a committed version, wherein the first timestamp when the first transaction is committed can be the logical time of the system. The first timestamp is used to identify the order in which different transactions occur.

[0060] According to an embodiment of the present invention, for other transactions that read the target data row, only the changes of the target data row before the execution of the first transaction and after the first transaction is committed are concerned. Therefore, by merging multiple row version information on the uncommitted version data chain of the target data row, data storage space can be saved. By identifying the committed row version information corresponding to the first transaction with the first timestamp, a logical reference order is provided for the committed row version information corresponding to the first transaction, which facilitates improving the management efficiency of the system for the committed row version chain.

[0061] According to an embodiment of the present invention, a multi-version concurrency control method for a database also includes: in response to a received data read request for reading a target data row by a second transaction, determining at least one row version information to be rolled back from a committed row version chain based on a second timestamp of the second transaction; and performing data rollback based on the row version information to be rolled back and a third version of the target data row to obtain a target data row of a target version, wherein the third version of the target data row is a version obtained after the target transaction is committed, and the target transaction is the latest committed transaction among multiple committed transactions for the target data row.

[0062] According to an embodiment of the present invention, the second transaction may be a transaction that has a data read request for the target data row. The second timestamp of the second transaction is used to identify the timestamp when the second transaction starts to execute, wherein the second timestamp may be a timestamp assigned by the system according to the logical clock of the system. The row version information to be rolled back is the committed version information in the committed row version information that meets the condition to be rolled back, wherein the condition to be rolled back may be the committed row version information whose first timestamp is after the second timestamp.

[0063] According to an embodiment of the present invention, when a data read request of the second transaction is received, the chain head address of the committed row version chain corresponding to the target data row is determined according to the address information defined in the data read request. According to the connection order of each node in the committed row version chain, that is, the link order between each committed row version information, the second timestamp of the second transaction and the first timestamp of the committed row version information are compared in sequence, and at least one row version information to be rolled back is determined from the committed row version chain.

[0064] According to an embodiment of the present invention, the target transaction is the latest committed transaction among multiple committed transactions for the target data row, and the third version of the target data row is the data version of the target data row after the target data row is modified by the latest committed transaction. The third version of the target data row is usually stored in a non-volatile storage medium such as an external memory. This hybrid storage structure in which the committed row version chain is stored in the memory and the third version of the target data row is stored in the external memory, so that when the second transaction reads the target version of the target data row, it only needs to obtain the third version of the target data row from the external memory, and there is no need to call the full data set in the external memory into the memory for calculation, thereby reducing the limitation on the available capacity of the database. In order to minimize access to the external memory, the third version of the target data row can also be stored in the memory.

[0065] According to an embodiment of the present invention, the target data row of the target version is the data row version read by the third transaction, which is the data row version of the target data row at the time when the third transaction starts to execute. The row version information to be rolled back is rolled back based on the third version of the target data row, thereby obtaining the data row version of the target data row at the time before the third transaction starts to execute.

[0066] According to an embodiment of the present invention, data is rolled back based on the version information of the row to be rolled back and the third version of the target data row, and the target data row of the target version is obtained, thereby ensuring the consistency of the data read by the second transaction. In addition, in the process of reading the target data row of the target version, only the committed row version chain is accessed, and there is no need to access the undo log after persistence in the external memory, thereby reducing the number of data input and output times and improving the transaction processing efficiency.

[0067] According to an embodiment of the present invention, based on the second timestamp of the second transaction, at least one row version information to be rolled back is determined from the committed row version chain, including: based on the second timestamp, determining the target row version information from the committed row version chain, wherein the target row version information is the latest committed row version information in the committed row version chain that is located before the second timestamp; and determining at least one row version information to be rolled back based on the target row version information and the committed row version information whose first timestamp is greater than the second timestamp.

[0068] According to an embodiment of the present invention, the first timestamp of the target row version information is less than the second timestamp, and among all the committed row version information whose first timestamp is less than the second timestamp, the first timestamp of the target row version information is the largest. The target row version information is determined based on the comparison of the second timestamp with the committed row version information in the committed version chain in sequence. The target row version information and the committed row version information whose first timestamp is greater than the second timestamp are determined as at least one row version information to be rolled back.

[0069] According to an embodiment of the present invention, since the first timestamp of the committed row version information can represent the order in which transactions are committed, the second timestamp can be compared with the first timestamp to determine the modifications made to the target data row by the transaction committed after the start of the second transaction, thereby ensuring the consistency of the data read by the second transaction.

[0070] According to an embodiment of the present invention, the committed row version information is written into the committed row version chain corresponding to the target data row, including: when there is at least one historical committed row version information in the committed row version chain, the read pointer of the committed row version chain is updated to the memory address corresponding to the committed row version information; wherein the historical committed row version information is the row version information committed by at least one transaction; and the node corresponding to the historical committed row version information is used as the successor node of the node corresponding to the committed row version information to ensure the storage order of the historical committed row version information and the committed row version information.

[0071] According to an embodiment of the present invention, the historical committed row version information is the row version information submitted by other transactions before the first transaction starts. When there is at least one historical committed row version information in the committed row version chain, the head insertion method is used to insert the committed row version information into the committed row version chain. Specifically, the read pointer of the committed row version chain is updated to the memory address corresponding to the committed row version information; the node corresponding to the historical committed row version information is used as the successor node of the node corresponding to the committed row version information. This ensures the storage order of the historical committed row version information and the committed row version information.

[0072] Figure 4 A schematic diagram of a committed row version chain according to an embodiment of the present invention is shown.

[0073] like Figure 4 As shown, in the committed row version chain, there are historical committed row version information 401, historical committed row version information 402, and historical committed row version information 403. Historical committed row version information 401 includes first timestamp 1 and data difference 1; historical committed row version information 402 includes first timestamp 2 and data difference 2; historical committed row version information 403 includes first timestamp 3 and data difference 3, wherein the data difference is the difference between the target data row before and after the transaction corresponding to the historical committed row version information is committed.

[0074] The first timestamps of the historical committed row version information 401, the historical committed row version information 402, and the historical committed row version information 403 are arranged from large to small, i.e., the first timestamp 1 of the historical committed row version information 401 is the largest, and the first timestamp 3 of the historical committed row version information 403 is the smallest. A larger first timestamp indicates that the transaction corresponding to the historical committed row version information is committed later.

[0075] In the process of searching for the target row version information in the second transaction, you can start searching from the head of the committed row version chain and save the committed row version information of the non-target row version information in sequence until the target row version information is found, thereby saving search time and improving transaction processing efficiency.

[0076] According to an embodiment of the present invention, the multi-version concurrency control method of a database also includes: upon receiving a feedback signal indicating that the first transaction was successfully committed, obtaining the transaction start timestamp of each active transaction; and cleaning up the committed row version chain based on each transaction start timestamp.

[0077] According to an embodiment of the present invention, an active transaction represents an active transaction in a database management system. When the first transaction is successfully committed, that is, when a feedback signal representing the successful submission of the first transaction is received, the transaction start timestamp of each active transaction of the database management system is obtained. By comparing the first timestamp corresponding to the historically committed transaction on the committed row version chain, the historical committed row version information whose first timestamp is earlier than the start timestamp of each transaction is deleted. This is different from the traditional garbage collection (GC) of memory management, thereby improving the use efficiency of memory space and reducing the storage of data row versions that are not visible to transactions in memory.

[0078] According to an embodiment of the present invention, when a feedback signal indicating that the first transaction is successfully committed is received, the transaction start timestamp of each active transaction of the database management system is obtained. Based on the transaction start timestamp of each active transaction, historical committed row version information whose first timestamp is later than the start timestamp of each transaction in the committed row version chain can also be determined, and the historical committed row version information whose first timestamp is later than the start timestamp of each transaction is referred to as the first historical committed row version information, and the historical committed row version information whose first timestamp is earlier than the first historical committed row version information in the committed row version chain is referred to as the second historical committed row version information.

[0079] According to an embodiment of the present disclosure, in the case where there is at least one first historical committed row version information, the first historical committed row version information, the second historical committed row version information and the third version of the target data row are used to redetermine the target data row version corresponding to the second historical committed row version information and the historical committed row version information between the third version of the target data row. The redetermined historical committed row version information is used to replace the first historical committed row version information and the second historical committed row version information in the committed row version chain.

[0080] According to an embodiment of the present invention, the multi-version concurrency control method of a database also includes: determining the modification type of the target data row modified by the first transaction; and generating committed row version information based on the first timestamp, the modification type, and the merged row version information.

[0081] According to an embodiment of the present invention, the modification type of the target data row modified by the first transaction may include update data, delete data, insert data, etc. When the modification type is update data, the modification type may be identified as Write; when the modification type is delete data, the modification type may be identified as Delete; when the modification type is insert data, the modification type may be identified as Insert. Committed row version information is generated based on the first timestamp, the modification type, and the merged row version information.

[0082] According to an embodiment of the present invention, the modification type of the committed row version information is identified to facilitate determination of whether the committed row version information needs to be read when a transaction deletes data in a target data row. For example, when the second timestamp of the second transaction is greater than the first timestamp of the committed row version information, and the modification type of the committed row version information is to delete data, the system returns a prompt message to notify the user that the information has been deleted, and rolls back all operations of the second transaction, thereby improving the efficiency of the system in processing transactions.

[0083] Based on the above database multi-version concurrency control method, the present invention also provides a database multi-version concurrency control device. Figure 5 The device is described in detail.

[0084] Figure 5 A structural block diagram of a multi-version concurrency control device for a database according to an embodiment of the present invention is shown.

[0085] like Figure 5 As shown, the multi-version concurrency control device 500 for a database in this embodiment includes a difference determination module 510 , an information writing module 520 , and a version writing module 530 .

[0086] The difference determination module 510 is used to determine the difference information of the target data row according to the first version and the second version of the target data row, wherein the second version of the target data row is obtained by modifying the first version by the first transaction. In one embodiment, the difference determination module 510 can be used to perform the operation S210 described above, which will not be described in detail here.

[0087] The information writing module 520 is used to write the difference information as the latest row version information into the uncommitted version data chain corresponding to the target data row, wherein the uncommitted version data chain includes at least one row version information, and the at least one row version information is obtained by executing the first transaction. In one embodiment, the information writing module 520 can be used to execute the operation S220 described above, which will not be repeated here.

[0088] The version writing module 530 is used to generate the committed row version information corresponding to the target data row according to the uncommitted version data chain when receiving the feedback signal indicating that the first transaction is successfully committed, and write the committed row version information into the committed row version chain corresponding to the target data row. In one embodiment, the version writing module 530 can be used to perform the operation S230 described above, which will not be described in detail here.

[0089] According to an embodiment of the present invention, the version writing module 530 includes: an information merging submodule and an information generating submodule.

[0090] The information merging submodule is used to merge the multiple row version information according to the writing order of the multiple row version information in the uncommitted version data chain when the uncommitted version data chain includes multiple row version information.

[0091] The information generation submodule is used to generate submitted row version information based on the first timestamp of submitting the first transaction and the merged row version information.

[0092] According to an embodiment of the present invention, the multi-version concurrency control device 500 for a database further includes: a version determination module and a data determination module.

[0093] The version determination module is used to respond to a received data read request for reading a target data row by a second transaction, and determine at least one to-be-rolled-back row version information from a committed row version chain based on a second timestamp of the second transaction.

[0094] The data determination module is used to roll back data based on the version information of the row to be rolled back and the third version of the target data row to obtain the target data row of the target version, wherein the third version of the target data row is the version obtained after the target transaction is committed, and the target transaction is the latest committed transaction among multiple committed transactions for the target data row.

[0095] According to an embodiment of the present invention, the version determination module includes: a target determination submodule and an information determination submodule.

[0096] The target determination submodule is used to determine the target row version information from the committed row version chain based on the second timestamp, wherein the target row version information is the latest committed row version information in the committed row version chain that is located before the second timestamp.

[0097] The information determination submodule is used to determine at least one row version information to be rolled back according to the target row version information and the committed row version information whose first timestamp is greater than the second timestamp.

[0098] According to an embodiment of the present invention, the information writing module 520 includes: a pointer updating submodule and a node determining submodule.

[0099] The pointer update submodule is used to update the read pointer of the committed row version chain to the memory address corresponding to the committed row version information when there is at least one historical committed row version information in the committed row version chain; wherein the historical committed row version information is the row version information submitted through at least one transaction.

[0100] The node determination submodule is used to use the node corresponding to the historical committed row version information as the successor node of the node corresponding to the committed row version information to ensure the storage order of the historical committed row version information and the committed row version information.

[0101] According to an embodiment of the present invention, the database multi-version concurrency control device 500 further includes: a timestamp determination module and a version cleaning module.

[0102] The timestamp determination module is used to obtain the transaction start timestamp of each active transaction when receiving a feedback signal indicating that the first transaction is successfully submitted.

[0103] The version cleaning module is used to clean up the committed row version chain based on the start timestamp of each transaction.

[0104] According to an embodiment of the present invention, the database multi-version concurrency control device 500 further includes: a type determination module and an information generation module.

[0105] The type determination module is used to determine the modification type of the target data row modified by the first transaction.

[0106] The information generation module is used to generate submitted row version information based on the first timestamp, the modification type, and the merged row version information.

[0107] According to an embodiment of the present invention, any multiple modules of the difference determination module 510, the information writing module 520, and the version writing module 530 can be combined into one module for implementation, or any one of the modules can be split into multiple modules. Alternatively, at least part of the functions of one or more of these modules can be combined with at least part of the functions of other modules and implemented in one module. According to an embodiment of the present invention, at least one of the difference determination module 510, the information writing module 520, and the version writing module 530 can be at least partially implemented as a hardware circuit, such as a field programmable gate array (FPGA), a programmable logic array (PLA), a system on a chip, a system on a substrate, a system on a package, an application specific integrated circuit (ASIC), or can be implemented by hardware or firmware such as any other reasonable way of integrating or packaging the circuit, or implemented in any one of the three implementation methods of software, hardware, and firmware, or in any appropriate combination of any of them. Alternatively, at least one of the difference determination module 510, the information writing module 520, and the version writing module 530 can be at least partially implemented as a computer program module, and when the computer program module is run, the corresponding function can be executed.

[0108] Figure 6 A block diagram of an electronic device suitable for implementing a multi-version concurrency control method for a database according to an embodiment of the present invention is shown.

[0109] like Figure 6As shown, the electronic device 600 according to an embodiment of the present invention includes a processor 601, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 602 or a program loaded from a storage part 608 to a random access memory (RAM) 603. The processor 601 may include, for example, a general-purpose microprocessor (e.g., a CPU), an instruction set processor and / or a related chipset and / or a special-purpose microprocessor (e.g., an application-specific integrated circuit (ASIC)), etc. The processor 601 may also include an onboard memory for caching purposes. The processor 601 may include a single processing unit or multiple processing units for performing different actions of the method flow according to an embodiment of the present invention.

[0110] In RAM 603, various programs and data required for the operation of electronic device 600 are stored. Processor 601, ROM 602 and RAM 603 are connected to each other via bus 604. Processor 601 performs various operations of the method flow according to the embodiment of the present invention by executing the program in ROM 602 and / or RAM 603. It should be noted that the program can also be stored in one or more memories other than ROM 602 and RAM 603. Processor 601 can also perform various operations of the method flow according to the embodiment of the present invention by executing the program stored in the one or more memories.

[0111] According to an embodiment of the present invention, the electronic device 600 may further include an input / output (I / O) interface 605, which is also connected to the bus 604. The electronic device 600 may further include one or more of the following components connected to the input / output (I / O) interface 605: an input portion 606 including a keyboard, a mouse, etc.; an output portion 607 including a cathode ray tube (CRT), a liquid crystal display (LCD), etc., and a speaker, etc.; a storage portion 608 including a hard disk, etc.; and a communication portion 609 including a network interface card such as a LAN card, a modem, etc. The communication portion 609 performs communication processing via a network such as the Internet. A drive 610 is also connected to the input / output (I / O) interface 605 as needed. A removable medium 611, such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc., is installed on the drive 610 as needed, so that a computer program read therefrom is installed into the storage portion 608 as needed.

[0112] The present invention also provides a computer-readable storage medium, which may be included in the device / apparatus / system described in the above embodiment; or may exist independently without being assembled into the device / apparatus / system. The above computer-readable storage medium carries one or more programs, and when the above one or more programs are executed, the method according to the embodiment of the present invention is implemented.

[0113] According to an embodiment of the present invention, the computer-readable storage medium may be a non-volatile computer-readable storage medium, for example, it may include but is not limited to: a portable computer disk, a hard disk, a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination thereof. In the present invention, the computer-readable storage medium may be any tangible medium containing or storing a program, which may be used by or in combination with an instruction execution system, an apparatus or a device. For example, according to an embodiment of the present invention, the computer-readable storage medium may include the ROM 602 and / or the RAM 603 described above and / or one or more memories other than the ROM 602 and the RAM 603.

[0114] The embodiment of the present invention also includes a computer program product, which includes a computer program, and the computer program contains program code for executing the method shown in the flowchart. When the computer program product is run in a computer system, the program code is used to enable the computer system to implement the multi-version concurrency control method for a database provided by the embodiment of the present invention.

[0115] The computer program executes the above functions defined in the system / device of the embodiment of the present invention when it is executed by the processor 601. According to the embodiment of the present invention, the system, device, module, unit, etc. described above can be implemented by a computer program module.

[0116] In one embodiment, the computer program may rely on tangible storage media such as optical storage devices, magnetic storage devices, etc. In another embodiment, the computer program may also be transmitted and distributed in the form of signals on a network medium, and downloaded and installed through the communication part 609, and / or installed from a removable medium 611. The program code contained in the computer program may be transmitted using any appropriate network medium, including but not limited to: wireless, wired, etc., or any suitable combination of the above.

[0117] In such an embodiment, the computer program can be downloaded and installed from the network through the communication part 609, and / or installed from the removable medium 611. When the computer program is executed by the processor 601, the above functions defined in the system of the embodiment of the present invention are performed. According to the embodiment of the present invention, the system, device, means, module, unit, etc. described above can be implemented by a computer program module.

[0118] According to an embodiment of the present invention, the program code for executing the computer program provided by the embodiment of the present invention can be written in any combination of one or more programming languages. Specifically, these computing programs can be implemented using high-level process and / or object-oriented programming languages, and / or assembly / machine languages. Programming languages ​​include, but are not limited to, Java, C++, python, "C" language or similar programming languages. The program code can be executed entirely on the user computing device, partially on the user device, partially on the remote computing device, or entirely on the remote computing device or server. In the case of a remote computing device, the remote computing device can be connected to the user computing device through any type of network, including a local area network (LAN) or a wide area network (WAN), or can be connected to an external computing device (e.g., using an Internet service provider to connect through the Internet).

[0119] The flow chart and block diagram in the accompanying drawings illustrate the possible architecture, function and operation of the system, method and computer program product according to various embodiments of the present invention. In this regard, each box in the flow chart or block diagram can represent a module, a program segment, or a part of a code, and the above-mentioned module, program segment, or a part of a code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a different order from the order marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram or flow chart, and the combination of the boxes in the block diagram or flow chart can be implemented with a dedicated hardware-based system that performs a specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0120] It will be appreciated by those skilled in the art that the features described in the various embodiments of the present invention may be combined and / or combined in various ways, even if such combinations and / or combinations are not explicitly described in the present invention. In particular, without departing from the spirit and teachings of the present invention, the features described in the various embodiments of the present invention may be combined and / or combined in various ways. All of these combinations and / or combinations fall within the scope of the present invention.

[0121] The embodiments of the present invention are described above. However, these embodiments are only for the purpose of illustration, and are not intended to limit the scope of the present invention. Although each embodiment is described above, it does not mean that the measures in each embodiment cannot be used in combination advantageously. Without departing from the scope of the present invention, those skilled in the art may make various substitutions and modifications, which should all fall within the scope of the present invention.

Claims

1. A multi-version concurrency control method for a database, characterized in that: The method comprises: Determining difference information of the target data row according to a first version and a second version of the target data row, wherein the second version of the target data row is obtained by modifying the first version through a first transaction; Writing the difference information as the latest row version information into an uncommitted version data chain corresponding to the target data row, wherein the uncommitted version data chain includes at least one row version information obtained by executing the first transaction; Upon receiving a feedback signal indicating successful submission of the first transaction, generating committed row version information corresponding to the target data row according to the uncommitted version data chain, and writing the committed row version information into the committed row version chain corresponding to the target data row; Wherein, the uncommitted version data chain and the committed row version chain are both stored in the memory; The step of writing the committed row version information into a committed row version chain corresponding to the target data row includes: In the case where there is at least one historical committed row version information in the committed row version chain, updating the read pointer of the committed row version chain to a memory address corresponding to the committed row version information; wherein the historical committed row version information is row version information committed by at least one transaction; The node corresponding to the historical committed row version information is used as the successor node of the node corresponding to the committed row version information to ensure the storage order of the historical committed row version information and the committed row version information.

2. The method according to claim 1, characterized in that The step of generating the committed row version information corresponding to the target data row according to the uncommitted version data chain includes: In the case where the uncommitted version data chain includes a plurality of the row version information, merging the plurality of the row version information according to the writing order of the plurality of the row version information in the uncommitted version data chain; The committed row version information is generated based on the first timestamp of committing the first transaction and the merged row version information.

3. The method according to claim 1, characterized in that The method further comprises: In response to a received data read request for reading a target data row by a second transaction, determining at least one to-be-rolled-back row version information from the committed row version chain based on a second timestamp of the second transaction; Data rollback is performed based on the to-be-rolled back row version information and the third version of the target data row to obtain a target data row of a target version, wherein the third version of the target data row is a version obtained after a target transaction is committed, and the target transaction is the latest committed transaction among multiple committed transactions for the target data row.

4. The method according to claim 3, characterized in that The determining, based on the second timestamp of the second transaction, at least one row version information to be rolled back from the committed row version chain includes: Based on the second timestamp, determine the target row version information from the committed row version chain, wherein the target row version information is the latest committed row version information in the committed row version chain that is before the second timestamp; At least one row version information to be rolled back is determined according to the target row version information and the committed row version information whose first timestamp is greater than the second timestamp.

5. The method according to claim 1, characterized in that The method further comprises: Upon receiving a feedback signal indicating that the first transaction is successfully submitted, obtaining a transaction start timestamp of each active transaction; The historical committed row version information is cleaned up based on each transaction start timestamp.

6. The method according to claim 2, characterized in that The method further comprises: determining a modification type of the target data row modified by the first transaction; The committed row version information is generated based on the first timestamp, the modification type, and the merged row version information.

7. A multi-version concurrent control device for a database, characterized in that: The device comprises: a difference determination module, configured to determine difference information of a target data row according to a first version and a second version of the target data row, wherein the second version of the target data row is obtained by modifying the first version through a first transaction; an information writing module, configured to write the difference information as the latest row version information into an uncommitted version data chain corresponding to the target data row, wherein the uncommitted version data chain includes at least one row version information, and the at least one row version information is obtained by executing the first transaction; a version writing module, configured to generate committed row version information corresponding to the target data row according to the uncommitted version data chain upon receiving a feedback signal indicating successful submission of the first transaction, and write the committed row version information into the committed row version chain corresponding to the target data row; Wherein, the uncommitted version data chain and the committed row version chain are both stored in the memory; The information writing module comprises: A pointer update submodule, configured to update the read pointer of the committed row version chain to a memory address corresponding to the committed row version information if there is at least one historical committed row version information in the committed row version chain; wherein the historical committed row version information is row version information committed by at least one transaction; The node determination submodule is used to use the node corresponding to the historical committed row version information as the successor node of the node corresponding to the committed row version information to ensure the storage order of the historical committed row version information and the committed row version information.

8. An electronic device, comprising: one or more processors; a memory for storing one or more computer programs, It is characterized in that the one or more processors execute the one or more computer programs to implement the steps of the method according to any one of claims 1 to 6.

9. A computer-readable storage medium having a computer program or instruction stored thereon, characterized in that: When the computer program or instruction is executed by a processor, the steps of the method according to any one of claims 1 to 6 are implemented.

Images