Graph database query method, electronic equipment and storage medium

Abstract

The invention discloses a graph database query method, electronic equipment and a storage medium, and the method comprises the steps: responding to a condition that a query condition in a query statement does not meet a preset index query requirement, and detecting an index structure of the query condition to obtain a detection result; in response to the detection result meeting the preset index structure requirement, performing reconstruction based on the query statement to obtain a fuzzy query index corresponding to an index layer in the graph database; and querying a storage layer of the graph database based on the fuzzy query index to obtain target graph data. According to the scheme, the data query efficiency of the graph database can be improved.

Description

Technical Field

[0001] This application relates to the field of graph database technology, and in particular to a graph database query method, electronic device, and storage medium. Background Technology

[0002] When using query statements to query or manipulate data in a graph database, if the query does not meet the requirements of a preset index, it directly scans the entire data in the storage layer of the graph database. Only after traversing all the data in the storage layer is the data requested by the query statement returned. This process is very time-consuming and inefficient. Therefore, there is an urgent need for a method that can avoid full scans or improve the performance of full table operations. Summary of the Invention

[0003] This application provides at least one graph database query method, electronic device, and storage medium, which can improve the data query efficiency of graph databases.

[0004] The first aspect of this application provides a graph database query method, which includes: in response to the query conditions in the query statement not meeting the preset index query requirements, detecting the index structure of the query conditions and obtaining the detection result; in response to the detection result meeting the preset index structure requirements, reconstructing the query statement based on the query statement to obtain the fuzzy query statement corresponding to the index layer in the graph database; and querying the storage layer of the graph database based on the fuzzy query statement to obtain the target graph data.

[0005] The process of reconstructing the query statement to obtain the fuzzy query statement corresponding to the index layer in the graph database includes: generating the index name to be queried based on the query parameters in the query statement; concatenating the wildcard with the index name to be queried to obtain the fuzzy query index; and converting the fuzzy query index to obtain the fuzzy query statement.

[0006] The query parameters include the graph data name and the label index name. Based on the query parameters in the query statement, the index name to be queried is generated by concatenating the graph data name and the label index name. The wildcard is then concatenated with the index name to be queried to obtain the fuzzy query index, which involves appending the wildcard to the label index name in the index name to obtain the fuzzy query index. This allows the wildcard to cover the index of the sub-region under the target label, where the target label is the label corresponding to the label index name.

[0007] The process involves examining the index structure of the query conditions to obtain the results. This includes parsing the query statement to obtain several query parameters in the query conditions, and checking whether the query parameters contain tag index names from the index layer.

[0008] The preset index structure requires that the detection results contain the tag index name in the index layer. After detecting whether the tag index name in the index layer exists in the query parameters and obtaining the detection result, the following steps are taken: in response to the detection result that the tag index name does not exist in the index layer, a full scan of the graph database is performed to obtain the target graph data corresponding to the query statement; or, in response to the detection result that the tag index name does not exist in the index layer, the system prompts an error.

[0009] The process of querying the graph database based on fuzzy query statements to obtain target graph data includes: determining the query category based on the fuzzy query statement, wherein the categories in the graph database include vertices and edges; obtaining several target category identifiers based on the query category; and querying the graph database based on the target category identifiers to obtain the target graph data.

[0010] Specifically, based on the query category, several target category identifiers are obtained, including: determining the target query statement based on the query category; querying the index layer using the target query statement to obtain several index query identifiers; and determining several target category identifiers corresponding to the storage layer in the graph database based on the index query identifiers.

[0011] The process includes: after querying the index layer using the target query statement to obtain several index query identifiers, the following steps are taken: filtering the index query identifiers to obtain several index filter identifiers, wherein the target attribute corresponding to the index filter identifier is not empty; converting the format of the index filter identifiers to obtain the target query identifier; determining several target category identifiers corresponding to the storage layer in the graph database based on the index query identifiers, including: determining several target category identifiers based on the target query identifiers; and after querying the storage layer of the graph database using the fuzzy query statement to obtain the target graph data, the following steps are taken: performing corresponding graph traversal calculations on the target graph data based on the operation information in the fuzzy query statement.

[0012] The second aspect of this application provides an electronic device including a memory and a processor coupled to each other, the processor being used to execute program instructions stored in the memory to implement the graph database query method of the first aspect described above.

