A large graph subgraph matching method and system based on multiple GPUs

Abstract

This invention provides a method and system for subgraph matching in large graphs based on multiple GPUs. The method includes dividing a large graph into subgraphs to obtain several subgraphs, including intra-partition subgraphs and cross-partition subgraphs; performing sequential queries on the intra-partition subgraphs to obtain a matching order, and determining a first matching strategy for the intra-partition subgraphs based on the matching order; identifying the hop count of the cross-partition subgraphs and determining a second matching strategy for the cross-partition subgraphs based on the hop count; and integrating the first and second matching strategies through GPUs to complete the matching of the intra-partition subgraphs and the cross-partition subgraphs. This invention can process the subgraph matching problem in parallel on multiple GPUs, overcoming the limitation of graph size on GPU subgraph matching in large graphs.

Description

Technical Field

[0001] This invention belongs to the technical field of parallel computing, specifically relating to a method and system for matching large graph subgraphs based on multiple GPUs. Background Technology

[0002] Despite the widespread attention given to subgraph matching, existing research techniques still have many shortcomings. Furthermore, with the ever-increasing scale of data—for example, Facebook, the largest social networking platform in the US, has 1.12 billion daily active users; Twitter has 417 million monthly active users; QQ in China has 972.4 million monthly active accounts; WeChat has 637 million monthly active users; and Amazon, the largest e-commerce website in the US, has 244 million active users and over 2 billion item sales relationships—traditional subgraph matching methods are no longer sufficient to meet the matching needs of today's large-scale graph data.

[0003] Chinese patent "CN112579835A A Subgraph Matching Method and System, Electronic Device, and Storage Medium" is merely a serialized subgraph matching algorithm, unsuitable for handling large-scale graph data. In "CN109992593A A Large-Scale Data Parallel Query Method Based on Subgraph Matching," a distributed processing approach is used, requiring high communication costs and unsuitable for subgraph matching problems that generate numerous intermediate results. Chinese patent "CN113420187A A GPU Subgraph Matching Method Based on Edge Partitioning" uses GPUs to accelerate the enumeration process of subgraph matching; however, due to the limited memory capacity of a single GPU and the large number of intermediate results generated during the matching process, large-graph subgraph matching problems are difficult to handle on a single GPU. Therefore, we need to research large-graph subgraph matching methods based on multiple GPUs.

[0004] However, research on multi-GPU-based subgraph matching faces the following challenges: (1) How to construct an effective multi-GPU programming model for subgraph matching of large graphs; (2) The multi-GPU programming model involves graph partitioning. If the previous distributed graph partitioning strategy is directly used to generate cross-partition matching solutions, frequent communication between GPUs is required, and the bandwidth of PCIe will become a bottleneck for efficient processing. Secondly, a large number of conditional disagreements will be generated when processing cross-partition subgraphs on the GPU side, which will directly affect the matching efficiency of the GPU; (3) The large graph data structure in real life is complex, and the skewed distribution of vertex degree makes the GPU thread load uneven, which greatly damages the parallel performance of the GPU. Summary of the Invention

[0005] To address the aforementioned technical problems, this invention provides a method, system, device, and readable storage medium for large graph subgraph matching based on multiple GPUs, thereby resolving the technical issues existing in the prior art.

[0006] In a first aspect, the invention provides the following technical solution: a large graph subgraph matching method based on multiple GPUs, the method comprising:

[0007] The large graph is divided into subgraphs to obtain several subgraphs, including subgraphs within a partition and subgraphs spanning multiple partitions.

[0008] Perform sequential queries on the subgraphs within the partition to obtain the matching order of the subgraphs within the partition, and determine the first matching strategy for the subgraphs within the partition based on the matching order;

[0009] Identify the hop count of the cross-partition subgraph and determine a second matching strategy for the cross-partition subgraph based on the hop count;

[0010] The first matching strategy and the second matching strategy are integrated by the GPU to complete the matching of subgraphs within the partition and subgraphs across partitions.

[0011] Compared to existing technologies, the beneficial effects of this application are as follows: This application first divides the large graph into subgraphs to obtain several subgraphs. The subgraph division process is completed through a graph partitioning engine. The balanced deployment of CPUs and multiple GPUs for collaborative computing by the graph partitioning engine makes the workload more balanced and reduces frequent interactions between multiple GPUs. This reduces the impact of limited data access bandwidth between GPUs on the efficient processing of multi-GPU subgraph matching. Then, the subgraphs within each partition are sequentially queried to obtain the matching order of the subgraphs within that partition. Based on the matching order, a first matching strategy for the subgraphs within each partition is determined. By utilizing heterogeneous resources to handle the large graph subgraph matching problem simply and efficiently, the execution efficiency of the subgraph matching algorithm is improved. Next, the hop count of the cross-partition subgraph is identified, and a second matching strategy for the cross-partition subgraph is determined based on the hop count. A zero-copy scheduling strategy and a dynamic adjustment strategy among multiple GPUs are used to dynamically schedule the partition subgraphs to ensure the correctness and completeness of the large graph subgraph matching method. Finally, the first matching strategy and the second matching strategy are integrated by the GPU to complete the matching of the subgraph within the partition with the cross-partition subgraph. This invention can process the subgraph matching problem in parallel on multiple GPUs, solves the limitation of graph size on GPU large graph subgraph matching, and solves the cross-partition subgraph matching problem caused by graph partitioning. Furthermore, combined with the SIMT architecture characteristics of the GPU, it ensures the internal load balancing of the GPU.

[0012] Preferably, the step of dividing the large graph into subgraphs to obtain several subgraphs includes:

[0013] The graph partitioning engine uses the standard graph partitioning method METIS to partition a large graph into subgraphs, resulting in several subgraphs.

[0014] Determine the partition boundary set between each of the subgraphs, and take the subgraph corresponding to the smallest partition boundary set as the subgraph within the partition;

[0015] Determine whether the data edges of each subgraph are cross-partition edges:

[0016]

[0017]

[0018] In the formula, V q To query the vertex set of the graph, Represents vertex f(u) j The sequence number in the subgraph. Represents vertex f(u) i The index in the subgraph, u i ,u j Indicates an edge within a partition or an edge spanning multiple partitions;

[0019] If u exists i ,u j ∈V q , Then u i ,u j For cross-partition edges, and with u i ,u j Determine the cross-regional subgraph centered on the subgraph.

[0020] Preferably, the step of performing sequential queries on the subgraphs within the partition to obtain the matching order of the subgraphs within the partition, and determining the first matching strategy for the subgraphs within the partition based on the matching order, includes:

[0021] A worker thread is created for each GPU, and the matching order of the subgraphs within the partition is determined based on the worker thread and the query graph vertex sorting function f(u), where:

[0022]

[0023] In the formula, deg(u) represents the degree of vertex u, and freq(u.label) represents the frequency of the label of vertex u in the data vertices;

[0024] Based on the breadth-first search algorithm and the matching order, instances within the partition are generated using the worker thread;

