A persistent graph index structure and query method suitable for incremental queries

Abstract

The application discloses a kind of persistent graph index structure and query method suitable for incremental query, index structure, including drawer and cabinet;Wherein, drawer is used to store similar elements, including the same attribute same value starting vertex and the edge element of the same attribute different value terminal vertex;Cabinet is used to store and manage the table structure of drawer, it stores the vertex with same attribute different value, and the edge drawer with these vertex as starting vertex.Based on the query method realized by the persistent graph index structure described, including subgraph matching query and incremental query.Can improve the efficiency of subgraph matching and the efficiency of subgraph matching after graph update, and reduce the space overhead of incremental query.

Description

Technical Field

[0001] This invention belongs to the field of graph data management technology, specifically relating to a persistent graph index structure and query method suitable for incremental queries. Background Technology

[0002] Graph databases are databases that store and manage data using graph data structures, and are widely used in fields such as biochemistry, software engineering, social networks, and artificial intelligence. In real-world applications, when graph data is updated—for example, by adding or deleting data—the original query results often become unreliable, requiring the query to be re-executed. In large-scale graph datasets, re-executing a query on all the data is extremely costly.

[0003] The concept of graph databases evolved from the understanding that in many applications, a single relation type connecting instances of a single concept can itself form a graph structure, whose data model is primarily represented by edges between vertices. Connections such as document links in hypertext documents, road connections in geodatabases, and chemical bonds in proteins can all be represented as edges in a graph database. A further requirement for most data models is that the data strictly conforms to the model's structural requirements. Applications in heterogeneous data integration and web data require greater flexibility, thus creating a need for using graph models for data management.

[0004] Graph databases and related queries are widely used in practical production processes: In a path network, a traveler from location loc1 to location loc2 might be interested in the shortest distance route with certain road constraints, such as avoiding roads under construction to prevent delays or avoiding toll roads. The shortest path operation only requires a subset of the graph specified at the time of query. In social networks, some graph analysis techniques calculate the shortest path between two people, and the returned path must use some type of relationship (e.g., family relationship).

[0005] Graphs in real life are constantly changing, and correspondingly, graph databases also require frequent updates. Updates often render existing query results unreliable, necessitating re-execution. First, for large-scale graph data, recalculating from scratch is prohibitively expensive. Second, the maintenance overhead of the database in response to frequent updates is also significant. Furthermore, some database techniques used to accelerate queries, such as indexes, also incur additional maintenance costs for frequent updates. Therefore, if queries on this data need to be recalculated every time it's updated, the query cost becomes prohibitively high.

[0006] While incremental algorithms exist in the field of data management, their drawbacks are significant: GraphBolt uses a dependency graph to store the complete graph update process and vertex values ​​to represent intermediate computational results. GraphInc stores the states of all vertices and generated information on disk after each update. Existing systems must maintain the intermediate results of previous computations, and the large number of intermediate results can lead to inefficiency. Each GraphBolt update generates |V| new vertices and...

[0007] The presence of 2^3 edges (|V|) can easily lead to memory overload in social networks where graph updates are almost continuous. GraphInc stores the updated information to disk, increasing the cost of I / O operations. Furthermore, GraphBolt's method of storing intermediate results using vertex values ​​is only applicable to graph structure computations, not graph queries. GraphBolt and Kickstarter require users to write graph computation statements using the provided API, which includes various functions for updating graph changes, checking changes in vertex attribute values, and propagating changes. AFF-based methods require researchers to propose entirely new intermediate structures for each computation or query and prove their correctness. Manually designing incremental algorithms is error-prone, difficult to verify, and lacks generality. Summary of the Invention

