Frequency class graph query method and related devices, electronic equipment and storage media

Abstract

This application discloses a frequency class graph query method and related apparatus, electronic device, and storage medium. The frequency class graph query method includes: setting a frequency field for each relation edge in a knowledge graph based on the entities at both ends of the relation edge; creating a first information database in the index backend based on the frequency field of the relation edge in the knowledge graph; wherein the first information database includes at least the frequency field of the relation edge in the knowledge graph and the index name; responding to a frequency class query request, constructing a frequency class query statement based on the frequency class query request, assembling a query instruction suitable for the index backend based on the frequency class query statement, and querying the first information database based on the query instruction to obtain the frequency query result. This solution can improve the efficiency of frequency class graph queries.

Description

Technical Field

[0001] This application relates to the field of knowledge graph technology, and in particular to a frequency class graph query method and related devices, electronic devices and storage media. Background Technology

[0002] Knowledge graphs typically contain various static and dynamic nodes as well as static and dynamic relationships. Due to their rich content and knowledge structure, they have been applied in more and more fields.

[0003] Currently, knowledge graphs have achieved significant performance advantages in relational queries. However, frequency-based queries (such as searching for people who stayed at a hotel more than N times during a specific month and year) remain a weakness of knowledge graphs. Taking the aforementioned frequency-based query as an example, if only one person in the dataset meets the query criteria, existing query techniques may require traversing the entire dataset to obtain the query result, resulting in very poor query efficiency. Therefore, improving the efficiency of frequency-based graph queries has become an urgent problem to be solved. Summary of the Invention

[0004] The main technical problem addressed by this application is to provide a frequency class graph query method and related devices, electronic devices, and storage media, which can improve the efficiency of frequency class graph queries.

[0005] To address the aforementioned issues, the first aspect of this application provides a frequency-based graph query method, comprising: setting a frequency field for a relation edge based on the entities at both ends of the relation edge in a knowledge graph; creating a first information database in an index backend based on the frequency field of the relation edge in the knowledge graph; wherein the first information database includes at least the frequency field of the relation edge in the knowledge graph and an index name; responding to a frequency-based query request, constructing a frequency-based query statement based on the frequency-based query request, assembling a query instruction applicable to the index backend based on the frequency-based query statement, and querying the first information database based on the query instruction to obtain a frequency query result.

[0006] To address the aforementioned issues, a third aspect of this application provides a frequency class graph query apparatus, comprising: a field setting module, an index creation module, and a result query module. The field setting module is used to set the frequency field of a relation edge based on the entities at both ends of the relation edge in the knowledge graph. The index creation module is used to create a first information database in the index backend based on the frequency field of the relation edge in the knowledge graph. The first information database includes at least the frequency field of the relation edge in the knowledge graph and the index name. The result query module is used to respond to a frequency class query request, construct a frequency class query statement based on the frequency class query request, assemble a query instruction suitable for the index backend based on the frequency class query statement, and query the first information database based on the query instruction to obtain the frequency query result.

[0007] To address the aforementioned problems, a third aspect of this application provides an electronic device including a memory and a processor coupled to each other. The memory stores program instructions, and the processor executes the program instructions to implement the frequency class graph query method described in the first aspect.

[0008] To address the aforementioned problems, a fourth aspect of this application provides a computer-readable storage medium storing program instructions executable by a processor, the program instructions being used in the frequency class graph query method described in the first aspect above.

[0009] The above scheme sets a frequency field for each entity at both ends of a relation edge in the knowledge graph. Based on this frequency field, a first information database is created on the index backend. This first information database includes at least the frequency field and index name of the relation edges in the knowledge graph. In response to frequency-based query requests, a frequency-based query statement is constructed, and a query instruction suitable for the index backend is assembled. The query is then performed on the first information database to obtain the frequency query results. This approach achieves two advantages: firstly, it eliminates the need for additional computing engines during frequency-based graph queries, requiring only the index backend; secondly, it avoids altering the original knowledge graph structure, as only the frequency field needs to be set for the relation edges, thus minimizing the need for large amounts of additional storage space. Furthermore, by setting the first information database using the frequency field and executing frequency-based graph queries within it, sufficient information is provided for the queries based on the frequency field and index name in the first information database. Therefore, this approach improves the efficiency of frequency-based graph queries. Attached Figure Description

[0010] Figure 1 This is a flowchart illustrating an embodiment of the frequency class graph query method of this application;

[0011] Figure 2 This is a schematic diagram of an embodiment of a knowledge graph;

[0012] Figure 3 This is a schematic diagram of another embodiment of a knowledge graph;

[0013] Figure 4 This is a schematic diagram of the framework of an embodiment of the frequency class graph query device of this application;

[0014] Figure 5 This is a schematic diagram of the framework of an embodiment of the electronic device of this application;

[0015] Figure 6 This is a schematic diagram of a framework of an embodiment of the computer-readable storage medium of this application. Detailed Implementation

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

[0017] 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.

[0018] In this paper, the terms "system" and "network" are often used interchangeably. The term "and / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A alone, A and B simultaneously, or B alone. Additionally, the character " / " generally indicates that the preceding and following related objects have an "or" relationship. Furthermore, "many" in this paper means two or more.

[0019] Please see Figure 1 , Figure 1 This is a flowchart illustrating an embodiment of the frequency class graph query method of this application. Specifically, it may include the following steps:

[0020] Step S11: Based on the entities at both ends of the relation edge in the knowledge graph, set the frequency field of the relation edge.

