Graph query optimization execution method and device

Abstract

The embodiment of the invention provides a graph query optimization execution method which is executed through a graph query engine and comprises the steps that a graph query statement is received, and the graph query statement comprises a hop count range of an indefinite hop path and a path constraint on a connecting edge; and executing a target execution plan generated for the graph query statement, including filtering candidate connection edges according to the path constraint when the connection edges of a first path are expanded, and the hop count of the first path belongs to the hop count range after expansion.

Description

Technical Field

[0001] One or more embodiments of the present specification relate to the field of computer data query technology, and in particular, to a method and device for optimizing the execution of graph queries. Background Art

[0002] With the development of big data and artificial intelligence, graph-structured data is being used to record and process business data in more and more scenarios. For example, in social platforms, graph-structured data is used to depict social relationships between users; in payment platforms, graph-structured data is used to build complex payment relationship graphs. As a result, the query demand for graph-structured data is growing. To this end, the industry has designed a variety of graph databases based on the characteristics of graph-structured data for storage and query of graph-structured data.

[0003] The data storage format of graph databases is different from that of conventional relational databases. Structured query languages ​​that perform queries based on data table relationships are not applicable to graph databases. Therefore, different graph databases are equipped with their own graph query languages ​​so that graph query statements can be written effectively to perform query operations on graph structured data in graph databases. In practical applications, query efficiency is an important indicator for measuring graph query execution performance.

[0004] Therefore, in the process of using graph query language to execute graph structured data queries, improving the execution efficiency of graph queries is one of the technical problems that need to be solved at present. Summary of the invention

[0005] One or more embodiments of the present specification describe an optimized execution method and device for graph queries, which perform optimization analysis on the path constraints present in the graph query statements, synchronously check the path constraints during the path extension search process, intercept the extension of connection edges that do not meet the conditions in real time, and effectively prevent computing resources from being wasted on the calculation of invalid paths, thereby improving the execution performance of graph queries and solving the above-mentioned technical problems.

[0006] According to a first aspect, a method for optimizing execution of a graph query is provided, which is executed by a graph query engine and includes:

[0007] A graph query statement is received, wherein the graph query statement includes a hop count range of an indefinite hop path and a path constraint on a connecting edge.

[0008] Executing a target execution plan generated for the graph query statement, including, when extending connecting edges for a first path, filtering candidate connecting edges according to the path constraints, wherein the number of hops of the first path after expansion falls within the hop number range.

[0009] According to one implementation, the target execution plan includes an iteratively executed combinatorial operator, the combinatorial operator including an edge extension operator for searching for a path that satisfies a hop count range, and an extension filter operator for filtering the connection edges based on the path constraint. The filtering of the candidate connection edges based on the path constraint includes: filtering the candidate connection edges based on the path constraint by executing the combinatorial operator.

[0010] According to an implementation manner, the connecting edge is an outgoing edge.

[0011] According to one implementation, the path constraint includes a first constraint on first data of a specific connection edge in the indefinite hop path, the first data including: a label, an attribute or a timestamp. Filtering the candidate connection edges according to the path constraint includes:

[0012] If the connection edge to be extended is a specific connection edge, whether the candidate connection edge is used as an extended connection edge is determined according to whether the first data of any candidate connection edge satisfies the first constraint.

[0013] In one scenario of the above implementation, the specific connection edge is at least one of the following: the first connection edge and the last connection edge.

[0014] According to one implementation, the path constraint includes a second constraint imposed on the relationship between second data of each connection edge in the indefinite hop path, and the second data includes: a label, an attribute or a timestamp. Filtering the candidate connection edges according to the path constraint includes:

[0015] The second data of any candidate connection edge is compared with the second data of the target connection edge in the first path based on the second constraint, and according to the comparison result, it is determined whether the candidate connection edge is used as an extended connection edge.

[0016] In a scenario of the above implementation, the second data is an attribute or a timestamp, and the target connection edge is the last connection edge.

[0017] The second constraint is that the second data is arranged in ascending order; the step of determining whether the candidate connection edge is used as an extended connection edge according to the comparison result includes: if the second data of the candidate connection edge is greater than the second data of the last connection edge, determining the candidate connection edge as an extended connection edge. Or,

[0018] The second constraint is that the second data is arranged in descending order; and determining whether the candidate connection edge is used as an extended connection edge based on the comparison result includes: if the second data of the candidate connection edge is less than the second data of the last connection edge, determining the candidate connection edge as an extended connection edge.

[0019] According to one implementation, each connection edge of the first path is sequentially stored in a target stack. The depth of the target stack is the upper limit of the hop count range. The filtering of the candidate connection edges includes:

[0020] The first element of the target stack is obtained, and the node pointed to by the corresponding connection edge is used as the expansion node.

[0021] Several connection edges of the extended node are used as candidate connection edges, and any connection edge that satisfies the path constraint is selected from them and pushed into the target stack. Or,

[0022] If the candidate connection edges do not include a connection edge that satisfies the path constraint, the stack head element is popped from the target stack.

[0023] In one scenario of the above implementation, filtering the candidate connection edges further includes:

[0024] When the target stack is empty, the starting node of the first path is determined according to the graph query statement, and any connecting edge on the starting node that satisfies the path constraint is pushed into the target stack.

[0025] According to one implementation, the graph query statement further includes a first keyword, and the first keyword is used to define a first termination condition for path extension. The filtering of candidate connection edges also includes:

[0026] For any candidate connection edge that meets the path constraint, a target determination is performed on it based on the first termination condition, and according to the determination result, it is determined whether the candidate connection edge is used as an extended connection edge.

[0027] In one scenario of the above implementation, the first termination condition includes a third constraint on the connection edge, and the target determination includes: determining the candidate connection edge according to the third constraint.

[0028] In one scenario of the above implementation, the first termination condition includes a fourth constraint on the node, and the target determination includes: determining the node to which the candidate connection edge points according to the fourth constraint.

[0029] According to one implementation, the graph query statement further includes a first function, and the first function is used to define a first window. The extended filter operator is implemented as a window filter operator. The filtering of candidate connection edges according to the path constraint includes:

[0030] By executing the window filtering operator, the candidate connection edges covered by the first window are filtered according to the path constraint.

[0031] In one scenario of the above implementation, the first window has a first width. The filtering of the candidate connection edges covered by the first window includes:

[0032] Connecting several candidate connection edges to be filtered to the first path to obtain a temporary extended path.

[0033] A window detection is performed on the temporary extended path to determine whether a number of candidate connection edges are used as extended connection edges; the window detection includes placing the first window at the end of the temporary extended path and detecting the path segments within the first window based on the path constraint.

[0034] According to an implementation of the above scenario, the first window also has a first step length. The performing window detection on the temporary extension path includes:

[0035] When the number of connection edges included in the temporary extended path is a multiple of the first step length, the window detection is performed on the temporary extended path.

[0036] According to a second aspect, a graph query optimization execution device is provided, the device comprising:

[0037] The receiving module is configured to receive a graph query statement, wherein the graph query statement includes a hop count range of an indefinite hop path and a path constraint on a connecting edge.

[0038] The filtering module is configured to execute a target execution plan generated for the graph query statement, including filtering candidate connection edges according to the path constraints when extending the connection edges of the first path, wherein the number of hops of the first path after expansion belongs to the hop number range.

[0039] According to a third aspect, a computer program product is provided, comprising a computer program / instruction, which, when executed by a processor, implements the steps of the method described in the first aspect.

[0040] According to a fourth aspect, a computing device is provided, comprising a memory and a processor, wherein an executable code is stored in the memory, and when the processor executes the executable code, the method described in the first aspect is implemented.

[0041] In summary, by using the above-mentioned method and device disclosed in the embodiments of this specification, in the process of executing graph queries, according to the constraints on the path in the statement, when expanding the connecting edges, a path constraint-based check can be performed in real time to achieve dynamic path screening and pruning, which significantly reduces the number of paths generated that do not meet the graph query conditions, avoids wasting computing resources on invalid paths, and thus improves the execution efficiency of graph queries. BRIEF DESCRIPTION OF THE DRAWINGS

[0042] In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments of the present invention, and for ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0043] Figure 1 is an exemplary property diagram disclosed in this specification;

[0044] Figure 2 is an exemplary graph query statement disclosed in this specification;

[0045] Figure 3 An execution plan for an exemplary graph query disclosed in this specification;

[0046] Figure 4 A flowchart of an optimized execution method for graph query provided according to an embodiment of this specification;

[0047] Figure 5 An execution plan for an exemplary graph query execution provided according to an embodiment of this specification;

[0048] Fig. 6A An exemplary candidate connection edge diagram provided for the embodiments of this specification;

[0049] Figure 6B An exemplary extended connection edge operation diagram provided for an embodiment of this specification;

[0050] Figure 7 A schematic diagram of an exemplary implementation of an extended connection edge provided according to an embodiment of this specification;

[0051] Figure 8 A schematic diagram of an optimized execution device for graph query according to an embodiment of this specification. DETAILED DESCRIPTION

[0052] The solution provided by the embodiments of this specification is described below in conjunction with the accompanying drawings.

[0053] As mentioned above, Graph Query Language is a programming language for querying, operating, and analyzing graph structured data in graph databases. The data structure of graph databases is different from that of traditional relational databases. It focuses on connecting data and the data relationships between them. In order to more effectively process the association query of complex graph structured data, a graph query language needs to be specially designed to handle the complex relationships between nodes, connecting edges, and attributes in graph structured data.

[0054] Currently, common graph query languages ​​include Cypher, Gremlin, SPARQL, etc. The syntax and functions of each language are different, but they can all process graph structured data and complete graph query tasks. In order to unify graph query languages, the ISO / IEC standardization organization has developed the GQL standard (ISO / IEC 39075:2024) as the standard query language specification for graph databases.

[0055] In one or more embodiments of this specification, a graph query written based on GQL will be used as an example to explain the additional computing overhead that may occur during the execution of the graph query, and to explain the technical solution that can solve this problem. It should be noted that although the GQL graph query language specification is used for description in some embodiments of this specification, it does not represent a limitation on the application scenarios and technical tools of the embodiments of the present invention. The technical concepts embodied in the various embodiments of this specification can be applied to other graph query engines that support graph structure data queries.

[0056] The object of graph query is the property graph, which is also the main data structure stored in the graph database. It consists of nodes, edges, and properties. It is often used to represent data relationships that are not easy to express in traditional relational data. It has a wide range of application scenarios, such as social networks, recommendation systems, knowledge graphs, financial analysis, etc.

[0057] In the property graph, nodes and edges are used to express the topological relationship between data. Attributes are attached to nodes and edges to provide additional information for nodes or edges to describe specific features. Usually, attributes are stored in the form of "key-value pairs", where the key refers to the category of an attribute (for example, business category) and the value is the specific data of an attribute (for example, transfer). In some property graphs, nodes or edges also have labels. Labels are a mark used to identify the category of nodes or edges. Different types of elements in the property graph (for example, account nodes, user nodes) can be distinguished based on different labels. In some property graphs, nodes or edges can also have timestamps to record the generation and update time of the corresponding nodes or edges.

[0058] Figure 1 An exemplary attribute graph is shown. The attribute graph is constructed based on a financial payment scenario. For the sake of simplicity, the nodes in the attribute graph are numbered. User nodes are numbered as P n Numbering, account nodes start with A n The nodes are numbered, and the connection edges between the nodes are represented by <source node, destination node>, and the direction of the connection edge is from the source node to the destination node.

[0059] Referring to the attached drawings, the property graph consists of nodes (shown as circles) and connecting edges (shown as arrow lines). On the nodes or connecting edges, there are respective labels (shown in the first row of the boxes) and properties (shown in the form of key: value in the boxes). The label represents the type of different elements in the property graph. For example, the label of node P1 is Person (user), the label of the connecting edge <P2, P3> is guarantee, and the label of the connecting edge <A1, A2> is transfer. The property is used to describe the specific characteristics of the node or edge. For example, the name of node P1 is "Zhang San", and the timestamp of the connecting edge <A1, A2> is "T+0". It should be noted that for example purposes, in this attached drawing, the timestamp is in units of natural days and is represented in the form of T+n, where T represents the reference date and n represents the nth natural day after the reference date. For example, assuming T is January 1, 2024, then T+1 represents January 2, 2024, T+2 represents January 3, 2024, and so on. Additionally, in this attached drawing, some properties and labels are also simplified, and some property information unrelated to the example is hidden. For example, for the connecting edge between node P1 and node A1, only the label information "hold" (own) is shown.

