Distributed database query method, distributed database, device, medium and product

Abstract

The invention discloses a distributed database query method, a distributed database, a device, a medium and a product; the method comprises: when a query request satisfies a target condition, a distributed database portal determines a storage node to be queried and a corresponding sub-query request, and sends the sub-query request to the corresponding storage node to be queried; each storage node to be queried queries a data table in the storage node to be queried in parallel through a main connection and at least one auxiliary connection between the storage node to be queried and the distributed database portal, and feeds back to the distributed database portal; the distributed database portal performs connection calculation on the query result, determines the target query request, and executes the target query request on the main connection corresponding to each storage node to be queried and a client, determines the query result, solves the problem of high latency when the distributed database queries data rows of multiple storage nodes, reduces the query latency of the distributed database executing complex SQL, and improves the query efficiency.

Description

Technical Field

[0001] The present invention relates to the technical field of distributed databases, and in particular to a distributed database query method, a distributed database, equipment, a medium and a product. Background Art

[0002] Distributed databases decompose business structured query language (SQL) requests to multiple storage nodes for execution. Storage nodes can usually guarantee ACID (atomicity, consistency, isolation, and durability) characteristics, but simply decomposing business SQL requests into multiple requests for execution on storage nodes cannot guarantee the isolation of distributed transactions as a whole.

[0003] Dirty reads may occur between transactions that operate on the same data table. For example, assume that a distributed database has storage nodes A and B. Distributed transaction 1 updates data on both storage nodes A and B. When entering the commit phase, the commit request will be decomposed into commit instructions for storage nodes A and B. If the commit speed of storage node A is faster than that of storage node B, there will be an intermediate state where A commits but B does not. If distributed transaction 2 queries storage nodes A and B at this time, it will be found that distributed transaction 1 has been modified on storage node A but not on B. But in fact. Distributed transaction 1 as a whole should be considered as an unfinished commit. For distributed transaction 2, this query result is a dirty read and does not follow the correct isolation. The ACID consistency of distributed transactions, that is, global transaction read consistency, cannot be guaranteed.

[0004] The multi-version concurrency control method based on TSO Server (global clock service) can solve the above problems, but this method has performance problems. The distributed database entry Gate serially queries all data rows of multiple tables from each storage node. If the table is large, the delay will be high. Summary of the invention

[0005] The present invention provides a distributed database query method, a distributed database, a device, a medium and a product to solve the problem of high latency when a distributed database queries data rows of multiple storage nodes.

[0006] According to one aspect of the present invention, a distributed database query method is provided, which is applied to a distributed database, wherein the distributed database includes a distributed database entry and at least one storage node, including:

[0007] After receiving the query request from the client, the distributed database portal determines at least one storage node to be queried and its corresponding sub-query request according to the query request if the query request meets the target condition, and sends the sub-query request to the corresponding storage node to be queried;

[0008] Each storage node to be queried queries the data table in the storage node to be queried in parallel through the main connection and at least one auxiliary connection between the storage node to be queried and the distributed database portal, determines the query result corresponding to the subquery request and feeds it back to the distributed database portal, wherein the auxiliary connection queries the data table in the storage node to be queried based on the connection identifier of the main connection and the distributed snapshot of the single-machine transaction opened on the main connection;

[0009] The distributed database entry performs connection calculation on the query results corresponding to each of the sub-query requests, determines the target query request, and executes the target query request on the main connection corresponding to each of the storage nodes to be queried and the client, to determine the query result of the query request.

[0010] According to another aspect of the present invention, there is provided a distributed database, the distributed database comprising a distributed database entry and at least one storage node;

[0011] A distributed database entry is used to, after receiving a query request from a client, determine at least one storage node to be queried and its corresponding sub-query request according to the query request and send the sub-query request to the corresponding storage node to be queried if the query request meets a target condition;

[0012] Each storage node to be queried is used to query the data table in the storage node to be queried in parallel through the main connection and at least one auxiliary connection between the storage node to be queried and the distributed database entry, determine the query result corresponding to the subquery request and feed it back to the distributed database entry, wherein the auxiliary connection queries the data table in the storage node to be queried based on the connection identifier of the main connection and the distributed snapshot of the single-machine transaction opened on the main connection;

[0013] The distributed database entry is used to perform connection calculation on the query results corresponding to each of the sub-query requests, determine the target query request, and execute the target query request on the main connection corresponding to each of the storage nodes to be queried and the client to determine the query result of the query request.

[0014] According to another aspect of the present invention, an electronic device is provided, the electronic device comprising:

[0015] at least one processor, and a memory communicatively coupled to the at least one processor;

[0016] The memory stores a computer program that can be executed by the at least one processor, and the computer program is executed by the at least one processor so that the at least one processor can execute the distributed database query method described in any embodiment of the present invention.

[0017] According to another aspect of the present invention, a computer-readable storage medium is provided, wherein the computer-readable storage medium stores computer instructions, and the computer instructions are used to enable a processor to implement the distributed database query method described in any embodiment of the present invention when executed.

[0018] According to another aspect of the present invention, a computer program product is provided. The computer program product includes a computer program. When the computer program is executed by a processor, the distributed database query method described in any embodiment of the present invention is implemented.

[0019] The technical solution of the embodiment of the present invention is that after receiving a query request from a client through a distributed database portal, if the query request meets a target condition, at least one storage node to be queried and its corresponding sub-query request are determined according to the query request, and the sub-query request is sent to the corresponding storage node to be queried; each storage node to be queried, through a main connection and at least one auxiliary connection between the storage node to be queried and the distributed database portal, queries a data table in the storage node to be queried in parallel, determines a query result corresponding to the sub-query request and feeds it back to the distributed database portal, wherein the auxiliary connection is based on a connection identifier of the main connection and a single-machine transaction opened on the main connection The distributed snapshot queries the data table in the storage node to be queried; the distributed database portal performs connection calculation on the query results corresponding to each sub-query request, determines the target query request, and executes the target query request on the main connection corresponding to each storage node to be queried and the client, determines the query result of the query request, solves the problem of high latency when the distributed database queries data rows of multiple storage nodes, and supports the distributed database portal to query all data rows of each table in parallel from multiple connections corresponding to the client of each storage node based on the distributed snapshot while ensuring the consistency of global transactions, thereby reducing the query latency of the distributed database in executing complex SQL and improving the query efficiency.

[0020] It should be understood that the contents described in this section are not intended to identify the key or important features of the embodiments of the present invention, nor are they intended to limit the scope of the present invention. Other features of the present invention will become easily understood through the following description. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] In order to more clearly illustrate the technical solutions in the embodiments of the present invention, 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 creative work.

[0022] Figure 1 This is a diagram of an implementation architecture of multi-version concurrency control based on TSO Server provided by an embodiment of the present invention;

[0023] Figure 2 is a flow chart of a distributed database query method provided by an embodiment of the present invention;

[0024] Figure 3 is a flow chart of a distributed database query method provided by an embodiment of the present invention;

[0025] Figure 4 It is a flowchart of implementing a query of a storage node to be queried through an auxiliary connection provided by an embodiment of the present invention;

[0026] Figure 5 It is a schematic diagram of the structure of a distributed database provided by an embodiment of the present invention;

[0027] Figure 6 It is a structural schematic diagram of an electronic device provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0028] In order to enable those skilled in the art to better understand the scheme of the present invention, the technical scheme in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of the present invention.