[0025] Based on the instances within the partition, a first matching strategy is used to generate the subgraph within the partition using a generation-filtering-connection strategy.

[0026] Preferably, the step of generating a first matching strategy for a subgraph within the partition based on instances within the partition and employing a generation-filtering-joining strategy includes:

[0027] Based on the instances within the partition, kernel_1 is invoked to generate a vertex candidate set cand_;

[0028] Call kernel_2 to perform two-stage filtering, filtering out candidate vertices that cannot match the query point, in order to reduce the size of intermediate candidate results;

[0029] Based on the filtered candidate vertices, kernel_3 is called to generate a candidate edge set;

[0030] The kernel_4 function is called to combine the candidate edge set and generate the first matching strategy for the subgraph within the partition.

[0031] Preferably, the step of identifying the hop count across the partition subgraph and determining the second matching strategy across the partition subgraph based on the hop count includes:

[0032] Identify the number of hops in the cross-partition subgraph and determine whether the number of hops in the cross-partition subgraph is greater than a first preset number;

[0033] If the number of hops in the cross-partition subgraph is not less than the first preset number, then the backtracking method is used to determine the second matching strategy for the cross-partition subgraph.

[0034] If the number of hops in the cross-partition subgraph is greater than the first preset number, then the query graph dynamic adjustment method is used to determine the second matching strategy for the cross-partition subgraph.

[0035] Preferably, the step of determining the second matching strategy for the cross-partition subgraph using a backtracking method if the number of hops across the subgraph is not less than a first preset number includes:

[0036] Perform several depth-first traversals on the cross-partition subgraph to find the vertices of the query graph of the cross-partition subgraph;

[0037] The vertices of the query graph determine the search range of the cross-partition subgraph, and the matching solution of the cross-partition subgraph is determined based on the search range;

[0038] The second matching strategy for the cross-partition subgraph is determined based on the matching solution of the cross-partition subgraph.

[0039] Preferably, if the number of hops in the cross-partition subgraph is greater than a first preset number, the step of determining the second matching strategy for the cross-partition subgraph using the query graph dynamic adjustment method includes:

[0040] Determine whether the number of hops across the subgraph is greater than a second preset number;

[0041] If the number of hops in the cross-partition subgraph is equal to the second preset number, then the cross-partition subgraph is retrieved from the CPU's zero-copy access memory using the GPU and zero-copy technology and fused with the internal graph splitting points. Query graph matching is performed on the cross-partition subgraph and the matching solution of the cross-partition subgraph is calculated to obtain the second matching strategy of the cross-partition subgraph.

[0042] If the number of hops in the cross-partition subgraph is greater than the second preset number, the graph storage on the GPU is adjusted according to the router information of the CPU and the transmitter. The edge point set in the GPU is obtained through the transmitter and stored in the zero-copy access memory of the CPU. The new edge point set is obtained from the zero-copy access memory using zero-copy technology and combined with the subgraph within the partition in its own device memory to obtain the second matching strategy for the cross-partition subgraph.

[0043] Preferably, before the step of integrating the first matching strategy and the second matching strategy via GPU to complete the matching of the intra-partition subgraph and the cross-partition subgraph, the method includes:

[0044] Optimize the GPU using a three-stage priority scheduling method;

[0045] The steps for optimizing the GPU using the three-stage priority scheduling method include:

[0046] Determine the priority Pri(v) of the GPU:

[0047]

[0048] In the formula, D V freL V These are the vertex degree and the frequency of vertex label occurrences, respectively.

[0049] When the priority Pri(v) is less than the thread block threshold, the matching is performed quickly using all threads of a set of thread blocks.

[0050] When the priority Pri(v) is less than the thread bundle threshold, small work modules are processed using a single thread.

[0051] When the priority Pri(v) is between the thread block threshold and the thread block threshold, the vertices in the middle of the matching set are processed using thread bundle processing.

[0052] Secondly, the invention provides the following technical solution: a large graph subgraph matching system based on multiple GPUs, the system comprising:

[0053] The partitioning module is used to partition a large graph into subgraphs to obtain several subgraphs, including subgraphs within a partition and subgraphs spanning multiple partitions.

[0054] The first strategy determination module is used to perform sequential queries on the subgraphs within the partition to obtain the matching order of the subgraphs within the partition, and determine the first matching strategy of the subgraphs within the partition based on the matching order.

[0055] The second strategy determination module is used to identify the number of hops in the cross-partition subgraph and determine the second matching strategy for the cross-partition subgraph based on the number of hops.

[0056] An integrated matching module is used to integrate the first matching strategy and the second matching strategy through the GPU to complete the matching of the subgraph within the partition and the subgraph across the partition.

[0057] Preferably, the system further includes:

[0058] The optimization module is used to optimize the GPU using a three-stage priority scheduling method;

[0059] The optimization module includes:

[0060] The priority determination submodule is used to determine the priority Pri(v) of the GPU:

[0061]

[0062] In the formula, D V freL V These are the vertex degree and the frequency of vertex label occurrences, respectively.

[0063] The first execution submodule is used to quickly perform matching using all threads of a set of thread blocks when the priority Pri(v) is less than the thread block threshold.

[0064] The second execution submodule is used to process small work modules using a single thread when the priority Pri(v) is less than the thread bundle threshold.

[0065] The third execution submodule is used to process the vertices in the matching set using thread bundles when the priority Pri(v) is between the thread block threshold and the thread block threshold. Attached Figure Description

[0066] To more clearly illustrate the technical solutions in the embodiments of the present invention, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0067] Figure 1 A flowchart of a large graph subgraph matching method based on multiple GPUs provided in the first embodiment of the present invention;

[0068] Figure 2 This is a detailed flowchart of step S1 in the multi-GPU-based large graph subgraph matching method provided in the first embodiment of the present invention;

[0069] Figure 3 This is a schematic diagram of the graph partitioning engine provided in the first embodiment of the present invention;

[0070] Figure 4 This is a detailed flowchart of step S2 in the multi-GPU-based large graph subgraph matching method provided in the first embodiment of the present invention;

[0071] Figure 5 A detailed flowchart of step S23 in the multi-GPU-based large graph subgraph matching method provided in the first embodiment of the present invention;

[0072] Figure 6 This is a detailed flowchart of step S3 in the multi-GPU-based large graph subgraph matching method provided in the first embodiment of the present invention;

[0073] Figure 7 This is a detailed flowchart of step S32 in the multi-GPU-based large graph subgraph matching method provided in the first embodiment of the present invention;

[0074] Figure 8 This is a detailed flowchart of step S33 in the multi-GPU-based large graph subgraph matching method provided in the first embodiment of the present invention;

[0075] Figure 9 This is a diagram of a zero-copy scheduling strategy with more than 4 hops provided in the first embodiment of the present invention;

[0076] Figure 10 A comparison diagram of the large graph subgraph matching method based on multi-GPU provided in the first embodiment of the present invention with the datasets of GSI, GunrockSM, and Gpsm;

