Method and application for accelerating execution of gpu operators in a heterogeneous database system

Abstract

The application discloses a method for accelerating GPU operator execution in a heterogeneous database system, which judges whether fusion of a specific operator combination is needed in a query optimization stage, and executes according to a query optimization scheme in a query execution stage. The method comprises the following steps: obtaining a query plan generated by a heterogeneous database system based on a traditional database for a query statement; deciding whether a special execution plan generation strategy is considered according to whether a GPU operator is used; judging whether fusion is effective and deciding whether an operator is placed on a GPU by considering an operator cost of the fused operator for the operator in the specific operator combination through a cost estimation method; selecting a specific fusion execution strategy after deciding that the operator in the specific combination is placed on the GPU; and executing the query plan according to the fusion execution strategy by the heterogeneous database system. The application further discloses application of the method in accelerating GPU operator execution in the heterogeneous database system.

Description

Technical Field

[0001] This invention belongs to the field of heterogeneous database technology, and relates to a GPU operator acceleration technology applied to heterogeneous database systems, and particularly to a method and application of integrating GPU operator execution in heterogeneous databases. Background Technology

[0002] With the development of hardware and software technologies, the scale of data continues to grow, and traditional databases with CPUs as the computing core are increasingly unable to cope with the ever-increasing volume of data. Therefore, a number of heterogeneous databases have emerged to accelerate large-scale data processing and analysis. Among them, heterogeneous database systems based on traditional databases retain friendly support for transactional workloads while improving the processing performance for analytical workloads. Common heterogeneous database system architectures include... Figure 1 As shown, traditional databases typically use interpreted execution to execute query statements. In this context, when heterogeneous database systems execute queries, computationally intensive operators are rewritten as GPU operators. Since the database call logic resides on the CPU, while the GPU primarily handles the operator computation, data needs to be copied from memory to GPU memory before GPU computation, and then copied back from GPU memory for use by the next operator. Therefore, when a query plan includes multiple GPU operators, data is copied back and forth between memory and GPU memory. This results in redundant data transfer between heterogeneous devices. Furthermore, frequent startup of CUDA kernel functions incurs significant startup costs. Both of these factors negatively impact query execution efficiency. Operator fusion can reduce the back-and-forth data transfer between heterogeneous devices and the number of kernel function startups.

[0003] Existing heterogeneous database systems based on traditional databases only support basic operator fusion schemes such as "scan-join," "scan-aggregate," and "scan-join-aggregate," without considering operator combinations that arise after subqueries in query statements have been rewritten. For example, TPC-H Q18 contains subqueries... Figure 2 This paper demonstrates the execution plan of a traditional database after rewriting a subquery, which includes a combination of "Scan-Agg-Join" operators. If these operators are executed on a GPU, heterogeneous database systems lack corresponding operator fusion strategies to integrate them, thus impacting query efficiency. Therefore, existing operator fusion strategies in heterogeneous database systems neglect the special scenario of subqueries, where new operator combinations emerge after query rewriting. The technical implementation needs to consider how to identify these new operator combinations and the complexity of the engineering implementation. Summary of the Invention

[0004] In order to solve the problems in the prior art, the purpose of the present application is to provide a method for accelerating GPU operator execution in a heterogeneous database system, so as to improve the overall performance of the query.

[0005] The specific technical solution for achieving the purpose of the present application is:

[0006] The present application provides a method for accelerating GPU operator execution in a heterogeneous database system, which relates to a fusion strategy for GPU operator execution in a heterogeneous database. Through the fusion strategy, the execution of multiple GPU operators can be fused, and the copying of data between memory and video memory can be reduced. The heterogeneous database system is based on a traditional database and is a collection of multiple related databases.

[0007] Specifically, executing a query task in a heterogeneous database system includes three stages of query parsing, query optimization, and query execution. The method of the present application determines whether to fuse a specific operator combination in the query optimization stage, and performs the query according to the query optimization scheme in the query execution stage, so as to accelerate the execution of the GPU operator. The specific steps include:

[0008] Step S1: obtaining a query plan generated by a heterogeneous database system based on a traditional database for a query statement;

[0009] Step S2: determining whether to consider a special execution plan generation strategy according to whether a GPU operator is used or not. If a GPU operator is used, a special execution plan generation strategy is considered. If a GPU operator is not used, a special execution plan generation strategy is not considered.

[0010] Step S3: using a cost estimation method to consider the cost of the fused operator in a specific operator combination to determine whether the fusion is effective and whether to place the operator on the GPU.

[0011] Step S4: after determining to place the operator in a specific combination on the GPU, selecting a specific fusion execution strategy.

[0012] Step S5: the heterogeneous database system executes the execution plan according to the fusion execution strategy.

[0013] In the present application, the traditional database and the heterogeneous database system used in step S1 are selected according to actual needs. The traditional database includes PostgreSQL, openGauss, and DB2, and the heterogeneous database system includes PG-Strom and DB2with BLU.

[0014] In step S1, the query plan in the heterogeneous database is a query plan generated by a traditional database for a heterogeneous database system, that is, a set of steps executed to complete a query. The query plan generated by the traditional database only contains CPU operators. The query plan generated by the heterogeneous database system contains heterogeneous operators, that is, contains CPU operators and GPU operators.

[0015] In the present application, the GPU used in step S2 is one or more of a physical GPU or a virtual GPU, and the GPU operator runs on a GPU device. The physical GPU refers to a real GPU, and the virtual GPU refers to a GPU that is perceived as a separate GPU in use and is actually a GPU shared by multiple users, which can be obtained by providing a cloud vendor with a GPU cloud host. In recent years, popular heterogeneous database systems almost all use GPUs of Nvidia and are developed based on the programming model CUDA, considering the ecology of the GPU programming model, the development speed, and the iteration speed of new features. Therefore, the GPU used in the present application is preferably a GPU produced by Nvidia.

[0016] In step S2, the special execution plan generation strategy is to generate an execution plan by considering the cost after fusion for a specific operator combination. Generally, the higher the cost, the longer the execution time, but the cost cannot be simply considered as time-consuming.

[0017] The specific operator combination is an operator combination that occurs after query rewriting of a subquery. The query rewriting is an equivalent logical transformation of the original query, which converts the SQL statement input by the user into a more efficient equivalent SQL statement. Query rewriting follows two basic principles, equivalence and efficiency. Common query rewriting techniques include constant folding, subquery promotion, etc. Constant folding refers to pre-computing the result of a constant expression before executing the SQL statement to improve efficiency, such as rewriting a <2*3 to a <6. Subqueries are easier for developers to understand, but not efficient in execution, so the database will eliminate the subquery through subquery promotion technology to rewrite the statement containing the subquery into a join statement or independently calculate the subquery content to achieve the same function of the query. Through equivalent transformation of the original query, a more optimal execution effect can be achieved. The specific operator combination includes aggregation-join operators, scan operator-aggregation operator-join operator, scan-aggregation-join-aggregation operator, etc. Compared with existing operator combinations, the above specific operator combinations after query rewriting will differ in engineering implementation complexity.

[0018] In step S2, if the GPU operator is not used, the original execution plan generation strategy is used.

[0019] In the present application, in step S3, the cost estimation method refers to obtaining statistical information provided by the database kernel, such as the number of table tuples, selection rate, table row number, tuple length, and information related to columns and indexes, and estimating the execution cost of the GPU operator by calculating the CPU cost, IO cost, and additional data transmission cost between the main memory and the video memory of the heterogeneous database. Taking the GPU join operator as an example, the number of tuples and the data size of the two tables participating in the join are obtained by the method provided by the database, and the calculation cost of the operator is estimated by multiplying the number of tuples by the calculation cost coefficient set according to the empirical value; the data transmission cost between the main memory and the video memory is estimated by multiplying the data size of the table by the data transmission cost coefficient. The sum of the costs to be considered is the cost of the operator.

