Method and apparatus for optimized execution of graph queries

Abstract

The embodiment of the present specification provides a method for optimizing execution of a graph query, executed by a graph query engine, comprising: receiving a graph query statement, the graph query statement containing a hop range of indefinite hop path and a path constraint on a connection edge; executing a target execution plan generated for the graph query statement, wherein it includes filtering candidate connection edges according to the path constraint when expanding a connection edge for a first path, wherein the hop number of the first path belongs to the hop range after expansion.

Description

TECHNICAL FIELD

[0001] One or more embodiments of the present specification relate to the technical field of computer data query, and particularly relate to a method and device for optimizing execution of a graph query. BACKGROUND

[0002] With the development of big data and artificial intelligence, graph structure data is increasingly used to record and process business data in more and more scenarios. For example, in a social platform, graph structure data is used to depict social relationships between users; in a payment platform, graph structure data is used to construct a complex payment relationship graph. Consequently, the demand for graph structure data queries is growing, and therefore, various graph databases have been designed for the characteristics of graph structure data to store and query graph structure data.

[0003] The data storage form of a graph database is different from that of a conventional relational database, and the structured query language based on data table relationships cannot be applied to a graph database. Therefore, different graph databases are equipped with their own matching graph query languages to effectively write graph query statements and perform query operations on graph structure data in a graph database. In actual applications, query efficiency is an important indicator of the performance of graph query execution.

[0004] Therefore, in the process of using a graph query language to execute a graph structure data query, improving the execution efficiency of a graph query is one of the technical problems to be solved. SUMMARY

[0005] One or more embodiments of the present specification describe a method and device for optimizing execution of a graph query. For path constraint conditions existing in a graph query statement, optimization analysis is performed, and path constraint checking is performed synchronously in the process of path expansion search, and invalid connection edge expansion is intercepted in real time, effectively preventing waste of computing resources in invalid path calculation, thereby improving the execution performance of a graph query and solving the above 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, comprising:

[0007] receiving a graph query statement, the graph query statement containing a hop range of an indefinite hop path and a path constraint on a connection edge.

[0008] executing a target execution plan generated for the graph query statement, wherein it includes filtering candidate connection edges according to the path constraint when expanding a connection edge of a first path, wherein the hop number of the first path belongs to the hop range after expansion.

[0009] According to an implementation, the target execution plan comprises a combined operator for iterative execution, the combined operator comprises an edge expansion operator for searching a path satisfying a hop range, and an expansion filter operator for filtering a connection edge based on the path constraint. The filtering of the candidate connection edge according to the path constraint comprises: filtering the candidate connection edge according to the path constraint by executing the combined operator.

[0010] According to an implementation, the connection edge is an out-edge.

[0011] According to an implementation, the path constraint comprises a first constraint on first data of a specific connection edge in the indefinite-hop path, the first data comprises a label, an attribute, or a timestamp. The filtering of the candidate connection edge according to the path constraint comprises:

[0012] If the connection edge to be expanded is the specific connection edge, it is determined whether the candidate connection edge is an expanded connection edge according to whether first data of the candidate connection edge satisfies the first constraint.

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

[0014] According to an implementation, the path constraint comprises a second constraint on a relationship between second data of each connection edge in the indefinite-hop path, the second data comprises a label, an attribute, or a timestamp. The filtering of the candidate connection edge according to the path constraint comprises:

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

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

[0017] The second constraint is that the second data is arranged in ascending order, and it is determined whether the candidate connection edge is an expanded connection edge according to the comparison result, which comprises: if the second data of the candidate connection edge is greater than the second data of the last connection edge, the candidate connection edge is determined as the expanded connection edge. Or,

[0018] The second constraint is that the second data is arranged in descending order, and it is determined whether the candidate connection edge is an expanded connection edge according to the comparison result, which comprises: if the second data of the candidate connection edge is less than the second data of the last connection edge, the candidate connection edge is determined as the expanded connection edge.

[0019] According to an implementation, each connection edge of the first path is saved in the target stack in sequence. A depth of the target stack is an upper bound of the hop range. The filtering of the candidate connection edge includes:

[0020] An element at a top of the target stack is obtained, and a node pointed to by a connection edge corresponding to the element is taken as an expansion node.

[0021] Several connection edges of the expansion node are taken as candidate connection edges, and any connection edge satisfying the path constraint is selected from the candidate connection edges and pushed into the target stack. Alternatively,

[0022] If the candidate connection edge does not include a connection edge satisfying the path constraint, the element at the top of the target stack is popped out of the target stack.

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

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

[0025] According to an implementation, the graph query statement further includes a first keyword, and the first keyword is used to define a first termination condition of path expansion. The filtering of the candidate connection edge further includes:

[0026] The target determination based on the first termination condition is performed on any candidate connection edge satisfying the path constraint, and whether the candidate connection edge is taken as an expansion connection edge is determined according to a determination result.

[0027] In one scenario of the above implementation, the first termination condition includes a third constraint on a 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 a node, and the target determination includes determining a node pointed to by the candidate connection edge according to the fourth constraint.

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

[0030] The candidate connection edge covered by the first window is filtered according to the path constraint by executing the window filter operator.

[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] The several candidate connection edges to be filtered are connected with the first path to obtain a temporary extended path.

[0033] The temporary extended path is subjected to window detection to determine whether the several candidate connection edges are extended connection edges; the window detection includes placing the first window at the tail of the temporary extended path and detecting the path segment in the first window based on the path constraint.

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

