Graph database query execution engine and method

Abstract

The invention discloses a graph database query execution engine and method, and belongs to the technical field of graph data query. The graph database query execution engine comprises an execution plan generation module, a scheduling module and an operator library; wherein the execution plan generation module is used for converting a logic execution plan into a physical operator set, and adding a storage access physical operator at a physical operator level so as to proxy a sub-plan pushed down to a storage layer for execution; packaging the physical operators into an execution component based on a data dependency relationship between the operators; constructing a physical execution plan composed of the execution components, and submitting the physical execution plan to a scheduling module; the scheduling module adds each execution component into an execution queue; selecting execution components for scheduling according to the state of the thread pool, and managing the execution components which are being executed according to a preset scheduling strategy; and the operator library provides a memory calculation physical operator shared by the calculation layer and the storage layer through a uniform interface. The graph database query execution engine provided by the invention can meet the performance requirements of OLTP and OLAP workloads at the same time.

Description

Technical Field

[0001] The present invention relates to the technical field of graph data query, and particularly to a graph database query execution engine and method. Background Art

[0002] With the rapid development of information technology, the amount of data has shown an explosive growth, and the correlation relationships between data have become increasingly complex. Due to its advantages in modeling, storing, and querying complex relationships, graph databases have been widely used in application scenarios such as social network analysis, knowledge graph construction, and recommendation systems. However, in the face of the growing data scale and increasingly complex query requirements, how to efficiently execute graph query operations has become one of the core challenges faced by graph databases.

[0003] Traditional graph database query execution engines have many performance bottlenecks when dealing with large-scale graph data and complex query tasks. On the one hand, in the execution mode based on the materialized model, when processing analytical (OLAP) query tasks, a large number of intermediate results are often generated. If these intermediate results are processed using the in-memory materialization strategy, it will significantly increase the consumption of memory bandwidth, reduce the utilization efficiency of the CPU cache, and may lead to the Out of Memory (OOM) problem, thus affecting the system stability and query performance. On the other hand, some query execution engines adopting the Volcano-style Model need to frequently call virtual functions or function pointers during operation, resulting in additional runtime overhead and thus affecting the overall execution efficiency.

[0004] In the industrial community, different types of graph database systems have optimized the query execution engine to varying degrees. For example, some graph databases (such as Neo4j) are mainly optimized for transactional (OLTP) workloads, and their query execution engines perform well in processing simple query tasks with low latency and high concurrency, but there are performance bottlenecks when facing analytical (OLAP) queries; some other graph database systems (such as TigerGraph) focus on the optimization of OLAP workloads and improve the execution efficiency by adopting code generation technology. However, the code generation process itself has a certain time overhead, so it is difficult to meet the low latency requirements in the OLTP scenario.

[0005] In summary, the execution engines of existing graph databases still have obvious deficiencies in terms of performance, resource utilization, and applicable workload types, and cannot fully meet the requirements of current diverse application scenarios for graph computing capabilities. Summary of the Invention

[0006] The object of the present invention is to provide a graph database query execution engine and method, so as to solve the problem that the graph database query execution engine in the prior art cannot fully meet the requirements of the current diverse application scenarios for graph computing capabilities.

[0007] To achieve the above object, the present application adopts the following technical solutions:

[0008] A graph database query execution engine of the present application includes: an execution plan generation module, a scheduling module, and an operator library; wherein,

[0009] The execution plan generation module is configured to:

[0010] Convert the logical execution plan of the query request into a set of physical operators, and add a storage access physical operator at the physical operator level to proxy the sub-plan pushed down to the storage layer for execution;

[0011] Based on the data dependency relationship between operators, encapsulate all physical operators into multiple independently schedulable execution components;

[0012] Construct a physical execution plan composed of the execution components and submit it to the scheduling module;

[0013] The scheduling module is configured to:

[0014] Add each execution component in the physical execution plan to the execution queue;