[0060] On the constructed property graph, graph query statements can be executed for operations such as data mining, relationship analysis, and path finding. The graph query statement is a query statement written using a target graph query language. In one example, the graph query can be written using the language of the GQL standard, and the example is as follows:

[0061] MATCH p=(m)-[r]-(n) RETURN p;

[0062] Among them, "()" is the identification symbol corresponding to the node, and the identifiers m and n inside it are variables representing nodes; "[]" is the identification symbol corresponding to the connecting edge, and the identifier r inside it is a variable representing the connecting edge; "-[r]-" indicates that the connecting edge between nodes m and n is an undirected edge, which can be replaced with the following forms of directed edges:

[0063] “-[r]->” or “<-[r]-”.

[0064] They represent outgoing edges and incoming edges respectively. It should be understood that the outgoing edges and incoming edges here are relative to node m. By executing this graph query, several network subgraphs can be matched from the attribute graph to be queried. The RETURN clause can return the query results in a predetermined form. For example, "RETURN p" returns the matched network subgraph in the form of a path. The RETURN clause can also include several query fields. For example, "RETURN m.name" returns the name attribute value of node m in the network subgraph.

[0065] In some examples, you can also filter queries based on the labels or attributes of nodes or edges, as shown below:

[0066] MATCHp=(m:Account{id:$id})-[r:transfer]-(n:Account)RETURNp;

[0067] Among them, Account specifies the label of node m, indicating that we are looking for node m with the label Account; "{}" is the identifier corresponding to the attribute, and the attribute filter condition is located inside it. This graph query statement will match the following subgraph path in the attribute graph to be queried: two Account nodes connected by the transfer edge, one of which has an id value of $id.

[0068] In other examples, quantifier constraints can also be applied to the connecting edges in the path, as shown below:

[0069] MATCHp=(m:Account)-[r:transfer*$i..$j]-(n:Account)RETURN p;

[0070] Among them, "*" is the identifier symbol of variable-length quantifier syntax, and the following "$i" and "$j" are the lower and upper bounds of the variable-length quantifier, which means that the path pattern of connecting edges is repeated a certain number of times within the given quantifier range. Due to the chain programming characteristics of the graph query language, the graph query statement in this example is also equivalent to the following statement:

[0071] MATCHp=((m:Account)-[r:transfer]-(n:Account)){$i,$j}RETURNp;

[0072] The graph query statement in this example indicates that a subgraph path with the following characteristics is queried in the property graph: two Account nodes connected by a transfer edge from $i to $j. The connection edge between two nodes can also be called a hop, so a graph query with a variable length quantifier as shown in the example can also be called an indefinite hop query.

[0073] The above is a brief description of some common example queries in graph query. In actual practice, graph query statements may also include other clauses, such as LIMIT, DISTINCT, CASE, etc. This specification does not give examples here.

[0074] In actual applications, after business data is established and stored in the form of an attribute graph, users' queries usually focus on both the topological structure and the changes in attribute data. This means that the graph query statement not only specifies the label constraints on nodes or connecting edges, but also accurately screens the attribute data on the path. In a specific scenario, financial risk control needs to track the flow trajectory of funds and the changes in the amount to discover suspicious behaviors. In this scenario, the graph query statement must not only clarify that the specified account transfers funds to other accounts through the connection edge of the transfer type, and the number of transfers is not fixed, but also ensure that the timestamp sequence corresponding to the transfer path between accounts in the query result remains in ascending order. Such a graph query statement can effectively explain the flow trajectory of funds by conditionally constraining the indefinite jump path. Figure 2 An exemplary graph query statement corresponding to the scenario in a related technology is shown.

[0075] Refer to the attached figure, this graph query is used to find the transfer relationship between a specific account and other accounts in the property graph, and ensure that these transfer relationships occur in ascending order of timestamps. Specifically:

[0076] "MATCH p=(acc:Account{id:10})": This part of the query defines a path variable named p, which starts from a node acc with the label Account (account type) and the attribute id equal to 10. "-[e1:transfer*1..3]->": This part of the query defines a path (connecting edge / jump) e1 from a specific account node acc to another account node other, the label of the path is transfer (transfer type), and in the path p, the path e1 can appear 1 to 3 times in a row, that is, the transfer can be a single transfer or an indirect transfer through at most two intermediate account nodes. "WHEREisAsc(getMemberProp(e1,'timestamp'))=true": This part of the WHERE clause is a filter condition that acts on the path p to ensure that the transfer relations (connecting edges) in the path are sorted in ascending order according to the timestamp. If the timestamps of all transfer relations on the path meet the ascending order, the result of the filter clause is true. "RETURN p": This query will eventually return the path p that meets the above conditions. In summary, the graph query in this example is used to find all paths between the account with id 10 and other accounts, which have 1 to 3 transfers and the transfers occur one by one in ascending timestamp order. Figure 1 For the property graph shown in , the above graph query will return the path results shown in Table 1.

[0077] Table 1 Graph query example results

[0078]

[0079] It can be seen that although the path A1→A2→A3→A4 is the account with id 10 that reaches the target account node after three transfers,<A3,A4> On the top, connect the edge with the previous transfer relationship<A2,A3> In comparison, the filtering condition of sorting the path timestamps in ascending order in the graph query is not met, so the path is discarded.

[0080] The inventors have discovered that in the execution process of graph query statements in the related technology, if there are conditional constraints on the indefinite jump query path, the execution process is often time-consuming and the system overhead is large. The reason is that for the conditional constraints in the indefinite jump query, the graph query engines in the related technology all adopt the execution strategy of "search first and then filter". In other words, the graph query engine will first search out all the preliminary screening paths that meet the topological structure conditions (indefinite jump constraints), and then apply the conditional constraints on these preliminary screening paths for filtering, discarding the preliminary screening paths that do not meet the constraints, and obtain the final result. In this execution process, the execution overhead of searching all the preliminary screening paths is considerable, and as the scale of the attribute graph increases, the execution overhead will grow exponentially, and this type of execution overhead can be optimized through technical means. The following will explain the technical discovery in detail.