[0035] When the number of connection edges contained 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, an apparatus for optimizing execution of a graph query is provided, and the apparatus includes:

[0037] A receiving module is configured to receive a graph query statement, the graph query statement containing a hop range of an indefinite hop path and a path constraint on a connection edge.

[0038] A 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 constraint when extending connection edges of a first path, wherein the number of hops of the first path belongs to the hop range after extension.

[0039] According to a third aspect, a computer program product is provided, including computer programs / instructions, which, when executed by a processor, implement the steps of the method of the first aspect.

[0040] According to a fourth aspect, a computing device is provided, including a memory and a processor, characterized in that the memory stores executable code, and the processor executes the executable code to implement the method of the first aspect.

[0041] In summary, by using the above method and apparatus disclosed in the embodiments of the present specification, in the process of executing a graph query, real-time path constraint-based checking can be performed when extending connection edges according to the path constraint in the statement, dynamic path screening and pruning are realized, the number of paths that do not meet the graph query condition is significantly reduced, and the consumption of computing resources on invalid paths is avoided, thereby improving the execution efficiency of the graph query. BRIEF DESCRIPTION OF DRAWINGS

[0042] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings needed to be used in the embodiments will be briefly introduced. Obviously, the drawings in the following description are only some embodiments of the present application, and other drawings can be obtained by those skilled in the art without any creative effort on the basis of these drawings.

[0043] Figure 1 An exemplary property graph disclosed in the present specification;

[0044] Figure 2 An exemplary graph query statement disclosed in the present specification;

[0045] Figure 3 An exemplary execution plan of a graph query disclosed in the present specification;

[0046] Figure 4 A flow chart of an optimized execution method of a graph query provided according to the embodiments of the present specification;

[0047] Figure 5 An exemplary execution plan of an exemplary graph query execution provided according to the embodiments of the present specification;

[0048] Figure 6A An exemplary candidate connection edge diagram provided according to the embodiments of the present specification;

[0049] Figure 6B An exemplary extended connection edge operation diagram provided according to the embodiments of the present specification;

[0050] Figure 7 An exemplary implementation diagram of an extended connection edge provided according to the embodiments of the present specification;

[0051] Figure 8 An exemplary optimized execution device diagram of a graph query provided according to the embodiments of the present specification. DETAILED DESCRIPTION

[0052] The schemes provided by the embodiments of the present specification will be described below in combination with the drawings.

[0053] As described above, the graph query language is a programming language for executing queries, operations and analysis of graph structure data in a graph database. The data structure of the graph database is different from that of the traditional relational database, and it focuses on connecting data and the data relationship therebetween. In order to more effectively process the associated queries of complex graph structure data, a graph query language needs to be specially designed to process the complex relationship between nodes, connection edges and properties in the graph structure data.

[0054] Commonly used graph query languages include Cypher, Gremlin, SPARQL, and the like. Each language has different syntax and functions, but can process graph structure data and complete graph query tasks. In order to unify the graph query language, the ISO / IEC standardization organization formulates the GQL standard (ISO / IEC 39075:2024) as the standard query language specification for graph databases.

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

[0056] The object of the graph query is the property graph, which is also the main data structure stored by the graph database, and is composed of nodes, connection edges, and properties. It is commonly used to represent data relationships that are not easily expressed in traditional relational data, and has a wide range of applications, such as social networks, recommendation systems, knowledge graphs, financial analysis, etc.

[0057] In the property graph, the topological relationship between data is expressed by nodes and connection edges, and properties are attached to nodes and connection edges to provide additional information for nodes or connection edges to describe specific characteristics. Generally, properties are stored in the form of "key-value pairs", where the key refers to the category of a certain property (for example, business category), and the value is the specific data of a certain property (for example, transfer). In some property graphs, nodes or connection edges also have labels, which are markers used to identify the category of nodes or connection edges, and different labels can be used to distinguish different types of elements in the property graph (for example, account nodes, user nodes). In some property graphs, nodes or connection edges can also have timestamps to record the generation and update time of the corresponding nodes or connection edges.

[0058] Figure 1 An exemplary property graph is shown, which is constructed based on a financial payment scenario. For ease of description, the nodes in the property graph are numbered, the user nodes are numbered as P n , the account nodes are numbered as A n , the connection edges between nodes are represented as <source node, destination node>, and the direction of the connection edge is from the source node to the destination node.

[0059] Referring to the drawings, the attribute graph is composed of nodes (shown as circles) and connecting edges (shown as arrow lines), on which there are respective labels (shown as the first line in the box) and attributes (shown as key: value in the box). The label represents the type of different elements in the attribute graph, for example, the label of node P1 is Person (user), the label of connecting edge <P2, P3> is guarantee (guarantee), and the label of connecting edge <A1, A2> is transfer (transfer). The attribute 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 connecting edge <A1, A2> is “T+0”. It should be noted that, for the sake of example, in this figure, the timestamp is represented in the form of T+n, with T representing the reference day and n representing the nth natural day after the reference day. For example, assuming that T is January 1, 2024, then T+1 represents January 2, 2024, T+2 represents January 3, 2024, and so on. In addition, in this figure, some attributes and labels are simplified, and some irrelevant attribute information is hidden, for example, the connecting edge between node P1 and node A1 only shows the label information “own” (own).

[0060] On the constructed attribute graph, graph query statements can be executed to perform data mining, relationship analysis, path finding, etc. The graph query statement is a query statement written by using a target graph query language. In an example, the graph query can be written in the language of GQL standard, for example:

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

