Query processing method, electronic equipment and storage medium

Abstract

The invention discloses a query processing method, electronic equipment and a storage medium. The method comprises the steps that graph query information is obtained, and the graph query information is used for representing an original logic execution plan obtained by compiling a pre-input graph query statement; intermediate presentation layer processing is carried out on the graph query information, a physical execution plan is constructed, and the intermediate presentation layer processing is at least used for carrying out correctness verification and query adjustment on the graph query information; based on the physical execution plan, a to-be-executed target query code is generated, and the target query code is used for obtaining a query result corresponding to the graph query statement. According to the method and the device, the technical problems of high calculation cost and low query efficiency of graph query caused by lengthy and complicated graph query process in related technologies are solved.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a query processing method, an electronic device, and a storage medium. Background Art

[0002] Graph data is a data structure used to model relationships between data. Compared to relational data structures, graph data expresses relationships more intuitively and has inherent advantages in storage and computing. Therefore, graph query technology based on graph data plays a key role in massive data analysis. The application of graph query technology faces the following two challenges. On the one hand, the query languages commonly used by users in application scenarios are diverse, and the cost of migrating between different query languages is extremely high. Therefore, graph query technology needs to be compatible with multiple common query languages. On the other hand, the graph query requirements of different application scenarios vary greatly, and graph query service scenarios are fragmented. To meet the graph query requirements in different application scenarios, it is necessary to introduce multiple computing engines into the graph query framework to adapt to various application scenarios.

[0003] As can be seen from the above, graph query frameworks need to adapt to multiple query languages and various application scenarios simultaneously. This results in a lengthy and complex graph query process, high computational costs, and low graph query efficiency. Currently, no effective solution has been proposed to address these issues. Summary of the Invention

[0004] The embodiments of the present application provide a query processing method, an electronic device, and a storage medium to at least solve the technical problem in the related art that the graph query process is lengthy and complicated, resulting in high graph query calculation cost and low query efficiency.

[0005] According to one aspect of an embodiment of the present application, a query processing method is provided, including: obtaining graph query information, wherein the graph query information is used to represent an original logical execution plan obtained by compiling a pre-input graph query statement; performing intermediate representation layer processing on the graph query information to construct a physical execution plan, wherein the intermediate representation layer processing is at least used to perform correctness verification and query adjustment on the graph query information; based on the physical execution plan, generating a target query code to be executed, wherein the target query code is used to obtain a query result corresponding to the graph query statement.

[0006] According to another aspect of an embodiment of the present application, a query processing method is also provided, including: obtaining a graph query request through a first application programming interface, wherein the request data carried in the graph query request includes: graph query information, the graph query information is used to represent the original logical execution plan obtained by compiling a pre-input graph query statement; returning a graph query response through a second application programming interface, wherein the response data carried in the graph query response includes: a query result corresponding to the graph query statement, the query result is obtained by executing a target query code, the target query code is generated based on a physical execution plan, the physical execution plan is constructed by performing intermediate representation layer processing on the graph query information, and the intermediate representation layer processing is at least used to perform correctness verification and query adjustment on the graph query information.

[0007] According to another aspect of an embodiment of the present application, a query processing method is also provided, including: obtaining a currently input graph query dialogue request, wherein the request data carried in the graph query dialogue request includes: graph query information, the graph query information is used to represent the original logical execution plan obtained by compiling a pre-input graph query statement; in response to the graph query dialogue request, returning a graph query dialogue reply, wherein the information carried in the graph query dialogue reply includes: a query result corresponding to the graph query statement, the query result is obtained by executing a target query code, the target query code is generated based on a physical execution plan, the physical execution plan is constructed by performing intermediate representation layer processing on the graph query information, the intermediate representation layer processing is at least used to perform correctness verification and query adjustment on the graph query information; and displaying the query results in a graphical user interface.

[0008] According to another aspect of an embodiment of the present application, a computer-readable storage medium is further provided, wherein the computer-readable storage medium includes a stored program, wherein when the program is executed, the device where the computer-readable storage medium is located is controlled to execute any one of the above-mentioned query processing methods.

[0009] According to another aspect of an embodiment of the present application, an electronic device is also provided, including: a processor; and a memory, connected to the above-mentioned processor, for providing the above-mentioned processor with instructions for processing the following processing steps: obtaining graph query information, wherein the graph query information is used to represent the original logical execution plan obtained by compiling a pre-input graph query statement; performing intermediate representation layer processing on the graph query information to construct a physical execution plan, wherein the intermediate representation layer processing is at least used to perform correctness verification and query adjustment on the graph query information; based on the physical execution plan, generating a target query code to be executed, wherein the target query code is used to obtain the query result corresponding to the graph query statement.

[0010] According to another aspect of an embodiment of the present application, an electronic device is further provided, including: a memory storing an executable program; and a processor for running the program, wherein any one of the above-mentioned query processing methods is executed when the program is running.

[0011] According to another aspect of an embodiment of the present application, a computer-readable storage medium is further provided, the computer-readable storage medium including a stored executable program, wherein when the executable program runs, the device where the computer-readable storage medium is located is controlled to execute any one of the above-mentioned query processing methods.

[0012] In an embodiment of the present application, graph query information is obtained, wherein the graph query information is used to represent an original logical execution plan obtained by compiling a pre-input graph query statement; the graph query information is processed at an intermediate representation layer to construct a physical execution plan, wherein the intermediate representation layer processing is at least used to perform correctness verification and query adjustment on the graph query information; based on the physical execution plan, a target query code to be executed is generated, wherein the target query code is used to obtain a query result corresponding to the graph query statement.

[0013] It is easy to notice that the present application constructs an intermediate representation layer between the compilation process of the graph query statement and the generation and execution process of the query code to decouple the compilation of the graph query statement from the code generation and execution. Before the intermediate representation layer, the compilation process of the graph query statement can adapt to a variety of query languages, and after the intermediate representation layer, the generation and execution process of the query code can adapt to the execution engines corresponding to a variety of application scenarios. Therefore, the present application achieves the purpose of reducing the complexity of the graph query process, thereby realizing the technical effect of saving the computational cost of the graph query process and improving the efficiency of the graph query, and thus solves the technical problem in the related technology that the graph query process is lengthy and complicated, resulting in high graph query computational cost and low query efficiency.

[0014] It is easy to notice that the above general description and the following detailed description are merely for the purpose of exemplifying and explaining the present application, and do not constitute a limitation of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings:

[0016] Figure 1 A hardware structure block diagram of a computer terminal (or mobile device) for implementing the query processing method is shown;

[0017] Figure 2 is a flowchart of a query processing method according to Example 1 of the present application;

[0018] Figure 3 It is a schematic diagram of a graph query system architecture based on related technologies;

[0019] Figure 4 is a schematic diagram of an optional graph query system architecture according to Example 1 of the present application;

[0020] Figure 5 is a flowchart of a query processing method according to Example 2 of the present application;

[0021] Figure 6 is a flowchart of a query processing method according to Example 3 of the present application;

[0022] Figure 7 is a structural diagram of a query processing device according to embodiment 4 of the present application;

[0023] Figure 8 is a structural diagram of another query processing device according to Example 4 of the present application;

[0024] Figure 9 is a structural diagram of another query processing device according to embodiment 4 of the present application;

[0025] Figure 10 This is a structural block diagram of a computer terminal according to Example 5 of the present application. DETAILED DESCRIPTION

[0026] In order to enable those skilled in the art to better understand the present invention, the following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments in the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts should fall within the scope of protection of this application.

[0027] It should be noted that the terms "first", "second", etc. in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects and are not necessarily used to describe a specific order or sequential order. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments of the present application described herein can be implemented in a sequence other than those illustrated or described herein. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions, for example, a process, method, system, product or device comprising a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0028] First, some nouns or terms that appear in the description of the embodiments of the present application are subject to the following interpretations:

[0029] Graph structure: refers to an abstract data structure consisting of nodes and edges connecting nodes.

[0030] Property Graph: A graph structure in which nodes and edges are attached with labels (such as products, users, etc.) and attribute information (such as name, age, etc.). These labels and attributes are used to indicate the category or nature of the node or edge.

[0031] Graph Traversal: It refers to the method of iteratively traversing along the edges in the graph structure from the node designated as the starting point to visit each associated node.

[0032] Graph Pattern Matching: refers to the process of finding all homomorphic mappings from the node set of the attribute graph G to the node set of the graph pattern Q based on a given attribute graph G and a graph pattern Q (usually a labeled attribute graph).

[0033] Graph query: A general term for various operations on property graphs, including graph traversal and graph pattern matching. Graph query operations typically access a small portion of the graph structure. Graph query languages, such as Gremlin and Cypher, are computer languages used to implement graph queries.

[0034] Graph statistics (GLogue): Count the number of nodes that match a pre-maintained small subgraph (with fewer than a certain threshold of nodes) in the attribute graph G, generating graph statistics. This graph statistics can be used to estimate the computational overhead of different query plans for a given query, thus assisting in selecting the query plan to execute.

[0035] Business Intelligence scenarios refer to graph query scenarios that are mainly used to mine complex decision-making information from business data.

[0036] Example 1

[0037] According to an embodiment of the present application, an embodiment of a query processing method is also provided. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and although a logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in an order different from that shown here.

[0038] The method embodiment provided in the first embodiment of the present application can be executed in a mobile terminal, a computer terminal or a similar computing device. Figure 1 FIG1 shows a hardware structure block diagram of a computer terminal (or mobile device) for implementing a query processing method. Figure 1 As shown, the computer terminal 10 (or mobile device 10) may include one or more processors 102 (illustrated as 102a, 102b, ..., 102n in the figure) (the processor 102 may include, but is not limited to, a processing device such as a microcontroller unit (MCU) or a programmable logic device (Field Programmable Gate Array, FPGA)), a memory 104 for storing data, and a transmission device 106 for communication functions. In addition, the computer terminal 10 may also include: a display, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of a computer bus), a network interface, a cursor control device (such as a mouse, a touchpad, etc.), a keyboard, a power supply, and / or a camera.

[0039] It can be understood by those skilled in the art that Figure 1 The structure shown is only for illustration and does not limit the structure of the above electronic device. Figure 1 More or fewer components than shown, or with Figure 1 Different configurations shown.

[0040] It should be noted that the one or more processors 102 and / or other data processing circuits described above may generally be referred to herein as "data processing circuitry". The data processing circuitry may be embodied in whole or in part as software, hardware, firmware, or any other combination thereof. In addition, the data processing circuitry may be a single independent processing module, or may be incorporated in whole or in part into any of the other components of the computer terminal 10 (or mobile device). As described in the embodiments of the present application, the data processing circuitry serves as a processor control (e.g., selection of a variable resistor terminal path connected to an interface).