[0021] It should be noted that, as mentioned earlier, knowledge graphs typically contain various static and dynamic nodes, as well as static and dynamic relationships. These nodes can be considered "entities," and the relationships can be considered "relationship edges." Taking the transportation field as an example, static nodes can include various types of archival data, such as personnel files, vehicle files, and case files. Dynamic nodes can include various spatiotemporal data, such as violation times and travel trajectories. Furthermore, static relationships can include kinship relationships and person-vehicle relationships, such as parent-child relationships, colleague relationships, and vehicle owner relationships, while dynamic relationships can include person-event relationships and vehicle-event relationships, such as peer relationships and violation relationships. Other cases can be deduced similarly, and will not be listed here.

[0022] In one implementation scenario, please refer to the following: Figure 2 , Figure 2 This is a schematic diagram of an embodiment of a knowledge graph. For example... Figure 2 As shown, the knowledge graph contains four entities. One is an entity labeled "Person," with attributes including "Name: Zhang San, Gender: Male." The other three are entities labeled "Accommodation Event," with attributes including "Time: 20220701, Location: XX City Hotel," "Time: 20220711, Location: XX City Hotel," and "Time: 20220721, Location: XX City Hotel." Furthermore, the entity labeled "Person" has an "Accommodation Relationship" edge with each of the entities labeled "Accommodation Event."

[0023] In one implementation scenario, please refer to the following: Figure 3 , Figure 3 This is a schematic diagram of another embodiment of a knowledge graph. For example... Figure 3 As shown, the knowledge graph contains four entities, all labeled "person," with attribute information including: "Name: Zhang San, ID: 111", "Name: Li Si, ID: 222", "Name: Li Si, ID: 222", and "Name: Li Si, ID: 222". Furthermore, the entity with ID 111 has a "same-sex relationship" edge with the entity with ID 222. Additionally, ID can be considered an entity identifier, and different entities have different entity identifiers.

[0024] It should be noted that, in this embodiment of the disclosure, unless otherwise specified, entity tags can be considered as entity types. Although Figure 3 The attribute information of entities in the knowledge graph shown includes entity identifiers, but this does not necessarily mean that the knowledge graph contains entity identifiers. In practical applications, the aforementioned entity identifiers can be created in the index backend. The index backend refers to a system that utilizes its own characteristics to support more retrieval functions such as fuzzy search, geographic coordinate search, and full-text search. Specifically, it can include, but is not limited to, Elastic Search, Solr, Lucene, etc. For ease of description, the following process will be described using Elastic Search as an example when setting the index backend in this embodiment. If other systems are selected as the index backend, the same principle applies, and they will not be listed one by one here. In addition, the graph data of the knowledge graph can be stored in a storage backend, which can include, but is not limited to, Cassandra, HBase, etc.

[0025] In one implementation scenario, the entities at both ends of a relation edge specifically refer to the two entities connected by the relation edge. Please refer to the relevant documentation. Figure 2 For the first relation edge counting from top to bottom, its two ends include: an entity with the attribute information "Name: Zhang San, Gender: Male" and an entity with the attribute information "Time: 20220701, Location: XX City Hotel"; or, please refer to the following: Figure 3 For the first relation edge counting from top to bottom, its two ends include: an entity with attribute information "Name: Zhang San, ID: 111" and an entity with attribute information "Name: Li Si, ID: 222". Other cases can be deduced similarly, and will not be listed here.

[0026] In one implementation scenario, the value of the frequency field can be set based on whether the entity labels of the two entities are the same, and with reference to the entity identifiers of the two entities. The specific meanings of entity labels and entity identifiers can be found in the aforementioned descriptions, and will not be repeated here. This method, which sets the value of the frequency field based on whether the entity labels of the two entities are the same and with reference to the entity identifiers of the two entities, can, on the one hand, link the frequency field of the relationship with the two entities, helping to provide auxiliary information for subsequent frequency class graph queries; on the other hand, it can minimize the complexity of setting the frequency field.

[0027] In a specific implementation scenario, for a relationship edge, it's possible to detect whether the entity labels of the entities at both ends are the same. If the entity labels of the two entities are the same, the entity identifiers of the two entities are concatenated to obtain the value of the frequency field. Please refer to further details. Figure 3 For the first relation edge from top to bottom, since the entity labels of the entities at both ends are "person", the entity identifiers of the two entities can be concatenated, that is, the entity identifier "111" and the entity identifier "222" can be concatenated to obtain the field value "111222" of the frequency field of the relation edge. Figure 3 For other relation edges in the graph or other knowledge graphs, the frequency field value can be set in the same way as described above, and will not be listed here again. Of course, to facilitate differentiation between the two entities based on the field value, a separator character (such as an underscore "_", a forward slash " / ") can be inserted between the entity identifiers of the two entities when concatenating them. Furthermore, the above field value can also be created in the index backend. The above method, by detecting whether the entity labels of the two entities are the same, and responding to the case where the entity labels of the two entities are the same, concatenates the entity identifiers of the two entities to obtain the frequency field value, further simplifies the setting of the field value.

[0028] In a specific implementation scenario, after detecting whether the entity labels of the two entities are the same, in response to the difference in entity labels between the two entities, the entity identifier of the first entity among the two entities can be used as the field value of the frequency field. Please refer to the following: Figure 2 For the first relation edge from top to bottom, since the entity labels of the entities at both ends are "person" and "accommodation event" respectively, the entity identifier of the first entity (i.e. the entity with the entity label "person") can be used as the field value of the frequency field of the relation edge. Figure 2For other relation edges in the graph or other knowledge graphs, the frequency field value can be set in the same way as described above, and will not be listed here again. It should be noted that the first entity mentioned above mainly refers to the aforementioned static nodes such as personnel. In response to the different entity labels of the two ends, the above method uses the entity identifier of the first entity in the two ends as the field value of the frequency field. Therefore, while ensuring the accuracy of frequency graph queries, it can reduce data redundancy and save disk space to a certain extent.

