Multi-table join query method and system, and device

Abstract

The embodiments of the present disclosure relate to the technical field of databases. Provided are a multi-table join query method and system, and a device. In the embodiments of the present disclosure, a computing node splits a multi-table join query into several multi-shard join queries, and provides the several multi-shard join queries to storage nodes for processing, the storage nodes feed shard query results back to the computing node, and the computing node then obtains a final query result on the basis of the shard query results. In this way, the processing of a multi-table join query is partially or fully dispersed into storage nodes, without the need of sending all table shards to a computing node for join querying, thereby significantly reducing the occupation of transmission resources and processing resources of the computing node.

Description

Method, system and device for multi-table join query

[0001] This disclosure claims priority to Chinese patent application No. 202310943415.1 filed on July 28, 2023, entitled “A method, device and computing device cluster for multi-table connection query”, and Chinese patent application No. 202311433696.2 filed on October 31, 2023, entitled “Method, system and device for multi-table connection query”, the entire contents of which are incorporated by reference into this disclosure. Technical Field

[0002] The present disclosure relates to the field of database technology, and in particular to a method, system and device for multi-table join query. Background Art

[0003] With the development of the internet, data volumes have exploded, while traditional databases have limited storage space. This has led to the emergence of cloud-native databases. In cloud-native databases, data tables are divided into multiple shards and stored across different storage nodes.

[0004] In a cloud-native database, multi-table join queries generally require aggregating all shards of the multiple data tables involved to a computing node. The computing node then combines the shards to obtain multiple data tables, and then performs a join query on these multiple data tables.

[0005] The above processing method will occupy a large amount of transmission resources and processing resources of the computing node.

[0006] Summary of the Invention

[0007] The present disclosure provides a method, system and device for multi-table join query, which can effectively reduce the occupation of transmission resources and processing resources of computing nodes.

[0008] In a first aspect, a method for performing a multi-table join query is provided. The method is applied to a cloud-native database system, the cloud-native database system including a computing node and multiple storage nodes. The method comprises: the computing node receiving a multi-table join query instruction, and then determining at least one first shard connection information to be processed by the storage node based on the table shards included in each of the multiple data tables corresponding to the multi-table join query instruction, wherein each first shard connection information indicates multiple table shards to be used for the join query. The computing node then sends shard connection query information corresponding to each first shard connection information to a target storage node corresponding to each first shard connection information, the shard connection query information including the first shard connection information and a query condition in the multi-table join query instruction, the target storage node storing the multiple table shards indicated by the corresponding first shard connection information. Each target storage node performs a join query on the multiple table shards indicated by the received first shard connection information based on the query condition, obtaining a first shard query result. The computing node receives the first shard query result sent by each target storage node, and then, based on the at least one received first shard query result, determines a query result for the multi-table join query instruction, and provides feedback to the multi-table join query instruction based on the query result.

[0009] A table shard can be formally considered a portion of a table's rows. Compute nodes split a multi-table join query into several multi-shard join queries, handing off some or all of these queries to storage nodes for processing. A multi-shard join query involves joining multiple table shards, and the processing logic for multi-shard join queries is identical. Storage nodes feed the shard query results back to compute nodes, which then generate the final query result based on the shard query results.

[0010] In this way, part or all of the processing of multi-table join queries is distributed to the storage nodes, and there is no need to send all table shards to the computing nodes for join queries, which can greatly reduce the occupation of the transmission and processing resources of the computing nodes.

[0011] In one possible implementation, the computing node determines at least one shard connection information based on the table shards respectively included in the multiple data tables corresponding to the multi-table join query instruction, wherein each shard connection information indicates multiple table shards used for the join query, and then the computing node determines at least one first shard connection information from the at least one shard connection information, wherein the multiple table shards indicated by the first shard connection information are stored in the same storage node.

[0012] The at least one shard connection information can also be referred to as theoretical shard connection information. The theoretical shard connection information is generated by combining all table shards included in multiple data tables based on specified combination logic to obtain all possible shard combinations (each shard in a shard combination belongs to a different data table). Each shard combination corresponds to one theoretical shard connection information, thus obtaining multiple theoretical shard connection information. The multiple table shards in each theoretical shard connection information belong to different data tables.

[0013] In this way, after determining the first shard connection information, the shard connection query information can be sent to the target storage node corresponding to the first shard connection information, and the target storage node will complete the multi-shard connection query operation. The multi-shard connection query can be handed over to the storage node for processing as much as possible, thereby reducing the occupancy of the computing node's transmission resources and processing resources.

[0014] In one possible implementation, a computing node determines at least one second shard connection information, wherein multiple table shards indicated by the second shard connection information are stored on different storage nodes. The computing node then obtains the multiple table shards indicated by the at least one second shard connection information from the multiple storage nodes corresponding to the at least one second shard connection information. The computing node then performs a join query on the multiple table shards indicated by the at least one second shard connection information based on a query condition in a multi-table join query instruction to obtain a second shard query result. Finally, the computing node combines the received at least one first shard query result and the second shard query result into a query result for the multi-table join query instruction.

[0015] For the second shard connection information, no storage node stores data of all table shards indicated by the second shard connection information. The set of the first shard connection information and the second shard connection information is the theoretical shard connection information.

[0016] In this way, part of the query processing of multi-table join queries is performed by the computing nodes, and part of the query processing is dispersed to the storage nodes. There is no need to send all table shards to the computing nodes for join queries, which can greatly reduce the occupation of the transmission resources and processing resources of the computing nodes.

[0017] In one possible implementation, the computing node combines the received multiple first shard query results into a query result of a multi-table join query instruction.

[0018] Each theoretical shard connection information corresponds to a storage node (the storage node stores the data of all table shards indicated by the theoretical shard connection information). Then, the computing node can combine the shard query results received from each storage node to obtain the final query result.

[0019] In this way, all query processing of multi-table join queries is dispersed to the storage nodes, and there is no need to send table shards to the computing nodes for join queries, which can greatly reduce the occupation of transmission resources and processing resources of the computing nodes.

[0020] In one possible implementation, the computing node determines at least one storage node corresponding to each first shard connection information, and the storage node stores multiple table shards indicated by the corresponding first shard connection information. Then, the computing node determines a target storage node from at least one storage node based on resource occupancy information of the at least one storage node.

[0021] The compute node can obtain resource usage information for each storage node and, based on the resource usage information, select the storage node with the least resource usage as the target storage node. The resource usage information can include at least one of the following: processor usage, the total amount of data corresponding to the currently processed read and write operations, and the number of currently processed read and write operations.

[0022] In this way, load balancing can be achieved to avoid some storage nodes having a heavy workload while some storage nodes are relatively idle.

[0023] In a possible implementation, the computing node determines the first shard connection information after determining that the data volume of the multiple data tables corresponding to the multi-table connection query instruction exceeds a preset threshold.

[0024] Based on the data type of the target column (the target column is the column involved in the multi-table connection query instruction in the corresponding data table), the data volume of each field corresponding to the target column can be determined. The product of this data volume and the number of rows is the data volume corresponding to the target column. The total data volume corresponding to all target columns in multiple data tables (that is, the data volume of multiple data tables corresponding to the multi-table connection query instruction) can be further determined. If the total data volume is greater than the data volume threshold, the computing node determines the first shard connection information and further performs the above-mentioned subsequent processing. If the data volume is less than the data volume threshold, the computing node obtains each table shard from the storage node, merges each table shard to obtain the corresponding data table, and then performs a multi-table connection query on the data table, and provides feedback to the multi-table connection query instruction based on the query results.