[0041] The memory 104 can be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the query processing method in the embodiment of the present application. The processor 102 executes various functional applications and data processing by running the software programs and modules stored in the memory 104, that is, implementing the above-mentioned query processing method. The memory 104 may include a high-speed random access memory, and may also include a non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include a memory remotely located relative to the processor 102, and these remote memories may be connected to the computer terminal 10 via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0042] The transmission device 106 is configured to connect to a network via a network interface to receive or transmit data. Specific examples of the aforementioned network may include a wired and / or wireless network provided by the communications provider of the computer terminal 10. In one embodiment, the transmission device 106 includes a network interface controller (NIC), which can be connected to other network devices via a base station to enable communication with the Internet. In another embodiment, the transmission device 106 may be a radio frequency (RF) module configured to communicate with the Internet wirelessly.

[0043] like Figure 1 The display shown may be, for example, a touch screen liquid crystal display (LCD), which enables a user to interact with a user interface of the computer terminal 10 (or mobile device).

[0044] It should be noted that, in some optional embodiments, the above Figure 1 The computer device (or mobile device) shown may include hardware elements (including circuits), software elements (including computer code stored on a computer-readable medium), or a combination of hardware elements and software elements. Figure 1 This is merely one example of a particular embodiment and is intended to illustrate the types of components that may be present in the aforementioned computer device (or mobile device).

[0045] Under the above operating environment, this application provides Figure 2 The query processing method shown. Figure 2 is a flowchart of a query processing method according to Example 1 of the present application, such as Figure 2 As shown, the query processing method includes:

[0046] Step S21: obtaining graph query information, wherein the graph query information is used to represent an original logical execution plan obtained by compiling a pre-input graph query statement;

[0047] Step S22: performing intermediate representation layer processing on the graph query information to construct a physical execution plan, wherein the intermediate representation layer processing is at least used to perform correctness verification and query adjustment on the graph query information;

[0048] Step S23: Generate a target query code to be executed based on the physical execution plan, wherein the target query code is used to obtain the query result corresponding to the graph query statement.

[0049] The above-mentioned graph query language can be a graph query statement pre-input in a preset application scenario. The above-mentioned preset application scenarios may include but are not limited to: social network analysis scenarios (graph queries are used to discover key nodes, community structures, information propagation paths, etc. in social networks), bioinformatics scenarios (graph queries are used to analyze biological data such as genomes and protein interactions to help study issues such as gene regulation and disease treatment), recommendation system scenarios (graph queries are used for personalized recommendations, recommending relevant products, news, music, etc. based on user interests and behavior patterns), banking and financial scenarios (graph queries are used for identifying fraud, risk management, customer relationship management, etc.), logistics and supply chain management scenarios (graph queries are used to optimize path planning, inventory management, transportation scheduling, etc.), knowledge graph scenarios (graph queries are used to build knowledge graphs, integrate and analyze knowledge from different fields, and support applications such as intelligent question answering and information extraction), e-commerce scenarios (graph queries are used to analyze user behavior, product associations, sales forecasts, etc.), medical and health scenarios (graph queries are used for disease diagnosis, drug development, clinical pathway optimization, etc.), traffic planning scenarios (graph queries are used for traffic flow prediction, road optimization, intelligent traffic management, etc.), and intelligent search scenarios (graph queries are used to improve search engine result ranking, information retrieval, etc.).

[0050] The above-mentioned query processing method also includes: obtaining a graph query statement pre-input in a preset application scenario; using a target parsing compiler to compile the graph query statement to obtain an original logical execution plan, wherein the target parsing compiler is determined by the query language category corresponding to the graph query statement.

[0051] In graph querying, information describing graph queries that is independent of the graph query language is called an intermediate representation (IR). The graph query IR is an extension of the relational algebra of relational databases for graph queries. The IR layer is the part of the graph query architecture that processes graph queries based on the IR. The IR layer processes graph query information to verify its correctness and adjust queries, and constructs a physical execution plan based on the IR processing results.

[0052] Specifically, in the intermediate representation layer, the original logical execution plan represented by the graph query information is correctness-checked and query optimized to obtain an optimized logical execution plan, and a physical execution plan is further constructed based on the optimized logical plan.

[0053] It should be noted that in the embodiment of the present application, the logical execution plan (IR Logical Plan) refers to the logical part in the intermediate representation layer that is not related to physical execution. Before being processed by the intermediate representation layer, the graph query language will be compiled into a logical execution plan, and some logically equivalent optimization operations will be applied in the logical execution plan. The physical execution plan (IRPhysical Plan) refers to the physical execution-related information such as the perception computing engine and storage module added to the intermediate representation layer. In the intermediate representation layer in the graph query system framework, the graph query information is correctness checked and query adjustment is processed, and a physical execution plan can be constructed to determine the execution actions at the physical device level (for example, including the computing actions to be executed by the perception computing engine and the storage actions to be executed by the storage module, etc.). In other words, the physical execution plan enables the query to obtain optimization capabilities related to the physical environment.

[0054] In order to adapt to the graph query requirements in different application scenarios, based on the execution engine adapted to the specified application scenario and the physical execution plan, the target query code to be executed by the execution engine is generated. Furthermore, the execution engine is driven to execute the above target query code and obtain the query results corresponding to the graph query statement from the graph database.

[0055] In an embodiment of the present application, graph query information is obtained, wherein the graph query information is used to represent an original logical execution plan obtained by compiling a pre-input graph query statement; the graph query information is processed at an intermediate representation layer to construct a physical execution plan, wherein the intermediate representation layer processing is at least used to perform correctness verification and query adjustment on the graph query information; based on the physical execution plan, a target query code to be executed is generated, wherein the target query code is used to obtain a query result corresponding to the graph query statement.

[0056] It is easy to notice that the present application constructs an intermediate representation layer between the compilation process of the graph query statement and the generation and execution process of the query code to decouple the compilation of the graph query statement from the code generation and execution. Before the intermediate representation layer, the compilation process of the graph query statement can adapt to a variety of query languages, and after the intermediate representation layer, the generation and execution process of the query code can adapt to the execution engines corresponding to a variety of application scenarios. Therefore, the present application achieves the purpose of reducing the complexity of the graph query process, thereby realizing the technical effect of saving the computational cost of the graph query process and improving the efficiency of the graph query, and thus solves the technical problem in the related technology that the graph query process is lengthy and complicated, resulting in high graph query computational cost and low query efficiency.

[0057] Across application scenarios, users commonly use a wide variety of query languages. Common query languages include Gremlin (Graph Traversal Query Language), GSQL (Graph Structured Query Language), custom graph query extensions based on GSQL, and third-party vendor-developed query languages. The cost of migrating between different query languages is extremely high, so graph query technology needs to be compatible with multiple common query languages. Furthermore, graph query requirements vary significantly across different application scenarios, leading to fragmented graph query service scenarios. For example, the main application scenarios for graph query include business intelligence (BI), high-throughput, and hybrid scenarios. In BI scenarios, graph queries often involve multi-hop graph traversals and complex relational computations such as aggregation, deduplication, and sorting, placing a higher demand on low latency. In high-throughput scenarios, graph queries are relatively simple (e.g., one- or two-hop graph traversals), placing a higher demand on high throughput, meaning the ability to execute as many queries as possible per unit time. In hybrid scenarios, it is desirable to balance low latency requirements with high throughput requirements based on the specific scenario. To meet the graph query requirements in different application scenarios, it is necessary to introduce multiple computing engines into the graph query framework to adapt to various application scenarios.

[0058] In this regard, related technologies are proposed to adapt to multiple query languages and multiple application scenarios as much as possible. Figure 3The graph query system architecture shown in the figure. Taking N sets of computing engines adapted to M query languages and N application scenarios as an example, when performing graph queries, the M query languages need to be connected to N sets of computing engines respectively, that is, the graph query system architecture contains a total of M×N engineering implementations. For each of these engineering implementations, the entire process of "query statement parsing (Language Parsing), correctness verification (Query Validation), query optimization (Query Optimization) and physical implementation (Runtime Implementation)" needs to be completed. Therefore, the process in the entire graph query system architecture is lengthy and the structure is complex. The development and maintenance of the graph query system architecture is extremely difficult, and the efficiency of graph queries based on the graph query system architecture is low.

[0059] According to the above method provided in the embodiment of the present application, Figure 4 As shown in the graph query system architecture. Figure 4 As shown, Figure 3 Compared with the graph query system architecture shown in the figure, the original M×N engineering implementation part is covered by the intermediate representation layer (IR Layer) of the Graphical Interactive Query Engine (GIE). The intermediate representation layer is used to handle the two core tasks in the graph query process, namely graph query correctness verification and graph query optimization, while the parsing (Parsing) of multiple query languages (M in this case) is split into the clients corresponding to the multiple query languages, and the code generation (Codegen) of multiple sets of execution engines (N in this case) in multiple application scenarios is split into the engine running layer corresponding to the multiple sets of execution engines. Based on this, in the graph query system architecture provided by this application, M parsers (Parsers) are implemented for M query languages, and N sets of code generators (Codegen) are implemented for N sets of execution engines, which can enable the graph query system architecture to adapt to M query languages and N application scenarios at the same time. Reducing the number of engineering implementations in the graph query system architecture from M×N to M+N simplifies the system architecture and query process, reduces the difficulty of developing and maintaining the graph query system architecture, saves graph query computing costs, and improves graph query efficiency.

[0060] In addition, according to Figure 4The graph query system architecture shown decouples parsing for multiple query languages from code generation for multiple execution engines in various application scenarios. This allows for flexible and convenient deployment of query language parsing modules and engine code generation execution modules based on application requirements. Specifically, when deploying the graph query system architecture, users select the upper-level query language parsing module based on language requirements, and the lower-level engine code generation execution module based on scenario requirements. By combining these two modules with the intermediate representation layer of the graph interactive query engine, a highly flexible and user-friendly graph query system architecture can be assembled to meet both language and scenario requirements.

[0061] In particular, for some scenarios that need to meet the parsing and encoding requirements of multiple query languages and the engine code generation and execution requirements of multiple application scenarios, multiple parsers corresponding to multiple query languages can be integrated in the upper-level query language parsing module, and multiple sets of engines can be integrated and built in the lower-level engine code generation and execution module. When the user initiates a graph query, the engine to be used is selected according to the query entered by the user to generate code and execute the query.

[0062] The following combination Figure 4 Some preferred implementation methods of the query processing method provided in the embodiments of the present application are further described.

[0063] In an optional embodiment, in step S21, obtaining graph query information includes the following method steps: Figure 2 Not shown):