[0062] Wherein, “()” is the identifier symbol corresponding to the node, the identifier m, n inside which is the variable representing the node; “[]” is the identifier symbol corresponding to the connecting edge, and the identifier r inside which is the variable representing the connecting edge; “-[r]-” indicates that the connecting edge between nodes m and n is an undirected edge, which can be replaced by the following directed edge form:

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

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

[0065] In some examples, a filtering query can also be performed on the labels or attributes of the nodes or connecting edges, for example as follows:

[0066] MATCH p = (m:Account {id: $id})-[r:transfer]-(n:Account) RETURN p;

[0067] wherein Account specifies the label of the node m, indicating that a node m with the label Account is sought; the "{}" is an identifier for the attribute, and the attribute filtering condition is located within it. This graph query statement matches the following subgraph path in the attribute graph to be queried: two Account nodes connected by a transfer connecting edge, one of which has an id value of $id.

[0068] In some other examples, a quantifier constraint can also be performed on the connecting edges in the path, for example as follows:

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

[0070] wherein "*" is an identifier for the variable-length quantifier syntax, and "$i" and "$j" respectively represent the lower and upper bounds of the variable-length quantifier, indicating a path pattern of connecting edges repeated a certain number of times within the given quantifier range. Due to the chain programming feature of the graph query language, the graph query statement of this example is also equivalent to the following statement:

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

[0072] The graph query statement in this example represents a query in an attributed graph for subgraph paths with the following characteristics: two Account nodes connected by i to j transfer connection edges. The connection edges between the two nodes can also be referred to as hops, therefore, the graph query with variable length quantifier as shown in the example can also be referred to as an indefinite hop query.

[0073] The above is a brief description of some example queries commonly seen in graph queries. In actual practice, a graph query statement can also include other clauses, such as LIMIT, DISTINCT, CASE, etc. This specification does not exemplify and elaborate here.

[0074] In actual applications, when business data is established and stored in the form of an attributed graph, a user's query usually concerns both the topological structure and the change in attribute data, which means that a graph query statement not only specifies label constraints on nodes or connection edges, but also precisely filters attribute data on paths. In a specific scenario, financial risk control needs to track the flow of funds and the change in the amount to discover suspicious behavior. In this scenario, a graph query statement not only needs to specify that an account transfers funds to other accounts through connection edges of type transfer, and that the number of transfers is not fixed, but also needs to ensure that the timestamp sequence corresponding to the transfer path between accounts in the query result is in ascending order. Such a graph query statement can effectively interpret the fund flow trajectory by conditionally constraining indefinite hop paths. Figure 2 An example graph query statement corresponding to this scenario in a related technology is shown.

[0075] Referring to the accompanying drawings, this graph query is used to find the transfer relationship between a specific account and other accounts in an attributed graph, and to ensure that these transfer relationships occur in ascending order of timestamp. Specifically:

[0076] " MATCH p=(acc:Account {id: 10}) ": This part of the query defines a path variable p starting from a node acc of label Account with attribute id equal to 10. " -[e1:transfer*1..3]-> ": This part of the query defines a path (connection edges / jumps) e1 from the specific account node acc to another account node other with label transfer, and in the path p, the path e1 can appear 1 to 3 times, that is, the transfer can be a one-time transfer or an indirect transfer through at most two intermediate account nodes. " WHERE isAsc(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 relationships (connection edges) in the path are in ascending order of timestamp, and if all transfer relationships in the path satisfy the ascending order of timestamp, the result of this filter condition clause is true. " RETURN p ": The query will finally return the path p that satisfies the above conditions. In summary, the graph query of this example is used to find all paths between the account with id 10 and other accounts through 1 to 3 transfers, and the transfers occur in ascending order of timestamp. Combined with the attribute graph shown in FIG. 8B, the graph query will return the path results as shown in Table 1. Figure 1

[0077] Table 1: Results of graph query example

[0078]

[0079] It can be seen that although the path A1→A2→A3→A4 is the account with id 10 reaching the target account node through 3 transfers, on the connection edge <A3, A4>, compared with the last transfer relationship connection edge <A2, A3>, it does not satisfy the filter condition of the ascending order of timestamp in the graph query, so this path is discarded.

[0080] ​The inventors found that in the execution process of a related-art graph query statement, if a condition constraint on an indefinite-hop query path appears in the statement, the execution process tends to be time-consuming and system-expensive. The reason is that for the condition constraint in an indefinite-hop query, the graph query engine of the related art adopts an execution strategy of "searching first and filtering later". That is, the graph query engine will first search out all the preliminary paths that satisfy the topological structure condition (the indefinite-hop constraint), and then on these preliminary paths, apply the condition constraint for filtering, discard the preliminary paths that do not satisfy the constraint condition, and obtain the final result. In this execution process, the execution overhead of searching all the preliminary paths is considerable, and as the scale of the attribute graph increases, the execution overhead will increase exponentially, and this kind of execution overhead can be optimized by technical means. The technical discovery will be described in detail below.

[0081] Figure 3 An example graph query execution plan is shown, which is generated based on the graph query example disclosed in the Figure 2 With reference to the accompanying drawings, 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, which represents the id value specified in the graph query, i.e. 10, in this step, the Account node with id=10 can be located as the starting node acc. After the starting node is found, the next step in the execution plan is to execute the indefinite-hop path expansion operator "VarLengthExpand", which will expand paths with lengths of 1 to 3 from the starting node acc along the connection edges of the Transfer type, "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) on all paths that satisfy the indefinite-hop query condition, which will check whether the timestamp attribute of each connection edge on each path is arranged in ascending order (isAsc), only the paths that satisfy the filter condition will be retained, and the rest of the paths will be discarded. Then, the "Projection" operator will project the filtered paths according to the variables and attributes that need to be included in the query result, and rename the projected data records as p. In the last step of the execution plan, the "ProduceResults" operator returns the result / result set p as the final query result. At this point, the example graph query in the Figure 2 is executed.

