A large-scale entity relation visual query method based on multi-dimension index

Abstract

The application provides a large-scale entity relationship visual query method based on multi-dimensional index, and belongs to the field of data engineering.The method inserts blockchain data into a graph database according to a storage paradigm of blockchain transaction entities and their relationships, and constructs an incremental information index for the inserted blockchain data; a field-based index, a tree structure index and a subgraph index are constructed; a query mechanism based on multi-dimensional index is constructed, a user's query request is accepted and query conditions are parsed, and corresponding index modes are selected for query according to the parsed query conditions.The application significantly improves the efficiency of large-scale data storage and query, enhances the flexibility and accuracy of data retrieval, and reduces the threshold of data analysis by using a visual tool, so that non-professionals can easily analyze large-scale blockchain transaction data.

Description

TECHNICAL FIELD

[0001] The present application belongs to the field of data engineering, and particularly relates to a large-scale entity relationship visual query method based on multi-dimensional index. BACKGROUND

[0002] With the rapid development of blockchain technology, its application in the fields of finance, supply chain, Internet of Things, etc. is becoming increasingly widespread. The data in the blockchain ecosystem is complex and diverse, usually with 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, these data have complex and large-scale characteristics, which bring great challenges to the storage, management and analysis of data.

[0003] Traditional data storage and query methods have difficulties in handling such large-scale blockchain transaction data. First, although traditional relational databases perform well in storing structured data, they often struggle to effectively express the rich relationships between entities in the face of the complexity and diversity of blockchain data; second, the increasing size of blockchain transaction data also affects the query efficiency of data, 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 associations of data, making it difficult to reveal the underlying relationships of data.

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

[0005] To address the problems of low query efficiency and poor data display effect of large-scale transaction data in the blockchain ecosystem, the present application proposes a large-scale entity relationship visual query method and system based on multi-dimensional index, which maps large-scale transaction data in the blockchain ecosystem to a graph database by designing an entity and its relationship storage paradigm, constructs a multi-dimensional index mechanism of incremental information index, tree structure index, and subgraph index, and can quickly obtain effective information from large-scale blockchain transaction data, and display data information using graph visualization technology.

[0006] To achieve the above purpose, the present application adopts the following technical solution: the present application provides a large-scale entity relationship visual query method based on multi-dimensional index, which includes the following steps:

[0007] 1) According to the blockchain data format, a storage paradigm is formulated, which is used to store the blockchain data in a unified data structure in a graph database; 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, wherein the basic layer stores historical data, and the incremental layer stores recently updated data or dynamic data being processed; when inserting the 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;

[0009] 3) Inside the basic layer and the incremental layer, field-based indexes, tree structure indexes and subgraph indexes are constructed for the stored data;

[0010] 4) A multi-dimensional index-based query mechanism is constructed; the multi-dimensional index-based query mechanism accepts a user's query request and parses the query conditions, selects a corresponding index mode for querying according to the parsed query conditions, and visually presents the query results, realizing the query of large-scale entity data in the blockchain ecology.

[0011] The present application proposes a large-scale entity relationship visual query method based on multi-dimensional indexing, which maps large-scale transaction data in the blockchain ecology to a graph database by designing an entity and its relationship storage paradigm, constructs a variety of index structures, and realizes an efficient data query mode, which not only has good practical value, but also has good reference significance.

[0012] The present application improves the storage and query efficiency of large-scale data, and optimizes the data retrieval process. The present application enhances the flexibility and accuracy of data retrieval through multi-dimensional indexing technology. The use of the visualization tool of the present application reduces the threshold of data analysis, so that non-professionals can also understand and analyze blockchain data. BRIEF DESCRIPTION OF DRAWINGS

[0013] Figure 1 The present application is a large-scale entity relationship query flowchart based on multi-dimensional indexing;

[0014] Figure 2 The present application is a large-scale entity relationship visual tool framework diagram. DETAILED DESCRIPTION

[0015] The present application will be further described and explained in conjunction with the specific embodiments. The embodiments are only exemplary and do not circumscribe the scope of the disclosure. The technical features of each embodiment in the present application can be combined accordingly without conflict.

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