[0008] The technical problem to be solved by this invention is to address the shortcomings of the prior art by providing a persistent graph index structure and query method suitable for incremental queries. This involves a subgraph matching index applicable to incremental algorithms, which implements graph index persistence, index-based subgraph matching, incremental query-based subgraph matching, and modification, insertion, and deletion of the persistent index based on drawer management. It can omit intermediate results of subgraph matching queries, making it suitable for efficient management and querying of graph data such as social networks and transportation networks. It can improve the efficiency of subgraph matching and subgraph matching queries after graph updates, and reduce the space overhead of incremental queries.

[0009] To achieve the above-mentioned technical objectives, the technical solution adopted by the present invention is as follows:

[0010] A persistent graph index structure suitable for incremental queries, comprising drawers and cabinets;

[0011] The drawer is used to store similar elements, including edge elements consisting of starting vertices with the same attribute and the same value, and ending vertices with the same attribute but different values.

[0012] The cabinet is a table structure used to store and manage drawers. It stores vertices with the same attribute but different values, as well as side drawers that start from these vertices.

[0013] To optimize the above technical solution, the specific measures also include:

[0014] The drawer described above has open and closed states. By detecting the open and closed states of the drawer, it can be determined whether the drawer has been loaded into memory.

[0015] When an element in a drawer is updated, all other elements in the drawer are checked to see if they should be updated synchronously.

[0016] Each row of the cabinet mentioned above represents a vertex, and each column represents the terminating vertex attribute. The rows and columns together represent the side drawers from the row vertex to the column attribute vertex.

[0017] Cabinet configuration functions are used to manage the drawers stored in the cabinet, including reading into memory and storing into external storage;

[0018] The cabinet only changes its structure when a vertex is deleted or inserted.

[0019] The query methods implemented based on the above persistent graph index structure include subgraph matching queries and incremental queries;

[0020] The subgraph matching query includes the following steps:

[0021] S11: Check if an index file exists at a specified location on the hard drive. If the index file does not exist, create an empty index file. If the index file exists, read the index file according to the query graph, establish the query order, and complete the preprocessing of the query graph.

[0022] S12: Connect the edges stored in the drawers based on the cabinet structure and generate the resulting subgraph;

[0023] S13: If there are still unprocessed query graphs in this query, it means that there are subsequent query operations, so proceed to S14; if this query has ended and there are no subsequent query operations, then end the query and wait for user operation.

[0024] S14: Preprocess the unprocessed query graph and perform drawer management.

[0025] The above-mentioned S11 reads the index file based on the query graph, including:

[0026] S111: Preprocess the vertices and edges of the query graph: Read the row counts of different cabinets in the index; for each vertex in the query graph, for its attribute, query the row count of the cabinet corresponding to that attribute in the index, and store it as the candidate number Num for that vertex. cand It also analyzes the degree of each vertex in the query graph and stores it as Deg;

[0027] according to Sort the values ​​from largest to smallest, use the vertex and its critical point as the query substructure, and establish the matching-connection order of the query substructure in the same order;

[0028] S112: Calculate the size of the contiguous space available in memory, initialize the cabinet structure according to the number of attributes, including a B+ tree structure for mapping vertex values ​​to cabinet row numbers, and a table structure for managing drawers;

[0029] S113: Based on the structural features of the query graph, and relying on the cabinet structure that has been read into memory, find the storage location of the drawer related to the query, load it into memory, and mark the drawer as open.

[0030] The aforementioned S12 specifically includes:

[0031] S121: For each query substructure, relying on the matching-connection order, find the corresponding row of the cabinet where the main vertex of the query substructure is located, determine whether there are enough elements in the drawer of the response column of the row to satisfy all the adjacent points of the main vertex, and filter out vertices that cannot form a substructure, that is, vertices with insufficient elements in the drawer.

[0032] S122: For the substructures corresponding to the remaining vertices, query the column attribute of the corresponding row of the cabinet where the boundary vertex is located, and determine whether the connection can be executed by querying whether there is an edge element in the drawer that connects to the other side.

[0033] S123: Perform actual connection operations on substructures that satisfy all connection conditions to generate a subgraph, which is the result subgraph of subgraph matching.

