Sub-graph matching optimization method based on vertex popularity cache

Abstract

The invention provides a subgraph matching optimization method based on vertex popularity cache. The method comprises the steps that by analyzing a query log, popularity vertexes with popularity within a preset range are recognized; a global popularity vertex cache is constructed, and the global popularity vertex cache is stored in a main node and comprises popularity vertexes and complete information of multi-hop neighbors of the popularity vertexes; after a query request is received, whether query is selective query meeting a preset condition or not is judged; if yes, executing cache coverage check, and verifying whether the query can be covered by the global popularity vertex cache or not; if the query is covered by the global popularity vertex cache, executing a subgraph matching algorithm on the main node to complete the query; otherwise, the query is distributed to the distributed sub-nodes, and distributed sub-graph matching calculation is carried out based on the partial evaluation framework. The problem that a large number of invalid intermediate results are generated is solved, and the query efficiency is remarkably improved.

Description

Technical Field

[0001] The present disclosure relates to the field of information technology, and in particular to a subgraph matching optimization method based on vertex heat cache. Background Art

[0002] With the widespread application of graph data in fields such as social networks, bioinformatics, and recommender systems, subgraph matching has become a critical task in graph computing. However, as graph data continues to grow in size, traditional single-machine subgraph matching algorithms face challenges such as limited computing resources and data transmission bottlenecks, making it difficult to efficiently process large-scale graph data. Therefore, distributed subgraph matching algorithms have emerged. By partitioning graph data across multiple computing nodes and executing queries in parallel, they significantly improve the efficiency of subgraph matching.

[0003] Distributed subgraph matching algorithms demonstrate significant advantages when processing large-scale graph data, but partitioning data into multiple partitions also presents new challenges. Specifically, the distributed storage of graph data requires accessing nodes across partitions during queries, resulting in significant message passing overhead. Distributed subgraph matching algorithms based on a partial evaluation framework divide the query process into two phases: partial evaluation and centralized computation. In the partial evaluation phase, independent partial matching computations are performed on each partition, effectively reducing message passing overhead.

[0004] However, this approach introduces a new problem, namely, poor support for highly selective queries. Highly selective queries refer to queries in which certain query vertices specify specific Uniform Resource Identifiers (URIs). Such queries can quickly locate specific data vertices through URIs, greatly reducing the search space of the query. However, under the partial evaluation framework, it is necessary to expand partial matches for the query as much as possible in each partition. This results in only being able to obtain matching results for other parts of the query if the URI information specified in the query does not exist in the partition. Due to the lack of pruning capabilities for vertices that specify specific URIs, algorithms based on the partial evaluation framework have to search for partial matches for the query across the entire partition, greatly increasing the search space of the query and generating a large number of invalid partial match results. Enumerating these invalid partial match results wastes a lot of time.

[0005] gStoreD is a distributed subgraph matching system based on a partial evaluation framework, using gStore as its underlying computing engine. Based on the partial evaluation framework, gStoreD distributes graph data across all nodes in a distributed cluster, with each node containing partial graph data. Queries are then fully distributed to all nodes, with each node receiving the complete query. Partial matching results for the query are then calculated on each node. Partial matching results refer to matching results for the query, but some query vertices are allowed to have no matching data vertices. Partial matching results are matching results for all connected subgraphs of the complete query. The partial matching results are then sent to the master node for assembly to obtain the final complete matching result. Figure 1 The overall process of the distributed subgraph matching method based on the partial evaluation framework is given.

[0006] gStoreD's computational approach faces certain limitations when processing highly selective queries. The partial evaluation framework divides graph data into multiple partitions, each containing only a portion of the graph data. The partial evaluation framework allows queries to obtain possible partial results, which means that in some partitions without information about highly selective vertices, queries can only match other subgraphs in the query. Due to the lack of pruning capabilities for highly selective vertices, this results in queries generating a large number of invalid intermediate results. gStoreD prunes partial matches by pre-communicating candidate sets and using LEC features. The pre-communicating candidate set approach can prune many impossible partial matching results, but in the way gStoreD calculates candidate sets, each query vertex only considers its direct neighbor information, resulting in poor utilization of the pruning capabilities for highly selective vertices. Summary of the Invention