[0017] Step one: develop a storage paradigm.

[0018] For the data format of blockchain ecological entities and relationships, the application designs a corresponding storage paradigm, allowing data of different sources and types to be stored in a unified data structure in a graph database. This storage paradigm divides data into transaction account entities and transaction relationship entities, ensuring data consistency and retrievability, while reducing storage overhead while ensuring data uniqueness. Specifically, in some embodiments, a corresponding transaction account entity data storage paradigm and a transaction relationship entity data storage paradigm are developed, as shown in Tables 1 and 2.

[0019] Table 1: Design of transaction account entity data storage paradigm

[0020]

[0021] Table 2: Design of transaction relationship entity data storage paradigm

[0022]

[0023]

[0024] The above-mentioned storage paradigm designed by the application has the following characteristics:

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

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

[0027] Storage overhead minimization: minimize storage overhead without affecting data usage.

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

[0029] Step two: develop a graph structure, insert data, and construct an incremental index; according to the format and usage requirements of blockchain transaction data, while maximizing the advantages of a graph database, the application uses transaction account entities as nodes in the graph structure, transaction relationship entities as edges in the graph structure, and the direction of the edge to represent the flow direction of funds, allowing multiple edges between nodes, and a single edge representing only a single transaction.

[0030] In the graph database, a single transaction account entity is uniquely identified by an account ID; different types of account information are stored according to the same attribute name, thereby ensuring data consistency. For different transactions between two accounts, the application uses a multi-edge method for processing, and is uniquely identified by a transaction ID; for different types of transactions, the same attribute name is used for storage, thereby ensuring data consistency. Specifically, for transaction account entity data, ND_ID is specified as the primary index key, which uniquely identifies a transaction account; for different types of account information such as digital renminbi and enterprise data, the same attribute is used to store the respective data, and the data type is distinguished by LABEL.

[0031] For transaction relationship entity data, ED_ID is specified as the primary index key, which uniquely identifies a transaction; for different types of transactions such as digital renminbi and enterprise data, the same attribute is used to store the respective data, and the data type is distinguished by LABEL; for a single transaction, the direction of the edge is indicated by FROM and TO.

[0032] Considering the efficiency requirements of storage and query, in some embodiments of the application, 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 the data inserted into the graph database, based on the attributes of different data entities and common retrieval requirements, the application constructs an incremental information index to record the changes in data attributes in the form of increments. The incremental information index specifically includes:

[0034] (1) Data change monitoring: real-time monitoring of data changes in the graph database, including addition, deletion, modification and other operations, through database triggers and log files and other tools.

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

[0036] (3) Index generation: using the graph database language to generate the index of the agreed attribute according to the content of the change log. The spatial distribution characteristics of the subgraph are used for data sampling, the topological characteristics such as degree centrality and node density in the subgraph are calculated to form a feature vector, and the incremental information of the graph data is constructed based on the feature vector. The incremental index internally constructs a tree structure index, a subgraph index and a field index.

[0037] (4) Index update: call the API of the graph database 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 periodically merged with the base layer (including field-based indexes, tree indexes, and subgraph indexes) to ensure that both historical and up-to-date data can be quickly accessed; further build secondary indexes, for transaction relationship entity retrieval, build secondary indexes based on transaction account entity incremental information and transaction relationship entity incremental information, allowing quick positioning of related transactions through transaction accounts.

[0038] In some embodiments of the application, 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 updates the incremental information index of the incremental layer. The incremental layer is stored in the form of memory residence or temporary table to ensure quick query response; when a query request arrives, the system first checks the incremental information index in the incremental layer, and if the query does not hit, it accesses the base layer;

[0040] 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 incremental information index of the base layer is updated and the incremental information index of the incremental layer.

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

[0042] The application constructs an incremental information index for blockchain data inserted into a graph database, and builds multi-dimensional indexes within the incremental information index, including field attribute-based index mode, tree structure index, and subgraph index.

