Data query methods

Abstract

This application belongs to the field of computer technology, specifically relating to a data query method, a data query device, a computer-readable medium, an electronic device, and a computer program product. The method includes: parsing a data query request to obtain query conditions, the query conditions including one or more of a subject, an object, and a predicate, the predicate representing the logical relationship between the subject and the object; determining a target data partition in a graph database based on the query conditions, the graph database including a first-level data partition obtained by dividing regions according to the density relationship between nodes, the first-level data partition including a second-level data partition obtained by dividing regions according to the logical relationship between nodes; and retrieving data query results matching the query conditions from the target data partition. This application can improve data query efficiency and reduce resource consumption in the data query process.

Description

Technical Field

[0001] This application belongs to the field of computer technology, and specifically relates to a data query method, a data query device, a computer-readable medium, an electronic device, and a computer program product. Background Technology

[0002] Graph databases are database systems specifically designed for processing graphical data. Their core advantage lies in efficient data relationship management. Compared to traditional relational databases, graph databases use vertices and edges to represent data entities and their relationships, making them more efficient and intuitive when handling highly interconnected data structures.

[0003] When querying data from a graph database, a simple and direct approach is to load the entire data file into memory and search for the corresponding query results in memory. However, this method requires accessing a large amount of data to retrieve the necessary information, leading to low query efficiency and high computational resource consumption. Summary of the Invention

[0004] The purpose of this application is to provide a data query method, a data query device, a computer-readable medium, an electronic device, and a computer program product, which aim to improve data query efficiency and reduce resource consumption in the data query process.

[0005] According to one aspect of the embodiments of this application, a data query method is provided, the method comprising: parsing a data query request to obtain query conditions, the query conditions including one or more of a subject, an object, and a predicate, the predicate being used to represent the logical relationship between the subject and the object; determining a target data partition in a graph database based on the query conditions, the graph database including a first-level data partition obtained by dividing regions according to the density relationship between nodes, the first-level data partition including a second-level data partition obtained by dividing regions according to the logical relationship between nodes; and retrieving data query results matching the query conditions in the target data partition.

[0006] According to one aspect of the embodiments of this application, a data query apparatus is provided, the apparatus comprising:

[0007] The parsing module is configured to parse data query requests to obtain query conditions. The query conditions include one or more of a subject, an object, and a predicate. The predicate is used to represent the logical relationship between the subject and the object.

[0008] The partitioning module is configured to determine the target data partition in the graph database based on the query conditions. The graph database includes a first-level data partition obtained by dividing regions according to the density relationship between nodes, and the first-level data partition includes a second-level data partition obtained by dividing regions according to the logical relationship between nodes.

[0009] The retrieval module is configured to retrieve data query results that match the query conditions in the target data partition.

[0010] In some embodiments of this application, based on the above technical solutions, the partitioning module may further include:

[0011] The pattern graph acquisition module is configured to acquire a complete pattern graph stored in a graph database, wherein the nodes in the complete pattern graph are used to represent subjects or objects, and the edges in the complete pattern graph are used to represent predicates.

[0012] The density determination module is configured to traverse the complete pattern graph to obtain the density relationship between nodes. The density relationship includes an importance parameter and a dependency parameter. The importance parameter is used to represent the importance of each node in the complete pattern graph, and the dependency parameter is used to represent the degree of dependency between any two nodes.

[0013] The core node selection module is configured to select a preset number of core nodes from the complete pattern diagram based on the importance parameter, wherein the core nodes are the nodes with the highest importance parameter in the complete pattern diagram;

[0014] The node allocation module is configured to allocate each node in the complete pattern graph to a first-level data partition centered on the core node, based on the dependency parameters.

[0015] In some embodiments of this application, based on the above technical solutions, the complete pattern graph is a directed graph, and the density determination module includes:

[0016] The shortest path set acquisition module is configured to determine the shortest path between two nodes according to the predicate, thereby obtaining the shortest path set of the complete pattern graph;

[0017] The distribution ratio statistics module is configured to calculate the distribution ratio of each node in the shortest path set to obtain the core degree parameter of the node.

[0018] The importance parameter determination module is configured to determine the importance parameter of the node based on the coreness parameter and the number of instances of the node.

[0019] In some embodiments of this application, based on the above technical solutions, the shortest path set acquisition module is further configured to: traverse the complete pattern graph to obtain node pairs consisting of any two nodes; determine all node pair paths with the node pair as the starting point and the ending point according to the predicate; compare the lengths of the node pair paths to obtain the shortest path set of the node pair.

[0020] In some embodiments of this application, based on the above technical solutions, the distribution ratio statistics module is further configured to: for a selected node pair, count the number of all shortest paths in the shortest path set to obtain a first path count; for a selected node, count the number of shortest paths in the shortest path set that contain the selected node to obtain a second path count; obtain the ratio of the second path count to the first path count to obtain the distribution ratio of the selected node in the shortest path set of the selected node pair; and accumulate the distribution ratios corresponding to each node and each node pair to obtain the core degree parameter of the node.

[0021] In some embodiments of this application, based on the above technical solutions, the distribution ratio statistics module is further configured to: normalize the core degree parameter of the node to obtain the normalized core degree of the node; normalize the number of instances of the node to obtain the normalized number of instances of the node; and sum the normalized core degree and the normalized number of instances to obtain the importance parameter of the node.

[0022] In some embodiments of this application, based on the above technical solutions, the tightness determination module includes:

[0023] The length acquisition module is configured to acquire the length of the shortest path of a selected pair of nodes.

[0024] The dependency parameter determination module is configured to determine the dependency parameters of the node pairs based on the importance parameters of each node located on the shortest path and the length of the shortest path. The dependency parameters are positively correlated with the importance parameters of the starting point on the shortest path, negatively correlated with the importance parameters of other nodes on the shortest path besides the starting point, and negatively correlated with the length of the shortest path.

[0025] In some embodiments of this application, based on the above technical solutions, the dependency parameter is also negatively correlated with the density parameter of two adjacent nodes on the shortest path. The density parameter is used to weight the importance parameters of other nodes on the shortest path other than the starting point.

[0026] In some embodiments of this application, based on the above technical solutions, the method for determining the density parameter includes: obtaining the number of instances of the starting node and the number of instances of the ending node in two adjacent nodes; and determining the density parameter of the two adjacent nodes based on the number of instances of the starting node, the number of instances of the ending node, and the total number of nodes in the complete pattern graph.

[0027] In some embodiments of this application, based on the above technical solutions, when the number of instances of the end node is zero, the density parameter is negatively correlated with the total number of nodes in the complete pattern graph; when the number of instances of the end node is not zero, the density parameter is negatively correlated with the total number of nodes in the complete pattern graph, positively correlated with the number of instances of the start node, and negatively correlated with the number of instances of the end node.

[0028] According to one aspect of the embodiments of this application, a computer-readable medium is provided, on which a computer program is stored, which, when executed by a processor, implements the data query method as described in the above technical solutions.