[0029] In a specific implementation scenario, unlike the aforementioned method of setting field values ​​when entity labels are different, in order to further save disk space, in response to the different entity labels of the two entities, the frequency field may not be set for the relationship edge.

[0030] In a specific implementation scenario, the frequency field can be denoted as "frequency" for ease of querying. Of course, the above setting is merely one possible implementation method in practical applications and does not limit the frequency field to other settings.

[0031] Step S12: Based on the frequency field of relation edges in the knowledge graph, create the first information database in the index backend.

[0032] In this embodiment of the disclosure, the first information base includes at least the frequency field and index name of the relation edges in the knowledge graph. Please refer to the following references. Figure 3 For example Figure 3 After setting the frequency field of the relation edges in the knowledge graph shown above, a first information base can be created in the index backend. This first information base can include the frequency field and index name of each relation edge in the knowledge graph. For example, it could include: the frequency field (value 111222) and index name (hasPeerEvent) of the first relation edge from top to bottom; the frequency field (value 111222) and index name (hasPeerEvent) of the second relation edge from top to bottom; and the frequency field (value 111222) and index name (hasPeerEvent) of the third relation edge from top to bottom. Other cases can be deduced similarly, and will not be listed here.

[0033] In one implementation scenario, the first information base may also include the entity attributes, entity tags, and entity identifiers of each entity in the knowledge graph. The specific meanings of the above three can be found in the aforementioned descriptions, and will not be repeated here.

[0034] In one implementation scenario, the index backend can also create a second information repository, which can include: frequency-based query requests that have already been responded to and their corresponding frequency query results. That is, after each frequency-based query request is received and a frequency query result is obtained, the frequency-based query request and its corresponding frequency query result can be associated and stored in the second information repository of the index backend. It should be noted that the second information repository is used to improve the response speed of frequency-based query requests; details will be provided in subsequent descriptions and will not be elaborated upon here.

[0035] Step S13: In response to a frequency-based query request, construct a frequency-based query statement based on the frequency-based query request, assemble a query instruction applicable to the index backend based on the frequency-based query statement, and query the first information database based on the query instruction to obtain the frequency query result.

[0036] In one implementation scenario, a frequency-based query request can include a query entity located at one end of a query edge and a frequency-based query identifier. The frequency-based query identifier includes the edge name, frequency threshold, sorting identifier, and frequency intent of the query edge. The target entity of the frequency-based query request is located at the other end of the query edge and satisfies the frequency threshold and frequency intent. It should be noted that for graph data queries, user query requests typically include both a query edge and a query entity. If a user query request is not a frequency-based query request, it usually does not include a frequency-based query identifier. In other words, the frequency-based query identifier is key to distinguishing between user query requests with frequency-based query requirements and those without. Furthermore, a query entity can be considered the query subject, a query edge indicates a relationship between the query subject and the entity represented by that edge, and the target entity can be considered an entity in the knowledge graph that matches the user's query request. Please refer to [further details]. Figure 2 For example, if a user queries "find people who stayed at the XX City Hotel more than 3 times in July 2022", the query subject is the entity whose attribute information includes "Time: 202207, Location: XX City Hotel" and whose entity label is "Accommodation Event". The query edge is the relationship edge named "Accommodation Relationship", and the target entity is... Figure 2 The entities in the knowledge graph shown that satisfy the user's query request are those whose attribute information includes "Name: Zhang San, Gender: Male" and whose entity tag is "Person". These are the frequency query results obtained from the index backend after the subsequent query process. The specific query process for the target entity can be found in the following descriptions, which will not be repeated here. Alternatively, please refer to [the relevant documentation / reference]. Figure 3 Taking the user query "Query people who have traveled with Zhang San more than 3 times" as an example, the query subject is the entity whose attribute information contains "Name: Zhang San, ID: 111" and whose entity label is "Person". The query edge is the relationship edge with the edge name "Travel Relationship". The target entity is... Figure 3Entities in the knowledge graph that meet the user's query request, i.e., entities with attribute information containing "Name: Li Si, ID: 222" and entity label "person", which are also the frequency query results obtained at the index backend after the subsequent query process. The specific query process of the target entity can be referred to the subsequent relevant descriptions and will not be elaborated here. The above example is only for the convenience of more clearly explaining the specific meanings of terms such as query edges, query entities, and target entities, and does not limit other cases of frequency-based queries.

[0037] In a specific implementation scenario, the query entity and the target entity can be represented in the user's query request in the form of <entity label, entity attribute, entity attribute value>. Still taking the previous user query request "Query people who have traveled with Zhang San more than 3 times" as an example, the query entity "Zhang San" can be represented as <person1, name, Zhang San>, and since the target entity only knows its entity label should be "person" and both the attribute and the attribute value are unknown, it can be represented by default (e.g., represented by square brackets []), that is, it can be represented as <person2, [], []>. The above example is only one possible implementation method in the actual application process, and other possible representation methods are not limited.

[0038] In a specific implementation scenario, the query edge can be represented in the user's query request in the form of <entity label1, edge name of the query edge, entity label2>. Still taking the previous user query request "Query people who have traveled with Zhang San more than 3 times" as an example, the query edge "traveling together relationship" can be represented as <person1, hasPeerEvent, person2>. The above example is only one possible implementation method in the actual application process, and other possible representation methods are not limited.