[0025] In this way, when the amount of data to be processed is large, the query processing of multi-table join queries is distributed to storage nodes, which can effectively reduce the use of transmission and processing resources of computing nodes. When the amount of data to be processed is small, the entire query processing of multi-table join queries is performed by computing nodes. Because computing nodes have stronger processing capabilities, this can improve processing efficiency.

[0026] In a second aspect, a cloud-native database system is provided, which includes a computing node and multiple storage nodes, and the computing node and multiple storage nodes are used to execute the method provided by the above-mentioned first aspect and its possible implementation methods.

[0027] In a third aspect, a method for multi-table join query is provided. The method is applied to a cloud-native database system, the cloud-native database system including a computing node and multiple storage nodes. The method is executed by the computing node and includes: receiving a multi-table join query instruction, and then determining at least one first shard connection information that needs to be processed by the storage node based on the table shards respectively included in the multiple data tables corresponding to the multi-table join query instruction, wherein each first shard connection information indicates multiple table shards used for the join query. Then, shard connection query information corresponding to the first shard connection information is sent to the target storage node corresponding to each first shard connection information, the shard connection query information including the first shard connection information and the query conditions in the multi-table join query instruction, the target storage node storing the multiple table shards indicated by the corresponding first shard connection information. Then, the first shard query result sent by each target storage node is received, and based on the at least one received first shard query result, a query result of the multi-table join query instruction is determined, and feedback is provided to the multi-table join query instruction based on the query result.

[0028] In this way, the computing node distributes part or all of the processing of multi-table join queries to the storage node, eliminating the need to send all table shards to the computing node for join queries, which can effectively reduce the use of transmission and processing resources of the computing node.

[0029] In one possible implementation, based on the table shards respectively included in the multiple data tables corresponding to the multi-table join query instruction, at least one shard connection information is determined, wherein each shard connection information indicates multiple table shards used for the join query, and then at least one first shard connection information is determined from the at least one shard connection information, wherein the multiple table shards indicated by the first shard connection information are stored in the same storage node.

[0030] In this way, after determining the first shard connection information, the shard connection query information can be sent to the target storage node corresponding to the first shard connection information, and the target storage node will complete the multi-shard connection query operation. The multi-shard connection query can be handed over to the storage node for processing as much as possible, thereby reducing the occupancy of the computing node's transmission resources and processing resources.

[0031] In one possible implementation, at least one piece of second shard connection information is determined, wherein multiple table shards indicated by the second shard connection information are stored in different storage nodes. Then, the multiple table shards indicated by the at least one piece of second shard connection information are obtained from the multiple storage nodes corresponding to the at least one piece of second shard connection information. Then, based on the query conditions in the multi-table join query instruction, a join query is performed on the multiple table shards indicated by the at least one piece of second shard connection information to obtain a second shard query result. Finally, the received at least one first shard query result and the second shard query result are combined to form the query result of the multi-table join query instruction.

[0032] In this way, part of the query processing of multi-table join queries is performed by the computing nodes, and part of the query processing is dispersed to the storage nodes. There is no need to send all table shards to the computing nodes for join queries, which can greatly reduce the occupation of the transmission resources and processing resources of the computing nodes.

[0033] In a possible implementation, the received multiple first shard query results are combined into a query result of a multi-table join query instruction.

[0034] In this way, all query processing of multi-table join queries is dispersed to the storage nodes, and there is no need to send table shards to the computing nodes for join queries, which can greatly reduce the occupation of transmission resources and processing resources of the computing nodes.

[0035] In one possible implementation, at least one storage node corresponding to each first shard connection information is determined, and the storage node stores multiple table shards indicated by the corresponding first shard connection information. Then, based on the resource occupancy information of the at least one storage node, a target storage node is determined from the at least one storage node.

[0036] In this way, load balancing can be achieved to avoid some storage nodes having a heavy workload while some storage nodes are relatively idle.

[0037] In a possible implementation, after determining that the data volume of multiple data tables corresponding to the multi-table connection query instruction exceeds a preset threshold, the first shard connection information is determined.

[0038] In this way, when the amount of data to be processed is large, the query processing of multi-table join queries is distributed to storage nodes, which can effectively reduce the use of transmission and processing resources of computing nodes. When the amount of data to be processed is small, the entire query processing of multi-table join queries is performed by computing nodes. Because computing nodes have stronger processing capabilities, this can improve processing efficiency.

[0039] In a fourth aspect, a method for multi-table join query is provided, which is applied to a cloud-native database system, which includes a computing node and multiple storage nodes. The method is executed by the storage node, and the method includes: receiving shard connection query information sent by the computing node, the shard connection query information includes first shard connection information and query conditions, and the multiple table shards indicated by the first shard connection information are stored in the storage node, and then based on the query conditions, a join query is performed in the multiple table shards indicated by the first shard connection information to obtain a first shard query result, and finally the first shard query result is sent to the computing node corresponding to the storage node.

[0040] In this way, part or all of the processing of multi-table join queries is distributed to the storage nodes, and there is no need to send all table shards to the computing nodes for join queries, which can greatly reduce the occupation of the transmission and processing resources of the computing nodes.

[0041] In a fifth aspect, a device for multi-table join query is provided, which includes at least one module, and the at least one module is used to implement the method provided by the third aspect and its possible implementation methods.

[0042] In a sixth aspect, a device for multi-table join query is provided, which includes at least one module, and the at least one module is used to implement the method provided by the above-mentioned fourth aspect and its possible implementation methods.

[0043] In the seventh aspect, a computing device cluster is provided, comprising at least one computing device, each computing device comprising a processor and a memory; the processor of at least one computing device is used to execute instructions stored in the memory of at least one computing device, so that the computing device cluster executes the method provided by the above-mentioned first aspect and its possible implementation methods.

[0044] In an eighth aspect, a computer device is provided, comprising a memory and a processor, wherein the memory is configured to store computer instructions. The processor executes the computer instructions stored in the memory to cause the computer device to perform the method provided in the third aspect and possible implementations thereof.

[0045] In a ninth aspect, a computer device is provided, comprising a memory and a processor, wherein the memory is configured to store computer instructions. The processor executes the computer instructions stored in the memory to cause the computer device to perform the method provided in the fourth aspect and possible implementations thereof.

[0046] In a tenth aspect, a computer-readable storage medium is provided, which includes computer program instructions. When the computer program instructions are executed by a computing device cluster, the computing device cluster executes the method provided by the above-mentioned first aspect and its possible implementation methods.

[0047] In the eleventh aspect, a computer-readable storage medium is provided, which stores computer program code. When the computer program code is executed by a computer device, the computer device executes the method provided by the third aspect and its possible implementation methods.

[0048] In the twelfth aspect, a computer-readable storage medium is provided, which stores computer program code. When the computer program code is executed by a computer device, the computer device executes the method provided by the fourth aspect and its possible implementation methods.

[0049] In a thirteenth aspect, a computer program product comprising instructions is provided. When the instructions are executed by a computing device cluster, the computing device cluster executes the method provided by the first aspect and its possible implementation manner.

[0050] In a fourteenth aspect, a computer program product is provided, which includes a computer program code. When the computer program code is executed by a computer device, the computer device executes the method provided by the third aspect and its possible implementation methods.

[0051] In the fifteenth aspect, a computer program product is provided, which includes computer program code. When the computer program code is executed by a computer device, the computer device executes the method provided in the fourth aspect and its possible implementation methods. BRIEF DESCRIPTION OF THE DRAWINGS

[0052] FIG1 is a schematic diagram of a data table sharding provided by an embodiment of the present disclosure;

[0053] FIG2 is a schematic diagram of the structure of a cloud native database system provided by an embodiment of the present disclosure;