[0064] Step S211: obtaining a graph query statement, wherein the graph query statement is written in a target query language among multiple query languages;

[0065] Step S212: parse and compile the graph query statement to obtain graph query information.

[0066] In the above optional embodiments, the multiple query languages can be various types of query languages commonly used by users, including: Gremlin, GSQL, Cypher (a declarative graph database query language), graph query customized extension languages based on structured query language, query languages developed by third-party manufacturers, etc. This application does not preemptively refer to these. The above target query language can be any one of the above multiple query languages.

[0067] According to the above method steps, in the application scenario, users can arbitrarily select the target query language to write graph query statements and input them into the client of the graph query system architecture provided by the embodiment of this application. The client can support parsing and compilation of graph query statements corresponding to multiple query languages.

[0068] In an optional embodiment, in step S212, parsing and compiling the graph query statement to obtain graph query information includes the following method steps:

[0069] Step S2121: using a target parser corresponding to the target query language to parse the graph query statement and obtain a parsing result;

[0070] Step S2122, compile the parsing results to obtain graph query information, wherein the graph query information includes multiple intermediate representation operators corresponding to the original logical execution plan, and the operator types of the multiple intermediate representation operators include relational algebra operators and graph operation operators.

[0071] In the above optional embodiment, according to the target query language, a target parser is selected from a plurality of parsers corresponding to a plurality of query languages, wherein the target parser is used to parse the graph query statement written in the target query language; the target parser is used to parse the graph query statement to obtain a parsing result, and the parsing result is compiled to obtain graph query information.

[0072] In an exemplary application scenario, after the user submits a graph query statement to GIE through the client, the client will use the pre-registered target parser corresponding to the graph query statement to parse and compile the graph query statement, and obtain a raw logical execution plan (Raw Logical Plan) containing multiple IR operators. The raw logical execution plan is passed to the intermediate representation layer of GIE as graph query information.

[0073] Specifically, the relational algebra operators in the above-mentioned multiple IR operators are inherited from relational algebra operations (RelationalAlgebra). For example, the relational algebra operators may include prediction operators (Projection), selection operators (Selection), grouping operators (Grouping), sorting operators (Ordering), etc. The graph operation operators in the above-mentioned multiple IR operators include point acquisition operators (GetV), edge expansion operators (EdgeExpansion) and path expansion operators (PathExpansion). Among them, the point acquisition operator is used to obtain points that meet the conditions from a given edge, the edge expansion operator is used to expand the edges that meet the conditions from a specific point, and the path expansion operator is used to expand the paths that meet the conditions from a specific point. Here, the path represents the continuous expansion of edges with a specific number of hops.

[0074] According to the above method steps, before the IR layer of GIE, the parsing and compilation of the graph query statement are completed in the target client corresponding to the graph query statement, without the need for docking between multiple query languages and multiple execution engines, thereby simplifying the system architecture.

[0075] In an optional embodiment, in step S22, the graph query information is processed in an intermediate representation layer to construct a physical execution plan, including the following method steps:

[0076] Step S221: Performing a correctness check on the graph query information to obtain a check result, wherein the check result includes some intermediate representation operators that pass the check among the multiple intermediate representation operators corresponding to the original logical execution plan;

[0077] Step S222: performing query adjustment processing on the verification result to obtain an adjusted logical execution plan, wherein the adjusted logical execution plan includes target intermediate representation operators that meet the adjustment conditions in some intermediate representation operators;

[0078] Step S223: construct a physical execution plan based on the adjusted logical execution plan.

[0079] In an exemplary application scenario, Figure 4 As shown in Figure 1, the IR layer of GIE includes a query validator, a query optimizer, and a job builder. The query validator verifies the graph query information for correctness, generating a validation result. The query optimizer then optimizes the validation result to generate an adjusted logical execution plan. The job builder then constructs a physical execution plan based on the adjusted logical execution plan.

[0080] It is easy to notice that in Figure 4 In the graph query system architecture shown, the correctness verification and graph query optimization parts of the graph query do not need to be repeatedly implemented for M query languages and N application scenarios. These two parts usually occupy most of the workload of the entire graph query processing flow (usually more than 80% of the workload based on experience). Therefore, the graph query system architecture provided by this application can greatly save graph query computing costs when the numbers M and N are large.

[0081] In an optional embodiment, in step S221, performing correctness verification processing on the graph query information to obtain a verification result includes at least one of the following method steps:

[0082] Step S2211: Perform a correctness check on the graph query information according to a validity check strategy to obtain a verification result, wherein the validity check strategy is used to check whether the connection relationship between multiple intermediate representation operators meets the preset connection rules;

[0083] Step S2212: According to the type verification strategy, the graph query information is verified for correctness to obtain a verification result, wherein the type verification strategy is used to check whether the expression operator in the multiple intermediate representation operators meets the operation support conditions. The expression operator is any operator in the multiple intermediate representation operators that contains an operation expression. The operation support condition is used to characterize whether the field type of the target data field corresponding to the expression operator supports completing the operation corresponding to the operation expression.

[0084] In the above optional embodiment, the above method further includes: generating error information based on operators in the graph query information that fail to pass the correctness check, and returning the error information to the client.

[0085] In an exemplary application scenario, in the process of using a query validator to perform correctness verification on graph query information, on the one hand, it is checked whether the connection relationship between multiple IR operators is legal. The connection relationship refers to the relationship between two IR operators connected by edges in the graph structure. Whether the connection relationship is legal is usually determined by the operator properties of the two IR operators (such as input data type, output data type, operator type, etc.). On the other hand, for IR operators containing expressions, the field type of the target data field corresponding to the IR operator is obtained and it is determined whether the field type can complete the subsequent arithmetic operations and logical operations corresponding to the IR operator.

[0086] Specifically, taking the execution plan fragment "EdgeExpansion.EdgeExpansion" as an example, check whether the connection relationship between the EdgeExpansion operator and the EdgeExpansion operator in this execution plan fragment is legal. It is easy to find that because the EdgeExpansion operator generates edge-type data, the EdgeExpansion operator then wants to obtain edge-type data again. However, the EdgeExpansion operator can only obtain edge-type data from points, and cannot continue to obtain edge-type data from the edge-type data generated by the EdgeExpansion operator. Therefore, such an execution plan is illegal (that is, it does not meet the preset connection rules). Operators with legal connection relationships are regarded as operators that have passed the legality check.

[0087] Specifically, for an operator containing the expression "age+1>10" as a filter condition, the query validator obtains the field type of the "age" field from the database schema and determines whether the field type supports the subsequent arithmetic and logical operations performed by the operator. Operators whose field types can support the subsequent arithmetic and logical operations are considered to have passed type verification.

[0088] The operators that pass both the legality check and the type check are determined as the intermediate representation operators that pass the check in the original logical execution plan, that is, the IR operators in the check result.

[0089] Through the above method and steps, the correctness verification of graph queries is completed at the IR layer of GIE, thereby ensuring the correct, efficient and secure execution of graph queries, while improving the stability and reliability of the graph query system.

[0090] In an optional embodiment, in step S222, query adjustment processing is performed on the verification result to obtain an adjusted logical execution plan, including the following method steps:

[0091] Step S2221: query and adjust the verification result based on the preset adjustment rule, filter out the intermediate representation operators that do not meet the preset adjustment rule in some intermediate representation operators, and obtain the rule adjustment result;

[0092] Step S2222: Based on the graph statistical information, an adjusted logical execution plan is selected from multiple candidate query plans corresponding to the rule adjustment result, wherein the graph statistical information includes: graph pattern matching data corresponding to multiple subgraphs and attribute graphs pre-maintained under a preset application scenario.

[0093] In an exemplary application scenario, a query optimizer is used to first perform query optimization based on preset adjustment rules (Rule-based Optimization, RBO). The preset adjustment rules include but are not limited to: node selection order optimization rules, which select an appropriate node access order to minimize the query depth and the number of node accesses, thereby reducing the query complexity; edge selection order optimization rules, which select the optimal edge traversal order to minimize the number of edge accesses and reduce the time complexity of the query; filter condition push-down optimization rules, which push the filter conditions to a location as close to the data source as possible to reduce unnecessary data transmission and processing, and can also reduce the amount of data that needs to be transferred by applying the filter conditions at the location closest to the data source; connection operation optimization rules, which select an appropriate connection algorithm for connection operations between multiple nodes, such as using a minimum spanning tree or a shortest path algorithm, to reduce the computational complexity of the connection; index utilization rules, which utilize the index structure that may exist in the graph database to quickly locate and access nodes. Select appropriate index types and optimize index usage to improve query performance; cache utilization rules: utilize query result caching, especially for repeatedly executed queries; parallel execution rules: decompose query tasks into subtasks when possible and leverage parallel processing capabilities to accelerate the overall query process; memory management optimization rules: effectively utilize memory to reduce disk access during query execution; statistical information utilization rules: utilize statistical information in the graph database, such as the degree distribution of nodes and edges, to optimize query plans; dynamic optimization rules: dynamically adjust optimization strategies based on query execution to adapt to different data distributions and query patterns. These preset adjustment rules can be flexibly set based on the specific graph database or graph query language type.

[0094] Furthermore, the query optimizer first performs cost-based optimization (CBO) based on computational cost estimation. Based on pre-acquired graph statistics, an adjusted logical execution plan is selected from multiple candidate query plans corresponding to the rule adjustment results. Through the above method and steps, query optimization in the graph query process is implemented in the IR layer of GIE, thereby improving graph query performance and efficiency.

[0095] In an optional embodiment, in step S2222, based on the graph statistical information, selecting an adjusted logical execution plan from multiple candidate query plans corresponding to the rule adjustment result includes the following method steps:

[0096] Step S2223: Using the graph statistical information, estimate the computational cost of multiple candidate operators in the rule adjustment result to obtain operator cost information;

[0097] Step S2224: construct multiple candidate query plans based on multiple candidate operators in the rule adjustment result;

[0098] Step S2225: Calculate query cost information of multiple candidate query plans based on the operator cost information;

[0099] Step S2226 : Using the query cost information, select an adjusted logical execution plan from multiple candidate query plans.

[0100] In an exemplary application scenario, the graph statistics are provided by GLogue. Using this information, the computational overhead of IR operators that pass query correctness checks and the RBO is estimated, yielding the query computational overhead corresponding to each IR operator. In other words, the operator overhead information includes the estimated query computational overhead for each of the multiple IR operators.

[0101] The graph statistics mentioned above include information about the number of specific structures in the graph maintained by GLogue. These specific structures include various types of vertices, multiple types of edges, and subgraphs composed of vertices and edges. Before query optimization, this graph statistics is calculated and stored in the GLogue structure.

