Database data state determination method and apparatus, and computer device

Abstract

The present disclosure provides a data state determination method and device of a database, a computer device and a storage medium, and the method comprises: acquiring a first transaction in the database and determining a first timestamp log corresponding to the first transaction, wherein the first transaction is used to indicate a read operation on data in the database; determining a second timestamp log of a second transaction, wherein the second transaction is used to indicate a data processing operation on data in the database; and determining a visible state of the second transaction relative to the first transaction based on a comparison result of the first timestamp log and the second timestamp log, thereby judging the visibility between transactions based on the timestamp log, and the data amount of the timestamp log is much smaller than that of the active transaction list, so that the present disclosure reduces the data maintenance cost and improves the database performance.

Description

TECHNICAL FIELD

[0001] The present disclosure relates to the technical field of database, and in particular, to a data state determination method and device of database, a computer device and a storage medium. BACKGROUND

[0002] Data consistency is one of the basic properties that a database must satisfy. As the core of data management, an effective visibility judgment method is an important means to ensure the consistency of the database, and the efficiency of the visibility judgment will also affect the overall performance of the database.

[0003] At present, the visibility judgment method based on the active transaction list is the most common visibility judgment method, wherein the active transaction list can include the commit state of a transaction. It should be understood that when reading data in the database through a read transaction, the committed transaction is visible to the read transaction. Here, the active transaction list is widely used in various commercial distributed relational databases. By maintaining the active transaction list, each transaction obtains its own active transaction list when it is started. When the business pressure is large and the degree of transaction concurrency is high, each transaction needs to maintain its own active transaction list, and during this period, it also involves locking and unlocking operations, which generally has high overhead and has become one of the important performance bottlenecks of the current mainstream database. SUMMARY

[0004] The embodiments of the present disclosure at least provide a data state determination method and device of database, a computer device and a storage medium.

[0005] In a first aspect, the embodiments of the present disclosure provide a data state determination method of database, comprising:

[0006] obtaining a first transaction in the database and determining a first timestamp log corresponding to the first transaction, wherein the first transaction is used to indicate a read operation on data in the database;

[0007] determining a second timestamp log of a second transaction, wherein the second transaction is used to indicate a data processing operation on data in the database;

[0008] determining a visible state of the second transaction relative to the first transaction based on a comparison result of the first timestamp log and the second timestamp log.

[0009] In an optional implementation, the determining of the visible state of the second transaction relative to the first transaction based on the comparison result of the first timestamp log and the second timestamp log comprises:

[0010] reading a second timestamp value of the second timestamp log and determining a processing state of the second transaction based on the second timestamp value;

[0011] In a case where the processing state is a target state, a first timestamp value of the first timestamp log is determined, and in a case where the first timestamp value is greater than the second timestamp value, the second transaction is determined to be visible with respect to the first transaction, wherein the target state is used to indicate that the second transaction has been committed;

[0012] In a case where the processing state is a non-target state, the second transaction is determined to be invisible with respect to the first transaction, wherein the target state is used to indicate that the second transaction has not been committed.

[0013] In an optional implementation, the method further includes:

[0014] determining a preset timestamp value;

[0015] In a case where the second timestamp value of the second timestamp log hits the preset timestamp value, the processing state is determined to be a non-target state;

[0016] In a case where the second timestamp value of the second timestamp log does not hit the preset timestamp value, the processing state is determined to be a target state.

[0017] In an optional implementation, the non-target state includes an initialization state, an abort state, and a commit-in-progress state.

[0018] The determining of the preset timestamp value includes:

[0019] a corresponding state value is set for each non-target state, and a preset radix is determined;

[0020] Based on the preset radix, the state value is converted into a corresponding timestamp to obtain a preset timestamp.

[0021] In an optional implementation, the second timestamp log includes a state bit, a physical timestamp, and a logical timestamp.

[0022] The determining of the second timestamp log of the second transaction includes:

[0023] a transaction type of the second transaction is determined, and the state bit value is determined based on the transaction type;

[0024] a real-time machine time is obtained, and the physical timestamp is determined based on the machine time;

[0025] In a case where the physical timestamp is the same, the logical timestamp is determined based on a time sequence of the second transaction in a second transaction queue;

[0026] According to the state bit value, the physical timestamp, and the logical timestamp, a second timestamp log of the second transaction is determined.

[0027] In an alternative embodiment, the method further comprises:

[0028] After the second timestamp log of the second transaction is determined, a transaction type of the second transaction is determined based on the second timestamp log.

[0029] In a case where the transaction type is a distributed transaction, a related transaction of the second transaction is determined, and a third timestamp log of the related transaction is determined.

[0030] Based on the second timestamp log and the third timestamp log, and a comparison result of the first timestamp log, a visible state of the second transaction relative to the first transaction is determined.

[0031] In a case where the transaction type is a sub-transaction, a parent transaction of the second transaction is determined, and a fourth timestamp log of the parent transaction is determined.

[0032] Based on a comparison result of the fourth timestamp log and the first timestamp log, a visible state of the second transaction relative to the first transaction is determined.

[0033] In an alternative embodiment, the determination of the second timestamp log of the second transaction further comprises:

[0034] After the database is restarted, the processing state of the second transaction is re-determined.

[0035] In a case where the second transaction is determined to have been committed based on the processing state, a target commit timestamp preset is obtained, and the second timestamp log is determined according to the target commit timestamp.

[0036] In a case where the second transaction is determined not to have been committed based on the processing state, a preset timestamp value is determined, and the second timestamp log is determined according to the preset commit timestamp.

[0037] In an alternative embodiment, the method further comprises:

[0038] After the log format conversion instruction is received, a processing state of the first transaction is determined based on the first timestamp log, and a transaction state log of the first transaction is generated based on the processing state; and

[0039] A processing state of the second transaction is determined based on the second timestamp log, and a transaction state log of the second transaction is generated based on the processing state.

[0040] In a second aspect, the present disclosure provides a data state determination apparatus for a database, comprising:

