CN114722125A - Database transaction processing method, device, equipment and computer readable medium - Google Patents

Database transaction processing method, device, equipment and computer readable medium Download PDF

Info

Publication number
CN114722125A
CN114722125A CN202210373077.8A CN202210373077A CN114722125A CN 114722125 A CN114722125 A CN 114722125A CN 202210373077 A CN202210373077 A CN 202210373077A CN 114722125 A CN114722125 A CN 114722125A
Authority
CN
China
Prior art keywords
file
database transaction
transaction
data file
cloud platform
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202210373077.8A
Other languages
Chinese (zh)
Inventor
王学伟
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Jingdong Technology Information Technology Co Ltd
Original Assignee
Jingdong Technology Information Technology Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Jingdong Technology Information Technology Co Ltd filed Critical Jingdong Technology Information Technology Co Ltd
Priority to CN202210373077.8A priority Critical patent/CN114722125A/en
Publication of CN114722125A publication Critical patent/CN114722125A/en
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/28—Databases characterised by their database models, e.g. relational or object models
    • G06F16/284—Relational databases
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/23—Updating
    • G06F16/2379—Updates performed during online database operations; commit processing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor

Landscapes

  • Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computing Systems (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

The invention discloses a method, a device, equipment and a computer readable medium for database transaction processing, and relates to the technical field of computers. One embodiment of the method comprises: recording the data file name of the database transaction into a recovery file of a temporary directory of the distributed nodes; when the recovery file does not exist in the cloud platform, moving the data file of the database transaction from the temporary directory to a data file directory of the cloud platform, and moving the recovery file of the temporary directory to the data file directory of the cloud platform to submit the database transaction; updating the symbolic link name of the data file in a visibility file based on the transaction sequence number of the database transaction; and moving the recovery file of the cloud platform to a directory of a cloud platform shared storage to determine that the database transaction is successfully submitted. The implementation method can improve the efficiency of database transaction processing in the cloud native scene.

Description

Database transaction processing method, device, equipment and computer readable medium
Technical Field
The present invention relates to the field of computer technologies, and in particular, to a method, an apparatus, a device, and a computer-readable medium for database transaction processing.
Background
The transaction is an important characteristic of the relational database, and as the database is developed from a single-machine centralized database to a distributed database, the single-machine database transaction is also changed into a distributed transaction. Distributed transactions are typically implemented using a two-phase commit protocol (2 PC). The execution of a two-phase commit is divided into two phases, the voting phase and the commit phase, as well as its name.
In the process of implementing the invention, the inventor finds that at least the following problems exist in the prior art: the main reasons for distributed transactions using the two-phase commit protocol are: two-phase commit is directed to a common distributed scenario. For a cloud native scenario that relies on the underlying services provided by the cloud platform, the efficiency of processing transactions is low.
Disclosure of Invention
In view of this, embodiments of the present invention provide a method, an apparatus, a device, and a computer readable medium for database transaction processing, which can improve the efficiency of database transaction processing in a cloud-native scenario.
To achieve the above object, according to an aspect of an embodiment of the present invention, there is provided a method for database transaction processing, including:
recording the data file name of the database transaction into a recovery file of a temporary directory of the distributed nodes;
when the recovery file does not exist in the cloud platform, moving the data file of the database transaction from the temporary directory to a data file directory of the cloud platform, and moving the recovery file of the temporary directory to the data file directory of the cloud platform to submit the database transaction;
updating the symbolic link name of the data file in a visibility file based on the transaction sequence number of the database transaction, wherein the visibility file is used for concurrency control of distributed nodes;
and moving the recovery file of the cloud platform to a directory of a cloud platform shared storage to determine that the database transaction is successfully submitted.
The database transaction comprises an update transaction;
before recording the data file name of the database transaction into the recovery file of the temporary directory of the distributed node, the method further includes:
creating a temporary data file at the distributed node, and executing the update transaction in the temporary data file to update the database transaction.
The database transaction comprises a non-update transaction;
before the recording the data file name of the database transaction into the recovery file of the temporary directory of the distributed node, the method also comprises
And storing the data file of the database transaction into the data file in the temporary directory.
When a recovery file exists in the cloud platform;
the method further comprises the following steps:
and after deleting the visibility file of the data file in the cloud platform, deleting the newly added file of the data file in the cloud platform and updating the visibility file of the cloud platform.
The method further comprises the following steps:
traversing a directory shared and stored by the cloud platform, and determining a cleaning sequence number according to a reference count of the data file, wherein the reference count is used for recording the number of times of calling the data file;
and deleting the data file with the transaction sequence number smaller than or equal to the cleaning sequence number.
Updating the symbolic link name of the data file in the visibility file based on the transaction sequence number of the database transaction, including:
linking the new symbol in the data file with the data file corresponding to the transaction sequence number of the database transaction;
and updating the new symbolic link name of the data file in the visibility file according to the transaction sequence number of the database transaction.
Before committing the database transaction, the method further comprises: executing locking operation;
after determining that the database transaction is successfully committed, the method further comprises: and executing unlocking operation.
According to a second aspect of the embodiments of the present invention, there is provided an apparatus for database transaction processing, including:
the recording module is used for recording the data file name of the database transaction into a recovery file of a temporary directory of the distributed nodes;
the submitting module is used for moving the data files of the database transaction from the temporary directory to a data file directory of the cloud platform and moving the recovery files of the temporary directory to the data file directory of the cloud platform to submit the database transaction under the condition that the recovery files do not exist in the cloud platform;
the updating module is used for updating the symbolic link name of the data file in a visibility file based on the transaction sequence number of the database transaction, and the visibility file is used for concurrency control of distributed nodes;
and the moving module is used for moving the recovery file of the cloud platform to a directory of a cloud platform shared storage to determine that the database transaction is successfully submitted.
According to a third aspect of the embodiments of the present invention, there is provided an electronic device for database transaction processing, including:
one or more processors;
a storage device for storing one or more programs,
when executed by the one or more processors, cause the one or more processors to implement the method as described above.
According to a fourth aspect of embodiments of the present invention, there is provided a computer readable medium, on which a computer program is stored, which when executed by a processor, implements the method as described above.
One embodiment of the above invention has the following advantages or benefits: recording the data file name of the database transaction into a recovery file of a temporary directory of the distributed nodes; when the recovery file does not exist in the cloud platform, moving the data file of the database transaction from the temporary directory to a data file directory of the cloud platform, and moving the recovery file of the temporary directory to the data file directory of the cloud platform to submit the database transaction; updating the symbolic link name of the data file in a visibility file based on the transaction sequence number of the database transaction, wherein the visibility file is used for concurrency control of distributed nodes; and moving the recovery file of the cloud platform to a directory of a cloud platform shared storage to determine that the database transaction is successfully submitted. The distributed nodes upload the data files of the database transaction to the cloud platform to process the database transaction, and other distributed nodes can acquire the data files, so that the efficiency of database transaction processing in a cloud scene can be improved.
Further effects of the above-mentioned non-conventional alternatives will be described below in connection with the embodiments.
Drawings
The drawings are included to provide a better understanding of the invention and are not to be construed as unduly limiting the invention. Wherein:
FIG. 1 is a schematic main flow diagram of a method of database transaction processing according to an embodiment of the invention;
FIG. 2 is a schematic diagram of a distributed database architecture according to an embodiment of the present invention;
FIG. 3 is a block diagram of a commit database transaction in accordance with an embodiment of the present invention;
FIG. 4 is a flow diagram illustrating background cleaning according to an embodiment of the invention;
FIG. 5 is a schematic flow chart of updating symbolic link names in a visibility file according to an embodiment of the present invention;
FIG. 6 is a schematic diagram of the main structure of a database transaction processing device according to an embodiment of the present invention;
FIG. 7 is an exemplary system architecture diagram in which embodiments of the present invention may be employed;
fig. 8 is a schematic block diagram of a computer system suitable for use in implementing a terminal device or server according to an embodiment of the present invention.
Detailed Description
Exemplary embodiments of the present invention are described below with reference to the accompanying drawings, in which various details of embodiments of the invention are included to assist understanding, and which are to be considered as merely exemplary. Accordingly, those of ordinary skill in the art will recognize that various changes and modifications of the embodiments described herein can be made without departing from the scope and spirit of the invention. Also, descriptions of well-known functions and constructions are omitted in the following description for clarity and conciseness.
The two-phase commit protocol for distributed transactions includes: a voting phase and a submission phase. In the voting phase, the coordinator sends a request for executing the operation to the participants of the transaction and waits for the responses of other participants, and the participants execute the corresponding transaction operation and return the result of the operation execution to the coordinator. The two-phase commit enters the commit phase when all participants have returned a certain result. The result of the determination includes approval or termination.
In the COMMIT phase, the coordinator will send instructions of COMMIT or ABORT to all participants based on the return from the voting phase. When all participants of the transaction decide a COMMIT transaction, the coordinator sends a COMMIT request to the participants, the participants return a completion message to the coordinator after completing the operation and releasing the resources, and the coordinator finishes the whole transaction when receiving the completion messages of all the participants; in contrast, when all participants decide about an ABORT current transaction, the coordinator will send an ABORT request to the participants of the transaction, and the participants will roll back and send a message to the coordinator of completion.
The two-phase commit described above is directed to the distributed scenario of the common MPP architecture. The MPP architecture is characterized in that tasks are distributed to a plurality of servers and nodes in parallel, and after calculation on each node is completed, results of respective parts are collected together to obtain a final result. The database adopting the MPP architecture is referred to as an MPP database.
For cloud-native scenarios, the efficiency of processing transactions is low. The cloud native scenario refers to a basic service provided by a cloud platform. Such as: the method comprises the steps of virtual machine service, cloud storage service and cloud file service, wherein the cloud file service runs a software scene. The cloud native scene is different from a scene that traditional software is deployed on a physical machine and depends on hardware of the physical machine to run. A cloud-native scene may also become a cloud scene. The cloud scenario is characterized in that: the computing nodes can be conveniently expanded, and the cluster size can be large.
In the execution process of the two-stage submission, the following disadvantages are specifically present when the method is applied to a cloud scene:
all nodes participating in the transaction operation are in a blocking state, and each participant cannot perform other task operations in the process of waiting for responses of other participants, so that the performance is very low.
In the existing two phases, a role of a coordinator is introduced, the role of the coordinator plays a very important role in the whole two-stage segment submission protocol, and once the coordinator has a problem, the second phase cannot operate. More seriously, if the coordinator has a problem in the second phase, the other participants will be in the state of locking the transaction resource and can not continue to complete the transaction operation.
If in the first phase, a network failure occurs, or part of participants fail, the coordinator ABORT transaction is caused, and the transaction success probability is reduced. This is particularly true in cases where the cluster size is large.
If in the second phase after the coordinator sends a commit request to the participants, a network anomaly occurs or the coordinator fails during the sending of the commit request, this may result in only a portion of the participants receiving the commit request. And the commit operation is executed after the commit request is received by the part of the participants. But the other machines that did not receive the commit request cannot perform the transaction commit. Data inconsistency occurs throughout the distributed system.
In summary, for a cloud scenario that depends on the basic service provided by the cloud platform, the efficiency of processing the transaction is low.
In order to solve the problem that the efficiency of processing transactions is low in a cloud scene, the following technical scheme in the embodiment of the invention can be adopted.
Referring to fig. 1, fig. 1 is a schematic main flow diagram of a method for database transaction processing according to an embodiment of the present invention, and a database transaction is submitted on a cloud platform through distributed nodes. As shown in fig. 1, the method specifically comprises the following steps:
s101, recording the data file name of the database transaction into a recovery file of a temporary directory of the distributed nodes.
The technical scheme in the embodiment of the invention is mainly applied to the cloud platform. The cloud platform provides cloud file services.
Referring to fig. 2, fig. 2 is a schematic diagram of a distributed database architecture according to an embodiment of the present invention. Fig. 2 includes two clients and a plurality of computing nodes, and the clients enjoy the cloud file service through the server nodes.
The cloud platform provides cloud file services, and the cloud file services belong to shared storage. On the shared storage, one computing node writes one file, and other settlement nodes can see the file in real time. Files are shared to all compute nodes using storage, and are therefore also called shared storage.
The client may communicate with any one of the computing nodes. The computing node is a computing unit of a cloud service, such as: a virtual machine or a container. The computing node can perform computation and access the stored data of the bottom layer, and then provide services such as query and the like for the upper layer client. A computing node may distribute computing tasks to other computing nodes to speed up computing. The storage is specifically a storage unit of the cloud service. The storage unit typically provides storage services for cloud file services, or objects.
The scheme in the embodiment of the invention realizes the distributed transaction based on the functions provided by the cloud file service. The following describes 4 basic characteristics of the cloud file service:
the characteristic 1 is that the cloud file service adopts 3-copy redundant storage, and provides ultra-strong stability and reliability.
The characteristic 2 supports standard NFSv4.0 and NFSv4.1 protocols, provides a full-hosted service, does not need to modify an application, and can be realized through a standard file system mounting step.
And 3, multiple cloud hosts can simultaneously access file storage established in the cloud file service through the NFS protocol, read and write operations are performed on files, and data sharing of multiple computing nodes is achieved.
Property 4, file operations are atomicity, such as moving a file, creating a file, modifying a file name, etc.
Because all distributed nodes have the same data using shared storage, the transaction does not require two phases to commit. Recording the commit information to the shared store at the commit of each node ensures that other nodes have consistent data. By utilizing the atomicity characteristic of shared storage file operation, all nodes can have the same transaction state, and only one specific file is established to represent transaction submission when the transaction is submitted, so that all nodes can confirm the transaction submission.
Referring to FIG. 3, FIG. 3 is a block diagram of a framework for committing database transactions, according to an embodiment of the invention. In shared storage, the framework of database transaction commit involves multiple directories and files.
As can be seen from fig. 3, the table belongs to a plurality of files. The files under the tables are described below.
With the N suffix it is meant that there may be multiple files or directories. The Lock file is used to perform locking operations. Such as: a spin lock. The locking operation on the cloud file service is a distributed lock, and once one node is locked, other nodes cannot be locked.
The recovery (Recover) file is used for recovery, similar to the function of the redo log and the undo log. A data file is a file representing the actual storage of data by an object. Visibility file mainly for realizing the multi-version concurrency control technology (MVCC), the creation transaction number and the deletion transaction number of the data file are recorded in the visibility file name in the format of Create _ Drop.
The transaction sequence number file is the file generated when the transaction commits, with the file name being a monotonically increasing sequence (1, 2, 3 …), and when the file generation succeeds, it means that the transaction commits successfully. The reference count file refers to the hard link of the transaction sequence number file currently being accessed to determine whether a query is currently available for the data file generated by accessing the transaction. Temporary data files are data files generated during the operation of a transaction and are not available until commit.
In the embodiment of the invention, in order to process the database transaction on the cloud platform, the data file name of the database transaction is recorded in the recovery file of the temporary directory of the distributed node.
From the NodeN _ tmp directory in fig. 3, i.e. the temporary directory of distributed nodes. The recovery file is the recovery file under the NodeN _ tmp directory in fig. 3.
The restoration files of the temporary directory have functions similar to redolog and undolog and are used for restoration. The above-described writing of the temporary file has two purposes.
The purpose one is as follows: the writing operation is not an atomic operation, and the data file can be ensured not to be damaged due to downtime by renaming or performing the atomic operation during the moving operation after the writing is finished.
Purpose two: writing the file content takes a long time, which is not beneficial to be performed in the submission stage. Whereas the rename operation is very fast. Moving operations in the cloud file service are equivalent to renaming operations.
In one embodiment of the invention, the database transaction comprises an update transaction. In order not to affect the reading operation, a temporary data file is newly created in the distributed node, and an update transaction is executed in the temporary data file to update the database transaction.
That is, the data file to be modified is not locally updated, but is copied as new temporary file data and then the temporary file data is modified. Thus, the reading and writing are not the same file, and the condition of reading and writing conflict can not occur.
In one embodiment of the invention, the database transactions comprise non-update transactions. And storing the data file of the database transaction into the data file in the temporary directory of the distributed node.
That is, if the database transaction is not an update transaction, the data file of the database transaction is written to the data file in the temporary directory of each distributed node.
In the above steps, the data files and data file names of the database transaction are recorded in the temporary directory of the distributed nodes, so that a foundation is laid for storing data to the cloud platform.
S102, when the recovery file does not exist in the cloud platform, the data file is moved from the temporary data directory to the data file directory of the cloud platform, and the recovery file of the temporary directory is moved to the data file directory of the cloud platform to submit the database transaction.
To ensure atomicity of transactions, all rollback or aborting transactions must restore the modified data to the state before the transaction started. If in the process of executing the transaction, the condition that an error occurs or the constraint is not satisfied and the like needs to be rolled back is found, all the operations are rolled back directly according to the information recorded in the memory. The role of the recovery (recovery) file is to recover the data.
In an embodiment of the present invention, when there is no recovery file in the cloud platform, it means that the last database transaction submitted is successful, and recovery is not required. And directly moving the submitted recovery file from the temporary directory of the distributed node to the data file directory of the cloud platform. Then, the data file of the database transaction is moved from the temporary directory of the distributed node to the data file directory of the cloud platform.
In an embodiment of the present invention, when a recovery file exists in the cloud platform, it means that the last commit of the database transaction failed, and rollback needs to be performed. The rollback operation comprises deleting the newly added files of the data files in the cloud platform and updating the visibility files of the cloud platform after deleting the visibility files of the data files in the cloud platform.
Specifically, the visibility file of the data file of the database transaction is deleted, and then the newly added file of the data file in the cloud platform is deleted. And if the newly added file of the data file in the cloud platform does not exist, the data file is not processed. The operation can be repeated when the part of deletion operation is performed, namely, if the process is abnormal, the operation can be repeated without additional processing.
In an embodiment of the present invention, in order to improve efficiency, a newly added file of a visibility file and a data file is deleted, and the above file may be moved to a temporary directory and cleaned by a background during implementation. The specific deletion scheme is as follows.
Referring to fig. 4, fig. 4 is a schematic flowchart of background cleaning according to an embodiment of the present invention. The method specifically comprises the following steps:
s401, traversing the directory shared and stored by the cloud platform, determining a cleaning sequence number according to the reference count of the data file, wherein the reference count is used for recording the number of times of calling the data file.
In the embodiment of the invention, in order to accelerate the process of processing the database transaction, the deletion operation is carried out in the background. It is understood that S401 and S402 are performed in the background. Specifically, the deleted file is not queried to be accessed, and is cleaned up by the background.
The visibility files with transaction sequence numbers not being 0 in the visibility directories of the shared storage in the cloud platform are not usually accessed after being queried, so the visibility files are cleaned by the background.
In embodiments of the present invention, in the case of querying the transaction sequence number, a hard link, referred to as a reference count, is established for the transaction sequence number file. The reference count is set in a temporary directory of the corresponding distributed node. The reference count of the transaction number is increased by one each time a data file is created. The reference count is used to record the number of times the data file is called. The less the reference count, the less the usage frequency of the specification file; the more the number of reference counts is, the higher the use frequency of the specification file is.
In order to clean a file, a cleaning sequence number needs to be determined. Specifically, a plurality of transaction sequence number files are stored under the TIDS directory. And traversing a directory in the cloud platform, such as a TIDS directory, and taking the maximum transaction sequence number with the reference count larger than 1 as a cleaning identifier.
Specifically, traversing a TIDS directory in the cloud platform, finding out a file with a reference count larger than 1, and if only one transaction sequence number file exists, meaning that no file needs to be cleaned up; traversing TIDS directories in the cloud platform, finding files with reference counts larger than 1, and if the reference counts of all transaction sequence number files are all 1, cleaning the identifiers to be the maximum value; if all transaction sequence number file reference counts are not all 1, clearing the transaction sequence number identified as the first reference count not being 1.
S402, deleting the data file with the transaction sequence number smaller than or equal to the cleaning identifier.
Traversing all data files in the cloud platform, and deleting files with transaction sequence numbers smaller than or equal to the cleaning identifier. And all the files with transaction sequence numbers less than or equal to the cleaning identifier in the visibility file are deletable files.
The cleaning identifier and the previous transaction file can be deleted because no one has access to the cleaning identifier and the cleaning identifier cannot be accessed later. And finally, deleting all files corresponding to the transaction sequence numbers smaller than the cleaning identifier.
In the embodiment of the invention, the cleaning operation comprises file query and file deletion. The query and the deletion are reentrant, namely, the deletion is omitted when the target file is not found.
In the embodiment of fig. 4, in order to increase the speed of processing database transactions, the operation of deleting files in the cloud platform can be implemented in the background.
S103, updating the symbolic link name of the data file in the visibility file based on the transaction sequence number of the database transaction, wherein the visibility file is used for concurrency control of the distributed nodes.
The transaction sequence number of the database transaction is used to identify the database transaction. As one example, the transaction number of a database transaction is the current maximum transaction number of the database transaction plus one. The transaction sequence number of a database transaction may be determined in the following manner.
Obtaining the transaction serial number (ID) of the current database transaction, namely traversing the TIDS directory once to obtain the file name with the maximum transaction serial number, and then adding one to obtain the transaction ID of the current database transaction: and (4) X.
Referring to fig. 5, fig. 5 is a flowchart illustrating a process of updating symbolic link names in a visibility file according to an embodiment of the present invention. The method specifically comprises the following steps:
s501, linking the original symbols in the data files with files, and associating the original symbols with the data files corresponding to the transaction sequence numbers of the database transactions.
The symbolic link name of the data file in the visibility file in the cloud platform is a data file pointing to a database transaction. In order to obtain the data file, the symbolic link name of the data file in the visibility file needs to be updated based on the transaction sequence number of the database transaction.
Specifically, a symbolic link file of the transaction sequence number of the database transaction is established in the visibility directory, the data file of the database transaction is associated, and the symbolic link name of the original data file is modified.
As an example, the transaction sequence number of a database transaction: and X, establishing a symbolic link file of X _0 in the visibility directory, pointing to the data file of the database transaction, modifying the symbolic link name of the original data file, and changing the create _0 into the create _ X.
S502, in the visibility file, the symbolic link name of the data file is updated according to the transaction sequence number of the database transaction.
In the visibility file, the symbolic link name of the data file is updated with the transaction number of the database transaction. And then according to the symbolic link name, the data file can be obtained.
In the embodiment of fig. 5, the data file can be acquired based on the updated symbolic link name.
And S104, moving the recovery file of the cloud platform to a directory of the cloud platform shared storage to determine that the database transaction is successfully submitted.
In order to determine that the database transaction is successfully committed, the recovery file of the cloud platform needs to be moved to the cloud platform shared storage directory, such as: the directory is in particular a TIDS directory. The move operation, once successful, means that the database transaction commit was successful. When querying a data file, the latest version of the data file is accessed by traversing the TIDS directory.
In the embodiment of the invention, once the data file is named successfully, all data are actually stored on the cloud file server, and the data have persistence and do not need to be recovered through a redo log.
It should be noted that, in the process of reading the data file, a cache may be utilized to avoid that the data file needs to be read from the cloud file service every time the data file is read.
In the embodiment of the invention, the disk data is stored on the shared storage, and the data seen by all distributed nodes is consistent. That is, the read data by each distributed node is the same to ensure data consistency.
When the distributed node reads data, a read number is firstly obtained in a TIDS directory of the cloud platform, namely the TIDS directory is traversed once, and the maximum transaction sequence number is obtained. Then, the data file which can be read by reading the maximum transaction sequence number is taken.
The judgment rule is as follows: the creation version number < ═ read sequence number of the file < delete sequence number of the file.
If database transaction X fails to commit, then there must be no X file in the TIDS directory and the transaction number of the query may only be X-1. Then the file visibility file committed in database transaction X is X _0, or a _ X. According to the above judgment rule, even if the files are not rolled back, reading is not affected, because the query itself will not read the file corresponding to X _0 and will read the A _ X file. The effect is the same as rolling back an X transaction.
That is, even in the case of distributed query, only the number X acquired by the master node needs to be transmitted to other distributed nodes for query, and the queried data are consistent.
In one embodiment of the invention, to avoid multiple distributed node concurrent operations, a locking operation may be performed before committing the database transaction; after the database transaction is successfully committed, an unlock operation is performed.
Namely: firstly, locking operation is executed, and then database transaction is submitted; and after the database transaction is determined to be successfully submitted, unlocking operation is executed. As one example, a distributed lock may be implemented using an external program such as zookeeper.
The SQL standard defines a class 4 isolation level, which includes specific rules to define which changes are visible and which are invisible inside and outside of a transaction. The low level of isolation generally supports higher concurrent processing and has lower overhead. Including read uncommitted, read committed, read repeatable, serializable.
In embodiments of the present invention, reading committed isolation levels is supported. The read transaction does not conflict with other transactions at all, and is a complete lock-free read. The insert transaction and the update transaction conflict only at the commit node, but the locking process is short in the database transaction phase of the commit, so the concurrency is high.
Update transactions and update transactions cannot be performed simultaneously, isolation is guaranteed by a distributed lock, external guarantees are required, or a distributed lock is implemented on shared storage.
In the embodiment of the invention, in order to ensure the atomicity of the database transaction, all the rollback or abnormal interruption transactions must restore the modified data to the state before the transaction starts. If in the process of executing the transaction, the condition that an error occurs or the constraint is not satisfied and the like needs to be rolled back is found, all the operations are rolled back directly according to the information recorded in the memory. The method mainly focuses on transaction rollback caused by downtime in the process of processing database transactions.
The main abnormal conditions include the following three:
abnormal case 1:
from the beginning of processing the database transaction, the recovery file in the temporary directory is moved to the recovery file of the cloud platform. At this time, the recovery file of the cloud platform is file-free, and all files needing rollback operation are in the temporary directory.
Therefore, the rollback operation is simple, and the temporary directory of the corresponding distributed node is emptied. The specific implementation of the part can be divided into two parts, wherein the first part is a node restarting stage, and when the distributed node is restarted, the corresponding temporary directory is emptied. And the second part is processed by other distributed nodes in the distributed system, and if the other distributed nodes find that the distributed nodes have faults, the temporary directory of the corresponding distributed nodes is cleared.
Abnormal case 2:
and after the recovery file is moved to the recovery file of the cloud platform, the recovery file is moved to be a preset identification file. As an example, if the preset identifier is X, the movement is an X file. This phase is with the recovery file and the rollback operation is handed over to the next database transaction to execute the commit process. If the next database transaction is not executed, then no rollback is needed because reads are not affected, and consistency is not affected.
Abnormal situation 3:
and moving the recovery file of the cloud platform into a data file, and when the transaction is finished, if no recovery file exists, considering that the transaction is submitted without rollback.
In the above embodiment, the data file name of the database transaction is recorded in the recovery file of the temporary directory of the distributed node; when the recovery file does not exist in the cloud platform, moving the data file of the database transaction from the temporary directory to a data file directory of the cloud platform, and moving the recovery file of the temporary directory to the data file directory of the cloud platform to submit the database transaction; updating the symbolic link name of the data file in a visibility file based on the transaction sequence number of the database transaction, wherein the visibility file is used for concurrency control of distributed nodes; and moving the recovery file of the cloud platform to a directory of a cloud platform shared storage to determine that the database transaction is successfully submitted. The distributed nodes upload the data files of the database transaction to the cloud platform to process the database transaction, and other distributed nodes can acquire the data files, so that the efficiency of database transaction processing in a cloud scene can be improved.
Referring to fig. 6, fig. 6 is a schematic diagram of a main structure of a database transaction processing apparatus according to an embodiment of the present invention, where the database transaction processing apparatus may implement a method for database transaction processing, and as shown in fig. 6, the database transaction processing apparatus specifically includes:
a recording module 601, configured to record a data file name of a database transaction in a recovery file of a temporary directory of a distributed node;
a submitting module 602, configured to, when a recovery file does not exist in a cloud platform, move a data file of the database transaction from the temporary data directory to a data file directory of the cloud platform, and move a recovery file of the temporary directory to the data file directory of the cloud platform, so as to submit the database transaction;
an updating module 603, configured to update a symbolic link name of the data file in a visibility file based on the transaction sequence number of the database transaction, where the visibility file is used for concurrency control of a distributed node;
a moving module 604, configured to move the recovery file of the cloud platform to a directory of the cloud platform shared storage to determine that the database transaction is successfully committed.
In one embodiment of the invention, the database transaction comprises an update transaction;
the recording module 601 is further configured to create a temporary data file at a distributed node, and execute the update transaction in the temporary data file, so as to update the database transaction.
In one embodiment of the invention, the database transactions include non-update transactions;
the recording module 601 is further configured to store the data file of the database transaction into the data file in the temporary directory.
In one embodiment of the invention, in the case where a restore file exists in the cloud platform;
the submitting module 602 is further configured to upload the newly added file of the data file in the cloud platform after deleting the visibility file of the data file in the cloud platform, and update the visibility file of the cloud platform.
In an embodiment of the present invention, the updating module 603 is further configured to traverse a directory shared and stored by the cloud platform, and determine a cleaning sequence number according to a reference count of the data file, where the reference count is used to record the number of times of calling the data file;
and deleting the data file with the transaction identification smaller than or equal to the cleaning sequence number.
In an embodiment of the present invention, the updating module 603 is further configured to link a new symbol in the data file to a file, and associate the data file corresponding to the transaction sequence number of the database transaction with the new symbol;
and updating the new symbolic link name of the data file in the visibility file according to the transaction sequence number of the database transaction.
In an embodiment of the present invention, the commit module 602 is further configured, before the committing the database transaction, to further include: and executing locking operation.
The moving module 604 is further configured to perform an unlocking operation.
Fig. 7 illustrates an exemplary system architecture 700 to which the method of database transaction processing or the apparatus of database transaction processing of embodiments of the invention may be applied.
As shown in fig. 7, the system architecture 700 may include terminal devices 701, 702, 703, a network 704, and a server 705. The network 704 serves to provide a medium for communication links between the terminal devices 701, 702, 703 and the server 705. Network 704 may include various connection types, such as wired, wireless communication links, or fiber optic cables, to name a few.
A user may use the terminal devices 701, 702, 703 to interact with a server 705 over a network 704, to receive or send messages or the like. The terminal devices 701, 702, 703 may have installed thereon various communication client applications, such as a shopping-like application, a web browser application, a search-like application, an instant messaging tool, a mailbox client, social platform software, etc. (by way of example only).
The terminal devices 701, 702, 703 may be various electronic devices having a display screen and supporting web browsing, including but not limited to smart phones, tablet computers, laptop portable computers, desktop computers, and the like.
The server 705 may be a server providing various services, such as a background management server (for example only) providing support for shopping websites browsed by users using the terminal devices 701, 702, 703. The backend management server may analyze and process the received data such as the product information query request, and feed back a processing result (for example, target push information and product information — just an example) to the terminal device.
It should be noted that the method for database transaction processing provided by the embodiment of the present invention is generally executed by the server 705, and accordingly, the apparatus for database transaction processing is generally disposed in the server 705.
It should be understood that the number of terminal devices, networks, and servers in fig. 7 is merely illustrative. There may be any number of terminal devices, networks, and servers, as desired for an implementation.
Referring now to FIG. 8, shown is a block diagram of a computer system 800 suitable for use with a terminal device implementing an embodiment of the present invention. The terminal device shown in fig. 8 is only an example, and should not bring any limitation to the functions and the scope of use of the embodiments of the present invention.
As shown in fig. 8, the computer system 800 includes a Central Processing Unit (CPU)801 that can perform various appropriate actions and processes in accordance with a program stored in a Read Only Memory (ROM)802 or a program loaded from a storage section 808 into a Random Access Memory (RAM) 803. In the RAM 803, various programs and data necessary for the operation of the system 800 are also stored. The CPU 801, ROM 802, and RAM 803 are connected to each other via a bus 804. An input/output (I/O) interface 805 is also connected to bus 804.
The following components are connected to the I/O interface 805: an input portion 806 including a keyboard, a mouse, and the like; an output section 807 including a signal such as a Cathode Ray Tube (CRT), a Liquid Crystal Display (LCD), and the like, and a speaker; a storage portion 808 including a hard disk and the like; and a communication section 809 including a network interface card such as a LAN card, a modem, or the like. The communication section 809 performs communication processing via a network such as the internet. A drive 810 is also connected to the I/O interface 805 as necessary. A removable medium 811 such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, or the like is mounted on the drive 810 as necessary, so that a computer program read out therefrom is mounted on the storage section 808 as necessary.
In particular, according to the embodiments of the present disclosure, the processes described above with reference to the flowcharts may be implemented as computer software programs. For example, embodiments of the present disclosure include a computer program product comprising a computer program embodied on a computer readable medium, the computer program comprising program code for performing the method illustrated in the flow chart. In such an embodiment, the computer program may be downloaded and installed from a network through the communication section 809 and/or installed from the removable medium 811. The computer program executes the above-described functions defined in the system of the present invention when executed by the Central Processing Unit (CPU) 801.
It should be noted that the computer readable medium shown in the present invention can be a computer readable signal medium or a computer readable storage medium or any combination of the two. A computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the foregoing. More specific examples of the computer readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the present invention, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. In the present invention, however, a computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated data signal may take many forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable signal medium may also be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to: wireless, wire, fiber optic cable, RF, etc., or any suitable combination of the foregoing.
The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams or flowchart illustration, and combinations of blocks in the block diagrams or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.
The modules described in the embodiments of the present invention may be implemented by software or hardware. The described modules may also be provided in a processor, which may be described as: a processor includes a logging module, a commit module, an update module, and a move module. Where the names of these modules do not in some cases constitute a limitation on the modules themselves, for example, a logging module may also be described as "logging data file names for database transactions into a recovery file of a temporary directory of distributed nodes".
As another aspect, the present invention also provides a computer-readable medium, which may be contained in the apparatus described in the above embodiments; or may be separate and not incorporated into the device. The computer readable medium carries one or more programs which, when executed by a device, cause the device to comprise:
recording the data file name of the database transaction into a recovery file of a temporary directory of the distributed node;
when the recovery file does not exist in the cloud platform, moving the data file of the database transaction from the temporary directory to a data file directory of the cloud platform, and moving the recovery file of the temporary directory to the data file directory of the cloud platform to submit the database transaction;
updating the symbolic link name of the data file in a visibility file based on the transaction sequence number of the database transaction, wherein the visibility file is used for concurrency control of distributed nodes;
and moving the recovery file of the cloud platform to a directory of a cloud platform shared storage to determine that the database transaction is successfully submitted.
According to the technical scheme of the embodiment of the invention, the data file name of the database transaction is recorded into the recovery file of the temporary directory of the distributed node; when the recovery file does not exist in the cloud platform, moving the data file of the database transaction from the temporary directory to a data file directory of the cloud platform, and moving the recovery file of the temporary directory to the data file directory of the cloud platform to submit the database transaction; updating the symbolic link name of the data file in a visibility file based on the transaction sequence number of the database transaction, wherein the visibility file is used for concurrency control of distributed nodes; and moving the recovery file of the cloud platform to a directory of a cloud platform shared storage to determine that the database transaction is successfully submitted. The distributed nodes upload the data files of the database transaction to the cloud platform to process the database transaction, and other distributed nodes can acquire the data files, so that the efficiency of database transaction processing in a cloud scene can be improved.
The above-described embodiments should not be construed as limiting the scope of the invention. It should be understood by those skilled in the art that various modifications, combinations, sub-combinations and substitutions may occur depending on design requirements and other factors. Any modification, equivalent replacement, and improvement made within the spirit and principle of the present invention should be included in the protection scope of the present invention.

Claims (10)

1. A method of database transaction processing, comprising:
recording the data file name of the database transaction into a recovery file of a temporary directory of the distributed node;
when the recovery file does not exist in the cloud platform, moving the data file of the database transaction from the temporary directory to a data file directory of the cloud platform, and moving the recovery file of the temporary directory to the data file directory of the cloud platform to submit the database transaction;
updating the symbolic link name of the data file in a visibility file based on the transaction sequence number of the database transaction, wherein the visibility file is used for concurrency control of distributed nodes;
and moving the recovery file of the cloud platform to a directory of a cloud platform shared storage to determine that the database transaction is successfully submitted.
2. The method of database transaction processing according to claim 1, wherein the database transaction comprises an update transaction;
before recording the data file name of the database transaction into the recovery file of the temporary directory of the distributed node, the method further includes:
creating a temporary data file at the distributed node, and executing the update transaction in the temporary data file to update the database transaction.
3. The method of database transaction processing according to claim 1, wherein the database transaction comprises a non-update transaction;
before the data file name of the database transaction is recorded in the recovery file of the temporary directory of the distributed node, the method also comprises
And storing the data file of the database transaction into the data file in the temporary directory.
4. The method of database transaction processing according to claim 1, wherein in case of a restore file existing in the cloud platform;
the method further comprises the following steps:
and after deleting the visibility file of the data file in the cloud platform, deleting the newly added file of the data file in the cloud platform and updating the visibility file of the cloud platform.
5. The method of database transaction processing according to claim 1, wherein said method further comprises:
traversing a directory shared and stored by the cloud platform, and determining a cleaning sequence number according to a reference count of the data file, wherein the reference count is used for recording the number of times of calling the data file;
and deleting the data file with the transaction sequence number smaller than or equal to the cleaning sequence number.
6. The method for processing the database transaction according to claim 1, wherein the updating the symbolic link name of the data file in the visibility file based on the transaction sequence number of the database transaction comprises:
linking the new symbol in the data file with the data file corresponding to the transaction sequence number of the database transaction;
and updating the new symbolic link name of the data file in the visibility file according to the transaction sequence number of the database transaction.
7. The method of database transaction processing according to claim 1, wherein said committing said database transaction further comprises: executing locking operation;
after determining that the database transaction is successfully committed, the method further comprises: and executing unlocking operation.
8. An apparatus for database transaction processing, comprising:
the recording module is used for recording the data file name of the database transaction into a recovery file of a temporary directory of the distributed nodes;
the submitting module is used for moving the data files of the database transaction from the temporary directory to a data file directory of the cloud platform and moving the recovery files of the temporary directory to the data file directory of the cloud platform to submit the database transaction under the condition that the recovery files do not exist in the cloud platform;
the updating module is used for updating the symbolic link name of the data file in a visibility file based on the transaction sequence number of the database transaction, and the visibility file is used for concurrency control of distributed nodes;
and the moving module is used for moving the recovery file of the cloud platform to a directory of the cloud platform shared storage so as to determine that the database transaction is successfully submitted.
9. An electronic device for database transaction processing, comprising:
one or more processors;
a storage device for storing one or more programs,
when executed by the one or more processors, cause the one or more processors to implement the method of any one of claims 1-7.
10. A computer-readable medium, on which a computer program is stored, which, when being executed by a processor, carries out the method according to any one of claims 1-7.
CN202210373077.8A 2022-04-11 2022-04-11 Database transaction processing method, device, equipment and computer readable medium Pending CN114722125A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202210373077.8A CN114722125A (en) 2022-04-11 2022-04-11 Database transaction processing method, device, equipment and computer readable medium

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202210373077.8A CN114722125A (en) 2022-04-11 2022-04-11 Database transaction processing method, device, equipment and computer readable medium

Publications (1)

Publication Number Publication Date
CN114722125A true CN114722125A (en) 2022-07-08

Family

ID=82241280

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202210373077.8A Pending CN114722125A (en) 2022-04-11 2022-04-11 Database transaction processing method, device, equipment and computer readable medium

Country Status (1)

Country Link
CN (1) CN114722125A (en)

Citations (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101667178A (en) * 2008-09-01 2010-03-10 北京数码大方科技有限公司 Transaction processing method used for C/S architecture file management system
US20140101102A1 (en) * 2012-10-10 2014-04-10 Apple Inc. Batch processing and data synchronization in cloud-based systems
US20160147809A1 (en) * 2014-11-25 2016-05-26 Ivan Schreter Exporting and Importing Database Tables in a Multi-User Database Environment
CN106462586A (en) * 2014-03-28 2017-02-22 华为技术有限公司 Efficient methods and systems for consistent read in record-based multi-version concurrency control
CN106855890A (en) * 2017-01-09 2017-06-16 广州巨杉软件开发有限公司 A kind of method for realizing the final consistency full-text search of high-performance data storehouse
CN106951559A (en) * 2017-03-31 2017-07-14 联想(北京)有限公司 Data reconstruction method and electronic equipment in distributed file system
US9824095B1 (en) * 2010-05-03 2017-11-21 Panzura, Inc. Using overlay metadata in a cloud controller to generate incremental snapshots for a distributed filesystem
CN107395763A (en) * 2017-08-30 2017-11-24 郑州云海信息技术有限公司 A kind of method, service end and the system of multi-client synchronization process file
US20190050442A1 (en) * 2017-08-08 2019-02-14 International Business Machines Corporation Database recovery using persistent address spaces
US20190163800A1 (en) * 2017-11-30 2019-05-30 International Business Machines Corporation Updating a database
CN111241200A (en) * 2020-01-10 2020-06-05 浙江华创视讯科技有限公司 sSQLite database-based main and standby synchronous processing method and device
CN111597015A (en) * 2020-04-27 2020-08-28 腾讯科技（深圳）有限公司 Transaction processing method and device, computer equipment and storage medium
CN111656340A (en) * 2018-07-06 2020-09-11 斯诺弗雷克公司 Data replication and data failover in a database system
CN111984388A (en) * 2020-08-27 2020-11-24 深圳壹账通智能科技有限公司 Method, device and medium for coordinating data consistency in distributed transactions of cloud environment
CN112286728A (en) * 2020-10-30 2021-01-29 深圳前海微众银行股份有限公司 Data backup method, device, equipment and computer storage medium
CN112384906A (en) * 2018-07-27 2021-02-19 华为技术有限公司 MVCC-based database system asynchronous cache consistency
CN112579698A (en) * 2020-12-02 2021-03-30 京东数字科技控股股份有限公司 Data synchronization method, device, gateway equipment and storage medium
WO2021073571A1 (en) * 2019-10-16 2021-04-22 深圳巨杉数据库软件有限公司 Fragment-free recovery-based database multi-version concurrency control system
CN112925676A (en) * 2021-03-09 2021-06-08 浪潮云信息技术股份公司 Method for realizing recovery of distributed database cluster at any time point based on WAL
CN113778975A (en) * 2021-09-15 2021-12-10 京东科技信息技术有限公司 Data processing method and device based on distributed database

Patent Citations (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101667178A (en) * 2008-09-01 2010-03-10 北京数码大方科技有限公司 Transaction processing method used for C/S architecture file management system
US9824095B1 (en) * 2010-05-03 2017-11-21 Panzura, Inc. Using overlay metadata in a cloud controller to generate incremental snapshots for a distributed filesystem
US20140101102A1 (en) * 2012-10-10 2014-04-10 Apple Inc. Batch processing and data synchronization in cloud-based systems
CN106462586A (en) * 2014-03-28 2017-02-22 华为技术有限公司 Efficient methods and systems for consistent read in record-based multi-version concurrency control
US20160147809A1 (en) * 2014-11-25 2016-05-26 Ivan Schreter Exporting and Importing Database Tables in a Multi-User Database Environment
CN106855890A (en) * 2017-01-09 2017-06-16 广州巨杉软件开发有限公司 A kind of method for realizing the final consistency full-text search of high-performance data storehouse
CN106951559A (en) * 2017-03-31 2017-07-14 联想(北京)有限公司 Data reconstruction method and electronic equipment in distributed file system
US20190050442A1 (en) * 2017-08-08 2019-02-14 International Business Machines Corporation Database recovery using persistent address spaces
CN107395763A (en) * 2017-08-30 2017-11-24 郑州云海信息技术有限公司 A kind of method, service end and the system of multi-client synchronization process file
US20190163800A1 (en) * 2017-11-30 2019-05-30 International Business Machines Corporation Updating a database
CN111656340A (en) * 2018-07-06 2020-09-11 斯诺弗雷克公司 Data replication and data failover in a database system
CN112384906A (en) * 2018-07-27 2021-02-19 华为技术有限公司 MVCC-based database system asynchronous cache consistency
WO2021073571A1 (en) * 2019-10-16 2021-04-22 深圳巨杉数据库软件有限公司 Fragment-free recovery-based database multi-version concurrency control system
CN111241200A (en) * 2020-01-10 2020-06-05 浙江华创视讯科技有限公司 sSQLite database-based main and standby synchronous processing method and device
CN111597015A (en) * 2020-04-27 2020-08-28 腾讯科技（深圳）有限公司 Transaction processing method and device, computer equipment and storage medium
CN111984388A (en) * 2020-08-27 2020-11-24 深圳壹账通智能科技有限公司 Method, device and medium for coordinating data consistency in distributed transactions of cloud environment
CN112286728A (en) * 2020-10-30 2021-01-29 深圳前海微众银行股份有限公司 Data backup method, device, equipment and computer storage medium
CN112579698A (en) * 2020-12-02 2021-03-30 京东数字科技控股股份有限公司 Data synchronization method, device, gateway equipment and storage medium
CN112925676A (en) * 2021-03-09 2021-06-08 浪潮云信息技术股份公司 Method for realizing recovery of distributed database cluster at any time point based on WAL
CN113778975A (en) * 2021-09-15 2021-12-10 京东科技信息技术有限公司 Data processing method and device based on distributed database

Non-Patent Citations (6)

* Cited by examiner, † Cited by third party
Title
KAIWUDB 数据库: "云原生分布式数据库事务隔离级别（上）_分布式事务隔离级别-CSDN博客", Retrieved from the Internet <URL:\'https://blog.csdn.net/ZNBase/article/details/122411003?ops_request_misc=%257B%2522request%255Fid%2522%253A%2522171403011316800182711117%2522%252C%2522scm%2522%253A%252220140713.130102334.pc%255Fall.%2522%257D&request_id=171403011316800182711117&biz_id=0&utm_medium=distribute.pc_search_result.none-task-blog-2~all~first_rank_ecpm_v1~rank_v31_ecpm-2-122411003-null-null.142^v100^pc_search_result_base9&utm_term=%E4%BA%91%E6%95%B0%E6%8D%AE%E5%BA%93%20%E5%88%86%E5%B8%83%E5%BC%8F%20%E4%BA%8B%E5%8A%A1%20MVCC&spm=1018.2226.3001.4187> *
YAO, Y. Y等: "PagePrompter: an intelligent Web agent created using data mining techniques", 《ROUGH SETS AND CURRENT TRENDS IN COMPUTING: THIRD INTERNATIONAL CONFERENCE, RSCTC》, 1 January 2002 (2002-01-01) *
李任: "基于MVCC的NoSQL事务机制的研究和实现", 《中国优秀硕士学位论文全文数据库 信息科技辑》, no. 12, 15 December 2019 (2019-12-15) *
熊莉, 陈松: "一种容错的分布式服务器复制与更新协议", 电脑开发与应用, no. 08, 30 August 2005 (2005-08-30) *
赵泓尧: "内存数据库并发控制算法的实验研究", 《软件学报》, vol. 33, no. 03, 14 March 2022 (2022-03-14) *
黄琳;路京;林中;: "基于影子页面的MMDB的数据恢复方法", 计算机工程与设计, no. 10, 28 May 2008 (2008-05-28) *

Similar Documents

Publication Publication Date Title
US11003689B2 (en) Distributed database transaction protocol
US10936578B2 (en) Client-driven commit of distributed write transactions in a database environment
US9081841B2 (en) Asynchronous distributed garbage collection for replicated storage clusters
US11132350B2 (en) Replicable differential store data structure
US9747356B2 (en) Eager replication of uncommitted transactions
US7702660B2 (en) I/O free recovery set determination
US20180329930A1 (en) Upgrading systems with changing constraints
CN111527487A (en) Assignment and reassignment of unique identifiers for content item synchronization
JP2023546249A (en) Transaction processing methods, devices, computer equipment and computer programs
US8380663B2 (en) Data integrity in a database environment through background synchronization
US11960363B2 (en) Write optimized, distributed, scalable indexing store
EP4189914B1 (en) Using multiple blockchains for applying transactions to a set of persistent data objects in persistent storage systems
US7069270B1 (en) Automated method and mechanism for converting a single instance application to a multiple instance application
US20180276267A1 (en) Methods and system for efficiently performing eventual and transactional edits on distributed metadata in an object storage system
CN111522791B (en) Distributed file repeated data deleting system and method
US11061889B2 (en) Systems and methods of managing manifest refresh in a database
WO2020192663A1 (en) Data management method and related device
US10740320B2 (en) Systems and methods of operation lock management and system catalog overrides in database systems
CN113361236A (en) Method and device for editing document
US11768741B2 (en) Replicating changes written by a transactional virtual storage access method
CN114722125A (en) Database transaction processing method, device, equipment and computer readable medium
CN115185966A (en) Method and device for processing data consistency in distributed cluster
US10459810B2 (en) Technique for higher availability in a multi-node system using replicated lock information to determine a set of data blocks for recovery
US20240126781A1 (en) Consensus protocol for asynchronous database transaction replication with fast, automatic failover, zero data loss, strong consistency, full sql support and horizontal scalability
WO2024081139A1 (en) Consensus protocol for asynchronous database transaction replication with fast, automatic failover, zero data loss, strong consistency, full sql support and horizontal scalability

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination