Large-scale entity relationship visual query method based on multi-dimensional index

Abstract

The invention provides a large-scale entity relationship visual query method based on a multi-dimensional index, and belongs to the field of data engineering. The method comprises the following steps: designing a storage normal form of a block chain transaction entity and a relationship thereof, inserting block chain data into a graph database according to the storage normal form, and constructing an incremental information index for the inserted block chain data; constructing a field-based index, a tree structure index and a sub-graph index; and constructing a query mechanism based on a multi-dimensional index, receiving a query request of a user, analyzing a query condition, and selecting a corresponding index mode for query according to the analyzed query condition. According to the method, the efficiency of large-scale data storage and query is remarkably improved through a multi-dimensional index technology, the flexibility and accuracy of data retrieval are enhanced, and the threshold of data analysis is reduced by utilizing a visual tool, so that non-professionals can also easily analyze large-scale block chain transaction data.

Description

Technical Field

[0001] The present invention belongs to the field of data engineering, and in particular relates to a large-scale entity relationship visualization query method based on multi-dimensional indexing. Background Art

[0002] With the rapid development of blockchain technology, its applications in finance, supply chain, Internet of Things and other fields are becoming more and more extensive. The data in the blockchain ecosystem is complex and diverse, and usually has a large scale. Each blockchain transaction generates a large amount of data, which contains rich entity relationship information, such as account information, transaction information, etc. However, the complex and large-scale characteristics of these data bring huge challenges to data storage, management and analysis.

[0003] Traditional data storage and query methods have difficulties in processing such large-scale blockchain transaction data. First, although traditional relational databases perform well in storing structured data, they often find it difficult to effectively express the rich relationships between entities in the face of the complexity and diversity of blockchain data; second, the increasing scale of blockchain transaction data has also had a certain impact on the efficiency of data queries, making it difficult for users to quickly and accurately obtain the required information; in addition, traditional query methods often lack the ability to mine deep-level data associations and find it difficult to reveal the inherent associations behind the data.

[0004] Traditional technologies also face challenges in data display. For large-scale blockchain transaction data, it is difficult to intuitively reflect the overall picture and deep-level connections of the data if it is only displayed in the form of tables or simple graphics. When analyzing data, users often need to switch between different data views and query results, which is not only inefficient but also difficult to meet the needs of in-depth analysis. Summary of the invention

[0005] In response to the problems of low query efficiency and poor data display effect of large-scale transaction data in the blockchain ecosystem, the present invention proposes a large-scale entity relationship visualization query method and system based on multi-dimensional indexing. By designing the storage paradigm of entities and their relationships, large-scale transaction data in the blockchain ecosystem are mapped to a graph database, and a multi-dimensional indexing mechanism of incremental information index, tree structure index, and subgraph index is constructed. It can quickly obtain effective information from large-scale blockchain transaction data and use graph visualization technology to display data information.

[0006] In order to achieve the above object, the present invention adopts the following technical solution: The present invention provides a large-scale entity relationship visualization query method based on multi-dimensional index, which comprises the following steps:

[0007] 1) According to the blockchain data format, a storage paradigm is formulated, which is used to store blockchain data in a graph database in a unified data structure; wherein the blockchain data is divided into transaction account entities and transaction relationship entities;

[0008] 2) The graph database is divided into a basic layer and an incremental layer, where the basic layer stores historical data and the incremental layer stores recently updated data or dynamic data being processed; when inserting blockchain data into the graph database, insert data into the incremental layer according to the storage paradigm; construct an incremental information index to manage the blockchain data in the graph database;

[0009] 3) In the base layer and incremental layer, field-based indexes, tree structure indexes, and subgraph indexes are built for the stored data;

[0010] 4) Constructing a query mechanism based on multi-dimensional indexes; the query mechanism based on multi-dimensional indexes accepts the user's query request and parses the query conditions, selects the corresponding index mode for query according to the parsed query conditions, and visualizes the query results to realize the query of large-scale entity data in the blockchain ecosystem.

