A distributed attributed graph management system and method of using the same

Abstract

The application provides a distributed attribute graph management system and a use method thereof, comprising a data storage module and a query processing module; the attribute graph is divided by taking a connected subgraph as a basic unit, the number of attribute pairs in the connected subgraph is calculated, and the number is taken as the cost of the connected subgraph; and when the division is performed, the benefit of each partition and the current connected subgraph is calculated, the connected subgraph is distributed to the partition with the maximum benefit and still having storage space, so that the load of each partition is kept within an acceptable range, and the repeated nodes are reduced as much as possible, the threshold is reduced by subtracting the cost of the intersection, so that the upper limit of the load of each partition is restricted; the subquery with a constant is added to the plan preferentially in a heuristic manner, and then the remaining subqueries are sequentially added to the plan according to the number of intersections of the subqueries and the query in the plan, so that the number of intermediate results which do not affect the final result is reduced, and unnecessary calculation and communication cost are reduced.

Description

Technical Field

[0001] This invention belongs to the field of graph database management technology in the area of ​​distributed attribute graph knowledge graphs, specifically involving a distributed attribute graph management system and its usage method. Background Technology

[0002] With strong national support for "new infrastructure," China's artificial intelligence technology is poised for a new era of rapid development. Hot research areas such as large language models urgently need to supplement external knowledge with knowledge graphs. Knowledge graphs are also fundamental to enabling machines to possess cognitive abilities and will play an irreplaceable role in the field of artificial intelligence.

[0003] A knowledge graph is essentially a large-scale semantic network constructed from entities and the various relationships between them. Entities can be real things (such as specific people or books) or abstract concepts (such as scientific laws or mathematical axioms). The various relationships between entities are called "relationships," such as friendships or teacher-student relationships. In practical applications, knowledge composed of entities, relationships, and their attributes forms one or more connected graphs with clear semantics. In these graphs, each entity is a node, and the relationships between entities are the edges connecting them. Ultimately, knowledge is structurally represented as a network, i.e., a knowledge graph.

[0004] One of the core challenges of knowledge graph data management is choosing an appropriate method to store and represent knowledge data, and providing efficient analytical and querying tools for knowledge requests. To ensure that the data in a knowledge graph is machine-readable and easily manipulated, it is crucial to use a specific data model to represent the data. Currently, attribute graph models and RDF models are the two mainstream data models in the field of knowledge graphs. Among them, attribute graphs have the advantage of providing more complete and richer data information. An example of an attribute graph can be found here. Figure 1 To efficiently manage and query knowledge graphs, graph database-based query languages, such as Cypher and Gremlin, have emerged. These query languages ​​enable users to retrieve subgraphs that satisfy query conditions through graph pattern queries. Each graph pattern query can be represented as a query graph. See the example of an attribute graph pattern query. Figure 2 .

[0005] For large-scale attribute graph knowledge graphs with over a billion edges, which are currently quite common, efficient graph schema querying has become a hot research topic. Meanwhile, with the continuous growth of attribute graph data, a single machine can no longer handle such large-scale graph datasets. Faced with this situation, using a distributed database system for query processing is essential. Distributed computing platforms have significant advantages in processing large-scale attribute graph knowledge graphs due to their high scalability and high performance. However, when performing attribute graph schema query processing in a distributed environment, the sheer size and complexity of attributes present numerous challenges to query performance and efficiency.

[0006] Therefore, in order to improve the efficiency of attribute graph schema queries, it is necessary to build an efficient distributed attribute graph management system and its usage method on a distributed computing platform from two levels: distributed storage and distributed execution. Summary of the Invention

[0007] To address the shortcomings and deficiencies in the aforementioned technologies, this invention provides a distributed attribute graph management system and its usage method.

[0008] The technical solution provided by this invention is as follows:

[0009] A distributed attribute graph management system, characterized in that: it includes

