Transaction log query processing method and storage node

Abstract

A transaction log query processing method and a storage node, the storage node storing a plurality of transaction logs through a plurality of log blocks, the method comprising: receiving a data query request indicating a first field and a corresponding first field value, the first field being a discrete field; querying a bitmap index corresponding to the first field to obtain an existence bitmap corresponding to the first field value; determining a target log block from the plurality of log blocks according to the existence bitmap; querying a reverse index corresponding to the first field in the target log block, and determining a target transaction number corresponding to a target transaction log involving the first field and the first field value in the target log block; and according to the target transaction number, reading the target transaction information from the target transaction log.

Description

Technical Field

[0001] One or more embodiments of this specification relate to the field of computers, and more particularly, to a transaction log query processing method and storage node. Background Art

[0002] In some technical scenarios, log blocks may be used to store transaction logs generated by software systems when executing specific transactions. Transaction logs can be used to update or restore specific business data. However, querying the transaction logs of storage nodes to obtain the desired transaction information typically requires traversing the entire transaction log, which is relatively inefficient. Summary of the Invention

[0003] One or more embodiments of this specification provide a transaction log query processing method and apparatus, which facilitates storage nodes to more efficiently query desired transaction information from a large number of transaction logs.

[0004] In a first aspect, a transaction log query processing method is provided, the method being executed by a storage node, the storage node storing multiple transaction logs via multiple log blocks, the method comprising: receiving a data query request, wherein a first field and a corresponding first field value are indicated, the first field being a discrete field; querying a bitmap index corresponding to the first field to obtain an existence bitmap corresponding to the first field value, and determining a target log block from the multiple log blocks based on the existence bitmap; querying an inverted index corresponding to the first field in the target log block to determine a target transaction number corresponding to a target transaction log involving the first field and the first field value in the target log block; and reading target transaction information from the target transaction log based on the target transaction number.

[0005] In a second aspect, a storage node is provided for storing multiple transaction logs through multiple log blocks, the storage node comprising: a request receiving unit, configured to receive a data query request, indicating a first field and a corresponding first field value, wherein the first field is a discrete field; a bitmap query unit, configured to query a bitmap index corresponding to the first field, obtain an existence bitmap corresponding to the first field value, and determine a target log block from the multiple log blocks according to the existence bitmap; a number query unit, configured to query an inverted index corresponding to the first field in the target log block, and determine a target transaction number corresponding to a target transaction log involving the first field and the first field value in the target log block; and a log query unit, configured to read target transaction information from the target transaction log according to the target transaction number.

[0006] In a third aspect, a computer-readable storage medium is provided, on which a computer program / instruction is stored. When the computer program / instruction is executed in a computing device, the computing device executes the method as described in the first aspect.

[0007] In a fourth aspect, a computing device is provided, comprising a memory and a processor, wherein the memory stores a computer program / instruction, and the processor executes the computer program / instruction to implement the method as described in the first aspect.

[0008] Through the method and storage node provided in one or more embodiments of the present specification, a two-layer index structure is set in the storage node for the transaction log stored in the log block. When the storage node needs to query for target transaction information that meets the expectations from multiple transaction logs stored by the storage node in multiple log blocks based on a discrete field, the storage node can quickly locate the target log block to which the target transaction log containing the target transaction information belongs through the bitmap index corresponding to the discrete field; then, through the inverted index corresponding to the discrete field in the target log, the target transaction number corresponding to the target transaction log is quickly determined; and then, based on the target transaction number, the target transaction log is quickly located in the target log block and the target transaction information is read from the target transaction log, without spending too much time traversing all the transaction logs in multiple log blocks, which is conducive to improving query efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] In order to more clearly illustrate the technical solutions of the embodiments of this specification, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0010] Figure 1 A schematic diagram of an application scenario of the technical solution provided in the embodiments of this specification; Figure 2 A schematic diagram of the data structure of a log block exemplarily provided in an embodiment of this specification; Figure 3 A schematic diagram of a bitmap index exemplarily provided in the embodiments of this specification; Figure 4 A flowchart of a transaction log query processing method provided in an embodiment of this specification; Figure 5 A schematic diagram of the structure of a storage node provided in an embodiment of this specification. DETAILED DESCRIPTION