[0041] an acquisition unit configured to acquire a first transaction in the database and determine a first timestamp log corresponding to the first transaction, wherein the first transaction is used to indicate a read operation on data in the database;

[0042] a first determination unit configured to determine a second timestamp log of a second transaction, wherein the second transaction is used to indicate a data processing operation on data in the database;

[0043] a second determination unit configured to determine a visible state of the second transaction relative to the first transaction based on a comparison result of the first timestamp log and the second timestamp log.

[0044] In a third aspect, the present disclosure provides a computer device, comprising a processor, a memory and a bus, wherein the memory stores machine readable instructions executable by the processor, and the processor and the memory communicate through the bus when the computer device is running, and the machine readable instructions are executed by the processor to perform the steps of the first aspect or any possible implementation manner of the first aspect.

[0045] In a fourth aspect, the present disclosure provides a computer readable storage medium, which stores a computer program, and the computer program is executed by a processor to perform the steps of the first aspect or any possible implementation manner of the first aspect.

[0046] In the present disclosure, first, a first transaction in the database can be acquired and a first timestamp log corresponding to the first transaction can be determined, wherein the first transaction is used to indicate a read operation on data in the database. Then, a second timestamp log of a second transaction can be determined, wherein the second transaction is used to indicate a data processing operation on data in the database. Next, the first timestamp log and the second timestamp log can be compared to obtain a comparison result, and the visible state of the second transaction relative to the first transaction can be determined based on the comparison result, so that the visibility between transactions can be determined based on the timestamp log, the data amount of the timestamp log is much smaller than that of the active transaction list, the maintenance cost is reduced, and the database performance is improved.

[0047] In order to make the above objectives, characteristics and advantages of the present disclosure more apparent and understandable, the following preferred embodiments are described in detail below, and the accompanying drawings are referred to. BRIEF DESCRIPTION OF DRAWINGS

[0048] In order to more clearly illustrate the technical solutions of the embodiments of the present disclosure, the following will briefly introduce the drawings needed to be used in the embodiments. The drawings incorporated into the specification and form a part of the specification, which show the embodiments consistent with the present disclosure, and are used to explain the technical solutions of the present disclosure together with the specification. It should be understood that the following drawings only show some of the embodiments of the present disclosure, and therefore should not be considered as a limitation to the scope, and for those skilled in the art, other related drawings can also be obtained without creative labor.

[0049] Figure 1 A flow chart of a method for determining a data state of a database is shown;

[0050] Figure 2 A flow chart of a method for determining a second timestamp log of a second transaction is shown;

[0051] Figure 3 A flow chart of another method for determining a second timestamp log of a second transaction is shown;

[0052] Figure 4 A schematic diagram of a device for determining a data state of a database is shown;

[0053] Figure 5 A schematic diagram of a computer device is shown. DETAILED DESCRIPTION

[0054] In order to make the objects, technical solutions and advantages of the embodiments of the present disclosure clearer, the following will combine the drawings in the embodiments of the present disclosure to make a clear and complete description of the technical solutions in the embodiments of the present disclosure. Obviously, the described embodiments are only some of the embodiments of the present disclosure, but not all the embodiments. The components of the embodiments of the present disclosure described and shown in the drawings can be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of the present disclosure provided in the drawings is not intended to limit the scope of the claimed present disclosure, but only represents selected embodiments of the present disclosure. Based on the embodiments of the present disclosure, all other embodiments obtained by those skilled in the art without creative labor are within the scope of protection of the present disclosure.

[0055] It should be noted that: similar reference numerals and letters represent similar items in the following drawings, and therefore, once an item is defined in one drawing, it does not need to be further defined and explained in the subsequent drawings.

[0056] The term "and / or", merely describes an associated relationship, which means that there can be three relationships, for example, A and / or B, which can represent: A exists alone, A and B exist together, and B exists alone. In addition, the term "at least one" herein means any one of a plurality or any combination of at least two of a plurality, for example, including at least one of A, B, C, which can mean selecting any one or more elements from a set consisting of A, B, and C.

[0057] It is found through research that data consistency is one of the basic properties that a database must satisfy. As the core of data management, an effective visibility judgment method is an important means to ensure the consistency of the database, and the efficiency of the visibility judgment will also affect the overall performance of the database.

[0058] At present, the visibility judgment method based on the active transaction list is the most common visibility judgment method, wherein the active transaction list can include the commit state of the transaction. It should be understood that when reading data in the database through a read transaction, the committed transaction is visible to the read transaction. Here, the active transaction list is widely used in various commercial distributed relational databases. By maintaining the active transaction list, each transaction obtains its own active transaction list when it is started. When the business pressure is large and the transaction concurrency is high, each transaction needs to maintain its own active transaction list, and during this period, it also involves locking and unlocking operations, which generally has high overhead and has become one of the important performance bottlenecks of the current mainstream database.

[0059] Based on the above research, the present disclosure provides a data state determination method and device of a database, a computer device, and a storage medium. In the embodiment of the present disclosure, first, a first transaction in the database can be obtained and a first timestamp log corresponding to the first transaction is determined, wherein the first transaction is used to indicate a read operation on data in the database. Then, a second timestamp log of a second transaction is determined, wherein the second transaction is used to indicate a data processing operation on data in the database. Next, the first timestamp log and the second timestamp log are compared to obtain a comparison result, and the visible state of the second transaction relative to the first transaction is determined based on the comparison result, so that the visibility between transactions can be judged based on the timestamp log. The data amount of the timestamp log is much smaller than that of the active transaction list, which reduces the maintenance cost and improves the performance of the database.

[0060] For the convenience of understanding the present embodiment, first, a database data state determination method disclosed by the present embodiment is introduced in detail, and the execution subject of the database data state determination method provided by the present embodiment is generally a computer device with certain computing power. In some possible implementation manners, the database data state determination method can be realized by calling the computer readable instructions stored in the memory by the processor.