[0015] Select execution components from the execution queue for scheduling according to the thread pool status, and manage the executing execution components according to a preset scheduling strategy;

[0016] The operator library is configured to:

[0017] Provide memory computing physical operators shared by the computing layer and the storage layer through a unified interface, including filtering physical operators, sorting physical operators, and joining physical operators.

[0018] Preferably, the data transmission between physical operators within the execution component all adopts a bound table format;

[0019] The filtering operator filters the data in the bound table based on the mask operation of the bit set.

[0020] Preferably, the storage access physical operator is configured to:

[0021] Respond to the data request of the downstream physical operator, and obtain the bound table data from the storage layer through the remote procedure call mechanism;

[0022] The proxy pushed-down sub-plan includes a filtering physical operator, a vertex scan physical operator, or an edge scan physical operator executed by the storage layer.

[0023] Preferably, the unified interface includes a first interface for producing data, a second interface for consuming data transmitted from the upstream, a third interface for notifying the upstream of the need for data, and a fourth interface for notifying the upstream that data is no longer needed.

[0024] Preferably, the execution strategy of the execution component includes:

[0025] The downstream physical operator requests data from the upstream through the third interface;

[0026] After the upstream physical operator responds to the request, it produces data through the first interface and calls the second interface of the downstream to transmit the bound table data.

[0027] Preferably, the execution component is further configured to:

[0028] A single execution component is executed in one thread, and the internal data of the execution component flows through each physical operator in sequence.

[0029] Preferably, the preset scheduling strategy includes a cancellation strategy, a suspension strategy, and a yielding strategy.

[0030] Preferably, the preset scheduling strategy further includes a time slice scheduling mechanism for allocating the same time slice to each executing execution component, and removing it from the thread pool and re-adding it to the tail of the execution queue when the execution time of the execution component exceeds the threshold.

[0031] Preferably, the scheduling module is further configured to:

[0032] Support affinity scheduling based on non-uniform memory access to reschedule the interrupted execution component to the original CPU core for execution.

[0033] A method for query execution in a graph database, applied to the above-mentioned graph database query execution engine, includes the following steps:

[0034] Convert the logical execution plan of the query request into a set of physical operators, and add a storage access physical operator at the physical operator level to proxy the sub-plan pushed down to the storage layer for execution;

[0035] Based on the data dependency relationship between operators, encapsulate all physical operators into multiple independently schedulable execution components;

[0036] Construct a physical execution plan composed of the execution components and submit it to the execution queue;

[0037] Select an execution component from the execution queue for scheduling according to the thread pool status, and manage the executing execution components according to the preset scheduling strategy;

[0038] Among them, the in-memory computing physical operator in the execution component is shared between the computing layer and the storage layer through a unified interface.

[0039] The present invention has the following beneficial effects:

[0040] The graph database query execution engine provided by the present invention can simultaneously meet the performance requirements of OLTP and OLAP workloads through the sharing of in-memory computing physical operators between the computing layer and the storage layer, the optimization of the scheduling strategy of the scheduling module, and the optimized design of the core components. Compared with traditional query execution engines, the performance is improved several times or even higher. BRIEF DESCRIPTION OF THE DRAWINGS

[0041] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the following will briefly introduce the drawings required for use in the description of the embodiments or the prior art. Obviously, the drawings in the following description are only some embodiments of the present application. For those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative efforts.

[0042] Figure 1 It is a schematic structural diagram of a graph database query execution engine provided by an embodiment of the present application;

[0043] Figure 2 It is a schematic diagram of the conversion between a logical execution plan and a physical execution plan provided by an embodiment of the present application;