[0011] The present invention proposes a large-scale entity relationship visualization query method based on multi-dimensional indexing. This method maps large-scale transaction data in the blockchain ecosystem into a graph database by designing a storage paradigm for entities and their relationships, constructs a variety of index structures, and realizes an efficient data query mode. It not only has good practical value, but also has great reference significance.

[0012] The present invention improves the storage and query efficiency of large-scale data and optimizes the data retrieval process. The present invention enhances the flexibility and accuracy of data retrieval through multi-dimensional indexing technology. The use of the visualization tool of the present invention lowers the threshold of data analysis, allowing non-professionals to understand and analyze blockchain data. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] Figure 1 This is a flowchart of a large-scale entity relationship query based on multi-dimensional indexing according to the present invention;

[0014] Figure 2 This is a framework diagram of the large-scale entity relationship visualization tool of the present invention. DETAILED DESCRIPTION

[0015] The present invention is further described and illustrated below in conjunction with specific embodiments. The embodiments are merely exemplary of the present disclosure and do not define the scope of limitation. The technical features of each embodiment of the present invention may be combined accordingly without conflicting with each other.

[0016] The large-scale entity relationship query method based on multi-dimensional indexing of the present invention has a specific process that can be divided into five parts: (1) formulating a storage paradigm; (2) formulating a graph structure, inserting data, and building an incremental index; (3) building an index based on field attributes, a tree structure index, and a subgraph index; (4) querying data, calling different indexes to return results; (5) calling a visualization tool to present the query results. The details of each part are as follows:

[0017] Step 1: Develop a storage paradigm.

[0018] The present invention designs a corresponding storage paradigm for blockchain ecological entities and relational data formats, allowing data from different sources and types to be stored in a graph database with a unified data structure. The storage paradigm divides data into transaction account entities and transaction relationship entities to ensure data consistency and retrievability, while reducing storage overhead while ensuring data uniqueness. Specifically, in some embodiments, corresponding transaction account entity data storage paradigms and transaction relationship entity data storage paradigms are formulated, as shown in Table 1 and Table 2.

[0019] Table 1 Transaction account entity data storage paradigm design

[0020]

[0021] Table 2 Transaction relationship entity data storage paradigm design

[0022]

[0023]

[0024] The above storage paradigm designed by the present invention has the following characteristics:

[0025] Uniformity: Allows data from different sources and types to be stored in the graph database in a unified data structure.

[0026] Consistency: Ensure data consistency during storage and retrieval.

[0027] Minimize storage overhead: Reduce storage overhead as much as possible without affecting data usage.

[0028] Retrievability: facilitates subsequent index creation and query.

[0029] Step 2: Formulate a graph structure, insert data, and build an incremental index; According to the format and usage requirements of blockchain transaction data, while giving full play to the advantages of the graph database as much as possible, the present invention uses transaction account entities as nodes in the graph structure, and transaction relationship entities as edges in the graph structure. The direction of the edge represents the flow direction of funds, and multiple edges are allowed between nodes. A single edge only represents a single transaction.

[0030] In the graph database, for a single transaction account entity, only the account ID is used for unique identification; for different types of account information, they are stored according to the same attribute name to ensure data consistency. For different transactions between two accounts, the present invention uses multiple edges to process them and uniquely identifies them through the transaction ID; for different types of transactions, they are stored according to the same attribute name to ensure data consistency. Specifically, for transaction account entity data, ND_ID is specified as the primary index key to uniquely identify a transaction account; for different types of account information such as Bitcoin, digital RMB, and corporate data, the same attributes are used to store their respective data, and LABEL is used to distinguish data types.

[0031] For transaction relationship entity data, ED_ID is specified as the primary index key to uniquely identify a transaction; for different types of transactions such as Bitcoin, digital RMB, and corporate data, the same attributes are used to store their respective data, and LABEL is used to distinguish data types; for a single transaction, FROM and TO are used to indicate the direction of the edge.