[0061] Referring to Figure 1 The flowchart of the database data state determination method provided by the present embodiment is shown, and the method comprises steps S101-S105, wherein:

[0062] S101: acquiring a first transaction in the database and determining a first timestamp log corresponding to the first transaction, wherein the first transaction is used to indicate a read operation on data in the database.

[0063] In the present embodiment, the first transaction can be a read transaction in the database, wherein the read transaction is used to indicate a read operation on data in the database. Therefore, it is necessary to determine the transaction visible to the read transaction, so as to perform a read operation on the data corresponding to the transaction.

[0064] After detecting the first transaction, a read timestamp can be generated for the first transaction based on the establishment time of the first transaction, and a first timestamp log can be generated based on the read timestamp, wherein the read timestamp can be a timestamp with a preset number of bits, for example, 64 bits. Here, the way to determine the first timestamp log is described as follows, which is not expanded here.

[0065] S103: determining a second timestamp log of a second transaction, wherein the second transaction is used to indicate a data processing operation on data in the database.

[0066] In the present embodiment, the second transaction can be a write transaction in the database, which can be used to indicate a data processing operation on data in the database, and the data processing operation can be used to indicate data storage, data modification, data deletion and other operations in the database.

[0067] After detecting the second transaction, a fusion timestamp can be generated for the first transaction based on the commit time of the second transaction. Considering that the second transaction in the processing process is invisible, therefore, in addition to being used to indicate the commit time of the second transaction, the fusion timestamp can also be used to indicate the transaction type and processing state of the second transaction, and the number of bits of the fusion timestamp can be the same as that of the read timestamp, so as to facilitate comparison between the two. Here, the way to determine the second timestamp log is described as follows, which is not expanded here.

[0068] S105: determining the visible state of the second transaction relative to the first transaction based on the comparison result of the first timestamp log and the second timestamp log.

[0069] In the embodiments of the present disclosure, the value of the read timestamp in the first timestamp log and the value of the fusion timestamp in the second timestamp log can be calculated respectively, and the values are compared to obtain a comparison result. Here, the comparison result can be used to indicate whether the second transaction has been committed, if yes, the visible state of the second transaction relative to the first transaction is visible; if no, the visible state of the second transaction relative to the first transaction is invisible.

[0070] Specifically, first, the processing state of the second transaction can be determined based on the fusion timestamp, wherein the processing state includes a committed state and an uncommitted state. When the second transaction is in the uncommitted state, it is directly determined that the visible state of the second transaction relative to the first transaction is invisible.

[0071] If the second transaction is in the committed state, the value of the fusion timestamp is compared with the read timestamp in the first timestamp log. If the value of the fusion timestamp is greater than the read timestamp, it indicates that the second transaction has been successfully committed when the first transaction is established, and the visible state of the second transaction relative to the first transaction is visible. If the value of the fusion timestamp is not greater than the read timestamp, it indicates that the second transaction has not been successfully committed when the first transaction is established, and the visible state of the second transaction relative to the first transaction is invisible.

[0072] As can be seen from the above description, in the embodiments of the present disclosure, first, the first transaction in the database can be acquired and the first timestamp log corresponding to the first transaction is determined, wherein the first transaction is used to indicate a read operation on the data in the database. Then, the second timestamp log of the second transaction can be determined, wherein the second transaction is used to indicate a data processing operation on the data in the database. Next, the first timestamp log and the second timestamp log are compared to obtain a comparison result, and the visible state of the second transaction relative to the first transaction is determined based on the comparison result, so that the visibility between transactions can be determined based on the timestamp log, the data amount of the timestamp log is much smaller than the active transaction list, the maintenance cost is reduced, and the database performance is improved.

[0073] In an optional implementation, the second timestamp log includes a state bit, a physical timestamp and a logical timestamp, as shown in Figure 2 FIG. 10 shows a flowchart of the process of determining the second timestamp log of the second transaction in step S103, which specifically includes the following processes:

[0074] S11: determining the transaction type of the second transaction, and determining the value of the state bit based on the transaction type.

[0075] S12: Obtain a real-time machine time, and determine the physical timestamp based on the machine time.

[0076] S13: In the case that the physical timestamps are the same, determine the logical timestamp based on the sequence of the second transaction in the second transaction queue.

[0077] S14: Determine the second timestamp log according to the state bit value, the physical timestamp, and the logical timestamp.

[0078] In the embodiments of the present disclosure, the fusion timestamp in the second timestamp log can be set to 64 bits, and the fusion timestamp can include 2-bit state bits, 46-bit physical timestamps, and 16-bit logical timestamps.

[0079] Specifically, when determining the second timestamp, the state bit value can be determined first. Considering that there is a non-independent write transaction in the second transaction, the non-independent write transaction needs to rely on other write transactions associated therewith, such as a child transaction and a prepare transaction, when determining whether the non-independent write transaction has been committed. Here, the child transaction is part of a complete transaction, and the visibility of the child transaction depends on the parent transaction. In addition, the prepare transaction can be executed on multiple databases at the same time, and only when all the prepare transactions are executed, the transaction can be finally committed, thereby ensuring consistency. Therefore, the visibility of the prepare transaction depends on other prepare transactions associated therewith.

[0080] Based on this, the state bits for indicating the transaction type of the second transaction can be set in the fusion timestamp, and the state bit value indicates whether the second transaction is a non-independent write transaction. As known from the above, the state bits can include the highest bit and the second highest bit. Here, when the value of the highest bit is 1, it can represent that the second transaction is a child transaction, and when the value of the highest bit is 0, it can represent that the second transaction is a normal transaction. In addition, when the value of the second highest bit is 1, it can represent that the second transaction is a prepare transaction, and when the value of the second highest bit is 0, it can represent that the second transaction is a normal transaction.

[0081] Next, a real-time machine time can be obtained, and a physical timestamp can be determined based on the real-time machine time. Specifically, the real-time machine time can be accurate to the millisecond level. After the physical timestamp is determined, the logical timestamp corresponding to the second transaction can be determined.