[0010] A data storage module receives an attribute graph as input. Based on relation types, the attribute graph is divided into several subgraphs, and each subgraph is further divided into several connected subgraphs. Connected subgraphs are used as the basic unit for partitioning the attribute graph. The number of attribute pairs in each connected subgraph is calculated as the cost of the connected subgraph. During partitioning, the benefit of each partition relative to the current connected subgraph is calculated, and the connected subgraph is allocated to the partition with the largest remaining storage space and the highest benefit.

[0011] In the query processing module, the input query is first rewritten into a set of subqueries; a query plan is generated by first adding subqueries with constants to the plan, then sorting the remaining subqueries in descending order according to the number of intersections between the subqueries and the planned query, and adding them to the query plan; then the subqueries are sent to all slave nodes and the graph-mode query is executed; and the returned partial results are merged to form the final result.

[0012] Furthermore, the present invention also provides a method for using a distributed attribute graph management system, characterized by comprising the following steps:

[0013] S1: Establish an attribute graph management system;

[0014] S2: Divide the attribute graph into several subgraphs based on the relation type, and then divide the subgraphs into several connected subgraphs;

[0015] S3: Divide the attribute graph into units of connected subgraphs, calculate the number of attribute pairs in the connected subgraphs, and use them as the cost of the connected subgraphs.

[0016] S4: When performing partitioning, calculate the benefit of each partition to the current connected subgraph, and allocate the connected subgraph to the partition that still has storage space and the greatest benefit;

[0017] S5: Store the database on the server;

[0018] S6: Create a database, specifying the database name and the path for storing data;

[0019] S7: Perform a query based on the given query statement;

[0020] S7.1: Decompose the query statement into a set of subqueries;

[0021] S7.2: Generate a query plan;

[0022] S7.3: Send the subquery to all Slave nodes and execute the graph pattern query;

[0023] S8: Merge the returned partial results to form the final result.

[0024] As a further preferred embodiment of the present invention, step S1, when establishing the attribute graph management system, includes the following steps:

[0025] S1.1: Deploy the front end of the attribute graph management system:

[0026] S1.1.1: Download and open the front-end package;

[0027] S1.1.2: Modify the proxy object;

[0028] S1.1.3: Set the address and port for the backend server;

[0029] S1.2: Deploy the backend of the attribute graph management system:

[0030] S1.2.1: Create a new folder, enter the new folder, and compile;

[0031] S1.2.2: Create configuration file;

[0032] S1.2.3: In the configuration file, set the IP address, service port, username, and password of the Slave node.

[0033] As a further preferred embodiment of the present invention, in step S3, when calculating the number of attribute pairs in the connected subgraph and using them as the cost of the connected subgraph, the calculation is performed according to the following formula:

[0034] ;

[0035] in,

[0036] This represents the total number of attribute pairs across all records of object o;

[0037] p represents a single attribute pair;

[0038] This represents all properties of object o.

[0039] As a further preferred embodiment of the present invention, in step S4, when calculating the benefit of each partition and the current connected subgraph, the calculation is performed according to the following formula:

[0040] ;

[0041] in,

[0042] benefit(lcc) i l F j ) indicates a partition With the i-th connected subgraph The benefits;

[0043] Represents the i-th connected subgraph The set of nodes in;

[0044] This represents the set of nodes in the j-th partition;

[0045] function This indicates that node n is in the partition. The number of times it appears in the text.

[0046] As a further preferred embodiment of the present invention, in step S7.1, each group of subqueries includes: a graph pattern query with a specified relation type and a variable-length path query.

[0047] As a further preferred embodiment of the present invention, in step S7.2, when generating the query plan,

[0048] S7.2.1: First, add the subquery with constants to the plan;

[0049] S7.2.2: Sort the remaining subqueries according to the number of intersections between the subqueries and the plan query, and add them to the plan in order according to the sorting results.