[0034] S14 above is as follows: First, mark the drawer that is not related to the query as closed. Second, mark the drawer that is related to the query, has been loaded but marked as closed, as open again. Alternatively, load the drawer that is related to the query but has not been loaded into memory into memory and mark it as open. If the drawer that is related to the query but has not been loaded into memory exceeds the available memory range of the drawer, remove the drawer marked as closed from memory and proceed to S12.

[0035] The incremental query described above includes the following steps:

[0036] S21: When there is a modification, insertion, or deletion operation on the graph data, an incremental drawer is generated, and the original drawer and related query results are marked;

[0037] S22: Reuse the original query results, judge and delete the marked query results: When performing subgraph matching incremental calculation, delete the subgraphs in the query results before modification that used the modified drawer;

[0038] S23: Following the subgraph matching steps, perform the query operation only on the modified drawer to obtain the updated subgraph result, and merge it with the query result deleted in step S22 to obtain the updated complete subgraph query result;

[0039] S24: When the modified drawer is removed from memory, make consistent modifications to the file on disk and replace the drawer on disk with the incremental drawer.

[0040] The aforementioned S21 includes:

[0041] S211: Read in the modification command for the graph data. For the attributes and values ​​of the starting vertex of the edge to be modified, and the attributes of the ending vertex, generate a new drawer and name it the incremental drawer.

[0042] S212: Based on the type of modification, generate modification flags, bind the edges to the modification flags, and put them into the incremental drawer;

[0043] S213: After all modification instructions have been stored in the incremental drawer, for each incremental drawer, put the unaffected edges in the drawer with the same position number in the original index into the incremental drawer and mark the original drawer.

[0044] The aforementioned S22 includes:

[0045] S221: For the marked original drawer structure, remove all internal edges;

[0046] S222: For the original query result, compare the edges taken out in step S221 in turn. If the edge exists in the subgraph, delete the subgraph.

[0047] S223: Save the trimmed subgraphs; these are the reusable results from the original query.

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

[0049] 1. This invention proposes a persistent graph data index applicable to incremental algorithms, including a special drawer structure and a cabinet structure for managing the drawers. It has good scalability and extensibility, and is suitable for graph query algorithms that rely on connectivity. Through drawer management, the graph index is persisted, resulting in higher data security, and it is suitable for managing large-scale data.

[0050] 2. The incremental query algorithm proposed in this invention, combined with an index, forms an index suitable for incremental queries. It is not only faster than general incremental query methods but also eliminates the overhead of maintaining intermediate results. The subgraph matching algorithm proposed in this invention, combined with an index, allows users to directly obtain subgraph matching results by querying the index, eliminating the need for correctness verification and reducing query difficulty. On the one hand, it avoids the overhead of frequently modifying graph data; on the other hand, it allows for the reuse of query results from before the update, quickly obtaining updated query results without generating intermediate results. Compared to traditional incremental graph algorithms, the method proposed in this invention consumes fewer resources and is more user-friendly. Attached Figure Description

[0051] Figure 1 This is a schematic diagram of the overall process of an embodiment of the present invention;

[0052] Figure 2 This is a schematic diagram of the index structure according to an embodiment of the present invention;

[0053] Figure 3 This is a schematic diagram of the incremental query process in an embodiment of the present invention. Detailed Implementation

[0054] The embodiments of the present invention will be described in further detail below with reference to the accompanying drawings.

[0055] This invention provides a persistent graph index structure suitable for incremental queries, comprising drawers and cabinets;

[0056] The drawer is used to store similar elements, including edge elements consisting of starting vertices with the same attribute and the same value, and ending vertices with the same attribute but different values.

[0057] The cabinet is a table structure used to store and manage drawers. It stores vertices with the same attribute but different values, as well as side drawers that start from these vertices.

[0058] The drawer has open and closed states. By detecting the open and closed states of the drawer, it can be determined whether the drawer has been loaded into memory.