[0029] It should be noted that the terms "first", "second", etc. in the specification and claims of the present invention and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchanged where appropriate, so that the embodiments of the present invention described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to those steps or units that are clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0030] Figure 1 An implementation architecture diagram of a multi-version concurrency control based on TSO Server is provided for an embodiment of the present invention. The architecture includes: a distributed database portal 11, a global clock service 12, a client 13 and at least one storage node 14.

[0031] Among them, the entry 11 of the distributed database is mainly responsible for processing client requests and distributing the requests to various storage nodes, and is also responsible for controlling the execution process of distributed transactions;

[0032] The global clock service 12 is responsible for distributing globally unique increasing timestamps.

[0033] Snapshot-TS (sts): When a distributed transaction starts, the Gate is obtained from the TSO. When each storage node transaction is started, the sts is issued. That is, each storage node transaction belonging to this distributed transaction has the same sts. Each storage node transaction uses the same sts to query data to meet the ACID consistency of the distributed transaction.

[0034] Commit-TS (cts): Before the distributed transaction is committed, the Gate obtains it from the TSO. When each storage node transaction is committed, cts is issued. That is, each storage node transaction belonging to this distributed transaction has the same cts. Each storage node transaction has the same cts to meet the ACID consistency of the distributed transaction.

[0035] Storage node 14 is responsible for the storage of distributed database data. The storage node can be a stand-alone database or a storage node of distributed storage. The storage node uses global multi-version concurrency control technology. The transaction is a write operation to modify the latest version of the data, and at the same time generate the historical version of the data. Each version of the data adds the persistence of the cts column, which represents the cts of the distributed transaction that updates this data version; when a read operation occurs, according to the snapshot obtained at the beginning of the transaction where the read operation is located, starting from the latest version, the historical version data is traversed in reverse order to find the first version of the data item that can be read (a certain version of data can be read, generally also referred to as a certain version of data visible). There are two snapshots, one is a local transaction snapshot, which is a collection of currently active transactions. Using this snapshot to read data (determine whether the data is visible) can read data consistent with the single-machine transaction; the other is a distributed transaction snapshot (also called a global snapshot), that is, sts. Using this snapshot to read data (determine whether the data is visible) can read data consistent with the global transaction. Therefore, the storage node transaction belonging to the distributed transaction determines whether the data is visible based on the distributed transaction snapshot, so as to ensure the read consistency of the global transaction.

[0036] When Gate receives some complex SQL requests, for example: Delete from t1 where last_name in (select last_name from t2).

[0037] t1 and t2 are distributed tables with the same table structure, both containing the following columns: id, first_name, and last_name. The id column is the primary key, and the data is evenly stored in multiple storage nodes based on the value of the id column (hash algorithm).

[0038] The correct behavior of executing this SQL is to delete the data rows in t1 that meet target condition 1 on each storage node. Target condition 1 is that the value of the last_name column of the data row in the t1 table is the same as the value of the last_name column of any data row in the t2 table on all storage nodes.

[0039] Gate cannot send this SQL statement directly to each storage node for execution, because this is an incorrect behavior: on each storage node, delete the data rows in t1 that meet target condition 2, where the value of the last_name column of the data row in table t1 is the same as the value of the last_name column of any data row in table t2 on the current storage node. Target condition 2 is different from target condition 1.

[0040] For the execution of this sample SQL, the existing solution mainly includes the following steps:

[0041] A. Gate receives the sql sent by the client and obtains sts;

[0042] B. Gate queries all data rows of t1 from the unique connection corresponding to each storage node of the client based on sts;

[0043] C. Gate queries all data rows of t2 from the unique connection corresponding to each storage node of the client based on sts;

[0044] D. Gate performs join calculation on all data rows of t1 and all data rows of t2 based on the value of the last_name column, obtains the target t1 data row set (containing only the last_name column), and generates the target SQL (delete from t1where last_name in (target t1 data row set));

[0045] E. Gate executes the target SQL on the only connection of each storage node corresponding to the client to complete the target operation.

[0046] Furthermore, for similar complex SQL requests, which cannot be directly sent to each storage node for execution, it is necessary to pull all data rows of multiple tables from each storage node, then perform connection calculations, and finally generate the target SQL to be sent to each storage node. The existing solutions are as follows:

[0047] A. Gate receives the complex SQL sent by the client and obtains sts;

[0048] B. Gate queries all data rows in each table based on the unique connection serial of each storage node corresponding to the client based on sts;

[0049] C. Gate performs join calculations on each table to generate the target SQL;

[0050] D. Gate executes the target SQL on the only connection of each storage node corresponding to the client to complete the target operation.

[0051] However, the above method has performance problems. Gate serially queries all data rows of multiple tables from each storage node. If the table is large, the delay will be high. The distributed database query method provided by the embodiment of the present application can reduce the query delay while ensuring the read consistency of global transactions.

[0052] Figure 2 This is a flow chart of a distributed database query method provided by an embodiment of the present invention. This embodiment is applicable to the case of performing parallel query on storage nodes in a distributed database.

[0053] like Figure 2 As shown, the method includes:

[0054] S101. After receiving a query request from a client, if the query request meets a target condition, the distributed database portal determines at least one storage node to be queried and its corresponding sub-query request according to the query request, and sends the sub-query request to the corresponding storage node to be queried.

[0055] In this embodiment, the query request can be a database request such as SQL; the target condition can be preset, for example, the target condition is that the SQL cannot be sent directly to each storage node for execution, and all data rows of multiple tables need to be pulled from each storage node, and then connected and calculated, and finally the target SQL sent to each storage node is generated. The storage node to be queried can be understood as the storage node that needs to perform data query; the subquery request can be understood as a request for querying the storage node to be queried.

[0056] When querying data, users can establish a connection with the distributed database through the client and send a query request to the distributed database portal through the client. After receiving the query request, the distributed database portal determines whether the query request meets the target condition. If so, it parses the query request, determines the storage node to be queried and its corresponding sub-query request, and sends the sub-query request to the corresponding storage node to be queried.

[0057] S102. Each storage node to be queried queries the data table in the storage node to be queried in parallel through the main connection and at least one auxiliary connection between the storage node to be queried and the distributed database portal, determines the query result corresponding to the subquery request and feeds it back to the distributed database portal, wherein the auxiliary connection queries the data table in the storage node to be queried based on the connection identifier of the main connection and the distributed snapshot of the single-machine transaction opened on the main connection.

[0058] After the client establishes a connection with the distributed portal, a main connection and at least one auxiliary connection are established between the storage node to be queried and the distributed database portal corresponding to this client. Each storage node to be queried queries the data table in the storage node to be queried in parallel through the main connection and at least one auxiliary connection between the storage node to be queried and the distributed database portal. At this time, the more the number of main connections and auxiliary connections, the more the number of parallel executions of the storage node to be queried, and the faster the query speed. However, considering that the resources of the storage node to be queried are limited when querying some data, in order to avoid waste of resources, the number of auxiliary connections can be set based on multiple factors, for example, according to one or more factors such as business type, the number of storage nodes in the database, and the number of data tables. According to the sub-query request, the data table in the storage node to be queried is queried, the data of the data row is obtained from the data table, the corresponding query result is obtained, and then fed back to the distributed database portal.

