CN113687921A - Transaction processing method and device, distributed database system and electronic equipment - Google Patents

Transaction processing method and device, distributed database system and electronic equipment Download PDF

Info

Publication number
CN113687921A
CN113687921A CN202111237338.5A CN202111237338A CN113687921A CN 113687921 A CN113687921 A CN 113687921A CN 202111237338 A CN202111237338 A CN 202111237338A CN 113687921 A CN113687921 A CN 113687921A
Authority
CN
China
Prior art keywords
timestamp
transaction
read
preparation
data
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
CN202111237338.5A
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.)
Beijing Kingsoft Cloud Network Technology Co Ltd
Original Assignee
Beijing Kingsoft Cloud Network 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 Beijing Kingsoft Cloud Network Technology Co Ltd filed Critical Beijing Kingsoft Cloud Network Technology Co Ltd
Priority to CN202111237338.5A priority Critical patent/CN113687921A/en
Publication of CN113687921A publication Critical patent/CN113687921A/en
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/466—Transaction 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/23—Updating
    • G06F16/2308—Concurrency control
    • G06F16/2315—Optimistic concurrency control
    • G06F16/2322—Optimistic concurrency control using timestamps
    • 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/2365—Ensuring data consistency and integrity
    • 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/24—Querying
    • G06F16/242—Query formulation
    • G06F16/2433—Query languages
    • 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

Abstract

The embodiment of the invention provides a transaction processing method and device, a distributed database system and electronic equipment, and relates to the technical field of databases. The specific implementation scheme is as follows: when a processing request of a read transaction is received, determining row data for which the read transaction aims; wherein the read transaction carries a read timestamp; if the data state of the row of data is modified by the write transaction and the write transaction is in a preparation state, determining a preparation timestamp corresponding to the write transaction; when the write transaction enters the preparation state, the transaction manager issues the maximum timestamp which is obtained currently to the resource manager; comparing the size of the preparation timestamp and the read timestamp; if the preparation timestamp is greater than or equal to the read timestamp, determining that the current version of the row of data modified by the write transaction is invisible to the read transaction; and if the preparation timestamp is smaller than the read timestamp, blocking the read transaction.

Description

