A method and apparatus for database query based on computational memory

Abstract

The application relates to the technical field of databases, in particular to a database query method and device based on a computable storage. The method comprises the following steps: integrating heterogeneous hardware capable of processing computationally-intensive operators on a computing storage device to expand the operator support range; receiving and analyzing an SQL query statement to generate a query plan tree; determining the execution position of each node in the query plan tree; if the execution position of the node is the computing storage device, converting the query semantics corresponding to the node into at least one offload instruction recognizable by the computing storage device, wherein the offload instruction defines the data-level operation of the computing storage device to execute the node; generating an intermediate processing result by performing the data-level operation according to the offload instruction by the heterogeneous hardware, completing the final query based on the intermediate processing result, and returning the obtained query result to the user. The application can expand the operator offload range of the computing storage device and reduce the query delay.

Description

Technical Field

[0001] This invention relates to the field of database technology, and in particular to a database query method and apparatus based on a computable memory. Background Technology

[0002] As data volumes rapidly increase from gigabytes (GB) to terabytes (TB) and even petabytes (PB), the traditional Von Neumann architecture-based computing and storage separation model of database systems is increasingly revealing severe input / output (I / O) bottlenecks. Specifically, when executing analytical queries, large amounts of data must be loaded from storage devices into host memory for processing. Even if the final result set is small, all data must be moved, leading to increased PCIe (Peripheral Component Interconnect Express) bandwidth pressure, increased CPU load, and increased energy consumption. To overcome I / O bottlenecks, compute-based storage emerged as a revolutionary Processing-In-Memory (PIM) technology. With the rapid evolution of storage technology, compute-based storage has evolved from early prototype systems based on Hard Disk Drives (HDDs) to modern architectures based on Solid State Drives (SSDs), thus providing higher internal bandwidth and lower access latency. Its core idea is to offload some computing tasks from the host CPU to the storage device for direct execution. By performing data-intensive operations such as filtering and aggregation on the data source side, the compute-based storage device only needs to send the processed intermediate or final results back to the host, thereby reducing I / O bottlenecks.

[0003] To improve database query speed, various hardware implementations for in-memory processing have been explored. The main goal of these efforts is to reduce data movement by utilizing the bandwidth within or near the storage device to execute part of the query processing logic closer to the data. These hardware options include embedded processors and Field-Programmable Gate Arrays (FPGAs). Embedded processors are typically used as general-purpose computing units; for example, integrating an ARM (Advanced RISC Machine) core or other low-power CPU into the storage device offloads some query execution tasks to the storage layer. This approach offers a degree of flexibility while maintaining relatively low implementation complexity. FPGAs, with their reconfigurable characteristics, can build customized operator pipelines and achieve high throughput and high energy efficiency, thus finding widespread application in in-memory processing.

[0004] However, existing in-memory processing solutions based on embedded processors or FPGAs still have significant limitations in terms of operator offloading range and execution efficiency. Summary of the Invention

[0005] In view of the above-mentioned defects or improvement needs of the prior art, the present invention proposes a database query method and apparatus based on a computational memory, which can expand the operator offloading range of the computational storage device and reduce query latency.

[0006] The embodiments of the present invention adopt the following technical solutions: In a first aspect, the present invention provides a database query method based on a computable memory, specifically: integrating heterogeneous hardware capable of processing computationally intensive operators into a computing storage device to expand the operator support range of the computing storage device; Receive and parse the SQL query statement submitted by the user, generate the corresponding query plan tree; determine the execution position of each node in the query plan tree; If the execution location of the node is a compute storage device, then the query semantics corresponding to the node are converted into at least one unload instruction that the compute storage device can recognize, wherein the unload instruction defines the compute storage device performing data-level operations on the node; The heterogeneous hardware performs data-level operations according to the unloading instructions to generate intermediate processing results, completes the final query based on the intermediate processing results, and returns the obtained query results to the user.

[0007] Preferably, the method further includes: Traverse the query plan tree and identify at least one unloadable operator in the query plan tree based on a predefined unloadable operator metadata table; Traverse the query plan tree from bottom to top, merging unloadable operators that satisfy the constraints of the compute storage device in turn, until an operator that does not satisfy the constraints of the compute storage device is encountered, thereby splitting at least one unload subtree, in which all nodes in each unload subtree are assigned to the compute storage device for execution.

[0008] Preferably, the method further includes: For the query plan tree, the host-side query optimizer is used to generate multiple candidate execution plans; For each candidate execution plan, identify the unloadable operators in the candidate execution plan, and generate multiple unloadable subtrees by enumerating unloadable combinations of unloadable operators, wherein the unloadable combination includes at least one unloadable operator; For each unloading subtree, a high-dimensional vector is constructed based on the task characteristics of the unloading subtree and the real-time resource characteristics of the computable memory, wherein the task characteristics include at least the execution cost of the unloading subtree under ideal load conditions of the computable memory. The high-dimensional vector is input into the trained prediction model to obtain the profit prediction value of each unloading subtree. The unloading subtree with the largest profit prediction value is selected as the optimal unloading subtree, and the optimal unloading subtree is allocated to the computing storage device for execution.

[0009] Preferably, the method further includes: For an unloading subtree, the cost items included in the calculation formula of the execution cost of each operator are determined according to the operation characteristics and data dependency pattern of each operator in the unloading subtree. The parameter values ​​in the cost item are determined by combining the query semantics of the SQL query statement; Calculate the execution cost of each operator based on the cost item and the parameter value; The execution cost of each operator is organized into a tree structure to obtain a column vector, which is then used as the execution cost of the unloading subtree.

[0010] Preferably, the operator execution cost calculation formula is as follows: ; in, This represents the total execution cost of the operator. This indicates the data retrieval latency of the underlying storage medium. Indicates the data transfer latency required for execution. This indicates the computation delay.