[0020] In the judgment of whether the fusion is effective, different operator costs can be estimated according to the different data volumes involved in data transmission and calculation before and after fusion. If the operator cost after fusion is less than the operator cost before fusion, it is considered that the fusion is effective, and at this time the GPU operator is fused and placed on the GPU.

[0021] In step S3, if the operator cost after fusion is greater than the operator cost before fusion, the operator fusion is not performed, and the query plan is directly executed.

[0022] In the present application, in step S4, the specific fusion execution strategy corresponds to a specific operator combination, and the multiple operators in the specific operator combination are bound together for execution.

[0023] For example, when the query plan appears a scan operator-aggregation operator-join operator, the three GPU operators are fused and executed, that is, the data is fixed in the video memory during the operator execution process, and will not be copied back to the main memory. Other operator combinations are the same.

[0024] In the present application, in step S5, the execution plan is an execution scheme finally containing the specific implementation of the operator and the placement position of the operator.

[0025] The present application also provides an application of the above method in accelerating the execution of GPU operators in a heterogeneous database system.

[0026] The beneficial effects of the present application include:

[0027] Compared with the prior art, the present application has obvious advantages and beneficial effects. By the above technical scheme, the method for accelerating the execution of GPU operators in a heterogeneous database system provided by the present application can achieve considerable technical progress and practicality, and has wide industrial utilization value, and at least has the following advantages:

[0028] The method of the present application is based on a heterogeneous database system, and is oriented to the operator combination after subquery rewriting. More operator combinations that can be fused can be found through the means of subquery rewriting, the types of queries that can be fused are expanded, and for query statements containing subqueries, the data after operator fusion is continuously operated on the GPU by multiple operators, reducing redundant data transmission and reducing the startup cost of CUDA kernel functions, so as to improve the overall query performance. In addition, through this method, if more GPU operators are implemented, the number of operator combinations that can be fused can be increased. BRIEF DESCRIPTION OF DRAWINGS

[0029] Figure 1 A heterogeneous database system architecture of an embodiment of the present application;

[0030] Figure 2 A sample query plan diagram of TPC-H Query-18 involved in the prior art;

[0031] Figure 3 A flowchart of the method for accelerating GPU operator execution of the present application. DETAILED DESCRIPTION

[0032] The present application will be further described in conjunction with the following specific examples and drawings. The process, conditions, experimental methods, etc. for implementing the present application are the general knowledge and common sense in the art, and the present application does not have special restrictions.

[0033] Some exemplary embodiments are described as processes or methods depicted as flowcharts. Although the flowcharts depict the steps in a particular order, many of the steps can be performed in parallel, concurrently, or at the same time. In addition, the order of the steps can be re-arranged. The process can be terminated when its operations are completed, but can also have additional steps not included in the figure. The process can correspond to a method, function, routine, subroutine, or the like.

[0034] With the development of hardware and software technology, the scale of data is growing, and the traditional database with CPU as the computing core is increasingly unable to cope with the growing large-scale data. Therefore, a batch of heterogeneous databases for accelerating large-scale data processing and analysis has emerged. The heterogeneous database system based on the traditional database not only retains the friendly support for transactional load, but also improves the processing performance of analytical load. Common heterogeneous database system architectures are as follows Figure 1As shown, it includes a query parsing module, a query optimization module, a query execution module, a storage management module and a GPU function extension module. A traditional database usually executes a query statement in an interpretive execution mode. Under this premise, when the heterogeneous database system executes a query, the computationally intensive operators are rewritten into GPU operators. Since the database calling logic is on the CPU side, when the query plan contains multiple GPU operators, redundant data transmission occurs between the heterogeneous devices. In addition, frequent launching of CUDA kernel functions will bring significant launch overhead. Both of them will affect the execution efficiency of the query. Operator fusion can reduce the data transmission between the heterogeneous devices and the number of kernel function launches.