Transaction processing method and device, distributed database system and electronic equipment
Technical Field
The present invention relates to the field of database technologies, and in particular, to a transaction processing method and apparatus, a distributed database system, and an electronic device.
Background
The distributed database is a database constructed on a distributed cluster, and can realize the expansion of transaction processing performance in a mode of dividing data into a plurality of server nodes. In distributed databases, distributed coherent reads of distributed transactions are typically handled in a timestamp-based manner.
In the related art, when a read transaction reads data in a certain row, if the data state of the row of data is modified by a write transaction and the write transaction is in a prepare state, the visibility of the row of data cannot be judged because the read timestamp size of the read transaction and the commit timestamp size of the write transaction cannot be judged. At this point, the read transaction is blocked until the commit timestamp of the write transaction is written to the row of data, i.e., a write-blocking read occurs.
In the process of write blocking reading, lock resources, connection resources and the like held by a read transaction cannot be released in time. If the blocked transaction is too long in latency, it is clear that significant jitter in database performance occurs.
Disclosure of Invention
The embodiment of the invention aims to provide a transaction processing method, a transaction processing device, a distributed database system and electronic equipment, so that the probability of writing blocking reading is reduced to the maximum extent, and the stability of the performance of a database is ensured. The specific technical scheme is as follows:
in a first aspect, an embodiment of the present invention provides a transaction processing method, which is applied to a resource manager, where the method includes:
when a processing request of a read transaction is received, determining row data for which the read transaction aims; wherein the read transaction carries a read timestamp;
if the data state of the row of data is modified by a write transaction and the write transaction is in a ready state, determining a ready timestamp corresponding to the write transaction; when the write transaction enters the preparation state, the transaction manager issues the maximum timestamp which is obtained currently to the resource manager;
comparing the size of the preparation timestamp and the read timestamp;
if the preparation timestamp is greater than or equal to the read timestamp, determining that the current version of the row of data modified by the write transaction is invisible to the read transaction;
and if the preparation timestamp is smaller than the read timestamp, blocking the read transaction.
Optionally, before determining the preparation timestamp corresponding to the write transaction, the method further includes:
and receiving the currently acquired maximum timestamp issued by the transaction manager when the write transaction enters a preparation state, and taking the maximum timestamp as a preparation timestamp corresponding to the write transaction.
Optionally, the receiving, when the write transaction enters a preparation state, a currently acquired maximum timestamp sent by the transaction manager as a preparation timestamp corresponding to the write transaction includes:
receiving an instruction which is issued by the transaction manager and used for indicating the write transaction to enter a preparation state; wherein, the instruction carries the maximum timestamp that the transaction manager has currently acquired;
and extracting the maximum timestamp from the instruction to serve as a preparation timestamp corresponding to the write transaction.
Optionally, after determining that the current version of the row of data modified by the write transaction is invisible to the read transaction, the method further includes:
obtaining a previous version of a current version of the line of data;
comparing the sizes of the commit timestamp and the read timestamp in the previous version;
and if the read timestamp is greater than or equal to the commit timestamp in the previous version, reading the data in the previous version as a response result of the read transaction.
In a second aspect, an embodiment of the present invention provides a distributed database system, where the system includes: a transaction manager and a resource manager;
the resource manager is configured to determine line data to which a read transaction is directed when a processing request of the read transaction is received, where the read transaction carries a read timestamp; if the data state of the row of data is modified by a write transaction and the write transaction is in a preparation state, obtaining a preparation timestamp corresponding to the write transaction, wherein the preparation timestamp is a currently obtained maximum timestamp issued by a transaction manager to a resource manager when the write transaction enters the preparation state; comparing the size of the preparation timestamp and the read timestamp; if the preparation timestamp is greater than or equal to the read timestamp, determining that the current version of the row of data modified by the write transaction is invisible to the read transaction; blocking the read transaction if the preparation timestamp is less than the read timestamp;
and the transaction manager is used for issuing the currently acquired maximum timestamp to the resource manager when the write transaction enters a preparation state.
Optionally, the system further comprises: a global timestamp server;
the transaction manager is further configured to obtain, from the global timestamp server, a timestamp to be utilized by each write transaction/read transaction;
and the global timestamp server is used for distributing timestamps for the write transaction/read transaction.
Optionally, the resource manager is further configured to receive, before determining the preparation timestamp corresponding to the write transaction, a currently acquired maximum timestamp sent by the transaction manager when the write transaction enters a preparation state, as the preparation timestamp corresponding to the write transaction.
Optionally, the resource manager is further configured to: upon determining that the current version of the row of data modified by the write transaction is not visible to the read transaction,
obtaining a previous version of a current version of the line of data;
comparing the sizes of the commit timestamp and the read timestamp in the previous version;
and if the read timestamp is greater than or equal to the commit timestamp in the previous version, reading the data in the previous version as a response result of the read transaction.
In a third aspect, an embodiment of the present invention provides a transaction processing apparatus, applied to a resource manager, where the apparatus includes:
the device comprises a first determination module, a second determination module and a third determination module, wherein the first determination module is used for determining line data aimed at by a read transaction when a processing request of the read transaction is received; wherein the read transaction carries a read timestamp;
a second determining module, configured to determine a preparation timestamp corresponding to the write transaction if the data state of the row of data is modified by the write transaction and the write transaction is in a preparation state; when the write transaction enters the preparation state, the transaction manager issues the maximum timestamp which is obtained currently to the resource manager;
a comparison module for comparing the size of the preparation timestamp and the read timestamp;
a determining module, configured to determine, if the preparation timestamp is greater than or equal to the read timestamp, a current version of the row of data modified by the write transaction, which is invisible to the read transaction;
and a blocking module, configured to block the read transaction if the preparation timestamp is less than the read timestamp.
In a fourth aspect, an embodiment of the present invention provides an electronic device, including a processor, a communication interface, a memory, and a communication bus, where the processor and the communication interface complete communication between the memory and the processor through the communication bus;
a memory for storing a computer program;
and the processor is used for realizing the steps of the transaction processing method when executing the program stored in the memory.
In a fifth aspect, an embodiment of the present invention provides a computer-readable storage medium, in which a computer program is stored, and the computer program, when executed by a processor, implements the above-mentioned transaction processing method steps.
In a sixth aspect, an embodiment of the present invention further provides a computer program product including instructions, which when run on a computer, cause the computer to execute any of the above-mentioned transaction processing methods.
The embodiment of the invention has the following beneficial effects:
after determining the line data to which the read transaction is directed, when the data state of the line data is modified by a write transaction and the write transaction is in a ready state, determining a preparation timestamp corresponding to the write transaction, wherein the preparation timestamp is a maximum timestamp which is sent to the resource manager by the transaction manager and is currently acquired when the write transaction enters the ready state, and one of the maximum timestamps is definitely smaller than a commit timestamp when the write transaction is committed; then, comparing the size of the preparation timestamp with the size of the read timestamp, and if the preparation timestamp is greater than or equal to the read timestamp, determining that the current version of the row of data is invisible to the read transaction; otherwise, blocking the read transaction. Therefore, by introducing the comparison between the preparation timestamp and the read timestamp, the situation that the visibility of the current version of the row of data to the read transaction cannot be judged is reduced, the probability of write blocking read is further reduced to the maximum extent, and the stability of the performance of the database is ensured.
Of course, not all of the advantages described above need to be achieved at the same time in the practice of any one product or method of the invention.
Drawings
In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly described below, it is obvious that the drawings in the following description are only some embodiments of the present invention, and it is obvious for those skilled in the art that other embodiments can be obtained by referring to these drawings.
FIG. 1 is a schematic diagram of a row of data according to an embodiment of the present invention;
fig. 2 is a schematic diagram illustrating an architecture of a transaction processing method according to an embodiment of the present invention;
fig. 3 is a flowchart of a transaction processing method according to an embodiment of the present invention;
FIG. 4 is another flow chart of a transaction processing method according to an embodiment of the present invention;
fig. 5 is a schematic structural diagram of a distributed database system according to an embodiment of the present invention;
fig. 6 is a schematic structural diagram of a transaction processing apparatus according to an embodiment of the present invention;
fig. 7 is a schematic structural diagram of an electronic device according to an embodiment of the present invention.
Detailed Description
The technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the drawings in the embodiments of the present invention, and it is obvious that the described embodiments are only a part of the embodiments of the present invention, and not all of the embodiments. All other embodiments, which can be derived from the embodiments given herein by one of ordinary skill in the art, are within the scope of the invention.
Distributed databases refer to a logically unified database formed by connecting a plurality of physically distributed data storage units using a high-speed computer network. The basic idea of the distributed database is to store data in an original centralized database to a plurality of data storage nodes connected through a network in a scattered manner, so as to obtain a larger storage capacity and a higher concurrent access amount. The distributed transaction means that a participant of the transaction, a server supporting the transaction, a resource manager and a transaction manager are respectively positioned on different nodes of different distributed systems. Essentially, distributed transactions are to ensure data consistency across different databases.
And the write transaction and the read transaction processed by the resource manager belong to branch transactions, and a plurality of branch transactions form a distributed transaction. For an application scenario of MVCC (Multi-Version concurrent Control), a row of data is recorded in the distributed database, and each row of data (which may also be referred to as a row record) may have a plurality of Version data; and, any write transaction is used to generate new version data for a certain line of data; and any read transaction is used to read a visible version of data from the respective version of data of the row of data.
In the related art, a data consistency read of a distributed transaction in a distributed database is generally processed in a timestamp-based manner. When generating a read transaction for a resource manager, a transaction manager requests an opening timestamp of the read transaction, namely RTS (read timestamp), from a global timestamp server, and issues the read transaction to the resource manager through an SQL (Structured Query Language) statement, where the RTS statement carries the RTS. Similarly, when the transaction manager generates a write transaction for the resource manager, the transaction manager also requests the global timestamp server for a start timestamp of the write transaction, and issues the write transaction to the resource manager through an SQL statement, where the write transaction carries the start timestamp; after receiving the write transaction, namely after receiving a processing request of the write transaction, the resource manager performs corresponding processing (namely processing represented by the write transaction) on the row data to which the write transaction aims, namely, starts the write transaction, and at the moment, the write transaction is in an Active state (namely, an Active state); then, in order to ensure distributed data consistency, after the write transaction processes the row data, a segmented commit process is entered:
the first stage is a preparation stage: the transaction manager sends a preparation instruction (Prepare instruction) to the resource manager to inquire whether the resource manager is ready to submit, so that the resource manager returns information about success or failure to the transaction manager according to the self condition; after the resource manager receives the Prepare instruction, the write transaction is in a Prepare state (Prepare state);
the second phase is a transaction commit or rollback phase: if the transaction manager receives the success messages of all the resource managers, the transaction manager sends a Commit instruction (the Commit instruction carries a Commit timestamp) to the resource managers, and after receiving the Commit instruction, the resource managers carry out persistence processing on the version data modified by the write transaction, namely Commit processing; otherwise a rollback instruction is issued. Wherein, rollback refers to the action of program or data processing error and restoring the program or data to the last correct state.
To facilitate understanding of distributed consistent reads for processing distributed transactions in a distributed database in a timestamp-based manner, the following description is made with reference to the accompanying drawings:
as shown in fig. 1, ROW1_ DATA is shown as DATA in the first ROW of DATA, ROW2_ DATA is shown as DATA in the second ROW of DATA, CTS is a commit timestamp persisted onto the ROW of DATA, new _ version represents the latest version of the ROW of DATA, i.e., the current version, and old _ version is the previous version of the current version of the ROW of DATA.
Take the read transaction TrxA to read a certain ROW of data ROW1 as an example:
when ROW1_ DATA is not modified by other transactions, TrxA _ RTS (read timestamp of read transaction) and ROW1_ CTS are comparednew(commit timestamp of the current version of the first line of data), if TrxA _ RTS>=ROW1_CTSnewThe current version of ROW1 is visible to TrxA, at which point TrxA may read the data in the current version of ROW 1; otherwise, it is necessary to trace back to the previous version of the current version of ROW1 and continue to compare the sizes of TrxA _ RTS and ROW1_ CTSold。
When ROW1 is modified by write transaction TrxB and TrxB is in the Active state, then the current version of ROW1 is not visible to TrxA, requiring a trace back to the previous version of ROW1, comparing TrxA _ RTS with ROW1_ CTSold。
When the ROW1 is modified by the write transaction TrxB and TrxB is in the Prepare state, since the CTS of TrxB (the commit timestamp of TrxB, which is the commit timestamp corresponding to the current version modified by TrxB) cannot be known at this time, there is a possibility that TrxA _ RTS is greater than, equal to, or less than TrxB _ CTS (the CTS of TrxB), the data visibility of the current version of the ROW cannot be determined, and TrxA is blocked until TrxB _ CTS is in the Prepare statenewIs written to this row and is called a write-block read.
The read process for ROW2_ DATA is similar to that described above for ROW1_ DATA.
Can clean upIt is understood that while TrxB is in the Active state, the two-phase commit process has not been entered, and the commit timestamp of subsequent requests must be greater than the timestamp of the current read transaction, so the current version of ROW1 is not visible to TrxA. When the TrxB is in the Prepare state, the commit timestamp may have been requested, that is, the request of the timestamp of the read transaction and the commit timestamp of the current write transaction is out of order, so that who is big or small cannot be guaranteed. Thus, TrxA will be blocked until TrxB _ CTSnewIs written into the line data.
In addition, after the write transaction is in the Prepare state, the transaction manager needs to acquire a CTS from the global timestamp server, and after acquiring the CTS, the transaction manager packages the CTS into an XA COMMIT (distributed transaction COMMIT) instruction (i.e., the COMMIT instruction) and issues the CTS to the resource manager. The process takes about two RTTs (Round Trip Time) in total, so the blocked transaction needs to suspend the Time of the two RTTs, and the held lock resources, connection resources and the like cannot be released in Time, which causes obvious jitter in performance.
Based on the above, in order to reduce the probability of write blocking read to the maximum extent and ensure the stable performance of the database, the invention provides a transaction processing method, a transaction processing device, a distributed database system and electronic equipment.
First, a transaction processing method provided in an embodiment of the present invention is described below.
The transaction processing method provided by the embodiment of the invention is applied to a resource manager, and the resource manager is communicated with the transaction manager. In a specific application, as shown in fig. 2, when the transaction manager receives the service SQL statement, two types of distributed transactions, i.e., a write transaction or a read transaction, are generated according to the related content in the service SQL statement and are issued to the resource manager. When the transaction manager executes the distributed transaction, a corresponding timestamp is requested from the global timestamp server, and a relevant execution instruction and the requested timestamp are issued to the resource manager, and the resource manager executes corresponding processing operation.
It is to be understood that the resource manager may be deployed in a storage node for storing data resources in a distributed storage system; and the transaction manager may be deployed in a management node for a distributed data system.
The transaction processing method provided by the embodiment of the invention can comprise the following steps:
when a processing request of a read transaction is received, determining row data for which the read transaction aims; wherein the read transaction carries a read timestamp;
if the data state of the row of data is modified by a write transaction and the write transaction is in a ready state, determining a ready timestamp corresponding to the write transaction; when the write transaction enters the preparation state, the transaction manager issues the maximum timestamp which is obtained currently to the resource manager;
comparing the size of the preparation timestamp and the read timestamp;
if the preparation timestamp is greater than or equal to the read timestamp, determining that the current version of the row of data modified by the write transaction is invisible to the read transaction;
and if the preparation timestamp is smaller than the read timestamp, blocking the read transaction.
In the scheme provided by the embodiment of the invention, after determining the row data to which the read transaction is directed, when the data state of the row data is modified by the write transaction and the write transaction is in a ready state, determining a ready timestamp corresponding to the write transaction, wherein the ready timestamp is a currently acquired maximum timestamp issued by a transaction manager to a resource manager when the write transaction enters the ready state, and is definitely smaller than a commit timestamp when the write transaction is committed; then, comparing the size of the preparation timestamp with the size of the read timestamp, and if the preparation timestamp is greater than or equal to the read timestamp, determining that the current version of the row of data is invisible to the read transaction; otherwise, blocking the read transaction. Therefore, by introducing the comparison between the preparation timestamp and the read timestamp, the situation that the visibility of the current version of the row of data to the read transaction cannot be judged is reduced, the probability of write blocking read is further reduced to the maximum extent, and the stability of the performance of the database is ensured.
The following describes a transaction processing method provided by an embodiment of the present invention with reference to the drawings.
As shown in fig. 3, a transaction processing method provided in an embodiment of the present invention may include the following steps:
s301, when a processing request of a read transaction is received, determining line data to which the read transaction aims; wherein the read transaction carries a read timestamp;
in this embodiment, when the resource manager receives a processing request of a read transaction issued by the transaction manager, the resource manager may analyze information carried in the processing request, so as to determine line data to which the read transaction is directed. The processing request may carry an id of the line data, but is not limited to this. Illustratively, the processing request of the read transaction carries a line data id, and when the resource manager receives the processing request of the read transaction, the line data to which the read transaction is directed is determined according to the line data id.
It can be understood that, when a read transaction reads line data, the sizes of the commit timestamp and the read timestamp of the line data need to be compared, and whether each version data of the line data is visible to the read transaction is determined, so that the read transaction also needs to carry the read timestamp. In an implementation manner, the read timestamp may be carried in a processing request when the transaction manager issues the processing request of the read transaction to the resource manager. Illustratively, before issuing a processing request of a read transaction to a transaction manager, a resource manager requests a read timestamp from a global timestamp server, and after acquiring the read timestamp, issues the processing request carrying the read timestamp to the resource manager.
S302, if the data state of the row of data is modified by a write transaction and the write transaction is in a ready state, determining a ready timestamp corresponding to the write transaction; when the write transaction enters the preparation state, the transaction manager issues the maximum timestamp which is obtained currently to the resource manager;
if the data state of the row of data is modified by the write transaction and the write transaction is in a ready state, at this time, the transaction manager may have requested the commit timestamp of the write transaction from the global timestamp server, so that the sizes of the read timestamp and the commit timestamp of the write transaction cannot be determined. Therefore, in order to reduce the situation that the sizes of the read timestamp and the commit timestamp of the write transaction cannot be determined, in this embodiment, if the data state of the row of data is modified by the write transaction and the write transaction is in a ready state, the ready timestamp corresponding to the write transaction is determined, so that different processing is subsequently performed based on the relationship between the ready timestamp corresponding to the write transaction and the size of the read timestamp of the read transaction.
And when the write transaction enters the preparation state, the transaction manager issues the maximum timestamp which is obtained currently to the resource manager. It will be appreciated that the transaction manager manages multiple transactions and requests timestamps from the global timestamp server at different stages of each transaction, and thus, the transaction manager can retrieve multiple timestamps. At this time, the preparation timestamp is the maximum timestamp which is issued by the transaction manager to the resource manager and is currently acquired when the write transaction enters the preparation phase.
Optionally, before determining the preparation timestamp corresponding to the write transaction, the method further includes:
and receiving the currently acquired maximum timestamp issued by the transaction manager when the write transaction enters a preparation state, and taking the maximum timestamp as a preparation timestamp corresponding to the write transaction.
In this implementation manner, before determining the preparation timestamp corresponding to the write transaction, the resource manager receives the currently acquired maximum timestamp sent by the transaction manager when the write transaction enters the preparation state, and the maximum timestamp is used as the preparation timestamp corresponding to the write transaction. The maximum timestamp may be carried in an instruction issued by the transaction manager to the resource manager, and issued to the resource manager, or may be issued to the resource manager separately.
Optionally, in an implementation manner, the receiving, by the transaction manager, the maximum timestamp that is sent by the transaction manager when the write transaction enters the preparation state and that is currently acquired as the preparation timestamp corresponding to the write transaction includes steps a1-a 2:
a1, receiving an instruction (i.e. the above preparation instruction) issued by the transaction manager and used for instructing the write transaction to enter a preparation state; wherein, the instruction carries the maximum timestamp that the transaction manager has currently acquired;
that is, after receiving the instruction sent by the transaction manager and used for indicating that the write transaction enters the ready state, the resource manager executes the corresponding operation for entering the ready state. The maximum timestamp may be carried in the instruction and sent to the resource manager.
A2, extracting the maximum timestamp from the instruction as a preparation timestamp corresponding to the write transaction.
After receiving the instruction issued by the transaction manager, by analyzing the information carried by the instruction, the maximum timestamp can be extracted from the information carried by the instruction and used as the preparation timestamp corresponding to the write transaction.
Optionally, if the data state of the row of data is modified by a write transaction and the write transaction is in a ready state, before determining a ready timestamp corresponding to the write transaction, the data state of the row of data may also be detected. Any implementation manner of detecting the data state of the line data may be applied to the present embodiment.
Illustratively, the resource manager may have recorded therein status information for each line of data: whether the write transaction is modified or not and if the write transaction is modified, recording the states (Active state and Prepare state) of the write transaction; thus, in one implementation, the data state of the row of data may be detected based on pre-recorded state information subsequent to processing of the read transaction.
For example, after receiving a processing request of a write transaction, the resource manager may record an identification of the write transaction in a current version of the line data modified by the write transaction, and record a transaction state corresponding to the write transaction: the Active state, the Prepare state and the Commit state, when the write transaction is in the Commit state, because the write transaction has completed the Commit phase, it indicates that the line data is not modified by other transactions; thus, in another implementation, the data state of the row of data may be detected based on the identification of the write transaction in the row record.
S303, comparing the sizes of the preparation timestamp and the read timestamp;
in this embodiment, the preparation timestamp determined in step S302 is a timestamp acquired when the read transaction is in a preparation state before being committed, and is definitely smaller than the commit timestamp of the read transaction. Therefore, by further comparing the sizes of the preparation timestamp and the read timestamp, i.e., adding a new comparison object, a more detailed comparison result can be obtained, thereby reducing the situation that the sizes of the read timestamp and the preparation timestamp cannot be judged in the subsequent judgment process.
S304, if the preparation timestamp is larger than or equal to the read timestamp, judging the current version of the row of data modified by the write transaction, and making the current version invisible to the read transaction;
in this embodiment, since the preparation timestamp is smaller than the commit timestamp, if the preparation timestamp is greater than or equal to the read timestamp, the commit timestamp is necessarily greater than the read timestamp, and at this time, the current version of the row of data modified by the write transaction is invisible to the read transaction.
The preparation timestamp is the maximum timestamp which is issued by the transaction manager and is acquired currently when the write transaction enters the preparation state, and is definitely smaller than the commit timestamp of the write transaction, so that a comparison relationship between the preparation timestamp and the read timestamp can be introduced, and further, when the preparation timestamp is greater than or equal to the read timestamp, the current version of the row of data is judged to be invisible to the read transaction, so that the probability of blocking the read transaction is reduced.
S305, if the preparation timestamp is smaller than the read timestamp, blocking the read transaction.
In this embodiment, if the preparation timestamp is smaller than the read timestamp, the read timestamp may be greater than, smaller than, or equal to the commit timestamp, so that the sizes of the commit timestamp and the read timestamp cannot be determined, the visibility of the current version of the row of data to the read transaction cannot be determined, and at this time, the read transaction is blocked until the write transaction completes the commit.
In addition, if the data state of the row data is not modified by the write transaction, or is modified by the write transaction but the write transaction is not in a ready state, the visibility of the current version of the row data to the read transaction needs to be additionally judged.
Illustratively, if the data state of the row of data is not modified by the write transaction, the read timestamp of the read transaction is compared with the commit timestamp of the current version of the row of data, and if the read timestamp is greater than or equal to the commit timestamp, the current version of the row of data is obviously visible to the read transaction, otherwise, the previous version of the row of data needs to be traced back, and the commit timestamps of the read timestamp and the previous version of the row of data are continuously compared.
Illustratively, the data state of the row data is modified by a write transaction, but the write transaction is in an Active state, then the current version of the row data is invisible to the read transaction, and it is necessary to trace back to the previous version of the row data, and continue to compare the read timestamp with the commit timestamp of the previous version of the row data.
In the scheme provided by the embodiment of the invention, after determining the row data to which the read transaction is directed, when the data state of the row data is modified by the write transaction and the write transaction is in a ready state, determining a ready timestamp corresponding to the write transaction, wherein the ready timestamp is a currently acquired maximum timestamp issued by a transaction manager to a resource manager when the write transaction enters the ready state, and is definitely smaller than a commit timestamp when the write transaction is committed; then, comparing the size of the preparation timestamp with the size of the read timestamp, and if the preparation timestamp is greater than or equal to the read timestamp, determining that the current version of the row of data is invisible to the read transaction; otherwise, blocking the read transaction. Therefore, by introducing the comparison between the preparation timestamp and the read timestamp, the situation that the visibility of the current version of the row of data to the read transaction cannot be judged is reduced, the probability of write blocking read is further reduced to the maximum extent, and the stability of the performance of the database is ensured.
Optionally, in another embodiment of the present invention, as shown in fig. 4, after the determining that the current version of the row of data modified by the write transaction is invisible to the read transaction, the method further includes the following steps:
s401, acquiring a previous version of the current version of the line data;
in this embodiment, if the preparation timestamp is greater than or equal to the read timestamp, the commit timestamp of the write transaction is certainly greater than the read timestamp, and the read transaction cannot read the data in the current version of the row of data modified by the write transaction, so that the resource manager needs to obtain the previous version of the current version of the row of data, that is, the row of data targeted by the read transaction traces back to the previous version of the current version of the row of data.
S402, comparing the sizes of the submission timestamp and the reading timestamp in the previous version;
in this embodiment, after the previous version of the current version of the row of data is obtained, the commit timestamp and the read timestamp of the write transaction in the previous version are continuously compared, so as to determine whether the previous version is visible to the read transaction. In one implementation, the commit timestamp is persisted to the row data when the write transaction is committed, and the commit timestamp in the previous version can be found in the row data through information such as id of the write transaction, version of the row data, and the like.
S403, if the read timestamp is greater than or equal to the commit timestamp in the previous version, reading the data in the previous version as a response result of the read transaction.
In this embodiment, if the data read timestamp is greater than or equal to the comparison timestamp in the previous version, the data in the previous version is definitely visible to the read transaction, and at this time, the read transaction reads the data in the previous version.
As can be seen, according to this embodiment, after determining that the current version of the row of data modified by the write transaction is invisible to the read transaction, the commit timestamp and the read timestamp of the write transaction in the previous version are continuously compared, so that the read transaction can continue to read the data in the previous version after the current version is invisible, thereby ensuring normal execution of the read transaction.
To better illustrate the content of embodiments of the present invention, the generation and use of the backup timestamp is described below in connection with a specific example.
Preparation timestamp generation:
(1) when managing the affair, the affair manager records the maximum value of the timestamp obtained currently in real time as Node _ Max _ TS;
(2) when any write transaction enters a ready state, the transaction manager issues a Node _ Max _ TS to a resource manager for processing the write transaction, so that the resource manager takes the received Node _ Max _ TS as a PTS corresponding to the write transaction;
the transaction manager may encapsulate Node _ Max _ TS into an instruction for indicating a ready state of the write transaction, and send the instruction to the resource manager for processing the write transaction; thus, the resource manager can extract the Node _ Max _ TS from the command to obtain the preparation timestamp PTS corresponding to the write transaction.
In addition, in the submitting stage of the write transaction, the transaction manager acquires a CTS from the global timestamp server, packages the CTS into a submitting instruction and sends the submitting instruction to the resource manager; since Node _ MAX _ TS records the maximum timestamp that the transaction manager has acquired when the write transaction enters the ready state, which is certainly less than the timestamp that the global timestamp server has not allocated, it can ensure that PTS < CTS.
Preparation for use of time stamp:
(1) when ROW1 (the line data read by the read transaction TrxA) is not modified by other transactions, TrxA _ RTS (read timestamp of the read transaction) is compared to ROW1_ CTSnew(commit timestamp in latest version), if TrxA _ RTS>= ROW1_CTSnewROW1 is visible to TrxA, otherwise it is necessary to go back to the last version of ROW1 and continue to compare TrxA _ RTS with ROW1_ CTSold(commit timestamp in the previous version).
(2) When ROW1 is modified by the write transaction TrxB and TrxB is in the Active state, then ROW1 current version is invisible to TrxA, and it is necessary to trace back to the last version of ROW1 and compare TrxA _ RTS with ROW1_ CTSold。
(3) When ROW1 is modified by the write transaction TrxB and TrxB is in the Prepare state, TrxA _ RTS and ROW1_ PTS (the corresponding Prepare timestamp for the write transaction) are compared.
If TrxA _ RTS<= ROW1_ PTS, then TrxA _ RTS must be less than commit timestamp of write transaction TrxB, the current version of the ROW of data is invisible to TrxA, it is necessary to go back to the last version of ROW1, and TrxA _ RTS and ROW1_ CTS continue to be comparedold。
If TrxA _ RTS > ROW1_ PTS, the relationship of the sizes of the commit timestamps of TrxA _ RTS and write transaction TrxB cannot be determined, blocking TrxA until TrxB _ CTS is written to the current version of the ROW of data.
Therefore, in the implementation scheme, the preparation timestamp is introduced, so that the probability of writing blocking reading can be reduced to the maximum extent, and the stability of performance data is ensured; and the PTS can be generated with zero overhead, without requiring additional computational resources.
Correspondingly to the foregoing method embodiment, an embodiment of the present invention further provides a distributed database system, as shown in fig. 5, where the system includes: resource manager 510 and transaction manager 520;
the resource manager 510 is configured to determine, when a processing request of a read transaction is received, row data to which the read transaction is directed, where the read transaction carries a read timestamp; if the data state of the row of data is modified by the write transaction and the write transaction is in a ready state, acquiring a ready timestamp corresponding to the write transaction, wherein the ready timestamp is a currently acquired maximum timestamp issued by the transaction manager 520 to the resource manager when the write transaction enters the ready state; comparing the size of the preparation timestamp and the read timestamp; if the preparation timestamp is greater than or equal to the read timestamp, determining that the current version of the row of data modified by the write transaction is invisible to the read transaction; blocking the read transaction if the preparation timestamp is less than the read timestamp;
the transaction manager 520 is configured to send the currently acquired maximum timestamp to the resource manager 510 when the write transaction enters the ready state.
Optionally, the system further comprises: a global timestamp server;
the transaction manager is further configured to obtain, from the global timestamp server, a timestamp to be utilized by each write transaction/read transaction;
and the global timestamp server is used for distributing timestamps for the write transaction/read transaction.
Optionally, the resource manager is further configured to receive, before determining the preparation timestamp corresponding to the write transaction, a currently acquired maximum timestamp sent by the transaction manager when the write transaction enters a preparation state, as the preparation timestamp corresponding to the write transaction.
Optionally, the resource manager is specifically configured to:
receiving an instruction which is issued by the transaction manager and used for indicating the write transaction to enter a preparation state; wherein, the instruction carries the maximum timestamp that the transaction manager has currently acquired;
and extracting the maximum timestamp from the instruction to serve as a preparation timestamp corresponding to the write transaction.
Optionally, the resource manager is further configured to: upon determining that the current version of the row of data modified by the write transaction is not visible to the read transaction,
obtaining a previous version of a current version of the line of data;
comparing the sizes of the commit timestamp and the read timestamp in the previous version;
and if the read timestamp is greater than or equal to the commit timestamp in the previous version, reading the data in the previous version as a response result of the read transaction.
Corresponding to the foregoing method embodiment, an embodiment of the present invention further provides a transaction processing apparatus, which is applied to a resource manager, and as shown in fig. 6, the apparatus includes:
a first determining module 610, configured to determine, when a processing request of a read transaction is received, line data to which the read transaction is directed; wherein the read transaction carries a read timestamp;
a second determining module 620, configured to determine a preparation timestamp corresponding to the write transaction if the data state of the row of data is modified by the write transaction and the write transaction is in a preparation state; when the write transaction enters the preparation state, the transaction manager issues the maximum timestamp which is obtained currently to the resource manager;
a comparison module 630 for comparing the sizes of the preparation timestamp and the read timestamp;
a determining module 640, configured to determine, if the preparation timestamp is greater than or equal to the read timestamp, a current version of the row of data modified by the write transaction, which is invisible to the read transaction;
a blocking module 650, configured to block the read transaction if the preparation timestamp is smaller than the read timestamp.
Optionally, the apparatus further comprises:
a receiving module, configured to receive, before the second determining module executes the preparation timestamp corresponding to the write transaction, a currently acquired maximum timestamp issued by the transaction manager when the write transaction enters a preparation state, as the preparation timestamp corresponding to the write transaction.
Optionally, the receiving module is specifically configured to:
receiving an instruction which is issued by the transaction manager and used for indicating the write transaction to enter a preparation state; wherein, the instruction carries the maximum timestamp that the transaction manager has currently acquired;
and extracting the maximum timestamp from the instruction to serve as a preparation timestamp corresponding to the write transaction.
Optionally, the apparatus further comprises:
an obtaining module, configured to obtain a previous version of the current version of the line data after the determining module performs the determining that the current version of the line data modified by the write transaction is invisible to the read transaction;
the second comparison module is used for comparing the sizes of the submission timestamp and the reading timestamp in the previous version;
and the reading module is used for reading the data in the previous version as a response result of the read transaction if the read timestamp is greater than or equal to the commit timestamp in the previous version.
An embodiment of the present invention further provides an electronic device, as shown in fig. 7, including a processor 701, a communication interface 702, a memory 703 and a communication bus 704, where the processor 701, the communication interface 702, and the memory 703 complete mutual communication through the communication bus 704,
a memory 703 for storing a computer program;
the processor 701 is configured to implement the steps of any of the transaction processing methods provided in the foregoing embodiments of the present invention when executing the program stored in the memory 703.
The communication bus mentioned in the electronic device may be a Peripheral Component Interconnect (PCI) bus, an Extended Industry Standard Architecture (EISA) bus, or the like. The communication bus may be divided into an address bus, a data bus, a control bus, etc. For ease of illustration, only one thick line is shown, but this does not mean that there is only one bus or one type of bus.
The communication interface is used for communication between the electronic equipment and other equipment.
The Memory may include a Random Access Memory (RAM) or a Non-Volatile Memory (NVM), such as at least one disk Memory. Optionally, the memory may also be at least one memory device located remotely from the processor.
The Processor may be a general-purpose Processor, including a Central Processing Unit (CPU), a Network Processor (NP), and the like; but also Digital Signal Processors (DSPs), Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs) or other Programmable logic devices, discrete Gate or transistor logic devices, discrete hardware components.
In yet another embodiment of the present invention, a computer-readable storage medium is further provided, in which a computer program is stored, and the computer program realizes the steps of any one of the above transaction processing methods when executed by a processor.
In yet another embodiment, a computer program product containing instructions is provided, which when run on a computer causes the computer to perform any of the above-described transaction processing methods.
In the above embodiments, the implementation may be wholly or partially realized by software, hardware, firmware, or any combination thereof. When implemented in software, may be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When loaded and executed on a computer, cause the processes or functions described in accordance with the embodiments of the invention to occur, in whole or in part. The computer may be a general purpose computer, a special purpose computer, a network of computers, or other programmable device. The computer instructions may be stored in a computer readable storage medium or transmitted from one computer readable storage medium to another, for example, from one website site, computer, server, or data center to another website site, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, Digital Subscriber Line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.). The computer-readable storage medium can be any available medium that can be accessed by a computer or a data storage device, such as a server, a data center, etc., that incorporates one or more of the available media. The usable medium may be a magnetic medium (e.g., floppy Disk, hard Disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., Solid State Disk (SSD)), among others.
It is noted that, herein, relational terms such as first and second, and the like may be used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. Also, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other identical elements in a process, method, article, or apparatus that comprises the element.
All the embodiments in the present specification are described in a related manner, and the same and similar parts among the embodiments may be referred to each other, and each embodiment focuses on the differences from the other embodiments. In particular, for the system embodiment, since it is substantially similar to the method embodiment, the description is simple, and for the relevant points, reference may be made to the partial description of the method embodiment.
The above description is only for the preferred embodiment of the present invention, and is not intended to limit the scope of the present invention. Any modification, equivalent replacement, or improvement made within the spirit and principle of the present invention shall fall within the protection scope of the present invention.