[0011] Preferably, the method further includes: The unloading subtree is decomposed into multiple subtasks using a bottom-up approach. Based on the predefined middleware metadata table, the query semantics corresponding to each subtask are converted into task vectors that can be recognized by the computing storage device; The computational resource requirements of each subtask are analyzed based on the task vector, and the heterogeneous hardware is determined for each subtask according to the available resources of the currently idle heterogeneous hardware. The task vector and the identifier corresponding to the heterogeneous hardware are encapsulated to obtain the unload instruction corresponding to each subtask.

[0012] Preferably, the step of converting the query semantics corresponding to each subtask into a task vector that can be recognized by the computing storage device according to a predefined middleware metadata table includes: Identify the core operators, physical execution units, and parameter configurations in the subtasks; The encodings corresponding to the core operators, physical execution units, and parameter configurations are determined based on the middleware metadata table. According to the execution order of the subtasks, the codes corresponding to the core operators, physical execution units, and parameter configurations are sequentially combined into a task vector.

[0013] Preferably, the method further includes: Receive and parse the unload command to obtain the task vector and the corresponding identifier of the heterogeneous hardware; pre-configure resources according to the data-level operations in the task vector; According to the identifier of the heterogeneous hardware, the subtask is assigned to the corresponding heterogeneous hardware for execution and the calculation result is output. Post-process the calculation results to obtain intermediate processing results, and release the allocated resources.

[0014] In a second aspect, the present invention provides a database query apparatus based on a computable memory, the apparatus comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the processor to perform the database query method based on a computable memory in the first aspect.

[0015] Thirdly, the present invention also provides a non-volatile computer storage medium storing computer-executable instructions that are executed by one or more processors to perform the database query method based on computable memory described in the first aspect.

[0016] Compared with the prior art, the beneficial effects of the present invention are as follows: It integrates heterogeneous hardware capable of processing computationally intensive operators on a computing storage device, utilizes the parallel computing capabilities of the heterogeneous hardware, and converts the query semantics corresponding to the node into at least one unloading instruction that the computing storage device can recognize, thereby unloading multiple computationally intensive operators to the computing storage device for execution. This enables the computing storage device to undertake a larger proportion of query computing tasks, and only returns the intermediate processing results processed by the computing storage device to the host, which greatly reduces the amount of data migration between the host and the storage device, thereby significantly reducing query latency and improving the throughput performance of large-scale data analysis. Attached Figure Description

[0017] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the embodiments of the present invention will be briefly described below. Obviously, the drawings described below are merely some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without any creative effort.

[0018] Figure 1 This is an architecture diagram of a database query system based on a computable memory provided in an embodiment of the present invention; Figure 2 This is a schematic flowchart of a database query method based on a computable memory provided in an embodiment of the present invention; Figure 3 This is an architecture diagram of a computable storage layer in a database query system based on computable memory, provided by an embodiment of the present invention. Figure 4 This is a flowchart of a method for determining the execution position of each node in a database query method based on a computable memory, provided in an embodiment of the present invention. Figure 5 This is a flowchart of another method for determining the execution position of each node in a database query method based on a computable memory provided in an embodiment of the present invention; Figure 6 This is a flowchart of a method for calculating execution cost in a computable and storable multi-operator unloading dynamic selection method provided in an embodiment of the present invention; Figure 7 This is a flowchart of a method for generating an unload instruction in a database query method based on a computable memory, provided in an embodiment of the present invention. Figure 8 This is a schematic diagram of a task vector in a database query method based on a computable memory provided in an embodiment of the present invention; Figure 9 This is a flowchart of a method for processing the computable storage layer in a database query method based on computable memory, provided in an embodiment of the present invention. Figure 10 This is a schematic diagram of a database query device based on a computable memory, provided as an embodiment of the present invention. Detailed Implementation

[0019] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0020] Unless the context otherwise requires, throughout the specification and claims, the term "comprising" is interpreted as openly inclusive, meaning "including, but not limited to." In the description of the specification, terms such as "one embodiment," "some embodiments," "exemplary embodiment," "example," "specific example," or "some examples" are intended to indicate that a particular feature, structure, material, or characteristic associated with that embodiment or example is included in at least one embodiment or example of this disclosure. The illustrative representations of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics mentioned may be included in any suitable manner in any one or more embodiments or examples; that is, although they may be incorporated into embodiments or examples using the above terms for reasons such as order and position, it does not limit them to be incorporated in combination by a single embodiment or example.

[0021] In the description of this invention, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, a feature defined with "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of embodiments of this disclosure, unless otherwise stated, "a plurality of" means two or more. Furthermore, for example, the description may use the prefix "A" or "B" to describe the same type of nouns as two independent entities. In this case, the corresponding features defined with "A" and "B" are used only to distinguish between similar entities and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features.

[0022] In the description of this invention, the expression “A and / or B” (where A and B are used to formally represent specific features) will be used. The corresponding expression includes the following three combinations: only A, only B, and a combination of A and B.

[0023] As used in this invention, “about,” “approximately,” or “approximately” includes the stated value and the average value within an acceptable range of deviation from a particular value, wherein the acceptable range of deviation is determined by a person skilled in the art taking into account the measurement under discussion and the error associated with the measurement of the particular quantity (i.e., the limitations of the measurement system).

[0024] Furthermore, the technical features involved in the various embodiments of the present invention described below can be combined with each other as long as they do not conflict with each other.

[0025] Example 1: To address the limitations of existing in-memory processing solutions based on embedded processors or FPGAs in terms of operator offloading range and execution efficiency, this invention provides a database query system based on computable memory. The purpose is to achieve efficient offloading of complex query operators to computable storage devices by constructing a hierarchical and collaborative processing architecture, and to solve the semantic compatibility problem between heterogeneous systems, thereby breaking through the limitations of traditional solutions in terms of operator support range and execution efficiency.

[0026] See Figure 1 The query execution system includes a database layer, a middleware layer, and a computable storage layer. The database layer, middleware layer, and computable storage layer work together through predefined interface protocols to achieve efficient offloading of complex query operators from the host side to the storage side. For example, the interface protocol is the Non-Volatile Memory Host Controller Interface Specification (NVMExpress, abbreviated as NVMe) extended command set.