[0007] In response to the above problems, the present disclosure proposes a distributed subgraph matching optimization method based on vertex heat cache. This method identifies frequently accessed vertices by analyzing query logs and defines them as high-heat vertices. Furthermore, these high-heat vertices and their multi-hop neighbor information are cached in the master node to build a global high-heat vertex cache. When calculating highly selective queries, the system uses a cache coverage method to check whether the information in the global high-heat vertex cache can meet the needs of the current query. If so, the calculation is completed directly on the master node, avoiding the problem that some evaluation frameworks have difficulty using highly selective vertices to narrow the search space.

[0008] The present disclosure provides a subgraph matching optimization method based on vertex heat cache, comprising: identifying hot vertices whose heat is within a preset range by analyzing query logs; constructing a global hot vertex cache, wherein the global hot vertex cache is stored in a master node and includes complete information of the hot vertices and their multi-hop neighbors; after receiving a query request, determining whether the query is a selective query that meets preset conditions; if so, performing a cache coverage check to verify whether the query can be covered by the global hot vertex cache; if the query is covered by the global hot vertex cache, executing a subgraph matching algorithm on the master node to complete the query; otherwise, distributing the query to distributed child nodes, and performing distributed subgraph matching calculations based on a partial evaluation framework.

[0009] In some embodiments, the subgraph matching optimization method based on vertex heat cache further includes: regularly updating the global heat vertex cache based on the query log to ensure the timeliness and hit rate of the cache.

[0010] In some embodiments, identifying hot vertices whose popularity is within a preset range includes: counting the frequency of occurrence of data vertices in a selective query result set; calculating the contribution weight of each data vertex's neighboring vertices within its β-hop range to the query based on a preset number of hops β; and screening out data vertices whose popularity is higher than a preset threshold as hot vertices based on a weighted result of the frequency of occurrence and the contribution weight.

[0011] In some embodiments, performing a cache coverage check includes: traversing all vertices in the query graph, marking selective vertices that specify a specific uniform resource identifier (URI); if the selective vertex matches a vertex in the global hot vertex cache, further marking its neighbor vertices within the coverage hop range; if all marked vertices can cover the connected subgraph of the query graph, then the query is determined to be covered by the cache.

[0012] In some embodiments, constructing a global hot vertex cache includes: collecting 1-hop neighbor information of the hot vertex from distributed child nodes based on the hot vertex set; iteratively expanding to a preset maximum hop number β, and gradually caching the neighbor information of each hop to the main node; establishing a mapping relationship from the vertex to its coverage hop number to ensure that the vertex and its multi-hop neighbor information stored in the cache can independently support matching queries.

[0013] In some embodiments, regularly updating the global hot vertex cache based on the query log includes: periodically analyzing the latest query log to re-identify hot vertices; rebuilding the global hot vertex cache based on the updated hot vertex set; and performing cache update operations during system idle periods.

[0014] In some embodiments, when executing the subgraph matching algorithm on the master node, the selective vertex is directly located through the index, and the search space is narrowed based on the multi-hop neighbor information in the cache, thereby reducing the generation of invalid intermediate results.

[0015] In some embodiments, for queries that cannot be covered by the global hot vertex cache, a distributed subgraph matching algorithm based on a partial evaluation framework is used to execute query tasks in parallel on multiple computing nodes, and assemble partial matching results of each partition on the master node.

[0016] In some embodiments, the data vertices whose popularity is higher than a preset threshold are data vertices whose sorting positions are before a preset position (eg, top 10, top 15, etc.) when the weighted results are sorted in descending order.

[0017] In some embodiments, the selective query that meets the preset condition is a query for which there is a query vertex specifying a specific uniform resource identifier.

[0018] The present disclosure proposes a subgraph matching query optimization method based on vertex heat cache, which is called global high-heat vertex cache. This method mines frequently accessed high-heat vertices by analyzing query logs, and caches them and their multi-hop neighbor information in the master node. By using cache coverage technology, highly selective queries that can be calculated using the global high-heat vertex cache are quickly identified, and the calculation of these queries is completed on the master node. This effectively avoids the problem that in a distributed environment, the distributed subgraph matching algorithm based on the partial evaluation framework has difficulty in using highly selective vertices to narrow the search space, thereby generating a large number of invalid intermediate results, and significantly improves query efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] The above and other features, advantages, and aspects of the various embodiments of the present disclosure will become more apparent with reference to the following detailed description in conjunction with the accompanying drawings. Throughout the drawings, the same or similar reference numerals represent the same or similar elements. It should be understood that the drawings are schematic and that components and elements are not necessarily drawn to scale.

[0020] Figure 1 A flowchart of a distributed subgraph matching method based on a partial evaluation framework is shown.