[0050] As a further preferred embodiment of the present invention, in step S8, when merging the returned partial results to form the final result, the subquery returns the matching result according to the query plan, performs a Join operation with the existing result, and iteratively performs Union and Join operations until the final subquery is executed to obtain the final graph pattern query result.

[0051] As a further preferred embodiment of the present invention, when performing a join operation on the first result and the second result, the following steps are included:

[0052] S8.1: First, create a hash table for each result of the second result;

[0053] S8.2: Each result of the first result is based on a hash table established by looking up common entities;

[0054] S8.3: Perform the corresponding operation based on the search results:

[0055] If the search is successful, the corresponding results will be merged, and a copy of the common entity will be retained.

[0056] If the search fails, the next result after the first result will be searched.

[0057] As a further preferred embodiment of the present invention, when performing a Union operation on the first result and the second result, the following steps are included: retaining each result of the first result and the second result, and removing duplicate results.

[0058] Compared with the prior art, the beneficial effects achieved by the present invention include:

[0059] 1) This invention provides a distributed attribute graph management system and its usage method, which can effectively improve the efficiency of attribute graph pattern query in a distributed environment.

[0060] 2) This invention provides a distributed attribute graph management system and its usage method. The system divides the attribute graph using connected subgraphs as basic units and calculates the number of attribute pairs in the connected subgraphs as the cost of the connected subgraphs. When performing the division, the system calculates the benefit of each partition with the current connected subgraph and allocates the connected subgraph to the partition with the largest benefit and still storage space. This keeps the load of each partition within an acceptable range and minimizes duplicate nodes. The threshold is reduced by subtracting the cost of the intersection, thereby constraining the load limit of each partition.

[0061] 3) This invention provides a distributed attribute graph management system and its usage method. Heuristically, subqueries with constant values ​​are added to the plan first, and then the remaining subqueries are added to the plan sequentially based on the number of intersections between the subqueries and the queries in the plan. This method reduces the number of intermediate results that do not affect the final result, thereby reducing unnecessary computation and communication costs. Attached Figure Description

[0062] Figure 1 This is an example diagram of a property graph in the prior art.

[0063] Figure 2 This is a schematic diagram illustrating an example of attribute graph pattern query in existing technologies.

[0064] Figure 3 This is a screenshot of the login interface of the attribute graph management system provided by the present invention.

[0065] Figure 4 A schematic diagram of the data storage module provided by this invention.

[0066] Figure 5 This is a schematic diagram of the page of the query processing module provided by the present invention.

[0067] Figure 6 This is an example schematic diagram of the partitioning attribute diagram provided by the present invention.

[0068] Figure 7 This is a schematic diagram illustrating a graph schema query example for a specified relation type provided by the present invention.

[0069] Figure 8 This is a schematic diagram illustrating a variable-length path query example of the present invention. Detailed Implementation

[0070] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0071] In the description of this invention, it should be noted that the terms "upper," "lower," "inner," "outer," "front end," "rear end," "both ends," "one end," and "the other end," etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are used only for the convenience of describing this invention and for simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on this invention. Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance.

[0072] In the description of this invention, it should be noted that, unless otherwise explicitly specified and limited, the terms "installed," "equipped with," "connected," etc., should be interpreted broadly. For example, "connection" can be a fixed connection, a detachable connection, or an integral connection; it can be a mechanical connection or an electrical connection; it can be a direct connection or an indirect connection through an intermediate medium; it can be a connection within two components. Those skilled in the art can understand the specific meaning of the above terms in this invention based on the specific circumstances.

[0073] [First Embodiment]

[0074] like Figure 3-5 The diagram shows a distributed attribute graph management system, referred to as DCG system (hereinafter the same), provided by the first embodiment of the present invention. It includes a graph database master node Master, a Cypher / Gremlin query statement q, and n graph database slave nodes.

[0075] like Figure 4-5 As shown, the system includes:

[0076] The data storage module loads the input attribute graph and performs distributed storage. The module takes the attribute graph as input, divides it into subgraphs based on relation types, and then further divides each subgraph into connected subgraphs. Connected subgraphs are used as the basic unit for partitioning the attribute graph. The number of attribute pairs in each connected subgraph is calculated as the cost of the connected subgraph. During partitioning, the benefit of each partition relative to the current connected subgraph is calculated, and the connected subgraph is allocated to the partition with the largest remaining storage space and the highest benefit.

[0077] In this embodiment, an attribute graph is divided into several partitions with non-intersecting edges. Edge-separated partitioning is used in many distributed attribute graph systems, which assigns each edge to a single partition.

[0078] In edge-disjoint partitioning, some points are copied within each partition. We call these copied points, and they are replicated across all partitions to ensure the integrity of the graph in each partition, such as... Figure 6 As shown.

[0079] as well as

[0080] The query processing module handles the input query. First, the input query is rewritten into a set of subqueries. A query plan is generated, initially adding subqueries with constants to the plan, then sorting the remaining subqueries in descending order based on the number of intersections between the subqueries and the planned query, and adding them to the query plan. Next, the subqueries are sent to all slave nodes and a graph-mode query is executed. Finally, the returned partial results are merged to obtain the final result.

[0081] [Second Embodiment]

[0082] The second embodiment of the present invention also provides a method for using a distributed attribute graph management system, comprising the following steps:

[0083] S1: Establish an attribute graph management system; specifically including the following steps:

[0084] S1.1: Deploying the front end of the attribute graph management system: including the following steps:

[0085] S1.1.1: Download and open the front-end package; S1.1.2: Modify the proxy object; S1.1.3: Set the address and port for the back-end server; Specifically, in this embodiment, the specific operations are as follows: The user can download the front-end package from GitHub and open it through vscode or webStorm; then, modify the proxy target in the vue.config.js file to set it to the address and port of the back-end deployment server; then, run npm run build:prod to package the files into the dist folder; the user can place the dist folder anywhere on the server and use nginx reverse proxy to complete the cross-domain deployment environment; finally, the user changes root in location / to the path where the dist folder is located, and modifies proxy_pass in location / api / to set the address and port of the back-end deployment server; thus, the user can access the DCG front-end by accessing the deployed address and port number;

[0086] S1.2: Deploying the backend of the attribute graph management system: including the following steps:

[0087] S1.2.1: Create a new folder, enter the new folder, and compile; S1.2.2: Create a configuration file; S1.2.3: In the configuration file, set the IP address, service port, username, and password of the Slave node; Specifically, in this embodiment, the specific operations are as follows: create a new folder named build, then enter this folder and use cmake to compile; To configure the Slave node in DCG, a configuration file named conf / servers.json is required; In this json file, the user can set the IP address of the Slave node, the port of the Neo4j HTTP service, the Neo4j username and password, etc.; After the user completes the configuration, the property graph management system can be run.

[0088] When using the property graph management system, users first enter the deployment address and port number in their browser to access the login page. The default username is "admin" and the default password is "111111". Figure 3 The image shows an example of a login interface. After logging in, the user is directed to the data storage module page, as shown below. Figure 4 As shown, this page is for managing databases. It displays the database name, the number of databases, a delete database button, and a add database button.

[0089] like Figure 5 As shown, on the query processing module page, users can enter a Cypher / Gremlin query, select the corresponding database, click the execute button to execute the query, and then obtain the results.

[0090] S2: Based on the relation type, the attribute graph is divided into several subgraphs, and then the subgraphs are further divided into several connected subgraphs; these weakly connected components obtained by partitioning based on a specific relation type are called LCCs, and LCCs are used as the basic unit of partitioning. Indicates based on relation type The i-th LCC obtained by partitioning.