[0077] Figure 11 A detailed flowchart of the large graph subgraph matching method based on multiple GPUs provided in the second embodiment of the present invention;

[0078] Figure 12 A detailed flowchart of step S40 in the multi-GPU-based large graph subgraph matching method provided in the second embodiment of the present invention;

[0079] Figure 13 A model structure diagram of the three-stage priority scheduling method provided in the second embodiment of the present invention;

[0080] Figure 14 This is a structural block diagram of a large graph subgraph matching system based on multiple GPUs provided in the third embodiment of the present invention;

[0081] Figure 15 This is a hardware structure block diagram of a computer provided for another embodiment of the present invention.

[0082] The embodiments of the present invention will be further described below with reference to the accompanying drawings. Detailed Implementation

[0083] Embodiments of the present invention are described in detail below, examples of which are illustrated in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain embodiments of the present invention, and should not be construed as limiting the present invention.

[0084] In the description of the embodiments of the present invention, it should be understood that the terms "length", "width", "upper", "lower", "front", "rear", "left", "right", "vertical", "horizontal", "top", "bottom", "inner", "outer", etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are only for the convenience of describing the embodiments of the present invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on the present invention.

[0085] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of embodiments of the present invention, "a plurality of" means two or more, unless otherwise explicitly specified.

[0086] In the embodiments of the present invention, unless otherwise explicitly specified and limited, the terms "installation," "connection," "linking," "fixing," etc., should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral part; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; they can refer to the internal communication of two components or the interaction between two components. Those skilled in the art can understand the specific meaning of the above terms in the embodiments of the present invention according to the specific circumstances.

[0087] Example 1

[0088] like Figure 1As shown, in the first embodiment of the present invention, the invention provides the following technical solution: a large graph subgraph matching method based on multiple GPUs, the method comprising:

[0089] S1. Divide the large graph into subgraphs to obtain several subgraphs, including subgraphs within a partition and subgraphs spanning multiple partitions;

[0090] Specifically, in this embodiment, a graph partitioning engine is used to partition the large graph, i.e., the data graph, into subgraphs. The data graph serves as the input to the graph partitioning engine, and the output of the graph partitioning engine is the intra-partition subgraph gpu_segGraph and the cross-partition subgraph cpu_segGraph. The graph partitioning engine is mainly used to divide the data graph into GPU subgraphs that satisfy the single GPU memory block, and to construct cross-partition subgraphs based on the partitioned GPU subgraphs.

[0091] like Figure 2 As shown, step S1 includes:

[0092] S11. The large graph is divided into subgraphs using the standard graph partitioning method METIS through the graph partitioning engine to obtain several subgraphs;

[0093] Specifically, the graph partitioning engine uses the standard graph partitioning method METIS to partition the graph. This method seeks the minimum cross-partition edge set to ensure that as much graph data as possible is partitioned into different GPU memory, so that the multi-GPU programming model can make full use of the high concurrency and high bandwidth advantages of the GPU.

[0094] S12. Determine the partition boundary set between each of the subgraphs, and take the subgraph corresponding to the smallest partition boundary set as the subgraph within the partition.

[0095] S13. Determine whether the data edges of each subgraph are cross-partition edges:

[0096]

[0097]

[0098] In the formula, V q To query the vertex set of the graph, Represents vertex f(u) j The sequence number in the subgraph. Represents vertex f(u) i The index in the subgraph, u i ,u j Indicates an edge within a partition or an edge spanning multiple partitions;

[0099] For unavoidable cross-partition edge sets, the proposed query graph-oriented dynamic adjustment technique is used to generate a subgraph set centered on the cross-partition edge set within a K-hop range, and store it on the CPU. This allows the multi-GPU programming model to further leverage the architectural advantages of multi-core CPUs, such as branch prediction, to handle complex cross-partition instances in order to determine the cross-partition subgraph.

[0100] S14. If u exists i ,u j ∈V q , Then u i ,u j For cross-partition edges, and with u i ,u j Determine a cross-regional subgraph centered on the subgraph;

[0101] like Figure 3 As shown, with Figure 3 To illustrate the working principle of the graph partitioning engine, for a given data graph G, the graph partitioning engine first uses METIS to partition it into different GPU memory (G0 and G2). The G0 and G2 subgraphs are connected by only one edge, thus satisfying the minimum cross-partition edge set and avoiding frequent interactions between GPUs. For the cross-partition subgraph set (G1), a dynamic adjustment technique oriented towards the query graph is used to construct it and deploy it into CPU memory.

[0102] It is worth noting that the balanced deployment of CPUs and multi-GPU collaborative computing in the graph partitioning engine makes the workload more balanced and reduces the frequent interaction between multiple GPUs, thus reducing the impact of the limited data access bandwidth between GPUs on the efficient processing of multi-GPU subgraph matching.

[0103] S2. Perform sequential queries on the subgraphs within the partition to obtain the matching order of the subgraphs within the partition, and determine the first matching strategy for the subgraphs within the partition based on the matching order;

[0104] Specifically, after the graph partitioning engine is invoked, a Sender, a Router, and a Receiver are constructed for routing and linking between computational resources. Computational resources refer to the CPU and GPU resources required to run subgraph matching. The Sender is used for communication between computational resources within a node, while the Router provides a unified and convenient address lookup interface. The Receiver is used for the final integration of matching sets on heterogeneous resources, which will then be performed in parallel on the heterogeneous resource model. On the GPU side, a worker thread is created for each GPU device. Each GPU generates instances within the partition in parallel using thousands of GPU threads based on the query order generated by the query graph vertex sorting function f(u), according to the breadth-first search algorithm.

[0105] like Figure 4 As shown, step S2 includes:

[0106] S21. Establish a worker thread for each GPU, and determine the matching order of the subgraphs within the partition based on the worker thread and the query graph vertex sorting function f(u), wherein:

[0107]

[0108] In the formula, deg(u) represents the degree of vertex u, and freq(u.label) represents the frequency of the label of vertex u in the data vertices;

[0109] S22. Based on the breadth-first search algorithm and the matching order, and using the worker thread, instances within the partition are generated;

[0110] S23. Based on the instances within the partition, and using a generation-filtering-connection strategy, generate a first matching strategy for the subgraph within the partition;

[0111] Meanwhile, the process of determining the first matching strategy for subgraphs within a partition can be completed in a very short time and hidden within the GPU's computation process. After calling the BSP model to complete the synchronization of heterogeneous processing, a receiver is used for scheduling. This process needs to integrate the matching results between multiple physical devices, ensure the integrity of the matching solutions, deduplicate the generated matching solutions, verify the correctness of the results, and ensure the uniqueness of the cross-partition matching results processed by the CPU and the intra-partition matching results processed by the multi-GPU, and finally return all results.

[0112] like Figure 5 As shown, step S23 includes:

[0113] S231. Based on the instances within the partition, kernel_1 is called to generate a vertex candidate set cand_;

[0114] S232. Call kernel_2 to perform two-stage filtering to filter out candidate vertices that cannot match the query point, so as to reduce the size of intermediate candidate results.

[0115] S233. Based on the filtered candidate vertices, kernel_3 is called to generate a candidate edge set;

[0116] S234. Call kernel_4 to combine the candidate edge set and generate the first matching strategy of the subgraph within the partition.

[0117] By encapsulating and calling multiple GPUs through a graph scheduling engine, the programming model can utilize heterogeneous resources to handle large graph subgraph matching problems simply and efficiently, thereby improving the execution efficiency of subgraph matching algorithms.

[0118] S3. Identify the number of hops in the cross-partition subgraph and determine a second matching strategy for the cross-partition subgraph based on the number of hops;

[0119] like Figure 6 As shown, specifically, step S3 includes:

[0120] S31. Identify the number of hops in the cross-partition subgraph and determine whether the number of hops in the cross-partition subgraph is greater than a first preset number;

[0121] Specifically, the first preset number is 3. In most regular matching, the cross-partition subgraph within 3 hops is sufficient to generate a correct cross-partition matching solution. However, for a very small number of special query matching, the size of the cross-partition subgraph is dynamically adjusted and expanded to meet the matching requirements of special queries. Therefore, in this step, the corresponding method needs to be selected based on the number of hops in the cross-partition subgraph to determine the second matching strategy.

[0122] S32. If the number of hops in the cross-partition subgraph is not less than the first preset number, then the backtracking method is used to determine the second matching strategy for the cross-partition subgraph.

[0123] like Figure 7 As shown, step S32 includes:

[0124] S321. Perform several depth-first traversals on the cross-partition subgraph to find the vertices of the query graph of the cross-partition subgraph;

[0125] S322, The vertices of the query graph determine the search range of the cross-partition subgraph, and the matching solution of the cross-partition subgraph is determined based on the search range;

[0126] S323. Determine the second matching strategy for the cross-partition subgraph based on the matching solution of the cross-partition subgraph;

[0127] In most regular matching scenarios, a cross-partition subgraph within 3 hops is sufficient to generate a correct cross-partition matching solution. However, for a very small number of special query matching scenarios, the size of the cross-partition subgraph is dynamically adjusted and expanded to meet the matching requirements of special queries. Therefore, the cross-partition subgraph within 3 hops can automatically generate the corresponding matching solution through GPU processing.

[0128] It is worth noting that, based on each cross-partition edge ρ, and according to the set number of hops π, a cross-partition sub-graphet centered on the cross-partition edge and within π hops is generated, which is P. π Here, π hops refer to the fact that for any vertex u in the query graph, any vertex u′ in the query graph can be reached through a depth-first traversal of no more than π times. In the real world, most query graphs are no larger than 3 hops. Therefore, when preprocessing cross-partition subgraphs, for each cross-partition subgraph... All of these encompass the entire search range of the query graph Q. This is beneficial for utilizing idle multi-core CPUs to quickly process cross-partition subgraph sets while multi-GPUs handle a large number of subgraph matches within partitions. Since typical subgraph sets are small and numerous, using backtracking to quickly match enumerated results is a very time-efficient matching scheme.

[0129] S33. If the number of hops in the cross-partition subgraph is greater than the first preset number, the query graph dynamic adjustment method is used to determine the second matching strategy for the cross-partition subgraph.

[0130] like Figure 8 As shown, step S33 includes:

[0131] S332. Determine whether the number of jumps in the cross-partition subgraph is greater than the second preset number;

[0132] The second preset number is 4. When the number of hops exceeds this, a single GPU cannot calculate all matching solutions. Therefore, different methods need to be selected based on the specific number of hops to correctly calculate all matching solutions across the partition subgraph. This embodiment will use zero-copy access technology to dynamically adjust the size of the cross-partition subgraph set from the GPU to ensure the correct calculation of all matching solutions. Compared to DMA (Direct Memory Access) based methods, zero-copy technology not only guarantees performance when accessing discrete data but also avoids explicit data transfer.

[0133] S332. If the number of hops in the cross-partition subgraph is equal to the second preset number, then the cross-partition subgraph is retrieved from the CPU's zero-copy access memory using the GPU and zero-copy technology and fused with the internal graph splitting points. Query graph matching is performed on the cross-partition subgraph and the matching solution of the cross-partition subgraph is calculated to obtain the second matching strategy of the cross-partition subgraph.

[0134] S332. If the number of hops in the cross-partition subgraph is greater than the second preset number, the graph storage on the GPU is adjusted according to the upper router information of the CPU and the transmitter. The edge point set in the GPU is obtained through the transmitter and stored in the zero-copy access memory of the CPU. The new edge point set is obtained from the zero-copy access memory using zero-copy technology and combined with the subgraph within the partition in its own device memory to obtain the second matching strategy for the cross-partition subgraph.

[0135] Specifically, for query graph matching with more than three hops, there are two scenarios: (1) When the graph size is 4 hops and it is at the edge of the graph partition, the intra-partition subgraph in the single GPU memory and the cross-partition subgraph in the CPU memory cannot completely cover the query graph with a size of 4 hops. At this time, the GPU uses zero-copy technology to retrieve the cross-partition subgraph from the CPU's zero-copy access memory and merges it with the internal graph partition points to meet the matching requirements of the query graph with a size of 4 hops. (2) When the graph size expands to more than 4 hops and it is at the edge of the matching graph partition, the original intra-partition subgraph in the single GPU memory and the cross-partition subgraph in the CPU memory can no longer guarantee matching all results. At this time, it is necessary to adjust the graph storage on the GPU based on the router information and transmitter on the CPU, such as Figure 9 As shown, thin arrows represent logical transfers, while thick arrows represent actual data transfers. When the GPU... i When the internal storage graph needs to be adjusted, the information is sent to the router, which then transmits it to the transmitter according to the routing table. The transmitter obtains the edge point set in the GPU memory and stores it in the CPU zero-copy access memory. The GPU can use zero-copy technology to directly obtain the new edge point set from the zero-copy access memory and combine it with the subgraph in the partition in its own device memory, avoiding complex data transmission and meeting the query graph matching requirements of more than 4 hops.

[0136] S4. The first matching strategy and the second matching strategy are integrated by GPU to complete the matching of the subgraph within the partition and the subgraph across the partition;

[0137] Specifically, by integrating the first matching strategy with the second matching strategy, when performing subgraph matching, the first matching strategy or the second matching strategy can be freely selected according to the type of the subgraph.