[0021] Figure 2 The workflow of a global hot vertex cache is shown in accordance with some embodiments.

[0022] Figure 3a A distributed RDF graph with two partitions is shown in accordance with some embodiments.

[0023] Figure 3bFIG. 4 shows high-temperature vertex cache information obtained by querying logs according to some embodiments.

[0024] Figure 4a A highly selective query is shown in accordance with some embodiments.

[0025] Figure 4b The corresponding partial matching results using a partial evaluation framework according to some embodiments are shown.

[0026] Figures 5a to 5c shows the average query time after a global hot vertex cache hit according to some embodiments, Figure 5a Corresponding to Q1-Q6, Figure 5b Corresponding to Q7-Q12, Figure 5c Corresponding to Q13-Q18.

[0027] Figure 6 Shown are the hit rates of different types of queries in the global hot vertex cache, according to some embodiments. DETAILED DESCRIPTION

[0028] The following describes embodiments of the present disclosure in more detail with reference to the accompanying drawings. Although certain embodiments of the present disclosure are shown in the accompanying drawings, it should be understood that the present disclosure can be implemented in various forms and should not be construed as limited to the embodiments described herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of the present disclosure. It should be understood that the drawings and embodiments of the present disclosure are for illustrative purposes only and are not intended to limit the scope of protection of the present disclosure.

[0029] It should be understood that the various steps described in the method embodiments of the present disclosure can be performed sequentially and / or in parallel. In addition, the method embodiments may include additional steps and / or omit the steps shown. The scope of the present disclosure is not limited in this respect.

[0030] As used herein, the term "including" and its variations are open-ended, i.e., "including but not limited to." The term "based on" means "based, at least in part, on." The term "one embodiment" means "at least one embodiment," the term "another embodiment" means "at least one additional embodiment," and the term "some embodiments" means "at least some embodiments." Other terms are defined in the following description.

[0031] It should be noted that the concepts of "first" and "second" mentioned in this disclosure are only used to distinguish different devices, modules or units, and are not used to limit the order or interdependence of the functions performed by these devices, modules or units.

[0032] It should be noted that the modification of “one” mentioned in the present disclosure is illustrative rather than restrictive, and those skilled in the art should understand that unless otherwise clearly indicated in the context, it should be understood as “one or more”.

[0033] The present disclosure extracts popular data by identifying the heat information of vertices in graph data, and adopts different execution processes for different query types, combining the advantages of subgraph matching methods based on a single-machine enumeration framework and a partial evaluation framework, and dynamically selecting the best execution strategy. By analyzing query logs, frequently accessed vertices are identified and defined as high-heat vertices. Furthermore, these high-heat vertices and their multi-hop neighbor information are cached in the master node to build a global high-heat vertex cache. When calculating highly selective queries, the system uses a cache coverage method to check whether the information in the global high-heat vertex cache can meet the needs of the current query. If so, the calculation is completed directly on the master node, avoiding the problem that the partial evaluation framework has difficulty in using highly selective vertices to narrow the search space.

[0034] The distributed subgraph matching algorithm based on the partial evaluation framework significantly improves the efficiency of subgraph matching by dividing the graph data into multiple computing nodes and executing query tasks in parallel. However, despite the parallel advantage when processing large-scale graph data, data partitioning also brings challenges. Specifically, since the graph data is divided into multiple partitions, for highly selective queries, it is difficult for some partitions to use specific vertex information to narrow the search space, resulting in a large number of invalid intermediate results. Therefore, the present disclosure proposes a distributed subgraph matching optimization method based on vertex heat cache. This method utilizes the principle of query locality, analyzes query logs, identifies frequently accessed vertices, treats them as high-heat vertices, and caches these high-heat vertices and their multi-hop neighbor information on the master node. This allows highly selective queries that can be covered by the cache to be calculated directly on the master node, avoiding the problem that the partial evaluation framework has difficulty in using highly selective vertices to narrow the search space.

[0035] Figure 2 This paper describes the workflow of the global high-heat vertex cache. On the master node, the global high-heat vertex cache module first pre-processes the query. Specifically, the module first determines whether the query is a highly selective query. For highly selective queries, the module will use the global high-heat vertex cache combined with the cache coverage method to determine whether the query can be matched on the master node. If the query meets the matching conditions, it will be directly calculated locally on the master node, so that high-selectivity vertices can be better utilized to narrow the search space; otherwise, the query request will be forwarded to the child nodes for distributed computing. In addition, the cache update module will regularly perform offline cache updates based on the query log to ensure the timeliness and accuracy of the cached data.