[0102] It is easy to notice that in the method steps provided in the embodiment of the present application, since the number of subgraphs of a specific structure is taken into account in the graph statistical information, the efficiency of the operator calculation overhead estimation will be higher. For example, a certain graph query requires finding the combination of all people living in the same city, that is, "A:Person->B:Person, A:Person->C:City, B:Person->C:City". However, usually the number of "Person->Person" type edges in the graph is in the hundreds of billions, and the number of "Person->City" type edges in the graph is in the tens of millions. If all "Person->Person" edges are found first, and then one by one, whether the two persons corresponding to the edges correspond to the same city, the amount of calculation will be very large and the efficiency will be extremely low. If the graph statistical information in the embodiment of the present application is adopted, using the pre-counted number of subgraphs of a specific structure, first find all combinations of "Person->City", and then for each combination, obtain the set of another person by finding the intersection of the two sets of the person's friends and the residents of the city, that is, obtain the "Person->Person" that meets the condition "living in the same city".

[0103] The above-mentioned multiple candidate query plans are all possible query plans that can be implemented based on the multiple candidate operators in the rule adjustment results. Each query plan may use some or all of the multiple candidate operators. Based on the query calculation overhead of each candidate operator in the multiple candidate operators, the planned query cost of each candidate query plan is calculated. In other words, the query cost information includes the planned query cost of each candidate query plan in the multiple candidate query plans. Furthermore, the candidate query plan with the lowest planned query cost is selected from the multiple candidate query plans to obtain the adjusted logical execution plan.

[0104] In an optional embodiment, in step S2224, multiple candidate query plans are constructed based on multiple candidate operators in the rule adjustment result, including the following method steps:

[0105] Step S2227, orchestrate some or all of the multiple candidate operators to construct multiple candidate query plans that can complete the query tasks corresponding to the graph query statement, wherein the orchestration includes at least one of the following: sorting processing, combination processing, and equivalent transformation processing.

[0106] In the above optional embodiment, when constructing multiple candidate query plans, the candidate operators may be sorted, combined, and subjected to equivalent transformations. In other words, the adjusted logical execution plan may include optimized IR operators not included in the original logical execution plan. These optimized IR operators are obtained by transforming one or more IR operators in the original logical execution plan according to equivalent transformation rules.

[0107] Therefore, in the query processing method provided in the embodiment of the present application, all query plans that may be implemented by multiple candidate operators are fully considered when performing graph query optimization, and a query plan with lower query calculation cost and higher query efficiency can be obtained.

[0108] In an optional embodiment, in step S223, constructing a physical execution plan based on the adjusted logical execution plan includes the following method steps:

[0109] Step S2231: inserting the physical execution information corresponding to the graph query engine into the adjusted logical execution plan to obtain an insertion result;

[0110] Step S2232: Convert the target intermediate representation operator in the insertion result into the corresponding operator library to obtain a physical execution plan.

[0111] In an exemplary application scenario, the physical execution information corresponding to the graph query engine is used to determine: whether the execution engine is distributed, whether the graph database is partitioned, and whether the engine has pre-registered algorithm libraries (such as the shortest path algorithm). At the GIE IR layer, the job builder constructs a physical execution plan based on the adjusted logical execution plan. The physical execution information is inserted into the adjusted logical execution plan to obtain the insertion result.

[0112] In addition, the above method further includes: adding shuffling semantic information to the insertion result, and updating the insertion result to ensure that the calculation partitions and storage partitions in the adjusted logical execution plan are aligned.

[0113] Furthermore, the target intermediate representation operator in the insertion result is converted into the corresponding operator library to obtain the physical execution plan. At this point, the intermediate representation layer processing is completed and the physical execution plan is transmitted to the running layer of GIE.

[0114] In an optional embodiment, in step S23, based on the physical execution plan, generating target query code to be executed includes the following method steps:

[0115] Step S231 , compiling the physical execution plan and the first system component to obtain a compilation result, wherein the first system component includes a system component corresponding to a preset high-throughput executor;

[0116] Step S232: Generate native code based on the compilation result to obtain the target query code.

[0117] In an exemplary application scenario, native code generation is performed for the high-throughput graph query requirements of the application scenario. Specifically, the physical execution plan is loaded into the running layer architecture, and the code generator corresponding to the preset high-throughput executor will compile the physical execution plan and the first system component to obtain a compilation result. For example, the above-mentioned high-throughput executor is Hiactor, and correspondingly, the first system component is the Hiactor library. Native code generation is performed based on the physical execution plan and the Hiactor library to obtain the Hiactor program (that is, the target query code).

[0118] Furthermore, the above compilation results are mounted into the engine execution layer in the form of a dynamic link library, and the globally unique ID corresponding to the compilation result is returned to the user. Thereafter, the user uses the globally unique ID and query parameters to quickly access the engine execution module corresponding to the compilation result for graph query.

[0119] Through the above method steps, a high-throughput engine execution module is built in the graph query system architecture. After the target query code is generated, the target query code is executed using a preset high-throughput executor, and the query result corresponding to the graph query statement is obtained from the graph database, and the query result is returned to the corresponding client to provide to the user.

[0120] In an optional embodiment, in step S23, based on the physical execution plan, generating target query code to be executed includes the following method steps:

[0121] In step S233, based on the physical execution plan, the second system component and the precompilation result, analytical code generation is performed to obtain the target query code, wherein the second system component includes the system component corresponding to the preset low-latency executor, and the precompilation result is obtained by precompiling multiple physical operators registered under the preset application scenario.

[0122] In one exemplary application scenario, descriptive code generation is performed to meet the low-latency requirements of graph queries. Multiple physical operators registered for a given application scenario are precompiled to generate precompiled results, which are then used for code generation. This avoids the operator compilation process required in native code generation and reduces system latency for graph queries.

[0123] For example, if the low-latency executor is Pegasus, the second system component is the Pegasus library. This performs descriptive code generation based on the physical execution plan, the Pegasus library, and the precompiled operator results to produce a Pegasus program (i.e., the target query code). Furthermore, Pegasus is driven to execute the Pegasus program, retrieve the query results corresponding to the graph query statement from the graph database, and return the query results to the corresponding client for the user.

[0124] In another exemplary application scenario, the native code generation module and the parsed code generation module can be integrated into the execution layer of GIE, so that the graph query system architecture can flexibly provide high-throughput graph query services and low-latency graph query services according to the user's query requirements.

[0125] It is easy to notice that after setting up the IR layer in GIE, multiple execution engines in the execution layer (such as Hiactor and Pegasus) can be decoupled from multiple query languages. In other words, multiple execution engines do not need to connect to various query languages separately, but instead connect to a unified physical execution plan (Physical Plan), which can greatly reduce engineering workload.

[0126] In summary, the method provided in the embodiment of the present application can achieve the following technical effects: through a query language-independent graph query intermediate representation, compilation of multiple query languages is realized; equivalent transformation rules are introduced during query optimization, equivalent transformations in subgraph matching scenarios are considered, and the performance of subgraph matching queries is improved; rule-based query optimization (RBO) and cost-based query optimization (CBO) are improved. Since high-order statistical information is introduced into the graph statistical information (including not only statistical information of points and edges, but also statistical information of subgraphs of specific structures), the accuracy of operator overhead estimation in the cost-based query optimization process is improved, which is conducive to the derivation of more efficient query plans; different code generation schemes are proposed for different scenarios, so that graph queries in various scenarios can achieve better execution effects.

[0127] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data must comply with the relevant laws, regulations and standards of relevant countries and regions, and provide corresponding operation entrances for users to choose to authorize or refuse.

[0128] It should be noted that for the aforementioned method embodiments, for the sake of simplicity, they are all expressed as a series of action combinations, but those skilled in the art should be aware that this application is not limited by the order of the actions described, because according to this application, certain steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also be aware that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily required by this application.

[0129] Through the description of the above implementation methods, those skilled in the art can clearly understand that the method according to the above embodiment can be implemented by means of software plus the necessary general hardware platform, and of course can also be implemented by hardware. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art, can be embodied in the form of a software product, which is stored in a storage medium (such as a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk), and includes a number of instructions for enabling a terminal device (which can be a mobile phone, a computer, a server, or a network device, etc.) to execute the methods described in each embodiment of the present application.

[0130] Example 2

[0131] In the operating environment as in Example 1, the present application provides Figure 5 Another query processing method shown. Figure 5 is a flowchart of a query processing method according to Example 2 of the present application, such as Figure 5 As shown, the query processing method includes:

[0132] Step S51: obtaining a graph query request through a first application programming interface, wherein the request data carried in the graph query request includes: graph query information, the graph query information being used to represent an original logical execution plan obtained by compiling a pre-input graph query statement;

[0133] Step S52: Return the graph query response through the second application programming interface, wherein the response data carried in the graph query response includes: the query result corresponding to the graph query statement, the query result is obtained by executing the target query code, the target query code is generated based on the physical execution plan, the physical execution plan is constructed by performing intermediate representation layer processing on the graph query information, and the intermediate representation layer processing is at least used for correctness verification and query adjustment of the graph query information.

[0134] According to the above method steps, a method for implementing a query processing cloud service is provided, which runs on a cloud server. The cloud server obtains a graph query request issued by a service caller through a first application programming interface, executes a query processing process based on the request data (i.e., graph query information) carried in the graph query request, and thereby obtains a query result corresponding to the graph query statement. Furthermore, the cloud server returns a graph query response to the service caller through a second application programming interface to provide the query result to the service caller.

[0135] The above-mentioned graph query language can be a graph query statement pre-input in a preset application scenario. The above-mentioned preset application scenarios may include but are not limited to: social network analysis scenarios (graph queries are used to discover key nodes, community structures, information propagation paths, etc. in social networks), bioinformatics scenarios (graph queries are used to analyze biological data such as genomes and protein interactions to help study issues such as gene regulation and disease treatment), recommendation system scenarios (graph queries are used for personalized recommendations, recommending relevant products, news, music, etc. based on user interests and behavior patterns), banking and financial scenarios (graph queries are used for identifying fraud, risk management, customer relationship management, etc.), logistics and supply chain management scenarios (graph queries are used to optimize path planning, inventory management, transportation scheduling, etc.), knowledge graph scenarios (graph queries are used to build knowledge graphs, integrate and analyze knowledge from different fields, and support applications such as intelligent question answering and information extraction), e-commerce scenarios (graph queries are used to analyze user behavior, product associations, sales forecasts, etc.), medical and health scenarios (graph queries are used for disease diagnosis, drug development, clinical pathway optimization, etc.), traffic planning scenarios (graph queries are used for traffic flow prediction, road optimization, intelligent traffic management, etc.), and intelligent search scenarios (graph queries are used to improve search engine result ranking, information retrieval, etc.).