[0138] Notably, this invention achieves collaborative operation of the subgraph matching algorithm across multiple GPUs, solving the bottleneck of single GPU memory space in handling large graph problems when using GPUs for acceleration. It also utilizes multiple GPUs collaboratively to quickly process subgraph matching within partitions. Secondly, a dynamic adjustment technique based on the query graph is employed to handle cross-partition subgraph sets, resolving the cross-partition subgraph matching challenge caused by graph partitioning and ensuring the correctness and uniqueness of the matching results. Combining the SIMT architecture characteristics of GPUs, a priority scheduling strategy is proposed to ensure internal load balancing within the GPUs, enabling the proposed model to better handle complex and diverse large graph data in real-world scenarios and improving its practicality.

[0139] Table 1 Dataset Statistics

[0140]

[0141] This invention also conducted experimental analyses on the model's performance, stability, and optimization effects on 9 real datasets and 15 generated datasets. The real datasets are shown in Table 1, including a YouTube-based social network, a Texas road network, Wikipedia graphs Enwiki-2016 and Enwiki-2020, a book network graph Fb_se, a large-scale crawling graph Gsh-2015, and graphs with power-law distribution properties such as Web-Google, Higgs-Twitter, and LiveJournal. Since previous work has demonstrated the superiority of single-GPU subgraph matching algorithms over CPU-based subgraph matching algorithms, and no multi-GPU-based subgraph matching algorithms have yet been invented, this invention only compares with current mainstream single-core GPU subgraph matching algorithms, including GpSM, GSI, and GunrockSM. GpSM and GunrockSM are both single-GPU subgraph matching algorithms based on breadth-first traversal and edge-connection-oriented. GSI is the latest single-GPU subgraph matching algorithm oriented towards vertex connections. The experimental setup consisted of a GPU server running Ubuntu 18.04. The server was equipped with an Intel Xeon Silver 4214 CPU at 2.20GHz and 128GB of RAM, along with four NVIDIA RTX 2080Ti graphics cards, each with 11GB of RAM.

[0142] Performance comparison experiments, such as Figure 7 The figure shows the runtime of our proposed framework compared to state-of-the-art GPU solutions. Missing data indicates failures due to crashes or insufficient memory. As shown, on the first three small datasets, our method demonstrates a significant advantage over Gpsm and GunrockSM, with a speedup of over 4x. This is primarily because our proposed programming model shields PCIe communication between partitions, reducing execution coupling between multiple GPUs and leveraging their stronger parallel capabilities to quickly generate subgraph matching results. However, on smaller datasets, the advantage over the state-of-the-art GPU solution GSI is not significant, mainly because the scheduling time of multiple GPUs cannot be masked by computation time. On the fourth dataset, Enwiki-2020, with data sizes reaching hundreds of millions, our multi-GPU model begins to show its processing power for large datasets. As the dataset size continues to increase, Gpsm and GunrockSM can no longer perform subgraph matching computations due to exceeding memory limitations. On the fifth dataset, our method achieves a speedup of 2.6x. When the dataset expands to the billions, GSI cannot continue to compute even with a single-core GPU, while our method can still handle large-scale matching operations on multi-core GPUs.

[0143] Since it is difficult to find datasets that continuously and steadily increase, the stability analysis of the proposed framework is tested using generated graphs. The generated graph set ensures the connectivity of the graph and the randomness of its generation. For example... Figure 10 As shown, the generated graph atlases, numbered 1-15, represent datasets ranging from 10 million to 150 million. With increasing data size, Gpsm and GunrockSM exhibit exponential growth, and when the data size reaches the hundreds of millions, both algorithms fail to properly match the data due to insufficient memory. The latest GSI algorithm, due to optimizations in join operations, can handle even larger graphs; however, processing time increases sharply with increasing data size. In comparison, the framework of this invention utilizes the higher parallelism of multiple GPUs, resulting in better performance in handling large-scale data. It is less sensitive to the increasing trend of graph size and also exhibits good scalability.

[0144] When processing power-law graphs using the framework presented in this paper, our proposed priority scheduling optimization begins to demonstrate its advantages. As shown in Table 2, this scheduling strategy has minimal impact on time in non-power-law graphs, mainly because the conventional use of thread bundles to process data graphs is a relatively balanced processing mode. However, in power-law graphs, the basic approach without scheduling will lead to a tailing effect due to uneven load, making it difficult to leverage the advantages of multi-GPUs in large-scale data matching. Priority scheduling is more suitable for processing data graphs with uneven density distribution. When the Pri(v) value of the data is less than the thread block threshold, calling thread blocks for centralized processing reduces the thread load by 8 times. Conversely, when the Pri(v) value of the data is greater than the thread bundle threshold, calling individual threads to process the matching solution increases the parallelism between threads, thus reducing the total execution time of kernel functions.

[0145] Table 2 Priority Scheduling Optimization Analysis

[0146]

[0147]

[0148] The advantages of this first embodiment are as follows: By partitioning a large graph into subgraphs, several subgraphs are obtained. The subgraph partitioning process is completed by a graph partitioning engine. The balanced deployment of CPUs and multiple GPUs in the graph partitioning engine results in a more balanced workload and reduces frequent interactions between GPUs. This reduces the impact of limited data access bandwidth between GPUs on the efficient processing of multi-GPU subgraph matching. Then, a sequential query is performed on the subgraphs within each partition to obtain the matching order. Based on this matching order, a first matching strategy for the subgraphs within each partition is determined. By utilizing heterogeneous resources to handle the large graph subgraph matching problem simply and efficiently, the execution efficiency of the subgraph matching algorithm is improved, followed by identification. The invention uses the number of hops across the subgraph and determines a second matching strategy based on this number. It employs a zero-copy scheduling strategy and a dynamic adjustment strategy between multiple GPUs to dynamically schedule the subgraphs, ensuring the correctness and completeness of the large graph subgraph matching method. Finally, the first and second matching strategies are integrated by the GPU to complete the matching of the subgraphs within the partition with the subgraphs across the partition. This invention can process subgraph matching problems in parallel on multiple GPUs, solving the limitation of graph size on GPU large graph subgraph matching, and also solving the cross-partition subgraph matching problem caused by graph partitioning. Furthermore, it combines the SIMT architecture characteristics of the GPU to ensure internal load balancing within the GPU.

[0149] Example 2

[0150] like Figure 11 As shown, in the second embodiment of the present invention, the invention provides the following technical solution: a large graph subgraph matching method based on multiple GPUs, the method comprising:

[0151] S10. Divide the large graph into subgraphs to obtain several subgraphs, including subgraphs within a partition and subgraphs across partitions;

[0152] S20. Perform sequential queries on the subgraphs within the partition to obtain the matching order of the subgraphs within the partition, and determine the first matching strategy for the subgraphs within the partition based on the matching order;

[0153] S30. Identify the number of hops in the cross-partition subgraph and determine a second matching strategy for the cross-partition subgraph based on the number of hops;

[0154] S40. Optimize the GPU using a three-stage priority scheduling method;