Claims (11)

1. A transaction processing method applied to a resource manager, the method comprising:
when a processing request of a read transaction is received, determining row data for which the read transaction aims; wherein the read transaction carries a read timestamp;
if the data state of the row of data is modified by a write transaction and the write transaction is in a ready state, determining a ready timestamp corresponding to the write transaction; when the write transaction enters the preparation state, the transaction manager issues the maximum timestamp which is obtained currently to the resource manager;
comparing the size of the preparation timestamp and the read timestamp;
if the preparation timestamp is greater than or equal to the read timestamp, determining that the current version of the row of data modified by the write transaction is invisible to the read transaction;
and if the preparation timestamp is smaller than the read timestamp, blocking the read transaction.
2. The method of claim 1, wherein prior to determining the preparation timestamp corresponding to the write transaction, the method further comprises:
and receiving the currently acquired maximum timestamp issued by the transaction manager when the write transaction enters a preparation state, and taking the maximum timestamp as a preparation timestamp corresponding to the write transaction.
3. The method according to claim 2, wherein the receiving, by the transaction manager, the currently acquired maximum timestamp sent down when the write transaction enters the ready state as the ready timestamp corresponding to the write transaction includes:
receiving an instruction which is issued by the transaction manager and used for indicating the write transaction to enter a preparation state; wherein, the instruction carries the maximum timestamp that the transaction manager has currently acquired;
and extracting the maximum timestamp from the instruction to serve as a preparation timestamp corresponding to the write transaction.
4. The method of claim 1, wherein after determining that the current version of the row of data modified by the write transaction is not visible to the read transaction, the method further comprises:
obtaining a previous version of a current version of the line of data;
comparing the sizes of the commit timestamp and the read timestamp in the previous version;
and if the read timestamp is greater than or equal to the commit timestamp in the previous version, reading the data in the previous version as a response result of the read transaction.
5. A distributed database system, the system comprising: a transaction manager and a resource manager;
the resource manager is configured to determine line data to which a read transaction is directed when a processing request of the read transaction is received, where the read transaction carries a read timestamp; if the data state of the row of data is modified by a write transaction and the write transaction is in a preparation state, obtaining a preparation timestamp corresponding to the write transaction, wherein the preparation timestamp is a currently obtained maximum timestamp issued by a transaction manager to a resource manager when the write transaction enters the preparation state; comparing the size of the preparation timestamp and the read timestamp; if the preparation timestamp is greater than or equal to the read timestamp, determining that the current version of the row of data modified by the write transaction is invisible to the read transaction; blocking the read transaction if the preparation timestamp is less than the read timestamp;
and the transaction manager is used for issuing the currently acquired maximum timestamp to the resource manager when the write transaction enters a preparation state.
6. The system of claim 5, further comprising: a global timestamp server;
the transaction manager is further configured to obtain, from the global timestamp server, a timestamp to be utilized by each write transaction/read transaction;
and the global timestamp server is used for distributing timestamps for the write transaction/read transaction.
7. The system according to claim 5, wherein the resource manager is further configured to receive, before determining the preparation timestamp corresponding to the write transaction, a currently obtained maximum timestamp issued by the transaction manager when the write transaction enters a preparation state, as the preparation timestamp corresponding to the write transaction.
8. The system of claim 5, wherein the resource manager is further configured to: upon determining that the current version of the row of data modified by the write transaction is not visible to the read transaction,
obtaining a previous version of a current version of the line of data;
comparing the sizes of the commit timestamp and the read timestamp in the previous version;
and if the read timestamp is greater than or equal to the commit timestamp in the previous version, reading the data in the previous version as a response result of the read transaction.
9. A transaction processing apparatus applied to a resource manager, the apparatus comprising:
the device comprises a first determination module, a second determination module and a third determination module, wherein the first determination module is used for determining line data aimed at by a read transaction when a processing request of the read transaction is received; wherein the read transaction carries a read timestamp;
a second determining module, configured to determine a preparation timestamp corresponding to the write transaction if the data state of the row of data is modified by the write transaction and the write transaction is in a preparation state; when the write transaction enters the preparation state, the transaction manager issues the maximum timestamp which is obtained currently to the resource manager;
a comparison module for comparing the size of the preparation timestamp and the read timestamp;
a determining module, configured to determine, if the preparation timestamp is greater than or equal to the read timestamp, a current version of the row of data modified by the write transaction, which is invisible to the read transaction;
and a blocking module, configured to block the read transaction if the preparation timestamp is less than the read timestamp.
10. An electronic device is characterized by comprising a processor, a communication interface, a memory and a communication bus, wherein the processor and the communication interface are used for realizing mutual communication by the memory through the communication bus;
a memory for storing a computer program;
a processor for implementing the method steps of any one of claims 1 to 4 when executing a program stored in the memory.
11. A computer-readable storage medium, characterized in that a computer program is stored in the computer-readable storage medium, which computer program, when being executed by a processor, carries out the method steps of any one of claims 1-4.
CN202111237338.5A 2021-10-25 2021-10-25 Transaction processing method and device, distributed database system and electronic equipment Pending CN113687921A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202111237338.5A CN113687921A (en) 2021-10-25 2021-10-25 Transaction processing method and device, distributed database system and electronic equipment

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202111237338.5A CN113687921A (en) 2021-10-25 2021-10-25 Transaction processing method and device, distributed database system and electronic equipment