[0036] Figure 3a Given a distributed RDF graph with two partitions. Figure 3b The high-heat vertex cache information is obtained by querying the log. The default number of cache hops is set to 3. The global high-heat vertex cache records the cached vertices and the corresponding coverage of the vertices. For example, for the high-heat vertex v1, it can be guaranteed that all of its 3-hop neighbor information is stored in the cache. And for the 1-hop neighbor v2 of vertex v1, all of its 2-hop neighbor information must be stored in the cache. Figure 4a The highly selective query given in specifies that the URI of the query vertex u1 is CompanyA, that is, v1. If the partial evaluation framework is used, the corresponding partial matching result is as follows Figure 4b As shown, in partition S1, query vertex u1 can be used to speed up the partial matching calculation. However, in partition S2, since there is no information about vertex v1, all possible partial matches will be calculated. A total of 4 partial matching results are found in S2, but only <_, v2, v8, v7> are valid partial matching results, and the other three partial matches are invalid. This situation will be more serious in large-scale data sets. Enumerating a large number of invalid intermediate results will cause a huge waste of performance. Although existing methods use some strategies to prune invalid intermediate results, since there is no highly selective vertex information in the partition, existing methods inevitably require additional message passing overhead. If a global high-heat vertex cache is used, it will be found that the 3-hop neighbors of vertex v1 are all included in the cache, which means that Figure 4a The query in can be matched on the master node. Since the master node uses an extended single-machine enumeration algorithm, it can directly locate the data vertex v1 through the index. Therefore, the query search space can be limited to the 3-hop neighborhood of v1, which greatly reduces the query search space and speeds up query execution.

[0037] The cache coverage check method is used to determine whether the existing cache information can satisfy the query requirements. The cache coverage method checks which highly selective vertices in the query belong to the global hot vertex cache and marks these vertices and their multi-hop neighbors in the query to check whether the cache can cover the query.

[0038] Definition (Cache Coverage): Given a query Q = (V q ,E q ,∑ q , Λ q ), for any vertex u∈V q If u specifies a specific URI, then u.selective = true, match(u) indicates the data vertex that u matches. At the same time, given the vertex set V in the global high-temperature vertex cache c , for any vertex v∈Vc , C h [v] represents the coverage of vertex v. The cache coverage is defined as follows:

[0039] 1. For each vertex u in the query graph Q, if u is a high-selectivity vertex and match(u)∈V c , then mark u and its C in Q h [match(u)] - All neighbor vertices within 1 hop.

[0040] 2. After traversing all vertices in the query graph Q, if there are no two connected unmarked vertices in Q, the query Q is considered to be covered by the global high-temperature vertex cache.

[0041] Algorithm 5 describes the process of cache coverage checking algorithm in detail. The input of this algorithm includes query Q, vertex set V in the global hot vertex cache c And the shortest distance matrix D between query vertices. Among them, the shortest distance matrix D is used to quickly obtain the undirected shortest distance between any two query vertices. The algorithm first initializes an empty set V mark , used to record the marked query vertices (line 1). Then, the algorithm checks each vertex u in the query Q one by one i , to determine whether it is a high selectivity vertex. For each high selectivity vertex, further check its matching vertex match(u i ) belongs to V c (Lines 2-3). If the condition is met, u i All its neighbor query vertices within the coverage hop count minus one are marked as covered (lines 4-7). During the marking process, the algorithm checks the marked set V mark Whether all vertices in the query graph Q are covered. If V mark The number of vertices in is the same as the number of vertices in Q, which means that the existing cached data can completely cover the current query, and the algorithm then returns True (lines 8-9). mark If all query vertices are still not covered, the algorithm will further check the connectivity between unlabeled vertices. If two unlabeled vertices are connected, the cache cannot cover the query (lines 10-13). If all unlabeled vertices in the query graph Q are unconnected, the existing cached data can be considered to fully cover the current query, and the algorithm returns True; otherwise, it returns False.

[0042]

[0043] This paper uses the frequency of occurrence of data vertices in the query log and the contribution of its neighbors within β hops to the query as evaluation indicators of vertex heat, calculates a weight for each vertex appearing in the query log, and identifies the heat of the vertex according to the size of the weight.