[0059] When the storage node to be queried queries the data table through the auxiliary connection, the main connection is determined based on the connection identifier of the main connection, and the latest visible version of the data is determined based on the distributed snapshot of the stand-alone transaction opened on the main connection, so as to achieve global transaction read consistency. When the distributed database portal establishes a connection with the storage node to be queried, the connection identifier is returned to the distributed database portal as a result by the storage node to be queried. For each storage node in the distributed database, a connection identifier can be generated and fed back to the distributed data portal when a connection is established with the distributed database portal. For the main connection, no other information is required when querying. The stand-alone transaction has been opened on the main connection, and the distributed snapshot of the transaction has been set. The distributed snapshot of this transaction will be used when querying.

[0060] For a storage node to be queried, different data tables can be queried on different connections. For example, data table 1 can be queried on the primary connection, data table 2 can be queried on auxiliary connection 1 through the connection identifier of the primary connection and the distributed snapshot, data table 3 can be queried on auxiliary connection 2 through the connection identifier of the primary connection and the distributed snapshot, and so on, to achieve parallel query.

[0061] S103, the distributed database portal performs connection calculation on the query results corresponding to each sub-query request, determines the target query request, and executes the target query request on the main connection corresponding to each storage node to be queried and the client, to determine the query result of the query request.

[0062] In this embodiment, the target query request can be understood as a query request obtained after connection calculation.

[0063] After the distributed database portal queries all data rows of multiple tables in the storage node to be queried through a subquery request, the query result corresponding to the subquery request is connected and calculated to obtain the target query request, and all the storage nodes to be queried are traversed. For each storage node to be queried, the target query request is executed on the main connection corresponding to the storage node to be queried and the client. The result obtained is the query result of the query request sent by the client. After obtaining the query result of the query request, the query result can be fed back to the client, and the client performs the next step of processing, or the client displays it to the user, etc.

[0064] The embodiment of the present invention provides a distributed database query method, which solves the problem of high latency when a distributed database queries data rows of multiple storage nodes. The data table in the storage node to be queried is queried in parallel through a main connection and at least one auxiliary connection between the storage node to be queried and the distributed database portal, thereby realizing fast query of data rows. Compared with the serial query in the prior art, the query latency is effectively reduced. While ensuring the consistency of global transactions, the distributed database portal is supported to query all data rows of each table in parallel from multiple connections of each storage node corresponding to the client based on a distributed snapshot, thereby reducing the query latency of the distributed database executing complex SQL and improving the query efficiency.

[0065] Figure 3 This is a flow chart of a distributed database query method provided by an embodiment of the present invention. This embodiment is refined on the basis of the above embodiment. Figure 3 As shown, the method includes:

[0066] S201. After receiving a query request from a client, if the query request meets a target condition, the distributed database portal determines at least one storage node to be queried and its corresponding sub-query request according to the query request, and sends the sub-query request to the corresponding storage node to be queried.

[0067] S202. If the stand-alone transaction is not enabled on the main connection between the storage node and the distributed database portal corresponding to the client, the distributed database portal obtains the latest timestamp, enables the stand-alone transaction on the main connection, and sets the distributed snapshot of the stand-alone transaction to the latest timestamp.

[0068] The distributed database portal determines whether a single-machine transaction has been opened on the main connection corresponding to the client, the storage node and the distributed database portal. If it has been opened, step S203 is directly executed. If it has not been opened, the latest timestamp sts1 is obtained. The latest timestamp can be obtained from the TSO Server, and a single-machine transaction is opened on the main connection, and the distributed snapshot of the single-machine transaction is set to the latest timestamp sts1.

[0069] When judging whether a stand-alone transaction is opened on the main connection between the storage node and the distributed database portal corresponding to the client, it can be determined by whether the client has sent a request to open a distributed transaction; if the client has sent a request to open a distributed transaction (that is, the request of this query request is executed in a distributed transaction, and the distributed database portal has opened a stand-alone transaction on the main connection corresponding to the client, and set a distributed snapshot of the transaction; at the same time, this distributed transaction may have executed several SQL requests), S203 can be directly executed; otherwise, the distributed database portal obtains the latest timestamp, opens a stand-alone transaction on the main connection, and sets the distributed snapshot of the stand-alone transaction to the latest timestamp.

[0070] The distributed database portal traverses all storage nodes to be queried and performs the same query operation on each storage node to be queried.

[0071] S203. Each storage node to be queried queries the data table in the storage node to be queried in parallel through the main connection and at least one auxiliary connection between the storage node to be queried and the distributed database portal, determines the query result corresponding to the subquery request and feeds it back to the distributed database portal, wherein the auxiliary connection queries the data table in the storage node to be queried based on the connection identifier of the main connection and the distributed snapshot of the single-machine transaction opened on the main connection.

[0072] S204, the distributed database portal performs connection calculation on the query results corresponding to each sub-query request, determines the target query request, and executes the target query request on the main connection corresponding to each storage node to be queried and the client, to determine the query result of the query request.

[0073] As an optional embodiment, this optional embodiment further queries the data table in the storage node to be queried through the auxiliary connection between the storage node to be queried and the distributed database entry, determines the query result corresponding to the sub-query request, and performs optimization, including steps A1-A4:

[0074] A1. The storage node to be queried receives the subquery request, the connection identifier of the main connection, and the distributed snapshot of the stand-alone transaction opened on the main connection through the auxiliary connection between the storage node to be queried and the distributed database portal.

[0075] The auxiliary connection of the storage node to be queried receives the subquery request sent by the distributed database entry, the connection identifier (conn_id) of the main connection, and the distributed snapshot sts. When the auxiliary connection receives the subquery request, it means that the main connection has opened a single-machine transaction (trx), and the distributed snapshot of trx is sts, that is, the distributed snapshot used by the auxiliary connection query uses the same distributed snapshot query data as the single-machine transaction opened on the main connection to ensure global transaction read consistency.

[0076] A2. The storage node to be queried parses the subquery request and determines the name of the table to be queried and the filtering condition.

[0077] In this embodiment, the name of the table to be queried can be understood as the name of the data table to be queried, and the filtering condition can be understood as the condition for filtering the data rows in the data table. The storage node to be queried parses the subquery request to determine the name of the table to be queried and the filtering condition used for the query.

[0078] A3. The storage node to be queried queries the global connection list according to the connection identifier of the primary connection to determine the primary connection. If the primary connection has not started to release resources, the table resolution object is obtained according to the name of the table to be queried.

[0079] In this embodiment, the global connection list is used to store all connections on the storage node, and each storage node corresponds to a global connection list to store the primary connection and auxiliary connection of this storage node. The table parsing object is used to parse the value of each column of the row data of the table.

[0080] The storage node to be queried queries the global connection list corresponding to this storage node according to the connection identifier of the primary connection to determine the corresponding primary connection. Determine whether the primary connection has started to release resources. If it has, an error is returned to the distributed database entry, indicating that the primary connection is accidentally disconnected. The parallel query of the auxiliary link does not need to continue to execute, and an error is directly returned. If the resource release has not started, determine whether the temporary table created on the primary connection or the ordinary table needs to be accessed by the name of the table to be queried, and obtain the corresponding table resolution object.

[0081] Whether the main connection starts releasing resources can be marked by the start releasing resource flag; for example, if the start releasing resource flag is true, it means that the main connection starts releasing resources, and if the start releasing resource flag is false, it means that the main connection does not start releasing resources. When marking by the start releasing resource flag, the start releasing resource flag defaults to false.