[0011] The following describes in detail various non-limiting embodiments provided in this specification in conjunction with the accompanying drawings.

[0012] In some technical scenarios, storage nodes may use log blocks to store transaction logs generated by the software system when executing certain specific transactions. Transaction logs can be used to update / restore business data. For example, for some distributed data storage systems, multiple storage nodes may be used to store multiple data copies of target business data. Data copies can generally be divided into multiple types, such as log-type copies, encrypted voting-type copies, universal copies, and read-only copies. Log-type copies include the plaintext of the transaction log, encrypted voting-type copies include the ciphertext of the transaction log, universal copies include the plaintext of the transaction log and its corresponding target business data, and read-only copies include the target business data. Storage nodes used to store log-type copies or universal copies generally use multiple log blocks to store the plaintext of multiple transaction logs.

[0013] Transaction logs typically include information such as log number, transaction content, and timestamp. In addition, they may also include the update type of related business data (such as addition, modification, deletion, etc.). The transaction content may include several fields and the field values corresponding to each of the several fields. There may be one or more discrete fields in the several fields. For example, for a transaction log generated by a merchant executing a bill issuance transaction on a commodity trading platform, the transaction content may be a specific bill, such as the merchant (issuer), user (recipient), product name, quantity, unit price, amount, tax rate, tax amount and other fields and their corresponding field values. The field value of the field "merchant" usually belongs to a certain data set with a limited number of elements, and the field "merchant" can be a discrete field. Similarly, the field value of the field "user" usually belongs to a certain data set with a limited number of elements, and the field "user" can be a discrete field.

[0014] Discrete fields in a transaction log can support query requesters in querying the transaction log, obtaining desired transaction information from the transaction log, and performing statistical analysis on the relevant transaction information or achieving other purposes. Continuing with the previous example, a data query request Q1 may include the field "Merchant" and its corresponding field value "A1." When a storage node processes this data query request Q1, it can retrieve all invoices with a field value of "A1" for the "Merchant" field from the multiple log blocks it maintains, and return all of these invoices to the corresponding query requester. Continuing with the previous example, a data query request Q2 may include the field "Merchant" and its corresponding field value "A1," as well as the field "User" corresponding to the desired transaction data. When a storage node processes this data query request Q2, it can retrieve all invoices with a field value of "A1" for the "Merchant" field from the multiple data blocks it maintains, and return all of the field values under the "User" field in these invoices to the corresponding query requester.

[0015] The preceding description of transaction logs is merely illustrative. For example, transaction logs may be generated by a payment platform when executing payment transactions. The transaction content in the transaction logs may include fields such as the paying account, receiving account, and payment amount, along with their corresponding field values. The paying account and receiving account can be treated as discrete fields, and we will not enumerate them here.

[0016] When a storage node processes a query request and needs to query its own stored transaction log based on discrete fields to obtain and return the expected transaction information, it usually needs to traverse all transaction logs in all log blocks.

[0017] A transaction log query processing method and storage node are provided in an embodiment of the present specification. A storage node stores multiple transaction logs through multiple log blocks. The storage node can receive a data query request, which indicates a first field and a corresponding first field value, where the first field is a discrete field; then query the bitmap index corresponding to the first field to obtain an existence bitmap corresponding to the first field value, and determine a target log block from multiple log blocks stored in the storage node based on the existence bitmap; then query the inverted index corresponding to the first field in the target log block to determine a target transaction number corresponding to the target transaction log involving the first field and the first field value in the target log block; and then read the target transaction information from the target transaction log based on the target transaction number.