[0039] In a specific implementation scenario, if a user query request is a frequency-based query, it can be represented in the query request as <edge name of the query edge, frequency threshold, sorting identifier, frequency intent>. It's important to note that the frequency threshold represents the upper or lower limit of the frequency-based query. For example, for the user query "Query people who have traveled with Zhang San more than 3 times," the frequency threshold is 3, representing the lower limit of the frequency-based query. Furthermore, the sorting identifier indicates the sorting of the results after the frequency-based query is completed, such as ascending or descending order. The frequency intent represents the query target of the frequency-based query, such as a person, vehicle, or event. For example, for the user query "Query people who have traveled with Zhang San more than 3 times," the frequency intent is "person." Therefore, for the user query "Query people who have traveled with Zhang San more than 3 times," the frequency-based query identifier can be represented as...<hasPeerEvent,3,acs,person> It should be noted that acs indicates ascending order. The expression of the frequency query identifier can be similarly applied to other frequency-based query requests, and will not be listed here.

[0040] In one implementation scenario, after obtaining a user query request, it can be first analyzed to determine whether the user query request contains a frequency-based query identifier. If a frequency-based query identifier is found in the user query request, it can be determined that the user query request is a frequency-based query request. Therefore, the step of "constructing a frequency-based query statement based on the frequency-based query request in response to the frequency-based query request" and subsequent steps in this embodiment can be executed. It should be noted that the meaning of the frequency-based query identifier can be found in the foregoing description and will not be repeated here. The above method analyzes whether the user query request contains a frequency-based query identifier, and in response to the presence of a frequency-based query identifier in the user query request, determines that the user query request is a frequency-based query request. This allows for the execution of the step of constructing a frequency-based query statement based on the frequency-based query request and subsequent steps. Therefore, determining whether the user query request is a frequency-based query request before executing the corresponding query steps can distinguish between frequency-based and non-frequency-based queries, which helps improve query efficiency.

[0041] In one implementation scenario, as mentioned earlier, after receiving a user query request, it can be first analyzed to see if the query request contains a frequency-based query identifier. If no frequency-based query identifier is found, it can be determined that the user query request is not a frequency-based query request. Based on this, a graph query statement can be constructed based on the user query request, and then the knowledge graph in the storage backend can be queried using this graph query statement to obtain the graph query results. It should be noted that the configuration of the storage backend can be found in the aforementioned descriptions and will not be repeated here. This method, even when no frequency-based query identifier is found in the user query request, constructs a graph query statement based on the user query request and then queries the knowledge graph in the storage backend using this graph query statement to obtain the graph query results, without needing to use the frequency-based query process again. This effectively distinguishes between frequency-based and non-frequency-based queries, thus improving query efficiency.

[0042] In a specific implementation scenario, graph query statements can include, but are not limited to, ordinary queries and graph traversal statements such as Gremlin; no specific limitation is made here. Gremlin is the graph traversal language of TinkerPop, enabling users to perform complex graph traversals with concise code. Gremlin features "write once, execute anywhere." For the specific process of constructing graph query statements based on user query requests, please refer to the technical details of graph traversal languages ​​such as Gremlin; these will not be elaborated upon here.

[0043] In a specific implementation scenario, similar to the aforementioned construction of graph query statements, the specific process of querying the knowledge graph in the storage backend based on graph query statements can be found in the technical details of graph traversal languages ​​such as Gremlin, which will not be elaborated here.

[0044] In one implementation scenario, taking the Gremlin graph traversal language as an example, for the aforementioned frequency-based query request "query people who have walked with Zhang San more than 3 times", the following frequency-based query statement can be constructed: gE().has('hasPeerEvent','from_name','Zhang San').limit(5).frequency().with(hasPeerEvent,3,asc,person). Here, frequency().with(hasPeerEvent,3,asc,person) is a custom frequency Gremlin statement used to represent the frequency-based query identifier. Furthermore, has('hasPeerEvent','from_name','Zhang San') is mainly used to define the query edge and the query entity, that is, the entity that has a query edge "walking-in-the-row relationship" (i.e., hasPeerEvent) with the query entity "Zhang San". Other cases can be deduced similarly, and will not be listed here.

[0045] In one implementation scenario, taking Elastic Search as an example of an index backend, after constructing a frequency-based query statement, the original execution operator chain of the frequency-based query statement can be parsed and traversed. The JanusGraphStep and FrequencyStep in the original execution operator chain are then merged into a MixedIndexFrequencyStep. The MixedIndexFrequencyStep contains a frequency query builder, allowing query information to be constructed using this builder. This query information is then assembled according to the query template provided by the index backend to obtain the query command. It should be noted that JanusGraph is a graph database engine that uses property graphs for modeling. JanusGraph's modular architecture allows it to adapt to various storage and index backends. The specific meanings of storage and index backends can be found in the aforementioned descriptions and will not be repeated here. The above method, when using Elastic Search as the index backend, parses and traverses the original execution operator chain of frequency-based query statements, merges JanusGraphStep and FrequencyStep in the original execution operator chain into MixedIndexFrequencyStep, and MixedIndexFrequencyStep creates a frequency query builder. Thus, the query information is constructed through the frequency query builder in MixedIndexFrequencyStep, and the query information is assembled according to the query template of the index backend to obtain the query instruction. Therefore, when Elastic Search is selected as the index backend, the frequency-based query requirements can be met.

[0046] In a specific implementation scenario, before parsing and traversing, the frequency-based query statement can be passed to the aforementioned graph database execution engine TinkerPop for initial parsing to ensure that it can be successfully pushed down to index backends such as ElasticSearch for querying.