[0136] The above-mentioned query processing method also includes: obtaining a graph query statement pre-input in a preset application scenario; using a target parsing compiler to compile the graph query statement to obtain an original logical execution plan, wherein the target parsing compiler is determined by the query language category corresponding to the graph query statement.

[0137] In graph querying, the information used to describe the query, independent of the graph query language, is called an intermediate representation. The intermediate representation for graph queries is an extension of the relational algebra of relational databases specifically designed for graph queries. The intermediate representation layer is the component of the graph query architecture that processes graph queries based on the intermediate representation. The intermediate representation layer processes graph query information to verify its correctness and adjust queries. Physical execution plans are then constructed based on the results of the intermediate representation processing.

[0138] Specifically, in the intermediate representation layer, the original logical execution plan represented by the graph query information is correctness-checked and query optimized to obtain an optimized logical execution plan, and a physical execution plan is further constructed based on the optimized logical plan.

[0139] It should be noted that in the embodiments of this application, the logical execution plan refers to the logical portion of the intermediate representation layer that is unrelated to physical execution. Before being processed by the intermediate representation layer, the graph query language is compiled into a logical execution plan, in which some logically equivalent optimization operations are applied. The physical execution plan refers to information related to physical execution, such as the perception computing engine and storage module added to the intermediate representation layer. The physical execution plan enables queries to obtain optimization capabilities related to the physical environment.

[0140] In order to adapt to the graph query requirements in different application scenarios, based on the execution engine adapted to the specified application scenario and the physical execution plan, the target query code to be executed by the execution engine is generated. Furthermore, the execution engine is driven to execute the above target query code and obtain the query results corresponding to the graph query statement from the graph database.

[0141] In an embodiment of the present application, a graph query request is obtained through a first application programming interface, wherein the request data carried in the graph query request includes: graph query information, which is used to represent the original logical execution plan obtained by compiling a pre-input graph query statement; a graph query response is returned through a second application programming interface, wherein the response data carried in the graph query response includes: a query result corresponding to the graph query statement, which is obtained by executing a target query code, which is generated based on a physical execution plan, which is constructed by performing intermediate representation layer processing on the graph query information, and the intermediate representation layer processing is at least used to perform correctness verification and query adjustment on the graph query information.

[0142] It is easy to notice that the present application constructs an intermediate representation layer between the compilation process of the graph query statement and the generation and execution process of the query code to decouple the compilation of the graph query statement from the code generation and execution. Before the intermediate representation layer, the compilation process of the graph query statement can adapt to a variety of query languages, and after the intermediate representation layer, the generation and execution process of the query code can adapt to the execution engines corresponding to a variety of application scenarios. Therefore, the present application achieves the purpose of reducing the complexity of the graph query process, thereby realizing the technical effect of saving the computational cost of the graph query process and improving the efficiency of the graph query, and thus solves the technical problem in the related technology that the graph query process is lengthy and complicated, resulting in high graph query computational cost and low query efficiency.

[0143] It should be noted that the preferred implementation of this embodiment can be found in the relevant description in Example 1 and will not be repeated here.

[0144] Example 3

[0145] In the operating environment as in Example 1, the present application provides Figure 6 Another query processing method shown. Figure 6is a flowchart of a query processing method according to Example 3 of the present application, such as Figure 6 As shown, the query processing method includes:

[0146] Step S61: obtaining a currently input graph query dialog request, wherein the request data carried in the graph query dialog request includes: graph query information, which is used to represent an original logical execution plan obtained by compiling a pre-input graph query statement;

[0147] Step S62: In response to the graph query dialogue request, a graph query dialogue reply is returned, wherein the information carried in the graph query dialogue reply includes: a query result corresponding to the graph query statement, the query result being obtained by executing a target query code, the target query code being generated based on a physical execution plan, the physical execution plan being constructed by performing intermediate representation layer processing on the graph query information, the intermediate representation layer processing being used at least for correctness verification and query adjustment of the graph query information;

[0148] Step S63: Display the query results in the graphical user interface.

[0149] According to the above method steps, a visualization solution for query processing functions is provided. The terminal device provides a graphical user interface, in which at least one query processing scenario is displayed. The display content of the graphical user interface also includes an input component (such as a text input box, a voice input control, etc.) and a display component (such as a text display window, an image display window, etc.). The user inputs a graph query dialogue request through the input component to specify the graph query information corresponding to the graph query processing task. After detecting the user's input behavior, the query processing process is executed based on the graph query information to obtain the query result corresponding to the graph query statement. Further, the query result is displayed through the display component in the graphical user interface.

[0150] The above-mentioned graph query language can be a graph query statement pre-input in a preset application scenario. The above-mentioned preset application scenarios may include but are not limited to: social network analysis scenarios (graph queries are used to discover key nodes, community structures, information propagation paths, etc. in social networks), bioinformatics scenarios (graph queries are used to analyze biological data such as genomes and protein interactions to help study issues such as gene regulation and disease treatment), recommendation system scenarios (graph queries are used for personalized recommendations, recommending relevant products, news, music, etc. based on user interests and behavior patterns), banking and financial scenarios (graph queries are used for identifying fraud, risk management, customer relationship management, etc.), logistics and supply chain management scenarios (graph queries are used to optimize path planning, inventory management, transportation scheduling, etc.), knowledge graph scenarios (graph queries are used to build knowledge graphs, integrate and analyze knowledge from different fields, and support applications such as intelligent question answering and information extraction), e-commerce scenarios (graph queries are used to analyze user behavior, product associations, sales forecasts, etc.), medical and health scenarios (graph queries are used for disease diagnosis, drug development, clinical pathway optimization, etc.), traffic planning scenarios (graph queries are used for traffic flow prediction, road optimization, intelligent traffic management, etc.), and intelligent search scenarios (graph queries are used to improve search engine result ranking, information retrieval, etc.).

[0151] The above-mentioned query processing method also includes: obtaining a graph query statement pre-input in a preset application scenario; using a target parsing compiler to compile the graph query statement to obtain an original logical execution plan, wherein the target parsing compiler is determined by the query language category corresponding to the graph query statement.

[0152] In graph querying, the information used to describe the query, independent of the graph query language, is called an intermediate representation. The intermediate representation for graph queries is an extension of the relational algebra of relational databases specifically designed for graph queries. The intermediate representation layer is the component of the graph query architecture that processes graph queries based on the intermediate representation. The intermediate representation layer processes graph query information to verify its correctness and adjust queries. Physical execution plans are then constructed based on the results of the intermediate representation processing.

[0153] Specifically, in the intermediate representation layer, the original logical execution plan represented by the graph query information is correctness-checked and query optimized to obtain an optimized logical execution plan, and a physical execution plan is further constructed based on the optimized logical plan.

[0154] It should be noted that in the embodiments of this application, the logical execution plan refers to the logical portion of the intermediate representation layer that is unrelated to physical execution. Before being processed by the intermediate representation layer, the graph query language is compiled into a logical execution plan, in which some logically equivalent optimization operations are applied. The physical execution plan refers to information related to physical execution, such as the perception computing engine and storage module added to the intermediate representation layer. The physical execution plan enables queries to obtain optimization capabilities related to the physical environment.

[0155] In order to adapt to the graph query requirements in different application scenarios, based on the execution engine adapted to the specified application scenario and the physical execution plan, the target query code to be executed by the execution engine is generated. Furthermore, the execution engine is driven to execute the above target query code and obtain the query results corresponding to the graph query statement from the graph database.

[0156] In an embodiment of the present application, a currently input graph query dialogue request is obtained, wherein the request data carried in the graph query dialogue request includes: graph query information, which is used to represent the original logical execution plan obtained by compiling the pre-input graph query statement; in response to the graph query dialogue request, a graph query dialogue reply is returned, wherein the information carried in the graph query dialogue reply includes: a query result corresponding to the graph query statement, which is obtained by executing the target query code, which is generated based on the physical execution plan, which is constructed by performing intermediate representation layer processing on the graph query information, and the intermediate representation layer processing is at least used to perform correctness verification and query adjustment on the graph query information; and the query result is displayed in a graphical user interface.

[0157] It is easy to notice that the present application constructs an intermediate representation layer between the compilation process of the graph query statement and the generation and execution process of the query code to decouple the compilation of the graph query statement from the code generation and execution. Before the intermediate representation layer, the compilation process of the graph query statement can adapt to a variety of query languages, and after the intermediate representation layer, the generation and execution process of the query code can adapt to the execution engines corresponding to a variety of application scenarios. Therefore, the present application achieves the purpose of reducing the complexity of the graph query process, thereby realizing the technical effect of saving the computational cost of the graph query process and improving the efficiency of the graph query, and thus solves the technical problem in the related technology that the graph query process is lengthy and complicated, resulting in high graph query computational cost and low query efficiency.

[0158] It should be noted that the preferred implementation of this embodiment can be found in the relevant description in Example 1 and will not be repeated here.

[0159] Example 4

[0160] According to an embodiment of the present application, a device embodiment for implementing the above-mentioned query processing method is also provided. Figure 7is a structural diagram of a query processing device according to embodiment 4 of the present application, such as Figure 7 As shown, the device includes:

[0161] An acquisition module 701 is configured to acquire graph query information, wherein the graph query information is used to represent an original logical execution plan obtained by compiling a pre-input graph query statement;

[0162] Processing module 702, configured to perform intermediate representation layer processing on the graph query information and construct a physical execution plan, wherein the intermediate representation layer processing is at least used to perform correctness verification and query adjustment on the graph query information;

[0163] The generation module 703 is used to generate a target query code to be executed based on the physical execution plan, wherein the target query code is used to obtain a query result corresponding to the graph query statement.

[0164] Optionally, the acquisition module 701 is further used to: acquire a graph query statement, wherein the graph query statement is written in a target query language among multiple query languages; and parse and compile the graph query statement to obtain graph query information.

[0165] Optionally, the acquisition module 701 is also used to: use a target parser corresponding to the target query language to parse the graph query statement to obtain a parsing result; compile the parsing result to obtain graph query information, wherein the graph query information includes multiple intermediate representation operators corresponding to the original logical execution plan, and the operator types of the multiple intermediate representation operators include relational algebra operators and graph operation operators.

[0166] Optionally, the above-mentioned processing module 702 is also used to: perform correctness verification processing on the graph query information to obtain a verification result, wherein the verification result includes some intermediate representation operators that have passed the verification among multiple intermediate representation operators corresponding to the original logical execution plan; perform query adjustment processing on the verification result to obtain an adjusted logical execution plan, wherein the adjusted logical execution plan includes target intermediate representation operators that meet the adjustment conditions among some intermediate representation operators; and construct a physical execution plan based on the adjusted logical execution plan.