[0018] In this way, a two-layer index structure is set in the storage node for the transaction log stored in the log block. When the storage node searches for target transaction information that meets the expectations from multiple transaction logs stored in the storage node through multiple log blocks based on a discrete field, the storage node can quickly locate the target log block to which the target transaction log containing the target transaction information belongs through the bitmap index corresponding to the discrete field; quickly determine the target transaction number corresponding to the target transaction log through the inverted index corresponding to the discrete field in the target log; and then quickly locate the target transaction log in the target log block based on the target transaction number and read the target transaction information from the target transaction log, without spending too much time to query all the transaction logs in the multiple log blocks, which is conducive to improving query efficiency.

[0019] The storage node may be a storage node in a computer system dedicated to storing all transaction logs generated by the computer system; or may be a storage node in a distributed storage system used to store log-type copies of relevant target business data.

[0020] The following exemplifies a technical scenario in which the technical solutions in the embodiments of this specification are applied to a distributed storage system.

[0021] For example, refer to Figure 1 As shown, a distributed storage system may store multiple data copies of target business data through multiple storage nodes, such as storing a universal copy of the target business data through storage node Node A, storing a log copy of the target business data through storage node Node B, and storing a log copy of the target business data through storage node Node C. A load balancer connected to Node A, Node B, and Node C may receive a data query request initiated by a query requester for the target business data; based on the corresponding load balancing strategy, the load balancer can send the data query request to storage node Node B or storage node Node C for processing when the data query request is an analytical processing (AP) request, and send the data query request to storage node Node A for processing when the data query request is a transactional processing (TP) request. Storage node Node B and / or Node C can apply the solution provided in the embodiments of this specification.

[0022] In the distributed storage system of the aforementioned example, any storage node, when processing a data query request related to the target business data, can jointly execute a consistency algorithm, such as Raft or Paxos, with other storage nodes used to store data copies of the target business data to verify the validity / correctness of certain specific information that is desired to be verified.

[0023] The following is an exemplary description of the log blocks stored in the storage node provided in the embodiments of this specification.

[0024] After obtaining several transaction logs included in the target log block to be generated, the storage node can determine several discrete fields for which an inverted index needs to be generated; for any target field among the several discrete fields, the storage node can generate an inverted index corresponding to the target field based on the field value of the target field in the several transaction logs and the transaction numbers corresponding to the several transaction logs; and the target log block can be generated based on the several transaction logs and the inverted indexes corresponding to the several discrete fields.

[0025] The aforementioned transaction number can be the arrangement sequence number of the corresponding transaction log among the multiple transaction logs included in the corresponding log block, or the arrangement sequence number (i.e., log number) of the corresponding transaction log among the multiple transaction logs stored in multiple log blocks on the storage node. This article will mainly use the example of the transaction number being the log number for illustrative description.

[0026] Continuing with the previous example, several transaction logs belonging to log block N include transaction numbers as follows ~ The m transaction logs may include transaction logs generated by executing the bill issuance transaction in the aforementioned example, wherein the transaction content of such transaction logs may include discrete fields "merchant" and "user". In the process of generating log block N, the storage node may use the discrete fields "merchant" and / or "user" as discrete fields for generating inverted indexes, and generate inverted indexes corresponding to "merchant" and / or "user" respectively according to the m transaction logs.

[0027] Here we assume that the value of m is 10 and the log numbers are ~ All 10 transaction logs are generated by merchants issuing invoices. The "Merchant" field value in transaction logs 1, 3, 5, and 7 is A1, the "Merchant" field value in transaction logs 2, 8, and 10 is A2, and the "Merchant" field value in transaction logs 4, 6, and 9 is A3. Therefore, an inverted index can be generated for the "Merchant" field, as shown in Table 1 below: The inverted index of the example in Table 1 above can show that in log block N, there are transaction logs with the "merchant" field and the field value of the "merchant" field is A1, and the corresponding transaction numbers are 、 、 、 ; For each transaction log that has a "Merchant" field and the value of the "Merchant" field is A2, the corresponding transaction number is 、 、 ; For each transaction log with a merchant field and a merchant field value of A3, the corresponding transaction number is 、 、 .