[0047] In a specific implementation scenario, the original execution operator chain is: JanusGraphStep → FrequencyStep → GlobleRangeStep. This original chain can be optimized to obtain an optimized chain: MixedIndexFrequencyStep → GlobleRangeStep. This optimized chain can then be executed sequentially. During the execution of MixedIndexFrequencyStep, query information is constructed using its internal frequency query builder, and assembled according to the query template in the index backend to obtain the query instruction. This instruction is then used to perform a query in the index backend. After execution, GlobleRangeStep can be executed to integrate the results of the aforementioned operators, thus obtaining the frequency query result. The specific processes of querying and integration are described below and will not be elaborated upon here.

[0048] In a specific implementation scenario, taking Elastic Search as the index backend as an example, the query template for the index backend can be defined as follows:

[0049]

[0050] It should be noted that the specific meaning of the above query templates can be found in the official Elastic Search aggregation documentation, and will not be elaborated upon here. Furthermore, the variable parameters whose values ​​are represented by "XXX" in the above query templates need to be defined and set according to the query information. Specifically, `min_doc_count` represents the frequency threshold, `order` represents the sorting identifier, and `_count` represents the specific setting of the query identifier. Taking the frequency-based query request "Query people who have traveled with Zhang San more than 3 times" as an example, the `min_doc_count` parameter in the above query template can be assembled using the value 3, and the `_count` parameter can be assembled using the string `acs`. In addition, the query index name can also be assembled using the edge name of the query edge. Again, taking the frequency-based query request "Query people who have traveled with Zhang San more than 3 times" as an example, the query index name can be assembled using the edge name "hasPeerEvent". Further, the field parameter value can be calculated and filled based on the query edge and frequency intent. Specifically, if the entity labels of the two ends of the query edge are the same, the field parameter value is recorded as the result of concatenating the entity identifiers of the two ends; otherwise, the field parameter value is the entity identifier of the first entity among the two ends.

[0051] In one implementation scenario, as mentioned earlier, the index backend also creates a second information database. After receiving a query instruction, and before querying the first information database based on the query instruction, a query can be performed in the second information database first. If the second information database returns no results, the step of querying the first information database based on the query instruction can be executed to obtain the frequency query results. This method, by first querying the second information database based on the query instruction before querying the first information database, and then querying the first information database only if the second information database returns no results, innovatively combines offline statistical generation of the first information database with real-time online statistical generation of the second information database to jointly serve frequency-based queries, thus helping to improve the real-time performance of frequency queries.

[0052] In a specific implementation scenario, the constructed query command and query index name can be modified by adding a frequency identifier before querying the second information database. Taking the aforementioned frequency-based query request "Query people who have walked with Zhang San more than 3 times" as an example, the constructed query command and query index name `hasPeerEvent` can be modified by adding a frequency identifier to obtain `hasPeerEvent_frequency`, and then queried in the second information database first. Further, if the second information database contains the corresponding attribute, it will directly return the result, which is edge information, such as (label11, label22), etc., and can be integrated to obtain the frequency query result. Conversely, if the second information database does not return any results, the query can be performed in the first information database based on the query command. The specific process of querying in the first information database can be found in the following description, and will not be elaborated here.

[0053] In a specific implementation scenario, after querying the first information database based on the query command and obtaining the frequency query results, the second information database can be updated based on the current frequency query request and the frequency query results obtained from the first information database. This enables real-time online statistical updates of the second information database, thereby helping to further improve the real-time performance of frequency queries.

[0054] In one implementation scenario, as mentioned earlier, the query instruction at least defines the attribute information of the query edge (e.g., the edge name of the query edge, the query entity connected to the query edge, etc.) and a frequency threshold. During the query process based on the query instruction in the first information database, the query instruction can be executed in the first information database to obtain several candidate query results matching the attribute information. These candidate query results include the edge identifier and the number of entries for the relation edges matching the attribute information. Based on this, each candidate query result can be filtered according to the frequency threshold and the number of entries in each candidate query result to obtain the target query result. Then, based on the edge identifiers in each target query result, each target query result can be integrated to obtain the frequency query result. In this approach, the query instruction is first executed in the first information database to obtain several candidate query results matching the attribute information. Then, the candidate query results are filtered using the frequency threshold to obtain the target query result. Finally, by integrating the target query results, the frequency query result is obtained, thus enabling the rapid retrieval of query results that match the query request.

[0055] In a specific implementation scenario, taking the aforementioned frequency-based query request "Query people who have walked with Zhang San more than 3 times" as an example, as mentioned before, the attribute information of the query edge can include: the edge name "hasPeerEvent" and the query entity connected to the query edge, namely the entity "Zhang San" with the entity label "person" and its entity identifier 111. Please refer to the relevant documentation. Figure 3Upon querying, we can obtain the relation edges matching the aforementioned attribute information. The frequency field value of each edge is 111222, and the number of entries is 3. This means that relation edges satisfying the following requirements can be queried: the frequency field value contains the entity identifier of the queried entity, and the edge name is the same as the edge name of the queried edge. Furthermore, relation edges matching the attribute information in the same candidate query result have the same frequency field. Therefore, for the frequency-based query request "query people who have walked with Zhang San more than 3 times," we can obtain a candidate query result containing 3 relation edges with an edge identifier of 111222. It should be noted that the edge identifier can specifically be the frequency field of the relation edge. Other cases can be deduced similarly, and will not be listed here.

[0056] In a specific implementation scenario, let's take Elastic Search as the index backend as an example. For instance, as a possible implementation result, a candidate query result returned by the first information repository can be represented as:

[0057] buckets":[

[0058] {

[0059] "key":"kg246lxl1a82637e014a1ad62395029b236b46af",

[0060] "doc_count":1814

[0061] }