[0029] According to one aspect of the embodiments of this application, an electronic device is provided, the electronic device comprising: a processor; and a memory for storing executable instructions of the processor; wherein the processor is configured to execute the executable instructions to implement the data query method as described in the above technical solutions.

[0030] According to one aspect of the embodiments of this application, a computer program product is provided, including a computer program that, when executed by a processor, implements the data query method as described in the above technical solutions.

[0031] In the technical solution provided in this application embodiment, key query conditions, including subject, object, and predicate, are extracted by intelligently parsing data query requests to accurately capture the logical relationships of the query. Then, the solution utilizes the partitioning structure of a graph database to first identify primary data partitions based on node density, and further refine them to secondary data partitions based on logical relationships, thereby efficiently locating the target data. This application embodiment not only improves the accuracy and efficiency of the query but also optimizes query performance by reducing the data retrieval scope, ultimately achieving fast and accurate retrieval of results matching the query conditions. Attached Figure Description

[0032] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application. It is obvious that the drawings described below are merely some embodiments of this application, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort.

[0033] Figure 1 An exemplary system architecture block diagram illustrating the application of the technical solution of this application is shown schematically.

[0034] Figure 2 A flowchart of a data query method according to one embodiment of this application is shown.

[0035] Figure 3 A schematic diagram illustrating the principle framework of the data query method in the embodiments of this application is shown.

[0036] Figure 4 A flowchart of a method for dividing a primary data partition into regions is shown in one embodiment of this application.

[0037] Figure 5 This diagram illustrates an RDF schema diagram in an application scenario according to an embodiment of this application.

[0038] Figure 6 This illustrates the correspondence between the pattern diagram and the number of instances in an application scenario of an embodiment of this application.

[0039] Figure 7 The diagram illustrates the first-level data partitioning result of a pattern diagram in an application scenario according to an embodiment of this application.

[0040] Figure 8 This illustration shows the partitioning result of copying data from a primary data partition in an application scenario according to an embodiment of this application.

[0041] Figure 9 A schematic block diagram of the data query device provided in an embodiment of this application is shown.

[0042] Figure 10 A schematic diagram of a computer system architecture suitable for implementing the embodiments of this application is shown. Detailed Implementation

[0043] Exemplary embodiments will now be described more fully with reference to the accompanying drawings. However, these exemplary embodiments can be implemented in many forms and should not be construed as limited to the examples set forth herein; rather, these embodiments are provided to make this application more comprehensive and complete, and to fully convey the concept of the exemplary embodiments to those skilled in the art.

[0044] Furthermore, the described features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. Numerous specific details are provided in the following description to give a thorough understanding of embodiments of this application. However, those skilled in the art will recognize that the technical solutions of this application can be practiced without one or more of the specific details, or other methods, components, apparatuses, steps, etc., can be employed. In other instances, well-known methods, apparatuses, implementations, or operations are not shown or described in detail to avoid obscuring various aspects of this application.

[0045] In the embodiments of this application, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

[0046] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.

[0047] The flowcharts shown in the accompanying drawings are merely illustrative and do not necessarily include all content and operations / steps, nor do they necessarily need to be performed in the described order. For example, some operations / steps can be broken down, while others can be combined or partially combined; therefore, the actual execution order may change depending on the specific circumstances.

[0048] Figure 1 An exemplary system architecture block diagram illustrating the application of the technical solution of this application is shown schematically.

[0049] like Figure 1As shown, the system architecture 100 may include terminal devices 110, a network 120, and a server 130. Terminal devices 110 may include various electronic devices such as smartphones, tablets, laptops, desktop computer smart speakers, smart wearable devices, smart in-vehicle devices, and smart payment terminals. Server 130 may be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms. Network 120 may be a communication medium of various connection types capable of providing a communication link between terminal devices 110 and server 130, such as a wired communication link or a wireless communication link.

[0050] Depending on the implementation requirements, the system architecture in this application embodiment can have any number of terminal devices, networks, and servers. For example, server 130 can be a server group composed of multiple server devices. In addition, the technical solutions provided in this application embodiment can be applied to terminal device 110, or to server 130, or can be implemented jointly by terminal device 110 and server 130. This application does not impose any special limitations on this.

[0051] The following detailed description of the technical solutions provided in this application, including the data query method, data query device, computer-readable medium, electronic device, and computer program product, is based on specific embodiments.

[0052] Figure 2 A flowchart of a data query method according to one embodiment of this application is shown. This data query method can be provided by... Figure 1 The terminal device or server shown can be used for execution, or it can be executed by... Figure 1 The terminal device and server work together to execute the method. This application uses a data query method executed by the terminal device as an example for illustration. For example... Figure 2 As shown, the data query method may include the following steps S210 to S230.

[0053] S210: Parse the data query request to obtain the query conditions. The query conditions include one or more of the following: subject, object, and predicate. The predicate is used to express the logical relationship between the subject and the object.

[0054] S220: Determine the target data partition in the graph database based on the query conditions. The graph database includes first-level data partitions obtained by dividing regions according to the density relationship between nodes. The first-level data partitions include second-level data partitions obtained by dividing regions according to the logical relationship between nodes.

[0055] S230: Retrieve data query results that match the query conditions in the target data partition.

[0056] This application embodiment intelligently parses data query requests to extract key query conditions, including subject, object, and predicate, thereby accurately capturing the logical relationships of the query. Then, the solution utilizes the partitioning structure of a graph database to first identify primary data partitions based on node density, and further refine them to secondary data partitions based on logical relationships, thus efficiently locating the target data. This application embodiment not only improves the accuracy and efficiency of the query but also optimizes query performance by reducing the data retrieval scope, ultimately achieving fast and accurate retrieval of results matching the query conditions.

[0057] In one embodiment of this application, the graph database stores data in the form of a Resource Description Framework (RDF).

[0058] RDF is a standard model for describing resources on the web, and it forms one of the foundational technologies of the Semantic Web. The basic unit of RDF information is a triple, also known as a statement, which consists of three parts (hereinafter referred to as triples).

[0059] Subject: The resource or entity being described.

[0060] Predicate: Describes the attributes or relationships of a subject.

[0061] Object: The attribute value of a subject or another resource that interacts with the subject.

[0062] For example, a triple can be represented as "Harry Potter, author, J.K. Rowling", where "Harry Potter" is the subject, "author" is the predicate, and J.K. Rowling is the object.

[0063] To store, manage, and query the ever-increasing volume of RDF data, numerous RDF storage and query engines have emerged. Apache Spark is a popular big data computing engine, used in research for efficient querying of RDF data. This platform utilizes in-memory data structures for storing RDF data, offering higher efficiency and supporting effective distributed query responses.

[0064] A simple and straightforward approach to performing RDF queries using Spark is to store all the triples in the RDF as a single large file in HDFS, load it into memory during the query, and search for the corresponding answer in memory. However, this method requires accessing a large amount of data to retrieve the required information, resulting in poor query performance.