[0054] FIG3 is a schematic diagram of the structure of a cloud native database system provided by an embodiment of the present disclosure;

[0055] FIG4 is a flow chart of a method for multi-table join query provided by an embodiment of the present disclosure;

[0056] FIG5 is a flow chart of a method for determining slice connection information to be sent provided by an embodiment of the present disclosure;

[0057] FIG6 is a schematic structural diagram of a device for multi-table join query provided by an embodiment of the present disclosure;

[0058] FIG7 is a schematic structural diagram of a device for multi-table join query provided by an embodiment of the present disclosure;

[0059] FIG8 is a schematic diagram of a computing device provided by an embodiment of the present disclosure;

[0060] FIG9 is a schematic diagram of a computing device cluster provided by an embodiment of the present disclosure;

[0061] FIG10 is a schematic diagram of a computing device cluster provided by an embodiment of the present disclosure. DETAILED DESCRIPTION

[0062] In order to make the objectives, technical solutions and advantages of the present disclosure more clear, the embodiments of the present disclosure will be further described in detail below with reference to the accompanying drawings.

[0063] The concepts involved in this disclosure are explained below:

[0064] database

[0065] A database is a collection of data with a specified data structure. The data in a database is generally stored in a two-dimensional table, also known as a data table.

[0066] Multi-table join query

[0067] A multi-table join query, or join query, is an operation that integrates and returns the contents of multiple tables in a database. The corresponding command, called a multi-table join query instruction, is a Structured Query Language (SQL) statement. SQL is a database operation and programming language used to access data, query, update, and manage databases.

[0068] The form of multi-table join query instructions can be as follows:

[0069] SELECT target_column FROM table_A JOIN table_B ON A_column=B_column

[0070] In this instruction, "SELECT" is the instruction name, indicating that the instruction is used for querying. "target_column" is the name of the target column (or target attribute). The target column can be considered as the column involved in the instruction. There can be multiple target columns, and the instruction can query multiple target columns in the table. The value of this field can also be "*", indicating that the data in all columns of the data table is queried. "FROM" and "JOIN" are fixed fields in the instruction, used to extract the multiple data tables targeted by the query. "table_A" and "table_B" are the names of these multiple data tables. "ON" is a fixed field in the instruction, used to extract the connection conditions of multiple data tables. "A_column = B_column" is the connection condition, which means that when the A_column attribute of the data in a row of table_A is equal to the B_column attribute of the data in a row of table_B, the two rows of data will be "joined", that is, the two rows of data will be combined into a row of data as the row of data in the query result. A_column and B_column can be called reference attributes.

[0071] Table slice

[0072] A table shard can be formally considered a portion of a table's rows. For example, a table with 1,000 rows is divided into 20 shards, each containing 50 rows. As shown in Figure 1, the table is divided into two shards: sliceX (the data enclosed by the upper dashed box) and sliceY (the data enclosed by the lower dashed box), each containing 5 rows.

[0073] The present disclosure provides a method for multi-table join query. This method can be applied to a cloud-native database system. The cloud-native database system may include a computing server (or computing node) and a storage server (or storage node). The structure of the cloud-native database system is shown in Figure 2. The following describes each component of the cloud-native database system:

[0074] Compute node 210 can be an independent computer device, a virtual machine, or a computer cluster. Compute nodes are user-oriented and can interpret user commands, execute them, and ultimately provide feedback to the user. The execution of commands can involve writing data to or reading data from storage nodes. In a cloud-native database system, each user can be assigned a compute node.

[0075] The storage node 220 can be a computer device with powerful storage capacity and some basic processing capabilities. The storage node is used to store data and read and write data under the control of the computing node.

[0076] In a cloud-native database system, when storing a data table, the data table is divided into multiple table shards, and then the table shards are dispersed and stored in multiple storage nodes. In addition, a certain redundancy mechanism can be set up to copy each table shard into several copies and store them in different storage nodes, as shown in Figure 3. The execution method of multi-table connection query instructions under this database architecture is very different from the execution method under the traditional database architecture. The embodiment of the present disclosure provides a method for multi-table connection query, which can make good use of the processing resources of storage nodes in a cloud-native database system and reduce the resource occupation of computing nodes. As shown in Figure 4, the processing flow of this method includes the following steps:

[0077] Step 401: A computing node receives a multi-table join query instruction.

[0078] When a user wants to perform a multi-table join query, they can enter a multi-table join query command through their device, and the device will send the command to the cloud-native database system. The command content has been described above and can be:

[0079] SELECT target_column FROM table_A JOIN table_B ON A_column=B_column

[0080] In a cloud-native database system, the computing node is responsible for receiving and parsing multi-table join query instructions sent by user devices. The syntax parser in the computing node parses the instruction and obtains the various fields in the instruction. Based on the fixed fields such as "SELECT" and "JOIN" in the instruction, it can be determined that the instruction is a query instruction, and it is a multi-table join query instruction. Then, the query conditions in the multi-table join query instruction can be determined. The query conditions may include the names of the multiple data tables to be joined (i.e., table_A and table_B), the names of the reference attributes in each data table (i.e., attribute A_column in data table table_A and attribute B_column in data table table_B), and the name of the target attribute (i.e., target_column).

[0081] In step 402 , the computing node determines at least one shard connection information to be sent to the storage node for processing based on the table shards respectively included in the multiple data tables corresponding to the multi-table join query instruction.

[0082] In the computing node, you can record the relevant information of each data table in the database system, including all the table shards included in the data table, the storage nodes where the table shards are located, etc. A corresponding relationship table between data tables, table shards, and storage nodes can be established in the computing node, as shown in Table 1:

[0083] Table 1

[0084] After parsing the multi-table join query instruction, the compute node can obtain the name of the data table carried in it. Then, by searching the corresponding table shards in the above-mentioned correspondence table, all the table shards of the data table involved in the multi-table join query instruction can be determined (the storage nodes recorded in the correspondence table will be used in the subsequent processing). Furthermore, based on these table shards, the compute node can determine the shard connection information to be sent. The process is as follows:

[0085] Split a multi-table connection query into several multi-shard connection queries, and hand over some or all of the multi-shard connection queries to the storage node for processing. A multi-shard connection query is a connection query for multiple table shards. Because a table shard is actually a relatively small data table, the processing logic of a multi-shard connection query is exactly the same as that of a multi-table connection query. The only difference is that the amount of data in a table shard is much smaller than that in a data table. Each multi-shard connection query handed over to the storage node for processing corresponds to a shard connection information to be sent (which can be called the first shard connection information). The shard connection information may include identifiers of multiple table shards, which are used to instruct the storage node to perform a connection query on these multiple table shards. The multiple table shards for connection query should belong to different data tables, so the multiple table shards indicated by the shard connection information belong to different data tables.

[0086] For example, a multi-table join query is performed on the above data tables table_A and table_B (see Table 1). Table slices included in table_A are slice11 and slice12, and table_B includes table slices including slice21, slice22, and slice23. The corresponding slice connection information may include slice11 join slice21, slice11 join slice22, slice11 join slice23, slice12 join slice21, slice12 join slice22, and slice12 join slice23, these 6 shard connection information correspond to 6 multi-shard connection queries, which are all the multi-shard connection queries that can be obtained by splitting the above multi-table connection query. That is to say, after completing these 6 multi-shard connection queries, we can get 6 shard query results, and combine them to get the query result of the above multi-table connection query. Furthermore, the computing node can use part or all of the 6 shard connection information as the shard connection information to be sent based on the storage status of the table shards of the storage node or some preset business logic.