[0044] Figure 3 It is an execution flowchart of a graph database query execution engine provided by an embodiment of the present application. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0045] To make the technical solutions of the present application clearer, the following further describes the present invention in detail with reference to the accompanying drawings and specific embodiments. The terms "first", "second", etc. in the claims and the description of the present application are used to distinguish similar objects, and do not necessarily describe a specific order or sequence. It should be understood that such terms can be interchanged under appropriate circumstances. This is only a way of distinguishing objects with the same attributes when describing the embodiments of the present application. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusion, so that a process, method, system, product or device including a series of units does not necessarily have to be limited to those units, but may include other units that are not clearly listed or are inherent to these processes, methods, products or devices.

[0046] Embodiment 1

[0047] As Figure 1As shown in the figure, this embodiment provides a graph database query execution engine, including: an execution plan generation module, a scheduling module, and an operator library, where,

[0048] The execution plan generation module is configured to:

[0049] Convert the logical execution plan of the query request into a set of physical operators, and add a storage access physical operator at the physical operator level to proxy the sub-plan pushed down to the storage layer for execution;

[0050] Based on the data dependency relationship between operators, encapsulate all physical operators into multiple independently schedulable execution components;

[0051] Construct a physical execution plan composed of execution components and submit it to the scheduling module;

[0052] The scheduling module is configured to:

[0053] Add each execution component in the physical execution plan to the execution queue;

[0054] Select execution components from the execution queue for scheduling according to the thread pool status, and manage the executing execution components according to the preset scheduling strategy;

[0055] The operator library is configured to:

[0056] Provide memory computing physical operators shared by the computing layer and the storage layer through a unified interface, including filtering physical operators, sorting physical operators, and joining physical operators.

[0057] In this embodiment, the graph database query execution engine includes an execution plan generation module, a scheduling module, and an operator library. Among them, the execution plan generation module is the outermost front-end interface of the query execution engine, mainly responsible for receiving the logical execution plan of the query request and converting it into a physical execution plan; the scheduling module, as the "resource coordination center" of the query execution engine, realizes fine-grained resource allocation of query tasks by dynamically scheduling execution components and responding to scheduling strategies in real time, ensuring system stability and fairness in high-concurrency scenarios; the operator library, as the "cross-layer computing cornerstone" of the query execution engine, realizes code-level reuse of physical operators such as filtering (Filter) physical operators, sorting (Sort) physical operators, and joining (Join) physical operators in the computing layer and the storage layer through a unified interface, eliminates cross-component redundancy, and improves development efficiency while ensuring the consistency of data processing logic.

[0058] It should be noted here that the logical execution plan is an abstract representation of the query, used to describe how to extract the required results from the data source through a series of operations. It consists of multiple logical operators and forms a tree-shaped or directed acyclic graph (DAG) structure.

[0059] After receiving the logical execution plan, the execution plan generation module first converts each logical operator included in it into a corresponding physical operator to obtain a set of physical operators. Among them, most logical operators and physical operators have a one-to-one relationship. For example, the conversion from the Filter logical operator to the Filter physical operator; however, there are also some logical operators that have a one-to-many relationship with physical operators. For example, the Join logical operator will be converted into a pair of physical operators - the JoinBuild physical operator and the JoinProbe physical operator. In this embodiment, JoinProbe is abbreviated as JoinProb.

[0060] The sub-plan that can be pushed down to the storage layer is also marked in the logical execution plan. This sub-plan is also essentially composed of logical operators. Based on this sub-plan, the execution plan generation module will add a StorageAccess physical operator to the obtained set of physical operators. This StorageAccess physical operator is used to proxy the sub-plan pushed down to the storage layer. It should be noted here that the storage layer connected by the query execution engine in this embodiment defaults to providing a computing push-down interface.

[0061] Furthermore, the StorageAccess physical operator is configured as:

[0062] In response to the data request of the downstream physical operator, obtain the bound table data from the storage layer through the remote procedure call mechanism;

[0063] The pushed-down sub-plan proxied includes Filter physical operators, NodeScan physical operators, or EdgeScan physical operators executed by the storage layer.