[0155] In real-world large graphs, the vertex degrees mostly follow a power-law distribution, meaning there are a large number of low-degree vertices and a small number of high-degree vertices. GPUs use warps as the basic execution unit. When processing power-law graphs, only a small number of active warps persist throughout, while most threads remain as inactive warps, waiting for the active warps to finish. This skew in vertex degrees leads to uneven load distribution on GPU threads, significantly impairing GPU parallel performance. Existing GPU-based subgraph matching algorithms do not consider the performance degradation caused by the complex structure of large graphs. Therefore, a three-stage priority scheduling method is used, with the three stages centered on thread blocks, thread warps, and threads themselves, respectively.

[0156] like Figure 12 As shown, step 40 includes:

[0157] S401. Determine the priority Pri(v) of the GPU:

[0158]

[0159] In the formula, D V freL V These are the vertex degree and the frequency of vertex label occurrences, respectively.

[0160] S402. When the priority Pri(v) is less than the thread block threshold, use all threads of a group of thread blocks to quickly perform the matching.

[0161] S403. When the priority Pri(v) is less than the thread bundle threshold, a single thread is used to process small work modules.

[0162] S404. When the priority Pri(v) is between the thread block threshold and the thread block threshold, use thread bundle processing to handle the vertices in the center of the matching set.

[0163] Specifically, a lower priority indicates a higher frequency of matching for that set. During priority scheduling, the thread block size and thread bundle size are set as the thread block threshold and thread bundle threshold, respectively. When Pri(v) is less than the thread block threshold, a group of thread blocks is scheduled to a group of jobs. When Pri(v) is greater than the thread bundle threshold, a single thread is used to process small, numerous job modules. When Pri(v) is between the two thresholds, it indicates that the frequency of matching for that vertex is moderate, making thread bundle processing more suitable. Figure 13 As shown, when vertex v i-1When Pri(v) is less than the thread block threshold, it indicates that the vertex has many adjacent vertices and the set to be matched is large. Therefore, all threads in a thread block are used to quickly perform the matching. When vertex v i When Pri(v) falls between the thread block threshold and the thread bundle threshold, the thread bundle is used to process the vertices in the middle of the matching set. At this point, the matching sets of the remaining vertices are not large, and vertex v... i+1 v i+2 v i+3 If Pri(v) is greater than the thread bundle threshold, using a single thread to process sporadic matching results can effectively reduce thread waiting.

[0164] S50. The first matching strategy and the second matching strategy are integrated by the GPU to complete the matching of the subgraph within the partition and the subgraph across the partition.

[0165] The advantage of this second embodiment compared to the first embodiment is that by introducing a three-stage priority scheduling method to optimize the GPU, in the face of the uneven vertex distribution of the power-law graph, the matching sets of different sizes are deployed more evenly on the worker threads, which reduces the imbalance between blocks and the imbalance between thread bundles, and also avoids conditional branches caused by too many scheduling judgments.

[0166] Example 3

[0167] like Figure 14 As shown, a third embodiment of the present invention provides a large graph subgraph matching system based on multiple GPUs, the system comprising:

[0168] Secondly, the invention provides the following technical solution: a large graph subgraph matching system based on multiple GPUs, the system comprising:

[0169] The partitioning module 1 is used to partition a large graph into subgraphs to obtain several subgraphs, including subgraphs within a partition and subgraphs spanning multiple partitions.

[0170] The first strategy determination module 2 is used to perform sequential queries on the subgraphs within the partition to obtain the matching order of the subgraphs within the partition, and determine the first matching strategy of the subgraphs within the partition based on the matching order.

[0171] The second strategy determination module 3 is used to identify the number of hops in the cross-partition subgraph and determine the second matching strategy for the cross-partition subgraph based on the number of hops.

[0172] Optimization module 4 is used to optimize the GPU using a three-stage priority scheduling method;

[0173] The integration matching module 5 is used to integrate the first matching strategy and the second matching strategy through the GPU to complete the matching of the subgraph within the partition and the subgraph across the partition.

[0174] The partitioning module 1 includes:

[0175] The partitioning submodule is used to partition a large graph into subgraphs using the standard graph partitioning method METIS through the graph partitioning engine, so as to obtain several subgraphs;

[0176] The edge set submodule is used to determine the partition edge set between each of the subgraphs, and to take the subgraph corresponding to the smallest partition edge set as the subgraph within the partition.

[0177] The cross-partition discrimination submodule is used to determine whether the data edges of each subgraph are cross-partition edges:

[0178]

[0179]

[0180] In the formula, V q To query the vertex set of the graph, Represents vertex f(u) j The sequence number in the subgraph. Represents vertex f(u) i The index in the subgraph, u i ,u j Indicates an edge within a partition or an edge spanning multiple partitions;

[0181] Cross-partition subgraph submodule, used if u exists i ,u j ∈V q , Then u i ,u j For cross-partition edges, and with u i ,u j Determine the cross-regional subgraph centered on the subgraph.

[0182] The first strategy determination module 2 includes:

[0183] The thread determination submodule is used to create a worker thread for each GPU and determine the matching order of the subgraphs within the partition based on the worker thread and the query graph vertex sorting function f(u), wherein:

[0184]

[0185] In the formula, deg(u) represents the degree of vertex u, and freq(u.label) represents the frequency of the label of vertex u in the data vertices;

[0186] The sequence determination submodule is used to generate instances within a partition based on the breadth-first search algorithm and the matching order, and using the worker thread.

[0187] The first matching strategy determination submodule is used to generate a first matching strategy for the subgraph within the partition based on the instances within the partition and using a generation-filtering-connection strategy.

[0188] The first matching strategy determination submodule includes:

[0189] The first processing unit is used to call kernel_1 to generate a vertex candidate set cand_dset based on the instances in the partition;

[0190] The second processing unit is used to call kernel_2 to perform two-stage filtering, filtering out candidate vertices that cannot match the query point, so as to reduce the size of intermediate candidate results.

[0191] The third processing unit is used to call kernel_3 to generate a candidate edge set based on the filtered candidate vertices;

[0192] The fourth processing unit is used to call kernel_4 to combine the candidate edge set and generate the first matching strategy of the subgraph within the partition.

[0193] The second strategy determination module 3 includes:

[0194] The identification submodule is used to identify the number of hops in the cross-partition subgraph and determine whether the number of hops in the cross-partition subgraph is greater than a first preset number.

[0195] The first determining submodule is used to determine the second matching strategy of the cross-partition subgraph by using a backtracking method if the number of hops of the cross-partition subgraph is not less than the first preset number.

[0196] The second determining submodule is used to determine the second matching strategy of the cross-partition subgraph if the number of hops in the cross-partition subgraph is greater than the first preset number, by using the query graph dynamic adjustment method.

[0197] The first determining submodule includes:

[0198] The traversal unit is used to perform several depth-first traversals on the cross-partition subgraph to find the vertices of the query graph of the cross-partition subgraph.

[0199] A range unit is used to determine the search range of the cross-partition subgraph by the vertices of the query graph, and to determine the matching solution of the cross-partition subgraph based on the search range;

[0200] A determining unit is used to determine a second matching strategy for the cross-partition subgraph based on the matching solution of the cross-partition subgraph.