[0028] The storage node can store the inverted index in the form of key-value pairs. For example, the inverted index corresponding to the field "Merchant" includes the field value A1 and its corresponding transaction number. 、 、 、 , then the field value A1 can be "key" and the transaction number 、 、 、 is value, stored by A1 and 、 、 、 The key-value pair is used as an index entry in the inverted index corresponding to the field "Merchant". Typically, one or more key-value pairs / index entries included in the inverted index can be directly stored in a list, or a hash table can be used to store one or more key-value pairs / index entries included in the bitmap index. This facilitates more efficient implementation of the inverted index-based query in subsequent processes to find the target transaction number corresponding to the desired target transaction log.

[0029] The transaction number can be the log number of the transaction log or the order of the transaction log in the log block, so the transaction number can be used to locate the corresponding transaction log in the log block. For example, here it is assumed that among the multiple log blocks stored in order, the number (block number) of the first log block is 1, each log block stores m transaction logs, and the log block numbered N, that is, the log block N stores the log number ~ m transaction logs, then for log number ~ Log number in , log number The corresponding sequence number in the m logs is .

[0030] A log block can include a header and a body. Figure 2 As shown, several transaction logs can be arranged in order in the body of the log block, and the inverted index can be stored in the header or body of the log block. In order to facilitate the query and verification of the validity of the transaction information obtained from the transaction log, in some embodiments, the log block can also organize several transaction logs in order through a storage tree, and the target hash value corresponding to the root node of the storage tree can be stored in the header of the log block. A leaf node of the storage tree can correspond to a transaction log; the tree nodes other than the leaf nodes in the storage tree, that is, the intermediate nodes of the storage tree, can be stored in the body of the log block relatively independently from the several transaction logs.

[0031] The aforementioned storage tree may be a Merkle tree, or a Merkle B-tree, which is not limited here.

[0032] The following is an exemplary description of the bitmap index stored in the storage node provided in the embodiments of this specification.

[0033] After a storage node generates log block N, it can also update the bitmap indexes corresponding to several discrete fields based on the several inverted indexes included in log block N. The process of updating the bitmap index mainly includes: expanding the existence bitmap to the Nth element position corresponding to log block N and setting the value of the Nth element position.

[0034] Continuing with the previous example, if log block N includes an inverted index corresponding to the discrete field "merchant", the storage node can update the bitmap index corresponding to "merchant" based on the inverted index; if block N includes an inverted index corresponding to the discrete field "user", the storage node can update the bitmap index corresponding to "merchant" based on the inverted index.

[0035] Please refer to Figure 3The example bitmap index corresponding to the "Merchant" field. Here, it is assumed that after the storage node completes the N-1th update of the bitmap index corresponding to the "Merchant" field, the bitmap index includes the existence bitmaps corresponding to field values A1, A2, A3, and A4. A single existence bitmap includes N-1 element positions corresponding to the N-1 generated log blocks (i.e., log block 1 to log block N-1). In the existence bitmap corresponding to A1, the values of the first and N-1th element positions are 1, and the values of the remaining element positions are 0, indicating that a transaction log containing the "Merchant" field with a field value of A1 exists in log blocks 1 and log blocks N-1. In the existence bitmap corresponding to A2, the values of the first, second, and N-1th element positions are 1, and the values of the remaining element positions are 0, indicating that a transaction log containing the "Merchant" field with a field value of A2 exists in log blocks 1, log blocks 2, and log blocks N-1. In the existence bitmap corresponding to A3, the value of the second element position is 1, and the values of the remaining element positions are 0, indicating that a transaction log containing the "Merchant" field with a field value of A3 exists in log block 2. In the existence bitmap corresponding to A4, the values of the second and N-1th element positions are 1, and the values of the remaining element positions are 0, indicating that a transaction log containing the "Merchant" field with a field value of A4 exists in log blocks 2 and log blocks N-1.