[0064] As a bridge between the query execution engine and the storage layer, the StorageAccess physical operator can not only push down the sub-plan to be pushed down to the storage layer, but also send data requests such as filtering, projection, and aggregation in the computing layer to the storage layer through the remote procedure call (RPC) mechanism and receive the bound table data returned by the storage layer. The BindingTable is an abstract structure used to encapsulate the data returned by the storage layer. By binding the data requests in the computing layer with the data access logic in the storage layer, it is possible to avoid transmitting irrelevant data and reduce the RPC overhead.

[0065] At the same time, in this embodiment, the pushed-down sub-plan proxied by the StorageAccess physical operator includes, but is not limited to, Filter physical operators, NodeScan physical operators, or EdgeScan physical operators.

[0066] By introducing the StorageAccess physical operator at the physical operator level, some sub-plans can be pushed down to the storage layer for execution, thereby reducing the data transfer volume and improving query performance.

[0067] Then, the execution plan generation module encapsulates all physical operators into multiple independently schedulable execution components according to the data dependency relationships between operators. The physical operators mentioned here include the added StorageAccess physical operator.

[0068] Among them, the data dependency relationship between operators refers to how the output data of one operator serves as the input data of another operator, and how this dependency affects the execution order, parallelism, and data flow. By analyzing the data dependency relationships between operators, the query plan can be effectively optimized and the system performance can be improved.

[0069] In this embodiment, the execution component is specifically a pipeline (Pipeline). Each Pipeline encapsulates a set of physical operators with data dependency relationships. The Pipeline is responsible for coordinating the data transfer and execution order between this set of physical operators. At the same time, the internal data of the Pipeline will flow through each physical operator in sequence.

[0070] Furthermore, the data transfer between physical operators within the execution component all adopts the bound table format;

[0071] The filtering operator filters the data in the bound table based on the mask operation of the bit set.

[0072] All physical operators uniformly use the BindingTable as the format for exchanging data between operators, avoiding format conversion and reducing the conversion and replication overhead of data between different physical operators. At the same time, in the Filter physical operator, the mask operation based on the bitset is directly used to quickly mark and filter out the qualified data from the BindingTable. This can not only avoid unnecessary data movement, but also significantly improve query performance by reducing the data scan range and utilizing efficient bit operations.

[0073] Furthermore, the unified interface includes a first interface for producing data, a second interface for consuming the data passed from the upstream, a third interface for notifying the upstream that data is needed, and a fourth interface for notifying the upstream that data is no longer needed.

[0074] The operator library internally maintains the status of physical operators and defines four unified interfaces for physical operators, namely the first interface produce for generating data, the second interface consume for consuming data passed from upstream, the third interface needDate for notifying upstream that data is required, and the fourth interface noMoreData for notifying upstream that data is no longer needed. Through these four unified interfaces, not only can the inner-layer computing operators be shared between the computing layer and the storage layer, thereby reducing code redundancy, improving development efficiency and maintainability, but also different levels of physical operators can be conveniently called and coordinated, enhancing the overall integration of the system.

[0075] Furthermore, the execution strategy of the execution component includes:

[0076] The downstream physical operator requests data from the upstream through the third interface;

[0077] After the upstream physical operator responds to the request, it generates data through the first interface and calls the second interface of the downstream to transfer the bound table data.

[0078] In this embodiment, the execution strategy of the Pipeline is to find physical operators that can generate data in the reverse direction of the data flow. That is, only when the downstream physical operator needs data, will it drive the upstream physical operator to generate data, which is the Pull-Based mode. Specifically, only when the downstream physical operator actively initiates a data request by calling the needDate interface of the upstream physical operator, indicating that it needs to obtain data, will the upstream physical operator call its own produce interface to generate data and transfer the data to the downstream physical operator by calling the consume interface of the downstream physical operator. When the downstream physical operator no longer needs data, it will call the noMoreData interface of the upstream physical operator to notify the upstream physical operator to stop data generation. By optimizing the execution strategy of the Pipeline, it is ensured that each physical operator can work efficiently and cooperatively, improving the parallelism and continuity of data processing.