[0087] In practical applications, the computing node can first determine various possible combinations based on the determined table shards to obtain various possible shard connection information (also known as theoretical shard connection information). Then, based on this possible shard connection information and the storage nodes corresponding to the shards, it determines the shard connection information to be sent. All shards indicated by any shard connection information to be sent correspond to the same storage node. There are many possible specific processing logics here, which will be explained in detail later.

[0088] Step 403: The computing node sends shard connection query information to the target storage node corresponding to each shard connection information to be sent.

[0089] The shard connection query information includes the query conditions and shard connection information in the multi-table connection query instruction. The query conditions include the data table connection condition (i.e., "A_column = B_column") and the target column (i.e., target_column). In addition, if the table shard identifier in the shard connection information cannot uniquely locate the data table to which the table shard belongs, the query conditions may also include the data table identifier to locate the table shard based on the data table identifier and the table shard identifier.

[0090] Each shard connection information to be sent corresponds to at least one storage node, and any storage node corresponding to the shard connection information stores all shards indicated by the shard connection information. For shard connection information corresponding to only one storage node, the corresponding shard connection query information is sent directly to the storage node (the above-mentioned target storage node). For shard connection information corresponding to multiple storage nodes, the computing node can select a storage node (i.e., the above-mentioned target storage node) from multiple storage nodes based on certain selection rules, and send the shard connection query information to the storage node. The selection rule can be load balancing, random, polling, etc. Taking load balancing as an example, the computing node can obtain the resource occupancy information of each storage node, and select the storage node with the least occupied resources as the target storage node based on the resource occupancy information. The resource occupancy information can be at least one of the following information: processor occupancy rate, the total amount of data corresponding to the read and write operations currently being processed, and the number of read and write operations currently being processed.

[0091] For example, for the example shown in Figure 3, the slice connection information to be sent is slice11 join slice21, and the storage nodes that store slice11 and slice21 are storage node 1 and storage node 2. The computing node checks that the processor occupancy rates of these two storage nodes are 40% and 66% respectively, and then selects storage node 1 with a lower processor occupancy rate as the target storage node, and sends the slice connection information slice11 join slice21 and the query conditions to storage node 1.

[0092] In step 404 , the target storage node performs a connection query in the multiple table shards indicated by the shard connection information based on the query condition, and obtains a shard query result.

[0093] Based on the table shard identifier in the shard connection information, the storage node locally reads the corresponding table shard, i.e., the table shard to be connected to the query. Alternatively, the storage node can locally read the corresponding table shard based on the table shard identifier in the shard connection information and the data table identifier in the query condition.

[0094] Based on the join conditions and target columns in the query conditions, the storage node performs a join query on multiple table shards to obtain the shard query results. Table shards are actually smaller data tables. The processing logic for joining multiple table shards is the same as that for joining multiple data tables. The following describes the specific steps for joining table shards:

[0095] The table named stu records various student information. It has four columns: student ID (stu_id), name (stu_name), date of birth (stu_age), and gender (stu_sex). A slice of this table (sliceA) is shown in Table 2:

[0096] Table 2

[0097] The table named sc records students' grades. It has three columns: student ID (sc_stuid), course ID (sc_id), and grade (sc_score). A slice of this table (sliceB) is shown in Table 3:

[0098] Table 3

[0099] The target storage node performs a join query on sliceA and sliceB. To retrieve data from all columns, the multi-table join query instruction sent to the compute node might be: SELECT * FROM stu JOIN sc ON stu_id = sc_stuid . The query conditions sent by the compute node to the target storage node might include "*" and "stu_id = sc_stuid."

[0100] The join query operation process is as follows: the stu_id attribute in the first row of data in sliceA, "01, Zhao Lei, 2000-10-03, Male", is "01". "01" is searched for in all values ​​corresponding to the sc_stuid attribute in sliceB, and the row where "01" is located (the first row in Table 2) is determined. Then these two rows of data are joined to obtain a row of query results "01, Zhao Lei, 2000-10-03, Male, 01, 01, 80". The above operation is performed for each row of data in sliceA. The final complete slice query result can be shown in Table 4:

[0101] Table 4

[0102] When a user needs to return data in a target column (for example, stu_id and stu_name in the stu table and sc_id and sc_score in the sc table), the multi-table join query instruction sent to the compute node can be: SELECT stu_id, stu_name, sc_id, sc_score FROM stu JOIN sc ON stu_id = sc_stuid). The query conditions sent by the compute node to the target storage node may include information such as "stu_id, stu_name, sc_id, sc_score" and "stu_id = sc_stuid".

[0103] The join query operation process is similar to the above process. The difference is that the final query result only includes the data of the target column. The final shard query result can be shown in Table 5:

[0104] Table 5

[0105] Step 405: The target storage node sends the shard query result to the computing node.

[0106] Each target storage node that performs a multi-shard connection query operation sends the shard query results to the corresponding computing node.

[0107] Step 406: The computing node determines the query result of the multi-table join query instruction based on the received shard query result.

[0108] After receiving the shard query results fed back by each target storage node, the computing node determines the final query result based on these shard query results. For example, in some cases, the computing node can combine the received shard query results as the final query result; in some cases, the computing node gives a part of the shard connection information (which can be called the first shard connection information) to the storage node for multi-shard connection query, and performs a multi-shard connection query based on the other part of the shard connection information (which can be called the second shard connection information), combines the received shard query result (which can be called the first shard query result) and the shard query result of its own query (which can be called the second shard query result) to obtain the final query result, and so on. Based on the different specific processing methods of step 402, the processing methods for determining the final query result here are also different. In the following content, the specific processing of step 406 will be explained in detail in combination with the specific processing of step 402.

[0109] Step 407: The computing node provides feedback to the multi-table join query instruction based on the query result.

[0110] Alternatively, in a cloud-native database system, if the amount of data queried by a multi-table join query instruction is large, the above process can be used. The storage node performs a shard join query, and then the computing node summarizes the results. If the amount of data queried by a multi-table join query instruction is small, the computing node can merge the shards of each table to obtain the corresponding data table, and then perform a multi-table join query on the data table. The corresponding processing method can be as follows:

[0111] In the computing node, relevant information of each data table can be recorded, including all table shards included in the data table, the data type of each column of the data table, the number of rows in the data table, etc.

[0112] After parsing the multi-table join query instruction, the computing node can obtain the name of the data table and the name of the target column (the target column is the column involved in the multi-table join query instruction in the corresponding data table) carried therein. Furthermore, the data type of the target column in each data table can be determined, and the number of rows in each data table can be determined. Based on the data type of the target column, the data volume of each field corresponding to the target column can be determined. The product of this data volume and the number of rows is the data volume corresponding to the target column. Furthermore, the total data volume corresponding to all target columns in the multiple data tables (i.e., the data volume of the multiple data tables corresponding to the multi-table join query instruction) can be determined. The total data volume can then be compared with a preset data volume threshold. If the total data volume is greater than the data volume threshold, the processing of steps 402-407 is further executed. If the data volume is less than the data volume threshold, the computing node obtains each table shard from the storage node, merges each table shard to obtain the corresponding data table, performs a multi-table join query on the data table, and provides feedback to the multi-table join query instruction based on the query results.

[0113] In the disclosed embodiment, the compute node splits a multi-table join query into several multi-shard join queries, which are then processed by the storage node. The storage node then feeds the shard query results back to the compute node, which then obtains the final query result based on the shard query results. In this way, part or all of the processing of the multi-table join query is decentralized to the storage node, eliminating the need to send all table shards to the compute node for join queries, significantly reducing the use of the compute node's transmission and processing resources.