[0036] Referring to the inverted index of the example in Table 1 above, the inverted index can indicate that: in log block N, there is a transaction log containing the "merchant" field with a field value of A1; in log block N, there is a transaction log containing the "merchant" field with a field value of A2; in log block N, there is a transaction log containing the "merchant" field with a field value of A3. Figure 3 As shown, the Nth element position of the existence bitmap corresponding to each of A1 to A4 can be expanded, and the value of the Nth element position in the existence bitmap corresponding to each of A1 to A3 can be set to 1; in addition, the inverted index of the above-mentioned Table 1 example fails to indicate that there is a transaction log containing the "Merchant" field and the field value is A4 in log block N. Therefore, the value of the Nth element position in the existence bitmap corresponding to A4 can be set to 0, indicating that there is no transaction log containing the "Merchant" field and the field value is A4 in log block N.

[0037] The process of updating the bitmap index described above is exemplary. After completing the continuous generation of k log blocks, the storage node can also update the inverted indexes corresponding to the discrete fields based on the inverted indexes included in each of the k log blocks and the block numbers of the k log blocks.

[0038] The storage node can store the bitmap index in the form of a key-value pair. For example, the bitmap index corresponding to the field "Merchant" includes an existence bitmap (denoted as M1) corresponding to the field value A1. The field value A1 can be used as the key and the existence bitmap M1 can be used as the value to store the key-value pair consisting of A1 and M1. In this way, one or more existence bitmaps corresponding to one or more field values in the bitmap index corresponding to the field "Merchant" can be stored through one or more key-value pairs. Generally, one or more key-value pairs included in the bitmap index can be directly stored in the form of a list, or a hash table can be used to store one or more key-value pairs included in the bitmap index, so as to facilitate more efficient implementation of querying the desired existence bitmap from the bitmap index in the subsequent process.

[0039] Next, a transaction log query processing method provided in an embodiment of this specification is described.

[0040] Figure 4 This is a flowchart of a transaction log query processing method provided in an embodiment of this specification. This method can be executed by a storage node, which stores multiple transaction logs via multiple log blocks. A single transaction log typically includes information such as a log number, transaction content, and a timestamp. The transaction content may include multiple fields and corresponding field values for each of the multiple fields. The multiple fields may contain one or more discrete fields.

[0041] Reference Figure 4 As shown, the method may include but is not limited to part or all of the following steps S401 to S413.

[0042] Step S401: receiving a data query request, wherein the data query request indicates a first field and a corresponding first field value, and the first field is a discrete field.

[0043] Depending on the query requester's intent, the target transaction information to be queried may be the complete transaction content, or it may be the field values of certain specific fields within the transaction content. If the target transaction information to be queried is not the complete transaction content, the data query request should also indicate the second field to be queried.

[0044] Continuing with the previous example, in a transaction log generated by a merchant executing a bill issuance transaction on a commodity trading platform, the transaction content may be a specific bill, including, for example, multiple fields such as merchant, user, product name, quantity, unit price, amount, tax rate, and tax amount, along with their corresponding field values. "Merchant" and "User" are discrete fields. When a query requester wishes to obtain the cumulative amount corresponding to bills issued by merchant A1, the query requester's data query request may include the field "Merchant" as the first field, with the field value "A1" being the first field value corresponding to the first field. Additionally, the field "Amount" may be the second field.

[0045] Step S403: query the bitmap index corresponding to the first field to obtain the existence bitmap corresponding to the first field value.

[0046] As mentioned above, the storage node can store the bitmap index in the form of key-value pairs. Correspondingly, in the bitmap index corresponding to the first field, the value with the first field value as the key can be used as the existence bitmap corresponding to the first field value; continuing with the above example, still with "Merchant" as the first field and A1 as the first field value, then A1 can be used as the key. Figure 3 The existence bitmap corresponding to A1 is found in the example bitmap index. It is understandable that when a hash table is used to store the bitmap index, the hash value of the first field value can be calculated, the storage location corresponding to the calculated hash value in the hash table can be determined, and the existence bitmap with the first field value as the key can be read from the determined storage location.