[0065] To address this issue, some RDF horizontal and vertical partitioning schemes have emerged in the related technologies of this application, attempting to minimize the amount of data accessed during RDF queries. However, these schemes are relatively simple horizontal or vertical partitioning schemes, such as hash partitioning based on the principal in the triple. This technique works well in scenarios where queries radiate outwards from a central entity without needing to access data across multiple partitions. However, its performance is low in queries involving complex relationships between multiple entities.

[0066] To address the problems existing in the aforementioned related technologies, the embodiments of this application can effectively partition RDF data. This effectively groups highly correlated data together, minimizes the amount of data accessed during queries, and maintains a balanced distribution. During queries, based on the partitioning information of the RDF data, general query statements are converted into SQL statements that Spark can recognize, thereby improving query performance.

[0067] As mentioned above, RDF is based on triples in the form of "subject, predicate, object". They record the relationship between the subject and the object through the predicate. An RDF dataset contains two types of information: classes and the relationship between classes, and instances and the relationship between instances.

[0068] Both types of information are represented by triples. For example, "teacher, instruct, student" indicates that the type "teacher" and the type "student" have a "instruction" relationship, representing information about classes and relationships between classes. Conversely, "Old Wang, instruct, Little Li" indicates that the instance "Old Wang" and the instance "Little Li" have a "instruction" relationship, representing information about instances and relationships between instances. Here, the class is a generalization of the instance, and the instance is a concretization of the class; in other words, the instance is derived from the class. We can say that the instance "Old Wang" is derived from the type "teacher".

[0069] Classes and the relationships between classes form an RDF schema graph, where nodes represent classes and edges represent relationships between classes. Instances and the relationships between instances form an RDF instance graph, where nodes represent instances and edges represent relationships between instances.

[0070] The purpose of URIs is to provide unique, globally identifiable identifiers for resources on the web. These resources can be web pages, documents, images, videos, or any content accessible over the network, as well as abstract concepts, entities, or relationships. In the RDF triple structure, a URI can appear in the subject (s), predicate (p), or object (o) position. RDF uses URIs to uniquely identify a specific instance, relationship, or type. Continuing with the example above, "teacher, instruct, student" and "Old Wang, instruct, Little Li" would both be uniquely identified by URIs.

[0071] In the data query method provided in this application embodiment, the RDF dataset can be abstracted into two interrelated graphs, namely, a schema graph and an instance graph. This application embodiment first uses a certain algorithm to select k of the most important schema nodes from the schema graph as core nodes, each core node corresponding to a first-level data partition. Then, based on a dependency algorithm, the remaining nodes are assigned to the core nodes they primarily depend on.

[0072] Furthermore, the algorithm attempts to balance the data distribution across all partitions. This approach essentially tries to group frequently queried nodes together while maintaining a balanced data distribution.

[0073] Subsequently, based on the above partitioning method, a two-level partitioning scheme was implemented, which divides the instances in the first-level data partition into second-level data partitions, further reducing the data access required for query responses.

[0074] To improve query efficiency, several key indexes were designed. Finally, a query execution module is provided that accepts SPARQL queries and converts them into Spark SQL using the generated indexes and data statistics, which is then executed by Spark.

[0075] Figure 3 A schematic diagram illustrating the principle framework of the data query method in an embodiment of this application is shown. For example... Figure 3 As shown, the input to this embodiment is an RDF dataset. The scheme divides it into different primary and secondary data partitions, and then stores these data partitions separately on HDFS. The scheme then accepts a SPARQL query, converts the SPARQL into Spark SQL that Spark can recognize based on the previous partitioning information, and submits it to Spark for querying. HDFS (Hadoop Distributed File System) is a distributed file system, part of the Apache Hadoop project, used for storing and processing large amounts of data on commodity hardware clusters. HDFS is designed specifically for large-scale data processing.

[0076] Continue to refer to Figure 3 As shown, during RDF data storage, the data partitioner module is responsible for dividing the RDF dataset into multiple primary data partitions (partition 1, partition 2, ...). Within each primary partition, further subdivisions can be created to form secondary data partitions (VP ​​1, VP 2, ...). Simultaneously, index information (Indexes) corresponding to the data partition structure can be constructed, specifically including the primary partition schema index, secondary partition VP index, and instance index. After partitioning, the data is stored on the HDFS system, with one HDFS file for each secondary partition.

[0077] When performing RDF data queries, the partition finder module is responsible for parsing the query statement and calculating the primary and secondary data partitions of the data to be queried based on the query statement and index information. The SQL translator module constructs the retrieval statement SQL based on the query statement and the calculated data partition information, and then hands it over to the Spark big data computing engine for execution, finally outputting the query result answer.

[0078] Figure 4 A flowchart illustrating a method for dividing a primary data partition into regions, as shown in one embodiment of this application, is presented. Figure 4 As shown, based on the above embodiments, the method for dividing the region of a first-level data partition may include the following steps S410 to S440.

[0079] S410: Retrieve the complete pattern graph stored in the graph database. Nodes in the complete pattern graph are used to represent subjects or objects, and edges in the complete pattern graph are used to represent predicates.

[0080] S420: Traverse the complete pattern graph to obtain the density relationship between nodes. The density relationship includes importance parameters and dependency parameters. The importance parameter is used to represent the importance of each node in the complete pattern graph, and the dependency parameter is used to represent the degree of dependency between any two nodes.

[0081] S430: Select a preset number of core nodes from the complete pattern diagram based on the importance parameter. The core nodes are the nodes with the highest importance parameter in the complete pattern diagram.

[0082] S440: Assign each node in the complete schema graph to a first-level data partition centered on the core node based on the dependency parameters.

[0083] Taking an RDF schema graph as an example, the K most important nodes are selected from the RDF schema graph based on importance parameters as the core nodes for each partition (one core node corresponds to one partition). The remaining nodes are then assigned to the core nodes they primarily depend on based on dependency parameters to construct the partitions. Simply put, a core node plus a group of nodes that heavily depend on it constitutes a partition.

[0084] In an RDF graph dataset, a core node is characterized by two features: first, this node has a higher coreness than other nodes in the RDF schema graph; second, this node has more instances than other nodes.

[0085] In one embodiment of this application, the complete pattern graph is a directed graph, and the method for determining the importance parameter includes: determining the shortest path between two nodes according to the predicate direction to obtain the shortest path set of the complete pattern graph; calculating the distribution ratio of each node in the shortest path set to obtain the core degree parameter of the node; and determining the importance parameter of the node based on the core degree parameter and the number of instances of the node.

[0086] In one application scenario of this application, the coreness of a node in an RDF schema graph can be quantified by calculating how many shortest paths between all other node pairs pass through that node. In other words, the more involved a node is in the shortest paths between other nodes in the RDF schema graph, the more important it is.