[0013] A third aspect of this application provides a computer-readable storage medium having program instructions stored thereon, which, when executed by a processor, implement the graph database query method described in the first aspect above.

[0014] The above scheme first checks the query statement. If the query conditions in the query statement do not meet the preset index query requirements, the index structure of the query conditions is then checked to obtain the detection result. If the detection result meets the preset index structure requirements, the query statement is reconstructed to obtain a fuzzy query statement that meets the index layer requirements of the graph database. This fuzzy query statement is then used to query the storage layer of the graph database to obtain the target graph data. Compared to related technologies that directly scan the entire data in the storage layer when the query conditions in the query statement do not meet the preset index query requirements, this application reconstructs the query statement to obtain a fuzzy query statement that meets the index layer requirements, thereby improving the data query efficiency of the graph database.

[0015] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this application. Attached Figure Description

[0016] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with this application and, together with the specification, serve to explain the technical solutions of this application.

[0017] Figure 1 This is a flowchart illustrating an embodiment of the graph database query method of this application; Figure 2 This is a flowchart illustrating another embodiment of the graph database query method of this application; Figure 3 This is a flowchart illustrating yet another embodiment of the graph database query method of this application; Figure 4 This is a schematic diagram of the framework of an embodiment of the graph database query device of this application; Figure 5 This is a schematic diagram of the framework of an embodiment of the electronic device of this application; Figure 6 This is a schematic diagram of a framework of an embodiment of the computer-readable storage medium of this application. Detailed Implementation

[0018] The embodiments of this application will now be described in detail with reference to the accompanying drawings.

[0019] In the following description, specific details such as particular system architectures, interfaces, and technologies are presented for illustrative purposes rather than for limiting purposes, in order to provide a thorough understanding of this application.

[0020] In this document, the term "and / or" is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Additionally, the character " / " generally indicates that the preceding and following related objects have an "or" relationship. Furthermore, "many" in this document means two or more. Moreover, the term "at least one" in this document means any combination of at least two of any one or more of a plurality of objects. For example, including at least one of A, B, and C can mean including any one or more elements selected from the set consisting of A, B, and C.

[0021] Please see Figure 1 , Figure 1 This is a flowchart illustrating an embodiment of the graph database query method of this application. Specifically, it may include the following steps: Step S110: In response to the query conditions in the query statement not meeting the preset index query requirements, the index structure of the query conditions is checked, and the check results are obtained.

[0022] This application is primarily applied in the field of graph database technology, used for querying data in graph databases. When a query statement does not meet the requirements of a preset index query, a fuzzy query statement corresponding to the index layer in the graph database is generated, and then the fuzzy query statement is used for querying. Compared with related technologies, this application adopts a combination of direct index query and fuzzy query, avoiding a full scan of the data in the storage layer, thus improving the query efficiency of graph databases.

[0023] A graph database includes multiple graph datasets, each consisting of a graph structure composed of vertices, edges, properties, and labels. In this embodiment, JanusGraph can be used as the graph database. JanusGraph is an open-source, scalable, distributed graph database engine responsible for managing graph data models, graph queries, transaction management, and coordinating storage and indexing. Its distributed backend indexing and storage layers adopt an Elasticsearch+HBase architecture. Elasticsearch serves as the indexing layer in the graph database, responsible for creating indexes for properties and supporting complex queries (full-text search, fuzzy search, range search, etc.). HBase serves as the storage layer in the graph database, used to store massive amounts of graph data (vertices, edges, and properties).

[0024] In JanusGraph, Labels are the core metadata for organizing and categorizing graph elements (vertices and edges), defining the structural semantics of the graph data model. JanusGraph is developed based on the Tinkerpop framework and uses Gremlin as its query language. Gremlin is a path-oriented language used for graph operations and traversal (also known as a query language), a component of Tinkerpop. HBase is a distributed, column-oriented NoSQL database built on Hadoop HDFS, designed for handling massive amounts of data and high concurrency. In JanusGraph, it serves as the storage backend, storing all graph structure data (vertices, edges, attributes). Elasticsearch is a distributed, open-source search and analytics engine capable of quickly and in real-time storing, searching, and analyzing large amounts of data. In JanusGraph, it serves as the index backend, storing attribute values ​​and corresponding vertex IDs (Identity Documents), accelerating attribute queries.