[0035] The existing heterogeneous database system based on a traditional database only supports basic operator fusion schemes such as "scan-join", "scan-aggregation" and "scan-join-aggregation", and does not consider the operator combination after the subquery in the query statement is rewritten through query rewriting. For example, TPC-H Q18 contains a subquery, Figure 2 The traditional database shows the query plan after rewriting the subquery thereof, and the "scan-aggregation-join" operator combination appears in the plan. If these operators are executed in the GPU, the heterogeneous database system cannot fuse these operators due to the lack of a corresponding operator fusion strategy, thereby affecting the query efficiency. Therefore, the operator fusion strategy in the existing heterogeneous database system ignores the new combination after the subquery is rewritten through query rewriting. Therefore, how to perform GPU operator fusion for the new combination after the subquery is rewritten through query rewriting becomes a technical problem to be solved.

[0036] To solve the above technical problem, an embodiment of the present application provides a method for accelerating GPU operator execution in a heterogeneous database system. The core idea of the method is to generate a query plan with the help of a heterogeneous database, and to decide whether to consider a special execution plan generation strategy according to whether a GPU operator is used, to select whether an operator should be placed in the GPU from bottom to top, to judge whether fusion is effective by a cost estimation method when deciding whether to place an operator in the GPU for the operator combination (such as scan-aggregation-join) after the subquery is rewritten, and finally to execute the operators in the specific operator combination by using a corresponding fusion strategy. By using the method, the data transmission overhead across the heterogeneous devices and the overhead of launching the CUDA kernel function can be effectively reduced, and the execution efficiency of the query can be improved.

[0037] Figure 3 A flowchart of a method for accelerating GPU operator execution by fusing specific GPU operator combinations in a heterogeneous database system based on a traditional database according to an embodiment of the present application. The method comprises:

[0038] Step S1, the heterogeneous database system accepts the query statement of the user, carries out the lexical and syntax analysis to generate the abstract syntax tree and carries out the preliminary rewriting according to the rules (such as projection elimination, predicate pushdown, etc.) to generate the query plan.

[0039] As an example, Figure 2 The preliminary query plan generated by the heterogeneous database system PG-Strom with the help of PostgreSQL. The query plan is a logical query plan, that is, it does not involve the specific implementation of the operator and the placement position.

[0040] Step S2, the query plan decides whether to consider the special execution plan generation strategy according to whether the GPU operator is used or not.

[0041] Step S3, by the method of cost estimation, the operator in the specific operator combination is considered to judge whether the fusion is effective and whether the operator is placed on the GPU according to the operator cost after the fusion.

[0042] As an embodiment, the specific operator combination is the new operator combination generated by rewriting the subquery, such as Figure 2 The "scan-aggregation-join" operator combination in the above.

[0043] It should be noted that the determination order of the specific implementation of the operator and the placement position is from bottom to top. In the determination process, if the operator in the specific operator combination appears, since the fusion can reduce the data transmission and the cost of starting the CUDA kernel function, the lower operator cost after the fusion needs to be considered to determine the specific implementation of the operator and the placement position. Among them, the estimation of the operator cost is carried out with the help of the statistical information in the database system (such as the number of rows of the table, the tuple length, and the related information of the column and the index, etc.).

[0044] Step S4, after deciding to place the operator in the specific combination on the GPU, the specific fusion execution strategy is selected.

[0045] As an embodiment, the specific fusion execution strategy corresponds to the specific operator combination, that is, the fusion execution strategy for the new operator combination after the rewriting of the subquery.

[0046] Step S5, the heterogeneous database system executes the execution plan according to the fusion execution strategy.

[0047] The method disclosed in the application is based on the heterogeneous database system, and by facing the operator combination after the rewriting of the subquery, the fusible operator combination is expanded, the query type that can be fused is expanded, for the query statement containing the subquery, the redundant data transmission and the starting cost of the CUDA kernel function can be reduced, so as to achieve the purpose of improving the overall query performance.

[0048] As an embodiment, the embodiment of the present application can be applied to a heterogeneous database system such as PG-Strom in a series of traditional databases developed based on a PostgreSQL kernel.