[0082] As an optional embodiment, this optional embodiment further optimizes obtaining a table resolution object according to the name of the table to be queried, including: querying a temporary table list of the main connection according to the name of the table to be queried; if there is a table structure matching the name of the table to be queried in the temporary table list, obtaining the table resolution object of the temporary table; otherwise, obtaining the table resolution object of the ordinary table.

[0083] In this embodiment, the temporary table list stores the table structures of all temporary tables created on the main connection. When a temporary table is created, a table structure is created accordingly and then inserted into the temporary table list. When the temporary table is deleted, the table structure is deleted from the temporary table list.

[0084] Query the temporary table list of the main connection according to the name of the table to be queried, and determine whether there is a table structure matching the name of the table to be queried in the temporary table list. If it matches, it is determined that the temporary table created on the main connection needs to be accessed, and the table resolution object of the temporary table is obtained; if it does not match, it means that the data table to be accessed is a common table, and the table resolution object of the common table is obtained.

[0085] As an optional embodiment, this optional embodiment further optimizes the table parsing object for obtaining the temporary table, including:

[0086] B1. If the list of available table resolution objects of the table structure is empty, create a table resolution object based on the table structure, and use the created table resolution object as the table resolution object of the temporary table.

[0087] In this embodiment, the available table resolution object list stores the available table resolution objects corresponding to the table structure, that is, the available table resolution object list stores the unused table resolution objects corresponding to the table structure, so as to realize the reuse of the table resolution objects and avoid the performance loss caused by the frequent creation and destruction of the table resolution objects. The available table resolution object list corresponding to the table structure is determined, and the table resolution objects in the available table resolution object list are queried. If the available table resolution object list is empty, it means that there is no available table resolution object at this time. A table resolution object table_query is created based on the table structure, and the created table resolution object is used as the table resolution object of the temporary table.

[0088] B2. If the list of available table parsing objects of the table structure is not empty, select a table parsing object from the list of available table parsing objects as the table parsing object of the temporary table.

[0089] If the list of available table resolution objects of the table structure is not empty, there are available table resolution objects and no need to recreate them; select a table resolution object from the list of available table resolution objects, for example, randomly select a table resolution object as the table resolution object of the temporary table, select a table resolution object according to the order of table resolution objects as the table resolution object of the temporary table, and so on.

[0090] As an optional embodiment, this optional embodiment is further optimized to include that after obtaining the table resolution object of the temporary table, the storage node to be queried adds the table resolution object to the list of used table resolution objects and accumulates the temporary table access count of the main connection.

[0091] In this embodiment, the used table resolution object list stores the used table resolution objects corresponding to the table structure. The temporary table access count indicates the number of auxiliary connections accessing the temporary table created by the primary connection, and the initial value is 0.

[0092] After obtaining the table resolution object of the temporary table, the storage node to be queried adds the table resolution object to the list of used table resolution objects to ensure that this table resolution object is not used simultaneously by different auxiliary connections; at the same time, the temporary table access count of the primary connection is accumulated, for example, plus 1, indicating that the number of auxiliary connections accessing the temporary table of the primary connection has increased by one.

[0093] As an optional embodiment, this optional embodiment is further optimized to include that after selecting a table resolution object from the available table resolution object list as the table resolution object of the temporary table, the storage node to be queried deletes the table resolution object from the available table resolution object list.

[0094] After a table resolution object is selected from the list of available table resolution objects as the table resolution object of the temporary table, the table resolution object changes from the available state to the used state, and the storage node to be queried deletes the table resolution object from the list of available table resolution objects to prevent it from being obtained and used simultaneously by other auxiliary connections.

[0095] The overall process of obtaining the table parsing object of the temporary table can be described as:

[0096] If the free table query list (free_table_query_list) of the table structure table_def is empty, create a table query object (table_query) based on table_def, and then insert table_query into the used table query list (used_table_query_list) of table_def, and at the same time increase the temporary table access count (temp_table_access_count) of main_conn by 1.

[0097] If the free_table_query_list of table_def is not empty, take a table_query object from the free_table_query_list of table_def, delete table_query from the free_table_query_list of table_def, and insert table_query into the used_table_query_list of table_def. At the same time, temp_table_access_count of main_conn is incremented by 1.

[0098] A4. The storage node to be queried reads the data rows of the data table in the storage node to be queried based on the table parsing object, the filter condition and the distributed snapshot, and determines the query result corresponding to the subquery request.

[0099] The storage node to be queried queries and filters the data rows of the stored data table based on the filtering conditions, and judges the read data rows through the table parsing object and distributed snapshot to determine whether it is available data. If so, the queried data is used as the query result corresponding to the subquery request.

[0100] As an optional embodiment, this optional embodiment further reads the data rows of the data table in the storage node to be queried based on the table parsing object, the filter condition and the distributed snapshot, determines the query result corresponding to the subquery request, and performs optimization, including steps C1-C3:

[0101] C1. Query the latest version of each row of data in the data table in the storage node to be queried based on the filter condition.

[0102] The data table in the storage node to be queried is queried based on the filter condition to determine the latest version of each data row that meets the filter condition.

[0103] C2. The visibility of the latest version of each data row is judged based on the table parsing object and the distributed snapshot. If the data row is visible, the data row is added to the data row result set. If the data row is not visible, a new latest version is determined, and the process returns to judge the visibility of the latest version of each data row based on the table parsing object and the distributed snapshot until the latest version of the data row is visible.

[0104] In this embodiment, the data row result set can be understood as a set formed by the data rows obtained by the query.

[0105] The latest version of each data row is judged for visibility based on the table parsing object and the distributed snapshot. For example, the latest version is determined to be invisible if it is modified by other transactions and the transaction is not committed through the table parsing object and the distributed snapshot. Alternatively, the latest version is determined to be visible if it is modified by the transaction on the primary connection and the transaction is not committed through the table parsing object and the distributed snapshot. If the latest version is visible, the data row is directly added to the data row result set. If the latest version is not visible, a new latest version is determined, and the visibility judgment of the latest version of each data row based on the table parsing object and the distributed snapshot is returned until the latest visible version of the data row is determined, and then the data row with the latest visible version is added to the data row result set.

[0106] C3. After determining the latest visible versions of all data rows, the data row result set is used as the query result corresponding to the subquery request.

[0107] After querying the latest visible version of each data row in turn, add the latest visible version of the data row to the data row result set; after determining the latest visible version of all data rows, the data row result set now saves each queried data row, and uses the data row result set as the query result corresponding to the subquery request.

[0108] As an optional embodiment, this optional embodiment further optimizes the visibility judgment of the latest version of the data row based on the table resolution object and the distributed snapshot, including:

[0109] D1. Parse the transaction identifier and commit timestamp of the data row based on the table parsing object.

[0110] The transaction identifier and the commit timestamp are two system columns of the row data. The data row is parsed based on the table parsing object to determine the system columns of the data row. The two column values ​​corresponding to the transaction identifier and the commit timestamp are read to determine the transaction identifier and the commit timestamp.

[0111] Optionally, the transaction identifier of the data row is determined according to the transaction identifier of the current transaction that updates the data row when the data row is updated; the commit timestamp of the data row is set to a preset value when the data row is updated, and is set to the commit timestamp of the current transaction when the current transaction that updates the data row is committed.