[0027] The database layer is deployed within the database management system. Its core functions include receiving and parsing SQL query statements submitted by users, generating corresponding query plan trees, selecting execution locations to determine the execution location of each node in the query plan tree, sending the unloading operators to the middleware layer through the ISP manager in the database layer, and receiving intermediate processing results returned by the computing storage device to complete the final query processing.

[0028] The middleware layer is deployed at the operating system layer, located between the database management system and the compute storage device. Its core functions include converting high-level database query semantics into custom unload instructions that can be recognized by the compute storage device based on metadata tables, managing task queues and worker thread pools to schedule operator execution, and maintaining version mapping tables to handle data format heterogeneity and transaction visibility.

[0029] The computeable storage layer is specifically implemented as a compute-intensive storage device, and heterogeneous hardware capable of processing compute-intensive operators is integrated on the compute-intensive storage device to expand the operator support range of the compute-intensive storage device. It also receives unload instructions sent by the middleware layer, and the heterogeneous hardware performs data-level operations according to the unload instructions to generate intermediate processing results, which are then returned to the database layer through the PCIe (Peripheral Component Interconnect express) interface.

[0030] like Figure 2 As shown, based on Figure 1 The provided query execution system, in Embodiment 1 of this invention, provides a database query method based on a computable memory, which specifically includes the following steps: Step 101: Integrate heterogeneous hardware capable of processing computationally intensive operators into the computational storage device to expand the operator support range of the computational storage device.

[0031] Computationally intensive operators include joins, sorting, complex predicate computation, multi-table associations, hashing, and aggregation. Heterogeneous hardware includes NAND flash memory, ARM multi-core processors, Dynamic Random Access Memory (DRAM), and FPGAs.

[0032] Current mainstream in-storage processing technologies only focus on simple single-table operations such as filtering and aggregation, and cannot handle computationally intensive operators. This single operator offloading strategy means that a large amount of computational logic still needs to be executed on the host side, which cannot make full use of the high-bandwidth parallel computing capabilities inside the computing storage device, and it is also difficult to significantly reduce the host CPU load and PCIe data transmission pressure.

[0033] To address the aforementioned problems, embodiments of the present invention integrate NAND Flash, an ARM multi-core processor, DRAM, and FPGA programmable logic into a computing storage device. See also... Figure 3The compute-side storage layer adopts a near-data compute architecture, consisting of NVMe solid-state storage media physically coupled with a heterogeneous compute accelerator card. The heterogeneous compute accelerator card integrates a Processing System (PS) layer and a Programmable Logic (PL) layer. The PS and PL layers communicate via an on-chip high-speed Advanced eXtensible Interface (AXI) interconnect bus to collaboratively complete the processing flow. The PS layer is deployed on a multi-core ARM processor and equipped with DRAM, used to perform control plane functions, including task scheduling, logical address to physical address translation, memory management, and execution of low-computation-demand instructions. The PL layer is deployed on an FPGA, used to perform data plane acceleration functions, including massively parallel data operations, hash calculations, and hardware-accelerated scanning.

[0034] Step 102: Receive and parse the SQL query statement submitted by the user, generate the corresponding query plan tree; determine the execution position of each node in the query plan tree.

[0035] The query plan tree is derived from Structured Query Language (SQL) statements through parsing and optimization. Each node in the query plan tree represents a relational algebra operator (such as scan, filter, join, and aggregation), and these relational algebra operators are connected through data flow to collectively realize the semantics of the SQL statement.

[0036] The execution location includes compute storage devices and the host; that is, the database layer determines whether each node executes on a compute storage device or on the host.

[0037] If the node's execution location is on the host, its operations on the storage disk, such as reading data pages, writing data pages, reading index pages, flushing log buffers to disk, and writing temporary tables to disk, follow the traditional database management system workflow and are handled by the storage manager. If the node's execution location is on a compute storage device, the operations are passed to the ISP manager, which then instructs the middleware layer to perform memory and data alignment between the relevant nodes and the host so that the execution results from the compute storage device can be stored in the corresponding memory area.

[0038] Step 103: If the execution location of the node is a compute storage device, then the query semantics corresponding to the node are converted into at least one unload instruction that the compute storage device can recognize, wherein the unload instruction defines the compute storage device performing the data-level operation of the node.

[0039] There is a significant mismatch between database execution semantics and the execution environment of compute storage devices. Specifically, this manifests as limited operator compatibility between different database systems and insufficient data format interoperability. Although some analytical databases support user-defined functions based on SQL, complex semantic mapping still exists between the logical semantics of database operators and the execution mechanism of compute storage devices based on the NVMe protocol. To address this complex semantic mapping issue, this invention uses a middleware layer to convert database query semantics into custom unloading commands that the compute storage device can recognize, ensuring that the compute storage device understands the semantics of the SQL statement itself when performing related operations.

[0040] The data-level operations of a node refer to relational algebra operations (such as scans, filters, joins, and aggregations) performed on compute storage devices, along with their complete parameters (the tables involved, join conditions, and filter predicates). This is a finer-grained division after step 102 determines the execution location of each node. For example, if a node represents a filtering operation, step 102 only determines whether this filtering operation is performed on the compute storage device or on the host. Once step 102 determines that the filtering operation is performed on the compute storage device, step 103 further divides the filtering operation at the data level, defining which table the compute storage device scans, which column of that table is filtered, and what the filtering conditions are, etc.

[0041] Step 104: The heterogeneous hardware performs data-level operations according to the unloading instructions to generate intermediate processing results, completes the final query based on the intermediate processing results, and returns the obtained query results to the user.

[0042] In one embodiment, the compute storage layer receives an unload instruction sent by the middleware layer, and the heterogeneous hardware on the compute storage layer performs data-level operations according to the unload instruction to generate intermediate processing results. Since the unload instruction has refined the operation to the data level, the heterogeneous hardware does not need to perform additional optimization or decision-making and can directly execute the unload instruction.