[0047] As mentioned above, executing Figure 4 The storage node in the illustrated method may be one of multiple storage nodes in a distributed storage system used to store target business data. The multiple transaction logs stored by the storage node via multiple log blocks correspond to log-type replicas of the target business data. In this case, the storage node may also perform the following step S405.

[0048] Step S405 : jointly verifying the existence bitmap with the remaining storage nodes in the plurality of storage nodes.

[0049] For example, refer to the above Figure 1According to the relevant description, storage node Node A stores a universal copy of the target business data, and Node B and Node C store log-type copies of the target business data. The universal copy includes the target business data and its corresponding transaction log, that is, Node A, Node B and Node C all store the transaction log corresponding to the target business data. Correspondingly, storage nodes Node A, Node B and Node C can all store the existence bitmap corresponding to the first field. In this way, a storage node used to store a log-type copy of the target business data, such as storage node Node B, can also jointly execute the corresponding consistency algorithm, such as Raft or Paxos, with Node A and Node C in the process of processing the AP request after obtaining the existence bitmap corresponding to the first field value through step S403, to jointly verify the validity / correctness of the existence bitmap corresponding to the first field value obtained by Node B through step S403.

[0050] When the existence bitmap verification passes, the following step S407 may be executed; otherwise, other processing procedures may be executed, such as resetting the existence bitmap that fails the verification or even directly rebuilding the corresponding bitmap index.

[0051] Step S407 : determining a target log block from the plurality of log blocks according to the existence bitmap corresponding to the first field value.

[0052] The existence bitmap corresponding to the first field value includes multiple element positions corresponding to multiple log blocks, wherein the value of any i-th element position can be used to indicate whether there is a "transaction log containing the first field and having the value of the first field as the first field value" in the i-th log block. Please continue to refer to Figure 3 In the example bitmap index, the first field is "Merchant" and the first field value is "A1". Assume that in the existence bitmap corresponding to A1, the values of the 3rd to N-2 element positions are all 0. Then, the element positions 1, N-1, and N with values of 1 can be determined from the existence bitmap corresponding to A1, thereby determining that the target log blocks include log block 1, log block N-1, and log block N.

[0053] Step S409 : query the inverted index corresponding to the first field in the target log block to determine the target transaction number corresponding to the target transaction log involving the first field and the first field value in the target log block.

[0054] With reference to the inverted index of the example in Table 1 above, it can be understood that the inverted index corresponding to the first field includes one or more index entries with the field value as the key and the transaction number as the value. Therefore, the index entry with the first field value as the key can be queried in the inverted index corresponding to the first field, and the transaction numbers corresponding to the respective target transaction logs containing the first field and whose field value is the first field value can be read from the index entry. In particular, when a hash table is used to store the inverted index, the hash value of the first field value can be first calculated, and the storage position in the hash table corresponding to the calculated hash value can be determined, and then the index entry with the first field value as the key can be queried in the determined storage position, and the target transaction numbers corresponding to the respective target transaction logs can be read from the index entry.

[0055] Continuing with the previous example, let's assume that the first field is "Merchant" and the first field value is A1. Assume that the inverted index corresponding to the "Merchant" field in log block N, which is the target log block, is as shown in Table 1. In this case, the storage node can use A1 as the key and query the index entry with A1 as the key in the inverted index in Table 1. Then, the transaction number that is the target transaction number can be read from this index entry. 、 、 、 .

[0056] Step S411: Read target transaction information from the target transaction log according to the target transaction number.

[0057] The transaction number can be the order in which the corresponding transaction log is arranged among the multiple transaction logs included in the corresponding log block. Alternatively, the transaction number can be the order in which the corresponding transaction log is arranged among the multiple transaction logs stored in multiple log blocks on the storage node (i.e., the log number). The transaction number can be used to locate the corresponding transaction log in the log block.