[0201] The second determining submodule includes:

[0202] The judgment unit is used to determine whether the number of jumps in the cross-partition subgraph is greater than a second preset number;

[0203] The first matching unit is configured to, if the number of hops in the cross-partition subgraph is equal to the second preset number, retrieve the cross-partition subgraph from the CPU's zero-copy access memory using the GPU and zero-copy technology, merge it with the internal graph splitting points, perform query graph matching on the cross-partition subgraph, and calculate the matching solution of the cross-partition subgraph to obtain the second matching strategy of the cross-partition subgraph.

[0204] The second matching unit is configured to adjust the graph storage on the GPU based on the upper router information of the CPU and the transmitter if the number of hops in the cross-partition subgraph is greater than a second preset number. The unit obtains the edge point set in the GPU through the transmitter and stores it in the zero-copy access memory of the CPU. It then uses zero-copy technology to obtain a new edge point set from the zero-copy access memory and combines it with the subgraph within the partition in its own device memory to obtain the second matching strategy for the cross-partition subgraph.

[0205] The optimization module 4 includes:

[0206] The priority determination submodule is used to determine the priority Pri(v) of the GPU:

[0207]

[0208] In the formula, D V freL V These are the vertex degree and the frequency of vertex label occurrences, respectively.

[0209] The first execution submodule is used to quickly perform matching using all threads of a set of thread blocks when the priority Pri(v) is less than the thread block threshold.

[0210] The second execution submodule is used to process small work modules using a single thread when the priority Pri(v) is less than the thread bundle threshold.

[0211] The third execution submodule is used to process the vertices in the matching set using thread bundles when the priority Pri(v) is between the thread block threshold and the thread block threshold.

[0212] In other embodiments of the present invention, the present invention provides the following technical solution: a computer, including a memory 102, a processor 101, and a computer program stored in the memory 102 and executable on the processor 101, wherein the processor 101 executes the computer program to implement the above-described multi-GPU-based large graph subgraph matching method.

[0213] Specifically, the processor 101 may include a central processing unit (CPU), an application specific integrated circuit (ASIC), or one or more integrated circuits that can be configured to implement the embodiments of this application.

[0214] The memory 102 may include a mass storage device for data or instructions. For example, and not limitingly, the memory 102 may include a hard disk drive (HDD), a floppy disk drive, a solid-state drive (SSD), flash memory, an optical disk drive, a magneto-optical disk drive, magnetic tape, or a Universal Serial Bus (USB) drive, or a combination of two or more of these. Where appropriate, the memory 102 may include removable or non-removable (or fixed) media. Where appropriate, the memory 102 may be internal or external to a data processing device. In a particular embodiment, the memory 102 is non-volatile memory. In a particular embodiment, the memory 102 includes read-only memory (ROM) and random access memory (RAM). Where appropriate, the ROM may be a mask-programmed ROM, a programmable read-only memory (PROM), an erasable read-only memory (EPROM), an electrically erasable read-only memory (EEPROM), an electrically alterable read-only memory (EAROM), or flash memory, or a combination of two or more of these. Where appropriate, the RAM can be Static Random-Access Memory (SRAM) or Dynamic Random-Access Memory (DRAM). DRAM can be Fast Page Mode Dynamic Random Access Memory (FPMDRAM), Extended Data Out Dynamic Random Access Memory (EDODRAM), Synchronous Dynamic Random-Access Memory (SDRAM), etc.

[0215] The memory 102 can be used to store or cache various data files that need to be processed and / or used for communication, as well as possible computer program instructions executed by the processor 101.

[0216] The processor 101 implements the above-described multi-GPU-based large graph subgraph matching method by reading and executing computer program instructions stored in the memory 102.

[0217] In some embodiments, the computer may further include a communication interface 103 and a bus 100. For example, Figure 15 As shown, the processor 101, memory 102, and communication interface 103 are connected through bus 100 and complete communication with each other.

[0218] The communication interface 103 is used to enable communication between the various modules, devices, units, and / or equipment in the embodiments of this application. The communication interface 103 can also enable data communication with other components such as external devices, image / data acquisition devices, databases, external storage, and image / data processing workstations.

[0219] Bus 100 includes hardware, software, or both, that couples components of a computer device together. Bus 100 includes, but is not limited to, at least one of the following: data bus, address bus, control bus, expansion bus, and local bus. For example, and not as a limitation, bus 100 may include an Accelerated Graphics Port (AGP) or other graphics bus, an Extended Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), a Hyper Transport (HT) interconnect, an Industry Standard Architecture (ISA) bus, an InfiniBand interconnect, a Low Pin Count (LPC) bus, a memory bus, a Micro Channel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCI-X) bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association Local Bus (VLB) bus, or other suitable buses, or a combination of two or more of these. Where appropriate, bus 100 may include one or more buses. Although specific buses are described and illustrated in the embodiments of this application, this application considers any suitable bus or interconnection.

[0220] The computer can obtain a large graph subgraph matching system based on multi-GPUs and execute the large graph subgraph matching method of this application to achieve matching based on large graph subgraphs.

[0221] In some further embodiments of the present invention, in conjunction with the above-described multi-GPU-based large graph subgraph matching method, the present invention provides the following technical solution: a readable storage medium storing a computer program, wherein the computer program, when executed by a processor, implements the above-described multi-GPU-based large graph subgraph matching method.

[0222] Those skilled in the art will understand that the logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequential list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus, or device (such as a computer-based system, a processor-included system, or other system that can fetch and execute instructions from, an instruction execution system, apparatus, or device). For the purposes of this specification, "computer-readable medium" can mean any means that can contain, store, communicate, propagate, or transmit programs for use by, or in conjunction with, an instruction execution system, apparatus, or device.

[0223] More specific examples of readable media (a non-exhaustive list) include: electrical connections (electronic devices) with one or more wires, portable computer disk drives (magnetic devices), random access memory (RAM), read-only memory (ROM), erasable and editable read-only memory (EPROM or flash memory), fiber optic devices, and portable optical disc read-only memory (CDROM). Furthermore, computer-readable media can even be paper or other suitable media on which the program can be printed, since the program can be obtained electronically, for example, by optically scanning the paper or other medium, followed by editing, interpreting, or otherwise processing as necessary, and then stored in computer memory.

[0224] It should be understood that various parts of the present invention can be implemented in hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented in software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, it can be implemented using any one or a combination of the following techniques known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0225] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0226] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the invention patent. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this patent application should be determined by the appended claims.

Claims