[0167] Optionally, the above-mentioned processing module 702 is also used to: perform correctness verification on the graph query information according to the legitimacy verification strategy to obtain a verification result, wherein the legitimacy verification strategy is used to check whether the connection relationship between multiple intermediate representation operators satisfies the preset connection rules; perform correctness verification on the graph query information according to the type verification strategy to obtain a verification result, wherein the type verification strategy is used to check whether the expression operator in the multiple intermediate representation operators satisfies the operation support condition, the expression operator is any operator in the multiple intermediate representation operators that contains an operation expression, and the operation support condition is used to characterize whether the field type of the target data field corresponding to the expression operator supports completing the operation corresponding to the operation expression.

[0168] Optionally, the above-mentioned processing module 702 is also used to: perform query adjustment on the verification result based on preset adjustment rules, filter out intermediate representation operators in some intermediate representation operators that do not meet the preset adjustment rules, and obtain rule adjustment results; based on graph statistical information, select the adjusted logical execution plan from multiple candidate query plans corresponding to the rule adjustment results, wherein the graph statistical information includes: graph pattern matching data corresponding to multiple subgraphs and attribute graphs pre-maintained under preset application scenarios.

[0169] Optionally, the above-mentioned processing module 702 is also used to: use graph statistical information to estimate the computational costs of multiple candidate operators in the rule adjustment results to obtain operator cost information; construct multiple candidate query plans based on the multiple candidate operators in the rule adjustment results; calculate the query cost information of multiple candidate query plans based on the operator cost information; and use the query cost information to select an adjusted logical execution plan from multiple candidate query plans.

[0170] Optionally, the processing module 702 is further used to perform orchestration processing on some or all of the multiple candidate operators to construct multiple candidate query plans that can complete the query tasks corresponding to the graph query statements, wherein the orchestration processing includes at least one of the following: sorting processing, combination processing, and equivalent transformation processing.

[0171] Optionally, the processing module 702 is further used to: insert physical execution information corresponding to the graph query engine into the adjusted logical execution plan to obtain an insertion result; convert the target intermediate representation operator in the insertion result into a corresponding operator library to obtain a physical execution plan.

[0172] Optionally, the generation module 703 is further used to: compile the physical execution plan and the first system component to obtain a compilation result, wherein the first system component includes a system component corresponding to a preset high-throughput executor; and generate native code based on the compilation result to obtain a target query code.

[0173] Optionally, the above-mentioned generation module 703 is also used to: generate analytical code based on the physical execution plan, the second system component and the precompilation result to obtain the target query code, wherein the second system component includes the system component corresponding to the preset low-latency executor, and the precompilation result is obtained by precompiling multiple physical operators registered under the preset application scenario.

[0174] It should be noted that the acquisition module 701, processing module 702, and generation module 703 correspond to steps S21 to S23 in Example 1. The examples and application scenarios implemented by the three modules and the corresponding steps are the same, but are not limited to the contents disclosed in Example 1. It should be noted that the modules or units can be hardware components or software components stored in a memory (e.g., memory 104) and processed by one or more processors (e.g., processors 102a, 102b, ..., 102n). The modules can also be part of the device and can be run in the computer terminal 10 provided in Example 1.

[0175] In an embodiment of the present application, an acquisition module is used to acquire graph query information, wherein the graph query information is used to represent an original logical execution plan obtained by compiling a pre-input graph query statement; a processing module is used to perform intermediate representation layer processing on the graph query information to construct a physical execution plan, wherein the intermediate representation layer processing is at least used to perform correctness verification and query adjustment on the graph query information; a generation module is used to generate a target query code to be executed based on the physical execution plan, wherein the target query code is used to obtain a query result corresponding to the graph query statement.

[0176] It is easy to notice that the present application constructs an intermediate representation layer between the compilation process of the graph query statement and the generation and execution process of the query code to decouple the compilation of the graph query statement from the code generation and execution. Before the intermediate representation layer, the compilation process of the graph query statement can adapt to a variety of query languages, and after the intermediate representation layer, the generation and execution process of the query code can adapt to the execution engines corresponding to a variety of application scenarios. Therefore, the present application achieves the purpose of reducing the complexity of the graph query process, thereby realizing the technical effect of saving the computational cost of the graph query process and improving the efficiency of the graph query, and thus solves the technical problem in the related technology that the graph query process is lengthy and complicated, resulting in high graph query computational cost and low query efficiency.

[0177] According to an embodiment of the present application, a device embodiment for implementing the query processing method in the above embodiment 2 is also provided. Figure 8 is a structural diagram of another query processing device according to embodiment 4 of the present application, such as Figure 8 As shown, the device includes:

[0178] An acquisition module 801 is configured to acquire a graph query request through a first application programming interface, wherein the request data carried in the graph query request includes: graph query information, the graph query information being used to represent an original logical execution plan obtained by compiling a pre-input graph query statement;

[0179] Return module 802 is used to return a graph query response through a second application programming interface, wherein the response data carried in the graph query response includes: a query result corresponding to the graph query statement, the query result is obtained by executing a target query code, the target query code is generated based on a physical execution plan, and the physical execution plan is constructed by performing intermediate representation layer processing on the graph query information, and the intermediate representation layer processing is at least used for correctness verification and query adjustment of the graph query information.

[0180] It should be noted that the acquisition module 801 and the return module 802 correspond to steps S51 to S53 in Example 2. The examples and application scenarios implemented by the two modules and the corresponding steps are the same, but are not limited to the contents disclosed in Example 2. It should be noted that the modules or units can be hardware components or software components stored in a memory (e.g., memory 104) and processed by one or more processors (e.g., processors 102a, 102b, ..., 102n). The modules can also be run as part of the device in the computer terminal 10 provided in Example 1.

[0181] According to an embodiment of the present application, a device embodiment for implementing the query processing method in the above-mentioned embodiment 3 is also provided. Figure 9 is a structural diagram of another query processing device according to embodiment 4 of the present application, such as Figure 9 As shown, the device includes:

[0182] An acquisition module 901 is configured to acquire a currently input graph query dialog request, wherein the request data carried in the graph query dialog request includes graph query information, which is used to represent an original logical execution plan obtained by compiling a pre-input graph query statement;

[0183] A return module 902 is configured to return a graph query dialogue reply in response to the graph query dialogue request, wherein the information carried in the graph query dialogue reply includes: a query result corresponding to the graph query statement, the query result being obtained by executing a target query code, the target query code being generated based on a physical execution plan, the physical execution plan being constructed by performing intermediate representation layer processing on the graph query information, the intermediate representation layer processing being used at least for correctness verification and query adjustment of the graph query information;

[0184] The display module 903 is used to display the query results in a graphical user interface.

[0185] It should be noted that the acquisition module 901, return module 902, and display module 903 correspond to steps S61 to S63 in Example 3. The examples and application scenarios implemented by the three modules and the corresponding steps are the same, but are not limited to the contents disclosed in the above-mentioned Example 3. It should be noted that the above-mentioned modules or units can be hardware components or software components stored in a memory (e.g., memory 104) and processed by one or more processors (e.g., processors 102a, 102b, ..., 102n). The above-mentioned modules can also be run as part of the device in the computer terminal 10 provided in Example 1.

[0186] It should be noted that the preferred implementation of this embodiment can be found in the relevant descriptions in Example 1, Example 2 or Example 3, and will not be repeated here.

[0187] Example 5

[0188] According to an embodiment of the present application, a computer terminal is further provided, which can be any computer terminal device in a computer terminal group. Optionally, in this embodiment, the computer terminal can also be replaced by a terminal device such as a mobile terminal.

[0189] Optionally, in this embodiment, the computer terminal may be located in at least one network device among a plurality of network devices of a computer network.

[0190] In this embodiment, the above-mentioned computer terminal can execute the program code of the following steps in the query processing method: obtaining graph query information, wherein the graph query information is used to represent the original logical execution plan obtained by compiling a pre-input graph query statement; performing intermediate representation layer processing on the graph query information to construct a physical execution plan, wherein the intermediate representation layer processing is at least used to perform correctness verification and query adjustment on the graph query information; based on the physical execution plan, generating a target query code to be executed, wherein the target query code is used to obtain the query result corresponding to the graph query statement.

[0191] Optionally, Figure 10 is a structural block diagram of a computer terminal according to embodiment 5 of the present application, such as Figure 10 As shown, the computer terminal 100 may include: one or more (only one is shown in the figure) processors 1002, a memory 1004, a storage controller 1006, and a peripheral interface 1008, wherein the peripheral interface 1008 is connected to a radio frequency module, an audio module and a display.

[0192] Among them, the memory 1004 can be used to store software programs and modules, such as the program instructions / modules corresponding to the query processing method and device in the embodiments of the present application. The processor executes various functional applications and data processing by running the software programs and modules stored in the memory, that is, implementing the above-mentioned query processing method. The memory 1004 may include a high-speed random access memory, and may also include a non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 1004 may further include a memory remotely located relative to the processor, and these remote memories can be connected to the computer terminal 100 via a network. Examples of the above-mentioned network include but are not limited to the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0193] The processor 1002 can call the information and application stored in the memory through the transmission device to perform the following steps: obtain graph query information, wherein the graph query information is used to represent the original logical execution plan obtained by compiling a pre-input graph query statement; perform intermediate representation layer processing on the graph query information to construct a physical execution plan, wherein the intermediate representation layer processing is at least used to perform correctness verification and query adjustment on the graph query information; based on the physical execution plan, generate a target query code to be executed, wherein the target query code is used to obtain the query result corresponding to the graph query statement.

[0194] Optionally, the processor 1002 may further execute program code of the following steps: obtaining a graph query statement, wherein the graph query statement is written in a target query language among a plurality of query languages; parsing and compiling the graph query statement to obtain graph query information.

[0195] Optionally, the processor 1002 may also execute the program code of the following steps: using a target parser corresponding to a target query language to parse a graph query statement to obtain a parsing result; compiling the parsing result to obtain graph query information, wherein the graph query information includes multiple intermediate representation operators corresponding to the original logical execution plan, and the operator types of the multiple intermediate representation operators include relational algebra operators and graph operation operators.

[0196] Optionally, the processor 1002 may also execute the program code of the following steps: performing correctness verification processing on the graph query information to obtain a verification result, wherein the verification result includes some intermediate representation operators that have passed the verification among multiple intermediate representation operators corresponding to the original logical execution plan; performing query adjustment processing on the verification result to obtain an adjusted logical execution plan, wherein the adjusted logical execution plan includes target intermediate representation operators that meet the adjustment conditions among some intermediate representation operators; and constructing a physical execution plan based on the adjusted logical execution plan.