[0059] When an element in a drawer is updated, all other elements in the drawer are checked to see if they should be updated synchronously.

[0060] The practical significance of this structure lies in:

[0061] Graph query algorithms often place great emphasis on the connectivity of graph data; modifications to a vertex or edge often cause synchronous changes in the local data of that vertex or edge.

[0062] Each row of the cabinet represents a vertex, and each column represents the terminating vertex attribute. The rows and columns together represent the side drawers from the row vertex to the column attribute vertex.

[0063] Cabinet configuration functions are used to manage the drawers stored in the cabinet, including reading into memory and storing into external storage;

[0064] The cabinet only changes its structure when a vertex is deleted or inserted.

[0065] The query methods implemented based on the aforementioned persistent graph index structure include subgraph matching queries and incremental queries;

[0066] Combination Figure 1 The steps for subgraph matching query in this embodiment are as follows:

[0067] S11: Check if an index file exists at a specified location on the hard drive. If the index file does not exist, create an empty index file. If the index file exists, read the index file according to the query graph and establish the query plan.

[0068] In step S11, the step of reading the index file based on the query graph is as follows:

[0069] S111: Preprocess the vertices and edges of the query graph: Read the row counts of different cabinets in the index; for each vertex in the query graph, for its attribute, query the row count of the cabinet corresponding to that attribute in the index, and store it as the candidate number Num for that vertex. cand In addition, the degree of each vertex in the query graph is analyzed and stored as Deg.

[0070] The vertices in the query graph are sorted by the number of candidate vertices based on their attribute count (from smallest to largest) and the degree of vertices in the query graph (from largest to smallest). Sort the values ​​from largest to smallest, take the vertex (main vertex) and its critical point as the query substructure, and establish the matching-connection order of the query substructure in the same order;

[0071] S112: Calculate the size of the available contiguous space in memory, obtain the number of attributes required for the query through step S111, initialize the cabinet structure according to the number of attributes, including a B+ tree structure for mapping vertex values ​​to cabinet row numbers, and a table structure for managing drawers.

[0072] S113: Based on the structural features of the query graph, and relying on the cabinet structure that has been read into memory, find the storage location of the drawer related to the query, load it into memory, and mark the drawer as open.

[0073] S12: Perform matching and connection judgment on the preprocessed query graph to generate query results: connect the edges stored in the drawers based on the cabinet structure and generate a result subgraph.

[0074] Subgraph matching is performed in step S12, including:

[0075] S121: For each query substructure, relying on the matching-connection order obtained in step S111, find the corresponding row of the cabinet containing the main vertex of the query substructure, and determine whether there are enough elements in the drawer of the response column of that row to satisfy all the adjacent points of the main vertex. Filter out vertices that cannot form a substructure, i.e., vertices with insufficient elements in the drawer;

[0076] S122: For the substructures corresponding to the remaining vertices, query the column attribute of the corresponding row of the cabinet where the boundary vertex is located, and determine whether the connection can be executed by querying whether there is an edge element in the drawer that connects to the other side.

[0077] S123: Perform actual connection operations on substructures that satisfy all connection conditions to generate a subgraph, which is the result subgraph of subgraph matching.

[0078] S13: If there are unprocessed query graphs, proceed to S14. Otherwise, mark all drawers as open and output a flag indicating that the query is complete, awaiting user action. The entire index structure can be removed from memory.

[0079] S14: Preprocess the unprocessed query graph and perform drawer management:

[0080] First, mark drawers unrelated to the query as closed. Then, mark query-related drawers that have been loaded but marked as closed as open again, or load query-related drawers that haven't been loaded into memory and mark them as open. If the available memory is exceeded, release the memory of drawers marked as closed. Proceed to S12.

[0081] Specifically, the steps for managing the drawers are as follows:

[0082] S141: Load the new query graph, preprocess the vertices and edges of the query graph, read the row number of different cabinets in the index, divide the query substructure according to the number of candidate attribute vertices from small to large and the degree of vertices in the query graph from large to small, and establish the matching-connection order.