[0082] Specifically, considering that the concurrency of transactions in the database is high, multiple write transactions can be raised in the same millisecond. Therefore, the order of occurrence of the second transaction can be marked by a logical timestamp. Here, write transactions raised in the same millisecond as the second transaction can be obtained, that is, write transactions with the same physical timestamp as the second transaction.

[0083] Then, the second transaction queue in the current millisecond can be determined, and the logical timestamp of the second transaction can be determined based on the logical timestamps of the write transactions occurring between the current second transaction in the second transaction queue. Specifically, the logical timestamp of the second transaction can be obtained by adding one to the logical timestamp of an adjacent write transaction before the second transaction.

[0084] It should be understood that when determining the first timestamp log of the first transaction, the read timestamp in the first timestamp log can be set as 64 bits, and the fusion timestamp can be set as 64 bits. Specifically, the fusion timestamp can include 2-bit state bits, 46-bit physical timestamps, and 16-bit logical timestamps. Here, the value of the state bit can be set as a null value.

[0085] When determining the read timestamp, the physical timestamp can be determined first. The manner of determining the physical timestamp is described above in determining the physical timestamp in the fusion timestamp, which will not be described here. Then, the logical timestamp in the read timestamp can be determined. Specifically, the corresponding second transaction queue can be found based on the machine time corresponding to the physical timestamp, and the largest logical timestamp in the second transaction queue can be determined. The logical timestamp of the read timestamp can be obtained by adding one to the value of the logical timestamp.

[0086] In the embodiments of the present disclosure, the first timestamp log can be generated in real time for the first transaction, and the second timestamp log can be generated in real time for the second transaction. Here, the first timestamp log and the second timestamp log can store multiple transaction information through one log data, which reduces the data maintenance cost of the database.

[0087] In an optional implementation, the step S105 of determining the visibility state of the second transaction relative to the first transaction based on the comparison result of the first timestamp log and the second timestamp log specifically includes the following process:

[0088] S11: reading the second timestamp value of the second timestamp log, and determining the processing state of the second transaction based on the second timestamp value.

[0089] S12: in a case where the processing state is a target state, determining a first timestamp value of the first timestamp log, and determining that the second transaction is visible with respect to the first transaction in a case where the first timestamp value is greater than the second timestamp value, wherein the target state is used to indicate that the second transaction has been committed.

[0090] S13: in a case where the processing state is a non-target state, determining that the second transaction is not visible with respect to the first transaction, wherein the target state is used to indicate that the second transaction has not been committed.

[0091] In the embodiment of the present disclosure, firstly, a fusion timestamp in the second timestamp log can be acquired, and a value of the fusion timestamp is read to obtain a second timestamp value, and the processing state of the second transaction is determined based on the second timestamp value.

[0092] Here, the processing state can include a target state and a non-target state, the target state being a committed state, and the non-target state being a non-committed state. The manner of determining the processing state based on the second timestamp value is described as follows, which is not expanded here.

[0093] It should be understood that in a case where the processing state of the second transaction is a non-target state, it indicates that the data processing operation of the second transaction is not completed, at this time, the second transaction should be in a state of being not visible to the first transaction.

[0094] In a case where the processing state of the second transaction is a target state, it indicates that the second transaction has been completed, i.e., has been committed. When setting the visibility judgment standard, it can be set that a transaction with a larger timestamp value is visible to a transaction with a smaller timestamp value. Based on this, the second timestamp value of the fusion timestamp in the second timestamp log corresponding to the second transaction can be determined, and the first timestamp value of the read timestamp in the first timestamp log corresponding to the first transaction can be determined.

[0095] Then, the first timestamp value and the second timestamp value can be compared. If the first timestamp value is greater than the second timestamp value, it indicates that the second transaction has been committed before the first transaction is established, at this time, the second transaction is visible to the first transaction, and vice versa.

[0096] In the embodiment of the present disclosure, since the first timestamp log and the second timestamp log can both store multiple transaction information through one log data, the visibility of the second transaction with respect to the first transaction can be determined based on the comparison result of the first timestamp log and the second timestamp log, so as to ensure the accuracy of the judgment of the visibility while improving the accuracy of the determined visibility.

[0097] In an optional implementation, as Figure 3As shown in the above step S105, the step further includes the following process:

[0098] S21: determining a preset timestamp value.

[0099] S22: determining that the processing state is a non-target state in a case where the second timestamp value of the second timestamp log hits the preset timestamp value.

[0100] S23: determining that the processing state is a target state in a case where the second timestamp value of the second timestamp log does not hit the preset timestamp value.

[0101] In the embodiments of the present disclosure, during the process of committing the write transaction, the processing state of the write transaction can be monitored, and the fusion timestamp of the write transaction is assigned based on the processing state. Specifically, considering that the transaction can include multiple stages during the committing process, therefore, the corresponding preset timestamp value can be set for each stage, and the specific way of determining the preset timestamp value is as follows, which is not expanded here. It should be understood that after the write transaction is committed, the fusion timestamp of the write transaction is no longer assigned, so as to determine the completion time of the write transaction based on the fusion timestamp of the write transaction.

[0102] Based on this, it can be determined whether the second timestamp value of the fusion timestamp in the second timestamp log hits the preset timestamp value. If it hits, it means that the second transaction has not been committed and is in a non-target state, otherwise, it means that the second transaction has been committed and is in a target state.

[0103] In the embodiments of the present disclosure, the target state and the non-target state of the second transaction can be distinguished by assigning the fusion timestamp of the second transaction in an uncommitted state, so as to facilitate the judgment of the visibility of the second transaction relative to the first transaction.

[0104] In an optional implementation, the non-target state includes an initialization state, an abort state, and a committing state, and the step S21 of determining the preset timestamp value specifically includes the following process:

[0105] (1) setting a corresponding state value for each non-target state, and determining a preset radix;

[0106] (2) converting the state value into a corresponding timestamp based on the preset radix to obtain a preset timestamp.