[0082] As can be seen from the above examples, in the execution of the condition constraint in the indefinite jump query, the execution strategy of "searching first and then filtering" is adopted, and the Filter is an operator for filtering the entire path, which inevitably leads to a large number of invalid paths in the searched path that will not appear in the final result set, and the searching and storage process of these paths consumes a large amount of computing resources. In order to optimize this process, the inventors propose a method for optimizing the execution of a graph query, which pushes down the execution of the filter operator to the indefinite jump path expansion operator to form a combined operator, and applies path constraint connection edge filtering while performing path expansion. That is, while expanding the path, 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 will cause the path to no longer meet the given path constraint, the further expansion of the path along the candidate connection edge is terminated in time to avoid wasting computing resources. This execution strategy, especially when processing large-scale attribute graphs, can significantly reduce unnecessary path expansion calculation and storage overhead, and improve the execution performance of the graph query.

[0083] According to the above technical concept, in Figure 4 , a flowchart of a method for optimizing the 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, device cluster with computing and processing capabilities. Referring to Figure 4 , the method at least includes the following steps: S401: receiving a graph query statement, the graph query statement containing a jump number range of an indefinite jump path and a path constraint on a connection edge. S403: executing a target execution plan generated for the graph query statement, which includes filtering the candidate connection edge according to the path constraint when expanding the first path connection edge, wherein the jump number of the first path belongs to the jump number range after expansion.

[0084] Before the method flow shown in Figure 4 is described in detail, the execution plan corresponding to the method flow will be briefly introduced. Figure 5 An execution plan for the execution of a graph query in one embodiment is shown, which corresponds to Figure 2The disclosed exemplary graph query statement. In contrast to the execution plan in the related art disclosed above, it can be seen that the target execution plan of the present embodiment includes a combined operator (the operator with Id 2 in the figure) that is iteratively executed, the combined operator including an edge expansion operator (shown as a VarLengthExpand operator in the figure) for searching for a path satisfying the hop range, and an expansion filter operator (shown as a VarLenEdgeFilter operator in the figure) for filtering the connection edge based on the path constraint. By executing the combined operator, the candidate connection edge can be filtered according to the path constraint (shown as isAsc in the figure) while expanding the connection edge. It can also be seen that, since the filtering of the connection edge has been performed while expanding the connection edge, the operator (e.g., the Filter operator) for filtering the path is removed in the execution plan of the present embodiment, and the path obtained after expanding the connection edge already satisfies the path constraint.

[0085] It should be noted that, in the embodiments of the present disclosure, in order to make the description simple, the indefinite hop graph query statement with the hop range [1, 3] and the single path constraint (ascending order) is taken as an example to describe one or more embodiments, but it should be understood that, in specific practice, according to the data query and processing requirements, the graph query statement usually has extremely complex path constraints and more extensive hop ranges. In addition, some common operators (e.g., Projection, VarLengthExpand, etc.) are used as examples in the description of the execution plan, but it should be understood that these operators are only used as examples to describe the embodiment method and are not limited. In actual application scenarios, different graph query engines can generate execution plans including other operators according to different graph query statements. The one or more embodiments of the present disclosure are intended to provide an optimization execution method for indefinite hop graph queries containing path constraints, and are not limited to specific graph query statement structures or specific operator combinations. The method provided by the present embodiment can be applied to any scenario related to the technical concept provided by the present embodiment.

[0086] The method flow shown in the figure will be described in detail below. Figure 5 The method flow shown in the figure will be described in detail below. Figure 4 The method flow shown in the figure will be described in detail below.

[0087] Step S401: receiving a graph query statement, the graph query statement containing a hop range of an indefinite hop path and a path constraint on a connection edge.

[0088] Specifically, in the present embodiment, the graph query statement corresponding to the figure is received. Figure 2(acc:Account {id: 10})-[e1:transfer*1..3]->(other:Account) where isAsc(getMemberProp(e1, 'timestamp')) = true.

[0089] Next, in step S403, the target execution plan generated for the graph query statement is executed, which includes filtering candidate connecting edges according to the path constraint when extending connecting edges of the first path, where the number of hops of the first path belongs to the hop range after extension.

[0090] In this embodiment, the target execution plan corresponds to Figure 5 As shown in the figure. In the process of executing the target execution plan, first, the node matching the definition of the starting node in the graph query statement is determined as the starting node of executing the graph query in the attribute graph according to the definition of the starting node in the graph query statement, which corresponds to the execution step of the node search operator NodeUniqueIndexSeek in the execution plan.

[0091] In one scenario of this embodiment, the connecting edge defined in the graph query statement can 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) where isAsc(getMemberProp(e1, 'timestamp')) = true.

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

[0094] In another scenario of this embodiment, the connecting edge contained in the graph query statement can 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) where isAsc(getMemberProp(e1, 'timestamp')) = true.

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

[0097] In yet another scenario of this embodiment, the connecting edge contained in the graph query statement can also be a non-directional edge, that is, the writing paradigm of the graph query statement is "node-non-directional 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, and the node search operator is executed to select the nodes of the type account other from the property graph and take the union of the account type nodes acc with the attribute id = 10 as the starting nodes.