[0025] In the JanusGraph graph database, Gremlin statements can be used as query statements. Gremlin statements specify the attributes of vertices or edges in the graph data (these attributes already have corresponding indexes in Elasticsearch) for indexing queries. For example, in an entity with the label name "student", to find all students (vertices) whose name attribute is 'Alice' and retrieve their appended (age) value, the Gremlin statement (corresponding query) would be: `gV().hasLabel('student').has('name', 'Alice').values('age')`. Then, using the index of the name attribute, a set of vertex IDs can be quickly retrieved from Elasticsearch, and the corresponding vertex data can be obtained from HBase, thus obtaining the target graph data.

[0026] It is understood that graph databases such as NebulaGraph and HugeGraph can also be used in other implementations, and no specific limitations are made here.

[0027] In one implementation, after the client initiates a query by submitting a query statement, the graph database performs syntax parsing and processing on the query statement to determine whether the query conditions in the query statement meet the preset index query requirements. Specifically, the preset index query requirements are that the query conditions include index attributes. If the query conditions include index attributes, the index layer is directly requested, and an index query is performed in the index layer. The set of vertex or edge identifiers that meet the query statement is returned to the storage layer. The storage layer obtains the corresponding target graph data set based on the set of vertex or edge identifiers. If the query conditions do not include index attributes, the query statement needs to be further tested. See steps S111 to S112.

[0028] Furthermore, there may be multiple graph data in the graph database. All indexes with the graph data name plus the label index name prefix store all index data for the corresponding Label. The index query identifier in the index value is generated when the graph data of the vertex / edge is inserted (a unique primary key, a random string generated according to the encryption algorithm), which corresponds to the rowKey (unique primary key, vertex / edge ID) of this graph data in HBase.

[0029] Step S111: Parse the query statement to obtain several query parameters in the query conditions.

[0030] In one implementation, the query statement is Gremlin. After JanusGraph's syntax parsing, it is determined that there is no label index name in the index layer. Then JanusGraph will further obtain and parse the query conditions in the query statement. The query parameters in the query conditions include graph data name, query object type, quantity, predicate type, label index name, transaction object, index object, etc.

[0031] Specifically, the label index name "student" is parsed from the Gremlin statement `gV().hasLabel('student')`, and then the Elasticsearch index cache is checked to see if the corresponding label index name exists. The index name format in Elasticsearch is typically graph data name + label index name - partition, such as `graph_student-*`. During the check, partition information is obtained using `graph.getSchemaCache().getMixedIndexPeriodMap().get(labelName)`.

[0032] Through the index structure detection mechanism, the system can efficiently identify whether a full table operation can use an index query, avoiding the high latency problem of HBase full scan, shortening operation time, and significantly improving performance.

[0033] Step S112: Check whether the tag index name in the index layer exists in the query parameters, and obtain the detection result.

[0034] In one implementation, the preset index structure requires that the detection results contain the label index name in the index layer. Upon obtaining the query parameters corresponding to the query statement, JanusGraph checks the query parameters to determine whether they include the label index name. If the detection result indicates that the label index name does not exist in the index layer, a full scan of the graph database is performed to obtain the target graph data corresponding to the query statement; alternatively, if the detection result indicates that the label index name does not exist in the index layer, the system displays an error message.

[0035] If the detection result indicates that the tag index name does not exist in the index layer, then proceed with the next steps.

[0036] In the JanusGraph graph database, for every label with an index, there is a one-to-one correspondence between its index data and the graph data. To accelerate queries, most labels have indexes created based on their attributes (i.e., attribute indexes), and these are uniformly stored under the same label index (for example, "student" represents the student entity. The student entity has many attributes, such as student ID, name, age, gender, hobbies, etc.; these attributes are created as indexes and uniformly stored under an index named "graph data name_student"). For these labels, as long as all the indexes under the label can be retrieved, the entire set of index query identifiers for the entire label can be obtained.