[0087] Figure 5 This diagram illustrates an RDF schema diagram of an embodiment of this application in an application scenario. Figure 5 As shown, it is clear from experience that node D is the most important. The quantitative basis is that, in the RDF schema graph, apart from node D, many of the shortest paths between other nodes pass through node D, while for other nodes, the shortest paths passing through them are much fewer.

[0088] In one embodiment of this application, determining the shortest path between two nodes according to the predicate pointer to obtain the shortest path set of the complete pattern graph may include: traversing the complete pattern graph to obtain node pairs consisting of any two nodes; determining all node pair paths with the node pair as the start and end point according to the predicate pointer; and comparing the lengths of the node pair paths to obtain the shortest path set of the node pairs.

[0089] For example, let all the nodes at level 1 in the pattern graph be denoted as topLevelNodes. Level 1 means that no other node points to it. Figure 5 Nodes A, B, and C in the diagram are the first-level nodes.

[0090] Iterate through topLevelNodes and set the current node as currentNode.

[0091] Iterate through all nodes in the next level of the current node, and denote them as nextLevelNode. For each nextLevelNode, form a separate path with the parent node. For example, if the parent node is node 1 and the parent nodes are nodes 2 and 3, then node pair path 12 and node pair path 13 can be formed. Add the path to the path collection pathList.

[0092] Using nextLevelNode as currentNode, repeat the above steps until there are no more nodes at the next level. At this point, the path list contains all possible paths from all nodes at the first level to all nodes at the last level.

[0093] Iterate through all node pairs, and search the path list for paths that contain both nodes. Copy the two nodes and all nodes between them from these paths, creating a single node pair path and adding it to the pair path list. Each node pair corresponds to a single node pair path list.

[0094] Remove duplicates from the pairPathList of the nodes. The size of the deduplicated set is the total number of paths between the two nodes. Then compare the pairs to find the shortest path and set it as the shortestPathList.

[0095] In one embodiment of this application, the process of calculating the distribution ratio of each node in the shortest path set to obtain the core degree parameter of the node may further include: for a selected node pair, counting the number of all shortest paths in the shortest path set to obtain a first path count; for a selected node, counting the number of shortest paths in the shortest path set that contain the selected node to obtain a second path count; obtaining the ratio of the second path count to the first path count to obtain the distribution ratio of the selected node in the shortest path set of the selected node pair; and summing the distribution ratios corresponding to each node and each node pair to obtain the core degree parameter of the node.

[0096] In one application scenario of this application embodiment, the coreness of any node n in the RDF schema graph can be expressed as:

[0097]

[0098] in, This represents the total number of shortest paths from node s to node t. It is the number of paths that pass through node n among these shortest paths.

[0099] The number of paths in the shortest path set shortestPathList can be obtained by counting the number of paths in the above examples.

[0100] The method for determining this could include, for example, creating a hash table `throughPathsMap` where the key is a node and the value is the number of paths in `shortestPathList` that pass through that node. Iterating through `shortestPathList`, assuming the current path is `shortestPath`, for each node traversed by that path, retrieving the corresponding value from `throughPathsMap`. If the value doesn't exist, setting it to 1; otherwise, incrementing the value by 1. For any node `n`, retrieving its corresponding value from `throughPathsMap`. If the value exists, it represents the number of paths passing through `n` among all shortest paths between the node pairs. If value does not exist, then It is 0.

[0101] In one embodiment of this application, determining the importance parameter of a node based on the core degree parameter and the number of instances of the node may include: normalizing the core degree parameter of the node to obtain the normalized core degree of the node; normalizing the number of instances of the node to obtain the normalized number of instances of the node; and summing the normalized core degree and the normalized number of instances to obtain the importance parameter of the node.

[0102] A node has a higher coreity when it is a necessary node in many shortest paths. However, the number of nodes and connections between nodes in an RDF graph can interfere with coreity. To enable fair comparisons across graphs of different sizes and densities and to facilitate subsequent calculations, coreity values ​​need to be converted to a uniform scale.

[0103] For example, the coreness parameter can be normalized according to the following formula in the embodiments of this application:

[0104]

[0105] in, This represents the original value indicating the coreness of node n. Represents the set of all nodes in the RDF schema graph; Indicating all pattern nodes The minimum value; Indicating all pattern nodes The maximum value; the denominator represents The maximum range of values, the numerator represents the current node n. The value is the smallest among all nodes. The difference in values ​​can scale the unified result to between 0 and 1.

[0106] In this way, the interference of node size and node density can be ignored. Even if the original coreness values ​​calculated on different RDF sets are very different, the coreness of each node can be reasonably evaluated on a uniform scale.

[0107] Similar to the coreness parameter, the number of node instances can be normalized using the following formula in this embodiment:

[0108]

[0109] in, This represents the number of instances corresponding to pattern node n; Represents the set of all nodes in the RDF schema graph; This represents the minimum number of instances of all pattern nodes; This represents the maximum number of instances of all pattern nodes.

[0110] Based on this, the importance parameter of the pattern node can be expressed as the following formula:

[0111]

[0112] Based on the importance formula, calculate the importance of each pattern node, select the k most important nodes (k can be specified by the user), and divide the data into k first-level partitions: , , … .

[0113] In one embodiment of this application, the method for determining dependency parameters includes: for a selected node pair, obtaining the length of the shortest path of the selected node pair; determining the dependency parameters of the node pair based on the importance parameters of each node on the shortest path and the length of the shortest path, wherein the dependency parameters are positively correlated with the importance parameters of the starting point on the shortest path, negatively correlated with the importance parameters of other nodes on the shortest path besides the starting point, and negatively correlated with the length of the shortest path.

[0114] In one embodiment of this application, the dependency parameter is also negatively correlated with the density parameter of two adjacent nodes on the shortest path. The density parameter is used to weight the importance parameters of other nodes on the shortest path, excluding the starting point.

[0115] In one application scenario of this application embodiment, two nodes can be calculated according to the following formula. and Dependency parameters between .

[0116]