[0100] It should be noted that in the introduction of each embodiment of the present specification, the graph query statement with the connecting edge as the outgoing edge is taken as an example for illustration, and the technical idea involved therein can be equally applied to the execution of other graph query statements containing directed / undirected connecting edges.

[0101] After determining the starting nodes, the graph query engine will start from the starting nodes, expand the first path along each candidate connecting edge in the property graph according to the definition of the connecting edge in the graph query statement and in combination with the path constraint.

[0102] The candidate connecting edge refers to each connecting edge with the direction defined by the graph query statement connected at the node pointed to by the currently processed connecting edge. In the property graph, the node pointed to by the currently processed connecting edge can be directly reached by another node through each candidate connecting edge. Figure 6A An exemplary candidate connecting edge diagram is shown in the figure, in which the node pointed to by the currently processed connecting edge is node A, and there are three outgoing edges <A, B>, <A, C> and <A, D> at node A, which are the candidate connecting edges.

[0103] The first path expansion connecting edge refers to adding any selected candidate connecting edge to the first path and taking the candidate connecting edge as the currently processed connecting edge to carry out the next round of connecting edge expansion. With the gradual advancement of this process, the first path will continue to extend until the constraint (i.e., the hop range) on the number of hops in the graph query statement is met. In the present embodiment, the operation of expanding the connecting edge of the first path corresponds to the execution of the edge expansion operator VarLengthExpand in the execution plan.

[0104] It can be seen that there can be multiple candidate connection edges for selection at each time of performing the extended connection edge operation, and selecting different candidate connection edges as the extended connection edge means that the first path will extend in different directions, that is, the selection of the candidate connection edge determines the subsequent extension direction of the first path. It can be seen that if the selected candidate connection edge in the process of extending the connection edge at a certain time causes the first path to violate the path constraint in the graph query statement, all subsequent extended connection edge operations will become invalid, because the first path no longer meets the path constraint, thus destined to be unable to generate a valid query result.

[0105] In the embodiment, the selected candidate connection edge is filtered at the same time as the operation of extending the connection edge of the first path, which can ensure that each time of extending the connection edge operation does not cause the first path to violate the path constraint. In other words, this step can filter out the candidate connection edge that causes the first path to violate the path constraint in real time, and prevent the first path from continuing to extend in these directions.

[0106] Figure 6B An exemplary extended connection edge operation diagram is provided. In the example corresponding graph query statement, the value of the attribute v on the path connection edge is arranged in ascending order as the path constraint. Referring to the drawings, when the current processing connection edge is extended, among the 3 candidate connection edges on node A, the addition of <A, C> and <A, D> will cause the first path to violate the path constraint, so these two edges will not be selected as the extended connection edge, and the addition of the connection edge <A, B> meets the path constraint, and the attribute v on each connection edge of the first path still maintains the ascending order, so the connection edge can be selected as the extended connection edge and added to the first path.

[0107] In the above-described embodiment including the extended connection edge operation, 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 connection edge based on L1, if L1 cannot meet the path constraint P, then L2 cannot meet the path constraint P. Therefore, in the process of executing the graph query statement with the early termination property, when the candidate connection edge causes the first path to be unable to meet the path constraint, any path obtained by continuing to extend based on the candidate connection edge will not meet the path constraint, so in the above-described embodiment, the search along the candidate connection edge can be stopped in advance when an invalid candidate connection edge is encountered.

[0108] According to an implementation, the path constraint can be a constraint imposed on the relationship between each connection edge in the indefinite jump path. For example, in a query of a social relationship attribute graph, if an indirectly acquainted user is to be found, a constraint related to acquaintance time needs to be imposed on the connection edges at each odd or even connection depth. That is, the path constraint includes a second constraint imposed on the relationship between second data of each connection edge in the indefinite jump path, the second data including a label, an attribute, or a timestamp. When filtering the candidate connection edge, 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 whether the candidate connection edge is an extended connection edge is determined according to the comparison result.

[0109] In the implementation described above, when the second attribute is a certain attribute or a timestamp that can be compared numerically, the second constraint can be defined as a numerical continuity constraint of the second attribute of each connection edge in the path, for example, ascending order, descending order, fixed interval, and the like. At this time, the filtering of the candidate connection edge can be converted into a comparison of the candidate connection edge and its 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 whether the candidate connection edge is an extended connection edge is determined according to the comparison result, including: 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 whether the candidate connection edge is an extended connection edge is determined according to the comparison result, including: 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 can be a constraint imposed on a certain specific connection edge in the indefinite jump path. For example, in a query of a fund transaction attribute graph, if a transaction chain triggered by a certain specific transaction is to be found, a constraint needs to be imposed on the specific connection edge corresponding to the specific transaction, which is the first connection edge of the indefinite jump path. Similarly, if a transaction chain ending at a certain specific transaction is to be found, the specific connection edge is the last connection edge of the indefinite jump path. In some scenarios, the specific connection edge can be the first connection edge, the last connection edge, or a certain intermediate connection edge of the indefinite jump path. When the connection edge is extended, if the connection edge to be extended is the specific connection edge, the connection edge needs to be filtered according to the path constraint.

[0112] In one example, the path constraint includes a first constraint on first data of a specific connection edge in the indefinite jump path, the first data including: a label, an attribute, or a timestamp; and the filtering of the candidate connection edge according to the path constraint includes: if the connection edge to be expanded is the specific connection edge, determining whether the candidate connection edge is the expanded connection edge according to whether the first data of the candidate connection edge satisfies the first constraint.