[0112] The transaction identifier and commit timestamp are the values ​​of two system columns of the row data. When updating a data row, the value of the transaction identifier column of the data row will be updated to the transaction identifier of the current transaction and the value of the commit timestamp column will be updated to the preset value. For example, the preset value can be 0. When the transaction is committed, the value of the commit timestamp column of all data rows modified by the transaction will be updated to the commit timestamp of the current transaction. The assignment method of the transaction identifier and commit timestamp of the current transaction is not limited. When the commit timestamp cts1 is the preset value, this row of data has been modified by a transaction and the transaction has not been committed.

[0113] D2. If the commit timestamp is the preset value, query the transaction status information in the global transaction status list according to the transaction identifier.

[0114] In this embodiment, the global transaction status list stores the status information of all running transactions. The transaction status information includes the transaction identifier and the distributed snapshot of the transaction. The transaction identifier of each transaction is unique. When each transaction is started, the status information of the transaction is added to the global transaction status list. When the transaction is committed or rolled back, the status information of the transaction is deleted from the global transaction status list. If the commit timestamp is a preset value, the transaction status information corresponding to the transaction identifier is queried in the global transaction status list.

[0115] D3. Get the global snapshot timestamp of the transaction from the transaction status information. If the global snapshot timestamp is the same as the distributed snapshot timestamp, it is determined that the latest version of the data row is visible.

[0116] Get the global snapshot timestamp sts1 of this transaction from the transaction status information. If the distributed snapshot sts is equal to the global snapshot timestamp sts1, it means that this transaction is opened on the main connection, and this row of data is the latest version modified by the transaction opened on the main connection. This latest version is visible. This data row can be added to the data row result set.

[0117] Optionally, if the table resolution object is a table resolution object of a temporary table, after determining the query result corresponding to the subquery request, the method further includes:

[0118] E1. The storage node to be queried determines the primary connection according to the connection identifier of the primary connection, queries the temporary table list of the primary connection according to the name of the table to be queried, and determines the table structure corresponding to the name of the table to be queried.

[0119] If the table resolution object is a temporary table resolution object, that is, the temporary table created on the main connection is accessed at this time, after determining the query result corresponding to the subquery request, the state of the table resolution object is changed. The storage node to be queried queries the global connection list according to the connection identifier of the main connection to determine the main connection, and queries the temporary table list of the main connection according to the name of the table to be queried to determine the table structure corresponding to the name of the table to be queried.

[0120] E2. The storage node to be queried deletes the table resolution object from the used table resolution object list of the table structure, and adds the table resolution object to the available table resolution object list of the table structure.

[0121] The storage node to be queried determines the list of used table resolution objects of the table structure. Since the query has been completed at this time, the table resolution object is deleted from the list of used table resolution objects and added to the list of available table resolution objects of the table structure for subsequent reuse.

[0122] E3. The storage node to be queried decrements the temporary table access count of the primary connection.

[0123] The storage node to be queried decrements the temporary table access count of the primary connection, for example, decrements by 1, indicating that the number of auxiliary connections accessing the temporary table created by the primary connection is reduced by one.

[0124] As an optional embodiment, this optional embodiment is further optimized to include steps F1-F4:

[0125] F1. When the resource release condition is met, the storage node to be queried sets the start resource release mark of the primary connection to start releasing resources.

[0126] In this embodiment, the resource release condition can be understood as a condition for whether the main connection releases related resources. The resource release condition is set in advance, and whether the resource release condition is met is detected. When it is detected that the resource release condition is met, the storage node to be queried sets the start resource release mark of the main connection to start releasing resources, and the main connection starts to release resources.

[0127] Since the temporary table created on the main connection can be accessed by the corresponding auxiliary connection, in general, the main connection cannot release related resources before the auxiliary connection finishes accessing its temporary table, otherwise it will cause a system exception. There are two main reasons why the main connection releases resources: one is that the distributed database entry Gate actively closes the main connection, and the other is that the Gate and the main connection are accidentally disconnected due to network reasons. When the auxiliary connection is queried in parallel, the first situation will not occur, but the second situation may occur. Therefore, the embodiment of the present application can set the resource release condition to: the distributed database entry closes the main connection or the connection between the distributed database entry and the main connection is disconnected.

[0128] The resource release mark of the main connection is marked as the start of resource release, and no auxiliary connection is added to access the temporary table of the main connection. The resource release mark can be marked in true or false mode. For example, marking the resource release mark as true indicates the start of resource release.

[0129] F2. The storage node to be queried determines whether the temporary table access count of the primary connection is equal to 0. If so, execute F3; otherwise, execute F4.

[0130] The storage node to be queried determines whether the temporary table access count of the primary connection is equal to 0. If so, all auxiliary connections end accessing their temporary tables and execute F3. If not, there are still auxiliary connections that end access to the temporary table and execute F4.

[0131] F3. The storage node to be queried traverses the temporary table list of the primary connection, determines all table structures in the temporary table list, traverses the list of available table resolution objects corresponding to each table structure, destroys all table resolution objects in the list of available table resolution objects, and destroys the table structure.

[0132] The storage node to be queried traverses the temporary table list of the main connection, queries the temporary table list to determine all table structures in the temporary table list, traverses the list of available table resolution objects corresponding to each table structure, and destroys all table resolution objects in the list of available table resolution objects. Since no connection is accessing this temporary table at this time, all the used table resolution object lists at this time are empty, and there is no need to access the used table resolution object list. Finally, the table structure is destroyed. The storage node to be queried releases all table structures in the temporary table list in the above way.

[0133] F4. The storage node to be queried waits for a preset period of time and then re-reads the temporary table access count of the primary connection and returns to execute step F2 until the temporary table access count of the primary connection is equal to 0.

[0134] In this embodiment, the preset duration can be set according to the business type, the number of data tables, the number of data rows in the data table, etc. For example, the preset duration can be 0.5s. When the storage node to be queried determines that the temporary table access count of the primary connection is not equal to 0, the storage node to be queried waits for the preset duration and then re-reads the temporary table access count of the primary connection. This operation is repeated until the temporary table access count of the primary connection is 0, thereby waiting for all auxiliary connections to finish accessing their temporary tables.

[0135] For example, Figure 4 A flowchart of implementing querying a storage node to be queried through an auxiliary connection is provided in one embodiment of the present invention.

[0136] S1. Parse the subquery request and determine the name of the table to be queried and the filter conditions.

[0137] S2. Traverse the global connection list and determine the primary connection according to the connection identifier of the primary connection.

[0138] S3. Determine whether the main connection starts to release resources. If so, execute S4; otherwise, execute S5.

[0139] S4. Return error.

[0140] S5. Traverse the temporary table list of the primary connection to determine whether there is a table structure corresponding to the table name to be queried in the temporary table list. If not, determine to access the ordinary table and execute S6 to obtain the table resolution object. If so, determine to access the temporary table created on the primary connection and execute S7 to obtain the table resolution object.

[0141] S6. Get the table parsing object and execute S10.

[0142] S7. Determine whether the list of available table parsing objects of the table structure is empty. If so, execute S8; otherwise, execute S9.

[0143] S8. Create a table resolution object based on the table structure, add the table resolution object to the list of used table resolution objects, and accumulate the temporary table access count of the primary connection, and execute S10.