[0043] In one embodiment, the compute storage device communicates with the host system via a PCIe interface. In this embodiment, it is configured to support a dual-mode instruction receiving mechanism, specifically: in standard I / O mode, it receives host I / O requests through the standard NVMe protocol stack; in compute offload mode, it receives operator offload instructions and task vectors through a custom offload instruction.

[0044] In this embodiment, heterogeneous hardware capable of processing computationally intensive operators is integrated into the computing storage device. By leveraging the parallel computing capabilities of the heterogeneous hardware and converting the query semantics corresponding to the nodes into at least one unloading instruction that the computing storage device can recognize, multiple computationally intensive operators are unloaded to the computing storage device for execution. This allows the computing storage device to handle a larger proportion of query computation tasks, and only the intermediate processing results processed by the computing storage device are returned to the host. This significantly reduces the amount of data migration between the host and the storage device, thereby significantly reducing query latency and improving the throughput performance of large-scale data analysis.

[0045] The database layer contains a query execution extension module and an ISP manager module. These modules select the execution location and interact with the middleware layer. (See also...) Figure 4 The process of receiving and parsing the SQL query statement submitted by the user, generating the corresponding query plan tree, and selecting the execution position to determine the execution position of each node in the query plan tree specifically includes the following steps: Step 201: Traverse the query plan tree and identify at least one unloadable operator in the query plan tree based on the predefined unloadable operator metadata table.

[0046] In this context, unloadable operators refer to relational algebra operators that can be unloaded onto computational storage devices for execution. When traversing the query plan tree, the query execution extension module compares the unloadable operators recorded in the unloadable operator metadata table to determine which nodes in the query plan tree are unloadable operators.

[0047] Step 202: Traverse the query plan tree from bottom to top, merging unloadable operators that satisfy the constraints of the compute storage device in turn, until an operator that does not satisfy the constraints of the compute storage device is encountered, thereby splitting at least one unload subtree, wherein all nodes in each unload subtree are assigned to the compute storage device for execution.

[0048] The unloading subtree includes, but is not limited to, combinations of operators such as filtering, scanning, projection, aggregation, and hash join. That is, the unloading subtree contains one or more operators. Since scanning, filtering, joining, and aggregation are called operators in SQL, the unloading subtree is also called the operator tree. Each node of the operator tree represents an operator.

[0049] Computational storage device constraints refer to a set of conditions that determine whether an operator can be executed on a computational storage device. These conditions include inherent hardware limitations such as the types of operations supported by the computational storage device, data width, storage capacity, computing resources, and interface protocols. Only when the set of operators formed by the root node of the unloaded subtree and its descendant nodes all satisfy the computational storage device constraints can all nodes within the partitioned unloaded subtree be allocated to the computational storage device for execution.

[0050] The above method determines the execution location of a node from the perspective of whether the node is an unloadable operator. As long as the constraints of the compute storage device are met, the unloadable subtree corresponding to the node is executed on the compute storage device. However, this method fails to accurately model the heterogeneous computing characteristics, data movement costs, and dynamic load changes between the compute storage device and the host. This leads to the current determination of the execution location being suboptimal. That is, some unloadable operators may perform better when executed on the host than on the compute storage device.

[0051] Therefore, this invention proposes a superior method for determining the execution location. Specifically, by constructing a hybrid prediction framework that integrates convolutional neural networks and a cost model, the real-time load status of the computable storage device, heterogeneous computing characteristics, and data movement costs are incorporated into the query optimization decision-making process. See also... Figure 5 The process of receiving and parsing the SQL query statement submitted by the user, generating the corresponding query plan tree, and selecting the execution position to determine the execution position of each node in the query plan tree further includes the following steps: Step 301: For the query plan tree, use the host-side query optimizer to generate multiple candidate execution plans.

[0052] The host-side query optimizer uses traditional cardinality estimation methods and cost-based models to evaluate and select candidate execution plans. Candidate execution plans define the data flow order and operator combinations for query execution at an algebraic level. Each candidate execution plan is represented as a query plan tree, with different corresponding query execution paths. That is, for the same operator in a query, different join algorithms (such as hash joins instead of nested loops) or different base table scan methods (such as index scans instead of full table scans) may be used, but the final output will be the same query result. For example, in candidate execution plan 1, the scan operator is executed as an index scan, and the join operator is executed as a hash join; in candidate execution plan 2, the scan operator is executed as a full table scan, and the join operator is executed as a nested loop.

[0053] Step 302: For each candidate execution plan, identify the unloadable operators in the candidate execution plan, and generate multiple unloadable subtrees by enumerating unloadable combinations of unloadable operators, wherein the unloadable combination includes at least one unloadable operator.

[0054] In one embodiment, unloadable operators can still be identified through an unloadable operator metadata table. Each candidate execution plan corresponds to multiple unloadable subtrees.

[0055] Unloading combinations of unloadable operators determine the number of unloadable operators in the unloadable subtree and specify which unloadable operators are included in the combination. For example, if the unloadable operators are nodes 1 and 2, there are three corresponding unloading combinations: one unloading combination includes only node 1, another includes only node 2, and yet another includes both nodes 1 and 2. The execution locations of the operators differ across unloadable subtrees. For instance, if an index scan is determined to be performed, one unloadable subtree indicates that the index scan is executed on computed memory, while another indicates that the index scan is executed on the host machine.

[0056] Step 303: For each unloading subtree, construct a high-dimensional vector based on the task characteristics of the unloading subtree and the real-time resource characteristics of the computable memory, wherein the task characteristics include at least the execution cost of the unloading subtree under ideal load conditions of the computable memory.

[0057] In this embodiment of the invention, a high-dimensional vector is constructed based on the task characteristics of the unloaded subtree and the real-time resource characteristics of the computable memory. The task characteristics include query characteristics and data characteristics; the real-time resource characteristics include the computing resource utilization index of the computable memory and hardware configuration details.