[0037] When the index structure corresponding to a label does not exist, this solution provides a compatible handling method through a full scan or error reporting, avoiding the problem of the system being unable to process query requests when the index is missing, and ensuring the availability of full table operations in the graph database. This mechanism integrates seamlessly with JanusGraph's existing architecture without additional hardware support. Furthermore, it flexibly selects the processing method based on configuration parameters, significantly reducing the query failure rate caused by improper index configuration, improving system stability and user experience. It allows users to complete necessary operations through a full scan even when the index has not been created or is misconfigured, avoiding system interruptions due to missing indexes.

[0038] Step S120: In response to the detection result meeting the preset index structure requirements, the index is reconstructed based on the query statement to obtain the fuzzy query index corresponding to the index layer in the graph database.

[0039] In one embodiment, when the detection result meets the preset index structure requirements, the query parameters in the query statement are used to reconstruct the index to obtain the fuzzy query index corresponding to the index layer in the graph database. Specifically, refer to steps S121 to S122.

[0040] Step S121: Generate the index name to be queried based on the query parameters in the query statement.

[0041] In one implementation, the graph data name and the label index name can be concatenated to obtain the index name to be queried. For example, if the graph data name is graph and the label index name is student, then the index to be queried will be graph_student.

[0042] Step S122: Concatenate the query string with the index name to be queried to obtain the fuzzy query index.

[0043] In one implementation, the query string is concatenated to the tag index name in the index name to be queried to obtain a fuzzy query index. This allows the query string to cover the indexes of sub-regions under the target tag, where the target tag is the tag corresponding to the tag index name. For example, if the index layer is ElasticSearch, which has fuzzy query capabilities and its fuzzy query syntax supports regular expression matching, then a wildcard (*) (i.e., the query string) can be used for querying. That is, any character sequence can be queried to obtain the entire index. The wildcard (*) is then used to replace all partition indexes under the tag index name to obtain the fuzzy query index. For example, in ElasticSearch, the fuzzy query index is graph_student-*, and * is used to cover all sub-region indexes under the target tag student.

[0044] Step S122: Transform the fuzzy query index to obtain the fuzzy query statement.

[0045] In one implementation, before performing a query using the fuzzy query index graph_student-*, the corresponding index query API (Application Programming Interface) in the graph database's storage layer can be called based on the fuzzy query index (i.e., graph.indexQuery("student", "*").vertexStream()), and then the fuzzy query index can be converted to obtain the ElasticSearch DSL (Domain-Specific Language) fuzzy query statement: POST https: / / {es_host}:{es_port} / graph_student-* / _search { "query": { "query_string": { "query": "*", "analyze_wildcard": true } }, "from": 0, "size": 10000 }

[0046] Here, * corresponds to the query parameter in the es DSL statement; es_host: the IP address (Internet Protocol address) of one of the nodes in the es cluster; es_port: the external port number of the es cluster; size: the number of indexes returned, which is determined by the ElasticSearch configuration and defaults to 10000.

[0047] In addition, when the number of indexes hit in a single index query is less than or equal to 10,000, the above query method (i.e., Elasticsearch DSL) can be used; when the number of indexes hit in a single index query is greater than SCAN_LIMIT (default 10,000), JanusGraph will use a Scroll query, generate a Scroll DSL statement, fetch data in batches (the number of data fetched in each batch is 1,000 by default, which can be freely configured), merge the results and return them; until data that meets the conditions is fetched.

[0048] When ElasticSearch executes this fuzzy query, it can call the index query API to query the storage layer of the graph database and obtain the target graph data.

[0049] An ElasticSearch DSL fuzzy query consists of a URL (such as https: / / {es_host}:{es_port} / graph_student-* / _search) and a request body (JSON).

[0050] It is understandable that, in addition to the methods mentioned above, other methods may also be used to transform fuzzy query indexes.

[0051] In this application, a large number of indexes under a Label can be partitioned based on time to improve index performance. For example, for a Label containing a large amount of data, the index is partitioned during index creation, with one partition created each week. After obtaining the partition attribute of the Label, the backend index engine leverages Elasticsearch's feature that allows index names to be used as query strings. If it determines that it is a partitioned index, it converts the partition part of the index name into a query string format, thus covering all partitioned indexes under the Label. For example, `graph_hasPersonSamePeer-20250035` would have 52 / 53 indexes in a year. To ensure that queries cover all partitioned indexes, it needs to be rewritten as `graph_hasPersonSamePeer-*`.