[0117] in, express and The shorter the path, the weaker the dependency between the two elements. Using a square means that the path length is amplified, which means that the longer the path, the faster the dependency value will decrease. This design helps the algorithm prioritize nodes connected by shorter paths when partitioning data, thus enabling faster location and access to relevant data during query processing. Indicate the importance of the starting node; This represents the cumulative decay of importance from the starting node to the ending node. Importance decreases continuously along the path from the starting node to the ending node, decreasing once at each intermediate node. The decay rate is equal to the density parameter between the current node and the next node. The importance of intermediate nodes ( The higher the density, the greater its contribution to the final dependency; however, this contribution is negative, meaning that a higher density node is more likely to disperse the direct dependencies from the start point to the end point. The density between intermediate nodes and the next node contributes positively to the final dependency; a higher density means that they are more easily associated in queries and should be assigned to the same partition. This indicates the importance of the end node relative to the start node.

[0118] Ultimately, the dependency between two nodes is the importance of the ending node (relative to the starting node) divided by the square of the distance between the two nodes. As the distance between the two nodes increases, their dependency decreases rapidly; the higher the importance of the ending node, the higher the dependency, and vice versa.

[0119] In one embodiment of this application, the method for determining the density parameter may include: obtaining the number of instances of the starting node and the number of instances of the ending node in two adjacent nodes; and determining the density parameter of the two adjacent nodes based on the number of instances of the starting node, the number of instances of the ending node, and the total number of nodes in the complete pattern graph.

[0120] In one embodiment of this application, when the number of instances of the end node is zero, the density parameter is negatively correlated with the total number of nodes in the complete pattern graph; when the number of instances of the end node is not zero, the density parameter is negatively correlated with the total number of nodes in the complete pattern graph, positively correlated with the number of instances of the start node, and negatively correlated with the number of instances of the end node.

[0121] For example, let two adjacent nodes be... and They are connected by the predicate p. The number of instances is Through the predicate p and Connected The number of instances is The total number of nodes in the RDF schema graph is s. .

[0122] like If the value is 0, then the terms connected through the predicate p are... The density is:

[0123]

[0124] To ensure that a meaningful value can be calculated even without instances, the density depends on the number of nodes in the entire pattern graph. The larger the pattern graph (the more nodes), the lower the density. This is easy to understand; the larger the graph, the more complex the relationships, and the less dense the individual relationships become.

[0125] like Then they are connected by the predicate p. The density is:

[0126]

[0127] Figure 6 This illustrates the correspondence between a pattern diagram and the number of instances in an application scenario, as shown in an embodiment of this application. Figure 6 For example, if you want to find a person, the fastest way is to find all the people contained within building X, because the search space is only 30, making the search speed the fastest. However, if you search through country A, the search space is 1.3 billion, making the search speed very slow. Therefore, we can determine that the containment relationship between buildings and people is the strongest. Thus, we can conclude that... The larger the value, the better. Through the predicate p and The closer the relationship.

[0128] Based on the dependencies between the K most important nodes and the remaining nodes, and the upper limit of the pattern nodes for each partition, determine which partition the remaining nodes should be assigned to.

[0129] Since the data distribution may be significantly affected by the characteristics of the dataset. For example, if most of the instance data is only associated with a few schema nodes, it may lead to data skew, that is, a large amount of data accumulates in a single partition. Therefore, set an upper limit on the number of schema nodes for each partition: limit_size = the total number of nodes in the schema graph is s / the number of partitions k. limit_size can ensure the balanced distribution of data across partitions.

[0130] Traverse the nodes in the schema graph other than the top K core nodes with the highest importance, and set them as , calculate its dependency on each core node; select the first-level data partition corresponding to the core node with the greatest dependency as the candidate partition, and set this partition as , set the core node of this partition as , set the existing number of schema nodes of as s . If s < limit_size, then add the schema node , as well as all the schema nodes on the path between it and to the current partition . In other words, if a schema node is assigned to a certain partition, then all the intermediate schema nodes that logically connect this node to the partition core node will also be classified into this partition. Ensure that during query, those schema nodes with close logical connections and their related data entities can be stored together, improving the data cohesion and reducing the cross-partition data retrieval during query, thereby improving the query efficiency.

[0131] Add the instances corresponding to the schema node , as well as all the schema nodes on the path between it and to the current partition. If s >= limit_size, then select the partition with the second greatest dependency as the candidate partition, and repeat the above step until a partition with a large enough space and a high enough dependency between its core node and the current node is selected.

[0132] After the first-level partition is completed, check the schema nodes in each partition. If a node has an attribute association with nodes in other partitions, data copying needs to be performed.

[0133] Figure 7 Shows the result of the first-level data partition of the schema graph in an application scenario of this application embodiment. As Figure 7 shown, a schema graph schema graph is divided into three first-level data partitions.

[0134] As you can see, the F node of partition1 and the G node of partition2, the D node of partition1 and the P node of partition3, and the L node of partition2 and the Q node of partition3 all have attribute associations. At this point, the data of the associated nodes should be copied and placed in the associated partition.

[0135] Figure 8 This illustration shows the partitioning result of copying data from a primary data partition in an application scenario according to an embodiment of this application. For example... Figure 8 As shown, for attribute-related data, there are copies in both related first-level data partitions, which can ensure the integrity of the data and the effectiveness of queries.

[0136] Based on the completion of the first-level data partitioning, the first-level data partitioning can be divided into regions according to the logical relationship represented by the predicate to form the second-level data partitioning.

[0137] For example, embodiments of this application can split the triples in each primary data partition into multiple secondary data partitions based on the predicate. For example, Figure 8 If the primary data partition partition1 contains predicates p1, p2, p3, and p8, then it will eventually be split into four secondary data partitions: p1, p2, p3, and p8.

[0138] Each predicate corresponds to a secondary data partition, generating a separate file stored on HDFS. This design allows only the secondary data partitions related to the query predicate to be loaded during a query, greatly reducing the amount of data accessed.

[0139] If an instance is connected to other nodes in different partitions using different predicates, then this instance will have a copy in each second-level data partition. This ensures that when querying these partitions, the instance's information can be directly retrieved without needing to search across partitions. Complete information that would previously require cross-partition queries can now be obtained through copies within local partitions, reducing the amount of data that must be accessed during queries. Therefore, although there is some data storage redundancy, data access efficiency is greatly improved.

[0140] Continue to refer to Figure 3 As shown, in the data storage section, in order to speed up the query calculation process, some indexes need to be created so that the necessary sub-partitions can be located directly during query execution.

[0141] Since the above partitioning method is based on the schema of the RDF dataset, we can first establish a mapping relationship between the schema node and its corresponding first-level data partition, called the schema index. The index structure is as follows:

[0142] Schema Node -> Partition ID

[0143] Person1

[0144] Professor1

[0145] Publication 2

[0146] Secondly, the primary data partition is split into multiple secondary data partitions, and a mapping relationship is established between the schema node and the corresponding secondary data partition, called the secondary data partition index (VP Index). The index structure is as follows:

[0147] Schema Node ->Vertical Partitions

[0148] Personadvisor,affiliatedOf,subClassOf

[0149] Professoradvisor, subClassOf

[0150] PublicationpublicationResearch,orgPublication, subClassOf

[0151] Finally, the mapping relationship between instances and their corresponding schema nodes is established, called the instance index, with the following structure:

[0152] Instance -> Schema Node

[0153] Rosa Person

[0154] Robert Person

[0155] Doc Wang Professor

[0156] Book xPublication

[0157] Paper yPublication

[0158] The above three types of indexes are stored in HDFS.

[0159] Continue to refer to Figure 3 As shown, in the data query section, data queries can be initiated based on SPARQL.

[0160] SPARQL is a W3C-recommended standard RDF graph matching language that matches data in an RDF graph by defining a graph pattern. This pattern consists of triples, each containing a subject, a predicate, and an object.

[0161] For example, SELECT The expression `WHERE {xiaowang advisor ?professors}` queries Xiaowang's advisors. Another example is `SELECT ...`. The query `WHERE {laoli teacherOf ?students}` retrieves the students of laoli.

[0162] The query processing module accepts SPARQL input from the user, parses it, automatically converts it into SQL, and then calls the SparkSQL interface to perform the query.

[0163] Variables refer to placeholders or undefined specific values ​​used in SPARQL queries. They begin with a question mark (?), such as in "xiaowang advisor ?professors," where "?professors" is a variable representing the tutors being searched for. In a SPARQL query, these variables represent the actual data items the queryer wants to match or retrieve, but their specific values ​​are unknown at the time of query definition. When this query is executed, the SPARQL engine attempts to match these variables with the actual nodes in the RDF graph to find all combinations of triples that meet the criteria.

[0164] Create a query partition information structure to record all first-level and second-level data partitions that need to be accessed during query execution.

[0165] Extract all triples (one or more) from the query. Let the variables of known types and their corresponding types be variableSchemaMap. Since the query may involve multiple triples, and multiple triples may have the same variables, variableSchemaMap is used to facilitate these variables sharing the same schema.

[0166] Iterate through all triples, and let a single triple be p( , The goal is to find the first-level and second-level data partitions corresponding to the triplet.

[0167] set up , The instance in the context is nodeInstances;

[0168] extract , Let the variables in the file be defined as variables;

[0169] set up , The corresponding schema nodes are schemaNodes;

[0170] If p == rdf:type, then It is a schema node; add it to schemaNodes. If If it belongs to variables, then its corresponding schema is... , will , Add variableSchemaMap. The rdf:type attribute in RDF indicates that a resource belongs to a certain type, for example: <alive> rdf:type <book>This indicates that "To Live" is an instance of the class Book.

[0171] If p==rdf:type is not satisfied, the composition of the triple can be divided into the following cases.

[0172] ?x advisor y, where the predicate and object are known, and the subject is unknown (advisor is an example of a predicate).

[0173] x advisor ?y, where the subject and predicate are known, but the object is unknown.

[0174] x ? ?y, where the subject, predicate, and object are unknown.

[0175] Given x and y, where object, subject, and predicate are unknown.

[0176] x ? y, where the subject and object are known, and the predicate is unknown.

[0177] In the above scenarios, at least one of x and y is an instance (or both). If x is not a variable, x is found through the instance index and added to the schemaNodes. If y is not a variable, y is found through the instance index and its corresponding schema is added to the schemaNodes.

[0178] Another scenario is when the query extracts multiple triples, such as two. The first triple is: ?x rdf:type y, and the second triple is: ?x advisor ?y.

[0179] If two triples contain the same variable ?x, the schema of variable ?x can be determined through the first triple. Following the logic above, this will...<?x y> By adding variableSchemaMap, when processing the second triple, the corresponding schema can be directly obtained from variableSchemaMap and added to schemaNodes.

[0180] Traverse schemaNodes, find the first-level partition ID corresponding to the schema node through the schema index, and add it to the partitions variable.

[0181] `schemaNodes` may contain multiple schema nodes, and correspondingly, `partitions` may also contain multiple partitions. For example, in the case of `x ? y` mentioned above, `x` and `y` are assigned to different first-level partitions. In this case, following the partitioning process, instance data for `x` and `y` can be found in both partitions. The smallest partition (based on the number of instances it contains, the larger the number) is selected as the final partition (`finalPartition`), because a smaller partition results in higher query efficiency.

[0182] If the predicate is a variable, the corresponding secondary data partition (one or more) is found in the secondary data partition index (VP Index) through the schema node in schemaNodes; if the predicate is not a variable, it is itself a secondary data partition.

[0183] For example, the query statement is as follows:

[0184] SELECT?XWHERE{

[0185] ?Xrdfs:typePublication.

[0186] ?XpublicationAuthorAssistantProfessor0.

[0187] }

[0188] This contains two triples. The first triple indicates that the type of the object (?X) to be queried is Publication, and the second triple indicates that the author of the publication (?X) is AssistantProfessor0. In summary, the query should find publications whose author is AssistantProfessor0.

[0189] The first triple satisfies the condition p == rdf:type, therefore Publication is a schema node, and it is added to schemaNodes. It also satisfies... Since it falls under the condition of variables, the schema corresponding to the variable ?X is Publication. Add Publication to the variableSchemaMap. Find the first-level data partition (let's say p1) corresponding to Publication through the first-level data partition index (Schema Index). Since the predicate is fixed (rdf:type), the corresponding second-level data partition is directly derived as type.

[0190] In the second triple, AssistantProfessor0 is an instance. The schema node corresponding to the AssistantProfessor0 instance can be found through the instance index and added to schemaNodes. Based on the first-level data partition (let's assume it's p2) corresponding to the schema node of AssistantProfessor0, the corresponding second-level data partition can be directly deduced to be publicationAuthor.

[0191] To generate the final SQL query, each triple in the query is transformed into an SQL subquery. The table name in each subquery's FROM clause corresponds to a vertically partitioned table based on a predicate. The parsed first-level and second-level partition information is used to locate this table. Then, if the query involves multiple triples that contain common variables, these common variables are used to join all subqueries.

[0192] Iterate through each triple in the query and convert it into an SQL subquery based on the triple information and its parsed partition information.

[0193] The SQL FROM clause is constructed by determining the table to be queried based on the confirmed primary and secondary data partitions. For example, if the primary partition corresponding to the first triplet is p1 and the vertical partition is type, then the FROM clause is: FROM p1_type. If the primary partition corresponding to the second triplet is p2 and the vertical partition is publicationAuthor, then the FROM clause is: FROM p2_publicationAuthor.

[0194] The SQL SELECT clause is constructed as follows: The ?x in the triple consists of two parts: ? and x. ? represents the object to be queried, and x represents an alias. The position of ?x in the triple determines which of the following objects—subject, predicate, or object—is being retrieved. For example, in the first triple, ?X represents the object to be retrieved as 'subject', with the alias 'X', so the SELECT clause is: SELECT subject AS X. In the second triple, ?X represents the object to be retrieved as 'subject', with the alias 'X', so the SELECT clause is: SELECT subject AS X.

[0195] The SQL WHERE clause is constructed using the `subject` and `object` elements in a triplet. If these are not variables, they can be used as query conditions. For example, in the first triplet, `Publication` corresponds to `object`, which can be translated as `WHERE object="Publication"`. In the second triplet, `AssistantProfessor0` corresponds to `object`, which can be translated as `WHERE object='AssistantProfessor0'`.

[0196] The completed FROM, SELECT, and WHERE clauses are concatenated into a complete SELECT statement. For example, the SELECT statement corresponding to the first triplet is: `SELECT subject ASX FROM p1_type WHERE object="Publication"`. The SELECT statement corresponding to the second triplet is: `SELECT subject ASX FROM p2_publicationAuthor WHERE object="AssistantProfessor0"`.

[0197] The above describes the case where only one second-level data partition is resolved from the triple. If the predicate in the triple is a variable, multiple second-level data partitions may be resolved. In this case, each second-level data partition successfully resolves a sub-SQL statement, and then the multiple SQL statements are combined to form the final SQL statement.

[0198] For example, if the triple is ?X?AssistantProfessor0, the corresponding Schema Node is found in the instance index based on AssistantProfessor0, the corresponding first-level data partition is found in the first-level data partition index Schema Index as p1, and then the corresponding second-level data partitions are found in the second-level data partition index as vp1 and vp2.

[0199] The final parsed SQL is:

[0200] select subject from p1_vp1 where object=' AssistantProfessor0'

[0201] union

[0202] select subject from p1_vp2 where object='AssistantProfessor0'.

[0203] If a query contains multiple triples, these triples must share a common variable, and the subqueries corresponding to these triples must be related. The subqueries need to be linked together based on this common variable to form a complete query. Each of the multiple triples corresponds to a field, and these fields serve as the join conditions for the multiple SELECT statements. During the join, each subSELECT statement is given an alias in the order of tab0, tab1, tab2…tabn.

[0204] For example, if two triples share a common variable ?X, the resulting SQL will be as follows:

[0205] SELECT tab1.XASXFROM

[0206] (SELECTsubjectASXFROMp1_type

[0207] WHEREobject='Publication')AStab0,

[0208] (SELECTsubjectASXFROMp2_publicationAuthor

[0209] WHEREobject='AssistantProfessor0')AStab1

[0210] WHERE tab0.X=tab1.X

[0211] Finally, the generated SQL can be executed by Spark.

[0212] As described in the above application scenarios, the embodiments of this application can effectively partition RDF data. It can effectively group highly correlated data together, minimize the amount of data accessed during queries, and maintain a balanced distribution. During queries, based on the partitioning information of the RDF data, general query statements are converted into SQL statements that Spark can recognize, improving query performance.

[0213] It should be noted that although the steps of the method in this application are described in a specific order in the accompanying drawings, this does not require or imply that the steps must be performed in that specific order, or that all the steps shown must be performed to achieve the desired result. Additional or alternative steps may be omitted, multiple steps may be combined into one step, and / or one step may be broken down into multiple steps.

[0214] The following describes an embodiment of the apparatus of this application, which can be used to execute the data query method in the above embodiments of this application.

[0215] Figure 9 A schematic block diagram of the data query device provided in an embodiment of this application is shown. Figure 9 As shown, the data query device 900 includes:

[0216] The parsing module 910 is configured to parse a data query request to obtain query conditions. The query conditions include one or more of a subject, an object, and a predicate. The predicate is used to represent the logical relationship between the subject and the object.

[0217] The partitioning module 920 is configured to determine the target data partition in the graph database according to the query conditions. The graph database includes a first-level data partition obtained by dividing the region according to the density relationship between nodes, and the first-level data partition includes a second-level data partition obtained by dividing the region according to the logical relationship between nodes.

[0218] The retrieval module 930 is configured to retrieve data query results that match the query conditions in the target data partition.

[0219] In some embodiments of this application, based on the above technical solutions, the partitioning module 920 may further include:

[0220] The pattern graph acquisition module is configured to acquire a complete pattern graph stored in a graph database, wherein the nodes in the complete pattern graph are used to represent subjects or objects, and the edges in the complete pattern graph are used to represent predicates.

[0221] The density determination module is configured to traverse the complete pattern graph to obtain the density relationship between nodes. The density relationship includes an importance parameter and a dependency parameter. The importance parameter is used to represent the importance of each node in the complete pattern graph, and the dependency parameter is used to represent the degree of dependency between any two nodes.

[0222] The core node selection module is configured to select a preset number of core nodes from the complete pattern diagram based on the importance parameter, wherein the core nodes are the nodes with the highest importance parameter in the complete pattern diagram;

[0223] The node allocation module is configured to allocate each node in the complete pattern graph to a first-level data partition centered on the core node, based on the dependency parameters.

[0224] In some embodiments of this application, based on the above technical solutions, the complete pattern graph is a directed graph, and the density determination module includes:

[0225] The shortest path set acquisition module is configured to determine the shortest path between two nodes according to the predicate, thereby obtaining the shortest path set of the complete pattern graph;

[0226] The distribution ratio statistics module is configured to calculate the distribution ratio of each node in the shortest path set to obtain the core degree parameter of the node.

[0227] The importance parameter determination module is configured to determine the importance parameter of the node based on the coreness parameter and the number of instances of the node.

[0228] In some embodiments of this application, based on the above technical solutions, the shortest path set acquisition module is further configured to: traverse the complete pattern graph to obtain node pairs consisting of any two nodes; determine all node pair paths with the node pair as the starting point and the ending point according to the predicate; compare the lengths of the node pair paths to obtain the shortest path set of the node pair.

[0229] In some embodiments of this application, based on the above technical solutions, the distribution ratio statistics module is further configured to: for a selected node pair, count the number of all shortest paths in the shortest path set to obtain a first path count; for a selected node, count the number of shortest paths in the shortest path set that contain the selected node to obtain a second path count; obtain the ratio of the second path count to the first path count to obtain the distribution ratio of the selected node in the shortest path set of the selected node pair; and accumulate the distribution ratios corresponding to each node and each node pair to obtain the core degree parameter of the node.

[0230] In some embodiments of this application, based on the above technical solutions, the distribution ratio statistics module is further configured to: normalize the core degree parameter of the node to obtain the normalized core degree of the node; normalize the number of instances of the node to obtain the normalized number of instances of the node; and sum the normalized core degree and the normalized number of instances to obtain the importance parameter of the node.

[0231] In some embodiments of this application, based on the above technical solutions, the tightness determination module includes:

[0232] The length acquisition module is configured to acquire the length of the shortest path of a selected pair of nodes.

[0233] The dependency parameter determination module is configured to determine the dependency parameters of the node pairs based on the importance parameters of each node located on the shortest path and the length of the shortest path. The dependency parameters are positively correlated with the importance parameters of the starting point on the shortest path, negatively correlated with the importance parameters of other nodes on the shortest path besides the starting point, and negatively correlated with the length of the shortest path.

[0234] In some embodiments of this application, based on the above technical solutions, the dependency parameter is also negatively correlated with the density parameter of two adjacent nodes on the shortest path. The density parameter is used to weight the importance parameters of other nodes on the shortest path other than the starting point.

[0235] In some embodiments of this application, based on the above technical solutions, the method for determining the density parameter includes: obtaining the number of instances of the starting node and the number of instances of the ending node in two adjacent nodes; and determining the density parameter of the two adjacent nodes based on the number of instances of the starting node, the number of instances of the ending node, and the total number of nodes in the complete pattern graph.

[0236] In some embodiments of this application, based on the above technical solutions, when the number of instances of the end node is zero, the density parameter is negatively correlated with the total number of nodes in the complete pattern graph; when the number of instances of the end node is not zero, the density parameter is negatively correlated with the total number of nodes in the complete pattern graph, positively correlated with the number of instances of the start node, and negatively correlated with the number of instances of the end node.

[0237] The specific details of the data query device provided in the various embodiments of this application have been described in detail in the corresponding method embodiments, and will not be repeated here.

[0238] Figure 10 A schematic block diagram of a computer system architecture for implementing an electronic device according to embodiments of the present application is shown.

[0239] It should be noted that, Figure 10 The computer system 1000 of the electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0240] like Figure 10 As shown, the computer system 1000 includes a central processing unit (CPU) 1001, which can perform various appropriate actions and processes based on programs stored in read-only memory (ROM) 1002 or programs loaded from storage section 1008 into random access memory (RAM). The RAM 1003 also stores various programs and data required for system operation. The CPU 1001, ROM 1002, and RAM 1003 are interconnected via a bus 1004. An input / output interface 1005 (I / O interface) is also connected to the bus 1004.

[0241] The following components are connected to the input / output interface 1005: an input section 1006 including a keyboard, mouse, etc.; an output section 1007 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 1008 including a hard disk, etc.; and a communication section 1009 including a network interface card such as a local area network card, modem, etc. The communication section 1009 performs communication processing via a network such as the Internet. A drive 1010 is also connected to the input / output interface 1005 as needed. A removable medium 1011, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on the drive 1010 as needed so that computer programs read from it can be installed into the storage section 1008 as needed.

[0242] Specifically, according to embodiments of this application, the processes described in the various method flowcharts can be implemented as computer software programs. For example, embodiments of this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 1009, and / or installed from removable medium 1011. When the computer program is executed by central processing unit 1001, it performs various functions defined in the system of this application.

[0243] It should be noted that the computer-readable medium shown in the embodiments of this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination of the two. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, optical fiber, portable compact disc read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this application, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this application, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such transmitted data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. The computer-readable signal medium can also be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to wireless, wired, etc., or any suitable combination thereof.

[0244] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0245] It should be noted that although several modules or units for the device used to perform actions have been mentioned in the detailed description above, this division is not mandatory. In fact, according to the embodiments of this application, the features and functions of two or more modules or units described above can be embodied in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided and embodied by multiple modules or units.

[0246] Through the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, touch terminal, or network device, etc.) to execute the methods according to the embodiments of this application.