Publications (1)

Publication Number Publication Date
CN113687921A true CN113687921A (en) 2021-11-23

Family

ID=78587745

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202111237338.5A Pending CN113687921A (en) 2021-10-25 2021-10-25 Transaction processing method and device, distributed database system and electronic equipment

Country Status (1)

Country Link
CN (1) CN113687921A (en)

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109582686A (en) * 2018-12-13 2019-04-05 中山大学 Distributed meta-data management consistency ensuring method, device, system and application
US20190243908A1 (en) * 2018-02-05 2019-08-08 Electronics And Telecommunications Research Institute Storage server and adaptive prefetching method performed by storage server in distributed file system
CN111475493A (en) * 2020-06-19 2020-07-31 阿里云计算有限公司 Data reading method and device
CN111868707A (en) * 2018-03-13 2020-10-30 谷歌有限责任公司 Including transaction commit timestamps in a primary key of a relational database
US20210034605A1 (en) * 2019-08-02 2021-02-04 Alibaba Group Holding Limited Transaction processing for a database distributed across availability zones
CN112948064A (en) * 2021-02-23 2021-06-11 北京金山云网络技术有限公司 Data reading method and device and data reading system

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20190243908A1 (en) * 2018-02-05 2019-08-08 Electronics And Telecommunications Research Institute Storage server and adaptive prefetching method performed by storage server in distributed file system
CN111868707A (en) * 2018-03-13 2020-10-30 谷歌有限责任公司 Including transaction commit timestamps in a primary key of a relational database
CN109582686A (en) * 2018-12-13 2019-04-05 中山大学 Distributed meta-data management consistency ensuring method, device, system and application
US20210034605A1 (en) * 2019-08-02 2021-02-04 Alibaba Group Holding Limited Transaction processing for a database distributed across availability zones
CN111475493A (en) * 2020-06-19 2020-07-31 阿里云计算有限公司 Data reading method and device
CN112948064A (en) * 2021-02-23 2021-06-11 北京金山云网络技术有限公司 Data reading method and device and data reading system