[0058] In one embodiment, computational resource utilization metrics include CPU utilization, memory utilization, and bandwidth utilization. In one embodiment, query features include operator type encoding, predicate selectivity, data distribution skewness, and join algorithm type. In one embodiment, data features include input table size, average tuple length, column statistics, and the execution cost obtained in step 404. In one embodiment, hardware configuration details include the computational power of the computable memory, memory size, bandwidth, etc.

[0059] Step 304: Input the high-dimensional vector into the trained prediction model to obtain the profit prediction value of each unloading subtree. Select the unloading subtree with the largest profit prediction value as the optimal unloading subtree and allocate the optimal unloading subtree to the computeable memory for execution.

[0060] In real-world scenarios, the resources of computable memory change in real time; they may have abundant or scarce computing resources. Therefore, this embodiment of the invention also considers the real-time load status of the computable memory and provides a baseline prediction of the operator execution cost on the host and computable memory through a prediction model. This prediction model is based on a deep neural network architecture and adaptively adjusts prediction parameters by continuously learning historical execution feedback and real-time performance data to achieve accurate prediction of operator execution performance on the computable memory side. The prediction model is used to perform nonlinear correction and dynamic refinement on the baseline prediction provided by the statistical cost model, solving the prediction deviation problem caused by complex data distribution, hardware resource competition, and dynamic changes in workload that traditional cost models struggle to capture.

[0061] The final output of the prediction model is the difference between the performance gains of all nodes in the unloaded subtree executed on the host and the performance gains of all nodes in the unloaded subtree executed on compute-enabled storage. A positive difference indicates that unloading to compute-enabled storage offers performance benefits; a negative difference indicates that execution on the host is superior. After obtaining the performance difference for each physical query plan, the unloaded subtree with the largest positive difference is considered optimal.

[0062] In one embodiment, the prediction model includes an input layer, a first hidden layer, a second hidden layer, and an output layer. The input layer receives a normalized high-dimensional vector; the first hidden layer extracts features from the normalized high-dimensional vector; the second hidden layer extracts features from the output of the first hidden layer; and the output layer performs a weighted summation and linear activation on the output of the second hidden layer to generate a single real value. This real value is used as the predicted profit value, representing the predicted profit between executing the offloaded subtree on the host machine and executing it in computeable memory. In one embodiment, the first hidden layer has 256 neurons, the second hidden layer has 128 neurons, and the output layer has 1 neuron.

[0063] Specifically, the process of obtaining the revenue prediction value is as follows: The values ​​of each dimension in the high-dimensional vector are mapped to a unified range to obtain a normalized vector; all dimensions in the normalized vector are weighted and summed to extract the contribution of the coupling relationship between execution cost, other task features, and real-time resource features to the revenue prediction value, resulting in a first feature vector; all dimensions in the first feature vector are weighted and summed to extract the comprehensive impact of the execution cost after modulation by real-time resource features and other task features on the revenue prediction value, outputting a second feature vector; all dimensions in the second feature vector are weighted and summed to output the revenue prediction value. In other words, when the two hidden layers perform forward propagation on the normalized vector, they combine the originally dispersed dimensions in the normalized vector pairwise to extract the impact of each pair of features acting together on the revenue prediction value; these paired effects are further combined to extract the comprehensive impact of multiple features acting together on the revenue prediction value; finally, an importance weight is assigned to each comprehensive impact, with positive effects increasing the revenue prediction value and negative effects decreasing it, ultimately summing up to obtain the revenue prediction value of offloading relative to host execution.

[0064] The database layer calculates the execution cost of each offloaded subtree based on the ideal load state of the computable memory. (See [link / reference]). Figure 6 The multi-operator offloading dynamic selection method based on computable memory further includes the following steps: Step 401: For an unloading subtree, determine the cost items included in the execution cost calculation formula of each operator based on the operational characteristics and data dependency patterns of each operator in the unloading subtree.

[0065] This invention proposes a new cost model to calculate the resource consumption of unloading a subtree in two execution environments: the cost required to complete the computation on the host side and the overhead incurred by unloading it to a computable memory for execution. The estimated results are used as input for subsequent prediction models.

[0066] The execution of any operator can be abstracted into three parts: data acquisition, data transmission, and data computation. Correspondingly, the execution cost of any operator can be calculated using three cost items: the data acquisition latency of the underlying storage medium, the data transmission latency required for execution, and the computation latency. The formula for calculating the execution cost is as follows: ;

[0067]

[0068]

[0069] ; in, This represents the total execution cost of the operator. This indicates the data retrieval latency of the underlying storage medium. Indicates the data transfer latency required for execution. Indicates the computation delay. This indicates the number of pages that need to be read when performing a scan operation on the target relation table. Indicates the size of each page. Indicates the internal bandwidth of the SSD. Indicates the host interface bandwidth. Indicates the number of input tuples. Indicates the number of output tuples. This represents the time required for the operator to process a tuple. The width of a tuple is usually expressed in bytes. The device variable is a generalized expression that can represent either the host or a storage device with computing capabilities.

[0070] Based on the above three cost items, due to the essential differences in the operational characteristics and data dependency patterns of different operators, the ratio of revenue to expenditure for various operators is significantly different. Therefore, this embodiment of the invention establishes a differentiated cost model for each operator category, and further breaks down the cost items in the calculation stage to ensure that the actual cost items involved in the calculation are different for different operator categories.

[0071] In one embodiment, the core characteristic of the hash join operator is that it first needs to select a table, read all its data, and build an in-memory hash table based on the join key; then, it reads each row of data from another table, using the same join key to quickly probe the hash table and find matching rows. Therefore, in its cost items, in addition to the basic data acquisition latency and data transmission latency, the computation latency is further refined into two key overheads: hash table construction latency and hash probe latency.