[0081] Figure 3 An exemplary graph query execution plan is shown. Figure 2 . Referring to the attached figure, in the execution plan, the starting step is "NodeUniqueIndexSeek", which uses a unique index to find a node with a specific id attribute value in the Account type node. "$autoint_0" is an automatically generated anonymous variable used to represent the id value specified in the graph query, that is, 10. In this step, the Account node with id=10 can be located as the starting node acc. After finding the starting node, the next step in the execution plan is to execute the indefinite jump path expansion operator "VarLengthExpand", which will expand the path with a length of 1 to 3 along the connection edge of the Transfer type, starting from the starting node acc. "VarLengthExpand(All)" means that the operation will consider all possible path lengths and return all matching paths. Next, the execution plan applies a filter (Filter operator) to all paths that meet the indefinite jump query conditions. The filter will check whether the timestamp attribute of each connection edge on each path is arranged in ascending order (isAsc). Only paths that meet the filter conditions will be retained, and the rest will be discarded. After that, the "Projection" operator projects the filtered path according to the variables and attributes that need to be included in the query result, and renames the projected data record to p. In the last step of the execution plan, the "ProduceResults" operator returns the result / result set p as the final query result. Figure 2 The example graph query execution is completed.

[0082] As can be seen from the above examples, in the execution of the conditional constraints in the indefinite jump query, the execution strategy of "search first and then filter" is adopted. Filter is an operator that filters the entire path, which inevitably leads to the existence of a large number of invalid paths in the first searched path that will not eventually appear in the result set. The search and storage process of these paths consumes a lot of computing resources. In order to optimize this process, the inventor proposes an optimized execution method for graph query, which pushes the operator that performs filtering down to the indefinite jump path expansion operator to form a combined operator, and applies path constraints to filter the connection edges while executing path expansion. That is, while the path is being expanded, the next candidate connection edge to be added to the path is filtered based on the path constraint. If the addition of the candidate connection edge causes the path to no longer satisfy the given path constraint, the further expansion of the path along the candidate connection edge is terminated in time to avoid the waste of computing resources. This execution strategy, especially when processing graph queries of large-scale attribute graphs, can significantly reduce unnecessary path expansion calculations and storage overheads, and improve the execution performance of graph queries.

[0083] Following the above technical ideas, Figure 4 In FIG. 1 , a flowchart of a method for optimizing execution of a graph query according to an embodiment of the present specification is shown. It can be understood that the method can be executed by any device, equipment, platform, or device cluster with computing and processing capabilities. Figure 4 , the method at least comprises the following steps: S401: receiving a graph query statement, the graph query statement comprising a hop count range of an indefinite hop path and a path constraint on a connecting edge. S403: executing a target execution plan generated for the graph query statement, comprising, when extending connecting edges for a first path, filtering candidate connecting edges according to the path constraint, wherein the hop count of the first path after extension belongs to the hop count range.

[0084] In the right Figure 4 Before elaborating on the method flow shown, a brief introduction is first given to the execution plan corresponding to the method flow. Figure 5 An execution plan for executing a query in one embodiment is shown, which corresponds to Figure 2Disclosed exemplary graph query statements. Compared with the execution plan in the related art disclosed above, it can be seen that the target execution plan of this embodiment includes an iteratively executed combinatorial operator (the operator with ID 2 in the figure), and the combinatorial operator includes an edge expansion operator (shown as the VarLengthExpand operator in the figure) for searching for a path that satisfies the hop count range, and an expansion filter operator (shown as the VarLenEdgeFilter operator in the figure) for filtering the connection edges based on the path constraint. By executing the combinatorial operator, the candidate connection edges can be filtered according to the path constraint (shown as isAsc in the figure) while the connection edges are extended. It can also be known that since the connection edges have been filtered while the connection edges are extended, in the execution plan of this embodiment, the operator for filtering the path (for example, the Filter operator) is removed, and the path obtained after the connection edges are extended has satisfied the path constraint.

[0085] It should be noted that in the embodiments of this specification, for the sake of simplicity, an indefinite jump query statement with a hop range of [1,3] and a single path constraint (arranged in ascending order) is used as an example to describe one or more embodiments, but it should be understood that in specific practice, according to data query and processing requirements, graph query statements usually have extremely complex path constraints and a wider hop range. In addition, in the explanation of the execution plan, some common operators (for example, Projection, VarLengthExpand, etc.) are used as examples, but it should be known that these operators are only used as examples to illustrate the implementation method, and are not limited. In actual application scenarios, different graph query engines, according to different graph query statements, the generated execution plan may include other operators. One or more embodiments in this specification are intended to provide an optimized execution method for indefinite jump graph queries containing path constraints, without being limited to a specific graph query statement composition or a specific operator combination. All scenarios related to the technical concept provided by the embodiments of the present invention can apply the method provided by the embodiments of the present invention.

[0086] The following will be combined with the attached Figure 5 , for attachment Figure 4 The method flow shown is described in detail.

[0087] Step S401: receiving a graph query statement, wherein the graph query statement includes a hop count range of an indefinite hop path and path constraints on connecting edges.

[0088] Specifically, in this embodiment, receiving the corresponding Figure 2The graph query statement includes the hop count range of the indefinite hop path: 1..3, and the path constraint on the connecting edges (timestamp ascending order): isAsc(getMemberProp(e1,'timestamp')) = true.

[0089] Next, in step S403, a target execution plan generated for the graph query statement is executed, including filtering candidate connection edges according to the path constraints when extending the connection edges of the first path, wherein the number of hops of the first path after expansion belongs to the hop number range.

[0090] In this embodiment, the target execution plan corresponds to Figure 5 As shown. In the process of executing the target execution plan, firstly, according to the definition of the starting node in the graph query statement, a matching node is determined in the property graph as the starting node for executing the graph query. This operation corresponds to the execution step of the node search operator NodeUniqueIndexSeek in the execution plan.

[0091] In a scenario of this embodiment, the connection edge defined in the graph query statement may be an outgoing edge, that is, the writing paradigm of the graph query statement is "source node-outgoing edge->destination node", for example:

[0092] (acc:Account{id:10})-[e1:transfer*1..3]->(other:Account)

[0093] In this scenario, the node search operator is executed to search for the account type node acc with attribute id=10 from the attribute graph as the starting node.

[0094] In another scenario of this embodiment, the connection edge included in the graph query statement may be an incoming edge, that is, the writing paradigm of the graph query statement is "destination node <-incoming edge-source node", for example:

[0095] (acc:Account{id:10})<-[e1:transfer*1..3]-(other:Account)

[0096] In this scenario, the node search operator is executed to search for the node other of type account from the attribute graph as the starting node.

[0097] In another scenario of this embodiment, the connection edge contained in the graph query statement may also be an undirected edge, that is, the writing paradigm of the graph query statement is "node-undirected edge-node", for example:

[0098] (acc:Account{id:10})-[e1:transfer*1..3]-(other:Account)

[0099] This scenario is equivalent to the combination of the above two scenarios. The node search operator is executed to select the node other of account type from the attribute graph and the account type node acc with attribute id=10 as the starting node.

[0100] It should be noted that in the introduction of each embodiment of this specification, a graph query statement with connecting edges as outgoing edges will be used as an example for explanation, and the technical ideas involved can be equivalently reasoned and applied to the execution of other graph query statements containing directed / undirected connecting edges.

[0101] After determining the starting node, the graph query engine will start from the starting node, and according to the definition of the connection edge in the graph query statement and in combination with the path constraints, expand the first path along each candidate connection edge in the attribute graph.

[0102] Candidate connection edges refer to the connection edges with directions defined by the graph query statement connected to the node pointed to by the currently processed connection edge. In the attribute graph, the node pointed to by the currently processed connection edge can directly reach another node through each candidate connection edge. Fig. 6A FIG. 1 is a schematic diagram of an exemplary candidate connection edge. In the figure, the node pointed to by the connection edge currently being processed is node A, and there are 3 outgoing edges on node A:<A,B> ,<A,C> and<A,D> , these three outgoing edges are candidate connecting edges.

[0103] Extending the connection edge of the first path means adding any selected candidate connection edge to the first path, and using the candidate connection edge as the connection edge currently being processed to carry out the next round of connection edge extension. As this process progresses, the first path will continue to extend until the constraint on the number of hops in the graph query statement (i.e., the hop count range) is met. In this embodiment, the operation of extending the connection edge of the first path corresponds to the execution of the edge extension operator VarLengthExpand in the execution plan.

[0104] It is not difficult to see that each time an extended edge operation is performed, there may be multiple candidate edges to choose from. Selecting different candidate edges as extended edges to extend the first path means that the first path will extend in different directions, that is, the selection of candidate edges determines the subsequent extension direction of the first path. It can be seen that if during a certain edge extension process, the selected candidate edge causes the first path to violate the path constraint in the graph query statement, then all subsequent extended edge operations will become invalid because the first path no longer meets the path constraint, and is doomed to fail to generate valid query results.

[0105] In this embodiment, along with the operation of extending the connection edge of the first path, the selected candidate connection edges are filtered at the same time. This step can ensure that each operation of extending the connection edge will not cause the first path to violate the path constraint. In other words, this step can filter out the candidate connection edges that will cause the first path to violate the path constraint in real time, preventing the first path from continuing to expand along these directions.

[0106] Figure 6B An exemplary diagram of extending a connection edge operation is provided. In the graph query statement corresponding to this example, the values ​​of the attribute v on the path connection edge are arranged in ascending order as the path constraint. Referring to the accompanying figure, when the currently processed connection edge is extended, among the three candidate connection edges on node A,<A,C> ,<A,D> The addition of will cause the first path to violate the path constraint, so these two edges will not be used as extended connecting edges, but as connecting edges.<A,B> The addition of meets the path constraint, and the attribute v on each connecting edge of the first path remains in ascending order, so this connecting edge can be selected and added to the first path as an extended connecting edge.

[0107] In the above-described embodiment involving the operation of extending the connecting edge, it is necessary to confirm that the path constraint has the Early Termination Property (ETP), that is, for any path L1, and any path L2 obtained by extending the connecting edge based on L1, if L1 can no longer satisfy the path constraint P, then L2 must also fail to satisfy the path constraint P. For this reason, in the process of executing a graph query statement that processes a path constraint with an early termination feature, when a candidate connecting edge causes the first path to fail to satisfy the path constraint, any path obtained by continuing to expand backward based on the candidate connecting edge will fail to satisfy the path constraint. Therefore, in the above embodiment, when an invalid candidate connecting edge is encountered, the search along the candidate connecting edge can be stopped in advance.

[0108] According to one implementation, the path constraint may be a constraint imposed on the relationship between each connection edge in an indefinite hop path. For example, in a query of a personal relationship attribute graph, if one wants to find users with indirect acquaintances, then one needs to impose constraints related to the time of acquaintance on each connection edge with an odd or even connection depth. In other words, the path constraint includes a second constraint imposed on the relationship between the second data of each connection edge in the indefinite hop path, and the second data includes: a label, an attribute, or a timestamp. When filtering candidate connection edges, the second data of any candidate connection edge may be compared with the second data of the target connection edge in the first path based on the second constraint, and based on the comparison result, it is determined whether the candidate connection edge is used as an extended connection edge.

[0109] In the above implementation, when the second attribute is an attribute or a timestamp that can be numerically compared, the second constraint can be defined as a numerical continuity constraint on the second attribute of each connection edge in the path, for example, ascending order, descending order, fixed interval, etc. At this time, the filtering of the candidate connection edge can be converted into a comparison between the candidate connection edge and the previous connection edge (i.e., the last connection edge in the first path).

[0110] In one scenario, the second constraint is that the second data is arranged in ascending order; and the step of determining whether the candidate connection edge is used as an extended connection edge based on the comparison result includes: if the second data of the candidate connection edge is greater than the second data of the last connection edge in the first path, the candidate connection edge is determined as an extended connection edge. In another scenario, the second constraint is that the second data is arranged in descending order; and the step of determining whether the candidate connection edge is used as an extended connection edge based on the comparison result includes: if the second data of the candidate connection edge is less than the second data of the last connection edge in the first path, the candidate connection edge is determined as an extended connection edge.

[0111] According to another implementation, the path constraint may be a constraint imposed on a specific connection edge in an indefinite hop path. For example, in a query of a capital transaction attribute graph, if one wants to find a transaction chain triggered by a specific transaction, then one needs to constrain a specific connection edge corresponding to the specific transaction, and the specific connection edge is the first connection edge of the indefinite hop path. Similarly, if one wants to find a transaction chain ending at a specific transaction, the specific connection edge is the last connection edge of the indefinite hop path. In some scenarios, the specific connection edge may be the first connection edge, the last connection edge, or an intermediate connection edge of the indefinite hop path. When extending a connection edge, if the connection edge to be extended is the specific connection edge, then it needs to be filtered according to the path constraint.