[0044] Definition (vertex heat) given a query set Query result set Hop limit β and threshold ε, high-heat vertex set V h is determined as follows: For each query Q i , traverse all its query results For each data vertex v in Q, find its corresponding query vertex u and check the number of neighbor vertices within the hop count β of u as the number of neighbor vertices of data vertex v in Q. i If a data vertex v appears in multiple queries or in multiple results of the same query, all values ​​are added together as the weight. The higher the weight, the higher the popularity.

[0045] It is worth noting that since low-selectivity queries often bring a large number of query results, and in real-world queries, most of the vertices in the results of low-selectivity queries are often not used again in subsequent queries, identifying high-heat vertices for low-selectivity queries often does not bring better performance improvements, but instead causes cache pollution and reduces the cache hit rate. Therefore, this disclosure only analyzes the result set of high-selectivity queries to ensure that the vertices stored in the cache have a high reuse value, thereby effectively improving the cache utilization and query performance. In the subsequent content, unless otherwise stated, the query set mentioned refers to the high-selectivity query set.

[0046]

[0047] Algorithm 6 describes the process of vertex heat identification algorithm. For each query Q in the query set i , calculate an undirected shortest distance matrix D i Used to quickly obtain the shortest distance between two vertices (lines 2-3). The computeShortestDist function calculates the undirected shortest distance between all pairs of nodes in the input query graph and outputs the shortest distance matrix. iFor each data vertex v in each result, find the query vertex u corresponding to v and count the number of neighbors within β hops of this vertex u as the weight (lines 4-9). The function M(v) means getting the query vertex u corresponding to the data vertex v. Sort the weights from large to small, return the vertex sequence sorted by weight, and provide a threshold to prevent too many vertices from being recorded (lines 10-15). Among them, the sort function means sorting the sequence from large to small. The getNext function means getting an element from a sequence in order.

[0048] Next, the present disclosure introduces in detail the construction method of the global high-heat vertex cache. The cache is stored on the master node and is mainly optimized for highly selective queries. This method caches the high-heat vertices and their multi-hop neighbor information in the master node. When the query results can be completely covered by the vertices in the global high-heat vertex cache, the cache can be used directly to calculate the query results, thereby avoiding the additional overhead of distributed computing and improving query performance. In addition, the cache only records the high-heat vertices and their multi-hop neighbor information, and the amount of data is greatly reduced compared to the complete graph data. This greatly reduces the search space of the query and further improves the query efficiency. Therefore, the global high-heat vertex cache is a local subgraph of the query graph. In order to ensure that the global high-heat vertex cache can independently support qualified highly selective queries, the cache needs to save the complete information of the high-heat vertices and their multi-hop neighbors.

[0049] Algorithm 7 presents a global high-heat vertex cache construction algorithm, which collects multi-hop neighbor information of each high-heat vertex in an iterative manner. The input includes the graph partition S, the high-heat vertex set V h , a predefined maximum hop count β. The algorithm will eventually get a global hot vertex cache, which includes a mapping C from cached vertices to covered hop counts. h , as well as the \(1\)-hop neighbor information of all cached vertices, except for vertices with a cache hop count of \(0\).

[0050] The algorithm first initializes the cached vertex set V c , the vertex set V to be processed pending and the mapping C from cached vertices to covered hops h (Lines 1-3). c Refers to the vertex that has a 1-hop neighbor cached on the master node, V pending What is stored is the vertices waiting to be further expanded with 1-hop neighbors, and the high-heat vertex set V h As V pending The algorithm then enters multiple iterations, each of which starts with hop number t = 1 and expands by at most β hops (line 4). Before each iteration, a new neighbor vertex set V is initialized. newand partition vertex array P t (Lines 5-6). New neighbor vertex set V new Used to store the neighbor vertices collected in this round as the vertex set to be processed in the next round of iteration. Partition vertex array P t Used to divide the vertices to be processed into their corresponding partitions and collect neighbor information. S(v) represents the partition to which the vertex v belongs.

[0051] Then V c All pending vertices in the table record the number of hops covered, and group the vertices according to the partitions to which they belong (lines 7-9). Then, the pending vertices are sent to the corresponding partitions to collect the 1-hop neighbor information of the vertices, and the 1-hop neighbor information of the vertices is saved in the master node (lines 10-13). i Indicates that in this round of iteration, it is sent to partition S i cache(N i ) means N i All vertices and the one-hop neighbors of each vertex are stored in the master node. Since the global high-temperature vertex cache requires the complete data in the graph, the data in the global high-temperature vertex cache can be stored according to the data storage method required by the stand-alone system on the host. Then, all the one-hop neighbors of the vertex to be processed are traversed and the ones that are not recorded in V are c The vertices in V are recorded new As the next round of vertices to be processed (lines 14-17). Finally, the vertices processed in this round are added to the cached vertex set V c , and update the pending vertex set V pending The value of V new (Lines 18-19) Then it goes into the next round of iteration until the number of hops reaches the predefined number of hops β.

