A query method and device for graph data, a storage medium and an electronic device
By storing common query results as materialized views in the graph database instance, the graph data query process is optimized, solving the problem of slow graph data query speed and achieving more efficient query speed.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- UNIV OF SCI & TECH OF CHINA
- Filing Date
- 2025-12-29
- Publication Date
- 2026-05-26
AI Technical Summary
How to improve the speed of graph data queries, especially the efficiency of operations such as point queries, edge queries, and first-degree or n-degree queries of points and edges, and path queries in graph database instances.
By identifying common queries for each query load in the graph database instance, storing the results of these common queries as materialized views, and optimizing the query process using the pre-stored materialized views when a query statement to be executed is received, the actual query operations on the graph database instance are reduced.
It effectively improves the speed of graph data query, reduces the actual query operations on the graph database instance, and improves query efficiency.
Smart Images

Figure CN122087162A_ABST
Abstract
Description
Technical Field
[0001] This specification relates to the field of computer technology, and in particular to a method, apparatus, storage medium, and electronic device for querying graph data. Background Technology
[0002] With the development of the times, graph data has been widely used in various fields.
[0003] Graph data is data organized into a graph structure consisting of nodes and edges. Generally, nodes represent objects, and the data corresponding to a node is the object's attribute. However, graph data, in addition to containing object attributes, focuses more on recording the relationships between different objects in the form of edges. The data corresponding to each edge is the attribute of the relationship between different objects. For example, if nodes represent users and edges represent the relationships between users, then attributes such as a user's name are the attribute data of the node corresponding to that user, while relationships such as friends and relatives between users are the attribute data of the edges between different nodes.
[0004] Graph data allows for point queries, edge queries, and queries involving first-degree or n-degree relationships between points and edges, as well as path queries. Improving the query speed of graph data is a pressing issue that needs to be addressed. Summary of the Invention
[0005] This specification provides a method, apparatus, storage medium, and electronic device for querying graph data, in order to partially solve the problems existing in the prior art.
[0006] The embodiments in this specification adopt the following technical solutions: This specification provides a method for querying graph data, the method comprising: Obtain the query load for each graph data query performed in the graph database instance; Determine the common query for each query load, which is the query to be performed when querying the graph database instance using each query load; The results obtained from the public query in the graph database instance are determined and stored as a materialized view of the graph database instance. When the query statement to be executed contains the common query, the query result obtained by executing the query in the graph database instance using the stored materialized view is determined.
[0007] This specification provides a graph data query device, the device comprising: The acquisition module is used to acquire the query load of each graph data query performed in the graph database instance; A determination module is used to determine the common query for each query load, which is the query to be performed when querying the graph database instance using each query load; A module is created to determine the results obtained by using the public query in the graph database instance, and to store them as a materialized view of the graph database instance. The query module is used to determine the query result obtained by executing the query in the graph database instance using the query to be executed when the query statement to be executed contains the public query, based on the stored materialized view.
[0008] This specification provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described method for querying graph data.
[0009] This specification provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the program, it implements the above-mentioned method for querying graph data.
[0010] This specification provides a computer program product, which includes a computer program that, when executed by a processor, implements the above-mentioned method for querying graph data.
[0011] The above-described at least one technical solution adopted in the embodiments of this specification can achieve the following beneficial effects: This specification discloses a method for querying graph data. The method identifies a common query across various query loads, performs a query using this common query in a graph database instance, and stores the results as a materialized view of the graph database instance. When a query statement to be executed is received, if the query statement contains the common query, the query result obtained by executing the query using the query statement in the graph database instance is determined based on the stored materialized view. Through this method, when querying using a query statement to be executed, at least a portion of the query results can be determined based on the pre-stored materialized view, without needing to fully execute the query process corresponding to the query statement on the graph database instance, thus effectively improving query speed. Attached Figure Description
[0012] The accompanying drawings, which are included to provide a further understanding of this specification and form part of this specification, illustrate exemplary embodiments and are used to explain this specification, but do not constitute an undue limitation thereof. In the drawings: Figure 1 This is a flowchart of the graph data query method provided in the embodiments of this specification; Figure 2This is a schematic diagram illustrating query optimization based on a stored materialized view of a query pattern diagram of a query statement to be executed, provided as an embodiment of this specification. Figure 3 This is a schematic diagram of a graph data query device provided in an embodiment of this specification; Figure 4 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this specification. Detailed Implementation
[0013] To make the objectives, technical solutions, and advantages of this specification clearer, the technical solutions of this specification will be clearly and completely described below in conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this specification, and not all of them. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this specification.
[0014] The technical solutions provided in the various embodiments of this specification are described in detail below with reference to the accompanying drawings.
[0015] Figure 1 The flowchart of the graph data query method provided in the embodiments of this specification specifically includes the following steps: S100: Get the query loads for each graph data query performed in the graph database instance.
[0016] In the embodiments described in this specification, the following are employed: Figure 1 The device used to query graph data using the method described can be any device hosting the graph database system, such as a personal computer, mobile phone, tablet computer, server, or server cluster consisting of multiple servers. This specification does not impose any restrictions on this. The following explanation uses a server as an example only.
[0017] In the embodiments of this specification, the graph data pre-stored in the graph database system is called a graph database instance, and the graph database instance contains all the graph data of a graph structure. Furthermore, in the embodiments of this specification, even if all the graph data of the same graph structure are stored in different graph database systems, all the graph data of the same graph structure stored in these different graph database systems can be regarded as the same graph database instance, and thus, methods such as... Figure 1 The method shown stores materialized views and queries graph data for the graph database instance.
[0018] Before the server receives and executes a query statement, it can first obtain the query loads of the graph database instance. The query loads are query statements used to perform graph data queries on the graph database instance. These query statements may include those that have been executed on the graph database instance historically based on actual user query needs, or they may include query statements generated for other purposes (such as testing the performance of the graph database system) that require execution on the graph database instance. This specification does not limit the method or source of query load generation. Those skilled in the art should understand that while query loads are not generated based on current user query needs, they are still query statements capable of being executed on the graph database instance. Any query statement that meets this condition can be used as a query load.
[0019] Furthermore, the terms "comprising," "including," or any other variations thereof used in this specification are intended to cover a non-exclusive inclusion, such that a process, method, product, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, product, or apparatus. Without further limitations, the presence of other identical or equivalent elements in a process, method, product, or apparatus that includes said elements is not excluded. Moreover, the terms "a," "an," and "the" used in this specification are not specifically singular but may include plural forms.
[0020] S101: Determine the common query for each query load, which is the query to be performed when querying the graph database instance using each query load.
[0021] After the server obtains the query load of each query load of the graph database instance, it can determine the common query of each query load.
[0022] The common query described in the embodiments of this specification refers to a query that must be performed by more than a preset number of query loads when querying the graph database instance using various query loads. Alternatively, the common query is the query whose sub-results are included in the query results obtained by querying the graph database instance using various query loads, exceeding the preset number of query loads.
[0023] For example, suppose one query load wants to query all paths from node A to node B, and then all paths from node B to node C, while another query load wants to query all paths from node A to node B, and then all paths from node B to node D. When the above preset number is 2, the all paths from node A to node B in these two query loads are the common query.
[0024] S102: Determine the result obtained by using the public query in the graph database instance, and store it as a materialized view of the graph database instance.
[0025] After determining the common query for each query load in step S101, the common query can be used to perform a query in the graph database instance to obtain the query result, which is then stored as a materialized view of the graph database instance. Since the common query for each query load represents frequently performed queries on the graph database instance, storing the query result corresponding to the common query as a materialized view can optimize subsequent queries and improve query efficiency.
[0026] When storing materialized views, the query statement corresponding to the common query or the query pattern diagram corresponding to the common query can be stored as the label of the materialized view. Since the materialized view is the query result of the common query on the graph database instance mentioned above, the materialized view is equivalent to a subgraph contained in the graph structure corresponding to the graph database instance, and it is also composed of vertices and edges.
[0027] When the common query determined in step S101 is a path query, the materialized view stored in this embodiment of the specification includes at least one starting node (such as node A in the example above), one ending node (such as node B in the example above), all paths from the starting node to the ending node in the graph structure corresponding to the graph database instance, and the constraints on these paths in the common query (that is, the query conditions corresponding to these paths in the common query). If the common query queries more than one starting node and / or ending node, the common query can be split into several sub-common queries that only query one path from a starting node to an ending node, and the materialized view corresponding to each sub-common query can be stored using the above method.
[0028] However, if the common query is a query other than a path query, such as a point query, edge query, or point-edge one-degree or n-degree query, then the corresponding materialized view stored is not limited to a start node and an end node, and the query result of the common query can be directly stored as a materialized view. For ease of explanation, the following only uses a path query as an example of the common query.
[0029] When the public query is a path query, the path from the starting node to the ending node in the materialized view stored above in this specification includes an n-hop path from the starting node to the ending node, where n is an integer not less than 1. That is, the path length from the starting node to the ending node is variable. For example, in the example above, the path from node A to node B can be either a path formed by the edges directly connecting node A and node B, or a two-hop path formed by node A first going to node i, and then from node i to node B. When the size of n is not limited, the path from the starting node to the ending node is a variable-length path with no upper limit.
[0030] S103: When the query statement to be executed contains the common query, the query result obtained by executing the query in the graph database instance using the stored materialized view is determined.
[0031] After storing the materialized view using steps S100-S102, when the server receives a query statement to be executed, it can determine whether the query statement contains the aforementioned common query. In this specification, unless explicitly stated otherwise, "receiving and sending data" does not necessarily mean direct receiving and sending; it can be indirect receiving and sending. For example, A receiving data sent by B can be understood as A directly receiving data sent by B, or it can be understood as A indirectly receiving data sent by B through other entities such as C. Similarly, B sending data to A can be understood as B directly sending data to A, or it can be understood as B indirectly sending data to A through other entities such as C. Here, C can be one entity, or it can be two or more entities.
[0032] Specifically, when a query statement corresponding to a common query is used as the label for a stored materialized view, the server can perform syntax analysis on the query statement to be executed and determine whether it contains the query statement corresponding to the common query based on the analysis results. When a query pattern diagram corresponding to a common query is used as the label for a stored materialized view, the server can determine the query pattern diagram corresponding to the query statement to be executed and determine whether it contains the query pattern diagram corresponding to the common query.
[0033] When it is determined that the query statement to be executed contains a common query, the query result of the query statement to be executed can be determined based on the materialized view corresponding to the stored common query.
[0034] Let's take a query schema diagram as an example. Continuing with the previous example, after the server stores all paths from node A to node B as a materialized view, when it receives a query statement to be executed, assuming the schema diagram of the query statement to be executed is as follows... Figure 2 As shown.
[0035] Figure 2 This is a schematic diagram illustrating query optimization using a stored materialized view based on a query pattern diagram of the query statement to be executed, provided as an embodiment of this specification. Figure 2 In this context, the server can determine that the query pattern diagram of the query statement to be executed is to first query all paths from node A to node B, and then query all paths from node E to node B. Based on this query pattern diagram, the server can determine that the query pattern diagram contains the query pattern diagram corresponding to the stored common query from node A to node B. Therefore, the materialized view corresponding to the common query can be used to optimize the query statement to be executed.
[0036] Specifically, the server can mark the query pattern diagrams corresponding to common queries contained in the query pattern diagram of the query statement to be executed. Then, in the graph database instance, it executes the queries corresponding to the unmarked parts of the query pattern diagram corresponding to the query statement to be executed, obtains the query results, and finally uses the query results obtained from executing the unmarked parts and the materialized views corresponding to the marked common queries to obtain the final query result of the query statement to be executed. Figure 2 As shown, the server can first mark the portion of all paths from node A to node B contained in the query pattern graph corresponding to the query statement to be executed (such as...). Figure 2 (As shown in the dashed box), then execute the query corresponding to the unmarked part in the graph database instance, that is, query all paths from node E to node B in the graph database instance. Finally, use the materialized views corresponding to all paths from node A to node B and the queried all paths from node E to node B to obtain the final query result of the query statement to be executed.
[0037] By using the methods described above, the amount of graph data that is actually queried on the graph database instance can be reduced, thereby speeding up graph data queries.
[0038] Furthermore, the graph database instances stored in a graph database system are not static; they may change, such as by adding or removing nodes and edges. Therefore, the stored materialized views also need to be updated accordingly. Thus, the server can update the stored materialized views based on the updated graph database instance. The following explanation will still use a path query as an example of a common query corresponding to the stored materialized views.
[0039] Updates to a graph database instance primarily include four types: creating new nodes, deleting existing nodes, creating new edges, and deleting existing edges. When creating a new node, an edge is typically created connecting it to the new node; one end of the edge connects to an existing node. Conversely, deleting an existing node removes the existing node and all edges connected to it. Creating a new edge connects two existing nodes, while deleting an existing edge removes the existing edge between two existing nodes.
[0040] When updating a graph database instance involves creating a new node and edges connected to it, the server can determine, based on the updated graph database instance, whether a path exists from the start node to the end node of the materialized view that passes through the new node and satisfies a query condition. This query condition is the condition used by the stored common query for the materialized view to find paths from the start node to the end node. If a path exists, it is added to the stored materialized view to find the path from the start node to the end node that passes through the new node and satisfies the query condition. If no path exists, the stored materialized view remains unchanged.
[0041] When an update to a graph database instance involves deleting an existing node and the edges connected to that existing node, the server can determine whether the existing node is at least one of the start and end nodes in a stored materialized view. If so, the materialized view can be deleted directly; otherwise, the path in the materialized view containing the existing node can be deleted directly.
[0042] When updating a graph database instance to create a new edge in the graph database instance, the server can determine, based on the updated graph database instance, whether there exists a path from the start node to the end node of the stored materialized view that results in the new edge and satisfies the above query conditions. If it exists, a path from the start node to the end node that passes through the new edge and satisfies the above query conditions is added to the materialized view. If it does not exist, the materialized view can remain unchanged.
[0043] When an update to a graph database instance is to delete an existing edge within the graph database instance, the server can directly delete the path containing that existing edge in the materialized view.
[0044] Furthermore, to facilitate updates to materialized views under the four update types mentioned above, the server adopts... Figure 1After storing the materialized view in step S102, maintenance statement templates corresponding to the four different update types for updating the graph database instance can be generated. After the graph database instance is updated, the server can select the maintenance statement template corresponding to the current update type as the target template. Then, based on the changed points and / or edges in the updated graph database instance and the target template, a maintenance statement for updating the materialized view is generated. Finally, the maintenance statement is executed to update the stored materialized view. When the maintenance statements generated from the maintenance statement templates for the four different update types are executed, they are used to update the stored materialized view using the methods described above for updating the materialized view according to the four different update types.
[0045] The above example illustrates the case where the common query corresponding to the stored materialized view is a path query. When the common query is not a path query, the server can directly re-execute the query statement corresponding to the common query based on the updated graph database instance, and store the obtained query result as the materialized view corresponding to the common query.
[0046] It should be noted that specific terms are used in this specification to describe the embodiments thereof. For example, "an embodiment," "one embodiment," and / or "some embodiments" refer to a particular feature, structure, or characteristic related to at least one embodiment of this specification. Therefore, it should be emphasized and noted that "an embodiment," "one embodiment," or "an alternative embodiment" mentioned twice or more in different locations in this specification do not necessarily refer to the same embodiment. Furthermore, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples, without contradiction. Moreover, although one or more embodiments of this specification provide method steps as described in the embodiments or flowcharts, it is understood that the order of steps listed in the embodiments or flowcharts is merely one possible execution order among many steps, and does not represent the only execution order. Therefore, when the claims involve method steps, adjustments to the order of such steps, or parallel execution between steps, are also within the scope of protection of the claims.
[0047] The above is an example of a method for querying graph data provided in this specification. Based on the same idea, this specification also provides corresponding devices, storage media, and electronic devices.
[0048] Figure 3 This is a schematic diagram of a graph data query device provided in an embodiment of this specification. The device includes: The acquisition module 300 is used to acquire the query load of each query performed on graph data in the graph database instance; The determination module 301 is used to determine the common query of each query load, which is the query to be performed when each query load performs a query in the graph database instance; A creation module 302 is used to determine the results obtained by using the public query in the graph database instance, and store them as a materialized view of the graph database instance; The query module 303 is used to determine the query result obtained by executing the query in the graph database instance using the query to be executed when the query statement to be executed contains the public query, based on the stored materialized view.
[0049] Optionally, the materialized view includes a start node, an end node, a path from the start node to the end node in the graph structure corresponding to the graph database instance, and query conditions corresponding to the path; The path includes an n-hop path from the starting node to the ending node, where n is not less than 1.
[0050] Optionally, the device further includes: The management module 304 is used to update the stored materialized view according to the updated graph database instance after the graph database instance is updated.
[0051] Optionally, updating the graph database instance includes: creating a new node and an edge connected to the new node in the graph database instance; The management module 304 is specifically used to determine, based on the updated graph database instance, whether there exists a path from the start node to the end node that passes through the newly added node and satisfies the query conditions; if so, to add a path from the start node to the end node that passes through the newly added node and satisfies the query conditions in the materialized view.
[0052] Optionally, updating the graph database instance includes: deleting existing nodes and edges connected to the existing nodes in the graph database instance; The management module 304 is specifically used to delete the materialized view if the existing node is at least one of the starting node and the ending node; and to delete the path containing the existing node if the existing node is not at least one of the starting node and the ending node.
[0053] Optionally, updating the graph database instance includes: creating new edges in the graph database instance; The management module 304 is specifically used to determine, based on the updated graph database instance, whether there exists a path from the starting node to the ending node that passes through the newly added edge and satisfies the query conditions; if so, to add a path from the starting node to the ending node that passes through the newly added edge and satisfies the query conditions in the materialized view.
[0054] Optionally, updating the graph database instance includes: deleting existing edges in the graph database instance; The management module 304 is specifically used to delete paths that contain the existing edge.
[0055] Optionally, the management module 304 is further configured to, after the creation module 303 determines that the result obtained by using the public query in the graph database instance is used as a materialized view of the graph database instance and stored, generate maintenance statement templates corresponding to different update types for updating the graph database instance; the different update types include at least one of: creating a new node and edges connected to the new node in the graph database instance, deleting an existing node and edges connected to the existing node in the graph database instance, creating a new edge in the graph database instance, and deleting an existing edge in the graph database instance; The management module 304 is specifically used to: select a maintenance statement template corresponding to the update type of the graph database instance as the target template; generate a maintenance statement for updating the materialized view based on the changed points and / or edges in the updated graph database instance and the target template; and execute the maintenance statement to update the stored materialized view.
[0056] For ease of description, this specification describes the above devices by dividing them into various modules or units based on their functions. Of course, when implementing one or more of these specifications, the functions of each module or unit can be implemented in one or more software and / or hardware components, or a module that performs the same function can be implemented by a combination of multiple sub-modules or sub-units. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division; in actual implementation, there may be other division methods. For instance, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed.
[0057] This specification also provides a computer-readable storage medium storing a computer program that, when executed by a processor, can be used to perform the graph data query method provided above.
[0058] This specification also provides a computer program product, which includes a computer program that, when executed by a processor, implements the graph data query method provided above.
[0059] based on Figure 1 The method for querying graph data shown in this specification is further provided in the embodiments. Figure 4 The diagram shows the structure of the electronic device. Figure 4 At the hardware level, the electronic device includes a processor, internal bus, network interface, memory, and non-volatile storage, and may also include other hardware required for the business. The processor reads the corresponding computer program from the non-volatile storage into memory and then runs it to implement the above-mentioned method for querying graph data.
[0060] The above description is merely an embodiment of this specification and is not intended to limit this specification. Various modifications and variations can be made to this specification by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this specification should be included within the scope of the claims of this specification.
Claims
1. A method for querying graph data, the method comprising: Obtain the query load for each graph data query performed in the graph database instance; Determine the common query for each query load, which is the query to be performed when querying the graph database instance using each query load; The results obtained from the public query in the graph database instance are determined and stored as a materialized view of the graph database instance. When the query statement to be executed contains the common query, the query result obtained by executing the query in the graph database instance using the stored materialized view is determined.
2. The method as described in claim 1, wherein the materialized view includes a start node, an end node, a path from the start node to the end node in the graph structure corresponding to the graph database instance, and query conditions corresponding to the path; The path includes an n-hop path from the starting node to the ending node, where n is not less than 1.
3. The method of claim 2, further comprising: After the graph database instance is updated, the stored materialized view is updated according to the updated graph database instance.
4. The method of claim 3, wherein updating the graph database instance includes: Create a new node and an edge connected to the new node in the graph database instance; Based on the updated graph database instance, update the stored materialized view, specifically including: Based on the updated graph database instance, determine whether there exists a path from the starting node to the ending node that passes through the newly added node and satisfies the query conditions; If such a path exists, a new path is added to the materialized view that runs from the starting node to the ending node, passes through the new node, and satisfies the query conditions.
5. The method of claim 3, wherein updating the graph database instance includes: Delete existing nodes and edges connected to existing nodes in the graph database instance; Based on the updated graph database instance, update the stored materialized view, specifically including: If the existing node is at least one of the starting node and the ending node, then delete the materialized view; If the existing node is not at least one of the starting node and the ending node, then delete the path containing the existing node.
6. The method of claim 3, wherein updating the graph database instance includes: Create new edges in the graph database instance; Based on the updated graph database instance, update the stored materialized view, specifically including: Based on the updated graph database instance, determine whether there exists a path from the starting node to the ending node that passes through the newly added edge and satisfies the query conditions; If such a path exists, a new path is added to the materialized view that runs from the starting node to the ending node, passes through the new edge, and satisfies the query conditions.
7. The method of claim 3, wherein updating the graph database instance includes: Delete existing edges in the graph database instance; Based on the updated graph database instance, update the stored materialized view, specifically including: Delete any path that contains the existing edge.
8. The method of claim 3, after determining and storing the results obtained by using the public query in the graph database instance as a materialized view of the graph database instance, the method further includes: Based on the different update types that update the graph database instance, generate maintenance statement templates corresponding to different update types; The different update types include at least one of the following: creating a new node and an edge connected to the new node in the graph database instance, deleting an existing node and an edge connected to the existing node in the graph database instance, creating a new edge in the graph database instance, and deleting an existing edge in the graph database instance. Based on the updated graph database instance, update the stored materialized view, specifically including: Based on the update type of the graph database instance, select the maintenance statement template corresponding to the update type as the target template; Based on the changed points and / or edges in the updated graph database instance, and the target template, generate maintenance statements for updating the materialized view; Execute the maintenance statement to update the stored materialized view.
9. A graph data query device, the device comprising: The acquisition module is used to acquire the query load of each graph data query performed in the graph database instance; A determination module is used to determine the common query for each query load, which is the query to be performed when querying the graph database instance using each query load; A module is created to determine the results obtained by using the public query in the graph database instance, and to store them as a materialized view of the graph database instance. The query module is used to determine the query result obtained by executing the query in the graph database instance using the query to be executed when the query statement to be executed contains the public query, based on the stored materialized view.
10. A computer-readable storage medium storing a computer program that, when executed by a processor, implements the method described in any one of claims 1-8.
11. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the method described in any one of claims 1-8.
12. A computer program product comprising a computer program that, when executed by a processor, implements the method described in any one of claims 1-8.