[0032] Considering the efficiency requirements of storage and query, in some embodiments of the present invention, the graph database is divided into a basic layer and an incremental layer, wherein the basic layer stores historical data and the incremental layer stores recently updated data or dynamic data being processed. When inserting blockchain data into the graph database, the data is inserted into the incremental layer according to the storage paradigm; an incremental information index is constructed to manage the blockchain data in the graph database.

[0033] For data inserted into a graph database, the present invention constructs an incremental information index based on the attributes of different data entities and common retrieval requirements, and records the changes in data attributes in an incremental form. The incremental information index specifically includes:

[0034] (1) Data change monitoring: Use tools such as database triggers and log files to monitor data changes in the graph database in real time, including operations such as addition, deletion, and modification.

[0035] (2) Change log record: records the monitored data changes, including the type of data change (i.e., addition, deletion, or modification), the name of the changed field, the changed value, the time of occurrence, and other information.

[0036] (3) Index generation: Use the graph database language to generate an index of agreed attributes based on the content of the change log. Data is sampled based on the spatial distribution characteristics of the subgraph, and topological features such as degree centrality and node density in the subgraph are calculated to form a feature vector, which is then used to construct incremental information of the graph data. The incremental index internally constructs a tree structure index, a subgraph index, and a field index.

[0037] (4) Index update: Call the graph database API to insert the generated index entries into the incremental index structure of the graph database. Newly inserted or updated data first enters the incremental layer and is regularly merged with the base layer (including field-based indexes, tree indexes, and subgraph indexes) to ensure that both historical data and the latest data can be quickly accessed; further construct secondary indexes. For the retrieval of transaction relationship entities, construct secondary indexes based on the incremental information of transaction account entities and the incremental information of transaction relationship entities, allowing the relevant transaction relationships to be quickly located through transaction accounts.

[0038] In some embodiments of the present invention, the incremental information index of the base layer is not frequently updated, while the incremental information index of the incremental layer is constantly growing and changing, and is periodically merged with the incremental information index of the base layer;

[0039] Each time data is inserted or updated, the data first enters the incremental layer and the incremental information index of the incremental layer is updated. The incremental layer is stored in memory or in a temporary table to ensure fast query response. When a query request arrives, the system first checks the incremental information index in the incremental layer. If the query does not hit, it accesses the basic layer.

[0040] When the data of the incremental layer reaches a certain size, the data of the incremental layer is merged into the base layer, and the incremental information index of the base layer and the incremental information index of the incremental layer are updated.

[0041] Step 3: In the base layer and incremental layer, build field attribute-based indexes, tree structure indexes, and subgraph indexes for the stored data.

[0042] The present invention constructs an incremental information index for blockchain data inserted into a graph database, and constructs a multi-dimensional index inside the incremental information index. The multi-dimensional index mainly includes an index mode based on field attributes, a tree structure index, and a subgraph index.

[0043] a. Index mode based on field attributes. Used for fast and accurate query of a single field. Specifically includes:

[0044] Create indexes for the key attributes of data in the graph database to speed up node search and filtering. The key attributes include the account ID and type of the node. Create indexes for the key attributes of the edges in the graph database to support filtering and association by attribute conditions. The key attributes of the edges include the transaction ID, transaction account number, and type of the edge.

[0045] b. Tree structure index construction. Incremental indexes are used to provide detailed information about data changes for the construction of tree structure indexes. B-tree or other tree structure indexing technologies of graph databases are used to build efficient index structures for the retrieval of account entities, supporting fast data location and retrieval.

[0046] Tree structure index construction, including:

[0047] Select B+ tree as the tree structure for managing incremental information index in graph database;

[0048] Each B+ tree node stores multiple key values, and the node size matches the disk block size to ensure maximum efficiency every time data is read from the disk; non-leaf nodes of the B+ tree only store keys, not data; all data is stored in the leaf nodes of the B+ tree, and the leaf nodes are connected by linked lists;