[0079] Furthermore, the execution component is also configured to:

[0080] A single execution component is executed in one thread, and the internal data of the execution component flows through each physical operator in sequence.

[0081] In this embodiment, the execution of a single Pipeline is carried out in one thread, avoiding the overhead introduced by thread context switching.

[0082] In one embodiment, as Figure 2As shown, the logical execution plan includes a NodeScan operator, an EdgeScan operator, a Filter operator, a Join operator, and a Project operator. After performing physical operator conversion and adding StorageAccess operators, the final set of physical operators is obtained. Then, based on data dependencies, these physical operators are encapsulated to obtain Pipeline1 encapsulated by StorageAccess operators, JoinProb operators, and Project operators, Pipeline2 encapsulated by StorageAccess operators and JoinBuild operators, Pipeline3 encapsulated by NodeScan operators and Filter operators, and Pipeline4 encapsulated by EdgeScan operators.

[0083] After encapsulating to obtain Pipeline1, Pipeline2, Pipeline3, and Pipeline4, the execution plan generation module will organize these 4 Pipelines into a physical execution plan. Specifically, Pipeline1 and Pipeline2 are deployed at the computing layer to undertake the core computing logic, and Pipeline3 and Pipeline4 are sunk to the storage layer to directly interface with the storage engine and perform storage operations such as data scanning and predicate pushdown. At the same time, the computing layer and the storage layer achieve cross-layer communication through the Remote Procedure Call mechanism (RPC). Then, this physical execution plan is submitted to the scheduling module for execution.

[0084] It should also be noted here that in graph database queries, Project refers to extracting specific fields or attributes from the query results to generate a new result set containing only the required information.

[0085] The scheduling module is a globally shared scheduler that contains a thread pool and an execution queue. After receiving the physical execution plan submitted by the execution plan generation module, the scheduling module will put each Pipeline in this physical execution plan into the execution queue and take out at least one executable Pipeline from this execution queue for execution according to the execution situation of the thread pool.

[0086] Furthermore, the scheduling module is also configured to:

[0087] Support affinity scheduling based on non-uniform memory access to reschedule interrupted execution components to the original CPU core for execution.

[0088] After selecting an executable Pipeline, it is also necessary to select the CPU core to execute this Pipeline. In this embodiment, the scheduling module supports affinity scheduling based on non-uniform memory access (NUMA). That is to say, in a multi-node server environment, this scheduling module will reasonably allocate tasks and data according to the memory layout and CPU core distribution of the nodes, thereby reducing the cross-node memory access overhead and improving the overall system performance.

[0089] Specifically, when scheduling a certain Pipeline for the first time, the scheduling module will select the currently idle CPU core as the core to execute this Pipeline at this time, and record the CPU identifier (ID) information into this Pipeline. When rescheduling this Pipeline next time, query its historical scheduling information and consider CPU affinity, and try to schedule the execution to the same CPU core.

[0090] Furthermore, the preset scheduling policies include a cancellation policy, a suspension policy, and a yielding policy.

[0091] The scheduling module also pre-sets scheduling policies, including a Cancel policy, a pause policy, and a Yield policy.

[0092] Specifically, when the physical execution plan executes a cancel operation, the Pipeline belonging to this physical execution plan will be removed from the currently executing thread pool, this execution plan will be cancelled, and Canceled will be returned as the execution result; when the physical execution plan executes a pause operation, the Pipeline belonging to this physical execution plan will be removed from the currently executing thread pool, and only when the physical execution plan executes a resume operation will the Pipeline re-queue into the execution queue; when the physical execution plan executes a yield operation, the Pipeline belonging to this physical execution plan will be removed from the currently executing thread pool and re-added to the end of the execution queue, queuing up to wait to be scheduled.

[0093] By supporting operations such as Cancel, pause, and Yield, it allows tasks to pause execution at an appropriate time and release resources to other more urgent tasks.