[0072] Taking the hash join operation on tables A and B as an example, the cost items involved in the hash join operator calculation include the time required to read data from NAND, the time to build the hash table, the time spent probing the hash table, and the data transfer time. The corresponding calculation formula for the execution cost is as follows: ;

[0073]

[0074]

[0075]

[0076] in, The total execution cost of the hash join operator. The time required to read data from NAND for table A. The time required for Table B to read data from NAND. Indicates the data transfer latency required for execution. Indicates the time when the hash table was built. This indicates the time spent probing the hash table. This represents the number of pages that need to be read when performing a scan operation on the target relation table. Indicates the size of each page. It refers to the host interface bandwidth. This is the number of input tuples in table B. This is the number of input tuples in table A. It is the number of output tuples. Indicates the width of the tuple. This represents the time required to process a tuple. This indicates the time taken to probe a tuple.

[0077] Step 402: Determine the parameter values ​​in the cost item by combining the query semantics of the SQL statement.

[0078] In one embodiment, when calculating the execution cost, in addition to the different cost items involved, the specific values ​​of the parameters in each cost item also need to be dynamically evaluated in conjunction with the query semantics of the SQL query statement to determine the specific parameter values.

[0079] In one embodiment, in the above calculation formula, when performing a scan operation on the target relation table, it is necessary to consider the number of pages read P and the number of input tuples. Number of output tuples The time required for the operator to process a tuple They have different statistical characteristics, and the differences in statistical characteristics determine the different specific values.

[0080] Specifically, the latency of data access to flash memory and the time spent on cross-layer data transfer mainly depend on the total amount of input and output data, including the total number of page scans, the size of the result set, and the width of tuples. This type of metadata can be determined by parsing the metadata information of the table and combining it with the cardinality prediction results generated by the optimizer.

[0081] The time consumption of the computation phase is closely related to the size of the input data and the complexity of tuple processing. Some operators exhibit a linear positive correlation; for example, projection and aggregation increase their execution time proportionally with the number of input tuples, while the processing cost per tuple remains relatively constant. However, certain operators require dynamic evaluation in conjunction with query semantics. For instance, the processing cost per tuple in filtering operations is closely related to the number of predicate conditions and logical complexity; the computational cost of constraint operations directly depends on the final output size; and sorting operations follow a logarithmic linear growth pattern, with their complexity conforming to the characteristic curve of (Nin)(log2Nin).

[0082] Step 403: Calculate the execution cost of each operator based on the cost item and the parameter value.

[0083] Step 404: Organize the execution cost of each operator in a tree structure to obtain a column vector, and use the column vector as the execution cost of the unloading subtree.

[0084] For each unloading subtree, it is regarded as an operator tree. Each node in the tree is divided into leaf nodes and non-leaf nodes. The execution cost of a leaf node is the execution cost of the operator itself; the execution cost of a non-leaf node is the sum of the execution cost of the operator itself and the execution costs of all its child nodes.

[0085] Specifically, after calculating the execution cost of each operator individually, the execution cost of each node is obtained according to whether it is a leaf node or a non-leaf node, using the method described above. Then, the execution costs of each node are arranged sequentially according to the preorder traversal order to form a column vector, which is used as the execution cost of the unloading subgraph.

[0086] This invention constructs a prediction model that integrates a convolutional neural network and a cost model. The optimal offloading subtree is determined by the revenue prediction value output by the prediction model. The cost model provides a baseline prediction for operator execution costs on the host and computeable memory. Specifically, the prediction model performs nonlinear correction and dynamic refinement on the baseline prediction provided by the cost model, thereby solving the prediction bias problems caused by complex data distributions, hardware resource competition, and dynamic workload changes that are difficult for traditional cost models to capture. The prediction is based on a deep neural network architecture, which continuously learns from historical execution feedback and real-time performance data, adaptively adjusting prediction parameters to achieve accurate prediction of operator execution performance on the computeable memory side.

[0087] After determining the optimal offload subtree—that is, identifying which nodes execute on the compute storage device and which on the host—the operators to be executed on the compute storage device are passed to the ISP manager. The ISP manager is then responsible for notifying the middleware layer to perform semantic translation. The middleware layer includes a semantic translation module, a task allocation module, and a worker management module. All modules in the middleware layer perform data-level partitioning of the offload subtree and interact with the compute storage layer, such as... Figure 7 As shown, the multi-operator offloading method for the computable memory further includes the following steps: Step 501: Decompose the unloading subtree into multiple subtasks using a bottom-up approach.

[0088] Each subtask contains a root operator and its left and right subtree dependencies. For example, a subtask may include a scanning operation and a filtering operation. After dividing it into two subtasks, one subtask performs the scanning operation and the other subtask performs the filtering operation. The filtering operation depends on the result of the scanning operation.

[0089] Subtasks define the specific semantics of operations, such as which table to scan, what the filtering conditions are, which two tables to join, and what the join conditions are. These are data-level operations.

[0090] Step 502: Based on the predefined middleware metadata table, convert the query semantics corresponding to each subtask into a task vector that can be recognized by the computing storage device.

[0091] The middleware metadata table is stored within the semantic transformation module. The middleware metadata table is divided into three layers: the core operator layer (e.g., selection, projection, connection); the physical execution unit layer (e.g., arithmetic, comparison); and the parameter configuration layer (different inputs to the operator, available computation units, CSD parameter values, etc.). Both the core operator layer and the physical execution unit layer use one-hot encoding, and different operators are represented by unique identifiers.

[0092] Specifically, the core operators, physical execution units, and parameter configurations in the subtasks are identified; the codes corresponding to the core operators, physical execution units, and parameter configurations are determined according to the middleware metadata table; and the codes corresponding to the core operators, physical execution units, and parameter configurations are sequentially combined into a task vector according to the execution order of the subtasks.