[0052]

[0053] Compared to traditional distributed subgraph matching methods based on partial evaluation frameworks, this distributed subgraph matching method based on a global hot vertex cache preprocesses highly selective queries on the master node, allowing highly selective queries that can be covered by the cache to be computed there, thereby fully utilizing the pruning capabilities of highly selective vertices. For low-selectivity queries and highly selective queries that cannot be covered by the cache, a partial evaluation framework is used for computation.

[0054] Algorithm 8 gives the detailed process of the distributed subgraph matching algorithm based on the global hot vertex cache. The input of the algorithm includes the partition set S, the query graph Q and the global hot vertex cache C. h. After the query reaches the master node, the master node will first calculate an undirected shortest distance matrix for the query for subsequent cache coverage calculations (lines 1-2). Then, through Algorithm 7, that is, the function checkCacheCoverage, check whether the current query can be covered by the global high-temperature vertex cache. For queries that can be covered by the cache, a stand-alone algorithm is used on the master node to complete the subgraph matching (lines 3-4). Otherwise, the partial evaluation framework is used to complete the subgraph matching calculation, and the partial match is calculated independently on each partition, that is, the function getPartialMatch, and then the partial match is concentrated on the master node for assembly, corresponding to the function assemble (lines 5-9). Finally, the final result after assembly is returned (line 10).

[0055]

[0056] There are generally two existing cache update methods: a least recently used (LRU) cache update strategy and an offline cache update strategy.

[0057] The LRU cache update strategy is an online cache update strategy. Its core concept is to manage the cache based on the "least recently used" principle. When cache space is insufficient, the system prioritizes evicting cache items that have not been accessed in the recent period. The main advantages of this strategy are its simple implementation and its ability to adapt well to dynamically changing data access patterns. It can quickly respond to data access requests and automatically adjust cache contents based on access frequency, thereby improving cache hit rates. However, the LRU strategy also has significant limitations. Because the LRU algorithm does not rely on data weights, cache contamination can occur. Specifically, occasional query results may overwrite cached data vertices with high weights, resulting in a decrease in cache hit rates. Furthermore, because LRU is an online update strategy that requires real-time response to data access requests, it struggles with caches that are heavily updated. In such cases, frequent updates not only increase system overhead but also lead to frequent cache changes, further reducing cache effectiveness.

[0058] In the present disclosure, since the global high-heat vertex cache needs to analyze query logs and needs to collect complete multi-hop neighbor information of high-heat vertices in child nodes, cache updates require a large time overhead. This makes online cache update strategies unacceptable. Online update strategies need to respond to data changes in real time and update cache contents frequently, which will cause system performance to degrade significantly in high-overhead scenarios, especially in distributed environments, where message transmission delays and bandwidth limitations will further aggravate performance issues. The core idea of ​​the offline cache update strategy is to rebuild the cache when the system is idle, rather than updating in real time. The main advantage of this method is that it can perform large-scale data processing when the system load is low, thereby reducing the impact on online service performance. By building the cache in an offline state, system resources can be fully utilized and performance bottlenecks caused by real-time updates can be avoided.

[0059] Therefore, considering the above two solutions, this paper adopts an offline cache update strategy. Whenever a period of time passes or the number of query logs reaches a predetermined threshold, Algorithm 6 is used to restart the identification of high-hot vertices and rebuild the cache.

[0060] To validate the effectiveness of the global hot vertex cache, we conducted experiments on the LUBM synthetic dataset. We compared it with gStoreD, the currently best-performing architecture based on a partial evaluation framework. The results demonstrate that for highly selective queries that hit the cache, query time can be significantly reduced.

[0061] This paper integrates a global high-heat vertex cache by modifying the gStoreD source code. The system was deployed on a server with a 64-core Intel Xeon Silver 4216 @ 2.10GHz CPU, 512GB of memory, a 1920GB solid-state drive, and CentOS 7.6. Three Docker containers were created on the server as distributed nodes. Table 1 shows the test dataset information, and Table 2 shows the query test set.