[0114] In the embodiment of the present disclosure, when performing the processing of the above step 402 and determining the shard connection information to be sent to the storage node for processing, the processing method shown in FIG5 may be adopted, including the following steps:

[0115] In step 501 , the computing node determines a plurality of theoretical shard connection information based on all table shards respectively included in a plurality of data tables corresponding to the multi-table join query instruction.

[0116] Based on the specified combination logic, all table shards included in multiple data tables are combined to obtain all possible shard combinations (each shard in the shard combination belongs to a different data table). Each shard combination corresponds to a theoretical shard connection information, thus obtaining multiple theoretical shard connection information. The multiple table shards in each theoretical shard connection information belong to different data tables.

[0117] There are many possible situations for the above combinational logic. The following describes several of them:

[0118] In case 1, the number of table shards indicated by the theoretical shard connection information is equal to the number of data tables corresponding to the multi-table connection query instruction. In other words, the multiple table shards indicated by the theoretical shard connection information are obtained by selecting one table shard from each of the data tables corresponding to the multi-table connection query instruction.

[0119] In this case, the computing node can hand over the connection query to the storage node as much as possible.

[0120] For example, if the number of data tables included in a multi-table join query instruction is 2, table_A contains table shards slice11 and slice12, and table_B contains table shards slice21, slice22, and slice23, the generated theoretical shard join information includes:

[0121] slice11 join slice21;

[0122] slice11 join slice22;

[0123] slice11 join slice23;

[0124] slice12 join slice21;

[0125] slice12 join slice22;

[0126] slice12 join slice23.

[0127] For another example, the number of data tables included in the multi-table join query instruction is 3, table_A contains table shards slice11 and slice12, table_B contains table shards slice21, slice22, and slice23, and table_C contains table shards slice31 and slice32. The generated theoretical shard join information includes:

[0128] slice11 join slice21 join slice31;

[0129] slice11 join slice21 join slice32;

[0130] slice11 join slice22 join slice31;

[0131] slice11 join slice22 join slice32;

[0132] slice11 join slice23 join slice31;

[0133] slice11 join slice23 join slice32;

[0134] slice12 join slice21 join slice31;

[0135] slice12 join slice21 join slice32;

[0136] slice12 join slice22 join slice31;

[0137] slice12 join slice22 join slice32;

[0138] slice12 join slice23 join slice31;

[0139] slice12 join slice23 join slice32.

[0140] For the first scenario, the processing of step 406 may include:

[0141] If each theoretical shard connection information corresponds to a storage node (the storage node stores the data of all table shards indicated by the theoretical shard connection information), then the computing node can combine the shard query results received from each storage node to obtain the final query result. If some theoretical shard connection information does not have a corresponding storage node (that is, there is no storage node that stores the data of all table shards indicated by the theoretical shard connection information), then for each theoretical shard connection information that does not have a corresponding storage node, the computing node obtains all table shards contained in the theoretical shard connection information from the storage node, and then completes the multi-shard connection query operation to obtain the corresponding shard query result. For the theoretical shard connection information that corresponds to a storage node, the storage node can perform the corresponding multi-shard connection query and send the shard query result to the computing node. In this way, for all theoretical shard connection information, the computing node obtains the corresponding shard query results, and the computing node can combine these shard query results to obtain a combined query result as the final query result.

[0142] In the second scenario, the number of table shards indicated by the theoretical shard connection information is less than the number of data tables corresponding to the multi-table connection query instruction. In other words, the multiple table shards indicated by the theoretical shard connection information are obtained by selecting one table shard each from the partial data tables corresponding to the multi-table connection query instruction.

[0143] In this case, the computing nodes themselves also have to share more connection query processing.

[0144] For example, a multi-table join query contains three tables, table_A contains table shards slice11 and slice12, table_B contains table shards slice21, slice22, and slice23, and table_C contains table shards slice31 and slice32. Theoretical shard join information is generated only for the table shards corresponding to table_A and table_B. The generated theoretical shard join information includes:

[0145] slice11 join slice21;

[0146] slice11 join slice22;

[0147] slice11 join slice23;

[0148] slice12 join slice21;

[0149] slice12 join slice22;

[0150] slice12 join slice23.

[0151] For the situation described in this example, the processing of step 406 may include:

[0152] The compute node can use the same processing as step 406 in scenario 1 to obtain shard query results corresponding to all theoretical shard connection information, and then combine these shard query results to obtain a combined query result. Furthermore, the compute node obtains the shards of table_C from the storage node and combines the shards to obtain table_C. The compute node can then perform a join query on this combined query result and table_C to obtain the final query result.

[0153] For another example, the number of data tables included in the multi-table join query instruction is 4, table_A contains table shards slice11 and slice12, table_B contains table shards slice21, slice22, and slice23, table_C contains table shards slice31 and slice32, and table_D contains table shards slice41, slice42, and slice43. The table shards corresponding to table_A and table_B are generated into theoretical shard join information, which includes:

[0154] slice11 join slice21;

[0155] slice11 join slice22;

[0156] slice11 join slice23;

[0157] slice12 join slice21;

[0158] slice12 join slice22;

[0159] slice12 join slice23.

[0160] Generate theoretical shard connection information for the table shards corresponding to table_C and table_D. The generated theoretical shard connection information includes:

[0161] slice31 join slice41;

[0162] slice31 join slice42;

[0163] slice31 join slice43;

[0164] slice32 join slice41;

[0165] slice32 join slice42;

[0166] slice32 join slice43.

[0167] For the situation described in this example, the processing of step 406 may include:

[0168] The theoretical shard connection information corresponding to table_A and table_B forms shard connection information set M, and the theoretical shard connection information corresponding to table_C and table_D forms shard connection information set N. The computing node can use the processing method of step 406 in case one to obtain the shard query results corresponding to shard connection information set M and shard connection information set N. All shard query results corresponding to shard connection information set M are combined to obtain a first combined query result. All shard query results corresponding to shard connection information set N are combined to obtain a second combined query result. The computing node then performs a join query process on the first and second combined query results to obtain a final query result.

[0169] Similar processing methods can be used for any number of data tables, and will not be described here one by one.

[0170] Step 502: The computing node determines at least one shard connection information to be sent to the storage node for processing based on multiple theoretical shard connection information.

[0171] For each theoretical shard connection information, the computing node can obtain the storage nodes corresponding to all table shards in the theoretical shard connection information by looking up the correspondence table of data tables, table shards, and storage nodes. The computing node can then determine whether there is an intersection of the storage nodes corresponding to each table shard, that is, whether there is a storage node that stores all the table shards indicated by the theoretical shard connection information. If such a storage node exists, the storage node is used as the storage node corresponding to the theoretical shard connection information, and the theoretical shard connection information is determined as the shard connection information to be sent.

[0172] For example, for the example shown in Figure 3, a corresponding relationship table between data tables, table shards, and storage nodes can be established in the computing node, as shown in Table 1:

[0173] The method for determining whether the theoretical shard connection information slice11 join slice21 is the shard connection information to be sent is as follows: by searching the above correspondence table, it can be concluded that storage node 1 and storage node 2 both store table shard slice11 and table shard slice21, so the theoretical shard connection information slice11 join slice21 is determined as the shard connection information to be sent, and the storage nodes corresponding to the theoretical shard connection information slice11 join slice21 are recorded as storage node 1 and storage node 2. Similarly, it can be determined whether each theoretical shard connection information is the shard connection information to be sent, and the storage node corresponding to the theoretical shard connection information can be recorded. The shard connection information to be sent and the corresponding storage node are recorded in the correspondence table of the shard connection information to be sent and the storage node.