[0093] See Figure 8The task vector for subtask 1 is [1,1,7,1,-1,-2,0,70]. The first item of the task vector is encoded as 1, representing subtask ID 1; the second item is encoded as 1, representing the specific operation is filtering; the third item is encoded as 7, representing the corresponding logical operator is =<; the fourth item is encoded as 1, representing the target table for the specific operation is table A; the fifth item is encoded as -1, indicating that the operation depends on the results of other subtasks; the sixth item is encoded as -2, representing that the right subtree is a constant value; the seventh item is encoded as 0, representing that the other subtask IDs the operation depends on are 0; and the eighth item is encoded as 70, representing that the specific value of the constant value in the right subtree is 70. If the fifth item is positive, it indicates dependence on a specific column attribute of the database table. If the code of the sixth item in the task vector is -2, it means that the right subtree is a constant value; if the code of the sixth item in the task vector is -3, it means that the right subtree is string data; if the code of the sixth item in the task vector is -4, it means that the right subtree is in date format.

[0094] According to the predefined codes representing each core operator, physical execution unit, and parameter configuration, and the order that the computing storage device can recognize, the codes of the core operators, physical execution units, and parameter configurations in the subtask are sequentially combined into a task vector.

[0095] Step 503: Analyze the computational resource requirements of each subtask according to the task vector, and determine the heterogeneous hardware for each subtask according to the available resources of the currently idle heterogeneous hardware.

[0096] In one embodiment, the task allocation module parses the computational resource requirements of subtasks based on task vectors, retrieves the number of currently idle heterogeneous hardware units from the metadata table, and determines, based on the available resources of the heterogeneous hardware, which specific heterogeneous hardware unit will process each subtask after it is allocated to a compute storage device. Furthermore, after determining the heterogeneous hardware for each subtask, the task allocation module also maintains the dependencies between different subtasks.

[0097] Furthermore, to maximize the computational potential of computing storage devices, embodiments of the present invention also match each subtask with heterogeneous hardware more suitable for processing its type of task, provided that heterogeneous hardware resources allow. For example, lightweight computing tasks are assigned to ARM processors for execution; data-intensive, highly parallel computing tasks (such as hash construction, streaming probing, and filtering) are offloaded to FPGA hardware for acceleration.

[0098] Step 504: Encapsulate the task vector and the identifier corresponding to the heterogeneous hardware to obtain the unload instruction corresponding to each subtask.

[0099] In one embodiment, the worker thread module includes multiple parallel worker threads, each configured with an independent sending unit, receiving unit, and computing unit request interface; the worker thread module offloads each subtask to the CSD for execution via the NVMe command, and manages DMA data transfer between the CSD and the host; wherein, after the subtask is completed, the worker thread receives the processing result returned by the CSD, and performs format conversion and alignment processing on the result data according to the variable-length field length encoding and alignment rules of the target database management system.

[0100] After the middleware layer determines the corresponding unload instruction, it is passed to the computable storage layer. The PS and PL layers within the computable storage layer then execute the specific operations and interact with the database layer. (See [reference needed]). Figure 9 The multi-operator offloading method for the computable memory further includes the following steps: Step 601: Receive and parse the unload command to obtain the task vector and the identifier corresponding to the heterogeneous hardware; pre-configure resources according to the data-level operations in the task vector.

[0101] In one embodiment, the offload instruction transmitted by the middleware layer is received and parsed by the PS layer to obtain the heterogeneous hardware identifier and task vector. The task vector includes connection type, table identifier, key column definition, and filtering conditions.

[0102] Before execution at the PL layer, the NAND controller pre-configures resources through task vector scheduling of subtasks. Taking table A hashing table B as an example, the pre-configuration is as follows: read the associated table data from the NAND flash memory; write the data to the specified on-chip memory region via DMA; send a configuration command to the PL layer; after receiving the configuration, the PL layer initializes the computing engine and monitors the readiness status of the memory buffer through the on-chip interconnect bus.

[0103] Step 602: Assign the subtasks to the corresponding heterogeneous hardware according to the identifiers of the heterogeneous hardware, and output the calculation results.

[0104] In one embodiment, the PS layer also monitors the runtime state of the PL layer, dynamically allocates parallel subtasks to the PL layer based on the identifiers corresponding to heterogeneous hardware, and performs memory resource management, including garbage collection operations. Additionally, the PS layer can also execute lightweight subtasks; the PL layer is primarily used to accelerate operations.

[0105] Taking the hash connection of table A to table B as an example, the PL layer reads table data from memory through DMA, performs FPGA-accelerated hash calculation on the key values ​​of table A to build a hardware hash table residing in memory, and then matches the key values ​​of table B with the hash table and outputs the result to the result buffer.

[0106] Step 603: Post-process the calculation results to obtain intermediate processing results and release the allocated resources.

[0107] Post-processing includes deduplication, sorting, and aggregation operations.

[0108] In one embodiment, the PS layer receives a completion interrupt signal from the PL layer, reads the calculation result from the PL layer via DMA, performs post-processing on the calculation result, and then returns the intermediate processing result set to the host via PCIe and releases the allocated resources.

[0109] Furthermore, the collaboration between the PS layer and the PL layer is not limited to cross-layer task allocation, but also extends to the joint execution of complex tasks. For example, when a filtering operation involves relatively complex computational conditions, the PS layer performs the computation first, and then notifies the PL layer, which subsequently completes the filtering operation.

[0110] Example 2: Based on the database query method based on computationally readable memory provided in the foregoing embodiments, the present invention also provides an apparatus for implementing the above-described database query method based on computationally readable memory, such as... Figure 10 The diagram shown is a schematic representation of the device architecture according to an embodiment of the present invention. The device for database querying based on computeable memory in this embodiment includes one or more processors 21 and a memory 22. Figure 10 Take a processor 21 as an example.

[0111] Processor 21 and memory 22 can be connected via a bus or other means. Figure 10 Taking the example of a connection between China and Israel via a bus.