Similar Documents

Publication Publication Date Title
WO2021180025A1 (en) Message processing method and apparatus, electronic device and medium
CN102831156B (en) Distributed transaction processing method on cloud computing platform
US8799213B2 (en) Combining capture and apply in a distributed information sharing system
WO2020181810A1 (en) Data processing method and apparatus applied to multi-level caching in cluster
US6970872B1 (en) Techniques for reducing latency in a multi-node system when obtaining a resource that does not reside in cache
US9514170B1 (en) Priority queue using two differently-indexed single-index tables
CN110008041B (en) Message processing method and device
US20220318095A1 (en) Using a storage log to generate an incremental backup
CN112434043B (en) Data synchronization method, device, electronic equipment and medium
WO2019109854A1 (en) Data processing method and device for distributed database, storage medium, and electronic device
US11880290B2 (en) Scalable exactly-once data processing using transactional streaming writes
JP2023541298A (en) Transaction processing methods, systems, devices, equipment, and programs
CN112307119A (en) Data synchronization method, device, equipment and storage medium
CN112231070A (en) Data writing and reading method and device and server
WO2022242372A1 (en) Object processing method and apparatus, computer device, and storage medium
CN114741449A (en) Object storage method and device based on distributed database
US11061889B2 (en) Systems and methods of managing manifest refresh in a database
CN110019527B (en) Slave library reading method, related device and equipment
WO2024027057A1 (en) Data rollback method and apparatus, and device and storage medium therefor
CN110659303A (en) Read-write control method and device for database nodes
CN113687921A (en) Transaction processing method and device, distributed database system and electronic equipment
CN115629822A (en) Concurrent transaction processing method and system based on multi-core processor
CN111753141A (en) Data management method and related equipment
KR102123616B1 (en) Method and apparatus for parallel journaling using conflict page list
CN114064725A (en) Data processing method, device, equipment and storage medium

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