[0112] In one example, the path constraint includes a first constraint on the first data of a specific connection edge in the indefinite hop path, and the first data includes: a label, an attribute or a timestamp; the candidate connection edges are filtered according to the path constraint, including: if the connection edge to be extended is a specific connection edge, then determining whether the candidate connection edge is used as an extended connection edge based on whether the first data of any candidate connection edge satisfies the first constraint.

[0113] The above is an explanation of the method for filtering candidate connection edges in the path extension process. By continuously performing edge extension operations including connection edge filtering, it can be ensured that the first path always satisfies the path constraint. When the number of connection edges included in the first path satisfies the hop count range, the first path is recorded in the result set of the graph query statement.

[0114] In practice, the execution method of this complete graph query statement including edge filtering operation can be implemented through a variety of algorithms, for example: recursively or non-recursively implement depth-first and breadth-first search of the property graph, and add filtering operations on the connected edges in each step of the search process.

[0115] In a specific example, the connection edge expansion of the first path can be implemented based on depth-first search in a non-recursive manner. Figure 7 Pseudocode for implementing the extended edge operation in this example is shown. Non-recursive depth-first search requires the use of a stack to temporarily store intermediate results. In this code implementation, stackDFS is the target stack, which stores the current first path. Since the maximum number of hops of the first path is the upper limit of the hop range defined in the graph query statement, the depth of the target stack can be set to the upper limit of the hop range. nextEdge is a candidate edge, and check predicate is a filtering check based on path constraints. currentLength is the number of hops of the current first path in the target stack. max_hop and min_hop are the upper and lower bounds of the hop range, respectively. resultArray stores the result set of the graph query statement.

[0116] Overall, this code implementation is as follows: first, in the attribute graph, the starting node is determined according to the graph query statement, and any connection edge that satisfies the path constraint is selected on the starting node as the first connection edge of the first path, and is pushed into the target stack to complete the initialization of the target stack (corresponding to line 1 in the pseudocode). The iterative process begins (pseudocode lines 2-21), and each round of iteration is based on the last connection edge of the first path (i.e., the top element of the target stack) to expand the connection edge. Specifically, in a single iteration round, the top element of the stack is read as the connection edge of the current search (line 3 in the pseudocode). Determine whether the number of hops of the current first path in the target stack has reached the upper limit of the hop range. If so, directly include the current first path in the result set, and pop the top element of the stack (pseudocode lines 4-8). Because the first path has reached the upper limit of the number of hops, there is no possibility of continuing to search backwards, and it can go back one step and continue to expand backwards along the previous connection edge. If the current first path has not reached the upper limit of the hop count range, start to expand the connection edge and filter the candidate connection edges. Specifically, if there is a valid connection edge that meets the path constraint among the candidate connection edges, then the connection edge can be used as an extended connection edge and pushed into the target stack, indicating that the first path extends one hop backward along the extended connection edge, and the subsequent steps will continue to search along the extended connection edge (lines 9-13 in the pseudo code); if there is no valid connection edge among the candidate connection edges, or there is no connection edge that meets the path constraint, it means that it is meaningless to continue searching backward along the currently processed connection edge, so the top element of the stack can be popped out, and the first path moves back one step (line 15 in the pseudo code). Popping the stack will cause the number of hops of the current first path in the target stack to change, so when the popping operation occurs, it can be checked whether the number of hops of the current first path is not less than the lower limit of the hop count range. If the lower limit constraint is met, the current first path can be included in the result set (lines 14-20 in the pseudo code). The above is an explanation of one of the operations of expanding the connection edges in a non-recursive depth-first search. The above steps are continuously executed to gradually expand the first path. The above method is executed until the target stack is empty, indicating that the first path search along the connection edge of the starting node has been completed. At this time, the target stack needs to be initialized again, and other connection edges on the starting node that can be used as the first connection edge of the first path are pushed into the target stack to start the above iterative processing. Finally, the result set of the graph query statement can be obtained, which contains several first paths that meet the query conditions.

[0117] The above is a brief introduction to the execution process of the pseudocode of this example. This example can also be summarized as follows: each connection edge of the first path is saved in the target stack in sequence. The depth of the target stack is the upper limit of the hop count range. When the target stack is empty, the starting node of the first path is determined according to the graph query statement, and any connection edge on the starting node that satisfies the path constraint is pushed into the target stack. The filtering of candidate connection edges includes: obtaining the first element of the target stack, and using the node pointed to by the corresponding connection edge as an extension node. Several connection edges of the extension node are used as candidate connection edges, and any connection edge that satisfies the path constraint is selected from them and pushed into the target stack; or, if the candidate connection edges do not contain connection edges that satisfy the path constraint, the first element of the stack is popped from the target stack.

[0118] In some embodiments of the present specification, a method for extending constraints on a graph query language is also provided to enhance the grammatical expression ability and graph query execution ability of the graph query language, thereby broadening the application scope of the graph query language.

[0119] Specifically, in some graph query languages ​​(for example, GQL), there is a lack of support for single-element level filtering conditions. For example, filtering conditions applied to a single node or a single connecting edge. Correspondingly, a first keyword can be added to indicate the termination condition for path extension during the execution of the graph query statement. When the graph query searches for an element that satisfies the termination condition, the search is stopped. The definition of the termination condition can be placed after the first keyword, thereby expanding the support of the graph query language for single-element filtering conditions. It should be noted that the termination condition can be applied to a node or to a connecting edge; the termination condition can be a constraint on an attribute or a constraint on a label. The first keyword can be placed after the quantifier of the graph query statement (for example, [1..3] in an indefinite jump query), or it can be inserted into other positions in the graph query statement without destroying the query keyword syntax. This specification does not make specific restrictions on this.