[0107] In the embodiments of the present disclosure, the non-target state of the second transaction can include an initialization state, an abort state, and a commit-in state. Here, the initialization state can be used to indicate that the second transaction is in a running state, the abort state can be used to indicate that the second transaction has been aborted, and the commit-in state is used to indicate that the second transaction is in the process of committing, but has not completed committing.

[0108] In order to enable the second timestamp log of the second transaction to contain the state information of the second transaction, a corresponding state value can be set for each non-target state, so as to facilitate the determination of the specific processing state of the second transaction based on the second timestamp log.

[0109] After determining that each non-target state sets a corresponding state value, a preset radix can be determined. Specifically, the preset radix can match the fusion timestamp described above. For example, when the fusion timestamp is 64 bits, the preset radix can be hexadecimal. Then, based on the preset radix, each state value can be converted into a corresponding timestamp to obtain a preset timestamp.

[0110] For example, the value of the preset timestamp corresponding to the initialization state can be a first value, which is equal to 0x0 (hexadecimal, value 0), the value of the preset timestamp corresponding to the abort state can be a second value, which is equal to 0x1 (hexadecimal, value 1), and the value of the preset timestamp corresponding to the commit-in state can be a third value, which is equal to 0x2 (hexadecimal, value 2).

[0111] In the embodiments of the present disclosure, considering that a transaction can include multiple stages in the process of committing, a corresponding preset timestamp value can be set for each stage to assign a fusion timestamp of the second task in the process of committing based on the preset timestamp value, thereby facilitating reading the processing state of the second task based on the fusion timestamp.

[0112] In an optional implementation, the above Figure 1 The corresponding embodiments also include the following processes:

[0113] (1) After determining the second timestamp log of the second transaction, the transaction type of the second transaction is determined based on the second timestamp log.

[0114] (2) In the case where the transaction type is a distributed transaction, the associated transaction of the second transaction is determined, and the third timestamp log of the associated transaction is determined.

[0115] (3) Based on the comparison result of the second timestamp log and the third timestamp log with the first timestamp log, the visible state of the second transaction relative to the first transaction is determined.

[0116] (4) in the case of the transaction type being a sub-transaction, determining a parent transaction of the second transaction, and determining a fourth timestamp log of the parent transaction;

[0117] (5) determining a visible state of the second transaction relative to the first transaction based on a comparison result of the fourth timestamp log and the first timestamp log.

[0118] In the embodiments of the present disclosure, firstly, a fusion timestamp in a second timestamp log of a second transaction can be acquired, and the fusion timestamp is parsed based on a state bit to determine a transaction type of the second transaction, wherein the transaction type can include a normal transaction and a special transaction, and the special transaction can include the above-mentioned sub-transaction and prepare transaction, specifically, the prepare transaction is the above-mentioned distributed transaction.

[0119] As can be seen from the above, the state bit of the fusion timestamp includes the highest bit and the next highest bit, firstly, the highest bit value in the fusion timestamp can be parsed to determine whether the second task is a sub-task. Specifically, if the highest bit value is 1, the second task is a sub-task, and if the highest bit value is 0, the second task is a normal task.

[0120] After it is determined that the second task is a sub-task, the parent task corresponding to the second task can be found, and the second timestamp log of the parent task is acquired to compare the fourth timestamp log with the first timestamp log, and the visible state of the parent transaction relative to the first transaction is determined based on the comparison result, and the visible state of the second transaction is determined based on the visible state of the parent transaction.

[0121] Specifically, the way of comparing the fourth timestamp log with the first timestamp log can refer to the way of comparing the second timestamp log with the first timestamp log as described in the above-mentioned step S105, which will not be described here. It should be understood that when it is determined that the parent transaction is visible relative to the first transaction, it can be considered that the second transaction is visible relative to the first transaction, and vice versa.

[0122] Next, the next highest bit value in the fusion timestamp can also be parsed to determine whether the second task is a distributed task. Specifically, if the next highest bit value is 1, the second task is a distributed task, and if the next highest bit value is 0, the distributed task is a normal task.

[0123] After determining that the second task is a subtask, all associated transactions associated with the second task can be searched, and third timestamp logs of the associated transactions can be determined. Then, among all third timestamp logs, a third timestamp log with the largest read timestamp value can be determined, and the third timestamp log can be compared with the first timestamp log based on the comparison result to determine the visibility of the second transaction relative to the first transaction. Specifically, if the read timestamp value of the third timestamp log is less than the fusion timestamp value of the first timestamp log, it indicates that the second transaction is visible relative to the first transaction, otherwise, it is not visible. Specifically, the way of comparing the third timestamp log with the first timestamp log can refer to the way of comparing the second timestamp log with the first timestamp log as described in the above step S105, which will not be described here.

[0124] In the embodiments of the present disclosure, considering that a write transaction can be divided into a normal transaction and a special transaction, and the way of judging the visibility of the special transaction is different from that of the normal transaction, therefore, in the present disclosure, the transaction type of the second transaction can be determined based on the second timestamp log of the second transaction, so that different ways of judging the visibility are used based on different transaction types, thereby improving the accuracy of the determined visibility state of the second transaction.

[0125] In an optional implementation, the step S103 further includes the following process:

[0126] S31: After restarting the database, the processing state of the second transaction is determined again.

[0127] S32: In a case where it is determined based on the processing state that the second transaction has been committed, a target commit timestamp preset is obtained, and the second timestamp log is determined according to the target commit timestamp.

[0128] S33: In a case where it is determined based on the processing state that the second transaction has not been committed, a preset timestamp value is determined, and the second timestamp log is determined according to the preset commit timestamp.

[0129] In the embodiments of the present disclosure, considering that the transaction state log is generally used to record the transaction state in the current database, therefore, the transaction state log can be converted to obtain a timestamp log. Taking the second transaction as an example, the transaction state log of the second transaction can be converted to obtain the corresponding second timestamp log.