[0062] }]

[0063] It should be noted that the above `key` represents the virtual ID of the relation edge matching the attribute information, and `doc_count` represents the number of entries of the relation edge matching the attribute information (specifically, the number of entries of the relation edge with the above virtual ID). Based on this, candidate query results with fewer than the frequency threshold can be filtered out first, and the remaining candidate query results are the target query results that meet the requirements. Furthermore, the virtual IDs in the target query results can be parsed using a function to obtain the real IDs (e.g., the field value of the frequency field of the relation edge).

[0064] In a specific implementation scenario, taking Elastic Search as the index backend as an example, as mentioned earlier, the GlobleRangeStep operator can be executed to integrate the results. Specifically, as mentioned earlier, the query command can also define a sorting identifier. It can analyze the edge identifiers in the target query results to obtain the target entities that match the frequency-based query request. Based on the number of entries in the target query results, it determines the frequency count of the target entities obtained from the target query results analysis. Then, based on the sorting identifier, it sorts each target entity according to its frequency count to obtain the frequency query results. For example, as mentioned earlier, the edge identifier can be represented by the field value of the frequency field. In this case, the target entity can be determined based on the entity identifier and field value of the query entity. For example, for the aforementioned frequency-based query request "Query people who have traveled with Zhang San more than 3 times", since the field value of the frequency field of the relation edge matching the attribute information is 111222, and the entity identifier of the query entity is 111, the target entity can be determined to be the entity with entity identifier 222, i.e. Figure 3 The entity with the attribute information "Li Si" is the only target entity, and since the frequency count corresponding to this target entity is 3, the frequency query results will only contain entities with the attribute information "Li Si" after sorting based on the sorting identifier acs. Other cases can be deduced similarly, and will not be listed here.

[0065] The above scheme sets a frequency field for each entity at both ends of a relation edge in the knowledge graph. Based on this frequency field, a first information database is created on the index backend. This first information database includes at least the frequency field and index name of the relation edges in the knowledge graph. In response to frequency-based query requests, a frequency-based query statement is constructed, and a query instruction suitable for the index backend is assembled. The query is then performed on the first information database to obtain the frequency query results. This approach achieves two advantages: firstly, it eliminates the need for additional computing engines during frequency-based graph queries, requiring only the index backend; secondly, it avoids altering the original knowledge graph structure, as only the frequency field needs to be set for the relation edges, thus minimizing the need for large amounts of additional storage space. Furthermore, by setting the first information database using the frequency field and executing frequency-based graph queries within it, sufficient information is provided for the queries based on the frequency field and index name in the first information database. Therefore, this approach improves the efficiency of frequency-based graph queries.

[0066] Please see Figure 4 , Figure 4This is a schematic diagram of the framework of an embodiment of the frequency class graph query device 40 of this application. The frequency class graph query device 40 includes: a field setting module 41, an index creation module 42, and a result query module 43. The field setting module 41 is used to set the frequency field of the relation edge based on the two end entities of the relation edge in the knowledge graph; the index creation module 42 is used to create a first information database in the index backend based on the frequency field of the relation edge in the knowledge graph; wherein, the first information database includes at least the frequency field of the relation edge in the knowledge graph and the index name; the result query module 43 is used to respond to a frequency class query request, construct a frequency class query statement based on the frequency class query request, assemble a query instruction applicable to the index backend based on the frequency class query statement, and query the first information database based on the query instruction to obtain the frequency query result.

[0067] The above solution has several advantages. First, it requires only an index backend without introducing other computing engines during frequency graph queries. Second, it doesn't require changing the original knowledge graph structure; only frequency fields need to be set for relation edges. Therefore, it doesn't require a large amount of additional storage space. Third, it uses the frequency field to set up a first information database and performs frequency graph queries within this database, providing sufficient information for the query based on the frequency field and index name. Thus, it improves the efficiency of frequency graph queries.

[0068] In some disclosed embodiments, the value of the frequency field is set based on whether the entity labels of the two entities are the same, and with reference to the entity identifiers of the two entities.

[0069] In some disclosed embodiments, the field setting module 41 includes a label detection submodule for detecting whether the entity labels of the two entities are the same; the field setting module 41 includes an identifier splicing submodule for splicing the entity identifiers of the two entities in response to the entity labels of the two entities being the same, to obtain the field value of the frequency field.

[0070] In some disclosed embodiments, the field setting module 41 includes an identifier selection submodule, which, in response to the different entity labels of the two entities, uses the entity identifier of the first entity among the two entities as the field value of the frequency field.

[0071] In some publicly disclosed embodiments, the index backend also creates a second information database, which includes: frequency class query requests that have been responded to and their corresponding frequency query results. The frequency class graph query device 40 also includes a historical query module, which is used to query the second information database based on the query instruction. The result query module 43 is specifically used to respond to the second information database not returning any results, and to perform the step of querying the first information database based on the query instruction to obtain the frequency query result.

[0072] In some disclosed embodiments, the frequency class graph query device 40 further includes an information update module for updating the second information database based on the frequency class query request and the frequency query results obtained from the first information database.

[0073] In some disclosed embodiments, the frequency class graph query device 40 further includes a request parsing module for parsing whether the user query request contains a frequency class query identifier; the frequency class graph query device 40 also includes a first determining module for determining that the user query request is a frequency class query request in response to the user query request containing a frequency class query identifier, and performing the steps of constructing a frequency class query statement based on the frequency class query request in response to the frequency class query request and subsequent steps in conjunction with the result query module 43.