[0052] Step S130: Query the storage layer of the graph database based on the fuzzy query statement to obtain the target graph data.

[0053] In some implementations, after obtaining the fuzzy query statement, the fuzzy query statement can be used to query the storage layer of the graph database to obtain the target graph data. Specifically, refer to steps S131 to S133.

[0054] Step S131: Determine the query category based on the fuzzy query statement, where the categories in the graph database include vertices and edges.

[0055] In one implementation, because the query and return methods for vertices and edges in graph data are different, they need to be classified to determine the query category corresponding to the fuzzy query statement.

[0056] Step S132: Based on the query category, obtain several target category identifiers.

[0057] In one implementation, the graph database is JanusGraph. After determining the query category, the target query statement can be determined based on the query category. For example, if the query category is vertex, then the vertex query statement is used as the target query statement; if the query statement is edge, then the edge query statement is used as the target query statement. Next, the target query statement is used to query the index layer ElasticSearch to obtain several index query identifiers, which can be IDs, etc., without specific limitations. Based on the index query identifiers, several target category identifiers (i.e., rowKeys) corresponding to the storage layer HBase in the graph database are determined.

[0058] For example, Class 2 of Grade 11 has 20 boys and 15 girls. This can be used to generate a graph, with students and classes as vertices, gender as an attribute of the vertices, and edges representing the relationships between students and classes. The resulting fuzzy query is to retrieve the number of male students, thus defining the query category as the "student" vertex. Therefore, a vertex query is used to query the index layer ElasticSearch, obtaining the index identifiers for the 20 male students. Based on these 20 male student index identifiers, several target category identifiers are then determined for the corresponding storage layer HBase in the graph database.

[0059] To reduce the computational load in subsequent steps, several index query identifiers can be filtered to obtain several index filter identifiers. The target attribute corresponding to each index filter identifier must not be empty. These index filter identifiers are then formatted to obtain target query identifiers. Finally, based on the target query identifiers, several target category identifiers are determined.

[0060] By precisely filtering invalid data and performing format conversions, a full scan of HBase is avoided, significantly improving the performance of full table data processing from minutes to seconds compared to traditional methods. The transactional consistency mechanism of the index and stored data ensures that the filtering and conversion processes do not produce data inconsistencies, allowing clients to complete full table operations simply by submitting Gremlin statements, eliminating the need for frequent network interactions and greatly improving the efficiency and availability of graph databases in batch processing scenarios.

[0061] Step S133: Query the graph database based on the target category identifier to obtain the target graph data.

[0062] In one implementation, HBase uses the get(ids) statement to query the graph database to obtain vertex / edge graph data, and then returns the obtained data to JanusGraph.

[0063] Furthermore, after obtaining the target graph data, the corresponding graph traversal calculations can be performed on the target graph data based on the operation information in the query statement (such as reading, statistics, deletion, etc.).

[0064] For example, when the operation information is statistics, the system will count the acquired target category identifier set (such as vertex ID set or edge ID set); when the operation information is pagination, the system will return the target category identifier set in batches according to the specified batches; when the operation information is deletion, the system will perform the deletion operation. This processing method ensures that the target category identifier set can be directly used to execute specific business operations without additional data scanning or network interaction.

[0065] Please see Figure 2 , Figure 2This is a flowchart illustrating another embodiment of the graph database query method of this application. In this application scenario, JanusGraph is used as the graph database. After the user submits a Gremlin query statement on the client, JanusGraph parses its syntax to determine whether the query statement includes index attributes. If the query statement includes index attributes, it directly requests ElasticSearch to perform an index query to obtain the index query identifier that satisfies the query statement, and returns it to HBase. The storage layer obtains the corresponding target category identifier based on the index query identifier, and then queries JanusGraph using the target category identifier to obtain the target graph data set. Based on the operation information in the Gremlin query statement, it performs graph traversal calculations on the target graph data set. If the operation information is deletion, the target graph data set is deleted; if the operation information is statistics, the target graph data set is aggregated. The final data is then returned to the client.

[0066] If the Gremlin query does not include index attributes, JanusGraph will further retrieve and parse the query parameters, including the graph data name, query object type, quantity, predicate type, label index name, transaction object, and index object. It then determines whether the label index name in the Gremlin query is a label index name that exists in Elasticsearch. If not, it performs a full data scan of the graph data in HBase to obtain the target graph data.