[0120] In one embodiment, the graph query statement may also include a first keyword, and the first keyword is used to define the first termination condition of the path extension. For example, the first keyword is UNTIL, and a termination condition is given after it, indicating that when the edge extension operator extends the first path to a certain connection edge, the connection edge or the destination node it points to meets the termination condition, then the search for the connection edge / connection edge extension is stopped. In one example, the condition UNTIL b.type=people is placed after the upper bound of the hop count range in the graph query statement, indicating that when a node (b) or connection edge (b) with a type attribute of people is searched, the current search is stopped. That is to say, in the process of executing the graph query with the first keyword, the filtering of candidate connection edges also includes: for any candidate connection edge that meets the path constraint, performing a target judgment based on the first termination condition, and determining whether the candidate connection edge is used as an extended connection edge according to the judgment result. The first termination condition can be a constraint on the connection edge or a constraint on the node.

[0121] In an implementation of the above embodiment, the first termination condition includes a third constraint on the connection edge, and the target determination includes: determining the candidate connection edge according to the third constraint.

[0122] In another implementation of the above embodiment, the first termination condition includes a fourth constraint on the node, and the target determination includes: determining the node to which the candidate connection edge points according to the fourth constraint.

[0123] In addition, in some graph query languages ​​(e.g., GQL), there is still a lack of support for setting filtering conditions at the level of repeated elements. For example, in an indefinite jump query, the continuity constraint on a certain attribute of the connection edge. Correspondingly, a first function can be added to construct an inspection window. During the execution of the graph query statement, the window is placed on the searched path, and the connection edges covered by the window are checked based on the filtering conditions. It should be pointed out that according to the first function, the inspection window can be constructed as a window of the same length as the target query path for a one-time filtering check; it can also be constructed as a window of preset width according to the definition given in the graph query statement. During the execution of the graph query statement, the searched path is checked in segments, or by sliding on the path to achieve an inspection of the entire path. The first function can be placed after the MATCH clause of the graph query statement and before the RETURN clause, or it can be inserted into other positions in the graph query statement without destroying the query keyword syntax. This specification does not make specific restrictions on this.

[0124] In another embodiment, the graph query statement may further include a first function, which is used to define a first window. The above-mentioned extended filter operator may be implemented as a window filter operator. In a specific example, the first function is named sw, and the first function is included in the graph query statement, which may be shown as WITH sw onp as pp, indicating that a first window pp is constructed on path p (the width of the first window may be a preset default value, or a unit length of 1, or any value defined by the user in the graph query statement, which is not limited here). The window filter operator is executed, and the first window starts from the starting point of the first path, and filters the nodes and connecting edges selected in the first window based on the path constraint. As the first path continues to expand, the first window slides sequentially along the path expansion direction on the first path, and executes the window filter operator until the terminal node / last connecting edge of the first path is selected in the first window. That is, in this embodiment, filtering the candidate connecting edges according to the path constraint includes: filtering the candidate connecting edges covered by the first window according to the path constraint by executing the window filter operator.

[0125] In one implementation of the above embodiment, the first window may have a first width. For example, the paradigm of the first function may be defined as sw(length) for constructing the first window, and its window width length may be defined by the user in the graph query statement. For example, sw(2) indicates that the width of the first window is 2, which can select a path of length 2 (including 3 nodes and 2 connecting edges). That is, in this implementation, the filtering of the candidate connecting edges covered by the first window includes: connecting several candidate connecting edges to be filtered with the first path to obtain a temporary extended path. The temporary extended path is subjected to a window detection to determine whether several candidate connecting edges are used as extended connecting edges; the window detection includes placing the first window at the end of the temporary extended path, and detecting the path segments within the first window based on the path constraints.

[0126] Based on the above implementation, in a specific scenario, the first window also has a first step length. For example, the paradigm of the first function can be defined as sw(length,step) for constructing the first window, and its sliding step length on the first path can be defined by the user in the graph query statement (step parameter). In one example, the first window is defined as sw(2,1) with a step length of 1. Then, in each connection edge expansion, the window filter operator needs to be executed to take out the last two segments of the current first path to determine whether it meets the path constraint. In another example, the first window is defined as sw(3,2) with a step length of 2. Then, when the number of hops of the current first path reaches a multiple of the step length (when the first path contains 2, 4, 6...connection edges), the window filter operator can be executed to take out the last three segments of the current first path to determine whether it meets the path constraint. That is, in this scenario, the window detection of the temporary extended path includes: when the number of connection edges contained in the temporary extended path is a multiple of the first step length, the window detection of the temporary extended path is performed.

[0127] The above is an introduction to the main process of an optimized execution method for graph query provided in the embodiments of this specification. Although the above embodiments mainly use the GQL standard graph query statement and its corresponding graph query engine as an example to illustrate the method flow, the technical concept embodied therein can also be applied to the execution process of other graph query engines on related graph query statements.

[0128] By adopting the above method provided in the embodiment of this specification, in the process of executing graph queries, according to the constraints on the path in the statement, when expanding the connecting edges, a path constraint-based check can be performed in real time to implement dynamic path screening and pruning, which significantly reduces the number of paths generated that do not meet the graph query conditions, thereby improving the execution efficiency of the graph query.

[0129] In this specification, the word "first" in terms such as first path and first data, and the corresponding "second" and "third" (if any), etc. in the text are merely for the convenience of distinction and description and do not have any limiting meaning.

[0130] The foregoing describes certain embodiments of the present specification, and other embodiments are within the scope of the appended claims. In some cases, the actions or steps described in the claims may be performed in an order different from that in the embodiments, and the desired results may still be achieved. In addition, the processes depicted in the accompanying drawings do not necessarily have to be performed in the specific order or sequential order shown to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0131] Figure 8Schematic diagram of an optimized execution device for graph query according to an embodiment of this specification. The device 800 is deployed in a computing device, which can be implemented by any device, equipment, platform, device cluster, etc. with computing and processing capabilities. Figure 4 The method embodiment shown corresponds to the embodiment shown in FIG. 800 . The device 800 includes:

[0132] The receiving module is configured to receive a graph query statement, wherein the graph query statement includes a hop count range of an indefinite hop path and a path constraint on a connecting edge.

[0133] The filtering module is configured to execute a target execution plan generated for the graph query statement, including filtering candidate connection edges according to the path constraints when extending the connection edges of the first path, wherein the number of hops of the first path after expansion belongs to the hop number range.

[0134] According to another embodiment of the present specification, there is also provided a computer program product, including a computer program / instruction, which implements the aforementioned combination when executed by a processor. Figure 4 The steps of the method.