[0197] Optionally, the processor 1002 may also execute the program code of the following steps: performing a correctness check on the graph query information according to a legitimacy check strategy to obtain a check result, wherein the legitimacy check strategy is used to check whether the connection relationship between multiple intermediate representation operators satisfies the preset connection rules; performing a correctness check on the graph query information according to a type check strategy to obtain a check result, wherein the type check strategy is used to check whether the expression operator in multiple intermediate representation operators satisfies the operation support condition, the expression operator is any operator in multiple intermediate representation operators that contains an operation expression, and the operation support condition is used to characterize whether the field type of the target data field corresponding to the expression operator supports completing the operation corresponding to the operation expression.

[0198] Optionally, the processor 1002 may also execute the program code of the following steps: performing query adjustment on the verification result based on preset adjustment rules, filtering out intermediate representation operators in some intermediate representation operators that do not meet the preset adjustment rules, and obtaining rule adjustment results; based on graph statistical information, selecting an adjusted logical execution plan from multiple candidate query plans corresponding to the rule adjustment results, wherein the graph statistical information includes: graph pattern matching data corresponding to multiple subgraphs and attribute graphs pre-maintained under preset application scenarios.

[0199] Optionally, the processor 1002 may also execute the program code of the following steps: using graph statistical information to estimate the computational overhead of multiple candidate operators in the rule adjustment results to obtain operator overhead information; constructing multiple candidate query plans based on the multiple candidate operators in the rule adjustment results; calculating the query cost information of the multiple candidate query plans based on the operator overhead information; and using the query cost information to select an adjusted logical execution plan from the multiple candidate query plans.

[0200] Optionally, the processor 1002 may also execute program code for the following steps: performing orchestration processing on some or all of the multiple candidate operators to construct multiple candidate query plans that can complete the query tasks corresponding to the graph query statements, wherein the orchestration processing includes at least one of the following: sorting processing, combination processing, and equivalent transformation processing.

[0201] Optionally, the processor 1002 may also execute the program code of the following steps: inserting the physical execution information corresponding to the graph query engine into the adjusted logical execution plan to obtain the insertion result; converting the target intermediate representation operator in the insertion result into the corresponding operator library to obtain the physical execution plan.

[0202] Optionally, the processor 1002 may also execute program code for the following steps: compile the physical execution plan and the first system component to obtain a compilation result, wherein the first system component includes a system component corresponding to a preset high-throughput executor; and generate native code based on the compilation result to obtain a target query code.

[0203] Optionally, the processor 1002 may also execute the program code of the following steps: based on the physical execution plan, the second system component and the precompilation result, perform analytical code generation to obtain the target query code, wherein the second system component includes the system component corresponding to the preset low-latency executor, and the precompilation result is obtained by precompiling multiple physical operators registered under the preset application scenario.

[0204] The processor 1002 can call the information and application stored in the memory through the transmission device to perform the following steps: obtain a graph query request through a first application programming interface, wherein the request data carried in the graph query request includes: graph query information, the graph query information is used to represent the original logical execution plan obtained by compiling a pre-input graph query statement; return a graph query response through a second application programming interface, wherein the response data carried in the graph query response includes: the query result corresponding to the graph query statement, the query result is obtained by executing the target query code, the target query code is generated based on the physical execution plan, the physical execution plan is constructed by performing intermediate representation layer processing on the graph query information, and the intermediate representation layer processing is at least used to perform correctness verification and query adjustment on the graph query information.

[0205] The processor 1002 can call the information and application stored in the memory through the transmission device to perform the following steps: obtain the currently input graph query dialogue request, wherein the request data carried in the graph query dialogue request includes: graph query information, the graph query information is used to represent the original logical execution plan obtained by compiling the pre-input graph query statement; in response to the graph query dialogue request, return a graph query dialogue reply, wherein the information carried in the graph query dialogue reply includes: the query result corresponding to the graph query statement, the query result is obtained by executing the target query code, the target query code is generated based on the physical execution plan, the physical execution plan is constructed by performing intermediate representation layer processing on the graph query information, and the intermediate representation layer processing is at least used to perform correctness verification and query adjustment on the graph query information; and display the query results in a graphical user interface.

[0206] According to an embodiment of the present application, a computer terminal for implementing the above-mentioned query processing method is provided. Graph query information is obtained, wherein the graph query information is used to represent the original logical execution plan obtained by compiling a pre-input graph query statement; the graph query information is processed at an intermediate representation layer to construct a physical execution plan, wherein the intermediate representation layer processing is at least used to perform correctness verification and query adjustment on the graph query information; based on the physical execution plan, a target query code to be executed is generated, wherein the target query code is used to obtain the query result corresponding to the graph query statement. The present application constructs an intermediate representation layer between the compilation process of the graph query statement and the generation and execution process of the query code to decouple the compilation of the graph query statement from the code generation and execution. Before the intermediate representation layer, the compilation process of the graph query statement can adapt to multiple query languages, and after the intermediate representation layer, the generation and execution process of the query code can adapt to the execution engines corresponding to multiple application scenarios. Thus, the present application achieves the purpose of reducing the complexity of the graph query process, thereby achieving the technical effect of saving the computational cost of the graph query process and improving the efficiency of the graph query, thereby solving the technical problem in the related art that the graph query process is lengthy and complicated, resulting in high graph query computational cost and low query efficiency.

[0207] It can be understood by those skilled in the art that Figure 10 The structure shown is for illustration only, and the computer terminal may also be a terminal device such as a smart phone (such as an Android phone, an iOS phone, etc.), a tablet computer, a PDA, or a mobile Internet device (MID). Figure 10 It does not limit the structure of the above-mentioned computer terminal. For example, the computer terminal 100 may also include Figure 10 More or fewer components (such as network interfaces, display devices, etc.) shown in, or with Figure 10 Different configurations shown.

[0208] A person skilled in the art can understand that all or part of the steps in the various methods of the above embodiments can be completed by instructing the hardware related to the terminal device through a program, and the program can be stored in a computer-readable storage medium, which can include: a flash drive, ROM, RAM, a magnetic disk or an optical disk, etc.

[0209] Example 6

[0210] According to an embodiment of the present application, a computer-readable storage medium is further provided. Optionally, in this embodiment, the storage medium can be used to store the program code executed by the query processing method provided in the above embodiment 1, embodiment 2 or embodiment 3.

[0211] Optionally, in this embodiment, the storage medium may be located in any computer terminal in a computer terminal group in a computer network, or in any mobile terminal in a mobile terminal group.

[0212] Optionally, in this embodiment, the computer-readable storage medium is configured to store program code for executing the following steps: obtaining graph query information, wherein the graph query information is used to represent the original logical execution plan obtained by compiling a pre-input graph query statement; performing intermediate representation layer processing on the graph query information to construct a physical execution plan, wherein the intermediate representation layer processing is at least used to perform correctness verification and query adjustment on the graph query information; based on the physical execution plan, generating a target query code to be executed, wherein the target query code is used to obtain the query result corresponding to the graph query statement.

[0213] Optionally, in this embodiment, the computer-readable storage medium is configured to store program code for executing the following steps: obtaining a graph query statement, wherein the graph query statement is written in a target query language among multiple query languages; parsing and compiling the graph query statement to obtain graph query information.

[0214] Optionally, in this embodiment, the computer-readable storage medium is configured to store program code for executing the following steps: using a target parser corresponding to a target query language to parse a graph query statement to obtain a parsing result; compiling the parsing result to obtain graph query information, wherein the graph query information includes multiple intermediate representation operators corresponding to the original logical execution plan, and the operator types of the multiple intermediate representation operators include relational algebra operators and graph operation operators.

[0215] Optionally, in this embodiment, the computer-readable storage medium is configured to store program code for executing the following steps: performing correctness verification processing on the graph query information to obtain a verification result, wherein the verification result includes some intermediate representation operators that pass the verification among multiple intermediate representation operators corresponding to the original logical execution plan; performing query adjustment processing on the verification result to obtain an adjusted logical execution plan, wherein the adjusted logical execution plan includes target intermediate representation operators that meet the adjustment conditions among some intermediate representation operators; and constructing a physical execution plan based on the adjusted logical execution plan.

[0216] Optionally, in this embodiment, the computer-readable storage medium is configured to store program code for executing the following steps: performing a correctness check on the graph query information according to a legitimacy check strategy to obtain a check result, wherein the legitimacy check strategy is used to check whether the connection relationship between multiple intermediate representation operators satisfies preset connection rules; performing a correctness check on the graph query information according to a type check strategy to obtain a check result, wherein the type check strategy is used to check whether the expression operator in the multiple intermediate representation operators satisfies the operation support condition, the expression operator is any operator in the multiple intermediate representation operators that contains an operation expression, and the operation support condition is used to characterize whether the field type of the target data field corresponding to the expression operator supports completing the operation corresponding to the operation expression.

[0217] Optionally, in this embodiment, the computer-readable storage medium is configured to store program code for executing the following steps: performing query adjustment on the verification result based on preset adjustment rules, filtering out intermediate representation operators in some intermediate representation operators that do not meet the preset adjustment rules, and obtaining rule adjustment results; based on graph statistical information, selecting an adjusted logical execution plan from multiple candidate query plans corresponding to the rule adjustment results, wherein the graph statistical information includes: graph pattern matching data corresponding to multiple subgraphs and attribute graphs pre-maintained under preset application scenarios.

[0218] Optionally, in this embodiment, the computer-readable storage medium is configured to store program code for executing the following steps: using graph statistical information, estimating the computational overhead of multiple candidate operators in the rule adjustment result to obtain operator overhead information; constructing multiple candidate query plans based on the multiple candidate operators in the rule adjustment result; calculating the query cost information of the multiple candidate query plans based on the operator overhead information; and using the query cost information, selecting an adjusted logical execution plan from the multiple candidate query plans.

[0219] Optionally, in this embodiment, the computer-readable storage medium is configured to store program code for executing the following steps: performing orchestration processing on some or all of the multiple candidate operators to construct multiple candidate query plans that can complete the query tasks corresponding to the graph query statement, wherein the orchestration processing includes at least one of the following: sorting processing, combination processing, and equivalent transformation processing.

[0220] Optionally, in this embodiment, the computer-readable storage medium is configured to store program code for performing the following steps: inserting physical execution information corresponding to the graph query engine into the adjusted logical execution plan to obtain an insertion result; converting the target intermediate representation operator in the insertion result into a corresponding operator library to obtain a physical execution plan.

[0221] Optionally, in this embodiment, the computer-readable storage medium is configured to store program code for performing the following steps: compiling the physical execution plan and the first system component to obtain a compilation result, wherein the first system component includes a system component corresponding to a preset high-throughput executor; and generating native code based on the compilation result to obtain a target query code.