[0113] The above is an elaboration of the method of filtering the candidate connection edge in the path expansion process. By continuously performing the edge expansion operation including the connection edge filtering, it can be ensured that the first path always satisfies the path constraint. When the number of connection edges contained in the first path satisfies the jump range, the first path is recorded in the result set of the graph query statement.

[0114] In practice, this complete execution method of the graph query statement including the edge filtering operation can be implemented by various algorithms, for example: implementing the depth-first search or the breadth-first search of the attribute graph in a recursive or non-recursive manner, and adding the filtering operation of the connection edge in the search process at each step.

[0115] In one specific example, the non-recursive depth-first search can be used to implement the expansion of the connection edge of the first path. Figure 7 The pseudo code for implementing the expansion of the connection edge in this example is shown. The non-recursive depth-first search needs to use a stack to temporarily store the intermediate results. In the implementation of this code, stackDFS is the target stack in which the current first path is stored. Since the maximum number of jumps of the first path is the upper limit of the jump range defined in the graph query statement, the depth of the target stack can be set to the upper limit of the jump range. nextEdge is the candidate connection edge, check predicate is the filtering check based on the path constraint. currentLength is the number of jumps of the current first path in the target stack. max_hop and min_hop are the upper limit and the lower limit of the jump range, respectively. resultArray saves the result set of the graph query statement.

[0116] Overall, the code implementation of this paragraph, first in the attribute graph, according to the graph query statement to determine the starting node, in the starting node, select any one of the connection edge to meet the path constraint, as the first path of the first connection edge, into the target stack, complete the initialization of the target stack (corresponding to the pseudo code in the first line). Start iteration processing (pseudo code 2-21 line), each iteration is based on the first path last connection edge (i.e. the top element of the target stack) to expand the connection edge. Specifically, in a single iteration round, read the top element as the current search connection edge (pseudo code in the third line). Determine whether the number of hops of the current first path in the target stack has reached the upper bound of the hop range, if so, directly into the result set of the current first path, and the top element of the stack is de-stacked (pseudo code in the fourth to eighth line), because the first path has reached the upper limit of the number of hops, there is no possibility to continue to search back, can be back one step along the last connection edge to continue to expand. If the current first path has not reached the upper bound of the hop range, start to expand the connection edge and filter the candidate connection edge. Specifically, if there is a valid and path constraint compliant connection edge in the candidate connection edge, the connection edge can be used as an expansion connection edge, which is pushed into the target stack, indicating that the first path extends one hop along the expansion connection edge, and the subsequent steps will continue to search along the expansion connection edge (pseudo code in the ninth to thirteenth line). If there is no valid connection edge in the candidate connection edge, or there is no connection edge that meets the path constraint, it means that there is no meaning to continue to search back along the current processing connection edge, so the top element of the stack can be de-stacked, and the first path is back one step (pseudo code in the fifteenth line). De-stacking will cause the number of hops of the current first path in the target stack to change, so when the de-stacking operation occurs, the number of hops of the current first path can be checked to see if it is not less than the lower bound of the hop range, and if it meets the lower bound constraint, the current first path can be included in the result set (pseudo code 14-20 line). The above is an explanation of one of the expansion connection edge operations of the non-recursive depth first search. The above steps are executed continuously 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, and the above iteration processing is started. 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 example pseudo code, which can also be summarized as: each connection edge of the first path is saved in the target stack in turn. The depth of the target stack is the upper bound of the hop 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 that satisfies the path constraint on the starting node is pushed into the target stack. The filtering of the candidate connection edge includes: obtaining the stack top element of the target stack, and taking the node pointed to by the connection edge corresponding to the stack top element as an expansion node. A plurality of connection edges of the expansion node are taken as candidate connection edges, and any connection edge that satisfies the path constraint is selected from the candidate connection edges and pushed into the target stack; or, if the candidate connection edge does not contain a connection edge that satisfies the path constraint, the stack top element is popped out of the target stack.

[0118] In some embodiments of the present specification, a method for extending the constraint conditions of a graph query language is also provided to enhance the syntax expression ability and graph query execution ability of the graph query language, thereby widening the application range 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 connection edge. Correspondingly, a first keyword can be added to indicate a termination condition for path expansion during the execution of a graph query statement, and the search is stopped when an element that satisfies the termination condition is found. The definition of the termination condition can be placed after the first keyword to extend 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 a connection edge, and 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 (for example, [1..3] in an indefinite hop query) of the graph query statement, or inserted into other positions in the graph query statement without destroying the syntax of the query keyword, which is not specifically limited in the present specification.

[0120] In one embodiment, the graph query statement can further comprise a first keyword, which is used to define a first termination condition of path expansion. For example, the first keyword is UNTIL, and a termination condition is given after the first keyword, which means that when the edge expansion operator expands a first path to a connection edge, if the connection edge or the destination node pointed by the connection edge satisfies the termination condition, the search / connection edge expansion of the connection edge is stopped. In one example, the condition UNTIL b.type=people is placed after the upper bound of the hop range in the graph query statement, which means that when a node (b) or a connection edge (b) with the type attribute of people is found, the current search is stopped. That is, in the process of executing the graph query with the first keyword, the filtering of the candidate connection edge further comprises: for any candidate connection edge satisfying the path constraint, performing a target determination of the candidate connection edge based on the first termination condition, and determining whether the candidate connection edge is an expanded connection edge according to the determination result. The first termination condition can be a constraint on the connection edge or a constraint on the node.

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

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