[0062] Table 1

[0063]

[0064] Table 2

[0065]

[0066] The present disclosure is tested on LUBM datasets of four sizes, and the datasets used are shown in Table 1. In order to comprehensively evaluate the performance of the global high-heat vertex cache, multiple types of queries are designed, and the specific query types are shown in Table 2. The present disclosure only uses high-selectivity query statements as test statements. High-selectivity queries refer to queries in which some query vertices specify specific URIs, while low-selectivity queries refer to queries in which all query vertices are variables. Each group of queries is divided into three categories according to the number of vertices, namely queries with 4 vertices, 5 vertices, and 6 vertices. For each type of query, 6 specific queries are constructed by changing the query structure and the position of the selective vertex in the query. Afterwards, each specific query is further expanded to 10 queries by changing the specific value of the URI of the selective vertex. Therefore, the total number of queries is 180.

[0067] In order to verify the effectiveness of the proposed method, this paper conducted tests from two aspects: one is to evaluate the acceleration effect of the global high-heat vertex cache on highly selective queries; the other is to test the cache hit rate. In terms of evaluating the acceleration effect of highly selective queries, the acceleration effect is quantified by comparing the execution time of the query in the case of cache hits and misses. The experiment selected three groups of queries and measured their execution time on data sets of different sizes. For each group of queries, the average query time was calculated as the basis for performance evaluation. In terms of evaluating the cache hit rate, the query results of the 180 highly selective queries mentioned above were used as query logs to identify high-heat vertices, and the hit rates of the six types of queries proposed in Table 2 were tested on the LUBM20 dataset.

[0068] Figures 5a to 5c The figure shows the performance difference between highly selective queries with cache hits and cache misses. The figure shows the average execution time for cache hits and cache misses for three groups of queries, divided by the number of vertices. As the dataset size increases, the query time for cache misses increases rapidly. This is mainly because the time gStoreD takes to calculate the candidate set for each vertex increases rapidly with the increase in data size.

[0069] The increase in the number of query vertices also leads to longer query times, partly because candidate vertices need to be calculated for more vertices, and partly because more expansion operations increase the search time for matching results. In contrast, the query time for hitting the global high-heat vertex cache is significantly reduced, and its growth trend is relatively stable as the data size increases. This is because queries that hit the cache can directly locate a specific data vertex through the index and expand from that vertex without having to globally calculate the candidate vertex set. Therefore, its search space does not grow rapidly as the size of the dataset increases. In addition, since the global high-heat vertex cache is a subset of the complete dataset, its overall data volume is relatively small, further reducing computational overhead. Although an additional cache coverage check is required, the time for this check is negligible compared to the subgraph matching query time.

[0070] Figure 6 The hit rates of different types of queries in the global high-heat vertex cache are shown. When the number of query vertices is 4, the cache hit rate is high for both chain queries and tree queries. This is because for queries containing 4 vertices, regardless of their structure and where the selective vertices are located, the high-heat vertices can cover all the vertices in the query. However, when the number of query vertices increases to 5, the hit rates of chain queries Q7 to Q9 drop significantly. This is because when the selective vertices are located at both ends of the chain query, no matter how their URIs change, they cannot hit the cache. Furthermore, this situation is even more obvious when the number of query vertices is 6. 13 ~Q 15 At this time, the cache hit is possible only when the selective vertex is in the middle of the query. This shows that as the number of query vertices increases, the cache hit rate becomes significantly more sensitive to the query structure and the position of the selective vertex.

[0071] The present disclosure proposes a subgraph matching query optimization method based on vertex heat cache, which is called global high-heat vertex cache. This method mines frequently accessed high-heat vertices by analyzing query logs, and caches them and their multi-hop neighbor information in the master node. By using cache coverage technology, highly selective queries that can be calculated using the global high-heat vertex cache are quickly identified, and the calculation of these queries is completed on the master node. This effectively avoids the problem that in a distributed environment, the distributed subgraph matching algorithm based on the partial evaluation framework has difficulty in using highly selective vertices to narrow the search space, thereby generating a large number of invalid intermediate results, and significantly improves query efficiency.

[0072] The above description is merely a preferred embodiment of the present disclosure and an illustration of the technical principles employed. Those skilled in the art should understand that the scope of disclosure involved in the present disclosure is not limited to the technical solutions formed by the specific combination of the above-mentioned technical features, but also includes other technical solutions formed by any combination of the above-mentioned technical features or their equivalents without departing from the above-mentioned disclosed concepts. For example, a technical solution formed by replacing the above-mentioned features with (but not limited to) technical features with similar functions disclosed in this disclosure.