[0074] In some disclosed embodiments, the frequency class graph query device 40 further includes a second determining module, used to determine that the user query request is not a frequency class query request in response to the user query request not containing a frequency class query identifier. The frequency class graph query device 40 also includes a graph query module, used to construct a graph query statement based on the user query request, and to query the knowledge graph in the storage backend based on the graph query statement to obtain a graph query result.

[0075] In some disclosed embodiments, the query instruction at least defines the attribute information and frequency threshold of the query edge. The result query module 43 includes a candidate query submodule, which is used to execute the query instruction in the first information database to obtain several candidate query results that match the attribute information. The candidate query results include the edge identifier and the number of entries of the relation edge that matches the attribute information. The result query module 43 includes a candidate filtering submodule, which is used to filter each candidate query result based on the frequency threshold and the number of entries in each candidate query result to obtain the target query result. The result query module 43 includes a result integration submodule, which is used to integrate each target query result based on the edge identifier in each target query result to obtain the frequency query result.

[0076] In some disclosed embodiments, the query instruction further defines a sorting identifier. The result integration submodule includes an identifier analysis unit, which analyzes the edge identifiers in the target query results to obtain target entities that meet the frequency-based query request. The result integration submodule includes a frequency determination unit, which determines the frequency of the target entities obtained from the target query results based on the number of entries in the target query results. The result integration submodule includes an entity sorting unit, which sorts the target entities according to their frequency based on the sorting identifier to obtain the frequency query results.

[0077] In some disclosed embodiments, the edge identifier of the relation edge matching the attribute information is represented by the field value of the frequency field. The frequency field of the relation edges matching the attribute information in the same candidate query result has the same field value, and the relation edges matching the attribute information meet the following requirements: the field value of the frequency field contains the entity identifier of the query entity, and the edge name is the same as the edge name of the query edge.

[0078] In some publicly available embodiments, the index backend is Elastic Search. The result query module 43 includes a parsing and traversal submodule for parsing and traversing the original execution operator chain of frequency-type query statements; the result query module 43 includes an operator optimization submodule for merging JanusGraphStep and FrequencyStep in the original execution operator chain into MixedIndexFrequencyStep, wherein MixedIndexFrequencyStep creates a frequency query builder; the result query module 43 includes an instruction construction submodule for constructing query information through the frequency query builder in MixedIndexFrequencyStep and assembling the query information according to the query template of the index backend to obtain query instructions.

[0079] In some disclosed embodiments, a frequency-based query request includes a query entity located at one end of a query edge and a frequency-based query identifier; wherein, the frequency-based query identifier includes the edge name, frequency threshold, sorting identifier, and frequency intent of the query edge, and the target entity of the frequency-based query request is located at the other end of the query edge and satisfies the frequency threshold and frequency intent.

[0080] 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 memory 51 stores program instructions, and the processor 52 is used to execute the program instructions to implement the steps in any of the frequency class graph query method embodiments described above.

[0081] Specifically, processor 52 controls itself and memory 51 to implement the steps in any of the frequency class graph query method embodiments described above. 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 by multiple integrated circuit chips.

[0082] The above solution, because the electronic device 50 can implement the steps in any of the frequency class graph query method embodiments, allows the electronic device 50 to perform frequency class graph queries without introducing other computing engines, requiring only an index backend. Furthermore, it does not require changing the original graph structure of the knowledge graph, only setting frequency fields for relation edges. Therefore, it eliminates the need for a large amount of additional storage space. Moreover, by setting a first information database through the frequency field and performing frequency class graph queries within the first information database, it can provide sufficient information for frequency class graph queries using the frequency field and index name in the first information database. Thus, it improves the efficiency of frequency class graph queries.

[0083] 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 61 that can be executed by a processor. The program instructions 61 are used to implement the steps in any of the above-described frequency class graph query method embodiments.

[0084] In the above solution, since the computer-readable storage medium 60 implements the steps in any of the frequency class graph query method embodiments, the computer-readable storage medium 60 only needs to index the backend without introducing other computing engines during the frequency class graph query process. Furthermore, it does not need to change the original graph structure of the knowledge graph, but only needs to set frequency fields for relation edges. Therefore, it does not require a large amount of additional storage space. Moreover, by setting the first information database through the frequency field and performing frequency class graph queries in the first information database, it can provide sufficient information for frequency class graph queries through the frequency field and index name in the first information database. Therefore, it can improve the efficiency of frequency class graph queries.

[0085] 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, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

[0086] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment, depending on actual needs.

[0087] 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.

[0088] 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.

[0089] If the technical solution of this application involves personal information, the product using this technical solution has clearly informed the user of the personal information processing rules and obtained the user's voluntary consent before processing the personal information. If the technical solution of this application involves sensitive personal information, the product using this technical solution has obtained the user's separate consent before processing the sensitive personal information, and also meets the requirement of "express consent". For example, at personal information collection devices such as cameras, clear and prominent signs are set up to inform users that they have entered the scope of personal information collection and that personal information will be collected. If an individual voluntarily enters the collection scope, it is deemed that they have agreed to the collection of their personal information; or on the personal information processing device, with clear signs / information informing users of the personal information processing rules, authorization is obtained from the individual through pop-up information or by asking the individual to upload their personal information; wherein, the personal information processing rules may include information such as the personal information processor, the purpose of personal information processing, the processing method, and the types of personal information processed.

Claims