[0130] In specific implementation, as known from the above, the processing state of the second transaction can include an initialization state, an abort state, a commit state and a committed state. Before log format conversion, the database process can be stopped first, and a configuration item can be modified to perform log format conversion operation based on the configuration item.

[0131] After the configuration item is modified, the database can be restarted through a restart instruction, and then the processing state of the second transaction after the restart can be re-determined based on the processing state of the second transaction before the database process is stopped. Specifically, the processing state of the second transaction in the initialization state and the abort state can be re-determined as the abort state, i.e., the uncommitted state, and the processing state of the second transaction in the commit state and the committed state can be re-determined as the committed state.

[0132] Next, the fusion timestamp of the second transaction can be determined based on the re-determined processing state, and the corresponding second timestamp log can be determined based on the fusion timestamp. Specifically, when the processing state of the second transaction is the uncommitted state, a preset timestamp value corresponding to the processing state of the second transaction can be determined. The specific way of determining the preset timestamp value corresponding to the processing state is as described above, and will not be described here.

[0133] In addition, when the processing state of the second transaction is the committed state, in order to ensure that the read timestamp corresponding to the read transaction generated next is greater than the fusion timestamp of the second transaction, so as to ensure that the second transaction is visible to the read transaction, the minimum value of the commit time corresponding to the fusion timestamp can be determined in advance, and the target commit timestamp can be determined based on the minimum value, so as to determine the second timestamp log according to the target commit timestamp.

[0134] In the embodiments of the present disclosure, considering that the transaction state log is generally recorded in the current database through the transaction state log, the transaction state log can be converted in the present disclosure to obtain the timestamp log, thereby improving the application scope of the present disclosure.

[0135] In an optional implementation, the above Figure 1 The corresponding embodiments also include the following processes:

[0136] After receiving the log format conversion instruction, the processing state of the first transaction is determined based on the first timestamp log, and the transaction state log of the first transaction is generated based on the processing state;

[0137] At the same time, the processing state of the second transaction is determined based on the second timestamp log, and the transaction state log of the second transaction is generated based on the processing state.

[0138] In order to improve the state conversion scheme between the transaction state log and the timestamp log, the present disclosure provides a way of converting the timestamp log into the transaction state log in the embodiments of the present disclosure. Here, the corresponding transaction state log can be determined for the first transaction and the second transaction respectively.

[0139] Specifically, for the first transaction, the processing state and the establishment time of the first transaction can be determined based on the first timestamp log, and the transaction state log of the first transaction can be determined according to the processing state and the establishment time. Similarly, for the second transaction, the processing state and the submission time of the second transaction can be determined based on the second timestamp log, and the transaction state log of the first transaction can be determined according to the processing state and the submission time.

[0140] To sum up, in the embodiments of the present disclosure, first, the first transaction in the database can be acquired, and the first timestamp log corresponding to the first transaction is determined, wherein the first transaction is used to indicate a read operation on data in the database. Then, the second timestamp log of the second transaction is determined, wherein the second transaction is used to indicate a data processing operation on data in the database. Next, the first timestamp log and the second timestamp log are compared to obtain a comparison result, and the visible state of the second transaction relative to the first transaction is determined based on the comparison result, so that the visibility between transactions can be determined based on the timestamp log. The data amount of the timestamp log is much smaller than that of the active transaction list, thereby reducing the maintenance cost and improving the database performance.

[0141] Those skilled in the art can understand that in the above method of the specific implementation, the writing order of each step does not mean a strict execution order and does not constitute any limitation on the implementation process. The specific execution order of each step should be determined by its function and possible internal logic.

[0142] Based on the same inventive concept, the embodiments of the present disclosure also provide a database data state determination method. Since the principle of solving problems in the embodiments of the present disclosure is similar to the above-mentioned database data state determination method, the implementation of the device can be referred to the implementation of the method, and the repeated parts will not be described here.

[0143] Referring to Figure 4 Fig. 1 shows a schematic diagram of a database data state determination device provided by the embodiments of the present disclosure. The device comprises an acquisition unit 41, a first determination unit 42, and a second determination unit 43.

[0144] The acquisition unit 41 is configured to acquire a first transaction in a database and determine a first timestamp log corresponding to the first transaction, wherein the first transaction is used to indicate a read operation on data in the database.

[0145] The first determination unit 42 is configured to determine a second timestamp log of a second transaction, wherein the second transaction is used to indicate a data processing operation on data in the database.

[0146] The second determining unit 43 is configured to determine, based on a comparison result of the first timestamp log and the second timestamp log, a visible state of the second transaction relative to the first transaction.

[0147] In the embodiments of the present disclosure, first, a first transaction in a database can be acquired and a first timestamp log corresponding to the first transaction is determined, where the first transaction is used to indicate a read operation on data in the database. Then, a second timestamp log of a second transaction is determined, where the second transaction is used to indicate a data processing operation on data in the database. Next, the first timestamp log and the second timestamp log are compared to obtain a comparison result, and the visible state of the second transaction relative to the first transaction is determined based on the comparison result, so that the visibility between transactions can be determined based on the timestamp log, the data amount of the timestamp log is much smaller than that of the active transaction list, the maintenance cost is reduced, and the database performance is improved.

[0148] In a possible implementation, the second determining unit 43 is further configured to:

[0149] read a second timestamp value of the second timestamp log, and determine a processing state of the second transaction based on the second timestamp value;

[0150] in a case where the processing state is a target state, determine a first timestamp value of the first timestamp log, and determine that the second transaction is visible relative to the first transaction when the first timestamp value is greater than the second timestamp value, where the target state is used to indicate that the second transaction is committed;

[0151] in a case where the processing state is a non-target state, determine that the second transaction is invisible relative to the first transaction, where the target state is used to indicate that the second transaction is uncommitted.

[0152] In a possible implementation, the second determining unit 43 is further configured to:

[0153] determine a preset timestamp value;

[0154] in a case where the second timestamp value of the second timestamp log hits the preset timestamp value, determine that the processing state is a non-target state;