[0247] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein.

[0248] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.< / book>

Claims

1. A data query method, characterized by, include: Parse the data query request to obtain query conditions, which include one or more of a subject, an object, and a predicate, wherein the predicate is used to represent the logical relationship between the subject and the object; The target data partition in the graph database is determined based on the query conditions. The graph database includes a first-level data partition obtained by dividing the region according to the density relationship between nodes. The first-level data partition includes a second-level data partition obtained by dividing the region according to the logical relationship between nodes. Retrieve data query results that match the query conditions in the target data partition; The method for partitioning the first-level data partition includes: acquiring a complete pattern graph stored in a graph database, where nodes in the complete pattern graph represent subjects or objects, and edges in the complete pattern graph represent predicates; traversing the complete pattern graph to obtain the density relationship between nodes, where the density relationship includes an importance parameter and a dependency parameter, where the importance parameter represents the importance of each node in the complete pattern graph, and the dependency parameter represents the degree of dependency between any two nodes; selecting a preset number of core nodes from the complete pattern graph based on the importance parameter, where the core nodes are the nodes with the highest importance parameter in the complete pattern graph; and assigning each node in the complete pattern graph to a first-level data partition centered on the core nodes based on the dependency parameter. The method for determining the dependency parameters includes: for a selected pair of nodes, obtaining the length of the shortest path of the selected pair of nodes; determining the dependency parameters of the pair of nodes based on the importance parameters of each node on the shortest path and the length of the shortest path, wherein the dependency parameters are positively correlated with the importance parameters of the starting point on the shortest path, negatively correlated with the importance parameters of other nodes on the shortest path besides the starting point, and negatively correlated with the length of the shortest path.