[0083] S142: In all drawers that have been loaded into memory, mark the drawers that are open but not related to the new query graph as closed, and mark the drawers that are closed but related to the new query graph as open.

[0084] S143: If there are drawers related to the query but not loaded, first determine the remaining available memory size. If the memory size is insufficient, release the memory of the closed drawers. Load the drawers related to the query but not loaded into memory and mark them as open.

[0085] Combination Figure 2 The index structure in this embodiment is as follows:

[0086] To illustrate the index structure in detail, let's take the data shown in the following figure as an example:

[0087] Vertices: (1,A),(2,A),(3,A),(4,A),(5,A),(6,A),(7,B),(8,B),(9,B),(10,B);

[0088] Edges: (5,7), (3,4), (1,8), (2,10), (6,10), (7,9).

[0089] Vertex (1,A) represents a vertex with a value of 1 and an attribute of A; edge (1,8) represents an undirected edge between vertex 1 and vertex 8.

[0090] Depend on Figure 2 It can be seen that for each attribute, an index is built into a cabinet structure, where each row of the cabinet represents a vertex value and each column represents the attribute of the other vertex of the edge. For this embodiment, the specific steps are as follows:

[0091] S1: Read in edge (5,7). First, use the B+ tree to find that the row number of 5 is 0 and the row number of 7 is also 0. Then, create drawers in the 0th row and 1st column of cabinet A and the 0th row and 0th column of cabinet B, and put the tuples representing the other's position into each drawer.

[0092] S2: Read in edge (3,4). First, use the B+ tree to get the row number of 3 as 1 and the row number of 4 as 2. Then, create drawers in the first row and 0 column of cabinet A and the second row and 0 column of cabinet A, and put the tuples representing the other's position into each drawer.

[0093] S3: Read in edge (1,8). First, use the B+ tree to get the row number of 1 as 3 and the row number of 8 as 1. Then, create drawers in the 3rd row and 1st column of cabinet A and the 1st row and 0th column of cabinet B, and put the tuples representing the other's position into each drawer.

[0094] S4: Read in edge (2,10). First, use the B+ tree to get the row number of 2 as 4 and the row number of 10 as 2. Then, create drawers in the 4th row and 1st column of cabinet A and the 2nd row and 0th column of cabinet B, and put the tuples representing the other's position into each drawer.

[0095] S5: Read in edge (6,10). First, use the B+ tree to get the row number of 6 as 5 and the row number of 10 as 2. Then, create a new drawer in the 5th row and 1st column of cabinet A. Place the tuples representing the positions of the other two drawers in the 5th row and 1st column of cabinet A and the 2nd row and 0th column of cabinet B.

[0096] S6: Read in edge (7,9). First, use the B+ tree to get the row number of 7 as 0 and the row number of 9 as 3. Then, create drawers in the 0th row and 1st column of cabinet B and the 3rd row and 1st column of cabinet B, and put the tuples representing the other's position into each drawer.

[0097] Combination Figure 3 The steps for performing incremental queries in this invention are as follows:

[0098] S21: For update operations (modification, insertion, or deletion), generate incremental drawers and mark the original drawers and related query results: When there are modification, insertion, or deletion operations on graph data, generate the drawer where the edge corresponding to the update operation is located and mark the original drawer.

[0099] In step S21, the step of generating the incremental drawer is as follows:

[0100] S211: Read in the modification command for the graph data. For the attributes and values ​​of the starting vertex of the edge to be modified, and the attributes of the ending vertex, generate a new drawer and name it the incremental drawer.

[0101] S212: Based on the type of modification, generate modification flags, bind the edges to the modification flags, and put them into the incremental drawer;

[0102] S213: After all modification instructions have been stored in the incremental drawer, for each incremental drawer, put the unaffected edges in the drawer with the same position number in the original index into the incremental drawer and mark the original drawer.