[0091] Specifically, the key to the partitioning and query algorithms in this invention lies in maintaining the connectivity of relationships within the attribute graph. During the query process, regardless of whether the query is a variable-length path query or a graph-pattern query with a specified relationship type, each relationship in the query result will be interconnected through paths, and these relationships are all of the same type. If the query result spans different LCCs, then there must be at least one connection path of the same type between these LCCs; in this case, these LCCs are considered as the same LCC.

[0092] S3: Divide the attribute graph into units of connected subgraphs, calculate the number of attribute pairs in the connected subgraphs, and use them as the cost of the connected subgraphs.

[0093] In a property graph, both nodes and relationships have a certain number of attributes, using records. To represent the set of attributes in a node or relation, a new cost model based on the number of attribute pairs is defined to achieve a more reasonable load balance among partitions, i.e., to minimize the maximum number of attribute pairs in each partition. , represents the total number of attribute pairs across all records of an object o (which can be a subgraph or a partition). Specifically, this total is calculated by summing the number of attribute pairs in every record contained in object o. Therefore,

[0094] When calculating the number of attribute pairs in a connected subgraph and using it as the cost of the connected subgraph, the following formula is used:

[0095] ;

[0096] in,

[0097] This represents the total number of attribute pairs across all records of object o;

[0098] p represents a single attribute pair;

[0099] This represents all properties of object o.

[0100] S4: When performing partitioning, calculate the benefit of each partition to the current connected subgraph, and allocate the connected subgraph to the partition that still has storage space and the greatest benefit;

[0101] Partitioning based on LCCs can lead to some node duplication. To minimize this duplication, a new concept called benefit is introduced, defined as the benefit of the i-th node. and partitions The number of intersecting nodes;

[0102] Therefore, the profit of each partition to the current connected subgraph is calculated according to the following formula:

[0103] ;

[0104] in,

[0105] benefit(lcc) i l F j ) indicates a partition With the i-th connected subgraph The benefits;

[0106] Represents the i-th connected subgraph The set of nodes in;

[0107] This represents the set of nodes in the j-th partition;

[0108] function This indicates that node n is in the partition. The number of times it appears in the text.

[0109] To keep the load on each partition within an acceptable range and minimize duplicate nodes, a dynamically updated threshold is initially set when performing the partitioning. In the process of assigning each LCC to the partition with the highest return, the threshold is lowered by subtracting the cost of the intersection, thereby constraining the load limit of each partition. All LCCs of relational types are merged into a set C, sorted in descending order of LCC cost, and allocated to the partition with the highest return and still having storage space, provided that the cost does not exceed the partition threshold. For example... Figure 6 The image shows an example of a partitioned attribute graph.

[0110] For example, in Figure 1 In the given attribute graph example, by first dividing the graph into connected subgraphs based on the relation type "knows", two LCCs can be obtained: , Then, based on the relation type "isLocatedIn", the connected subgraph can be divided to obtain 4 LCCs: , , , Here, we assume that each Person node has 8 attributes, each Place node has 4 attributes, each knows relation has 1 attribute, and each isLocatedIn relation has 1 attribute. Therefore, the cost of each LCC is: , , , , , After sorting the LCCs in descending order of cost, partitioning begins. To prevent an imbalance in load calculation caused by a partition consistently having the highest benefit due to an early inclusion of LCCs, the first n LCCs are prioritized and placed into n partitions. Assuming n=2, the first partitioning... Place it in partition 1. Place it in partition 2. Then calculate. The returns from partition 1 and partition 2 can be obtained , Therefore, it should be Assign it to partition 2; similarly, it should be... and Assign it to partition 1, Assign it to partition 2, and you will get the following: Figure 6 The partitioning information is shown below;

[0111] S5: Store the database on the server; specifically, a server with Neo4j / JanusGraph installed is selected to facilitate subsequent database creation and querying;

[0112] S6: Create a database, specifying the database name and data storage path; each graph database node begins creating its database by writing Cypher / Gremlin statements;