[0174] The corresponding relationship table of the shard connection information to be sent and the storage node can be shown in Table 6:

[0175] Table 6

[0176] Based on the same technical concept, an embodiment of the present disclosure provides a device for multi-table join query, which can be applied to the above computing node. As shown in FIG6 , the device includes:

[0177] Receiving module 610, for receiving a multi-table join query instruction;

[0178] A determination module 620 is configured to determine at least one first shard connection information based on the table shards respectively included in the multiple data tables corresponding to the multi-table join query instruction, wherein each first shard connection information indicates multiple table shards for the join query;

[0179] A sending module 630 is configured to send shard connection query information corresponding to each first shard connection information to a target storage node corresponding to each first shard connection information, where the shard connection query information includes the first shard connection information and a query condition in a multi-table connection query instruction, and the target storage node stores multiple table shards indicated by the corresponding first shard connection information.

[0180] A result module 640 is configured to receive the first shard query result sent by each target storage node, and determine a query result of the multi-table join query instruction based on at least one received first shard query result;

[0181] The feedback module 650 is configured to provide feedback on the multi-table join query instruction based on the query result.

[0182] In one possible implementation, the determination module 620 is used to: determine at least one shard connection information based on the table shards respectively included in the multiple data tables corresponding to the multi-table join query instruction, wherein each shard connection information indicates multiple table shards used for the join query; and determine at least one first shard connection information from the at least one shard connection information, wherein the multiple table shards indicated by the first shard connection information are stored in the same storage node.

[0183] In one possible implementation, the determination module 620 is further used to determine at least one second shard connection information, wherein the multiple table shards indicated by the second shard connection information are stored in different storage nodes; the receiving module 610 is further used to obtain the multiple table shards indicated by the at least one second shard connection information from the multiple storage nodes corresponding to the at least one second shard connection information; the device also includes a query module 660, which is used to perform a connection query on the multiple table shards indicated by the at least one second shard connection information based on the query conditions in the multi-table connection query instruction to obtain a second shard query result; the result module 640 is used to combine the received at least one first shard query result and the second shard query result into a query result of the multi-table connection query instruction.

[0184] In a possible implementation, the result module 640 is configured to combine the received multiple first shard query results into a query result of a multi-table join query instruction.

[0185] In one possible implementation, the determination module 620 is further used to: determine at least one storage node corresponding to each first shard connection information, where the storage node stores multiple table shards indicated by the corresponding first shard connection information; and determine a target storage node from at least one storage node based on resource occupancy information of the at least one storage node.

[0186] In a possible implementation, the determination module 620 is further configured to determine whether the data volume of the multiple data tables corresponding to the multi-table join query instruction exceeds a preset threshold.

[0187] In the disclosed embodiment, the compute node splits a multi-table join query into several multi-shard join queries, which are then processed by the storage node. The storage node then feeds the shard query results back to the compute node, which then obtains the final query result based on the shard query results. In this way, part or all of the processing of the multi-table join query is decentralized to the storage node, eliminating the need to send all table shards to the compute node for join queries, significantly reducing the use of the compute node's transmission and processing resources.

[0188] The receiving module 610, determining module 620, sending module 630, result module 640, feedback module 650, and query module 660 can all be implemented via software or hardware. For example, the implementation of the receiving module 610 will be described below using the receiving module 610 as an example. Similarly, the implementation of the determining module 620, sending module 630, result module 640, feedback module 650, and query module 660 can refer to the implementation of the receiving module 610.

[0189] As an example of a software functional unit, the receiving module 610 may include code running on a computing instance. The computing instance may include at least one of a physical host (computing device), a virtual machine, and a container. Furthermore, the computing instance may be one or more. For example, the receiving module 610 may include code running on multiple hosts / virtual machines / containers. It should be noted that the multiple hosts / virtual machines / containers used to run the code may be distributed in the same region or in different regions. Furthermore, the multiple hosts / virtual machines / containers used to run the code may be distributed in the same availability zone (AZ) or in different AZs, each AZ including one data center or multiple geographically close data centers. Typically, a region may include multiple AZs.

[0190] Similarly, multiple hosts / virtual machines / containers running the code can be distributed within the same virtual private cloud (VPC) or across multiple VPCs. Typically, a VPC is set up within a region. Cross-region communication between two VPCs within the same region, or between VPCs in different regions, requires a communication gateway within each VPC to interconnect the VPCs.

[0191] As an example of a hardware functional unit, the receiving module 610 may include at least one computing device, such as a server. Alternatively, the receiving module 610 may be implemented using an application-specific integrated circuit (ASIC) or a programmable logic device (PLD). The PLD may be a complex programmable logical device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), or any combination thereof.

[0192] The multiple computing devices included in the receiving module 610 can be distributed in the same region or in different regions. The multiple computing devices included in the receiving module 610 can be distributed in the same AZ or in different AZs. Similarly, the multiple computing devices included in the receiving module 610 can be distributed in the same VPC or in multiple VPCs. The multiple computing devices can be any combination of servers, ASICs, PLDs, CPLDs, FPGAs, GALs, and other computing devices.

[0193] It should be noted that, in other embodiments, the receiving module 610, the determining module 620, the sending module 630, the result module 640, the feedback module 650 and the query module 660 can be used for any step in the multi-table join query method in the computing node. The steps that the receiving module 610, the determining module 620, the sending module 630, the result module 640, the feedback module 650 and the query module 660 are responsible for implementing can be specified as needed. The full functions of the device for executing multi-table join queries on the computing node are realized by respectively implementing different steps in the multi-table join query method through the receiving module 610, the determining module 620, the sending module 630, the result module 640, the feedback module 650 and the query module 660.

[0194] Based on the same technical concept, an embodiment of the present disclosure provides a device for multi-table join query, which can be applied to the above storage node. As shown in FIG7 , the device includes:

[0195] A receiving module 710 is configured to receive shard connection query information sent by a computing node, where the shard connection query information includes first shard connection information and a query condition, and the first shard connection information indicates that multiple table shards are stored in a storage node.

[0196] A query module 720 is configured to perform a join query in the plurality of table shards indicated by the first shard connection information based on the query condition, and obtain a first shard query result;

[0197] The sending module 730 is used to send the first shard query result to the computing node.

[0198] In the disclosed embodiment, the compute node splits a multi-table join query into several multi-shard join queries, which are then processed by the storage node. The storage node then feeds the shard query results back to the compute node, which then obtains the final query result based on the shard query results. In this way, part or all of the processing of the multi-table join query is decentralized to the storage node, eliminating the need to send all table shards to the compute node for join queries, significantly reducing the use of the compute node's transmission and processing resources.

[0199] The receiving module 710, query module 720, and sending module 730 can all be implemented in software or hardware. For example, the implementation of the receiving module 710 will be described below using the receiving module 710 as an example. Similarly, the implementation of the query module 720 and sending module 730 can refer to the implementation of the receiving module 710.

[0200] As an example of a software functional unit, the receiving module 710 may include code running on a computing instance. The computing instance may include at least one of a physical host (computing device), a virtual machine, and a container. Furthermore, the computing instance may be one or more. For example, the receiving module 710 may include code running on multiple hosts / virtual machines / containers. It should be noted that the multiple hosts / virtual machines / containers used to run the code may be distributed in the same region or in different regions. Furthermore, the multiple hosts / virtual machines / containers used to run the code may be distributed in the same availability zone (AZ) or in different AZs, each AZ including one data center or multiple geographically close data centers. Typically, a region may include multiple AZs.