[0094] Furthermore, the preset scheduling policies also include a time slice scheduling mechanism, which is used to allocate the same time slice to each currently executing execution component, and when the execution time of the execution component exceeds the threshold, it will be removed from the thread pool and re-added to the end of the execution queue.

[0095] In this embodiment, the scheduling module also introduces a time slice scheduling algorithm, which assigns the same time slice to each executing Pipeline. When the execution time of the Pipeline to be scheduled exceeds the time slice time, it will be removed from the thread pool and re-enter the end of the execution queue to queue up. Through the time slice scheduling mechanism, it is possible to avoid the situation where a certain Pipeline needs to process a large amount of data and occupies the thread for a long time, resulting in other Pipelines not being scheduled to run, ensuring the fair execution of tasks.

[0096] In one embodiment, as Figure 3 shown, the execution plan generation module converts the logical execution plan into a physical execution plan composed of Pipeline 1 and Pipeline 2. Among them, Pipeline 2 contains a StorageAccess operator and a JoinBuild operator, and Pipeline 1 contains a StorageAccess operator, a Filter operator, a JoinProb operator, and a Project operator, and submits Pipeline 1 and Pipeline 2 to the execution queue, waiting for the scheduler to schedule them to the thread pool for execution.

[0097] It should be noted here that JoinBuild and JoinProb are a pair of dependent physical operators obtained by the execution plan generation module converting the Join logical operator. Specifically, JoinBuild is responsible for constructing a hash table from the build-side data of the Join operation; after obtaining the hash table, JoinProb is responsible for querying the hash table to find the associated rows during the process of processing the data in the Prob table. However, before JoinProb obtains the hash table produced by the JoinBuild side, the Pipeline 1 where it is located will enter a blocked state when executing this physical operator. At the same time, before entering the Block state, JoinProb will register a future event waiting for the hash table construction to complete with JoinBuild through Future.wait(); after JoinBuild completes the hash table, JoinBuild will notify JoinProb that this future event has been completed through Promise::fulfill, waking up the blocked Pipeline 1.

[0098] Among them, in asynchronous programming, Future is an object representing the result of an asynchronous operation. It allows other tasks to continue execution before a certain operation is completed and obtain the result after the operation is completed. Promise is an object used in conjunction with Future. It represents a commitment of an asynchronous operation and allows setting the result after the operation is completed, thereby "completing" the relevant Future. In this embodiment, JoinProb collaborates with the Future and Promise mechanisms and JoinBuild to ensure that JoinProb can start probing the hash table only after the hash table construction is completed, thus effectively managing the dependencies of asynchronous operations and enabling the query execution to proceed efficiently.

[0099] The graph database query execution engine provided in this embodiment can simultaneously meet the performance requirements of OLTP and OLAP workloads through the sharing of in-memory computing physical operators between the computing layer and the storage layer, the optimization of the scheduling strategy of the scheduling module, and the optimized design of the core components. Compared with traditional query execution engines, the performance is improved several times or even higher.

[0100] Embodiment 2

[0101] This embodiment provides a graph database query execution method, which is applied to the graph database query engine described in Embodiment 1 and includes the following steps:

[0102] Convert the logical execution plan of the query request into a set of physical operators, and add storage access physical operators at the physical operator level to proxy the sub-plan pushed down to the storage layer for execution;

[0103] Based on the data dependencies between operators, encapsulate all physical operators into multiple independently schedulable execution components;

[0104] Construct a physical execution plan composed of execution components and submit it to the execution queue;

[0105] Select execution components from the execution queue for scheduling according to the thread pool status, and manage the executing execution components according to the preset scheduling strategy;

[0106] Among them, the in-memory computing physical operators in the execution components are shared between the computing layer and the storage layer through a unified interface.