[0113] S7: Perform a query based on the given query statement;

[0114] S7.1: The Master node decomposes the query statement into a set of subqueries; based on this query decomposition method, each set of subqueries can be classified as follows:

[0115] Graph schema queries specifying relation types; such as Figure 7 The image shows an example of a graph-pattern query with the label "isLocatedIn"; and

[0116] Variable-length path query; Variable-length path query is an important feature of graph database queries, allowing users to query all paths between a start and end point even when the length of the path between the start and end points is uncertain. Its characteristic is the label. This represents all paths in the attribute graph that connect the specified source node and the specified target node within a specified path length range. Indicates the minimum path length. Indicates the maximum path length. For example... Figure 8 The example shown is a variable-length path query with the label "knows", where the minimum path length is 1 and the maximum path length is 5.

[0117] S7.2: Generate a query plan; When generating a query plan, S7.2.1: First, add subqueries with constants to the plan; S7.2.2: Then sort the remaining subqueries according to the number of intersections between the subqueries and the plan query, and add them to the plan in order according to the sorting results. This method can reduce the number of intermediate results that do not affect the final result, thereby reducing unnecessary calculation and communication costs.

[0118] This is because different query methods can yield the same query results. In a specific embodiment, the graph database stores nodes of types such as Person, Comment, Post, and Tag. Person nodes and Comment nodes have a hasCreator relationship, Comment nodes and Post nodes have a replyOf relationship, and Post nodes and Tag nodes have a hasTag relationship. Querying the graph database for comments posted by a specified user's friends when they replied to posts, along with the tags of those replies, can be done in two ways: first, find the comments replied by the specified friend, then collect the comment's attribute ID to find the corresponding post, and then collect the post's attribute ID to find the corresponding tag; or, first, collect the tags for all posts, then query the comments that replied to those posts, and then match which comments were posted by the specified user's friends. Both query methods yield the same final result, but their execution efficiency and query cost differ. Therefore, it is necessary to process the input query statement to generate a suitable query plan.

[0119] S7.3: The Master node sends the subquery to all Slave nodes and executes the graph-pattern query;

[0120] S8: Merge the returned partial results to form the final result; In this embodiment, each partition is stored in an independent graph database system, which can execute subqueries independently and in parallel. When merging the returned partial results to form the final result, the subquery returns matching results according to the query plan. After performing a Join operation with the existing results, the Union and Join operations are executed iteratively until the final subquery is executed to obtain the final graph pattern query result.

[0121] Specifically, when performing a join operation on the first result and the second result, the following steps are included:

[0122] S8.1: First, create a hash table for each result of the second result;

[0123] S8.2: Each result of the first result is based on a hash table established by looking up common entities;

[0124] S8.3: Perform the corresponding operation based on the search results:

[0125] If the search is successful, the corresponding results will be merged, and a copy of the common entity will be retained.

[0126] If the search fails, the next result after the first result will be searched.

[0127] When performing a Union operation on the first and second results, the following steps are included: retain each result from both the first and second results and remove duplicate results.

[0128] It will be apparent to those skilled in the art that the present invention is not limited to the details of the exemplary embodiments described above, and that the invention can be implemented in other specific forms without departing from its spirit or essential characteristics. Therefore, the embodiments should be considered in all respects as exemplary and non-limiting, and the scope of the invention is defined by the appended claims rather than the foregoing description. Thus, all variations falling within the meaning and scope of equivalents of the claims are intended to be included within the present invention. No reference numerals in the claims should be construed as limiting the scope of the claims.

Claims