[0155] in a case where the second timestamp value of the second timestamp log does not hit the preset timestamp value, determine that the processing state is a target state.

[0156] In a possible implementation, the non-target state includes an initialization state, an abort state, and a commit-in-progress state, and the second determining unit 43 is further configured to:

[0157] set a corresponding state value for each non-target state respectively, and determine a preset radix;

[0158] convert the state value into a corresponding timestamp based on the preset radix, to obtain a preset timestamp.

[0159] In a possible implementation, the second timestamp log includes a state bit, a physical timestamp, and a logical timestamp. The first determining unit 42 is further configured to:

[0160] The second timestamp log of the second transaction includes:

[0161] Determine a transaction type of the second transaction, and determine the state bit value based on the transaction type;

[0162] Obtain a real-time machine time, and determine the physical timestamp based on the machine time;

[0163] In the case where the physical timestamp is the same, determine the logical timestamp based on a time sequence of the second transaction in a second transaction queue;

[0164] Determine the second timestamp log according to the state bit value, the physical timestamp, and the logical timestamp.

[0165] In a possible implementation, the apparatus is further configured to:

[0166] After determining the second timestamp log of the second transaction, determine a transaction type of the second transaction based on the second timestamp log;

[0167] In the case where the transaction type is a distributed transaction, determine an associated transaction of the second transaction, and determine a third timestamp log of the associated transaction;

[0168] Based on a comparison result of the second timestamp log and the third timestamp log with the first timestamp log, determine a visible state of the second transaction relative to the first transaction;

[0169] In the case where the transaction type is a sub-transaction, determine a parent transaction of the second transaction, and determine a fourth timestamp log of the parent transaction;

[0170] Based on a comparison result of the fourth timestamp log and the first timestamp log, determine a visible state of the second transaction relative to the first transaction.

[0171] In a possible implementation, the first determining unit 42 is further configured to:

[0172] After restarting the database, redetermine the processing state of the second transaction;

[0173] In a case where it is determined based on the processing state that the second transaction is committed, a preset target commit timestamp is obtained, and a second timestamp log is determined according to the target commit timestamp;

[0174] In a case where it is determined based on the processing state that the second transaction is not committed, a preset timestamp value is determined, and a second timestamp log is determined according to the preset commit timestamp.

[0175] In a possible implementation, the apparatus is further configured to:

[0176] After receiving the log format conversion instruction, determine the processing state of the first transaction based on the first timestamp log, and generate a transaction state log of the first transaction based on the processing state; and

[0177] Determine the processing state of the second transaction based on the second timestamp log, and generate a transaction state log of the second transaction based on the processing state.

[0178] The description of the processing procedure of each unit in the apparatus and the interaction procedure between the units can refer to the related description in the method embodiments, and will not be described in detail here.

[0179] Corresponding to the data state determination method of the database in Figure 1 The embodiments of the present disclosure also provide a computer device 500, as shown in Figure 5 The computer device 500 provided by the embodiments of the present disclosure is a structure schematic diagram, which comprises:

[0180] a processor 51, a memory 52, and a bus 53; the memory 52 is used for storing execution instructions, including an internal memory 521 and an external memory 522; the internal memory 521 is also called an internal storage, which is used for temporarily storing operation data in the processor 51 and data exchanged with the external memory 522 such as a hard disk, the processor 51 exchanges data with the external memory 522 through the internal memory 521, and when the computer device 500 is running, the processor 51 and the memory 52 communicate through the bus 53, so that the processor 51 executes the following instructions:

[0181] obtain a first transaction in the database, and determine a first timestamp log corresponding to the first transaction, wherein the first transaction is used to indicate a read operation on data in the database;

[0182] determine a second timestamp log of a second transaction, wherein the second transaction is used to indicate a data processing operation on data in the database;

[0183] Based on a comparison result of the first timestamp log and the second timestamp log, a visible state of the second transaction relative to the first transaction is determined.

[0184] The embodiment of the present disclosure further provides a computer readable storage medium, and the computer readable storage medium stores a computer program. When the computer program is run by a processor, steps of the data state determination method of the database described in the above method embodiment are executed. The storage medium can be a volatile or non-volatile computer readable storage medium.

[0185] The embodiment of the present disclosure further provides a computer program product, and the computer program product carries a program code. The program code includes instructions that can be used to execute steps of the data state determination method of the database described in the above method embodiment. For details, refer to the above method embodiment, which will not be described here.

[0186] The computer program product can be specifically implemented by means of hardware, software or a combination thereof. In an optional embodiment, the computer program product is specifically embodied as a computer storage medium. In another optional embodiment, the computer program product is specifically embodied as a software product, such as a software development kit (SDK) and the like.

[0187] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working process of the above-described system and device can refer to the corresponding process in the foregoing method embodiment, which will not be described here. In several embodiments provided by the present disclosure, it should be understood that the disclosed system, device and method can be implemented by other means. The device embodiments described above are only schematic. For example, the division of the units is only a logical function division, and actual implementation can have another division manner. For example, a plurality of units or components can be combined or integrated into another system, or some features can be omitted or not executed. In addition, the coupling or direct coupling or communication connection between the units or components shown or discussed can be indirect coupling or communication connection through some communication interface, device or unit, which can be electrical, mechanical or other forms.

[0188] The units described as separate components can or can not be physically separate, and the components shown as units can or can not be physical units, that is, they can be located in one place or distributed on a plurality of network units. According to actual needs, some or all of the units can be selected to achieve the purpose of the embodiment.

[0189] In addition, each function unit in various embodiments of the present disclosure can be integrated in one processing unit, or each unit can be physically present separately, or two or more units can be integrated in one unit.

[0190] If the functions are implemented in the form of software function units and sold or used as independent products, they can be stored in a nonvolatile computer readable storage medium executable by a processor. Based on this understanding, the technical solutions of the present disclosure essentially or the part that contributes to the prior art or part of the technical solutions can be embodied in the form of a software product. The computer software product is stored in a storage medium, and includes several instructions to make a computer device (which can be a personal computer, a server, or a network device, etc.) execute all or part of the steps of the methods described in various embodiments of the present disclosure. The aforementioned storage medium includes: a U disk, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk, and various media that can store program codes.