[0103] S22: When performing subgraph matching incremental calculation, delete the subgraphs in the query results before modification that used the marked drawers.

[0104] Step S22 generates the pruned original query results. The steps are as follows:

[0105] S221: For the original drawer structure marked in step S21, remove all the internal edges;

[0106] S222: For the original query result, compare the edges taken out in step S221 in turn. If the edge exists in the subgraph, delete the subgraph.

[0107] S223: Save the pruned subgraphs; these are the reusable results from the original query results.

[0108] S23: Query the incremental drawer and generate the incremental result subgraph: According to the subgraph matching steps, only the drawer of the incremental index is queried to obtain the updated new subgraph result, and merge it with the pruned query result in step S22 to obtain the updated complete subgraph query result;

[0109] S24: Perform drawer management, merge incremental drawers and persist them: When the original drawer in the index is released from memory, make consistent modifications to the file on the disk, and replace the drawer on the disk with the incremental drawer.

[0110] This invention proposes an incremental index structure that quickly yields updated query results by reusing query results from before the update. It also introduces an incremental algorithm, integrating it with the index to create an index suitable for incremental queries: when a graph update instruction arrives, the graph data is not updated immediately but saved as an increment. During a query, the query results from before the update arrive are reused, supplemented by incremental queries, to obtain the correct result. The underlying principle is that in the real world, graph data updates are usually small compared to the complete graph data. When the update is small, the resulting change in query results is also usually small. Utilizing the query results from before the update reduces the query overhead after the update. Furthermore, incremental computation is crucial for parallel query processing. It partitions a large graph, performs partial query computations on different processors across partitions, treats inter-processor messages as updates, and performs incremental iterative computation to reduce costs.

[0111] This invention, based on incremental query algorithms and incremental dependency graphs, designs a novel incremental index structure. By querying the incremental index, the impact of updates on query results and the final query result are obtained. Traditional graph algorithms are difficult to apply directly to frequently updated social networks. Even if correctness can be theoretically guaranteed, the cost of updating the graph itself cannot be avoided. Incremental algorithms can minimize the cost of graph updates. Existing systems using incremental graphs require maintaining huge intermediate results, which can easily lead to memory overload or high I / O costs. Using indexes can eliminate intermediate results and directly obtain the query result. Manual incremental query methods are difficult to verify correctness; using indexes significantly reduces query difficulty and has universality.

[0112] The above are merely preferred embodiments of the present invention. The scope of protection of the present invention is not limited to the above embodiments. All technical solutions falling within the scope of the present invention's concept are within the scope of protection of the present invention. It should be noted that for those skilled in the art, any improvements and modifications made without departing from the principles of the present invention should be considered within the scope of protection of the present invention.

Claims

1. A query method implemented using a persistent graph index structure, characterized in that, The persistent graph index structure includes drawers and cabinets. Drawers store similar elements, including starting vertices with the same attribute and value, and edge elements consisting of ending vertices with the same attribute but different values. Cabinets are table structures used to store and manage drawers, storing vertices with the same attribute but different values, and the corresponding edge drawers. Drawers have open and closed states; by detecting the open and closed states of drawers, it is determined whether the drawer has been loaded into memory. When an element in a drawer is updated, other elements in the drawer are checked for synchronous updates. Each row in a cabinet represents a vertex, and each column represents the attribute of the ending vertex; rows and columns together represent the edge drawers from row vertices to column attribute vertices. Cabinet configuration functions manage the drawers stored in the cabinet, including loading into memory and storing in external storage. The cabinet structure is only modified when a vertex is deleted or inserted. The query methods include subgraph matching query and incremental query; The subgraph matching query includes the following steps: S11: Check if an index file exists at a specified location on the hard drive. If the index file does not exist, create an empty index file. If the index file exists, read the index file according to the query graph, establish the query order, and complete the preprocessing of the query graph. S12: Connect the edges stored in the drawers based on the cabinet structure and generate the resulting subgraph; S13: If there are still unprocessed query graphs in this query, it means that there are subsequent query operations, so proceed to S14; if this query has ended and there are no subsequent query operations, then end the query and wait for user operation. S14: Preprocess the unprocessed query graph and perform drawer management.