1. A large graph subgraph matching method based on multi-GPU, characterized in that, The method includes: The large graph is divided into subgraphs to obtain several subgraphs, including subgraphs within a partition and subgraphs spanning multiple partitions. Perform sequential queries on the subgraphs within the partition to obtain the matching order of the subgraphs within the partition, and determine the first matching strategy for the subgraphs within the partition based on the matching order; Identify the hop count of the cross-partition subgraph and determine a second matching strategy for the cross-partition subgraph based on the hop count; The first matching strategy and the second matching strategy are integrated by the GPU to complete the matching of the subgraph within the partition and the subgraph across the partition; The step of dividing a large graph into subgraphs to obtain several subgraphs includes: The graph partitioning engine uses the standard graph partitioning method METIS to partition a large graph into subgraphs, resulting in several subgraphs. Determine the partition boundary set between each of the subgraphs, and take the subgraph corresponding to the smallest partition boundary set as the subgraph within the partition; Determine whether the data edges of each subgraph are cross-partition edges: ； ； In the formula, To query the vertex set of the graph, Represents vertices The sequence number in the subgraph. Represents vertices The sequence number in the subgraph. Indicates an edge within a partition or an edge spanning multiple partitions; If it exists ,but( ) is a cross-partition edge, and with Determine the cross-regional subgraph with the center as the center.

2. The large graph subgraph matching method based on multi-GPU according to claim 1, characterized in that, The step of performing sequential queries on the subgraphs within the partition to obtain the matching order of the subgraphs within the partition, and determining the first matching strategy for the subgraphs within the partition based on the matching order, includes: A worker thread is created for each GPU, and the worker thread is used in conjunction with the query graph vertex sorting function. Determine the matching order of the subgraphs within the partition, wherein: ； In the formula, Representing the vertex The degree, Representing the vertex The frequency of the label appearing in the data vertices; Based on the breadth-first search algorithm and the matching order, instances within the partition are generated using the worker thread; Based on the instances within the partition, a first matching strategy is adopted to generate the subgraph within the partition using a generation-filtering-connection strategy.

3. The large graph subgraph matching method based on multi-GPU according to claim 2, characterized in that, The step of generating a first matching strategy for a subgraph within a partition based on instances within the partition and employing a generation-filtering-joining strategy includes: Based on the instances within the partition, kernel_1 is invoked to generate a vertex candidate set. ; Call kernel_2 to perform two-stage filtering, filtering out candidate vertices that cannot match the query point, in order to reduce the size of intermediate candidate results; Based on the filtered candidate vertices, kernel_3 is called to generate a candidate edge set; The kernel_4 function is called to combine the candidate edge set and generate the first matching strategy for the subgraph within the partition.

4. The large graph subgraph matching method based on multi-GPU according to claim 1, characterized in that, The step of identifying the hop count of the cross-partition subgraph and determining the second matching strategy for the cross-partition subgraph based on the hop count includes: Identify the number of hops in the cross-partition subgraph and determine whether the number of hops in the cross-partition subgraph is greater than a first preset number; If the number of hops in the cross-partition subgraph is not less than the first preset number, then the backtracking method is used to determine the second matching strategy for the cross-partition subgraph. If the number of hops in the cross-partition subgraph is greater than the first preset number, then the query graph dynamic adjustment method is used to determine the second matching strategy for the cross-partition subgraph.

5. The large graph subgraph matching method based on multi-GPU according to claim 4, characterized in that, The step of determining the second matching strategy for the cross-partition subgraph using backtracking if the number of hops in the cross-partition subgraph is not less than a first preset number includes: Perform several depth-first traversals on the cross-partition subgraph to find the vertices of the query graph of the cross-partition subgraph; The vertices of the query graph determine the search range of the cross-partition subgraph, and the matching solution of the cross-partition subgraph is determined based on the search range; The second matching strategy for the cross-partition subgraph is determined based on the matching solution of the cross-partition subgraph.

6. The large graph subgraph matching method based on multi-GPU according to claim 4, characterized in that, If the number of hops in the cross-partition subgraph is greater than the first preset number, the steps for determining the second matching strategy for the cross-partition subgraph using the query graph dynamic adjustment method include: Determine whether the number of hops across the subgraph is greater than a second preset number; If the number of hops in the cross-partition subgraph is equal to the second preset number, then the cross-partition subgraph is retrieved from the CPU's zero-copy access memory using the GPU and zero-copy technology and fused with the internal graph splitting points. Query graph matching is performed on the cross-partition subgraph and the matching solution of the cross-partition subgraph is calculated to obtain the second matching strategy of the cross-partition subgraph. If the number of hops in the cross-partition subgraph is greater than the second preset number, the graph storage on the GPU is adjusted according to the CPU's upper router information and the transmitter. The edge point set in the GPU is obtained through the transmitter and stored in the CPU's zero-copy access memory. The zero-copy technology is used to obtain a new edge point set from the zero-copy access memory and combine it with the subgraph within the partition in the device memory to obtain the second matching strategy for the cross-partition subgraph.

7. The large graph subgraph matching method based on multi-GPU according to claim 1, characterized in that, Before the step of integrating the first matching strategy and the second matching strategy via GPU to complete the matching of the intra-partition subgraph and the cross-partition subgraph, the method includes: Optimize the GPU using a three-stage priority scheduling method; The steps for optimizing the GPU using the three-stage priority scheduling method include: Determine the priority of the GPU : ； In the formula, , These are the vertex degree and the frequency of vertex label occurrences, respectively. When the priority When the value is less than the thread block threshold, use all threads of a group of thread blocks to quickly perform the matching. When the priority When the thread bundle threshold is exceeded, a single thread is used to process small work modules. When the priority When the vertex is between the thread block threshold and the thread bundle threshold, the thread bundle is used to process the vertices in the matching set.

8. A large graph subgraph matching system based on multiple GPUs, wherein the system employs the large graph subgraph matching method based on multiple GPUs as described in claim 1, characterized in that, The system includes: The partitioning module is used to partition a large graph into subgraphs to obtain several subgraphs, including subgraphs within a partition and subgraphs spanning multiple partitions. The first strategy determination module is used to perform sequential queries on the subgraphs within the partition to obtain the matching order of the subgraphs within the partition, and determine the first matching strategy of the subgraphs within the partition based on the matching order. The second strategy determination module is used to identify the number of hops in the cross-partition subgraph and determine the second matching strategy for the cross-partition subgraph based on the number of hops. An integrated matching module is used to integrate the first matching strategy and the second matching strategy through the GPU to complete the matching of the subgraph within the partition and the subgraph across the partition.

9. The large graph subgraph matching system based on multiple GPUs according to claim 8, characterized in that, The system also includes: The optimization module is used to optimize the GPU using a three-stage priority scheduling method; The optimization module includes: The priority determination submodule is used to determine the priority of the GPU. : ； In the formula, , These are the vertex degree and the frequency of vertex label occurrences, respectively. The first execution submodule is used when the priority is... When the value is less than the thread block threshold, use all threads of a group of thread blocks to quickly perform the matching. The second execution submodule is used when the priority is... When the thread bundle threshold is exceeded, a single thread is used to process small work modules. The third execution submodule is used when the priority is... When the vertex is between the thread block threshold and the thread block threshold, the vertices in the middle of the matching set are processed using thread bundle processing.

Images