[0107] This embodiment is used to implement the graph database query execution engine provided in the above embodiment and has the corresponding beneficial effects of the above engine. For technical details not described in detail in this embodiment, reference can be made to the engine provided in all the foregoing embodiments of the present invention.

[0108] The above-described embodiments merely represent several implementation manners of the present invention. The description thereof is relatively specific and detailed, but it should not be construed as a limitation on the scope of the patent for the present invention. It should be noted that for those of ordinary skill in the art, without departing from the concept of the present invention, several variations and improvements can still be made, and these all fall within the protection scope of the present invention. Therefore, the protection scope of the patent for the present invention shall be subject to the appended claims.

Claims

1. A graph database query execution engine, characterized in that, It includes: An execution plan generation module, a scheduling module, and an operator library; among them, The execution plan generation module is configured to: Convert the logical execution plan of the query request into a set of physical operators, and add storage access physical operators at the physical operator level to proxy the sub-plan pushed down to the storage layer for execution; Based on the data dependency relationship between operators, encapsulate all physical operators into multiple independently schedulable execution components; Construct a physical execution plan composed of the execution components and submit it to the scheduling module; The scheduling module is configured to: Add each execution component in the physical execution plan to the execution queue; Select execution components from the execution queue for scheduling according to the thread pool status, and manage the executing execution components according to the preset scheduling policy; The operator library is configured to: Provide in-memory computing physical operators shared by the computing layer and the storage layer through a unified interface, including filter physical operators, sort physical operators, and join physical operators.

2. The graph database query execution engine according to claim 1, characterized in that The data transmission between physical operators within the execution component all adopts a bound table format; The filter operator filters the data in the bound table based on the mask operation of the bit set.

3. The graph database query execution engine according to claim 2, wherein The storage access physical operator is configured to: Respond to the data request of the downstream physical operator, and obtain the bound table data from the storage layer through the remote procedure call mechanism; The proxy pushed-down sub-plan includes filter physical operators, point scan physical operators, or edge scan physical operators executed by the storage layer.

4. The graph database query execution engine according to claim 3, characterized in that, The unified interface includes a first interface for producing data, a second interface for consuming the data passed from the upstream, a third interface for notifying the upstream that data is needed, and a fourth interface for notifying the upstream that data is no longer needed.

5. The graph database query execution engine according to claim 4, wherein The execution strategy of the execution component includes: The downstream physical operator requests data from the upstream through the third interface; After the upstream physical operator responds to the request, it produces data through the first interface and calls the second interface of the downstream to transfer the bound table data.

6. The graph database query execution engine according to claim 5, characterized in that, The execution component is further configured to: A single execution component is executed in one thread, and the internal data of the execution component flows through each physical operator in sequence.

7. The graph database query execution engine according to claim 1, wherein The preset scheduling policy includes a cancellation policy, a suspension policy, and a yielding policy.

8. A graph database query execution engine according to claim 7, characterized in that, The preset scheduling policy further includes a time slice scheduling mechanism for allocating the same time slice to each executing execution component, and removing it from the thread pool and re-adding it to the end of the execution queue when the execution time of the execution component exceeds the threshold.

9. The graph database query execution engine according to claim 8, wherein The scheduling module is further configured to: Support affinity scheduling based on non-uniform memory access to reschedule the interrupted execution component to the original CPU core for execution.

10. A method for query execution in a graph database, characterized in that, Applied to the graph database query execution engine according to any one of claims 1 to 9, it includes the following steps: Convert the logical execution plan of the query request into a set of physical operators, and add storage access physical operators at the physical operator level to proxy the sub-plan pushed down to the storage layer for execution; Based on the data dependency relationship between operators, encapsulate all physical operators into multiple independently schedulable execution components; Construct a physical execution plan composed of the execution components and submit it to the execution queue; Select execution components from the execution queue according to the thread pool status and manage the executing execution components according to a preset scheduling policy; Among them, the in-memory computing physical operators in the execution components are shared between the computing layer and the storage layer through a unified interface.

Images