[0067] If so, concatenate the graph data name and label index name in the query parameters to obtain the index name to be queried. Concatenate the query string with the index name to obtain the fuzzy query index. Then, transform the fuzzy query index to obtain the fuzzy query statement. Next, determine the query category based on the fuzzy query statement. If the query category is vertex, convert the fuzzy query statement into a vertex query statement, perform an index query in Elasticsearch to obtain the vertex index query identifiers, and then filter them to obtain the vertex index filter identifier set. If the query category is edge, convert the fuzzy query statement into an edge query statement, perform an index query in Elasticsearch to obtain the edge index query identifiers, and then filter them to obtain the edge index filter identifier set. Finally, transform the obtained index query identifier set to obtain the target query identifier set conforming to the JanusGraph format.

[0068] JanusGraph sends a set of target query identifiers to HBase. HBase determines the target category identifiers it caches based on these identifiers. Then, it queries JanusGraph based on these target category identifiers to obtain the target graph data.

[0069] Please see Figure 3 , Figure 3 This is a flowchart illustrating another embodiment of the graph database query method of this application. Specifically, it may include the following steps: Step S310: In response to the query statement not meeting the preset index query requirements, the index structure of the query statement is checked and the check result is obtained.

[0070] This step is the same as step S110 above, so it will not be described again here.

[0071] Step S320: In response to the detection result meeting the preset index structure requirements, the query statement is reconstructed to obtain the fuzzy query statement corresponding to the index layer in the graph database.

[0072] This step is the same as step S120 above, so it will not be described again here.

[0073] Step S330: Perform format detection on the fuzzy query statement and obtain the format detection result.

[0074] Step S340: Use a fuzzy query statement whose format detection results meet the preset requirements to query the storage layer of the graph database to obtain the target graph data.

[0075] In one implementation, the obtained fuzzy query statement is derived from the query parameters in the query statement. The correctness of the fuzzy query statement directly affects the correctness of the obtained target graph data. Therefore, after obtaining the fuzzy query statement, its format and syntax need to be checked. Only if the format and syntax of the fuzzy query statement are correct will it be used to query the storage layer of the graph database to obtain the target graph data.

[0076] In this application, the query statement is inspected. If the query statement does not meet the preset index query requirements, the index structure of the query statement is inspected to obtain the inspection result. If the inspection result meets the preset index structure requirements, the query statement is reconstructed to obtain a fuzzy query statement that meets the index layer requirements of the graph database. This fuzzy query statement is then used to query the storage layer of the graph database to obtain the target graph data. Compared to related technologies, which directly scan the full data in the storage layer when the query statement does not meet the preset index query requirements, this application reconstructs the query statement to obtain a fuzzy query statement that meets the index layer requirements, thereby improving the data query efficiency of the graph database.

[0077] Furthermore, this application cleverly combines JanusGraph's support for direct index queries with ElasticSearch's support for fuzzy queries and query strings, applying them to the full table operation processing flow. This enables Gremlin's full table scan operation to obtain the graph data ID set by using index queries, thereby significantly improving the performance of full table operations in the JanusGraph graph database.

[0078] Furthermore, this application is developed and implemented on the existing architecture. It utilizes indexes to delete all data in the table, thereby avoiding the performance impact of deleting tombstones and eliminating the need for additional hardware costs. Moreover, in this application, the client only needs to submit Gremlin statements to complete full table operations on the graph database, without requiring frequent network interactions with the database server.

[0079] Those skilled in the art will understand that, in the above-described method of the specific implementation, the order in which each step is written does not imply a strict execution order and does not constitute any limitation on the implementation process. The specific execution order of each step should be determined by its function and possible internal logic.

[0080] Please see Figure 4 , Figure 4 This is a schematic diagram of the framework of an embodiment of the graph database query device 400 of this application. The graph database query device 400 includes a detection module 410, a reconstruction module 420, and a query module 430. The detection module 410 performs an operation to detect the index structure of the query statement if the query statement does not meet the preset index query requirements, and obtains a detection result. The reconstruction module 420 performs an operation to reconstruct the index structure based on the query statement if the detection result meets the preset index structure requirements, and obtains the fuzzy query statement corresponding to the index layer in the graph database. The query module 430 performs a query on the storage layer of the graph database based on the fuzzy query statement to obtain the target graph data.