1. A method for using a distributed attribute graph management system, characterized in that: Includes the following steps: S1: Establish an attribute graph management system; S2: Divide the attribute graph into several subgraphs based on the relation type, and then divide the subgraphs into several connected subgraphs; S3: Divide the attribute graph into units of connected subgraphs, calculate the number of attribute pairs in the connected subgraphs, and use them as the cost of the connected subgraphs. S4: When performing partitioning, calculate the benefit of each partition to the current connected subgraph, and allocate the connected subgraph to the partition that still has storage space and the greatest benefit; S5: Store the database on the server; S6: Create a database, specifying the database name and the path for storing data; S7: Perform a query based on the given query statement; S7.1: Decompose the query statement into a set of subqueries; S7.2: Generate a query plan; S7.3: Send the subquery to all Slave nodes and execute the graph pattern query; S8: Merge the returned partial results to form the final result; In step S3, when calculating the number of attribute pairs in the connected subgraph and using them as the cost of the connected subgraph, the calculation is performed according to the following formula: ； in, This represents the total number of attribute pairs across all records of object o; p represents a single attribute pair; This represents all properties of object o; In step S4, the profit of each partition and the current connected subgraph is calculated according to the following formula: ； in, benefit(lcc) i l F j ) indicates a partition With the i-th connected subgraph The benefits; Represents the i-th connected subgraph The set of nodes in; This represents the set of nodes in the j-th partition; function This indicates that node n is in the partition. The number of times it appears in; In step S7.1, each group of subqueries includes: a graph schema query specifying the relation type and a variable-length path query; In step S7.2, when generating the query plan, S7.2.1: First, add the subquery with constants to the plan; S7.2.2: Sort the remaining subqueries according to the number of intersections between the subqueries and the plan query, and add them to the plan in order according to the sorting results; In step S8, when merging the returned partial results to form the final result, the subquery returns the matching result according to the query plan. After performing a Join operation with the existing results, the Union and Join operations are executed iteratively until the final subquery is executed to obtain the final graph pattern query result.

2. The method of using a distributed attribute graph management system according to claim 1, characterized in that: In step S1, the establishment of the attribute graph management system includes the following steps: S1.1: Deploy the front end of the attribute graph management system: S1.1.1: Download and open the front-end package; S1.1.2: Modify the proxy object; S1.1.3: Set the address and port for the backend server; S1.2: Deploy the backend of the attribute graph management system: S1.2.1: Create a new folder, enter the new folder, and compile; S1.2.2: Create configuration file; S1.2.3: In the configuration file, set the IP address, service port, username, and password of the Slave node.

3. The method of using a distributed attribute graph management system according to claim 1, characterized in that: When performing a join operation on result 1 and result 2, the following steps are included: S8.1: First, create a hash table for each result of the second result; S8.2: Each result of the first result is based on a hash table established by looking up common entities; S8.3: Perform the corresponding operation based on the search results: If the search is successful, the corresponding results will be merged, and a copy of the common entity will be retained. If the search fails, the next result after the first result will be searched.

4. The method of using a distributed attribute graph management system according to claim 1, characterized in that: When performing a union operation on the first and second results, the following steps are included: retain each result from both the first and second results and remove duplicate results.

5. A distributed attribute graph management system, employing the method of using a distributed attribute graph management system as described in any one of claims 1-4, characterized in that: The system includes: A data storage module receives an attribute graph as input. Based on relation types, the attribute graph is divided into several subgraphs, and each subgraph is further divided into several connected subgraphs. Connected subgraphs are used as the basic unit for partitioning the attribute graph. The number of attribute pairs in each connected subgraph is calculated as the cost of the connected subgraph. During partitioning, the benefit of each partition relative to the current connected subgraph is calculated, and the connected subgraph is allocated to the partition with the largest remaining storage space and the highest benefit. In the query processing module, the input query is first rewritten into a set of subqueries; a query plan is generated by first adding subqueries with constants to the plan, then sorting the remaining subqueries in descending order according to the number of intersections between the subqueries and the planned query, and adding them to the query plan; then the subqueries are sent to all slave nodes and the graph-mode query is executed; and the returned partial results are merged to form the final result.

Images