[0073] In addition, although each operation is described in a specific order, this should not be understood as requiring these operations to be performed in the specific order shown or in a sequential order. Under certain circumstances, multitasking and parallel processing may be advantageous. Similarly, although some specific implementation details have been included in the above discussion, these should not be interpreted as limiting the scope of the present disclosure. Some features described in the context of a separate embodiment can also be implemented in a single embodiment in combination. On the contrary, the various features described in the context of a single embodiment can also be implemented in multiple embodiments individually or in any suitable sub-combination mode.

[0074] Although the subject matter has been described in language specific to structural features and / or methodological logical acts, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are merely example forms of implementing the claims.

Claims

1. A subgraph matching optimization method based on vertex heat cache, characterized in that: include: By analyzing query logs, identify hot vertices whose popularity is within a preset range; Constructing a global hot vertex cache, which is stored in the master node and includes complete information about the hot vertices and their multi-hop neighbors; After receiving the query request, determine whether the query is a selective query that meets the preset conditions; if so, perform a cache coverage check to verify whether the query can be covered by the global hot vertex cache; If the query is covered by the global hot vertex cache, the subgraph matching algorithm is executed on the master node to complete the query; otherwise, the query is distributed to the distributed child nodes, and distributed subgraph matching calculations are performed based on the partial evaluation framework.

2. The subgraph matching optimization method based on vertex heat cache according to claim 1 is characterized in that: Also includes: The global hot vertex cache is updated regularly based on the query log to ensure the timeliness and hit rate of the cache.

3. The subgraph matching optimization method based on vertex heat cache according to claim 1 is characterized in that: Identifying hot vertices with a heat level within a preset range includes: Count the occurrence frequency of data vertices in the selective query result set; Based on the preset hop number β, the contribution weight of each data vertex's neighbor vertices within its β hop range to the query is calculated; According to a weighted result of the occurrence frequency and the contribution weight, data vertices with a popularity higher than a preset threshold are screened out as hot vertices.

4. The subgraph matching optimization method based on vertex heat cache according to claim 1, characterized in that: Performing a cache coverage check involves: Traverse all vertices in the query graph and mark the selective vertices that specify a specific Uniform Resource Identifier (URI); If the selective vertex matches a vertex in the global hot vertex cache, then the neighbor vertices within the coverage hop range are further marked; If all marked vertices can cover the connected subgraph of the query graph, then the query is determined to be covered by the cache.

5. The subgraph matching optimization method based on vertex heat cache according to claim 1, characterized in that: Building a global heat vertex cache involves: According to the hot vertex set, collect the 1-hop neighbor information of the hot vertex from the distributed child nodes; Iteratively expand to the preset maximum number of hops β, and gradually cache the neighbor information of each hop to the master node; Establish a mapping relationship between vertices and their coverage hop counts to ensure that the vertex and its multi-hop neighbor information stored in the cache can independently support matching queries.

6. The subgraph matching optimization method based on vertex heat cache according to claim 2, characterized in that: Regularly updating the global hot vertex cache based on the query log includes: Periodically analyze the latest query logs and re-identify hot vertices; Rebuild the global hot vertex cache based on the updated hot vertex set; Perform cache updates during system idle time.

7. The subgraph matching optimization method based on vertex heat cache according to claim 1, characterized in that: When executing the subgraph matching algorithm on the master node, the selective vertex is directly located through the index, and the search space is narrowed based on the multi-hop neighbor information in the cache, thereby reducing the generation of invalid intermediate results.

8. The subgraph matching optimization method based on vertex heat cache according to claim 1, characterized in that: For queries that cannot be covered by the global hot vertex cache, a distributed subgraph matching algorithm based on the partial evaluation framework is used to execute query tasks in parallel on multiple computing nodes, and assemble the partial matching results of each partition on the master node.

9. The subgraph matching optimization method based on vertex heat cache according to claim 3, characterized in that: The data vertices whose heat is higher than the preset threshold are the data vertices whose sorting positions are before the preset position when the weighted results are sorted in descending order.

10. The subgraph matching optimization method based on vertex heat cache according to claim 1, characterized in that: A selective query that meets the preset conditions is a query in which there is a query vertex that specifies a specific uniform resource identifier.

Images