[0081] In one embodiment, the reconstruction module 420 performs reconstruction based on the query statement to obtain the fuzzy query statement corresponding to the index layer in the graph database, including: generating the index name to be queried based on the query parameters in the query statement; concatenating the query string with the index name to be queried to obtain the fuzzy query index; and converting the fuzzy query index to obtain the fuzzy query statement.

[0082] In one embodiment, the reconstruction module 420 executes query parameters including the graph data name and the label index name, and generates a query index name based on the query parameters in the query statement, including: concatenating the graph data name and the label index name to obtain the query index name; concatenating the query string with the query index name to obtain a fuzzy query index, including: concatenating the query string to the label index name in the query index name to obtain a fuzzy query index, so as to use the query string to cover the index of the sub-region under the target label, wherein the target label is the label corresponding to the label index name.

[0083] In one embodiment, the detection module 410 performs detection on the index structure of the query statement and obtains the detection result, including: parsing the query statement to obtain several query parameters in the query statement; detecting whether there are tag index names in the index layer in the query parameters and obtaining the detection result.

[0084] In one embodiment, the detection module 410 performs a preset index structure requirement that the detection result contains a tag index name in the index layer. After detecting whether the query parameters contain a tag index name in the index layer and obtaining the detection result, it includes: in response to the detection result that the tag index name does not exist in the index layer, performing a full scan of the graph database to obtain the target graph data corresponding to the query statement; or, in response to the detection result that the tag index name does not exist in the index layer, the system prompts an error.

[0085] In one embodiment, the query module 430 performs a query on the graph database based on a fuzzy query statement to obtain target graph data, including: determining a query category based on the fuzzy query statement, wherein the categories in the graph database include vertices and edges; obtaining several target category identifiers based on the query category; and querying the graph database based on the target category identifiers to obtain the target graph data.

[0086] In one embodiment, the query module 430 performs a process of obtaining several target category identifiers based on the query category, including: determining a target query statement based on the query category; querying the index layer using the target query statement to obtain several index query identifiers; and determining several target category identifiers corresponding to the storage layer in the graph database based on the index query identifiers.

[0087] In one embodiment, the query module 430 performs the following steps after querying the index layer using a target query statement to obtain several index query identifiers: filtering the several index query identifiers to obtain several index filter identifiers, wherein the target attribute corresponding to the index filter identifier is not empty; converting the format of the several index filter identifiers to obtain target query identifiers; determining several target category identifiers corresponding to the storage layer in the graph database based on the index query identifiers, including: determining several target category identifiers based on the target query identifiers; and after querying the storage layer of the graph database using a fuzzy query statement to obtain target graph data, the following steps are performed: performing corresponding graph traversal calculations on the target graph data based on the operation information in the fuzzy query statement.

[0088] Please see Figure 5 , Figure 5 This is a schematic diagram of an embodiment of the electronic device 50 of this application. The electronic device 50 includes a memory 51 and a processor 52 coupled to each other. The processor 52 is used to execute program instructions stored in the memory 51 to implement the steps in any of the above-described embodiments of the graph database query method. In a specific implementation scenario, the electronic device 50 may include, but is not limited to, a microcomputer or a server. In addition, the electronic device 50 may also include mobile devices such as laptops and tablets, which are not limited here.

[0089] Specifically, processor 52 controls itself and memory 51 to implement the steps in any of the above-described graph database query method embodiments. Processor 52 can also be referred to as a CPU (Central Processing Unit). Processor 52 may be an integrated circuit chip with signal processing capabilities. Processor 52 can also be a general-purpose processor, digital signal processor (DSP), application-specific integrated circuit (ASIC), field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. A general-purpose processor can be a microprocessor or any conventional processor. Furthermore, processor 52 can be implemented using integrated circuit chips.

[0090] Please see Figure 6 , Figure 6 This is a schematic diagram of a framework of an embodiment of the computer-readable storage medium 60 of this application. The computer-readable storage medium 60 stores program instructions 601 that can be executed by a processor. The program instructions 601 are used to implement the steps in any of the above-described embodiments of the graph database query method.