1. A frequency class graph query method, characterized by, The method comprises: Based on the two end entities of the relationship edge in the knowledge graph, the frequency field of the relationship edge is set; wherein the field value of the frequency field is set based on whether the entity labels of the two end entities are the same, and the entity labels of the two end entities are referred to, and in response to the entity labels of the two end entities being the same, the entity labels of the two end entities are spliced to obtain the field value of the frequency field, and in response to the entity labels of the two end entities being different, the entity label of the first entity of the two end entities is taken as the field value of the frequency field; Based on the frequency field of the relationship edge in the knowledge graph, a first information library is created in the index backend; wherein the first information library at least includes the frequency field and the index name of the relationship edge in the knowledge graph; In response to a frequency query request, a frequency query statement is constructed based on the frequency query request, and a query instruction suitable for the index backend is assembled based on the frequency query statement, and a frequency query result is obtained by querying the first information library based on the query instruction.

2. The method of claim 1, wherein, The index backend also creates a second information library, and the second information library includes: the frequency query result corresponding to the frequency query request which has been responded, and before the step of obtaining the frequency query result by querying the first information library based on the query instruction, the method further comprises: Querying the second information library based on the query instruction; The step of obtaining the frequency query result by querying the first information library based on the query instruction comprises: In response to no returned result of the second information library, the step of obtaining the frequency query result by querying the first information library based on the query instruction is executed.

3. The method of claim 2, wherein, After the step of obtaining the frequency query result by querying the first information library based on the query instruction, the method further comprises: Updating the second information library based on the frequency query request and the frequency query result obtained by querying the first information library.

4. The method of claim 1, wherein, Before the step of constructing a frequency query statement based on the frequency query request in response to a frequency query request, the method further comprises: Parsing whether the user query request contains a frequency query identifier; In response to the user query request containing the frequency query identifier, it is determined that the user query request is a frequency query request, and the step of constructing a frequency query statement based on the frequency query request in response to a frequency query request and the subsequent steps are executed.

5. The method of claim 4, wherein, After the step of parsing whether the user query request contains a frequency query identifier, the method further comprises: In response to the user query request not containing the frequency query identifier, it is determined that the user query request is not a frequency query request, a graph query statement is constructed based on the user query request, and a graph query result is obtained by querying the knowledge graph in the storage backend based on the graph query statement.

6. The method of claim 1, wherein, The query instruction at least defines the attribute information and the frequency threshold of the query edge, and the step of obtaining the frequency query result by querying the first information library based on the query instruction comprises: The first information base executes a query instruction to obtain a plurality of candidate query results matched with the attribute information; wherein the candidate query results include edge identifiers and entry numbers of relationship edges matched with the attribute information; The target query results are obtained by screening each of the candidate query results based on the frequency threshold and the entry number in each of the candidate query results; The frequency query result is obtained by integrating each of the target query results based on the edge identifier in each of the target query results.

7. The method of claim 6, wherein, The query instruction further defines a sorting identifier, and the frequency query result is obtained by integrating each of the target query results based on the edge identifier in each of the target query results, including: A target entity conforming to the frequency type query request is obtained by analyzing the edge identifier in the target query result; The frequency number of the target entity analyzed by the target query result is determined based on the entry number in the target query result; The target entities are sorted according to the frequency number of each target entity based on the sorting identifier, and the frequency query result is obtained.

8. The method of claim 6, wherein, The edge identifier of the relationship edge matched with the attribute information is represented by a field value of a frequency field, the frequency field of the relationship edge matched with the attribute information in the same candidate query result has the same field value, and the relationship edge matched with the attribute information meets the following requirements: the field value of the frequency field contains an entity identifier of a query entity, and the edge name is the same as that of a query edge.

9. The method of claim 1, wherein, The index backend is Elastic Search, and the query instruction suitable for the index backend is assembled based on the frequency type query statement, including: The original execution operator chain of the frequency type query statement is parsed and traversed; JanusGraphStep and FrequencyStep in the original execution operator chain are merged into MixedIndexFrequencyStep, wherein the MixedIndexFrequencyStep creates a frequency query constructor; Query information is constructed through the frequency query constructor in the MixedIndexFrequencyStep, and the query information is assembled according to the query template of the index backend to obtain the query instruction.

10. The method according to any one of claims 1 to 9, characterized in that, The frequency type query request includes a query entity at one end of a query edge and a frequency type query identifier; The frequency type query identifier includes an edge name of the query edge, a frequency threshold, a sorting identifier and a frequency intention, and the target entity of the frequency type query request is located at the other end of the query edge and meets the frequency threshold and the frequency intention.

11. A frequency class graph query apparatus, characterized by comprising: including: The field setting module is configured to set a frequency field of a relationship edge in the knowledge graph based on two end entities of the relationship edge, wherein a field value of the frequency field is set based on whether the entity labels of the two end entities are the same and based on the entity identifiers of the two end entities, and in response to the entity labels of the two end entities being the same, the entity identifiers of the two end entities are spliced to obtain the field value of the frequency field, and in response to the entity labels of the two end entities being different, the entity identifier of a first entity of the two end entities is taken as the field value of the frequency field; The index creation module is configured to create a first information base based on the frequency field of the relationship edge in the knowledge graph in an index backend, wherein the first information base at least includes the frequency field of the relationship edge in the knowledge graph and an index name; The result query module is configured to, in response to a frequency type query request, construct a frequency type query statement based on the frequency type query request, assemble a query instruction suitable for the index backend based on the frequency type query statement, and query the first information base based on the query instruction to obtain a frequency query result.

12. An electronic device, comprising: The memory stores program instructions, and the processor is configured to execute the program instructions to implement the frequency type graph query method in any one of claims 1 to 10.

13. A computer-readable storage medium, characterized in that, The memory stores program instructions capable of being executed by the processor, and the program instructions are configured to implement the frequency type graph query method in any one of claims 1 to 10.

Images