[0144] S9. Select a table parsing object from the list of available table parsing objects, delete the table parsing object from the list of available table parsing objects, and add the table parsing object to the list of used table parsing objects.

[0145] S10. Find the latest version of all data rows based on the filter conditions, and traverse each row of data.

[0146] Steps S11 to S13 are executed for each row of data.

[0147] S11. Parse the row data through the table parsing object to obtain the transaction identifier and commit timestamp.

[0148] S12: If the commit timestamp is equal to the preset value, query the transaction status information in the global transaction status list according to the transaction identifier, and obtain the global snapshot timestamp from the transaction status information.

[0149] S13. If the global snapshot timestamp is the same as the distributed snapshot, add this data row to the data row result set.

[0150] S14. After all data rows are traversed, determine whether to access the temporary table created on the primary connection. If so, execute S15; otherwise, execute S17.

[0151] S15. traverse the global connection list, determine the primary connection through the connection identifier of the primary connection, traverse the temporary table list of the primary connection, and determine the table structure through the name of the table to be queried.

[0152] S16. Delete the table resolution object of the temporary table from the used table resolution object list of the table structure, add the table resolution object of the temporary table to the available table resolution object list of the table structure, and decrement the temporary table access count of the primary connection.

[0153] S17. Return the data row result set to the distributed database entry.

[0154] The embodiment of the present invention provides a distributed database query method, which solves the problem of high latency when querying data rows of multiple storage nodes in a distributed database. The data table in the storage node to be queried is queried in parallel through the main connection and at least one auxiliary connection between the storage node to be queried and the distributed database entrance, so as to realize fast query of data rows. Compared with the serial query in the prior art, the query latency is effectively reduced. While ensuring the consistency of global transactions, it supports the parallel execution of complex requests on multiple connections on the storage node, thereby reducing the latency of complex requests of the distributed database; the query on the auxiliary connection and the single-machine transaction opened by the corresponding main connection can ensure the read consistency of global transactions; the query on the auxiliary connection can read the latest version of the data row that has been modified in the single-machine transaction opened on the corresponding main connection, thereby ensuring the strong consistency of the transaction; the query on the auxiliary connection can read the data of the temporary table created on the corresponding main connection, but cannot read the data of the temporary table created on other connections; before the auxiliary connection ends accessing the temporary table of the main connection, the main connection will not release the relevant temporary table resources, and will not cause system abnormality. The method provided by the present application not only supports parallel query of ordinary tables, but also supports parallel query of temporary tables, realizes data parallel query, and effectively improves query efficiency.

[0155] Figure 5A schematic diagram of the structure of a distributed database provided by an embodiment of the present invention. Figure 5 As shown, the distributed database includes: a distributed database entry 31 and at least one storage node 32;

[0156] The distributed database entry 31 is used to determine at least one storage node to be queried and its corresponding sub-query request according to the query request after receiving the query request from the client, if the query request meets the target condition, and send the sub-query request to the corresponding storage node 321 to be queried;

[0157] Each storage node to be queried 321 is used to query the data table in the storage node to be queried in parallel through the main connection and at least one auxiliary connection between the storage node to be queried and the distributed database portal, determine the query result corresponding to the subquery request and feed it back to the distributed database portal 31, wherein the auxiliary connection queries the data table in the storage node to be queried based on the connection identifier of the main connection and the distributed snapshot of the single-machine transaction opened on the main connection;

[0158] The distributed database entry 31 is used to perform connection calculation on the query results corresponding to each of the sub-query requests, determine the target query request, and execute the target query request on the main connection corresponding to each of the storage nodes to be queried and the client to determine the query result of the query request.

[0159] The embodiment of the present invention provides a distributed database, which solves the problem of high latency when the distributed database queries data rows of multiple storage nodes. The data table in the storage node to be queried is queried in parallel through the main connection and at least one auxiliary connection between the storage node to be queried and the distributed database portal, thereby realizing fast query of data rows. Compared with the serial query in the prior art, the query latency is effectively reduced. While ensuring the consistency of global transactions, the distributed database portal is supported to query all data rows of each table in parallel from multiple connections of each storage node corresponding to the client based on the distributed snapshot, thereby reducing the query latency of the distributed database executing complex SQL and improving the query efficiency.

[0160] Optionally, if a single-machine transaction is not opened on the main connection between the storage node and the distributed database portal corresponding to the client, the distributed database portal is also used to obtain the latest timestamp, and to open a single-machine transaction on the main connection, and to set the distributed snapshot of the single-machine transaction to the latest timestamp.

[0161] Optionally, the storage node to be queried includes:

[0162] A data receiving module, configured to receive, through an auxiliary connection between the storage node to be queried and the distributed database entry, a subquery request, a connection identifier of a primary connection, and a distributed snapshot of a stand-alone transaction opened on the primary connection;

[0163] A table parsing object acquisition module is used to parse the sub-query request to determine the name of the table to be queried and the filtering condition; query the global connection list according to the connection identifier of the main connection to determine the main connection, and if the main connection has not started to release resources, obtain the table parsing object according to the name of the table to be queried;

[0164] A data row query module is used to read the data rows of the data table in the storage node to be queried based on the table parsing object, the filtering condition and the distributed snapshot, and determine the query result corresponding to the sub-query request.

[0165] Optionally, the table parsing object acquisition module includes:

[0166] A temporary table list query unit, used for querying the temporary table list of the primary connection according to the name of the table to be queried;

[0167] The table parsing object acquiring unit is used to acquire the table parsing object of the temporary table if there is a table structure matching the name of the table to be queried in the temporary table list; otherwise, acquire the table parsing object of the common table.

[0168] Optionally, the table resolution object acquisition unit is specifically used to: if the list of available table resolution objects of the table structure is empty, create a table resolution object based on the table structure, and use the created table resolution object as the table resolution object of the temporary table; if the list of available table resolution objects of the table structure is not empty, select a table resolution object from the list of available table resolution objects as the table resolution object of the temporary table.

[0169] Optionally, the storage node to be queried is further used to: after obtaining the table resolution object of the temporary table, add the table resolution object to the list of used table resolution objects, and accumulate the temporary table access count of the primary connection.

[0170] Optionally, the storage node to be queried is further configured to: after selecting a table resolution object from the list of available table resolution objects as the table resolution object of the temporary table, the storage node to be queried deletes the table resolution object from the list of available table resolution objects.

[0171] Optionally, the data row query module includes:

[0172] A latest version query unit, used to query the latest version of each row of data in the data table in the storage node to be queried based on the filtering condition;

[0173] a visibility judgment unit, configured to judge the visibility of the latest version of each data row based on the table parsing object and the distributed snapshot, and if the data row is visible, add the data row to the data row result set; if the data row is not visible, determine a new latest version, and return to perform visibility judgment on the latest version of each data row based on the table parsing object and the distributed snapshot until the latest version of the data row is visible;

[0174] The query result determination unit is used to, after determining the latest visible versions of all data rows, use the data row result set as the query result corresponding to the sub-query request.

[0175] Optionally, a visibility judgment unit is specifically used to: parse the transaction identifier and commit timestamp of the data row based on the table parsing object; if the commit timestamp is a preset value, query the transaction status information in the global transaction status list according to the transaction identifier; obtain the global snapshot timestamp of the transaction from the transaction status information, and if the global snapshot timestamp is the same as the distributed snapshot, determine that the latest version of the data row is visible.