[0201] Similarly, multiple hosts / virtual machines / containers running the code can be distributed within the same virtual private cloud (VPC) or across multiple VPCs. Typically, a VPC is set up within a region. Cross-region communication between two VPCs within the same region, or between VPCs in different regions, requires a communication gateway within each VPC to interconnect the VPCs.

[0202] As an example of a hardware functional unit, receiving module 710 may include at least one computing device, such as a server. Alternatively, receiving module 710 may be implemented using an application-specific integrated circuit (ASIC) or a programmable logic device (PLD). The PLD may be a complex programmable logical device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), or any combination thereof.

[0203] The multiple computing devices included in the receiving module 610 can be distributed in the same region or in different regions. The multiple computing devices included in the receiving module 610 can be distributed in the same AZ or in different AZs. Similarly, the multiple computing devices included in the receiving module 610 can be distributed in the same VPC or in multiple VPCs. The multiple computing devices can be any combination of servers, ASICs, PLDs, CPLDs, FPGAs, GALs, and other computing devices.

[0204] It should be noted that, in other embodiments, the receiving module 710, the query module 720 and the sending module 730 can be used for any step in the multi-table connection query method in the storage node. The steps that the receiving module 710, the query module 720 and the sending module 730 are responsible for implementing can be specified as needed. The full functions of the device for executing multi-table connection query in the storage node are realized by respectively implementing different steps in the multi-table connection query method through the receiving module 710, the query module 720 and the sending module 730.

[0205] The present disclosure also provides a cloud-native database system, as shown in FIG2 , which includes computing nodes and storage nodes. The functions of the computing nodes and storage nodes have been introduced and will not be repeated here.

[0206] Compute nodes and storage nodes can be implemented in software or hardware. For example, the following describes the implementation of a compute node. Similarly, the implementation of a storage node can refer to the implementation of a compute node.

[0207] As an example of a software functional unit, a module may include a computing node that runs on a computing instance. The computing instance may be at least one of a physical host (computing device), a virtual machine, a container, and other computing devices. Furthermore, the computing device may be one or more. For example, a multi-table join query device may include code running on multiple hosts / virtual machines / containers. It should be noted that the multiple hosts / virtual machines / containers used to run the application may be distributed in the same region or in different regions. The multiple hosts / virtual machines / containers used to run the code may be distributed in the same AZ or in different AZs, and each AZ includes one data center or multiple geographically close data centers. Typically, a region may include multiple AZs.

[0208] Similarly, the multiple hosts / virtual machines / containers running the code can be distributed within the same VPC or across multiple VPCs. Typically, a VPC is located within a region. Cross-region communication between two VPCs within the same region, or between VPCs in different regions, requires a communication gateway within each VPC to interconnect the VPCs.

[0209] A module is an example of a hardware functional unit. A computing node may include at least one computing device, such as a server. Alternatively, the multi-table join query device may be implemented using an ASIC or a PLD. The PLD may be implemented using a CPLD, FPGA, GAL, or any combination thereof.

[0210] The multiple computing devices included in a compute node can be distributed in the same region or in different regions. They can also be distributed in the same AZ or in different AZs. Similarly, they can be distributed in the same VPC or across multiple VPCs. These multiple computing devices can be any combination of servers, ASICs, PLDs, CPLDs, FPGAs, GALs, and other computing devices.

[0211] The present disclosure also provides a computing device 100. Computing device 100 can be applied to the aforementioned computing node or storage node. As shown in FIG8 , computing device 100 includes a bus 102, a processor 104, a memory 106, and a communication interface 108. Processor 104, memory 106, and communication interface 108 communicate with each other via bus 102. Computing device 100 can be a server or a terminal device. It should be understood that the present disclosure does not limit the number of processors and memories in computing device 100.

[0212] Bus 102 may be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, among others. Buses may be classified as address buses, data buses, control buses, and the like. For ease of illustration, FIG8 illustrates a single bus line, but this does not imply a single bus or type of bus. Bus 102 may include a path for transmitting information between various components of computing device 100 (e.g., memory 106, processor 104, and communication interface 108).

[0213] The processor 104 may include any one or more processors such as a central processing unit (CPU), a graphics processing unit (GPU), a microprocessor (MP), or a digital signal processor (DSP).

[0214] The memory 106 may include volatile memory, such as random access memory (RAM). The memory 106 may also include non-volatile memory, such as read-only memory (ROM), flash memory, hard disk drive (HDD), or solid state drive (SSD).

[0215] The memory 106 stores executable program code. The processor 104 executes the executable program code to implement the functions of the aforementioned receiving module 610, determining module 620, sending module 630, result module 640, feedback module 650, query module 660, receiving module 710, query module 720, and sending module 730, thereby implementing the multi-table join query method. In other words, the memory 106 stores instructions for the multi-table join query method.

[0216] Alternatively, the memory 106 stores executable code, and the processor 104 executes the executable code to respectively implement the functions of the aforementioned receiving module 610, determining module 620, sending module 630, result module 640, feedback module 650, query module 660, receiving module 710, query module 720, and sending module 730, thereby implementing the multi-table join query method. In other words, the memory 106 stores instructions for the multi-table join query method.

[0217] The communication interface 108 uses a transceiver module such as, but not limited to, a network interface card or a transceiver to implement communication between the computing device 100 and other devices or a communication network.

[0218] The present disclosure also provides a computing device cluster. The computing device cluster includes at least one computing device. The computing device can be a server, such as a central server, an edge server, or a local server in a local data center. In some embodiments, the computing device can also be a terminal device such as a desktop computer, a laptop computer, or a smartphone.

[0219] As shown in Figure 9, the computing device cluster includes at least one computing device 100. The memory 106 of one or more computing devices 100 in the computing device cluster may store the same instructions for the multi-table join query method.

[0220] In some possible implementations, the memory 106 of one or more computing devices 100 in the computing device cluster may also store partial instructions for the multi-table join query method. In other words, the combination of one or more computing devices 100 can jointly execute the instructions for the multi-table join query method.

[0221] It should be noted that the memory 106 in different computing devices 100 in the computing device cluster can store different instructions, each for performing a portion of the functions of the apparatus for multi-table join query. That is, the instructions stored in the memory 106 in different computing devices 100 can implement the functions of one or more of the aforementioned receiving module 610, determining module 620, sending module 630, result module 640, feedback module 650, query module 660, receiving module 710, query module 720, and sending module 730.

[0222] In some possible implementations, one or more computing devices in a computing device cluster may be connected via a network. The network may be a wide area network (WAN) or a local area network (LAN), and the network may be a Transmission Control Protocol (TCP) network or a Remote Direct Memory Access (RDMA) network. FIG10 illustrates a possible implementation. As shown in FIG10 , two computing devices 100A and 100B are connected via a network. Specifically, the connection to the network is achieved via a communication interface in each computing device. In this type of possible implementation, the memory 106 in the computing device 100A stores instructions for executing the functions of the receiving module 610, the determining module 620, the sending module 630, the result module 640, the feedback module 650, and the query module 660. Simultaneously, the memory 106 in the computing device 100B stores instructions for executing the functions of the receiving module 710, the query module 720, and the sending module 730.

[0223] The connection method between the computing device clusters shown in Figure 10 can be that considering that the method for multi-table connection query provided by the present disclosure requires a large amount of data storage, it is considered to entrust the functions implemented by the receiving module 710, the query module 720 and the sending module 730 to the computing device 100B for execution.

[0224] It should be understood that the functions of the computing device 100A shown in FIG10 may also be completed by multiple computing devices 100. Similarly, the functions of the computing device 100B may also be completed by multiple computing devices 100.