[0043] a. Field attribute-based index mode. Used for fast and accurate query of a single field. Specifically including:

[0044] Indexing the key attributes of data in the graph database to speed up node lookup and filtering, including node account ID, type; indexing the key attributes of edges in the graph database to support attribute-based filtering and association, including transaction ID, transaction account, type of the edge.

[0045] b. Tree structure index construction. Incremental index provides detailed information on data changes for tree structure index construction, and uses B-tree or other tree structure index technology of the graph database to build efficient index structure for account entity retrieval, supporting fast data positioning and retrieval.

[0046] The tree structure index construction specifically includes:

[0047] The B+ tree is selected as the tree structure for managing the incremental information index in the graph database.

[0048] Each node of the B+ tree stores a plurality of key values, and the node size matches the disk block size, ensuring maximum efficiency when reading data from the disk each time. The non-leaf nodes of the B+ tree only store keys, and do not store data. All data is stored in the leaf nodes of the B+ tree, and the leaf nodes are connected through a linked list.

[0049] When inserting a new index into the tree structure index, the index is inserted in order into the leaf nodes of the B+ tree. If the leaf node is full, it is split and the middle key value is promoted to the parent node, maintaining the balance of the tree. When deleting an index, the balance of the tree is maintained through merging or rotating operations. When updating an index, the key value in the corresponding leaf node is directly updated.

[0050] c. Subgraph index construction. Based on the spatial distribution characteristics and topological characteristics of subgraphs, a subgraph index is constructed based on the existing tree structure index to support fast subgraph retrieval. Graph mining techniques are used to calculate features such as degree centrality and node density 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 a plurality of subgraphs, and high-frequency query subgraphs are generated according to query history frequency. Each subgraph is stored as a tree, and the entry node of the subgraph is indexed using a hash index. When querying, the entry node is first located, and then the nodes and relationships within the subgraph are quickly traversed.

[0052] In addition, commonly used subgraphs are cached in memory to improve query speed, and smaller and high-frequency query subgraphs are preferentially cached. When the incremental index of the graph database is updated, the related subgraph index is updated, and the incremental update method is used to handle only the local update of the affected subgraph.

[0053] In this embodiment, new data is inserted through the following cypher command, and the data only includes the numerical value of the primary index key for simplicity:

[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, keep the consistency of the data, retrieve the graph database before insertion, merge the same transaction account node, for the account, the state at any time will not affect the account ID; do not merge the transaction edge between two accounts, for the transaction, different transactions are not determined by the account of the transaction, but by the transaction ID unique identification.

[0064] After inserting data, new indexes need to be added and added to the index directory of the incremental layer. For the index mode based on field attributes, the following cypher command can be simply used:

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

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

[0067] For tree structure index, the tree structure needs to be maintained on the basis of the above, that is, if the number of nodes exceeds the maximum degree, split the node and adjust the tree. When storing, no additional operation is needed.

[0068] For subgraph index, the subgraph model needs to be precalculated on the above cypher command, such as u2 and u3 exist 2 transactions, the subgraph formed by u2, u3 and the transaction between them can be stored.

[0069] Step four: query data, return results by integrating three index methods.

[0070] As Figure 1 shown, the present application constructs a multi-dimensional index-based query mechanism, taking incremental information index as the top-level architecture, integrating three different index methods, and selecting different index modes according to the characteristics and advantages of the three indexes to effectively support the query of large-scale entity data in the blockchain ecological system, which specifically includes:

[0071] (A) Query analysis:

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

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

[0074] (B) Cost estimation:

[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 size, index structure, storage distribution, data access frequency, and other information. The cost model includes the following aspects:

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

[0078] CPU cost: calculate the processing resources required for query execution, such as filtering, sorting, merging, and other operations.

[0079] Memory cost: estimate the memory consumption required for data caching and index loading during query.

[0080] (b) Cost model formula:

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

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

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

[0084] (C) Index Selection

[0085] (a) Query Type-based Index Selection:

[0086] Field Attribute-based Retrieval Patterns are suitable for:

[0087] Fast Attribute Match Query: Requires fast retrieval of data based on a single attribute.

[0088] Exact Attribute Match: Query that performs an exact match on a specific attribute.

[0089] Data Condition Filtering: Filters data based on a specific attribute.

[0090] Tree Index Structure is suitable for:

[0091] Hierarchical Data: Facilitates processing of data with hierarchical structure.

[0092] Hierarchical Relationship Query: Finds the parent node, child node, or hierarchical relationship of a node.

[0093] Subgraph Index is suitable for:

[0094] Complex Graph Structure Query: Queries neighbor nodes of a specific node, nodes of neighbor nodes, etc., suitable for tasks that require exploration of graph structure.

[0095] Local Subgraph Operation: Analyzes or operates on 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 the cost of a certain index is low (e.g., minimum I / O overhead), that index is selected to execute the query.

[0099] (D) Query Path Optimization

[0100] (a) Multi-index Combination Optimization:

[0101] For complex queries, multiple indexes may need to be combined for querying. For example, when a query involves both frequently updated data and time sorting, the index selector may first filter out the latest data through the incremental index, and then use the tree structure index for sorting.

[0102] (b) Parallelized Query:

[0103] If the query can be executed in parallel (e.g., looking up in multiple indexes simultaneously), the query path optimizer will execute the query in multiple indexes simultaneously and then combine the results. For example, subgraph index queries of a graph database can be executed in parallel on different subgraphs.

[0104] Suppose we need to query transaction account entities that have indirect transaction relationships with a given transaction account entity, the subgraph index pattern is preferred to be invoked, the example cypher command is:

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

[0106] RETURN friendOfFriend;

[0107] friend is a transaction account entity that has a direct transaction relationship with the given transaction account entity, and friendOfFriend is a transaction account entity that has an indirect transaction relationship with the given transaction account entity.

[0108] Step five: Visualize the query structure.

[0109] As shown in Figure 2 , in some embodiments of the present application, the visualization of step five is performed with the help of visualization tools, and large-scale entity relationship visualization tools mainly include four modules:

[0110] Data display module: provides an interactive user interface that allows 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.

[0111] Interactive query module: allows users to build and execute multidimensional queries through a graphical interface without writing 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, allowing users to see changes in query results in real time and make corresponding adjustments.

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

[0113] Graph exploration module: special for exploration and analysis of graph data, support highlight of node and edge, path tracking and subgraph zoom; implement graph layout algorithm, such as force-directed layout and circular layout, to optimize the visual presentation of graph; support interactive operation of graph data, such as node expansion, contraction and path exploration.

[0114] The above-described embodiments are merely representative of several embodiments of the present application, and the description is more specific and detailed, but it should not be understood as limiting the scope of the patent of the present application. For those skilled in the art, without departing from the concept of the present application, a number of modifications and improvements can be made, which are within the scope of protection of the present application.

Claims

1. A method for visualizing and querying large-scale entity relationships based on multi-dimensional indexing, characterized in that, Includes the following steps: 1) Based on the blockchain data format, a storage paradigm is established, which is used to store blockchain data in a graph database with a unified data structure; wherein, the blockchain data is divided into transaction account entities and transaction relationship entities; 2) Divide the graph database into a basic layer and an incremental layer. The basic layer stores historical data, while the incremental layer stores the most recently updated data or dynamic data being processed. When inserting blockchain data into the graph database, insert the data into the incremental layer according to the storage paradigm. Construct an incremental information index to manage the blockchain data in the graph database. Building an incremental information index to manage blockchain data in the graph database specifically includes: Incremental information indexes are constructed for blockchain data in the base layer and incremental layer respectively. The base layer index is not updated frequently, while the incremental layer index grows and changes continuously and is periodically 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 simultaneously. 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 find the index, it then accesses the basic layer. When the data in the incremental layer reaches a certain scale, the data in the incremental layer is merged into the base layer, and the base layer index and the incremental layer index are updated. 3) Within the base layer and incremental layer, construct field-based indexes, tree-structured indexes, and subgraph indexes for the stored data; 4) Construct a query mechanism based on multi-dimensional indexes; the query mechanism based on multi-dimensional indexes accepts user query requests and parses query conditions, selects the corresponding index mode for querying according to the parsed query conditions, and presents the query results in a visual format, thereby enabling the querying of large-scale entity data in the blockchain ecosystem.