[0176] Optionally, the transaction identifier of the data row is determined based on the transaction identifier of the current transaction that updates the data row when the data row is updated; the commit timestamp of the data row is set to a preset value when the data row is updated, and is set to the commit timestamp of the current transaction when the current transaction that updates the data row is committed.

[0177] Optionally, the storage node to be queried is also used for: if the table resolution object is a table resolution object of a temporary table, after determining the query result corresponding to the subquery request, determining the main connection according to the connection identifier of the main connection, querying the temporary table list of the main connection according to the name of the table to be queried, and determining the table structure corresponding to the name of the table to be queried; deleting the table resolution object from the used table resolution object list of the table structure, adding the table resolution object to the available table resolution object list of the table structure; and decrementing the temporary table access count of the main connection.

[0178] Optionally, the storage node to be queried is also used to: when the resource release condition is met, set the start resource release mark of the main connection to start resource release; determine whether the temporary table access count of the main connection is equal to 0, if so, traverse the temporary table list of the main connection, determine all table structures in the temporary table list, traverse the available table resolution object list corresponding to each table structure, destroy all table resolution objects in the available table resolution object list, and destroy the table structure; if not, wait for a preset time and then re-read the temporary table access count of the main connection and return to execute the step of determining whether the temporary table access count of the main connection is equal to 0, until the temporary table access count of the main connection is equal to 0.

[0179] The distributed database provided in the embodiment of the present invention can execute the distributed database query method provided in any embodiment of the present invention, and has the corresponding functional modules and beneficial effects of the execution method.

[0180] Figure 6 A schematic diagram of the structure of an electronic device 40 provided for one embodiment of the present invention. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital assistants, cellular phones, smart phones, wearable devices (such as helmets, glasses, watches, etc.) and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely examples and are not intended to limit the implementation of the present invention described and / or required herein.

[0181] like Figure 6 As shown, the electronic device 40 includes at least one processor 41, and a memory connected to the at least one processor 41, such as a read-only memory (ROM) 42, a random access memory (RAM) 43, etc., wherein the memory stores a computer program that can be executed by at least one processor, and the processor 41 can perform various appropriate actions and processes according to the computer program stored in the read-only memory (ROM) 42 or the computer program loaded from the storage unit 48 to the random access memory (RAM) 43. In the RAM 43, various programs and data required for the operation of the electronic device 40 can also be stored. The processor 41, the ROM 42, and the RAM 43 are connected to each other through a bus 44. An input / output (I / O) interface 45 is also connected to the bus 44.

[0182] A number of components in the electronic device 40 are connected to the I / O interface 45, including: an input unit 46, such as a keyboard, a mouse, etc.; an output unit 47, such as various types of displays, speakers, etc.; a storage unit 48, such as a disk, an optical disk, etc.; and a communication unit 49, such as a network card, a modem, a wireless communication transceiver, etc. The communication unit 49 allows the electronic device 40 to exchange information / data with other devices through a computer network such as the Internet and / or various telecommunication networks.

[0183] The processor 41 may be a variety of general and / or special processing components with processing and computing capabilities. Some examples of the processor 41 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, digital signal processors (DSPs), and any appropriate processors, controllers, microcontrollers, etc. The processor 41 executes the various methods and processes described above, such as a distributed database query method.

[0184] In some embodiments, the distributed database query method may be implemented as a computer program, which is tangibly contained in a computer-readable storage medium, such as a storage unit 48. In some embodiments, part or all of the computer program may be loaded and / or installed on the electronic device 40 via the ROM 42 and / or the communication unit 49. When the computer program is loaded into the RAM 43 and executed by the processor 41, one or more steps of the distributed database query method described above may be performed. Alternatively, in other embodiments, the processor 41 may be configured to perform the distributed database query method in any other appropriate manner (e.g., by means of firmware).

[0185] Various implementations of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), application specific standard products (ASSPs), systems on chips (SOCs), load programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various implementations can include: being implemented in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which can be a special purpose or general purpose programmable processor that can receive data and instructions from a storage system, at least one input device, and at least one output device, and transmit data and instructions to the storage system, the at least one input device, and the at least one output device.

[0186] Computer programs for implementing the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, so that when the computer program is executed by the processor, the functions / operations specified in the flow chart and / or block diagram are implemented. The computer program may be executed entirely on the machine, partially on the machine, partially on the machine and partially on a remote machine as a stand-alone software package, or entirely on a remote machine or server.

[0187] An embodiment of the present invention provides a computer program product, which includes a computer program. When the computer program is executed by a processor, the distributed database query method described in any embodiment of the present invention is implemented.

[0188] In the context of the present invention, a computer-readable storage medium may be a tangible medium that may contain or store a computer program for use by or in combination with an instruction execution system, device or equipment. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices or equipment, or any suitable combination of the foregoing. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. A more specific example of a machine-readable storage medium may include an electrical connection based on one or more lines, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

[0189] To provide interaction with a user, the systems and techniques described herein may be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and a pointing device (e.g., a mouse or trackball) through which the user can provide input to the electronic device. Other types of devices may also be used to provide interaction with the user; for example, the feedback provided to the user may be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user may be received in any form (including acoustic input, voice input, or tactile input).

[0190] The systems and techniques described herein may be implemented in a computing system that includes backend components (e.g., as a data server), or a computing system that includes middleware components (e.g., an application server), or a computing system that includes frontend components (e.g., a user computer with a graphical user interface or a web browser through which a user can interact with implementations of the systems and techniques described herein), or a computing system that includes any combination of such backend components, middleware components, or frontend components. The components of the system may be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include: a local area network (LAN), a wide area network (WAN), a blockchain network, and the Internet.

[0191] A computing system may include a client and a server. The client and the server are generally remote from each other and usually interact through a communication network. The client and server relationship is generated by computer programs running on the corresponding computers and having a client-server relationship with each other. The server may be a cloud server, also known as a cloud computing server or cloud host, which is a host product in the cloud computing service system to solve the defects of difficult management and weak business scalability in traditional physical hosts and VPS services.

[0192] It should be understood that the various forms of processes shown above can be used to reorder, add or delete steps. For example, the steps described in the present invention can be executed in parallel, sequentially or in different orders, as long as the desired results of the technical solution of the present invention can be achieved, and this document does not limit this.

[0193] The above specific implementations do not constitute a limitation on the protection scope of the present invention. It should be understood by those skilled in the art that various modifications, combinations, sub-combinations and substitutions can be made according to design requirements and other factors. Any modification, equivalent substitution and improvement made within the spirit and principle of the present invention should be included in the protection scope of the present invention.

Claims