[0091] In some embodiments, the functions or modules of the apparatus provided in this disclosure can be used to perform the methods described in the above method embodiments. The specific implementation can be referred to the description of the above method embodiments, and for the sake of brevity, it will not be repeated here.

[0092] The description of the various embodiments above tends to emphasize the differences between the various embodiments. The similarities or similarities between them can be referred to, and for the sake of brevity, they will not be repeated here.

[0093] In the several embodiments provided in this application, it should be understood that the disclosed methods and apparatus can be implemented in other ways. For example, the apparatus implementations described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection of devices or units may be electrical, mechanical, or other forms.

[0094] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0095] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute all or part of the steps of the methods of various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

Claims

1. A graph database query method, characterized in that, include: In response to the query conditions in the query statement not meeting the preset index query requirements, the index structure of the query conditions is checked to obtain the detection result; In response to the detection result satisfying the preset index structure requirements, the query statement is reconstructed to obtain the fuzzy query statement corresponding to the index layer in the graph database; The target graph data is obtained by querying the storage layer of the graph database based on the fuzzy query statement.

2. The method according to claim 1, characterized in that, The process of reconstructing the query statement to obtain the fuzzy query statement corresponding to the index layer in the graph database includes: Based on the query parameters in the query statement, generate the index name to be queried; The query string is concatenated with the name of the index to be queried to obtain the fuzzy query index; The fuzzy query index is transformed to obtain the fuzzy query statement.

3. The method according to claim 2, characterized in that, The query parameters include the graph data name and the label index name. Generating the index name to be queried based on the query parameters in the query statement includes: The image data name and the label index name are concatenated to obtain the index name to be queried; The step of concatenating the query string with the index name to be queried to obtain the fuzzy query index includes: The query string is concatenated to the tag index name in the index name to be queried to obtain the fuzzy query index, so as to cover the index of the sub-region under the target tag using the query string, wherein the target tag is the tag corresponding to the tag index name.

4. The method according to claim 1, characterized in that, The process of detecting the index structure of the query conditions and obtaining the detection results includes: The query statement is parsed to obtain several query parameters in the query conditions; The presence of the tag index name in the index layer is checked in the query parameters to obtain the detection result.

5. The method according to claim 4, characterized in that, The preset index structure requires that the detection result contains the tag index name in the index layer. After detecting whether the tag index name in the index layer exists in the query parameters and obtaining the detection result, the process includes: In response to the detection result indicating that the tag index name does not exist in the index layer, a full scan of the graph database is performed to obtain the target graph data corresponding to the query statement; or, In response to the detection result indicating that the tag index name does not exist in the index layer, the system prompts an error.

6. The method according to claim 1, characterized in that, The process of querying the graph database based on the fuzzy query statement to obtain the target graph data includes: Based on the fuzzy query statement, the query category is determined, wherein the categories in the graph database include vertices and edges; Based on the query category, several target category identifiers are obtained; The target graph data is obtained by querying the graph database based on the target category identifier.

7. The method according to claim 6, characterized in that, Based on the query category, several target category identifiers are obtained, including: Based on the query category, determine the target query statement; The index layer is queried using the target query statement to obtain several index query identifiers; Based on the index query identifier, determine the several target category identifiers corresponding to the storage layer in the graph database.

8. The method according to claim 7, characterized in that, After querying the index layer using the target query statement to obtain several index query identifiers, the process includes: The index query identifiers are filtered to obtain a number of index filter identifiers, wherein the target attribute corresponding to the index filter identifier is not empty; The format of the aforementioned index filtering identifiers is converted to obtain the target query identifier; The step of determining the plurality of target category identifiers corresponding to the storage layer in the graph database based on the index query identifier includes: Based on the target query identifier, determine the plurality of target category identifiers; After querying the storage layer of the graph database based on the fuzzy query statement to obtain the target graph data, the process includes: Based on the operation information in the fuzzy query statement, the target graph data is subjected to corresponding graph traversal calculations.

9. An electronic device, characterized in that, The system includes a memory and a processor coupled to each other, the processor being configured to execute program instructions stored in the memory to implement the graph database query method according to any one of claims 1 to 8.

10. A computer-readable storage medium having program instructions stored thereon, characterized in that, When the program instructions are executed by the processor, they implement the graph database query method according to any one of claims 1 to 8.

Images