[0058] Taking the transaction number as the log number, let's assume that each log block stores m transaction logs. For log block N as the target log block, we can use the corresponding target transaction number, for example , the transaction number (i.e. log number) is calculated as The target transaction log is numbered in the order of the transaction logs included in log block N. , according to the sequence number to locate the transaction number is The target transaction log and the transaction number The target transaction information is read from the target transaction log. When the data query request does not specify a second field to be queried, the target transaction information may be the complete transaction content included in the target transaction log. When the data query request specifies a second field to be queried, the second field value of the second field may be read from the target transaction log as the target transaction information.

[0059] To facilitate querying and verifying the validity of transaction information obtained from the transaction log, the log block can also organize several transaction logs in an orderly manner through a storage tree. The target hash value corresponding to the root node of this storage tree can be stored in the log block header. Each leaf node of the storage tree corresponds to a transaction log; tree nodes other than leaf nodes in the storage tree, namely the intermediate nodes of the storage tree, can be stored relatively independently from the multiple transaction logs in the main body of the log block.

[0060] In this case, the storage node may further execute the following steps S413 and S415 on the target log block.

[0061] Step S413: Obtain an existence certificate corresponding to the target transaction information according to the storage tree used to organize the transaction logs belonging to the target log block.

[0062] Step S415: Verify the validity of the target transaction information based on the existence proof and the target hash value corresponding to the root node of the storage tree.

[0063] Taking the target log block as log block N and the storage tree used to organize several transaction logs as an example, the target hash value can be read from the header of log block N. In addition, based on the arrangement sequence of the target transaction log to which the target transaction information belongs in the several transaction logs, some intermediate nodes of the storage tree can be read from the body of log block N to form the Merkle path (i.e., proof of existence) corresponding to the target transaction log. Then, the hash value of the root node of the Merkle tree is recalculated based on the Merkle path and the target transaction log. If the recalculated hash value is the same as the target hash value, it means that the target transaction log has passed the validity verification, and it also means that the target transaction information read from the target transaction log has passed the verification.

[0064] Refer to the above and execute Figure 4 The storage node in the illustrated method may be one of multiple storage nodes in a distributed storage system used to store target business data. The storage node storing multiple transaction logs stored in multiple log blocks corresponds to a log-type replica of the target business data. In this case, the storage node may also execute the following step S413.

[0065] Step S417: jointly verify the target hash value with the remaining storage nodes in the multiple storage nodes.

[0066] The process of verifying the target hash value is similar to the process of verifying the existence bitmap and will not be repeated here. If the target hash value is verified, the corresponding target transaction information can be correctly returned to the query requester; if the target hash value is verified, other processing can be performed, such as rebuilding the corresponding target log block.

[0067] Based on the same concept as the aforementioned method embodiment, this embodiment of the specification further provides a storage node 500, which stores multiple transaction logs through multiple log blocks. Figure 5 As shown, the storage node 500 includes: a request receiving unit 501, configured to receive a data query request, which indicates a first field and a corresponding first field value, and the first field is a discrete field; a bitmap query unit 503, configured to query the bitmap index corresponding to the first field, obtain the existence bitmap corresponding to the first field value, and determine the target log block from the multiple log blocks according to the existence bitmap; a number query unit 505, configured to query the inverted index corresponding to the first field in the target log block, and determine the target transaction number corresponding to the target transaction log involving the first field and the first field value in the target log block; a log query unit 507, according to the target transaction number, reads the target transaction information from the target transaction log.

[0068] Those skilled in the art will appreciate that in one or more of the above examples, the functions described in this specification can be implemented using hardware, software, firmware, or any combination thereof. When implemented using software, the computer program corresponding to these functions can be stored in a computer-readable medium or transmitted as one or more instructions / codes on a computer-readable medium, so that when the computer program corresponding to these functions is executed by a computer, the method described in any embodiment of this specification is implemented by the computer.

[0069] An embodiment of this specification further provides a computer-readable storage medium having a computer program stored thereon. When the computer program is executed in a computing device, the computing device executes a transaction log query processing method provided in any embodiment of this specification.

[0070] An embodiment of this specification also provides a computing device including a memory and a processor, wherein the memory stores executable code, and when the processor executes the executable code, a transaction log query processing method provided in any embodiment of this specification is implemented.