[0222] Optionally, in this embodiment, the computer-readable storage medium is configured to store program code for executing the following steps: performing analytical code generation based on the physical execution plan, the second system component and the precompilation result to obtain the target query code, wherein the second system component includes a system component corresponding to a preset low-latency executor, and the precompilation result is obtained by precompiling multiple physical operators registered under a preset application scenario.

[0223] Optionally, in this embodiment, a computer-readable storage medium is configured to store program code for executing the following steps: obtaining a graph query request through a first application programming interface, wherein the request data carried in the graph query request includes: graph query information, the graph query information is used to represent the original logical execution plan obtained by compiling a pre-input graph query statement; returning a graph query response through a second application programming interface, wherein the response data carried in the graph query response includes: a query result corresponding to the graph query statement, the query result is obtained by executing a target query code, the target query code is generated based on a physical execution plan, the physical execution plan is constructed by performing intermediate representation layer processing on the graph query information, and the intermediate representation layer processing is at least used to perform correctness verification and query adjustment on the graph query information.

[0224] Optionally, in this embodiment, the computer-readable storage medium is configured to store program code for executing the following steps: obtaining a currently input graph query dialogue request, wherein the request data carried in the graph query dialogue request includes: graph query information, the graph query information is used to represent the original logical execution plan obtained by compiling a pre-input graph query statement; in response to the graph query dialogue request, returning a graph query dialogue reply, wherein the information carried in the graph query dialogue reply includes: a query result corresponding to the graph query statement, the query result is obtained by executing a target query code, the target query code is generated based on a physical execution plan, the physical execution plan is constructed by performing intermediate representation layer processing on the graph query information, and the intermediate representation layer processing is at least used to perform correctness verification and query adjustment on the graph query information; and displaying the query results in a graphical user interface.

[0225] According to an embodiment of the present application, a computer-readable storage medium for implementing the above-mentioned query processing method is provided. Graph query information is obtained, wherein the graph query information is used to represent the original logical execution plan obtained by compiling a pre-input graph query statement; the graph query information is processed at an intermediate representation layer to construct a physical execution plan, wherein the intermediate representation layer processing is at least used to perform correctness verification and query adjustment on the graph query information; based on the physical execution plan, a target query code to be executed is generated, wherein the target query code is used to obtain the query result corresponding to the graph query statement. The present application constructs an intermediate representation layer between the compilation process of the graph query statement and the generation and execution process of the query code to decouple the compilation of the graph query statement from the code generation and execution. Before the intermediate representation layer, the compilation process of the graph query statement can adapt to a variety of query languages, and after the intermediate representation layer, the generation and execution process of the query code can adapt to the execution engines corresponding to a variety of application scenarios. Thus, the present application achieves the purpose of reducing the complexity of the graph query process, thereby achieving the technical effect of saving the computational cost of the graph query process and improving the efficiency of the graph query, thereby solving the technical problem in the related art that the graph query process is lengthy and complicated, resulting in high graph query computational cost and low query efficiency.

[0226] The serial numbers of the above embodiments of the present application are for description only and do not represent the advantages or disadvantages of the embodiments.

[0227] In the above embodiments of the present application, the description of each embodiment has its own focus. For parts that are not described in detail in a certain embodiment, please refer to the relevant description of other embodiments.

[0228] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. Among them, the device embodiments described above are only schematic. For example, the division of the units is only a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of units or modules, which can be electrical or other forms.

[0229] The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of these units may be selected to achieve the purpose of this embodiment according to actual needs.

[0230] In addition, the functional units in the various embodiments of the present application may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0231] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art, or all or part of the technical solution can be embodied in the form of a software product, which is stored in a storage medium and includes several instructions for enabling a computer device (which can be a personal computer, server or network device, etc.) to execute all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: various media that can store program codes, such as USB flash drives, ROM, RAM, mobile hard drives, magnetic disks or optical disks.

[0232] The above is only a preferred embodiment of the present application. It should be pointed out that for ordinary technicians in this technical field, several improvements and modifications can be made without departing from the principles of the present application. These improvements and modifications should also be regarded as the scope of protection of the present application.

Claims

1. A query processing method, characterized in that: include: Acquire graph query information, wherein the graph query information is used to represent an original logical execution plan obtained by compiling a pre-input graph query statement; Performing intermediate representation layer processing on the graph query information to construct a physical execution plan, wherein the intermediate representation layer processing is at least used to perform correctness verification and query adjustment on the graph query information; Based on the physical execution plan, a target query code to be executed is generated, wherein the target query code is used to obtain a query result corresponding to the graph query statement.

2. The query processing method according to claim 1, characterized in that: Obtaining the graph query information includes: Obtaining the graph query statement, wherein the graph query statement is written in a target query language among multiple query languages; The graph query statement is parsed and compiled to obtain the graph query information.

3. The query processing method according to claim 2, wherein: The graph query statement is parsed and compiled to obtain the graph query information including: Using a target parser corresponding to the target query language to parse the graph query statement to obtain a parsing result; The parsing results are compiled to obtain the graph query information, wherein the graph query information includes multiple intermediate representation operators corresponding to the original logical execution plan, and the operator types of the multiple intermediate representation operators include relational algebra operators and graph operation operators.

4. The query processing method according to claim 1, wherein: Performing intermediate representation layer processing on the graph query information and constructing the physical execution plan includes: Performing a correctness check on the graph query information to obtain a check result, wherein the check result includes some intermediate representation operators that pass the check among the multiple intermediate representation operators corresponding to the original logical execution plan; Performing query adjustment processing on the verification result to obtain an adjusted logical execution plan, wherein the adjusted logical execution plan includes target intermediate representation operators that meet adjustment conditions among the partial intermediate representation operators; The physical execution plan is constructed based on the adjusted logical execution plan.

5. The query processing method according to claim 4, characterized in that: Performing a correctness check on the graph query information, obtaining a check result including at least one of the following: Performing a correctness check on the graph query information according to a validity check strategy to obtain the check result, wherein the validity check strategy is used to check whether the connection relationship between the multiple intermediate representation operators satisfies a preset connection rule; According to the type verification strategy, the graph query information is checked for correctness to obtain the verification result, wherein the type verification strategy is used to check whether the expression operator in the multiple intermediate representation operators meets the operation support condition, the expression operator is any operator in the multiple intermediate representation operators that contains an operation expression, and the operation support condition is used to characterize whether the field type of the target data field corresponding to the expression operator supports completing the operation corresponding to the operation expression.

6. The query processing method according to claim 4, characterized in that: Performing query adjustment processing on the verification result to obtain the adjusted logical execution plan includes: Performing query adjustment on the verification result based on a preset adjustment rule, filtering out intermediate representation operators that do not meet the preset adjustment rule from the intermediate representation operators, and obtaining a rule adjustment result; Based on graph statistical information, the adjusted logical execution plan is selected from multiple candidate query plans corresponding to the rule adjustment result, wherein the graph statistical information includes: graph pattern matching data corresponding to multiple subgraphs and attribute graphs pre-maintained under preset application scenarios.

7. The query processing method according to claim 6, characterized in that: Selecting the adjusted logical execution plan from a plurality of candidate query plans corresponding to the rule adjustment result based on the graph statistical information includes: Using the graph statistical information, estimating computational overheads of multiple candidate operators in the rule adjustment result to obtain operator overhead information; constructing the plurality of candidate query plans based on the plurality of candidate operators in the rule adjustment result; Calculating query cost information of the multiple candidate query plans based on the operator overhead information; The adjusted logical execution plan is selected from the multiple candidate query plans using the query cost information.

8. The query processing method according to claim 7, characterized in that: Constructing the multiple candidate query plans based on the multiple candidate operators in the rule adjustment result includes: Perform orchestration processing on some or all of the multiple candidate operators to construct the multiple candidate query plans that can complete the query tasks corresponding to the graph query statements, wherein the orchestration processing includes at least one of the following: sorting processing, combination processing, and equivalent transformation processing.

9. The query processing method according to claim 4, characterized in that: Constructing the physical execution plan based on the adjusted logical execution plan includes: Inserting physical execution information corresponding to the graph query engine into the adjusted logical execution plan to obtain an insertion result; The target intermediate representation operator in the insertion result is converted into a corresponding operator library to obtain the physical execution plan.

10. The query processing method according to claim 1, wherein: Generating the target query code to be executed based on the physical execution plan includes: Compiling the physical execution plan and the first system component to obtain a compilation result, wherein the first system component includes a system component corresponding to a preset high-throughput executor; Native code generation is performed based on the compilation result to obtain the target query code.

11. The query processing method according to claim 1, wherein: Generating the target query code to be executed based on the physical execution plan includes: Based on the physical execution plan, the second system component and the precompilation result, analytical code generation is performed to obtain the target query code, wherein the second system component includes a system component corresponding to a preset low-latency executor, and the precompilation result is obtained by precompiling multiple physical operators registered under a preset application scenario.

12. A query processing method, characterized in that: include: Obtaining a graph query request through a first application programming interface, wherein the request data carried in the graph query request includes: graph query information, the graph query information being used to represent an original logical execution plan obtained by compiling a pre-input graph query statement; A graph query response is returned through a second application programming interface, wherein the response data carried in the graph query response includes: a query result corresponding to the graph query statement, the query result is obtained by executing a target query code, the target query code is generated based on a physical execution plan, the physical execution plan is constructed by performing intermediate representation layer processing on the graph query information, and the intermediate representation layer processing is at least used to perform correctness verification and query adjustment on the graph query information.

13. A query processing method, characterized in that: include: Obtaining a currently input graph query dialogue request, wherein the request data carried in the graph query dialogue request includes: graph query information, the graph query information being used to represent an original logical execution plan obtained by compiling a pre-input graph query statement; In response to the graph query dialogue request, a graph query dialogue reply is returned, wherein the information carried in the graph query dialogue reply includes: a query result corresponding to the graph query statement, the query result being obtained by executing a target query code, the target query code being generated based on a physical execution plan, the physical execution plan being constructed by performing intermediate representation layer processing on the graph query information, the intermediate representation layer processing being used at least for correctness verification and query adjustment of the graph query information; The query results are displayed in a graphical user interface.

14. An electronic device, characterized in that: include: a memory storing an executable program; A processor is used to run the program, wherein the program executes the query processing method according to any one of claims 1 to 13 when running.

15. A computer-readable storage medium, characterized in that The computer-readable storage medium includes a stored executable program, wherein when the executable program is run, the device where the computer-readable storage medium is located is controlled to execute the query processing method according to any one of claims 1 to 13.

Images