[0123] In addition, in some graph query languages (for example, GQL), there is also a lack of support for setting filtering conditions at the level of repeated elements. For example, in an indefinite hop query, a continuity constraint on a certain attribute of a connection edge. Correspondingly, a first function can be added to construct a check window, which is placed on the path obtained by searching in the process of executing the graph query statement, and the connection edges covered by the window are checked based on the filtering condition. It should be noted that according to the first function, the check window can be constructed as a window with the same length as the target query path for one-time filtering check; or according to the definition given in the graph query statement, it can be constructed as a window with a preset width, which is used to check the segmented path obtained by searching in the process of executing the graph query statement, or is slid on the path to realize the check of the whole path. The first function can be placed after the MATCH clause and before the RETURN clause of the graph query statement, or can be inserted into other positions in the graph query statement without destroying the syntax of the query keyword, which is not limited in the present specification.

[0124] In another embodiment, the graph query statement can further include a first function for defining a first window. The extended filter operator described above can be implemented as a window filter operator. In a specific example, the first function is named as sw, and the graph query statement including the first function can be shown as WITH sw on p as pp, which means a first window pp is constructed on the path p (the width of the first window can be a preset default value, or a unit length 1, or any value defined by a user in the graph query statement, which is not limited here). The window filter operator is executed, and the first window starts from the start node of the first path, and filters the nodes and connection edges enclosed in the first window based on the path constraint. As the first path is continuously expanded, the first window slides along the path expansion direction on the first path in sequence, and the window filter operator is executed until the end node / last connection edge of the first path is enclosed in the first window. That is, in this embodiment, the filtering of the candidate connection edges according to the path constraint includes: filtering the candidate connection edges covered by the first window according to the path constraint by executing the window filter operator.

[0125] In an implementation of the above embodiment, the first window can have a first width. For example, the paradigm of the first function can be defined as sw(length) for constructing the first window, and the window width length can be defined by a user in the graph query statement. For example, sw(2) means that the width of the first window is 2, which can enclose a path with a length of 2 (including 3 nodes and 2 connection edges). That is, in this implementation, the filtering of the candidate connection edges covered by the first window includes: connecting the candidate connection edges to be filtered to the first path to obtain a temporarily expanded path. The temporarily expanded path is window detected to determine whether the candidate connection edges are extended connection edges; the window detection includes placing the first window at the tail of the temporarily expanded path, and detecting the path segment in the first window based on the path constraint.

[0126] Based on the above implementation, in a specific scenario, the first window further 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 the 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), and the step length is 1. Then, in each connection edge expansion, the window filtering operator needs to be executed to take out the last two segments of the current first path to determine whether the path constraint is met. In another example, the first window is defined as sw(3, 2), and the step length is 2. Then, the window filtering operator can be executed when the hop number of the current first path reaches a multiple of the step length (the first path contains 2, 4, 6, … connection edges), to take out the last three segments of the current first path to determine whether the path constraint is met. That is, in this scenario, the window detection on the temporary expanded path includes: when the number of connection edges contained in the temporary expanded path is a multiple of the first step length, performing the window detection on the temporary expanded path.

[0127] The above is an introduction to the main flow of the method for optimizing the execution of a graph query provided by the embodiments of the present specification. Although the method flow is described above mainly by taking the graph query statement of the GQL standard and the corresponding graph query engine as an example, the technical concept embodied therein can also be applied to the execution process of related graph query statements by other graph query engines.

[0128] By using the above method provided by the embodiments of the present specification, in the process of executing a graph query, the path constraint-based check can be performed in real time when expanding the connection edge according to the path constraint in the statement, dynamic path screening and pruning are realized, the number of paths that do not meet the graph query condition is significantly reduced, and the execution efficiency of the graph query is improved.

[0129] In the present specification, “first” in the words of first path, first data, etc., and the corresponding “second”, “third” (if any) in the text only serve to distinguish and describe for convenience, and do not have any limiting meaning.

[0130] The above describes specific embodiments of the present specification, and other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims can be performed in an order different from that in the embodiments, and the desired results can still be achieved. In addition, the processes depicted in the drawings do not necessarily have to be implemented in the specific order or continuous order shown to achieve the desired results. In some embodiments, multi-task processing and parallel processing are possible or can be advantageous.

[0131] Figure 8Fig. 8 is a schematic diagram of an apparatus for optimizing execution of a graph query according to an embodiment of the present specification. The apparatus 800 is deployed in a computing device, which can be implemented by any apparatus, device, platform, cluster of devices, etc. having computing and processing capabilities. The apparatus embodiment corresponds to the method embodiment shown in Fig. 7. Figure 4 The apparatus 800 comprises:

[0132] a receiving module configured to receive a graph query statement, the graph query statement comprising a range of hop counts of indefinite hop paths and a path constraint on connecting edges.

[0133] a filtering module configured to execute a target execution plan generated for the graph query statement, wherein the filtering module is configured to filter candidate connecting edges according to the path constraint when extending connecting edges of a first path, wherein the hop count of the first path belongs to the range of hop counts after extension.

[0134] According to another aspect, the present specification also provides a computer program product comprising computer programs / instructions, which, when executed by a processor, implement the steps of the method described above in conjunction with Figure 4 the method.

[0135] According to yet another aspect, the present specification also provides a computing device comprising a memory and a processor, wherein the memory stores executable codes, and the processor executes the executable codes to implement the steps of the method described above in conjunction with Figure 4 the method.