2. The data query method of claim 1, wherein, The complete pattern graph is a directed graph, and the method for determining the importance parameter includes: The shortest path between two nodes is determined according to the predicate, thus obtaining the shortest path set of the complete pattern graph; The distribution ratio of each node in the shortest path set is statistically analyzed to obtain the core degree parameter of the node. The importance parameter of a node is determined based on the coreness parameter and the number of instances of the node.

3. The data query method of claim 2, wherein, The shortest path between two nodes is determined according to the predicate, resulting in the shortest path set of the complete pattern graph, including: Traverse the complete pattern graph to obtain node pairs consisting of any two nodes; Determine all node pair paths with the node pair as the start and end point according to the predicate; By comparing the lengths of the paths of the node pairs, the set of shortest paths for the node pairs is obtained.

4. The data query method of claim 2, wherein, The distribution ratio of each node in the shortest path set is statistically analyzed to obtain the core degree parameter of the node, including: For a selected pair of nodes, count the number of all shortest paths in the shortest path set to obtain the first path count; For a selected node, count the number of shortest paths in the shortest path set that contain the selected node to obtain the second path count; The ratio of the number of the second path to the number of the first path is obtained to determine the distribution ratio of the selected node in the shortest path set of the selected node pair. The core degree parameter of the node is obtained by summing the distribution ratios corresponding to each node and each node pair.

5. The data query method of claim 4, wherein, The importance parameter of a node is determined based on the coreness parameter and the number of instances of the node, including: The core degree parameter of the node is normalized to obtain the normalized core degree of the node; The number of instances of the node is normalized to obtain the normalized number of instances of the node; The importance parameter of the node is obtained by summing the normalized core degree and the normalized number of instances.

6. The data query method of any one of claims 1 to 5, wherein, The dependency parameter is also negatively correlated with the density parameter of two adjacent nodes on the shortest path. The density parameter is used to weight the importance parameters of other nodes on the shortest path besides the starting point.

7. The data query method of claim 6, wherein, The method for determining the density parameter includes: Get the number of instances of the starting node and the number of instances of the ending node in two adjacent nodes; The density parameter of the two adjacent nodes is determined based on the number of instances of the starting node, the number of instances of the ending node, and the total number of nodes in the complete pattern graph.

8. The data query method of claim 7, wherein, When the number of instances of the ending node is zero, the density parameter is negatively correlated with the total number of nodes in the complete pattern graph; when the number of instances of the ending node is not zero, the density parameter is negatively correlated with the total number of nodes in the complete pattern graph, positively correlated with the number of instances of the starting node, and negatively correlated with the number of instances of the ending node.

Images