[0112] The memory 22, as a non-volatile computer-readable storage medium for a database query method based on computational memory, can be used to store non-volatile software programs and non-volatile computer-executable programs, such as the database query method based on computational memory in the foregoing embodiments. The processor 21 executes various functional applications and data processing of the database query device based on computational memory by running the non-volatile software programs, instructions, and modules stored in the memory 22, thereby implementing the database query method based on computational memory in the foregoing embodiments.

[0113] Memory 22 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other non-volatile solid-state storage device. In some embodiments, memory 22 may include memory remotely located relative to processor 21, which can be connected to processor 21 via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0114] The program instructions / modules are stored in memory 22 and, when executed by one or more processors 21, perform the database query method based on computable memory as described in the foregoing embodiments.

[0115] This invention also provides a non-volatile computer storage medium storing computer-executable instructions that are executed by one or more processors, for example... Figure 10 One of the processors 21 can enable the one or more processors to execute the database query method based on computable memory in the foregoing embodiments.

[0116] It is worth noting that the information interaction and execution process between the modules and units in the above-mentioned device and system are based on the same concept as the processing method embodiment of the present invention. For details, please refer to the description in the method embodiment of the present invention, and will not be repeated here.

[0117] Those skilled in the art will understand that all or part of the steps in the various methods of the embodiments can be implemented by a program instructing related hardware. The program can be stored in a computer-readable storage medium, which may include: read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0118] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A database query method based on a computable memory, characterized in that, include: Integrating heterogeneous hardware capable of processing computationally intensive operators into computing storage devices expands the operator support range of the computing storage devices; Receive and parse the SQL query statement submitted by the user, and generate the corresponding query plan tree; Determine the execution position of each node in the query plan tree; If the execution location of the node is a compute storage device, then the query semantics corresponding to the node are converted into at least one unload instruction that the compute storage device can recognize, wherein the unload instruction defines the compute storage device performing data-level operations on the node; The heterogeneous hardware performs data-level operations according to the unloading instructions to generate intermediate processing results, completes the final query based on the intermediate processing results, and returns the obtained query results to the user.

2. The database query method based on a computable memory according to claim 1, characterized in that, The method further includes: Traverse the query plan tree and identify at least one unloadable operator in the query plan tree based on a predefined unloadable operator metadata table; Traverse the query plan tree from bottom to top, merging unloadable operators that satisfy the constraints of the compute storage device in turn, until an operator that does not satisfy the constraints of the compute storage device is encountered, thereby splitting at least one unload subtree, in which all nodes in each unload subtree are assigned to the compute storage device for execution.

3. The database query method based on a computable memory according to claim 1, characterized in that, The method further includes: For the query plan tree, the host-side query optimizer is used to generate multiple candidate execution plans; For each candidate execution plan, identify the unloadable operators in the candidate execution plan, and generate multiple unloadable subtrees by enumerating unloadable combinations of unloadable operators, wherein the unloadable combination includes at least one unloadable operator; For each unloading subtree, a high-dimensional vector is constructed based on the task characteristics of the unloading subtree and the real-time resource characteristics of the computable memory, wherein the task characteristics include at least the execution cost of the unloading subtree under ideal load conditions of the computable memory. The high-dimensional vector is input into the trained prediction model to obtain the profit prediction value of each unloading subtree. The unloading subtree with the largest profit prediction value is selected as the optimal unloading subtree, and the optimal unloading subtree is allocated to the computing storage device for execution.

4. The database query method based on a computable memory according to claim 3, characterized in that, The method further includes: For an unloading subtree, the cost items included in the calculation formula of the execution cost of each operator are determined according to the operation characteristics and data dependency pattern of each operator in the unloading subtree. The parameter values ​​in the cost item are determined by combining the query semantics of the SQL query statement; Calculate the execution cost of each operator based on the cost item and the parameter value; The execution cost of each operator is organized into a tree structure to obtain a column vector, which is then used as the execution cost of the unloading subtree.

5. The database query method based on a computable memory according to claim 4, characterized in that, The formula for calculating the operator execution cost is as follows: ； in, This represents the total execution cost of the operator. This indicates the data retrieval latency of the underlying storage medium. Indicates the data transfer latency required for execution. This indicates the computation delay.

6. The database query method based on a computable memory according to claim 2 or 3, characterized in that, The method further includes: The unloading subtree is decomposed into multiple subtasks using a bottom-up approach. Based on the predefined middleware metadata table, the query semantics corresponding to each subtask are converted into task vectors that can be recognized by computing storage devices; The computational resource requirements of each subtask are analyzed based on the task vector, and the heterogeneous hardware is determined for each subtask according to the available resources of the currently idle heterogeneous hardware. The task vector and the identifier corresponding to the heterogeneous hardware are encapsulated to obtain the unload instruction corresponding to each subtask.

7. The database query method based on a computable memory according to claim 6, characterized in that, The step of converting the query semantics corresponding to each subtask into a task vector that can be recognized by the computing storage device according to the predefined middleware metadata table includes: Identify the core operators, physical execution units, and parameter configurations in the subtasks; The encodings corresponding to the core operators, physical execution units, and parameter configurations are determined based on the middleware metadata table. According to the execution order of the subtasks, the codes corresponding to the core operators, physical execution units, and parameter configurations are sequentially combined into a task vector.

8. The database query method based on a computable memory according to claim 1, characterized in that, The method further includes: Receive and parse the unload command to obtain the task vector and the corresponding identifier of the heterogeneous hardware; pre-configure resources according to the data-level operations in the task vector; According to the identifier of the heterogeneous hardware, the subtask is assigned to the corresponding heterogeneous hardware for execution, and the calculation result is output. Post-process the calculation results to obtain intermediate processing results, and release the allocated resources.

9. A database query device based on a computable memory, characterized in that, include: At least one processor; And a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the processor for performing the database query method based on a computable memory as described in any one of claims 1-8.

10. A non-volatile computer storage medium, characterized in that, The computer storage medium stores computer-executable instructions, which are executed by one or more processors to perform the database query method based on computable memory as described in any one of claims 1-8.

Images