[0049] When inserting a new index into a tree structure index, the index is inserted into the leaf nodes of the B+ tree in sequence; if the leaf node is full, it is split and the intermediate key value is promoted to the parent node to keep the tree balanced; when deleting an index, the balance of the tree is maintained through merge or rotation operations; when updating an index, the key value in the corresponding leaf node is directly updated.

[0050] c. Subgraph index construction. Based on the existing tree structure index, the subgraph index is constructed based on the spatial distribution characteristics and topological characteristics of the subgraph to support fast subgraph retrieval. The graph mining technology is used to calculate the degree centrality, node density and other characteristics of the subgraph to form a feature vector for subgraph index construction. Subgraph index construction specifically includes:

[0051] The graph formed by the data in the graph database is divided into several subgraphs, and the subgraphs with high frequency queries are generated according to the historical query frequency; each subgraph is stored as a tree, and the entry nodes of the subgraph are indexed using a hash index. When querying, the entry node is first located, and then the nodes and relationships in the subgraph are quickly traversed;

[0052] In addition, frequently used subgraphs are cached in memory to improve query speed, and smaller and more frequently queried subgraphs are cached first. When the incremental index of the graph database is updated, the relevant subgraph indexes are updated and processed through incremental updates, and only the affected subgraphs are partially updated.

[0053] In this embodiment, new data is inserted through the following cypher command. To simplify the description, the data only includes the value of the primary index key:

[0054] CREATE(:User{ND_Id:'u1'});

[0055] CREATE(:User{ND_Id:'u2'});

[0056] CREATE(:User{ND_Id:'u3'});

[0057] MATCH(u1:User{ND_Id:'u1'}),(u2:User{ND_Id:'u2'})

[0058] CREATE(u1)-[:TRANSACTION{ED_ID:'t1'}]->(u2);

[0059] MATCH(u2:User{ND_Id:'u2'}),(u3:User{ND_Id:'u3'})

[0060] CREATE(u2)-[:TRANSACTION{ED_ID:'t2'}]->(u3);

[0061] MATCH(u1:User{ND_Id:'u1'}),(u3:User{ND_Id:'u3'})

[0062] CREATE(u1)-[:TRANSACTION{ED_ID:'t3'}]->(u3);

[0063] In the process of inserting data, the consistency of the data is maintained. The graph database is searched before insertion, and the same transaction account nodes are merged. For an account, the status at any time will not affect the account ID; the transaction edges between two accounts are not merged. For transactions, different transactions are not determined by the transaction account, but are uniquely identified by the transaction ID.

[0064] After inserting data, you need to create a new index and add it to the index directory of the incremental layer. For the index mode based on field attributes, you can simply use the following cypher command:

[0065] CREATE INDEX ON:User(ND_Id);

[0066] CREATE INDEX ON:Transaction(ED_Id);

[0067] For tree structure indexes, the tree structure needs to be maintained on the basis of the above, that is, if the number of nodes exceeds the maximum degree, the nodes are split and the tree is adjusted. No additional operations are required during storage.

[0068] For subgraph indexes, it is necessary to pre-calculate the subgraph model on the above cypher command. For example, if there are two transactions between u2 and u3, the subgraph formed by u2, u3 and the transactions between them can be stored.

[0069] Step 4: Query data and return results by combining the three indexing methods.

[0070] like Figure 1 As shown in the figure, the present invention constructs a query mechanism based on multi-dimensional indexing, takes incremental information indexing as the top-level architecture, integrates three different indexing methods, and selects different indexing modes for different query tasks according to the characteristics and advantages of the three indexes, so as to effectively support the query of large-scale entity data in the blockchain ecosystem, specifically including:

[0071] (A) Query analysis:

[0072] The query analyzer receives and parses the query request, identifying whether the query is a single-key search, range search, graph query, or complex multi-condition query.

[0073] For different queries, identify the corresponding fields or query conditions. For example, the query "find records with ID 123" is a single key query, the query "find records with IDs between 100-200" is a range query, and the query "find the shortest path between two nodes" is a graph query.

[0074] (B) Cost Estimate:

[0075] (a) Analyze data volume and index cost:

[0076] The cost estimation module calculates the query cost of each index based on the existing data scale, index structure, storage distribution, data access frequency and other information. The cost model includes the following aspects:

[0077] I / O cost: Estimates the I / O cost of accessing storage devices such as disks or SSDs.

[0078] CPU cost: Calculates the processing resources required to execute the query, such as filtering, sorting, merging, and other operations.

[0079] Memory cost: Estimates the memory consumption of data cache and index loading required during the query.

[0080] (b) Cost model formula:

[0081] Assume that the parameters involved in the cost estimation include: C I / O represents the I / O cost, C CPU Indicates the CPU cost, C mem represents the memory cost. Then, the total cost of the index selector to calculate each index is:

[0082] C total =ω1·C I / O +ω2·C CPU +ω3·C mem

[0083] ω1, ω2, and ω3 are the weights of each cost, which depends on the hardware environment of the query executor and user requirements. The total cost is calculated for each index type, and the index path with the lowest cost is selected.

[0084] (C) Index selection

[0085] (a) Index selection based on query type:

[0086] The search mode based on field attributes is applicable to:

[0087] Fast attribute matching query: Need to quickly retrieve data based on a single attribute.

[0088] Exact attribute match: A query that performs an exact match on a specific attribute.

[0089] Data condition filtering: Filter data based on specific attributes.

[0090] The tree index structure is suitable for:

[0091] Hierarchical data: It is convenient to process data with hierarchical structure.

[0092] Hierarchical relationship query: Find the parent node, child node or hierarchical relationship of a node.

[0093] Subgraph indexes are available for:

[0094] Complex graph structure query: query the neighbor nodes of a specific node, the nodes of neighbor nodes, etc., which is suitable for tasks that require exploring the graph structure.

[0095] Local subgraph operations: Analyze or manipulate graph subgraphs.

[0096] (b) Cost model driven selection:

[0097] The index scheduler selects the index structure with the lowest cost based on the cost results fed back by the cost estimation module.

[0098] If a particular index has a lower cost (eg, has the lowest I / O overhead), then that index is selected to execute the query.

[0099] (D) Query path optimization

[0100] (a) Multi-index combination optimization:

[0101] For complex queries, you may need to combine multiple indexes. For example, when the query involves frequently updated data and needs to be sorted by time, the index selector may first filter out the latest data through the incremental index, and then use the tree structure index to sort.

[0102] (b) Parallel query:

[0103] If the query can be executed in parallel (such as searching in multiple indexes at the same time), the query path optimizer will execute the query in multiple indexes at the same time and then merge the results. For example, subgraph index queries of a graph database can be executed in parallel on different subgraphs.

[0104] In a specific embodiment of the present invention, assuming that all transactions in Bitcoin are to be queried, the retrieval mode based on field attributes is preferentially called, and the example cypher command is:

[0105] MATCH(u:Transaction)WHERE u.LABEL="btc" RETURN u;

[0106] u is a transaction in which the currency is Bitcoin.

[0107] Assuming that you need to query all companies controlled by a given company, you should first call the tree index structure. The example cyp her command is: MATCH(c:Company{ND_ID:'Company A'})-[:CONTROLS]->(controlledCompany)

[0108] RETURN c, controlledCompany;

[0109] c is a given enterprise, and controlledCompany is all enterprises controlled by c.

[0110] Assuming that you need to query the trading account entities that have an indirect trading relationship with a given trading account entity, you should first call the subgraph index mode. The sample cypher command is:

[0111] MATCH(u:User{ND_ID:'u1'})-[t:TRANSACTION]->(friend)-[t2:TRANSACTION]->(friendOfFriend)

[0112] RETURN friendOfFriend;

[0113] friend is a trading account entity that directly trades with a trading account entity, and friendOfFriend is a trading account entity that has an indirect trading relationship with a given trading account entity.

[0114] Step 5: Visualize the query structure.

[0115] like Figure 2As shown, in some embodiments of the present invention, step 5 is visualized with the help of a visualization tool, and the large-scale entity relationship visualization tool mainly includes four modules:

[0116] Data display module: provides an interactive user interface that enables users to intuitively view complex data stored in the graph database; supports multiple data views, such as table view, graph view, and time series view, to meet the needs of different users; implements dynamic data loading and rendering technology to ensure good performance even when the data volume is large.

[0117] Interactive query module: allows users to build and execute multi-dimensional queries through a graphical interface without having to write complex query statements; provides a query builder that allows users to build queries by dragging and dropping components, selecting fields, and setting conditions; supports real-time query feedback, so users can instantly see changes in query results and make corresponding adjustments.

[0118] Data analysis module: Integrates advanced data analysis algorithms, such as cluster analysis, association rule mining, and predictive analysis, to help users discover patterns and trends behind the data; provides data summary and statistical functions to quickly generate key indicators and reports.

[0119] Graph Exploration Module: It is specially used for exploring and analyzing graph data, and supports highlighting of nodes and edges, path tracing, and subgraph zooming. It implements graph layout algorithms, such as force-directed layout and circular layout, to optimize the visualization of graphs. It supports interactive operations on graph data, such as node expansion, contraction, and path exploration.

[0120] The above-mentioned embodiments only express several implementation methods of the present invention, and the description is relatively specific and detailed, but it cannot be understood as limiting the scope of the present invention. For ordinary technicians in this field, several modifications and improvements can be made without departing from the concept of the present invention, which all belong to the protection scope of the present invention.

Claims

1. A large-scale entity relationship visualization query method based on multi-dimensional indexing, characterized in that: The following steps are involved: 1) According to the blockchain data format, a storage paradigm is formulated, which is used to store blockchain data in a graph database in a unified data structure; wherein the blockchain data is divided into transaction account entities and transaction relationship entities; 2) The graph database is divided into a basic layer and an incremental layer, where the basic layer stores historical data and the incremental layer stores recently updated data or dynamic data being processed; when inserting blockchain data into the graph database, insert data into the incremental layer according to the storage paradigm; construct an incremental information index to manage the blockchain data in the graph database; 3) In the base layer and incremental layer, field-based indexes, tree structure indexes, and subgraph indexes are built for the stored data; 4) Constructing a query mechanism based on multi-dimensional indexes; the query mechanism based on multi-dimensional indexes accepts the user's query request and parses the query conditions, selects the corresponding index mode for query according to the parsed query conditions, and visualizes the query results to realize the query of large-scale entity data in the blockchain ecosystem.

2. The large-scale entity relationship visual query method based on multi-dimensional indexing according to claim 1 is characterized in that: In step 1), the transaction account entity includes basic information of the account involved in the transaction, and the transaction relationship entity includes detailed information of the transaction; In the graph database, the transaction account entity is regarded as the node in the graph, and the transaction relationship entity is regarded as the directed edge between the nodes in the graph. The transaction between the nodes is represented by the connection state and direction of the edge. For a single trading account entity, only the account ID is used for unique identification; for different types of trading account entities, they are stored according to the same attribute name to ensure data consistency; Different transactions between two transaction account entities, that is, different transaction relationship entities, are represented using multiple edges and uniquely identified by transaction IDs; different types of transaction relationship entities are stored using the same attribute name to ensure data consistency.