[0191] Finally, it should be noted that: the above-described embodiments are merely specific embodiments of the present disclosure, used to illustrate the technical solutions of the present disclosure, rather than limit them. The protection scope of the present disclosure is not limited thereto, although the present disclosure has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand: any person skilled in the art within the technical range disclosed by the present disclosure, can still modify or easily think of changes to the technical solutions recorded in the foregoing embodiments, or make equivalent replacements to part of the technical features; and these modifications, changes or replacements do not make the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the present disclosure, and should be covered within the protection scope of the present disclosure. Therefore, the protection scope of the present disclosure should be subject to the protection scope of the claims.

Claims

1. A method for determining the data status of a database, characterized in that, include: Obtain the first transaction in the database and determine the first timestamp log corresponding to the first transaction, wherein the first transaction is used to indicate a read operation on the data in the database; Determine the second timestamp log of the second transaction, wherein the second transaction is used to indicate data processing operations on data in the database; Based on the comparison results between the first timestamp log and the second timestamp log, the visibility status of the second transaction relative to the first transaction is determined; The second timestamp log for determining the second transaction includes: The transaction type of the second transaction is determined, and the status bit value is determined based on the transaction type; wherein the status bit value is used to indicate whether the second transaction is a non-independent write transaction; Obtain the real-time machine time and determine the physical timestamp based on the machine time; If the physical timestamps are the same, the logical timestamp is determined based on the timing of the second transaction in the second transaction queue; The second timestamp log is determined based on the status bit value, physical timestamp, and logical timestamp.

2. The method according to claim 1, characterized in that, Determining the visibility status of the second transaction relative to the first transaction based on the comparison result between the first timestamp log and the second timestamp log includes: Read the second timestamp value from the second timestamp log and determine the processing status of the second transaction based on the second timestamp value; When the processing status is the target status, the first timestamp value of the first timestamp log is determined, and when the first timestamp value is greater than the second timestamp value, the second transaction is determined to be visible relative to the first transaction, wherein the target status is used to indicate that the second transaction has been committed; If the processing state is a non-target state, it is determined that the second transaction is not visible relative to the first transaction, wherein the target state is used to indicate that the second transaction has not been committed.

3. The method according to claim 2, characterized in that, The method further includes: Determine the preset timestamp value; If the second timestamp value of the second timestamp log matches the preset timestamp value, the processing state is determined to be a non-target state. If the second timestamp value of the second timestamp log does not match the preset timestamp value, the processing state is determined to be the target state.

4. The method according to claim 3, characterized in that, The non-target states include: initialization state, abort state, and submission state; The determination of the preset timestamp value includes: Set corresponding state values ​​for each non-target state and determine the preset number system; Based on the preset base, the state value is converted into a corresponding timestamp to obtain the preset timestamp.

5. The method according to claim 1, characterized in that, The second timestamp log includes: status bits, physical timestamp, and logical timestamp.

6. The method according to claim 1, characterized in that, The method further includes: After determining the second timestamp log of the second transaction, the transaction type of the second transaction is determined based on the second timestamp log; In the case that the transaction type is a distributed transaction, determine the associated transaction of the second transaction, and determine the third timestamp log of the associated transaction; Based on the comparison results between the second timestamp log and the third timestamp log and the first timestamp log, the visibility status of the second transaction relative to the first transaction is determined. In the case that the transaction type is a sub-transaction, determine the parent transaction of the second transaction and determine the fourth timestamp log of the parent transaction; Based on the comparison between the fourth timestamp log and the first timestamp log, the visibility status of the second transaction relative to the first transaction is determined.

7. The method according to claim 1, characterized in that, The second timestamp log for determining the second transaction also includes: After restarting the database, the processing status of the second transaction is redefined; If it is determined that the second transaction has been committed based on the processing status, a pre-set target commit timestamp is obtained, and a second timestamp log is determined based on the target commit timestamp. If it is determined that the second transaction has not been committed based on the processing status, a preset timestamp value is determined, and a second timestamp log is determined based on the preset timestamp value.

8. The method according to claim 1, characterized in that, The method further includes: Upon receiving the log format conversion instruction, based on the first timestamp log, the processing status of the first transaction is determined, and a transaction status log for the first transaction is generated based on this processing status; and Based on the second timestamp log, the processing status of the second transaction is determined, and a transaction status log of the second transaction is generated based on the processing status.

9. A data status determination device for a database, characterized in that, include: The acquisition unit is used to acquire the first transaction in the database and determine the first timestamp log corresponding to the first transaction, wherein the first transaction is used to indicate a read operation on the data in the database; The first determining unit is used to determine the second timestamp log of the second transaction, wherein the second transaction is used to indicate data processing operations on data in the database; The second determining unit is configured to determine the visibility status of the second transaction relative to the first transaction based on the comparison result between the first timestamp log and the second timestamp log; the second timestamp log for determining the second transaction includes: The transaction type of the second transaction is determined, and the status bit value is determined based on the transaction type; wherein the status bit value is used to indicate whether the second transaction is a non-independent write transaction; Obtain the real-time machine time and determine the physical timestamp based on the machine time; If the physical timestamps are the same, the logical timestamp is determined based on the timing of the second transaction in the second transaction queue; The second timestamp log is determined based on the status bit value, physical timestamp, and logical timestamp.

10. A computer device, characterized in that, include: The computer device includes a processor, a memory, and a bus. The memory stores machine-readable instructions executable by the processor. When the computer device is running, the processor communicates with the memory via the bus. When the machine-readable instructions are executed by the processor, they perform the steps of the database data state determination method as described in any one of claims 1 to 8.

11. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, performs the steps of the database data state determination method as described in any one of claims 1 to 8.

Images