2. The query method according to claim 1, characterized in that, S11 reads the index file based on the query graph, including: S111: Preprocess the vertices and edges of the query graph: Read in the row counts of different cabinets from the index; for each vertex in the query graph, for its attribute, query the row count of the cabinet corresponding to that attribute in the index and store it as a candidate number for that vertex. ; and analyze the degree of each vertex in the query graph, storing it as ; according to Sort the values ​​from largest to smallest, use the vertex and its critical point as the query substructure, and establish the matching-connection order of the query substructure in the same order; S112: Calculate the size of the contiguous space available in memory, initialize the cabinet structure according to the number of attributes, including a B+ tree structure for mapping vertex values ​​to cabinet row numbers, and a table structure for managing drawers; S113: Based on the structural features of the query graph, and relying on the cabinet structure that has been read into memory, find the storage location of the drawer related to the query, load it into memory, and mark the drawer as open.

3. The query method according to claim 1, characterized in that, S12 specifically includes: S121: For each query substructure, relying on the matching-connection order, find the corresponding row of the cabinet where the main vertex of the query substructure is located, determine whether there are enough elements in the drawer of the response column of the row to satisfy all the adjacent points of the main vertex, and filter out vertices that cannot form a substructure, that is, vertices with insufficient elements in the drawer. S122: For the substructures corresponding to the remaining vertices, query the column attribute of the corresponding row of the cabinet where the boundary vertex is located, and determine whether the connection can be executed by querying whether there is an edge element in the drawer that connects to the other side. S123: Perform actual connection operations on substructures that satisfy all connection conditions to generate a subgraph, which is the result subgraph of subgraph matching.

4. The query method according to claim 1, characterized in that, S14 is as follows: First, drawers that are not related to the query are marked as closed. Second, drawers that are related to the query, have been loaded but marked as closed, are marked as open again. Alternatively, drawers that are related to the query but have not been loaded into memory are loaded into memory and marked as open. If the number of drawers that are related to the query but have not been loaded into memory exceeds the available memory range of the drawers, the drawers marked as closed are removed from memory and the process proceeds to S12.

5. The query method according to claim 1, characterized in that, Incremental queries involve the following steps: S21: When there is a modification, insertion, or deletion operation on the graph data, an incremental drawer is generated, and the original drawer and related query results are marked; S22: Reuse the original query results, judge and delete the marked query results: When performing subgraph matching incremental calculation, delete the subgraphs in the query results before modification that used the modified drawer; S23: Following the subgraph matching steps, perform the query operation only on the modified drawer to obtain the updated subgraph result, and merge it with the query result deleted in step S22 to obtain the updated complete subgraph query result; S24: When the modified drawer is removed from memory, make consistent modifications to the file on disk and replace the drawer on disk with the incremental drawer.

6. The query method according to claim 5, characterized in that, S21 includes: S211: Read in the modification command for the graph data. For the attributes and values ​​of the starting vertex of the edge to be modified, and the attributes of the ending vertex, generate a new drawer and name it the incremental drawer. S212: Based on the type of modification, generate modification flags, bind the edges to the modification flags, and put them into the incremental drawer; S213: After all modification instructions have been stored in the incremental drawer, for each incremental drawer, put the unaffected edges in the drawer with the same position number in the original index into the incremental drawer and mark the original drawer.

7. The query method according to claim 5, characterized in that, S22 includes: S221: For the marked original drawer structure, remove all internal edges; S222: For the original query result, compare the edges taken out in step S221 in turn. If the edge exists in the subgraph, delete the subgraph. S223: Save the trimmed subgraph, which is the result that can be reused in the original query results.

Images