3. The large-scale entity relationship visual query method based on multi-dimensional indexing according to claim 2 is characterized in that: In step 2), an incremental information index is constructed to manage the blockchain data in the graph database, specifically including: Construct incremental information indexes for blockchain data in the base layer and incremental layer respectively. The base layer index is not updated frequently, while the incremental layer index is constantly growing and changing, and is regularly merged with the base layer index. Each time data is inserted or updated, the data first enters the incremental layer and the incremental layer index is updated at the same time. The incremental layer is stored in memory or in a temporary table to ensure fast query response. When a query request arrives, the system first checks the index in the incremental layer. If the query does not hit, it accesses the base layer. When the data in the incremental layer reaches a certain size, the data in the incremental layer is merged into the base layer, and the base layer index and the incremental layer index are updated.

4. The large-scale entity relationship visual query method based on multi-dimensional indexing according to claim 1 is characterized in that: The construction of the field-based index in step 3) is as follows: Create indexes for the key attributes of data in the graph database to speed up node search and filtering. The key attributes include the account ID and type of the node. Create indexes for the key attributes of the edges in the graph database to support filtering and association by attribute conditions. The key attributes of the edges include the transaction ID, transaction account number, and type of the edge.

5. The large-scale entity relationship visual query method based on multi-dimensional indexing according to claim 1 is characterized in that: The tree structure index constructed in step 3) is specifically as follows: Select B+ tree as the tree structure for managing incremental information index in graph database; Each B+ tree node stores multiple key values, and the node size matches the disk block size to ensure maximum efficiency every time data is read from the disk; non-leaf nodes of the B+ tree only store keys, not data; all data is stored in the leaf nodes of the B+ tree, and the leaf nodes are connected by linked lists; When inserting a new index into a tree structure index, the index is inserted into the leaf nodes of the B+ tree in sequence; if the leaf node is full, it is split and the intermediate key value is promoted to the parent node to keep the tree balanced; when deleting an index, the balance of the tree is maintained through merge or rotation operations; when updating an index, the key value in the corresponding leaf node is directly updated.

6. The large-scale entity relationship visual query method based on multi-dimensional indexing according to claim 1 is characterized in that: The subgraph index is constructed as described in step 3), specifically: The graph formed by the data in the graph database is divided into several subgraphs, and the subgraphs with high frequency queries are generated according to the historical query frequency; each subgraph is stored as a tree, and the entry nodes of the subgraph are indexed using a hash index. When querying, the entry node is first located, and then the nodes and relationships in the subgraph are quickly traversed; In addition, frequently used subgraphs are cached in memory to improve query speed, and smaller and more frequently queried subgraphs are cached first. When the incremental index of the graph database is updated, the relevant subgraph indexes are updated and processed through incremental updates, and only the affected subgraphs are partially updated.

7. The large-scale entity relationship visual query method based on multi-dimensional indexing according to claim 1 is characterized in that: Step 4) The query mechanism based on multi-dimensional index includes four modules: Query analyzer: used to parse query statements and determine query types; B. Cost estimation module: calculates the cost of different indexes when executing the query; C. Index scheduler: decides which index to use, or uses multiple indexes at the same time, based on the parsing results of the query analyzer and the calculation results of the cost estimation module; D. Query path optimizer: responsible for selecting the optimal path among multiple possible query paths and performing optimization on it.

8. The large-scale entity relationship visual query method based on multi-dimensional indexing according to claim 7 is characterized in that: The index scheduler adopts a retrieval mode based on field attributes for fast attribute matching queries that need to quickly retrieve data based on a single attribute, queries that accurately match specific attributes, or filters data based on specific attributes; To find the parent node, child node or hierarchical relationship of a node, a tree index structure is used; Subgraph indexing is used to query the neighbor nodes of a specific node, the graph structure query tasks of neighbor nodes, and local subgraph operations.

9. The large-scale entity relationship visual query method based on multi-dimensional indexing according to claim 1 is characterized in that: Step 4) The data returned by the query is a collection of nodes and edges, and the query results are presented in a visual way.

Images