2. The method for large-scale entity relationship visualization query based on multi-dimensional indexing according to claim 1, characterized in that, In step 1), the transaction account entity includes basic information about the accounts participating in the transaction, and the transaction relationship entity includes detailed transaction information; In a graph database, transaction account entities are treated as nodes in the graph, and transaction relationship entities are treated as directed edges between nodes. The connection state and direction of the edges represent the transactions between nodes. For a single trading account entity, it is uniquely identified only by the account ID; for different types of trading account entities, they are stored according to the same attribute name to ensure data consistency. For different transactions between two transaction account entities, i.e. different transaction relationship entities, a multi-edge approach is used to represent them and they are uniquely identified by transaction IDs. For transaction relationship entities of different types, they are stored with the same attribute name to ensure data consistency.

3. The method for large-scale entity relationship visualization query based on multi-dimensional indexing according to claim 1, characterized in that, Step 3) describes constructing a field-based index, specifically as follows: Indexes are created for key attributes of data in the graph database to accelerate node lookup and filtering. These key attributes include the node's account ID and type. Indexes are also created for key attributes of edges in the graph database to support filtering and association based on attribute conditions. These key attributes include the edge's transaction ID, transaction account, and type.

4. The method for large-scale entity relationship visualization query based on multi-dimensional indexing according to claim 1, characterized in that, Step 3) describes constructing a tree-structured index, specifically as follows: A B+ tree is chosen as the tree structure for the incremental information index in the management graph database; Each node in a B+ tree stores multiple key-value pairs, and the node size matches the disk block size to ensure maximum efficiency each time data is read from the disk; non-leaf nodes in a 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-structured index, the index is inserted sequentially into the leaf nodes of the B+ tree; if a leaf node is full, it is split and the intermediate key value is promoted to the parent node to maintain the balance of the tree; 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 updated directly.

5. The method for large-scale entity relationship visualization query based on multi-dimensional indexing according to claim 1, characterized in that, The construction of the subgraph index in step 3) specifically involves: The graph formed by the data in the graph database is divided into several subgraphs. High-frequency query subgraphs are generated based on the query history frequency. Each subgraph is stored as a tree. The entry node of the subgraph is indexed using a hash index. When querying, the entry node is located first, 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 subgraphs with high frequency of queries are cached first. When the graph database's incremental index is updated, the relevant subgraph index is updated, and the update is handled by incremental update, so only the affected subgraphs are locally updated.

6. The method for large-scale entity relationship visualization query based on multi-dimensional indexing according to claim 1, characterized in that, Step 4) describes a query mechanism based on multi-dimensional indexes, which includes four modules: Query analyzer: Used to parse query statements and determine the query type; B. Cost estimation module: Calculates the cost of executing this query using different indexes; C. Index Scheduler: Based on the parsing results of the query analyzer and the calculation results of the cost estimation module, it determines which index to use, or to use multiple indexes simultaneously; D. Query Path Optimizer: Responsible for selecting the optimal path from multiple possible query paths and optimizing it.

7. The method for large-scale entity relationship visualization query based on multi-dimensional indexing according to claim 6, characterized in that, The index scheduler adopts a field attribute-based retrieval mode to meet the needs of fast attribute matching queries that require quick retrieval of data based on a single attribute, queries that perform precise matching of specific attributes, or data filtering based on specific attributes. For queries that look up the parent node, child node, or hierarchical relationship of a node, a tree index structure is used. For tasks involving querying the neighboring nodes of a specific node, querying the graph structure of neighboring nodes, and performing local subgraph operations, a subgraph index is used.

8. The method for large-scale entity relationship visualization query based on multi-dimensional indexing according to claim 1, characterized in that, Step 4) The query returns a set of nodes and edges, and the query results are presented in a visual way.

Images