[0049] After the heterogeneous database system based on the traditional database equipped with the GPU card-based server is deployed and started, the user sends a query statement to the server through the client. After the server receives the query statement, a series of operations are performed on the query statement until the query result is obtained and returned to the client. The series of operations include lexical syntax analysis, query optimization, and query execution. The method of the present application judges whether the fusion of a specific operator combination is needed in the query optimization stage, and then executes according to the corresponding execution strategy in the query execution stage.

[0050] The protection scope of the present application is not limited to the above embodiments. Changes and advantages that can be thought of by those skilled in the art without departing from the spirit and scope of the present application are included in the present application, and are protected by the appended claims.

Claims

1. A method for accelerating GPU operator execution in a heterogeneous database system, characterized in that, The method includes the following steps: Step S1: Obtain the query plan generated by the heterogeneous database system based on the traditional database for the query statement; Step S2: The query plan determines whether to consider a special execution plan generation strategy based on whether GPU operators are used; If GPU operators are used, a special execution plan generation strategy is considered; if GPU operators are not used, no special execution plan generation strategy is considered. In step S2, the GPU is one or more of a physical GPU or a virtual GPU, and the GPU operator runs on the GPU device; the physical GPU is a physical GPU, and the virtual GPU refers to a GPU provided by a cloud provider with a GPU cloud host and shared by multiple users. The specific execution plan generation strategy generates an execution plan by considering the cost of fusion for specific operator combinations; the specific operator combination is the combination of operators that appears after the subquery is rewritten; the query rewriting refers to performing an equivalent transformation on the query based on optimization rules to achieve better execution results; the specific operator combination includes aggregation-join operator, scan operator-aggregation operator-join operator, and scan-aggregation-join-aggregation operator. Step S3: Using cost estimation, for a specific combination of operators, consider the cost of the fused operators to determine whether the fusion is effective and whether to place the operators on the GPU. In step S3, the cost estimation method refers to obtaining statistical information provided by the database kernel and estimating the execution cost of the GPU operator by considering the CPU computation cost, IO cost, and the additional data transfer cost in video memory and main memory required for heterogeneous databases; the statistical information includes the number of tuples in the table, selectivity, number of rows in the table, tuple length, and column and index information; Step S4: After deciding to place the operators in a specific combination on the GPU, select the specific fusion execution strategy; Step S5: The heterogeneous database system runs the execution plan according to the fusion execution strategy.

2. The method as described in claim 1, characterized in that, In step S1, the traditional databases include PostgreSQL, openGauss, and DB2, and the heterogeneous database systems include PG-Strom and DB2 with BLU. The query plan in the heterogeneous database is a query plan generated by the heterogeneous database system with the help of a traditional database, that is, a set of steps to be executed in order to complete the query; the query plan generated by the heterogeneous database system includes heterogeneous operators, that is, CPU operators and GPU operators.

3. The method as described in claim 1, characterized in that, The query rewriting process transforms the original query into a more efficient equivalent SQL statement by performing an equivalent logical transformation. The query rewriting process adheres to the principles of equivalence and efficiency, and achieves better execution results through query rewriting techniques including constant folding and subquery lifting. The term "constant folding" refers to pre-calculating the result of a constant expression before executing an SQL statement. Subquery lifting refers to rewriting a statement containing a subquery into a join statement or independently calculating the subquery content to achieve the same query functionality as before the rewrite.

4. The method as described in claim 1, characterized in that, In step S3, when determining whether the fusion is effective, the different operator costs are estimated based on the different amounts of data involved in data transmission and computation before and after fusion. If the cost of the fused operator is less than the cost of the operator before fusion, the fusion is considered effective. At this time, the GPU operators are fused and placed on the GPU.

5. The method as described in claim 1, characterized in that, In step S4, the specific fusion execution strategy corresponds to a specific combination of operators, which binds multiple operators in the specific combination of operators together for execution.

6. The method as described in claim 1, characterized in that, In step S5, the execution plan is the final execution scheme that includes the specific implementation of the operator and the placement of the operator.

7. The application of the method as described in any one of claims 1-6 in accelerating the execution of GPU operators in heterogeneous database systems.

Images