[0136] Those skilled in the art should be aware that the functions described in the above one or more examples can be implemented in hardware, software, firmware, or any combination thereof. When implemented in software, the 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 above detailed description sets forth the purposes, technical solutions, and beneficial effects of the embodiments of the present specification. It should be understood that the above description is merely a specific implementation of the embodiments of the present specification and is not intended to limit the protection scope of the present specification. Any modifications, equivalent replacements, improvements, etc. made on the basis of the technical solutions of the present specification shall be included in the protection scope of the present specification.

Claims

1. A method for optimizing execution of a graph query, executed by a graph query engine, comprising: receiving a graph query statement written in a target graph query language, the graph query statement containing a hop range of an indefinite hop path and a path constraint imposed on edge data of a connecting edge, the edge data comprising: a label, an attribute, or a timestamp; the hop range being used to limit the number of connecting edges contained in the indefinite hop path; executing a target execution plan generated for the graph query statement, wherein includes, when expanding a first path with a connecting edge, filtering candidate connecting edges according to the path constraint, and adding a candidate connecting edge satisfying the path constraint to the first path, wherein the hop number of the first path belongs to the hop range after expansion.

2. The method of claim 1, wherein, the target execution plan comprises a combined operator executed iteratively, the combined operator comprising an edge expansion operator for searching a path satisfying the hop range, and an expansion filter operator for filtering a connecting edge based on the path constraint; the filtering a candidate connecting edge according to the path constraint comprises: filtering a candidate connecting edge according to the path constraint by executing the combined operator.

3. The method of claim 1, wherein, the connecting edge is an outgoing edge.

4. The method of claim 1, wherein, the path constraint comprises a first constraint on first edge data of a specific connecting edge in the indefinite hop path; the filtering a candidate connecting edge according to the path constraint comprises: if the connecting edge to be expanded is the specific connecting edge, determining whether the candidate connecting edge is an expanded connecting edge according to whether the first edge data of the candidate connecting edge satisfies the first constraint.

5. The method of claim 4, wherein, the specific connecting edge is at least one of: a first connecting edge, a last connecting edge.

6. The method of claim 1, wherein, the path constraint comprises a second constraint imposed on a relationship between second edge data of each connecting edge in the indefinite hop path; the filtering a candidate connecting edge according to the path constraint comprises: comparing the second edge data of any candidate connecting edge with the second edge data of a target connecting edge in the first path based on the second constraint, and determining whether the candidate connecting edge is an expanded connecting edge according to a comparison result.

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

8. The method of claim 1, wherein, each connecting edge of the first path is saved in a target stack in turn; a depth of the target stack is an upper bound of the hop range; the filtering a candidate connecting edge comprises: obtaining a stack head element of the target stack, and taking a node pointed to by a connecting edge corresponding to the stack head element as an expanded node; the extension node are taken as candidate connection edges, and any connection edge satisfying the path constraint is selected from the candidate connection edges and pushed into the target stack; or if the candidate connection edges do not include a connection edge satisfying the path constraint, the first element of the stack is popped from the target stack.

9. The method of claim 8, wherein the filtering of the candidate connection edges further comprises: when the target stack is empty, determining a starting node of a first path according to the graph query statement, and pushing any connection edge satisfying the path constraint on the starting node into the target stack.

10. The method of claim 1, wherein, the graph query statement further comprises a first keyword, and the first keyword is used to define a first termination condition of path expansion; the filtering of the candidate connection edges further comprises: for any candidate connection edge satisfying the path constraint, performing target determination of the candidate connection edge based on the first termination condition, and determining whether the candidate connection edge is taken as an extension connection edge according to a determination result.

11. The method of claim 10, wherein, the first termination condition comprises a third constraint on a connection edge, and the target determination comprises: determining the candidate connection edge according to the third constraint.

12. The method of claim 10, wherein, the first termination condition comprises a fourth constraint on a node, and the target determination comprises: determining a node pointed to by the candidate connection edge according to the fourth constraint.

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

14. The method of claim 13, wherein, the first window has a first width; the filtering of the candidate connection edges covered by the first window comprises: connecting a plurality of candidate connection edges to be filtered to the first path to obtain a temporary extension path; performing window detection on the temporary extension path to determine whether the plurality of candidate connection edges are taken as extension connection edges; and the window detection comprises placing the first window at a tail of the temporary extension path and detecting a path segment in the first window based on the path constraint.

15. The method of claim 14, wherein, the first window further has a first step size; and the window detection on the temporary extension path comprises: when a number of connection edges included in the temporary extension path is a multiple of the first step size, performing the window detection on the temporary extension path.

16. An apparatus for optimizing execution of a graph query, the apparatus comprising: a receiving module configured to receive a graph query statement written in a target graph query language, the graph query statement comprising a hop number range of an indefinite hop path and a path constraint imposed on edge data of a connection edge, the edge data comprising a label, an attribute, or a timestamp, and the hop number range being used to limit a number of connection edges included in the indefinite hop path; and a processing module configured to process the graph query statement according to the target graph query language. The filtering module is configured to execute a target execution plan generated for the graph query statement, wherein the target execution plan comprises, when expanding a first path to connect edges, filtering candidate connecting edges according to the path constraint, and adding the candidate connecting edges satisfying the path constraint to the first path, wherein the number of hops of the first path belongs to the hop range after expansion. 17.A computer program product comprising computer programs / instructions which, when executed by a processor, implement the steps of the method of any one of claims 1-15.

18. A computing device comprising a memory and a processor, wherein: The memory stores executable code, and the processor executes the executable code to implement the method of any one of claims 1-15.

Images