1. A distributed database query method, characterized in that: Applied to a distributed database, the distributed database includes a distributed database entry and at least one storage node, including: After receiving the query request from the client, the distributed database portal determines at least one storage node to be queried and its corresponding sub-query request according to the query request if the query request meets the target condition, and sends the sub-query request to the corresponding storage node to be queried; Each storage node to be queried queries the data table in the storage node to be queried in parallel through the main connection and at least one auxiliary connection between the storage node to be queried and the distributed database portal, determines the query result corresponding to the subquery request and feeds it back to the distributed database portal, wherein the auxiliary connection queries the data table in the storage node to be queried based on the connection identifier of the main connection and the distributed snapshot of the single-machine transaction opened on the main connection; The distributed database entry performs connection calculation on the query results corresponding to each of the sub-query requests to determine a target query request, and executes the target query request on the main connection corresponding to each of the storage nodes to be queried and the client to determine a query result of the query request; The storage node to be queried queries a data table in the storage node to be queried through an auxiliary connection between the storage node to be queried and the distributed database entry to determine a query result corresponding to the sub-query request, including: The storage node to be queried receives the subquery request, the connection identifier of the main connection, and the distributed snapshot of the stand-alone transaction opened on the main connection through the auxiliary connection between the storage node to be queried and the distributed database entry; The storage node to be queried parses the sub-query request to determine the name of the table to be queried and the filtering condition; The storage node to be queried queries the global connection list according to the connection identifier of the primary connection to determine the primary connection, and if the primary connection has not started to release resources, obtains a table resolution object according to the name of the table to be queried; The storage node to be queried reads data rows of the data table in the storage node to be queried based on the table parsing object, the filtering condition and the distributed snapshot, and determines a query result corresponding to the sub-query request.

2. The method according to claim 1, characterized in that Also includes: If corresponding to the client, a single-machine transaction is not opened on the main connection between the storage node and the distributed database portal, the distributed database portal obtains the latest timestamp, opens a single-machine transaction on the main connection, and sets the distributed snapshot of the single-machine transaction to the latest timestamp.

3. The method according to claim 1, characterized in that The obtaining of a table resolution object according to the name of the table to be queried includes: Query the temporary table list of the primary connection according to the name of the table to be queried; If there is a table structure matching the name of the table to be queried in the temporary table list, the table parsing object of the temporary table is obtained; otherwise, the table parsing object of the common table is obtained.

4. The method according to claim 3, characterized in that The table parsing object of obtaining the temporary table includes: If the list of available table parsing objects of the table structure is empty, create a table parsing object based on the table structure, and use the created table parsing object as the table parsing object of the temporary table; If the available table parsing object list of the table structure is not empty, a table parsing object is selected from the available table parsing object list as the table parsing object of the temporary table.

5. The method according to claim 4, characterized in that After obtaining the table parsing object of the temporary table, it also includes: The storage node to be queried adds the table resolution object to a list of used table resolution objects, and accumulates the temporary table access count of the primary connection.

6. The method according to claim 4, characterized in that After selecting a table parsing object from the available table parsing object list as the table parsing object of the temporary table, the method further includes: The storage node to be queried deletes the table resolution object from a list of available table resolution objects.

7. The method according to claim 1, characterized in that The storage node to be queried reads data rows of the data table in the storage node to be queried based on the table parsing object, the filtering condition and the distributed snapshot, and determines a query result corresponding to the subquery request, including: Querying the latest version of each row of data in the data table in the storage node to be queried based on the filtering condition; Perform visibility judgment on the latest version of each data row based on the table parsing object and the distributed snapshot, and if the data row is visible, add the data row to the data row result set; if the data row is not visible, determine a new latest version, and return to perform visibility judgment on the latest version of each data row based on the table parsing object and the distributed snapshot until the latest version of the data row is visible; After determining the latest visible versions of all data rows, the data row result set is used as the query result corresponding to the sub-query request.

8. The method according to claim 7, characterized in that The visibility of the latest version of the data row is judged based on the table parsing object and the distributed snapshot, including: Parsing the transaction identifier and the commit timestamp of the data row based on the table parsing object; If the commit timestamp is a preset value, querying the transaction status information in the global transaction status list according to the transaction identifier; A global snapshot timestamp of the transaction is obtained from the transaction status information, and if the global snapshot timestamp is the same as the distributed snapshot, it is determined that the latest version of the data row is visible.

9. The method according to claim 8, characterized in that The transaction identifier of the data row is determined according to the transaction identifier of the current transaction that updates the data row when the data row is updated; the commit timestamp of the data row is set to a preset value when the data row is updated, and is set to the commit timestamp of the current transaction when the current transaction that updates the data row is committed.

10. The method according to claim 1, characterized in that If the table resolution object is a table resolution object of a temporary table, after determining the query result corresponding to the subquery request, the method further includes: The storage node to be queried determines the primary connection according to the connection identifier of the primary connection, queries the temporary table list of the primary connection according to the name of the table to be queried, and determines the table structure corresponding to the name of the table to be queried; The storage node to be queried deletes the table parsing object in the used table parsing object list of the table structure, and adds the table parsing object to the available table parsing object list of the table structure; The storage node to be queried decrements the temporary table access count of the primary connection.

11. The method according to any one of claims 1 to 10, characterized in that: Also includes: When the resource release condition is met, the storage node to be queried sets the start resource release mark of the primary connection to start releasing resources; The storage node to be queried determines whether the temporary table access count of the primary connection is equal to 0, and if so, traverses the temporary table list of the primary connection, determines all table structures in the temporary table list, traverses the available table resolution object list corresponding to each table structure, destroys all table resolution objects in the available table resolution object list, and destroys the table structure; If not, the storage node to be queried waits for a preset period of time and then re-reads the temporary table access count of the main connection and returns to execute the step of determining whether the temporary table access count of the main connection is equal to 0, until the temporary table access count of the main connection is equal to 0.

12. A distributed database, characterized in that: The distributed database includes a distributed database entry and at least one storage node; A distributed database entry, for determining at least one storage node to be queried and its corresponding sub-query request according to the query request after receiving a query request from a client, if the query request meets a target condition, and sending the sub-query request to the corresponding storage node to be queried; Each storage node to be queried is used to query the data table in the storage node to be queried in parallel through the main connection and at least one auxiliary connection between the storage node to be queried and the distributed database entry, determine the query result corresponding to the subquery request and feed it back to the distributed database entry, wherein the auxiliary connection queries the data table in the storage node to be queried based on the connection identifier of the main connection and the distributed snapshot of the single-machine transaction opened on the main connection; The distributed database entry is used to perform connection calculation on the query results corresponding to each of the sub-query requests, determine the target query request, and execute the target query request on the main connection corresponding to each of the storage nodes to be queried and the client to determine the query result of the query request; The storage node to be queried includes: A data receiving module, configured to receive, through an auxiliary connection between the storage node to be queried and the distributed database entry, a subquery request, a connection identifier of a primary connection, and a distributed snapshot of a stand-alone transaction opened on the primary connection; A table parsing object acquisition module is used to parse the sub-query request to determine the name of the table to be queried and the filtering condition; query the global connection list according to the connection identifier of the main connection to determine the main connection, and if the main connection has not started to release resources, obtain the table parsing object according to the name of the table to be queried; A data row query module is used to read the data rows of the data table in the storage node to be queried based on the table parsing object, the filtering condition and the distributed snapshot, and determine the query result corresponding to the sub-query request.

13. An electronic device, characterized in that: The electronic device comprises: at least one processor, and a memory communicatively coupled to the at least one processor; The memory stores a computer program executable by the at least one processor, and the computer program is executed by the at least one processor so that the at least one processor can execute the distributed database query method described in any one of claims 1 to 11.

14. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer instructions, and the computer instructions are used to enable a processor to implement the distributed database query method according to any one of claims 1 to 11 when executed.

15. A computer program product, characterized in that The computer program product comprises a computer program, which, when executed by a processor, implements the distributed database query method according to any one of claims 1 to 11.

Images