Distributed database plan execution method, device and system
By assigning different line number starting values to multiple execution threads in a distributed database, they can generate data line numbers in parallel, which solves the single-point performance problem caused by data line number generation operations, and improves the parallel execution of distributed databases performance.
Patent Information
- Application Number
- CN202210554683.X
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2022-05-19
- Publication Date
- 2025-01-10
- Estimated Expiration
- 2042-05-19
AI Technical Summary
In a distributed database, single-point operations caused by execution operators involving data line number generation operations seriously affect the performance of parallel execution, resulting in DFOs being unable to execute in parallel.
When encountering an operation that needs to generate data line numbers, multiple execution threads send line number starting value acquisition requests to the dispatching node, and the dispatching node allocates different line number starting values. Each thread uses these values to generate line numbers for local data. , execute DFO in parallel.
Through this method, the parallel execution performance of distributed databases is improved and performance bottlenecks caused by single-point operations are avoided.
Smart Images

Figure CN114996299B_ABST
Abstract
Description
Technical Field
[0001] The embodiments of this specification generally relate to the field of databases, and in particular to a plan execution method and a plan execution device for a distributed database, a data query method and a data query engine, and a distributed database. Background Art
[0002] A distributed database consists of multiple distributed storage nodes. Each distributed storage node includes a data query engine and a data storage engine. Distributed databases usually adopt a shared noting architecture, such as the OceanBase database. In this distributed database, data is distributedly stored in various data storage engines.
[0003] When executing data query on distributed database, after the distributed storage node receives the data query statement, the distributed storage node will generate a distributed execution plan according to the received data query statement, each distributed execution plan is managed by a PX operator, and the distributed execution plan managed by the PX operator is converted into multiple distributed logical sub-plans (DFO), and the multiple DFOs are formed into a tree structure. Each of the multiple DFOs is dispatched to multiple distributed data storage nodes in sequence by the PX operator in a certain logical order, and multiple distributed storage nodes enable multiple execution threads to execute in parallel, thereby realizing data query.
[0004] However, in some distributed database application scenarios, the parallel-executed DFO may include execution operators that involve operations that require the generation of data row numbers for the data used, such as COUNT operators, SUM operators, etc. For example, when the semantics of a data query statement (e.g., an SQL statement) requires row numbers, the optimizer will choose to create row numbers during the execution of a suitable execution operator, such as creating row numbers during the execution of a count operator. In a distributed database, the data row number generation operation is usually implemented using the ROWNUM function. The semantics of the ROWNUM function determine that the generated data row numbers must be continuous, unique, and increasing. If the DFO includes execution operators that involve operations that require the generation of data row numbers for the data used, then during the execution of the DFO, data row numbers need to be generated for the data used, and the generated data row numbers need to be guaranteed to increase continuously, making the data row number generation operation a single-point operation. The term "single-point operation" refers to a computing operation that is executed sequentially by a single thread and cannot be executed concurrently. In a distributed database, this single-point operation will cause the corresponding DFO to be unable to be executed in parallel, thereby seriously affecting the parallel execution performance of the distributed database. Summary of the invention
[0005] In view of the above, the embodiments of this specification provide a plan execution method and plan execution device, a data query method and a data query engine, and a distributed database for a distributed database. Using the plan execution method and plan execution device, during the plan execution process, once a DFO that requires the operation of generating data row numbers for the data used is encountered, multiple execution threads executing the DFO in parallel send a row number starting value acquisition request to the scheduling node, and the scheduling node assigns different row number starting values to each execution thread. Each execution thread uses the assigned row number starting value to generate data row numbers for the data received locally, and then uses the data with the generated data row numbers to execute the DFO in parallel, thereby improving the parallel execution performance of the distributed database.
[0006] According to one aspect of an embodiment of the present specification, a method for executing a logical sub-plan of a distributed database is provided, the method being executed by a first execution thread at a plan execution node, the method comprising: receiving in parallel together with at least one second execution thread scheduled to execute the current logical sub-plan the return data returned by a sub-logical sub-plan of the current logical sub-plan; determining whether the current logical sub-plan includes an execution operator involving a row number generation operation; in response to the current logical sub-plan including an execution operator involving a row number generation operation, caching the received data and sending a row number start value acquisition request to a scheduling node, the row number start value acquisition request including the number of cached data rows, generating a data row number for the cached data according to the row number start value received from the scheduling node, the row number start value being allocated to the first execution thread by the scheduling node in response to the row number start value acquisition request, executing in parallel together with the second execution thread using the data generated with the data row number received by each of them; and sending in parallel together with the second execution thread the execution result of the current logical sub-plan as the return data to the execution thread of the parent logical sub-plan scheduled to execute the current logical sub-plan.
[0007] Optionally, in an example of the above aspect, the method may further include: in response to the current logical sub-plan not containing an execution operator involving a row number generation operation, together with the second execution thread, executing the current logical sub-plan in parallel using the respective received data.
[0008] Optionally, in an example of the above aspect, determining whether the current logical sub-plan includes an execution operator involving a line number generation operation may include: traversing the execution operators in the current logical sub-plan to determine whether the current logical sub-plan includes an execution operator involving a line number generation operation.
[0009] Optionally, in an example of the above aspect, the scheduling node obtains the number of cache data rows in the request based on the row number starting values received from the first execution thread and the second execution thread, and assigns continuously increasing row number starting values to the first execution thread and each second execution thread.
[0010] Optionally, in an example of the above aspect, the second execution thread includes an execution thread located at the same planned execution node as the first execution thread and / or an execution thread located at a different planned execution node than the first execution thread.
[0011] Optionally, in an example of the above aspect, the number of execution threads at each plan execution node is determined according to the data association between the data stored in the plan execution node and the current logical sub-plan and the idle thread resources at the plan execution node.
[0012] According to another aspect of an embodiment of the present specification, a method for performing data query in a distributed database is provided, comprising: receiving a data query statement provided by a user; generating a distributed execution plan according to the received data query statement; performing logical transformation on the distributed execution plan to obtain a plurality of distributed logical sub-plans, wherein the plurality of distributed logical sub-plans are formed into a tree structure; scheduling the plurality of distributed logical sub-plans in sequence to corresponding distributed data storage nodes according to a scheduling order to execute them in parallel according to the method described above; and providing the execution result of the top-level distributed logical sub-plan to the user as a data query result.
[0013] Optionally, in an example of the above aspect, the scheduling order of the distributed logical sub-plans is determined according to the tree structure of the distributed logical sub-plans.
[0014] According to another aspect of an embodiment of the present specification, there is provided an apparatus for executing a logical sub-plan of a distributed database, the distributed database comprising a plurality of distributed storage nodes, the apparatus being applied to a first distributed storage node acting as a plan execution node, the apparatus comprising: a data receiving unit, receiving, via a first execution thread at the first distributed storage node, in parallel with at least one second execution thread scheduled to execute the current logical sub-plan, the spit-out data returned by the sub-logical sub-plan of the current logical sub-plan; a plan judging unit, judging, via the first execution thread, whether the current logical sub-plan contains an execution operator involving a row number generation operation; a plan executing unit, in response to the current logical sub-plan containing an execution operator involving a row number generation operation, The first execution thread caches the received data and sends a row number starting value acquisition request to the scheduling node, the row number starting value acquisition request includes the number of cached data rows, generates a data row number for the cached data according to the row number starting value received from the scheduling node, the row number starting value is allocated to the first execution thread by the scheduling node in response to the row number starting value acquisition request, and together with the second execution thread, executes the current logical sub-plan in parallel using the data generated with the data row numbers respectively received; and a data sending unit, via the first execution thread, together with the second execution thread, sends the execution result of the current logical sub-plan as callback data in parallel to the execution thread of the parent logical sub-plan scheduled to execute the current logical sub-plan.
[0015] Optionally, in an example of the above aspect, in response to the current logical sub-plan not containing an execution operator involving a row number generation operation, the plan execution unit executes the current logical sub-plan in parallel via the first execution thread and the second execution thread using the data received by each.
[0016] Optionally, in an example of the above aspect, the plan execution unit includes: a data caching module, which caches the received data via the first execution thread in response to the current logical sub-plan containing an execution operator involving a row number generation operation; a request sending module, which sends a row number starting value acquisition request to the scheduling node via the first execution thread; a row number starting value receiving module, which receives the row number starting value from the scheduling node via the first execution thread; a row number generation module, which generates a data row number for the cached data based on the received row number starting value via the first execution thread; and a plan execution module, which executes the current logical sub-plan in parallel together with the first execution thread and the second execution thread using the data generated with the data row numbers respectively received.
[0017] Optionally, in an example of the above aspect, the plan determination unit traverses the execution operators in the current logical sub-plan to determine whether the current logical sub-plan includes an execution operator involving a row number generation operation.
[0018] Optionally, in an example of the above aspect, the row number starting values corresponding to the data at the first execution thread and each second execution thread are allocated by the scheduling node based on the number of cache data rows in the request obtained according to the row number starting values received from the first execution thread and the second execution thread, and the row number starting values received by the first execution thread and each second execution thread are continuously increased.
[0019] According to another aspect of an embodiment of the present specification, there is provided a data query engine for performing data query in a distributed database, wherein the distributed database comprises a plurality of distributed data storage nodes, each distributed data storage node comprises a data query engine and a data storage engine, and the data query engine comprises: a query statement receiving device, receiving a data query statement provided by a user; a plan generating device; generating a distributed execution plan according to the received data query statement; a plan transforming device; performing logical transformation on the distributed execution plan to obtain a plurality of distributed logical sub-plans, wherein the plurality of distributed logical sub-plans are formed into a tree structure; a plan scheduling device, scheduling the plurality of distributed logical sub-plans in sequence to corresponding distributed data storage nodes according to a scheduling order; the plan executing device as described above; and a query result providing device, providing the execution result of the top-level distributed logical sub-plan as a data query result to the user.
[0020] According to another aspect of an embodiment of the present specification, there is provided a distributed database, comprising: at least two distributed storage nodes, each storage node comprising a data storage engine and the data query engine as described above.
[0021] According to another aspect of an embodiment of the present specification, there is provided a plan execution device for a distributed database, comprising: at least one processor, a memory coupled to the at least one processor, and a computer program stored in the memory, wherein the at least one processor executes the computer program to implement the plan execution method as described above.
[0022] According to another aspect of an embodiment of the present specification, there is provided a data query engine for a distributed database, comprising: at least one processor, a memory coupled to the at least one processor, and a computer program stored in the memory, wherein the at least one processor executes the computer program to implement the data query method as described above.
[0023] According to another aspect of an embodiment of the present specification, a computer-readable storage medium is provided, which stores executable instructions, and when the instructions are executed, the processor executes the plan execution method as described above or executes the data query method as described above.
[0024] According to another aspect of an embodiment of the present specification, a computer program product is provided, including a computer program, wherein the computer program is executed by a processor to implement the plan execution method described above or to execute the data query method described above. BRIEF DESCRIPTION OF THE DRAWINGS
[0025] A further understanding of the nature and advantages of the content of this specification may be achieved by referring to the following drawings. In the drawings, similar components or features may have the same reference numerals.
[0026] Figure 1 An example schematic diagram of a distributed database is shown.
[0027] Figure 2 An example flow chart of a data query process of a distributed database according to an embodiment of the present specification is shown.
[0028] Figure 3 An example schematic diagram of a distributed execution plan is shown.
[0029] Figure 4A-4E An example schematic diagram showing a tree structure of a distributed logical sub-plan.
[0030] Figure 5 An example flow chart of a distributed database plan execution method according to an embodiment of the present specification is shown.
[0031] Figure 6 An example schematic diagram of a data query process is shown.
[0032] Figure 7 Shows Figure 3 An example schematic diagram of the plan execution process of a distributed execution plan is shown in FIG.
[0033] Figure 8 A block diagram of a data query engine of a distributed database according to an embodiment of the present specification is shown.
[0034] Fig. 9 A block diagram of a plan execution device for a distributed database according to an embodiment of the present specification is shown.
[0035] Fig.10 A block diagram of a plan execution unit according to an embodiment of the present specification is shown.
[0036] Fig.11An example schematic diagram of a plan execution device implemented based on a computer system according to an embodiment of the present specification is shown.
[0037] Fig.12 An example schematic diagram of a data query engine implemented based on a computer system according to an embodiment of the present specification is shown. DETAILED DESCRIPTION
[0038] The subject matter described herein will now be discussed with reference to example embodiments. It should be understood that the discussion of these embodiments is only to enable those skilled in the art to better understand and implement the subject matter described herein, and is not a limitation of the scope of protection, applicability or examples set forth in the claims. The functions and arrangements of the elements discussed can be changed without departing from the scope of protection of the contents of this specification. Various examples can omit, replace or add various processes or components as needed. For example, the described method can be performed in an order different from the described order, and various steps can be added, omitted or combined. In addition, the features described relative to some examples can also be combined in other examples.
[0039] As used herein, the term "including" and its variations represent open terms, meaning "including but not limited to". The term "based on" means "based at least in part on". The terms "one embodiment" and "an embodiment" mean "at least one embodiment". The term "another embodiment" means "at least one other embodiment". The terms "first", "second", etc. may refer to different or the same objects. Other definitions may be included below, whether explicit or implicit. Unless the context clearly indicates otherwise, the definition of a term is consistent throughout the specification.
[0040] Figure 1 An example schematic diagram of a distributed database 1 is shown. Figure 1 As shown, the distributed database system 1 includes a plurality of storage nodes 10-1 to 10-4. The storage nodes 10-1 to 10-4 are distributed storage nodes, each of which includes a data query engine and a data storage engine. It should be noted that Figure 1 The examples shown are merely illustrative. In other embodiments, the distributed database system 1 may include more or fewer storage nodes.
[0041] The distributed database 1 can adopt a shared noting architecture, such as the OceanBase database. In this distributed database, data is distributedly stored in the storage engines of each storage node. For example, data can be divided into multiple data partitions (also referred to as data blocks), and the divided data partitions are stored in different storage engines respectively. Each storage engine can store one or more data partitions. The CPU resources and IO resources required for data access on each storage node occur locally and are executed by the data query engine on the storage node.
[0042] When performing data query, a storage node in the distributed database acts as a scheduling node for the distributed execution plan. After the data query engine of the scheduling node receives the data query statement and generates a distributed execution plan, it will convert the distributed execution plan logic into multiple logical sub-plans (for example, logical conversion according to semantics). In this specification, the logical sub-plan can be referred to as DFO (Data Flow Operation). After completing the DFO conversion, the data query engine at the scheduling node schedules the generated DFO in parallel to multiple storage nodes (i.e., plan execution nodes), and each plan execution node enables one or more execution threads to execute the scheduled DFO in parallel.
[0043] Figure 2 An example flow chart of a data query process 200 of a distributed database according to an embodiment of the present specification is shown.
[0044] When querying data, Figure 2 As shown, at 210, a data query statement input by a user is received via a data query engine at a storage node to which the user is connected. In one example, the data query statement input by the user may be received via an input interface, an input unit, or an input device of the data query engine. For example, a data query statement input by a user may be received via an input box on a client interface of the data query engine. For example, in one example, the data query may be, for example, an SQL query, and the data query statement may include an SQL statement, such as, for example, the received SQL statement may be, for example, "select t2.a, t2.b, (select sum (c) from t5 where t1.b = t5.a) as sum from t1, t2, t3, t4 where t1.a = 1 and t1.b = t2.a and t1.b = t3.a and t1.b = t4.a".
[0045] At 220, at the scheduling node, a distributed execution plan is generated according to the received data query statement via the data query engine. For example, the scheduling node can generate a distributed execution plan according to the received data query statement using an optimizer in the data query engine. The distributed execution plan may, for example, include a SQL execution plan having a tree structure composed of a plurality of SQL operators. The SQL operator is a basic component unit constituting the SQL execution plan, and is used to describe basic operations corresponding to specific SQL semantics, such as a TABLE SCAN operator, a TABLE INSERT operator, a TABLE UPDATE operator, a TABLE DELETE operator, a JOIN operator, a GROUP BY operator, an ORDER BY operator, an EXCHANGE operator, etc. Accordingly, the optimizer may be a SQL optimizer. Figure 3 An example schematic diagram of an SQL execution plan for the SQL statement described above is shown. In one example, the storage node to which the user is connected can serve as a scheduling node. In other examples, the scheduling node can also be another storage node. In this case, the storage node to which the user is connected needs to send the received data query statement to the scheduling node.
[0046] At 230, at the scheduling node, the distributed execution plan logic is converted into multiple DFOs via the data query engine. For example, the SQL execution plan logic can be converted into multiple DFOs according to SQL semantics. Figure 3 The SQL execution plan shown in can be logically transformed with EXCHANGE OUT operator (sending operator) / EXCHANGE IN operator (receiving operator) as the boundary to obtain three DFOs. Each obtained DFO can include multiple operators executed in series, for example, multiple SQL operators. For example, one DFO includes a scan partition operator, an aggregation operator, and a sending operator, and another DFO includes a collection operator, an aggregation operator, etc. Each SQL operator can be processed in parallel. Specifically, operators 9-11 constitute DFO0, operators 4-8 constitute DFO1, and operators 1-3 constitute DFO2.
[0047] The generated DFO has a tree structure, and there is a hierarchical relationship between DFOs. If the DFO processing result of the second DFO is needed when the first DFO is executed, the first DFO is called the upper-level DFO or the parent DFO, and the second DFO is called the lower-level DFO or the child DFO. After generating the DFO, the scheduling order of the DFO can also be generated. The scheduling order of the DFO can be generated based on the tree structure of the DFO. The scheduling order of the DFO includes the traversal scheduling order of the DFO, that is, the scheduling order determined based on the traversal strategy. In addition, the parallel execution degree of the DFO can also be generated based on the tree structure of the DFO. Here, the term "parallel execution degree" refers to the number of DFOs scheduled in parallel. For Figure 3 In the SQL execution plan shown, the scheduling order of DFO is DFO0→DFO1→DFO2.
[0048] Figure 4A-4E An example schematic diagram showing a tree structure of a distributed logical sub-plan.
[0049] exist Figure 4A In the tree structure shown, the parallel execution degree of DFO is 2, that is, 2 DFOs are executed simultaneously. The scheduling order of DFO is DFO2→DFO1→DFO4→DFO3→DFO8→DFO7→DFO6→DFO5. Figure 4B In the tree structure shown, the parallel execution degree of DFO is 2 or 3, that is, 2 DFOs or 3 DFOs are executed simultaneously. The scheduling order of DFO is DFO4→DFO3→DFO2→DFO1→DFO8→DFO7→DFO6→DFO5. Figure 4C In the tree structure shown, the parallel execution degree of DFO is 2, that is, 2 DFOs are executed at the same time. The scheduling order of DFO is DFO4→DFO2→DFO1→DFO3→DFO8→DFO7→DFO6→DFO5. Figure 4D In the tree structure shown, the parallel execution degree of DFO is 2 or 3, that is, 2 DFOs or 3 DFOs are executed simultaneously. The scheduling order of DFO is DFO4→DFO2→DFO1→DFO10→DFO9→DFO3→DFO8→DFO7→DFO6→DFO5. Figure 4E In the tree structure shown, the parallel execution degree of DFO is 2 or 3, that is, 2 DFOs or 3 DFOs are executed simultaneously. The scheduling order of DFO is DFO10→DFO9→DFO3→DFO4→DFO2→DFO1→DFO8→DFO7→DFO6→DFO5.
[0050] Next, steps 240 to 270 are executed in a loop until the data query result is output.
[0051] Specifically, in each loop process, at 240, it is determined whether the scheduling is completed, that is, whether the scheduling process is completed for all DFOs. If the scheduling process is completed for all DFOs, then at 270, the processing result of the current DFO (that is, Root DFO) is provided to the user as a data query result. If there are still unscheduled DFOs, then at 250, the currently unscheduled DFOs are scheduled to each plan execution node according to the scheduling order. The data query engine of each plan execution node executes the received DFOs in parallel. The parallel execution process of the DFOs of each plan execution node will be referred to below. Figure 5 Next, at 260, after each plan execution node completes the parallel processing for the DFO, it streams back the data to the parent DFO (Patent DFO).
[0052] After the scheduling node schedules the DFO to each plan execution node, each plan execution node will enable one or more idle threads from its own idle thread pool to execute the received DFO in parallel. The threads enabled by each plan execution node can become execution threads. The execution threads enabled by each plan execution node can include one or more threads.
[0053] In some embodiments, the number of execution threads at each plan execution node can be determined according to the data association between the data stored in the plan execution node and the current DFO and the idle thread resources at the plan execution node. In this specification, the term "data association" is used to indicate whether there is an association between the data used when the DFO is executed and the data stored in the plan execution node, for example, whether the used data is the stored data, or whether the used data is obtained based on the stored data. For example, assuming that the execution parallelism of the DFO is 64, each plan execution node needs to enable a total of 64 threads. In this case, if there is a plan execution node with data association with the DFO in the plan execution node, try to select the idle thread in the plan execution node as the execution thread. If there is no plan execution node with data association with the DFO in the plan execution node, the idle thread can be randomly selected from the idle threads in each plan execution node as the execution thread. For example, for a DFO containing a data scanning operator (TABLE SCAN), try to schedule the idle thread in the storage node where the data to be scanned is located. For a DFO that does not contain a data scanning operator, a sufficient number of idle threads can be arbitrarily selected as the execution thread. In addition, in some embodiments, when selecting execution threads, the workload balance of each plan execution node may also be considered, that is, after enabling the execution threads, the workload of the plan execution nodes in the distributed database is kept as load balanced as possible.
[0054] Figure 5An example flow chart of a plan execution method 500 for a distributed database according to an embodiment of the present specification is shown. In the following description, an execution thread enabled by a plan execution node is referred to as a first execution thread, and other execution threads that execute the current DFO together with the first execution thread are referred to as second execution threads. The second execution thread may include at least one execution thread. For example, the second execution thread may include an execution thread located at the same plan execution node as the first execution thread and / or an execution thread located at a different plan execution node from the first execution thread.
[0055] like Figure 5 As shown, at 501, the first execution thread, together with all the second execution threads, receive in parallel the spit-out data returned by the child DFO of the current DFO. Here, the term "parallel reception" means that the first execution thread and the second execution thread simultaneously receive the spit-out data returned by the child DFO. The term "spit-out data" refers to the data that the child DFO needs to provide to the parent DFO for the parent DFO to use for execution. In addition, optionally, in another example, in the case where a storage node processes multiple DFOs in parallel, for example, in the case where there are a data producer DFO for producing data and a data consumer DFO for consuming data in the storage node, the first execution thread, together with all the second execution threads, stream-receives in parallel the spit-out data returned by the child DFO of the current DFO.
[0056] At 502, the first execution thread and each second execution thread respectively determine whether the current DFO contains an execution operator involving a row number generation operation. For example, the execution operators in the current DFO may be traversed to determine whether the current DFO contains an execution operator involving a row number generation operation. Examples of execution operators involving a row number generation operation may include, but are not limited to, a COUNT operator, a SUM operator, and the like.
[0057] In response to the current DFO not including an execution operator involving a row number generation operation, the first execution thread and all the second execution threads execute the current DFO in parallel using the data received by each of them at 503. Subsequently, at 504, the first execution thread and all the second execution threads send the processing result of the current DFO in parallel to the execution thread of the parent DFO scheduled to execute the current DFO.
[0058] In response to the current DFO containing an execution operator involving a row number generation operation, at 505, the first execution thread and each second execution thread cache the received data respectively, and at 506, the first execution thread and each second execution thread respectively send a row number start value acquisition request to the scheduling node, and the row number start value acquisition request sent by each execution thread includes the number of data rows cached by the execution thread.
[0059] In response to receiving a row number start value acquisition request sent by each execution thread, the scheduling node allocates continuously increasing row number start values to the first execution thread and each second execution thread according to the number of cached data rows in the received row number start value acquisition request. The allocated row number start values are allocated and provided to the corresponding execution threads. Among the allocated row number start values, the difference between two adjacent row number start values is not less than the number of data rows cached by the execution thread corresponding to the previous row number start value. In one example, the difference between two adjacent row number start values may be equal to the number of data rows cached by the execution thread corresponding to the previous row number start value. For example, assume there are two execution threads: thread A and thread B. Thread A has 5 rows of data cached, and thread B has 10 rows of data cached, then the row number start value M allocated to thread A is A = 0, and the row number starting value M assigned to thread B A =5.
[0060] At 507, the first execution thread and each second execution thread respectively receive a row number starting value returned in response to a row number starting value acquisition request from the scheduling node, and at 508, the first execution thread and each second execution thread respectively generate a data row number for the cached data according to the received row number starting value.
[0061] After generating data row numbers for the cached data, at 509, the first execution thread, together with each second execution thread, executes the current DFO in parallel using the data with generated data row numbers that they have received, and at 510, the first execution thread, together with each second execution thread, sends the execution result of the current DFO as callback data in parallel to the execution thread of the parent DFO that is scheduled to execute the current DFO, thereby completing the parallel execution processing of the current DFO.
[0062] Figure 6 Shows Figure 2 An example diagram of the data query process is shown in FIG. Figure 6 In the example, when performing data query, the PX Operator in the distributed storage node that receives the data query statement initiated by the user acts as a query coordinator (Query Coordinator, QC). The distributed storage node reserves sufficient thread resources. When the distributed execution plan needs to be executed in parallel, QC determines the degree of parallelism and sends a worker thread acquisition request (QC request) to the sub query coordinator (Sub Query Coordinator, SQC) on each distributed storage node. SQC is a thread on each distributed storage node used to process QC requests. SQC is responsible for applying for execution resources for DFO on the distributed storage node, constructing the execution context environment, etc., and then scheduling worker threads (Worker) to execute DFO in parallel on each storage node, such as Figure 6As shown in , at each QC or SQC, multiple execution threads scheduled in parallel compete for tasks from the scan task queue to execute.
[0063] like Figure 6 As shown, the QC distributes the DFOs that need to be executed in parallel to the appropriate storage nodes in the form of RPC. The SQC in the scheduled storage node schedules the PX thread to execute the received DFO. When the DFOs of each storage node are executed, the execution results are returned to the parent DFO in a streaming manner.
[0064] The following will refer to Figure 7 To describe Figure 3 The DFO execution process of the distributed execution plan shown in Figure 3 In the distributed execution plan shown in , the thread parallelism is 64, that is, for each DFO, 64 threads are enabled simultaneously for parallel execution.
[0065] Figure 3 The distributed execution plan is used to insert data from table t1 into table t2 in parallel and generate row numbers. Figure 3 The distributed execution plan in is divided into three DFOs managed by a PX operator, namely, the above-mentioned DFO0, DFO1 and DFO2. When executing DFO, DFO0 is executed first, followed by DFO1 and DFO2. The execution operator in DFO0 is a data scanning operator (TABLE SCAN), which does not involve a data row number generation operation, thereby enabling 64 execution threads to execute in parallel according to a conventional plan execution method. The return data of DFO0 is provided in parallel to DFO1. The execution operator in DFO1 is a COUNT operator, which involves a data row number generation operation, thereby enabling 64 execution threads to execute in parallel according to a parallel processing method according to an embodiment of the present specification. The return data of DFO1 is provided in parallel to DFO2. The execution operator in DFO2 is a data insertion operator (INSERT), which does not involve a data row number generation operation, thereby enabling 64 execution threads to execute in parallel according to a conventional plan execution method, thereby completing the execution process of the distributed execution plan.
[0066] Using the above-mentioned DFO execution scheme, once a DFO operation that requires generating data row numbers for the data used is encountered, multiple execution threads that execute the DFO in parallel send a row number starting value acquisition request to the scheduling node, and the scheduling node assigns a different row number starting value to each execution thread. Each execution thread uses the assigned row number starting value to generate data row numbers for the locally received data, and then uses the data with generated data row numbers to execute the DFO in parallel, thereby improving the parallel execution performance of the distributed database.
[0067] Figure 8An example block diagram of a data query engine 800 according to an embodiment of the present specification is shown.
[0068] like Figure 8 As shown, the data query engine 800 includes a data query statement receiving device 810, a plan generating device 820, a plan converting device 830, a plan scheduling device 840, a plan executing device 850 and a query result providing device 860.
[0069] The data query statement receiving device 810 is configured to receive data query statements. For example, in one example, the data query may be, for example, a SQL query, and the data query statement may include an SQL statement, such as, for example, the received SQL statement may be, for example, "select t2.a, t2.b, (select sum (c) from t5 where t1.b = t5.a) as sum from t1, t2, t3, t4 where t1.a = 1 and t1.b = t2.a and t1.b = t3.a and t1.b = t4.a". In one example, the data query statement receiving device 810 may be implemented as an input interface, input unit or input device of a data query engine. For example, the data query statement receiving device 810 may be an input box on a client interface of a data query engine, etc.
[0070] The plan generating device 820 is configured to generate a distributed execution plan according to the received data query statement. Examples of the plan generating device 820 may include an optimizer, such as a SQL optimizer. Figure 3 An example diagram of a SQL execution plan is shown.
[0071] The plan conversion device 830 is configured to perform a logical conversion on the distributed execution plan to obtain multiple distributed logical sub-plans (DFOs). In an example, the plan conversion device 830 can obtain multiple DFOs by performing a logical conversion on the distributed execution plan with the data redistribution point as the boundary. In this specification, the term "data redistribution" refers to, for example, a data distribution process of redistributing data from storage node A to storage node B, which can be implemented by operators (for example, Exchange out operator and Exchange in operator) responsible for data sending and data receiving in the distributed execution plan. The splitting of DFO will be split into two DFOs according to the Exchange out operator and the Exchange in operator, wherein one DFO is responsible for sending data after executing all execution operators of this DFO, and the other DFO is responsible for receiving data before executing all execution operators of this DFO. In addition to the Exchange operator, data redistribution can also be implemented using the PX COORD operator. The PX COORD operator is a special Exchange in operator. In addition to having the function of receiving data, it also has the function of scheduling the execution of the sub-DFO.
[0072] The plan scheduling device 840 is configured to schedule multiple DFOs to corresponding plan execution nodes in sequence according to the scheduling order. In response to receiving the DFO, the plan execution device 850 at each plan execution node enables its own execution thread to execute the received DFO in parallel. In response to the end of the DFO scheduling, the query result providing device 860 provides the execution result of the top-level DFO as a data query result to the user.
[0073] Fig. 9 FIG. 9 is a block diagram of a distributed database plan execution device 900 according to an embodiment of the present specification. Fig. 9 As shown, the plan execution device 900 includes a data receiving unit 910, a plan judgment unit 920, a plan execution unit 930 and a data sending unit 940.
[0074] The data receiving unit 910 is configured to receive the return data returned by the sub-DFO of the current DFO in parallel with at least one second execution thread scheduled to execute the current DFO via the first execution thread. The operation of the data receiving unit 910 can refer to the above reference Figure 5 The 501 describes the action.
[0075] The plan determination unit 920 is configured to determine, via the first execution thread, whether the current DFO includes an execution operator involved in a line number generation operation. For example, the plan determination unit 920 can determine whether the current DFO includes an execution operator involved in a line number generation operation by traversing the execution operators in the current DFO. The operation of the plan determination unit 920 can refer to the above reference. Figure 5 The 502 describes the operation.
[0076] The plan execution unit 930 is configured to, in response to the current DFO containing an execution operator involving a row number generation operation, cache the received data and send a row number start value acquisition request to the scheduling node via the first execution thread, wherein the row number start value acquisition request includes the number of cached data rows, and generates a data row number for the cached data according to the row number start value received from the scheduling node, wherein the row number start value is allocated to the first execution thread by the scheduling node in response to the row number start value acquisition request. Then, the current DFO is executed in parallel using the data generated with the data row number received by each of the first execution thread and the second execution thread together. In response to the current DFO not containing an execution operator involving a row number generation operation, the plan execution unit 930 executes the current DFO in parallel using the data received by each of the first execution thread and the second execution thread together.
[0077] The data sending unit 940 is configured to send the execution result of the current DFO as the return data in parallel to the execution thread of the parent DFO scheduled to execute the current DFO via the first execution thread and the second execution thread. The operation of the data sending unit 940 can refer to the above reference Figure 5 The operation described in 510.
[0078] Fig.10 FIG. 1 shows a block diagram of a plan execution unit 1000 according to an embodiment of the present specification. Fig.10 As shown, the plan execution unit 1000 includes a data cache module 1010 , a request sending module 1020 , a row number starting value receiving module 1030 , a row number generating module 1040 and a plan execution module 1050 .
[0079] The data cache module 1010 is configured to cache the received data via the first execution thread in response to the current DFO containing an execution operator involving a row number generation operation. The operation of the data cache module 1010 can refer to the above reference Figure 5 The operation of 505 is described.
[0080] The request sending module 1020 is configured to send a row number start value acquisition request to the scheduling node via the first execution thread. The operation of the request sending module 1020 can refer to the above reference Figure 5 The operation of 506 is described.
[0081] The row number start value receiving module 1030 is configured to receive the row number start value from the scheduling node via the first execution thread. The operation of the row number start value receiving module 1030 can refer to the above reference Figure 5 The operation of 507 is described.
[0082] The row number generation module 1040 is configured to generate a data row number for the cached data according to the received row number starting value via the first execution thread. The operation of the row number generation module 1040 can refer to the above reference. Figure 5 The operation of 508 is described.
[0083] The plan execution module 1050 is configured to execute the current DFO in parallel via the first execution thread and the second execution thread using the data generated with the data row number received by each. The operation of the plan execution module 1050 can refer to the above reference Figure 5 The operation of 509 is described.
[0084] As above Figures 1 to 10 , describes a plan execution method, a plan execution device, a data query method, a data query engine and a distributed database for a distributed database according to an embodiment of this specification. The above plan execution device and data query engine can be implemented by hardware, or by software or a combination of hardware and software.
[0085] Fig.11 FIG. 1 is a schematic diagram of a plan execution device 1100 implemented based on a computer system according to an embodiment of the present specification. Fig.11 As shown, the plan execution device 1100 may include at least one processor 1110, a memory (e.g., a non-volatile memory) 1120, a memory 1130, and a communication interface 1140, and the at least one processor 1110, the memory 1120, the memory 1130, and the communication interface 1140 are connected together via a bus 1160. At least one processor 1110 executes at least one computer-readable instruction stored or encoded in the memory (i.e., the above-mentioned element implemented in the form of software).
[0086] In one embodiment, computer executable instructions are stored in a memory, which when executed cause at least one processor 1110 to: receive in parallel with at least one second execution thread scheduled to execute the current logical sub-plan the return data returned by the child logical sub-plan of the current logical sub-plan; determine whether the current logical sub-plan includes an execution operator involving a row number generation operation; in response to the current logical sub-plan including an execution operator involving a row number generation operation, cache the received data and send a row number start value acquisition request to a scheduling node, wherein the row number start value acquisition request includes the number of cached data rows, generate a data row number for the cached data according to the row number start value received from the scheduling node, wherein the row number start value is allocated to the first execution thread by the scheduling node in response to the row number start value acquisition request, and execute the current logical sub-plan in parallel with the second execution thread using the data generated with the data row number received by each of them; and send in parallel with the second execution thread the execution result of the current logical sub-plan as the return data to the execution thread of the parent logical sub-plan scheduled to execute the current logical sub-plan.
[0087] It should be understood that the computer executable instructions stored in the memory, when executed, cause at least one processor 1110 to perform the above combined operations in various embodiments of the present specification. Figure 1-Figure 10 Describes the various operations and functions.
[0088] Fig.12 FIG. 1 shows a schematic diagram of a data query engine 1200 implemented based on a computer system according to an embodiment of the present specification. Fig.12 As shown, the data query engine 1200 may include at least one processor 1210, a memory (e.g., a non-volatile memory) 1220, a memory 1230, and a communication interface 1240, and the at least one processor 1210, the memory 1220, the memory 1230, and the communication interface 1240 are connected together via a bus 1260. At least one processor 1210 executes at least one computer-readable instruction stored or encoded in the memory (i.e., the above-mentioned element implemented in the form of software).
[0089] In one embodiment, computer executable instructions are stored in a memory, which when executed cause at least one processor 1210 to: receive a data query statement provided by a user; generate a distributed execution plan based on the received data query statement; perform logical transformation on the distributed execution plan to obtain multiple distributed logical sub-plans, wherein the multiple distributed logical sub-plans are formed into a tree structure; schedule the multiple distributed logical sub-plans in sequence to corresponding distributed data storage nodes according to a scheduling order to execute them in parallel as described above; and provide the execution result of the top-level distributed logical sub-plan to the user as a data query result.
[0090] It should be understood that the computer executable instructions stored in the memory, when executed, cause at least one processor 1210 to perform the above combined operations in various embodiments of the present specification. Figure 1-Figure 10 Describes the various operations and functions.
[0091] According to one embodiment, a program product such as a machine-readable medium (e.g., a non-transitory machine-readable medium) is provided. The machine-readable medium may have instructions (i.e., the above-mentioned elements implemented in the form of software), which, when executed by a machine, causes the machine to perform the above-mentioned combination of various embodiments of this specification. Figure 1-Figure 10 Specifically, a system or device equipped with a readable storage medium may be provided, on which a software program code implementing the functions of any of the above-mentioned embodiments is stored, and a computer or processor of the system or device reads and executes the instructions stored in the readable storage medium.
[0092] In this case, the program code itself read from the machine-readable medium can realize the function of any one of the above-mentioned embodiments, and thus the machine-readable code and the machine-readable storage medium storing the machine-readable code constitute a part of the present invention.
[0093] Examples of readable storage media include floppy disks, hard disks, magneto-optical disks, optical disks (such as CD-ROM, CD-R, CD-RW, DVD-ROM, DVD-RAM, DVD-RW, DVD-RW), magnetic tapes, non-volatile memory cards, and ROMs. Alternatively, the program code may be downloaded from a server computer or a cloud via a communication network.
[0094] According to one embodiment, a computer program product is provided. The computer program product includes a computer program. When the computer program is executed by a processor, the processor performs the above combination of the various embodiments of this specification. Figure 1-Figure 10 Describes the various operations and functions.
[0095] Those skilled in the art should understand that the various embodiments disclosed above can be modified and altered in various ways without departing from the essence of the invention. Therefore, the protection scope of the present invention should be defined by the appended claims.
[0096] It should be noted that not all steps and units in the above-mentioned processes and system structure diagrams are necessary, and some steps or units can be ignored according to actual needs. The execution order of each step is not fixed and can be determined as needed. The device structure described in the above-mentioned embodiments can be a physical structure or a logical structure, that is, some units may be implemented by the same physical entity, or some units may be implemented by multiple physical entities, or some components in multiple independent devices may be implemented together.
[0097] In the above embodiments, the hardware unit or module can be realized by mechanical or electrical means. For example, a hardware unit, module or processor can include permanent dedicated circuit or logic (such as special processor, FPGA or ASIC) to complete the corresponding operation. The hardware unit or processor can also include programmable logic or circuit (such as general-purpose processor or other programmable processor), which can be temporarily set by software to complete the corresponding operation. Specific implementation (mechanical method or dedicated permanent circuit or temporary circuit) can be determined based on cost and time consideration.
[0098] The specific embodiments described above in conjunction with the accompanying drawings describe exemplary embodiments, but do not represent all embodiments that can be implemented or fall within the scope of protection of the claims. The term "exemplary" used throughout this specification means "used as an example, instance or illustration" and does not mean "preferred" or "having advantages" over other embodiments. For the purpose of providing an understanding of the described technology, the specific embodiments include specific details. However, these technologies can be implemented without these specific details. In some instances, in order to avoid making the concepts of the described embodiments difficult to understand, well-known structures and devices are shown in block diagram form.
[0099] The above description of the present disclosure is provided to enable any person of ordinary skill in the art to implement or use the present disclosure. Various modifications to the present disclosure will be apparent to those of ordinary skill in the art, and the general principles defined herein may be applied to other variations without departing from the scope of protection of the present disclosure. Therefore, the present disclosure is not limited to the examples and designs described herein, but is consistent with the widest range of principles and novel features disclosed herein.
Claims
1. A method for executing a logical sub-plan of a distributed database, the method being executed by a first execution thread at a plan execution node, the method comprising: Together with at least one second execution thread scheduled to execute the current logical sub-plan, receiving in parallel the return data returned by the sub-logical sub-plan of the current logical sub-plan; Determining whether the current logical sub-plan includes an execution operator involving a row number generation operation; In response to the current logical sub-plan including an execution operator involving a row number generation operation, Cache the received data and send a row number start value acquisition request to the scheduling node, wherein the row number start value acquisition request includes the number of cached data rows. generating a data row number for the cached data according to a row number start value received from the scheduling node, the row number start value being assigned to the first execution thread by the scheduling node in response to the row number start value acquisition request, Together with the second execution thread, executing the current logical sub-plan in parallel using the data generated with data row numbers respectively received; as well as Together with the second execution thread, the execution result of the current logical sub-plan is sent in parallel as the return data to the execution thread of the parent logical sub-plan scheduled to execute the current logical sub-plan, Among them, the scheduling node obtains the number of cached data rows in the request according to the row number starting values received from the first execution thread and the second execution thread, allocates continuously increasing row number starting values to the first execution thread and each second execution thread, and the difference between two adjacent row number starting values is not less than the number of data rows cached by the execution thread corresponding to the previous row number starting value.
2. The method of claim 1, further comprising: In response to the current logical sub-plan not including an execution operator involving a row number generation operation, the current logical sub-plan is executed in parallel together with the second execution thread using the respectively received data.
3. The method of claim 1, wherein: Determining whether the current logical sub-plan includes an execution operator involving a row number generation operation includes: The execution operators in the current logical sub-plan are traversed to determine whether the current logical sub-plan includes an execution operator involving a row number generation operation.
4. The method of claim 1, wherein: The second execution thread includes an execution thread located at the same planned execution node as the first execution thread and / or an execution thread located at a different planned execution node than the first execution thread.
5. The method of claim 4, wherein: The number of execution threads at each plan execution node is determined according to the data association between the data stored in the plan execution node and the current logical sub-plan and the idle thread resources at the plan execution node.
6. A method for performing data query in a distributed database, comprising: Receive data query statements provided by users; Generate a distributed execution plan according to the received data query statement; Performing logical transformation on the distributed execution plan to obtain a plurality of distributed logical sub-plans, wherein the plurality of distributed logical sub-plans are formed into a tree structure; Scheduling the multiple distributed logical sub-plans to corresponding distributed data storage nodes in sequence according to a scheduling order for parallel execution according to the method described in any one of claims 1 to 5; as well as The execution result of the top-level distributed logical sub-plan is provided to the user as a data query result.
7. The method of claim 6, wherein: The scheduling order of the distributed logical sub-plans is determined according to the tree structure of the distributed logical sub-plans.
8. A device for executing a logical sub-plan of a distributed database, the distributed database comprising a plurality of distributed storage nodes, the device being applied to a first distributed storage node acting as a plan execution node, the device comprising: A data receiving unit receives, via a first execution thread at the first distributed storage node, the return data returned by the sub-logical sub-plan of the current logical sub-plan in parallel with at least one second execution thread scheduled to execute the current logical sub-plan; A plan determination unit, via the first execution thread, determines whether the current logical sub-plan includes an execution operator involving a row number generation operation; a plan execution unit, in response to the current logical sub-plan including an execution operator involving a row number generation operation, caching the received data and sending a row number start value acquisition request to a scheduling node via the first execution thread, wherein the row number start value acquisition request includes the number of cached data rows, generating data row numbers for the cached data according to the row number start value received from the scheduling node, wherein the row number start value is allocated to the first execution thread by the scheduling node in response to the row number start value acquisition request, and executing the current logical sub-plan in parallel with the second execution thread using the data with generated data row numbers respectively received; as well as The data sending unit, through the first execution thread, together with the second execution thread, sends the execution result of the current logical sub-plan as the return data in parallel to the execution thread of the parent logical sub-plan scheduled to execute the current logical sub-plan, Among them, the row number starting values corresponding to the data at the first execution thread and each second execution thread are allocated by the scheduling node according to the number of cached data rows in the request obtained by the row number starting values received from the first execution thread and the second execution thread, the row number starting values received by the first execution thread and each second execution thread increase continuously, and the difference between two adjacent row number starting values is not less than the number of data rows cached by the execution thread corresponding to the previous row number starting value.
9. The device of claim 8, wherein: In response to the current logical sub-plan not including an execution operator involving a row number generation operation, the plan execution unit executes the current logical sub-plan in parallel via the first execution thread and the second execution thread using the data received by each.
10. The device of claim 8, wherein: The plan execution unit comprises: a data caching module, in response to the current logical sub-plan including an execution operator involving a row number generation operation, caching the received data via the first execution thread; A request sending module, sending a row number start value acquisition request to a scheduling node via the first execution thread; A row number start value receiving module, receiving a row number start value from the scheduling node via the first execution thread; a row number generating module, generating a data row number for the cached data according to the received row number starting value via the first execution thread; and The plan execution module, through the first execution thread and the second execution thread, executes the current logical sub-plan in parallel using the data generated with data row numbers received by each of them.
11. The device of claim 8, wherein: The plan determination unit traverses the execution operators in the current logical sub-plan to determine whether the current logical sub-plan includes an execution operator involving a row number generation operation.
12. A data query engine for performing data query in a distributed database, the distributed database comprising a plurality of distributed data storage nodes, each distributed data storage node comprising a data query engine and a data storage engine, the data query engine comprising: A query statement receiving device receives a data query statement provided by a user; plan generating device; Generate a distributed execution plan according to the received data query statement; Plan conversion device; Performing logical transformation on the distributed execution plan to obtain a plurality of distributed logical sub-plans, wherein the plurality of distributed logical sub-plans are formed into a tree structure; A planning and scheduling device, which sequentially schedules the multiple distributed logical sub-plans to corresponding distributed data storage nodes according to a scheduling order; An apparatus for executing a logical sub-plan of a distributed database as claimed in any one of claims 8 to 11; as well as The query result providing device provides the execution result of the top-level distributed logical sub-plan as the data query result to the user.
13. A distributed database comprising: At least two distributed storage nodes, each storage node comprises a data storage engine and a data query engine as claimed in claim 12.
14. A planning and scheduling device for a distributed database, comprising: at least one processor, a memory coupled to the at least one processor, and A computer program stored in the memory, wherein the at least one processor executes the computer program to implement the method according to any one of claims 1 to 5.
15. A data query engine for a distributed database, comprising: at least one processor, a memory coupled to the at least one processor, and A computer program stored in the memory, the at least one processor executing the computer program to implement the method according to claim 6 or 7.
16. A computer-readable storage medium storing executable instructions, which, when executed, cause a processor to execute the method according to any one of claims 1 to 5 or the method according to claim 6 or 7.
17. A computer program product, comprising a computer program, wherein the computer program is executed by a processor to implement the method according to any one of claims 1 to 5 or to perform the method according to claim 6 or 7.
Citation Information
Patent Citations
Method and device of processing data by distributed algorithm
CN107870813A
SQL query method and device for distributed database
CN113934763A