[0071] The various embodiments in this specification are described in a progressive manner. References to the same or similar parts of each embodiment can be made to the other embodiments. Each embodiment focuses on the differences from other embodiments. In particular, the device embodiments are generally similar to the method embodiments, so their description is relatively simple. For relevant details, references to the method embodiments can be made to the descriptions of the method embodiments.

[0072] The foregoing description of this specification describes specific embodiments. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims can be performed in an order different from that described in the embodiments and still achieve the desired results. Furthermore, the processes depicted in the accompanying drawings do not necessarily require the specific order shown or the sequential order to achieve the desired results. In certain embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0073] The specific implementation methods described above further illustrate the objectives, technical solutions and beneficial effects of the present invention in detail. It should be understood that the above description is only a specific implementation method of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent replacements, improvements, etc. made on the basis of the technical solution of the present invention should be included in the scope of protection of the present invention.

Claims

1. A transaction log query processing method, the method being executed by a storage node, the storage node storing multiple transaction logs via multiple log blocks, the method comprising: Receive a data query request, which indicates a first field and a corresponding first field value, where the first field is a discrete field; querying a bitmap index corresponding to the first field to obtain an existence bitmap corresponding to the first field value, and determining a target log block from the plurality of log blocks according to the existence bitmap; querying an inverted index corresponding to the first field in the target log block to determine a target transaction number corresponding to a target transaction log involving the first field and the first field value in the target log block; Read target transaction information from the target transaction log according to the target transaction number.

2. According to the method of claim 1, the data query request further indicates a second field; the target transaction information includes a second field value corresponding to the second field.

3. According to the method of claim 1, the storage node belongs to multiple storage nodes in a distributed storage system for storing target business data, and the multiple transaction logs correspond to log-type copies of the target business data.

4. The method according to claim 3, further comprising: The existence bitmap is jointly verified with the remaining storage nodes of the plurality of storage nodes.

5. The method according to claim 1, further comprising: Obtaining several transaction logs included in the target log block to be generated; Determine the discrete fields for which inverted indexes need to be generated; For any target field among the plurality of discrete fields, generating an inverted index corresponding to the target field according to the field value of the target field in the plurality of transaction logs and the transaction numbers corresponding to the plurality of transaction logs; A target log block is generated according to the inverted indexes corresponding to the transaction logs and the discrete fields.

6. The method according to claim 5, further comprising: According to the inverted indexes corresponding to the discrete fields and the block number of the target log block, the bitmap indexes corresponding to the discrete fields are updated.

7. The method according to claim 1, wherein the body of the target log block organizes several transaction logs belonging to the target log block through a storage tree, and the header of the target log block includes a target hash value corresponding to the root node of the storage tree; wherein, The method further comprises: Obtaining a proof of existence corresponding to the target transaction information according to the storage tree; The validity of the target transaction information is verified based on the existence proof and the target hash value.

8. The method according to claim 7, wherein the storage node belongs to a plurality of storage nodes in a distributed storage system for storing target business data, and the plurality of transaction logs correspond to log-type copies of the target business data; in, The method further comprises: The target hash value is jointly verified with the remaining storage nodes in the plurality of storage nodes.

9. A storage node storing multiple transaction logs using multiple log blocks, the storage node comprising: a request receiving unit configured to receive a data query request, wherein the request indicates a first field and a corresponding first field value, wherein the first field is a discrete field; a bitmap query unit configured to query a bitmap index corresponding to the first field, obtain an existence bitmap corresponding to the first field value, and determine a target log block from the plurality of log blocks based on the existence bitmap; a number query unit configured to query an inverted index corresponding to the first field in the target log block, and determine a target transaction number corresponding to a target transaction log involving the first field and the first field value in the target log block; The log query unit reads target transaction information from the target transaction log according to the target transaction number.

10. A computing device comprising a memory and a processor, wherein the memory stores a computer program, and when the processor executes the computer program, the method according to any one of claims 1 to 8 is implemented.

Images