[0135] According to another embodiment, the present specification further provides a computing device, including a memory and a processor, wherein the memory stores executable code, and when the processor executes the executable code, the aforementioned combination is implemented. Figure 4 The steps of the method.

[0136] Those skilled in the art should be aware that in one or more of the above examples, the functions described in the embodiments of the present invention can be implemented by hardware, software, firmware, or any combination thereof. When implemented by software, these functions can be stored in a computer-readable medium or transmitted as one or more instructions or codes on a computer-readable medium.

[0137] The specific implementation methods described above further describe the purpose, technical solutions and beneficial effects of the embodiments of the present invention in detail. It should be understood that the above description is only a specific implementation method of the embodiments of the present invention and is not intended to limit the scope of protection of the present invention. Any modification, equivalent replacement, improvement, etc. made on the basis of the technical solution of the present invention shall be included in the scope of protection of the present invention.

Claims

1. A method for optimizing execution of a graph query, executed by a graph query engine, comprising: receiving a graph query statement, wherein the graph query statement includes a hop count range of an indefinite hop path and a path constraint on a connecting edge; Executing a target execution plan generated for the graph query statement, including, when extending connecting edges for a first path, filtering candidate connecting edges according to the path constraints, wherein the number of hops of the first path after expansion falls within the hop number range.

2. The method according to claim 1, wherein: The target execution plan includes an iteratively executed combinatorial operator, wherein the combinatorial operator includes an edge extension operator for searching for a path that satisfies a hop count range, and an extension filtering operator for filtering connection edges based on the path constraint; filtering candidate connection edges according to the path constraint includes: By executing the combination operator, the candidate connection edges are filtered according to the path constraints.

3. The method according to claim 1, wherein: The connecting edge is an outgoing edge.

4. The method according to claim 1, wherein: The path constraint includes a first constraint on first data of a specific connection edge in the indefinite hop path, wherein the first data includes: a label, an attribute or a timestamp; filtering the candidate connection edges according to the path constraint includes: If the connection edge to be extended is a specific connection edge, whether the candidate connection edge is used as an extended connection edge is determined according to whether the first data of any candidate connection edge satisfies the first constraint.

5. The method according to claim 4, wherein: The specific connection edge is at least one of the following: the first connection edge and the last connection edge.

6. The method according to claim 1, wherein: The path constraint includes a second constraint imposed on a relationship between second data of each connection edge in the indefinite hop path, the second data including: a label, an attribute or a timestamp; filtering the candidate connection edges according to the path constraint includes: The second data of any candidate connection edge is compared with the second data of the target connection edge in the first path based on the second constraint, and according to the comparison result, it is determined whether the candidate connection edge is used as an extended connection edge.

7. The method according to claim 6, wherein: The second data is an attribute or a timestamp, and the target connection edge is the last connection edge; The second constraint is that the second data is arranged in ascending order; The step of determining whether the candidate connection edge is used as an extended connection edge according to the comparison result includes: if the second data of the candidate connection edge is greater than the second data of the last connection edge, determining the candidate connection edge as an extended connection edge; or The second constraint is that the second data is arranged in descending order; and determining whether the candidate connection edge is used as an extended connection edge based on the comparison result includes: if the second data of the candidate connection edge is less than the second data of the last connection edge, determining the candidate connection edge as an extended connection edge.

8. The method according to claim 1, wherein: Each connecting edge of the first path is sequentially stored in the target stack; The depth of the target stack is the upper limit of the hop count range; the filtering of the candidate connection edges includes: Get the first element of the target stack, and use the node pointed to by the corresponding connection edge as the extension node; Taking several connection edges of the extended node as candidate connection edges, selecting any connection edge that satisfies the path constraint and pushing it into the target stack; or, If the candidate connection edges do not include a connection edge that satisfies the path constraint, the stack head element is popped from the target stack.

9. The method according to claim 8, wherein filtering the candidate connection edges further comprises: When the target stack is empty, the starting node of the first path is determined according to the graph query statement, and any connecting edge on the starting node that satisfies the path constraint is pushed into the target stack.

10. The method according to claim 1, wherein: The graph query statement also includes a first keyword, and the first keyword is used to define a first termination condition for path extension; The filtering of the candidate connection edges further includes: For any candidate connection edge that meets the path constraint, a target determination is performed on it based on the first termination condition, and according to the determination result, it is determined whether the candidate connection edge is used as an extended connection edge.

11. The method according to claim 10, wherein: The first termination condition includes a third constraint on the connecting edge, and the target determination includes: The candidate connecting edges are determined according to the third constraint.

12. The method according to claim 10, wherein: The first termination condition includes a fourth constraint on the node, and the target determination includes: According to the fourth constraint, the node to which the candidate connecting edge points is determined.

13. The method according to claim 2, wherein: The graph query statement further includes a first function, and the first function is used to define a first window; The extended filter operator is implemented as a window filter operator; the filtering of the candidate connection edges according to the path constraint includes: By executing the window filtering operator, the candidate connection edges covered by the first window are filtered according to the path constraint.

14. The method according to claim 13, wherein: The first window has a first width; The filtering of the candidate connection edges covered by the first window includes: Connecting a number of candidate connection edges to be filtered with the first path to obtain a temporary extended path; A window detection is performed on the temporary extended path to determine whether a number of candidate connection edges are used as extended connection edges; the window detection includes placing the first window at the end of the temporary extended path and detecting the path segments within the first window based on the path constraint.

15. The method according to claim 14, wherein: The first window also has a first step length; the performing window detection on the temporary extension path includes: When the number of connection edges included in the temporary extended path is a multiple of the first step length, the window detection is performed on the temporary extended path.

16. A graph query optimization execution device, the device comprising: A receiving module is configured to receive a graph query statement, wherein the graph query statement includes a hop count range of an indefinite hop path and a path constraint on a connecting edge; The filtering module is configured to execute a target execution plan generated for the graph query statement, including filtering candidate connection edges according to the path constraints when extending the connection edges of the first path, wherein the number of hops of the first path after expansion belongs to the hop number range.

17. A computer program product, comprising a computer program / instruction, which, when executed by a processor, implements the steps of the method according to any one of claims 1 to 15.

18. A computing device comprising a memory and a processor, characterized in that: The memory stores executable codes, and when the processor executes the executable codes, the method according to any one of claims 1 to 15 is implemented.

Images