[0225] The present disclosure also provides another computing device cluster. The connection relationship between the computing devices in this computing device cluster can be similar to the connection method of the computing device cluster described in Figures 9 and 10. However, the memory 106 of one or more computing devices 100 in this computing device cluster can store the same instructions for the multi-table join query method.

[0226] In some possible implementations, the memory 106 of one or more computing devices 100 in the computing device cluster may also store partial instructions for the multi-table join query method. In other words, the combination of one or more computing devices 100 can jointly execute the instructions for the multi-table join query method.

[0227] The present disclosure also provides a computer program product including instructions. The computer program product may be software or a program product including instructions that can be executed on a computing device or stored on any available medium. When executed on at least one computing device, the computer program product enables the at least one computing device to perform a multi-table join query.

[0228] The embodiments of the present disclosure also provide a computer-readable storage medium. The computer-readable storage medium can be any available medium that can be stored by a computing device, or a data storage device such as a data center that contains one or more available media. The available medium can be a magnetic medium (e.g., a floppy disk, a hard disk, a magnetic tape), an optical medium (e.g., a digital video disk (DVD)), or a semiconductor medium (e.g., a solid-state drive). The computer-readable storage medium includes instructions that instruct the computing device to perform a multi-table join query, or instruct the computing device to execute a multi-table join query.

[0229] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present disclosure, rather than to limit them. Although the present disclosure has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the protection scope of the technical solutions of the various embodiments of the present disclosure.

Claims

1. A method for multi-table connection query, characterized in that: The method is applied to a cloud native database system, the cloud native database system includes a computing node and a plurality of storage nodes, and the method includes: The computing node receives a multi-table connection query instruction; The computing node determines at least one first shard connection information based on the table shards respectively included in the multiple data tables corresponding to the multi-table connection query instruction, wherein each first shard connection information indicates multiple table shards for connection query; The computing node sends shard connection query information corresponding to the first shard connection information to each target storage node corresponding to the first shard connection information, wherein the shard connection query information includes the first shard connection information and the query condition in the multi-table connection query instruction, and the target storage node stores multiple table shards indicated by the corresponding first shard connection information; Based on the query condition, each of the target storage nodes performs a connection query in a plurality of table shards indicated by the first shard connection information corresponding to the target storage node to obtain a first shard query result; The computing node receives the first shard query result sent by each of the target storage nodes; The computing node determines a query result of the multi-table join query instruction based on the received at least one first shard query result, and provides feedback to the multi-table join query instruction based on the query result.

2. The method according to claim 1, characterized in that: The computing node determines at least one first shard connection information based on the table shards respectively included in the multiple data tables corresponding to the multi-table connection query instruction, including: The computing node determines at least one shard connection information based on the table shards respectively included in the multiple data tables corresponding to the multi-table connection query instruction, wherein each shard connection information indicates multiple table shards for connection query; The computing node determines at least one first shard connection information from the at least one shard connection information, wherein the multiple table shards indicated by the first shard connection information are stored in the same storage node.

3. The method according to claim 2, characterized in that The method further comprises: The computing node determines at least one second shard connection information, wherein the plurality of table shards indicated by the second shard connection information are stored in different storage nodes; The computing node obtains, from the plurality of storage nodes corresponding to the at least one second shard connection information, the plurality of table shards indicated by the at least one second shard connection information; The computing node performs a connection query on the multiple table shards indicated by the at least one second shard connection information based on the query condition in the multi-table connection query instruction to obtain a second shard query result; The computing node determines the query result of the multi-table join query instruction based on the received at least one first shard query result, including: The computing node combines the received at least one first shard query result and the second shard query result into a query result of the multi-table join query instruction.

4. The method according to claim 1, characterized in that The computing node determines the query result of the multi-table join query instruction based on the received multiple first shard query results, including: The computing node combines the received multiple first shard query results into a query result of the multi-table connection query instruction.

5. The method according to any one of claims 1 to 4, characterized in that The method further comprises: The computing node determines at least one storage node corresponding to each first shard connection information, and the storage node stores a plurality of table shards indicated by the corresponding first shard connection information; The computing node determines a target storage node from the at least one storage node according to the resource occupation information of the at least one storage node.

6. The method according to any one of claims 1 to 5, characterized in that Before the computing node determines at least one first shard connection information based on the table shards respectively included in the multiple data tables corresponding to the multi-table connection query instruction, the method further includes: The computing node determines that the data volume of the multiple data tables corresponding to the multi-table connection query instruction exceeds a preset threshold.

7. A cloud native database system, characterized in that: The cloud native database system includes a computing node and multiple storage nodes; The computing node is used to receive a multi-table connection query instruction; determine at least one first shard connection information based on table shards respectively included in a plurality of data tables corresponding to the multi-table connection query instruction, wherein each first shard connection information indicates a plurality of table shards used for connection query; send shard connection query information corresponding to the first shard connection information to a target storage node corresponding to each first shard connection information, the shard connection query information including the first shard connection information and a query condition in the multi-table connection query instruction, and the target storage node stores a plurality of table shards indicated by the corresponding first shard connection information; Each of the target storage nodes is configured to perform a connection query in a plurality of table shards indicated by the first shard connection information corresponding to the target storage node based on the query condition to obtain a first shard query result; The computing node is used to receive the first shard query result sent by each of the target storage nodes; determine the query result of the multi-table connection query instruction based on at least one first shard query result received, and provide feedback to the multi-table connection query instruction based on the query result.

8. The cloud native database system according to claim 7, characterized in that: The computing node is used for: Based on the table shards respectively included in the multiple data tables corresponding to the multi-table connection query instruction, determine at least one shard connection information, wherein each shard connection information indicates multiple table shards for connection query; At least one first shard connection information is determined from the at least one shard connection information, wherein the multiple table shards indicated by the first shard connection information are stored in the same storage node.

9. The cloud native database system according to claim 8, characterized in that: The computing node is further used for: Determine at least one second shard connection information, wherein the plurality of table shards indicated by the second shard connection information are stored in different storage nodes; Acquire, from the plurality of storage nodes corresponding to the at least one second shard connection information, the plurality of table shards indicated by the at least one second shard connection information; Based on the query condition in the multi-table connection query instruction, a connection query is performed on the multiple table shards indicated by the at least one second shard connection information to obtain a second shard query result; The computing node is used for: The at least one first shard query result and the second shard query result received are combined into a query result of the multi-table join query instruction.

10. The cloud native database system according to claim 7, characterized in that: The computing node is used for: The received multiple first shard query results are combined into a query result of the multi-table connection query instruction.

11. The cloud native database system according to any one of claims 7 to 10, characterized in that: The computing node is further used for: Determine at least one storage node corresponding to each first shard connection information, wherein the storage node stores a plurality of table shards indicated by the corresponding first shard connection information; According to the resource occupation information of the at least one storage node, a target storage node is determined from the at least one storage node.

12. The cloud native database system according to any one of claims 7 to 11, characterized in that: The computing node is further used for: It is determined that the data amount of the multiple data tables corresponding to the multi-table connection query instruction exceeds a preset threshold.

13. A computing device cluster, characterized in that: comprising at least one computing device, each computing device comprising a processor and a memory; The processor of the at least one computing device is configured to execute instructions stored in the memory of the at least one computing device, so that the computing device cluster executes the method according to any one of claims 1 to 6.

14. A computer-readable storage medium, characterized in that: The method comprises computer program instructions, and when the computer program instructions are executed by a computing device cluster, the computing device cluster performs the method according to any one of claims 1 to 6.

15. A computer program product comprising instructions, characterized in that When the instructions are executed by a computing device cluster, the computing device cluster is caused to perform the method according to any one of claims 1 to 6.

Images