Distributed co-purchase recommendation method based on graph pattern matching

Abstract

The invention discloses a distributed co-purchase recommendation method based on graph pattern matching, and aims to realize rapid combination recommendation. According to the scheme, a distributed co-purchase recommendation system based on graph pattern matching is constructed on a distributed cluster with NUMA, and each NUMA node comprises a graph partition module, a task generation module, a task buffer module, a task scheduling module, a task execution module, a vertex request module, a vertex response module and a vertex buffer module; the method comprises the following steps: constructing a co-purchase relationship data graph and a co-purchase relationship mode graph, enabling all modules of a co-purchase recommendation system to work in parallel, determining a vertex matching sequence according to a connection relationship of the co-purchase relationship mode graph, matching vertexes in the co-purchase relationship mode graph to vertexes of the co-purchase relationship data graph, and obtaining sub-graphs isomorphic with the co-purchase relationship mode graph; and obtaining an isomorphic sub-graph with the maximum frequency according to the common purchase frequency model, wherein a set of products represented by vertexes of each isomorphic sub-graph is a combined recommendation result. The recommendation efficiency and speed can be improved.

Description

Technical Field

[0001] This invention relates to the field of e-commerce recommendation technology, specifically to the intersection of personalized recommendation and distributed graph pattern matching, and particularly to a distributed co-purchasing recommendation method based on graph pattern matching. Background Technology

[0002] With the rapid development of information technology, the number of goods on e-commerce platforms has exploded, leading to information overload. How to help consumers efficiently and quickly locate the products they need from a massive selection and improve recommendation efficiency has become a hot topic in the e-commerce industry. Recommendation systems, by mining user interests and preferences, can filter massive amounts of information, provide personalized recommendations to consumers, alleviate information overload, and enhance core competitiveness, making them crucial for research and application.

[0003] Existing recommendation methods mostly focus on the association of single products, that is, mining the relationship between a single product and other products. For example, collaborative filtering-based recommendation algorithms provide recommendations such as "A user who bought product A also bought product B". Existing methods have not fully considered the characteristics of product combinations, ignored the functional complementarity of product combinations, and lack the ability to mine high-frequency multi-product combination patterns with practical use value, making it difficult to generate combination recommendations that meet users' real needs.

[0004] Furthermore, existing recommendation methods cannot support real-time recommendations on large e-commerce platforms with massive amounts of products and users. Collaborative filtering is a traditional recommendation method that analyzes user preferences by collecting historical user behavior (such as explicit product ratings and implicit browsing), constructing a behavior matrix, calculating similarity, and then identifying similar user groups to achieve personalized recommendations. However, the user-product interaction matrix generated by traditional collaborative filtering recommendation algorithms contains mostly default values, leading to decreased accuracy in similarity calculation and recommendation accuracy, and causing data sparsity problems. With the rapid growth in the number of users and products, the size of the interaction matrix also expands, significantly increasing computational difficulty and time, posing a severe challenge to the system's computing power and efficiency. In addition, this algorithm is highly dependent on historical behavior; new users and new products are difficult to recommend accurately due to a lack of historical interaction data, i.e., the cold start problem. These shortcomings make traditional collaborative filtering algorithms unsuitable for real-time personalized recommendation scenarios with increasingly large amounts of data. To solve the cold start problem, many researchers have proposed recommendation methods based on graph neural networks. The paper "Minghao Liu, Catherine Zhao, and Nathan Zhou. Building a Recommendation System Using Amazon Product Co-Purchasing Network. arXiv, 2025." constructs a product co-purchasing graph, where vertices represent products and edges represent co-purchasing relationships between products. This method utilizes an improved GraphSAGE graph neural network model to mine product features and the existing co-purchasing graph structure to predict potential co-purchasing relationships, including new products, thus alleviating the cold start problem to some extent. However, this graph neural network-based recommendation method still has limitations. Graph neural network models have high computational complexity, resulting in low training and inference efficiency when dealing with large-scale graph data. Furthermore, parameters need to be readjusted for different product types and interaction scenarios to ensure prediction accuracy, and it cannot support real-time recommendations on large e-commerce platforms with massive product and user scales. In addition, graph pattern matching-based recommendation systems also face challenges. Graph pattern matching is a fundamental graph analysis problem, aiming to find subgraphs isomorphic to a given pattern graph from a large-scale data graph. Existing distributed graph pattern matching methods mainly follow the "task-centric" approach.The paper "G-thinker: A Distributed Framework for Mining Subgraphs in a Big Graph" proposes G-thinker, which requires pre-fetching the minimum subgraph needed to explore the entire search tree into local memory via inter-node communication before executing the complete search task. However, the degree of real-world graphs follows a power-law distribution, leading to significant differences in the size of search trees. While high parallelism can be guaranteed in the early stages, after the smaller tasks are completed, the remaining large tasks still require a few threads to execute, while the rest remain idle, resulting in a severe load imbalance problem. Compared to G-thinker's coarse-grained task partitioning, the paper "Khuzdul: Efficient and Scalable Distributed Graph Pattern Mining Engine" proposes Khuzdul, which performs finer-grained task partitioning. Khuzdul chose to treat the expansion of a single vertex (a subtree of depth 1 formed by a vertex and its neighbors in the search tree) as a separate task, but scheduling the task corresponding to the entire search tree to a single computing node still faces the problem of load imbalance between nodes.

[0005] Therefore, how to optimize the processing efficiency of large-scale graph data, meet the combined recommendation and real-time recommendation needs of large e-commerce platforms, and improve recommendation efficiency remains a technical issue of great concern to researchers in this field. Summary of the Invention

[0006] The technical problem this invention aims to solve is that existing personalized recommendation methods cannot support large-scale product combination and real-time recommendations. It proposes a distributed co-purchasing recommendation method based on graph pattern matching to achieve rapid combination recommendations, meeting the combination and real-time recommendation needs of large e-commerce platforms and improving recommendation efficiency.

[0007] To address the aforementioned technical problems, the technical solution of this invention is to construct a distributed co-purchasing recommendation system based on graph pattern matching. This system is built on a distributed cluster with a Non-Uniform Memory Access (NUMA) architecture. Each NUMA node includes a graph partitioning module, a task generation module, a task buffering module, a task scheduling module, a task execution module, a vertex request module, a vertex response module, and a vertex buffering module. The system first constructs a co-purchasing relationship data graph and a co-purchasing relationship pattern graph. Then, based on the connection relationships in the co-purchasing relationship pattern graph, it determines the matching order of vertices, matching vertices in the co-purchasing relationship pattern graph to vertices in the co-purchasing relationship data graph in sequence. This results in a subgraph in the co-purchasing relationship data graph that is isomorphic to the co-purchasing relationship pattern graph. Based on a co-purchasing frequency model, it obtains several isomorphic subgraphs with the highest frequency. The set of products represented by the vertices of each isomorphic subgraph is the combined recommendation result.

[0008] To facilitate the following description, the following concepts will be defined first.

[0009] Matching order refers to the ordered set of all vertices in the co-purchase relationship schema graph.

[0010] The candidate set of vertices in the co-purchase relationship pattern graph refers to the set of vertices in the co-purchase relationship data graph that the vertex can be mapped to.

[0011] The execution plan corresponding to the matching order refers to the sequence of vertex sets involved in calculating the candidate set of each vertex in the matching order.

[0012] An embedded instance represents a subgraph in the co-purchase relationship data graph that is isomorphic to the co-purchase relationship schema graph.

[0013] Partial embeddings refer to incomplete results generated during the matching process, i.e., subgraphs of embedded instances. Given a matching order, embedded instances and partial embeddings can be formally represented as ordered sets of vertices. Vertices in the matching order are matched sequentially to vertices in either embedded instances or partial embeddings.

[0014] A vertex neighbor list refers to the set of neighboring vertices that are directly connected to a given vertex.

[0015] This invention decomposes the process of matching the co-purchase relationship pattern graph with the co-purchase relationship data graph into several extension tasks. An extension task is an abstraction of the task of extending a vertex from a partial embedding to obtain a new partial embedding or embedding instance. Executing this extension task requires calculating the intersection of the neighbor lists of the vertices connected to the vertex to be extended in the partial embedding. Extension tasks are categorized into ready extension tasks and not ready extension tasks based on the readiness of their vertex neighbor lists. A ready extension task is one where all the required vertex neighbor lists are ready, while a not ready extension task is one where some vertex neighbor lists are not ready. Extension tasks are also categorized into single-vertex extension tasks and intermediate extension tasks based on the number of vertices in their partial embeddings. A single-vertex extension task is one where the partial embedding is a single vertex, while an intermediate extension task is one where the partial embedding is multiple vertices.

[0016] Cost refers to computational cost. The cost of a vertex is the computational cost of expanding the embedded instance from that vertex; the cost of a graph partition is the sum of the costs of all vertices in the graph partition; the cost of a neighbor group is the sum of the costs of all vertices in the neighbor group; the cost of a single vertex expansion task is the cost of the vertices in its partial embedding; the cost of an intermediate expansion task is the computational cost of performing the expansion task.

[0017] The co-purchase frequency model refers to the mapping from the set of edge labels of embedded instances to the co-purchase frequency, which is used to estimate the frequency at which the combination of goods represented by the vertices of the embedded instances is purchased by users at the same time.

[0018] During the operation of the co-purchasing recommendation system, each NUMA node loads the co-purchasing relationship data graph, partitions the graph, and stores it in a distributed manner. Based on the local graph partitioning and cost model, it generates cost-balanced single-vertex extension tasks. It obtains the vertex neighbor list required for task execution by accessing the local graph partitioning module, the vertex cache module, or through communication. Once all vertex neighbor lists are ready, the extension task is executed, generating cost-balanced intermediate extension tasks. This process is repeated until all embedded instances are obtained. Based on the co-purchasing frequency model, the most frequent embedded instances are selected as the final combined recommendation result.

[0019] The present invention specifically includes the following steps: The first step is to construct a distributed collaborative purchasing recommendation system based on graph pattern matching. This system is built upon a graph pattern matching-based distributed collaborative purchasing recommendation system. On a cluster of computer nodes. The computer nodes use a NUMA architecture, and each computer node contains There are NUMA nodes. Among them, NUMA is a memory design for multiprocessor computers, designed to address the memory access latency and bandwidth bottlenecks in traditional Symmetric Multi-Processing (SMP) architectures. NUMA divides multiple CPU cores and memory resources into multiple NUMA nodes. CPUs within each NUMA node can directly access the memory within their own NUMA node, resulting in lower latency and higher bandwidth. Accessing the memory of remote NUMA nodes requires an interconnect bus, leading to higher latency and lower bandwidth compared to local memory access. The distributed co-purchasing recommendation system based on graph pattern matching includes... There are NUMA nodes, each deploying a graph partitioning module, task generation module, task buffer module, task scheduling module, task execution module, vertex request module, vertex response module, and vertex cache module. Identical modules on each NUMA node execute in parallel. The interaction between modules within any two NUMA nodes is determined by the first NUMA node. The NUMA node and the first Let's illustrate this with a NUMA node. For ease of description, the present invention will refer to the first... , The modules on each NUMA node are denoted as modules. and modules .

[0020] Each graph partitioning module executes in parallel. To avoid additional data transfer, each graph partitioning module simultaneously loads the co-purchase relationship data graph, divides the graph into partitions, and stores one of the partitions in local memory. (The last sentence appears to be incomplete and possibly refers to a separate process.) The and the first Taking a NUMA node as an example, the graph partitioning module With the task generation module Task generation module Task execution module Vertex Response Module Connected. The set of vertices with lower degrees (i.e., degrees below the degree threshold) in the co-purchase relationship data graph. The set of vertices, This set of vertices (called light vertices) has a low probability of being visited, hence the graph partitioning module. Horizontally partition the vertex set, that is, divide the light vertex set into... A set of disjoint subsets is defined, and one subset and a list of neighbors of the vertices in that subset are stored in local memory; vertices with higher degree (i.e., degrees not lower than the degree threshold) are defined. Vertices that are frequently visited (called heavy vertices) have a higher probability of being accessed. To avoid frequent communication, this invention requires each computer node to store a complete list of its vertex neighbors. To save memory space, the graph partitioning module... Perform vertical partitioning on the multiple vertices, that is, divide the neighbor list of the multiple vertices evenly into... The graph partitioning module divides the graph into disjoint subsets and stores one subset of its neighbor lists in local memory. This subset is then shared with other NUMA nodes on the same computer node to store the neighbor lists of the heavy vertices. Furthermore, since the degree of the graph follows a power-law distribution, the expansion task involving heavy vertices is costly. Therefore, the graph partitioning module... The neighbor list of a heavy vertex is divided into a cost-balanced neighbor group and a vertex-balanced neighbor group for generating cost-balanced tasks. (Graph Partitioning Module) Send the vertex neighbor list and neighbor group to the task generation module. and task execution module Send the vertex set to the task generation module. Send the vertex neighbor list to the vertex response module. .

[0021] The task generation modules execute in parallel. (The sentence is incomplete and ends abruptly.) The and the first Taking a NUMA node as an example. Task generation module for each NUMA node With graph partitioning module Task buffer module and located in the Graph partitioning module with NUMA nodes Connected. Task generation module. From the graph partitioning module Receive the vertex neighbor list and neighbor group, generate a cost-balanced single-vertex expansion task based on the vertex neighbor list and neighbor group, and send the single-vertex expansion task to the task buffer module. To achieve runtime load balancing, in the graph partitioning module After all vertices in the task are used to generate single-vertex extended tasks, the task generation module... From the graph partitioning module The system receives a set of vertices, generates a cost-balanced single-vertex extension task based on the set, and then sends the single-vertex extension task to the task caching module. .

[0022] Each task buffer module executes in parallel. Task buffer module for each NUMA node and task generation module Task execution module Task scheduling module Vertex Request Module Connected. Task buffer module. From the task generation module Receive single-vertex extended tasks from the task execution module. Receive intermediate extended tasks. Task buffer module. Collect data from extended tasks that participate in set operations but are not stored in the graph partitioning module. and vertex cache module The vertex set is sent to the vertex request module. Request module from vertex Receive the vertex neighbor list of these vertices. Once the required vertex neighbor list is ready, convert the expansion task into a ready expansion task and send the ready expansion task to the task scheduling module. .

[0023] The task scheduling modules execute in parallel. (The sentence is incomplete and requires more context to translate accurately.) Taking a NUMA node as an example, the task scheduling module With task buffer module Task execution module Connected. Task scheduling module. From the task buffer module Upon receiving ready extension tasks, a mapping scheme (referred to as a task mapping scheme) is formed from the cost of the ready extension tasks to the computation threads. The task mapping scheme and the ready extension tasks are then sent to the task execution module. .

[0024] Each task execution module executes in parallel. (The sentence is incomplete and ends abruptly.) Taking a NUMA node as an example. Task execution module. With graph partitioning module Vertex caching module Task scheduling module and task buffer module Connected. Task execution module. Load the co-purchase relationship schema diagram, and generate the matching order and execution plan for the co-purchase relationship schema diagram. (Task Execution Module) From the task scheduling module Receive the task mapping scheme and ready extension tasks, and execute the ready extension tasks. If embedded instances are obtained after the ready extension tasks are completed, calculate the co-purchase frequency of the embedded instances based on the co-purchase frequency model, and update the set of embedded instances with higher frequencies; otherwise, proceed from the graph partitioning module. Receive the vertex neighbor list and neighbor group from the vertex cache module. Receive the vertex neighbor list and partition it according to the graph partitioning module. The received vertex neighbor list, neighbor group, and information from the vertex cache module. The received vertex neighbor list generates a cost-balanced intermediate extension task, which is then sent to the task buffer module. .like Once all ready extension tasks in the task execution module have been completed and no new intermediate extension tasks have been generated, the co-purchase combination recommendation result will be output to the user.

[0025] Each vertex request module executes in parallel. (The sentence is incomplete and requires more context to translate accurately.) The and the first Taking the nth NUMA node as an example, located at the nth Vertex request module for each NUMA node With task buffer module Vertex caching module and located in the Vertex response module of NUMA node Connected. Vertex Request Module From the task buffer module Obtain the vertex set (i.e., the task buffer module) The intermediate extension tasks required by it, but not stored in the graph partitioning module. and vertex cache module The set of vertices), packaged according to the NUMA node number of the vertex, will contain the vertex located at the NUMA node number. The set of vertices on each NUMA node is sent to the vertex response module. Then from the vertex response module Receive the vertex neighbor list and send it to the task buffer module. If the vertex neighbor list meets the caching criteria, it is sent to the vertex cache module. .

[0026] Each vertex response module executes in parallel. (The sentence is incomplete and requires more context to translate accurately.) The and the first Taking the nth NUMA node as an example, located at the nth Vertex response module of NUMA node With graph partitioning module Located in the first Vertex request module for each NUMA node Connected. Vertex Response Module From the vertex request module Receive vertex set from graph partitioning module Receive the vertex neighbor list, and select the neighbor list of vertices in the vertex set from the received vertex neighbor list to send to the vertex request module. .

[0027] Each vertex cache module executes in parallel. (The sentence is incomplete and requires more context to translate accurately.) Taking a NUMA node as an example, the vertex cache module With the task execution module Vertex Request Module Connected. Vertex cache module From the vertex request module Receive the list of vertex neighbors that need to be cached, store it locally, and then execute the task module. The required list of vertex neighbors is sent to the task execution module. .

[0028] The second step is to construct a data diagram and a schema diagram of the co-purchase relationship. The method is as follows: (2.1) Construct a co-purchase relationship data graph, the method is as follows: The Amazon co-purchasing network dataset (see "J. Leskovec, L. Adamic and B. Adamic. The Dynamics of Viral Marketing. ACM Transactions on the Web (ACMTWEB), 1(1), 2007") was used as the co-purchasing relationship data graph. This dataset contains purchase network data from the Amazon e-commerce platform on March 2nd, March 12th, May 5th, and June 1st, 2003. Vertices in the graph represent products; if there is an edge between two vertices, it means that customers simultaneously purchased the products corresponding to those two vertices. Edge labels were randomly constructed for all edges in the data graph. These edge labels simulated the frequency of co-purchasing relationships between the products represented by the two vertices connected to the edge. The co-purchasing relationship data graph is denoted as... ,in, For the set of vertices in the co-purchase relationship data graph, Let the set of edges be the data graph of co-purchase relationships. The number of vertices is denoted as .

[0029] (2.2) This invention aims to find recommended product combinations with co-purchase relationships. Similar to constructing a co-purchase relationship data graph, products are abstracted as vertices, and co-purchase relationships are abstracted as edges to construct a co-purchase relationship pattern graph. Taking a combination recommendation of 3 products as an example, if there are co-purchase relationships between product 1 and product 2, product 2 and product 3, and product 1 and product 3, then these three products can be recommended to users as a combination set. Based on this idea, this invention prioritizes the existence of a co-purchase relationship between any two products in the product combination recommendation, that is, there is an edge between any two vertices in the graph, thereby constructing a group-type co-purchase relationship pattern graph. A group refers to a graph structure where any two vertices are interconnected. In addition, to increase the types of co-purchase combination recommendations, the condition of "there is an edge between any two points" can be appropriately relaxed, thereby constructing a pseudo-group-type co-purchase relationship pattern graph. A pseudo-group is a dense graph structure where the internal vertices are "approximately fully connected". The co-purchase relationship pattern graph is denoted as ,in, yes The set of vertices, yes The set of edges, The number of vertices is denoted as .

[0030] The third step involves the graph partitioning modules on each NUMA node executing in parallel. To avoid additional data transfer, each graph partitioning module simultaneously loads the co-purchase relationship data graph. ,right The graph is partitioned into light and heavy vertices, and one partition from the light vertex partition and one partition from the heavy vertex partition are stored in local memory. Light vertices are accessed less frequently, so a cost model is built to estimate the cost of each vertex. Based on this cost model, the graph is partitioned horizontally. The light vertices in the middle are divided into Each subset contains vertices and their neighbors, forming a graph partition, thus yielding... A cost-balanced graph partition is created, with one partition stored in local memory to achieve load balancing. Since duplicate vertices are accessed more frequently, each computer node stores a complete list of vertex neighbors to avoid frequent communication. Simultaneously, to save memory space, [the following is omitted as the original text is incomplete and likely refers to further details about memory allocation]. Vertical partitioning is performed on the multiple vertices in the array, that is, the neighbor list of each multiple vertex is divided into... Each NUMA node stores a set of three equally sized and disjoint neighbor subsets, and a subset of the neighbor list after vertical partitioning is stored by the graph partitioning module located on the same computer node. The graph partitioning module on each NUMA node executes the same process, with the one located on the 1st node... Graph partitioning module on each NUMA node ( )right The method for partitioning a graph using light and heavy vertices is as follows: (3.1) Graph Partitioning Module Read the co-purchase relationship data graph ,statistics middle The degree of each vertex, The maximum degree among the degrees of the vertices and By obtaining key information such as the two-hop degree of each vertex, we obtain the vertex degree array. Vertex 2-hop degree array , The Middle vertices second hop degree refer to The sum of the degrees of the neighboring vertices. The method is: (3.1.1) Graph Partitioning Module Read And statistics The degree of each vertex is stored in a vertex degree array. , The CCP There are elements, among which correspond The degree.

[0031] (3.1.2) Traversal of Each element, obtain Maximum degree in and obtain middle Average degree of each element .

[0032] (3.1.3) Graph Partitioning Module statistics middle The two-hop degree of each vertex is stored in a vertex two-hop degree array. And calculate the total cost. The method is: (3.1.3.1) Let .

[0033] (3.1.3.2) Let the vertex index .

[0034] (3.1.3.3) vertices second hop Initialize to 0.

[0035] (3.1.3.4) Graph Partitioning Module from Reading Vertex neighbor vertex set Find the vertex according to formula (1) second hop degree ,Will Put into the vertex two-hop degree array middle.

[0036] , formula (1); For the set of neighboring vertices Mid-vertex The degree.

[0037] (3.1.3.5) Order ,in, It is the vertex The cost is calculated according to formulas (2) to (3).

[0038] , formula (2); , formula (3); (3.1.3.6) Order ,like , see (3.1.3.3), if , turn to (3.2).

[0039] (3.2) Let the degree threshold ,in It is an adjustable parameter. ,Will Medium degree less than The vertex that is not a light vertex is called a light vertex, and the remaining vertices are called heavy vertices. There is A light vertex, A single vertex .

[0040] (3.3) Graph Partitioning Module in accordance with and right middle Light vertices are horizontally partitioned. To ensure a relatively balanced load across NUMA nodes, a cost model is constructed to estimate the computational cost of each graph partition, dividing the light vertices into... A cost equilibrium diagram partition . It is the first Each graph partition can be formally represented as a pair of tuples. , , The meaning of this pair is the first... Individual map partitions Including vertex index The light vertex. Formula (4) is the cost model used to calculate Cost .

[0041] , formula (4); in ; For ease of description, of Value and The values ​​are respectively denoted as and The method for horizontal partitioning is: (3.3.1) Let the vertex index .

[0042] (3.3.2) Let the partition index .

[0043] (3.3.3) Let .

[0044] (3.3.4) Calculate the mean cost of the partition , .

[0045] (3.3.5) Let the first Cost per partition .

[0046] (3.3.6) If This indicates the current vertex. If it is a light vertex, proceed to (3.3.7); otherwise, indicate that the current vertex... It is a heavy vertex, does not participate in horizontal partitioning, and does not need to be partitioned. Cost join in , directly transfer to (3.3.8).

[0047] (3.3.7) Let .

[0048] (3.3.8) Order ,if That is, the first If the cost of a partition is less than the average cost of the partitions, vertices need to be added, go to (3.3.6); otherwise, it means that the cost of the partitions has reached the average, and no vertices need to be added, go to (3.3.9).

[0049] (3.3.9) Order .

[0050] (3.3.10) Let the partition index ,like , see (3.3.3); if This indicates that the partitioning is complete and the graph partitioning results for light vertices are obtained. Proceed to (3.4).

[0051] (3.4) Graph Partitioning Module Read And collect the first Individual map partitions The list of neighbors of the middle vertex is stored in local memory.

[0052] (3.5) Graph Partitioning Module Will In The set of multiple vertices is denoted as the set of multiple vertices. , , It is the first A single vertex Because heavy vertices are accessed more frequently, to avoid frequent communication and save memory space, [the following is omitted as the text is incomplete and cannot be translated]. Perform vertical partitioning, dividing the neighbor list of each heavy vertex into... A set of equally sized and disjoint neighbor subsets, graph partitioning module. Storage number A subset is selected such that each computer node stores a copy of the heavy vertices. The method for vertical partitioning is: (3.5.1) Let the index of the multiple vertices be... .

[0053] (3.5.2) Read Find the neighboring vertices and obtain the neighbor list. .

[0054] (3.5.3) will Divided into A set of neighboring subsets that are of equal size and do not overlap.

[0055] (3.5.4) Graph Partitioning Module Storage number A subset of neighbors.

[0056] (3.5.5) Order ,like Go to (3.5.2); otherwise, for middle After processing all heavy vertices, the partitioning and storage of heavy vertices are completed. Proceed to (3.6).

[0057] (3.6) Graph Partitioning Module Send the locally stored list of neighbors for light and heavy vertices to the task generation module. and task execution module .

[0058] Fourthly, since the degree of the graph follows a power-law distribution, the cost of expanding tasks involving multiple vertices is high. Therefore, the graph partitioning modules of each NUMA node are executed in parallel. In The neighbor lists of each heavy vertex are divided into cost-balanced neighbor groups and vertex-balanced neighbor groups based on cost and number of vertices, respectively. These are used to generate the cost-balanced task in the subsequent sixth step, enabling finer-grained task parallelism and load balancing. (The last sentence appears to be incomplete and possibly refers to a different topic.) Graph partitioning module on each NUMA node For example, The method is: (4.1) Graph Partitioning Module right In The neighbor list of each heavy vertex is divided according to cost. A cost-equilibrium neighbor group is obtained. The cost-equilibrium neighbor group of all heavy vertices will be the first Each vertex The A cost-equilibrium neighbor group is denoted as , The resulting cost-balanced neighbor groups are used in the subsequent fifth step to decompose the computationally intensive single-vertex extension tasks, achieving fine-grained task parallelism and load balancing. The method is as follows: (4.1.1) Let the index of the multiple vertices be... .

[0059] (4.1.2) will The Middle Each vertex The neighbor list is recorded as , , ,for The number of vertices in the middle. Calculate. The estimated cost of each vertex in the middle, of which Estimated cost Calculate according to formula (5), and The estimated cost of each vertex is temporarily stored in the cost array. ,right middle The costs are summed up to obtain the total cost. .

[0060] , formula (5); (4.1.3) Calculate the first using formula (6). Each vertex The Neighborhood group Cost : , formula (6); (4.1.4) Based on Will The neighbor list is divided into A cost-equilibrium neighbor group. For ease of description, the first... A group of neighbors is denoted as a binary group. ,express The Each neighbor group contains a list of neighbors. The middle index belongs to the range The vertices inside will In , They are respectively denoted as and .Will The method for dividing the neighbor list into neighbor groups is: (4.1.4.1) Let the neighbor vertex index .

[0061] (4.1.4.2) Let the neighbor group index .

[0062] (4.1.4.3) Let .

[0063] (4.1.4.4) Graph Partitioning Module Calculate the mean cost of the neighbor group , .

[0064] (4.1.4.5) Cost of new neighbor groups .

[0065] (4.1.4.6) Let .

[0066] (4.1.4.7) Let .if , then proceed to (4.1.4.6); otherwise, proceed to the next step. Neighborhood group The cost exceeds the average cost of the neighboring group, see (4.1.4.8).

[0067] (4.1.4.8) Order .

[0068] (4.1.4.9) Order ,like If yes, then proceed to (4.1.4.3); otherwise, repeat the vertex. The neighbor list has been divided into 1 neighbor group, get The cost-equilibrium neighbor group, see (4.1.5).

[0069] (4.1.5) Order ,like Go to (4.1.2), otherwise, The neighbor list of all heavy vertices has been partitioned into The neighbor group received The cost-equilibrium neighbor group of all heavy vertices is determined, see (4.2).

[0070] (4.2) Graph Partitioning Module right In Each vertex The neighbor list is divided into several vertex-balanced neighbor groups based on the number of vertices. Among them, the first... vertices Neighbor list Divided into The neighbor group of the th vertex is balanced, except for the th vertex. In addition to the one neighbor group, all other neighbor groups include One vertex, The resulting balanced neighbor groups are used in the subsequent sixth step to decompose the computationally intensive intermediate extension tasks, achieving fine-grained task parallelism and load balancing. The partitioning method is as follows: (4.2.1) Let the threshold parameter for the number of vertices in the neighbor group be... .

[0071] (4.2.2) Let .

[0072] (4.2.3) will The first in Each vertex neighbor vertex set The number of vertices is of The last neighbor group is the _th neighbor group, and the last neighbor group is the _th neighbor group. The number of vertices in a neighboring group can be ,in, The Middle Each vertex The A balanced neighbor group of vertices is denoted as , .

[0073] (4.2.4) Let ,like Go to (4.2.3), otherwise, the neighbor lists of all heavy vertices have been divided into neighbor groups with balanced vertices, go to (4.3).

[0074] (4.3) Graph Partitioning Module Will middle The cost-balanced neighbor groups and vertex-balanced neighbor groups of each heavy vertex are sent to the task generation module. and task execution module .

[0075] Fifth, the task buffer modules of each NUMA node execute in parallel, the vertex request modules of each NUMA node execute in parallel, and the task execution modules of each NUMA node execute in parallel to initialize the task ready queue. Task cache area Vertex request queue and embedded instance collection (i.e., combined recommendation results). The task execution module calculates... Matching order and the corresponding execution plan With the first Taking a NUMA node as an example The method is: (5.1) Task buffer module Initialize a task ready queue and a task cache .

[0076] (5.2) Vertex Request Module initialization The vertex request queue, where the first vertex... The vertex request queue is denoted as .

[0077] (5.3) Task Execution Module Initialize a collection of embedded instances , used to record the indivual Recommended co-purchase packages at the node.

[0078] (5.4) Task Execution Module Loading co-purchase relationship diagram ,calculate Matching order and the corresponding execution plan The method is: (5.4.1) Selection The vertex with the highest degree As and Matching order The first vertex in, followed by the next vertex in Choose from the remaining vertices in the middle. The vertex with the most adjacent vertices is selected as the next vertex in the matching order. Matching order , , , yes An ordered set of vertices. yes The number of vertices, It is the first in the matching order One vertex.

[0079] (5.4.2) Based on Calculate the corresponding execution plan ,in, , No. A set of vertices yes Central Previous vertex set Zhongyu A set of connected vertices. (This is achieved through calculation.) The intersection of the neighbor lists of the vertices mapped to the co-purchase relationship data graph in the graph can be used to obtain the matching order of the vertices. A candidate set of vertices.

[0080] Step 6: Utilizing the cost-balanced neighbor groups and vertex-balanced neighbor groups formed in step (4.3), the task generation module, vertex request module, vertex response module, task buffer module, task scheduling module, and task execution module cooperate to use a distributed pattern graph matching algorithm in parallel. Perform pattern matching to obtain Diagram of the relationship between China and co-purchasing Homogeneous embedded instances with high frequency of co-purchase represent the product set of each embedded instance's vertex set as the combined recommendation result. The task generation module and task buffer module cooperate to process the data according to the procedure in (6.1). In the matching order, the first vertex is matched to One vertex is used to generate a cost-balanced single-vertex extension task; at the same time, the vertex request module and the vertex response module cooperate with each other and execute according to the process in (6.2), obtaining the vertex neighbor list required for task execution through communication; at the same time, the task buffer module, the task scheduling module and the task execution module cooperate with each other and continuously execute the single-vertex extension task according to the process in (6.3), generating intermediate extension tasks or embedded instances, and selecting several embedded instances with higher frequency of co-purchase to store. Execute intermediate extension tasks, repeating this process until no more intermediate extension tasks are generated, ultimately yielding a result containing the combined recommendation results. Extend the task Represented as a quadruple, , express exist Partial embedding on; Represents a set of vertices. The vertices in the diagram are matched vertices connected to the vertex to be expanded (i.e., the vertex to be expanded is partially embedded). (neighboring vertices in the data). express The neighbor list or neighbor group of the middle vertex can be calculated. We obtain the intersection of the neighbor lists of the mid-vertex. The candidate set of the next vertex to be expanded (i.e., the set of vertices that the vertex to be expanded can match in the vertices of the co-purchase relationship data graph). Indicate execution The cost. The method is: (6.1) The task generation modules of each NUMA node work in parallel to generate cost-balanced single-vertex extension tasks and send them to the local task buffer module. After all local single-vertex extension tasks have been generated, the vertex set is stolen from the graph partitioning module of the remote NUMA node to generate the stolen single-vertex extension task. (The sentence is incomplete and ends abruptly.) Taking a NUMA node as an example Task generation module Based on graph partitioning module The obtained vertex neighbor list and neighbor groups generate a cost-balanced single-vertex expansion task, which is then sent to the task buffer module. When the first After all single-vertex tasks on each NUMA node have been generated, to achieve dynamic load balancing, this invention employs a task-stealing mechanism, selecting a suitable NUMA node based on a priority order: local computer node first, then remote computer node. ( ), from the graph partitioning module Steal a set of vertices from the dataset and generate a single-vertex extension task from the stolen vertex. The method is as follows: (6.1.1) Since the degree of a heavy vertex is large, generating a single-vertex extension task for each heavy vertex would be computationally expensive. Therefore, this invention utilizes the cost-balanced neighbor group generated in step four to generate a single-vertex extension task for each heavy vertex. A cost-balanced, single-vertex scaling task. Based on the task generation module. For example, let the task generation module Located in the The first computer node Each NUMA node, at this time , ,1 .for In Each key vertex, task generation module For each heavy vertex, a low-cost single-vertex extension task is generated based on a group of its neighbors. The method is as follows: (6.1.1.1) Let .

[0081] (6.1.1.2) Task Generation Module generate The first in Each vertex Single-vertex extension task . Re-vertices Match to Matching order The first vertex in Therefore exist Partial embedding on The neighbors of the vertex to be expanded are only multiple vertices. Therefore To reduce the amount of computation, Only for The expansion will be carried out on some of the neighbors, therefore, we choose... A neighbor group As , yes The index of the cost-balanced neighbor group. The neighbor list is divided into in step (3.5) Each partition, graph partition module Storage number Each partition, simultaneously. The neighbor list is divided in step (4.1) The neighbor group can be approximated as the th neighbor group. The partition contains the first To the Each neighboring group, therefore , making Calculate the neighbor set of the candidate set It is stored in the memory of the local NUMA node, thereby reducing access across NUMA nodes and lowering memory access latency. It is based on the neighbor group The computational cost of extending the current embedding is therefore... Substituting into formula (6) to calculate... ,make .

[0082] (6.1.1.3) Task Generation Module Will Send to task buffer module .

[0083] (6.1.1.4) Task Buffer Module Will Store in the task ready queue If it is already full, then , This represents the maximum capacity of the task ready queue. Proceed to (6.1.1.4), and wait for a time interval. , ,like If not yet complete, proceed to (6.1.1.5).

[0084] (6.1.1.5) Order ,like If yes, proceed to (6.1.1.2); otherwise, it indicates that a single-vertex extension task has been generated for all vertices, proceed to (6.1.2).

[0085] (6.1.2) The task generation modules execute in parallel. (The sentence is incomplete and ends abruptly.) Task generation module on each NUMA node For example Task generation module From the graph partitioning module Get The task involves generating a list of neighbors for each light vertex and then extending that list to a single vertex. Each light vertex is denoted as , The method is: (6.1.2.1) Task Generation Module Initialize the index of the local partition light vertices, let .

[0086] (6.1.2.2) Task Generation Module Initialization by the first Single-vertex extended task generated by a light vertex . Light vertex Match to Matching order The first vertex in Therefore, partial embedding Light vertex It is a vertex connected to the vertex to be expanded, therefore ; The neighbor list of the middle vertex is Therefore ; It is to light vertex The cost of extending to full embedding, i.e. The cost, therefore Substituting into formula (2) to calculate... ,make .

[0087] (6.1.2.3) Task Generation Module Will Send to task buffer module .

[0088] (6.1.2.4) Task Buffer Module Will Store in the ready queue If the process is full, proceed to (6.1.2.4) and wait for a time interval. ;like Not yet, proceed to (6.1.2.5).

[0089] (6.1.2.5) Task Generation Module make ,like Proceed to (6.1.2.2); otherwise, proceed to the graph partitioning module. All light vertices in the array have been used to generate single-vertex extension tasks, see (6.1.3).

[0090] (6.1.3) To achieve dynamic load balancing, storage in the remote graph partitioning module is dynamically stolen based on cost. The set of vertices in the , . Values ​​are retrieved according to the following strategy: First, the remote NUMA nodes on the local computer node are searched, then the NUMA nodes on the remote computer node are searched. (i.e., the diagram partitioning module) The task generation module (not all light vertices on the module have been generated yet) is a single-vertex scalable embedding module. Task generation module From the graph partitioning module Obtain several vertices such that the sum of the costs of these vertices approaches the cost threshold. , The set of vertices in this group is denoted as the stolen vertex set. ,Will The Middle Each vertex is denoted as , .like Number of mid vertices Task generation module If the operation is complete, proceed to (6.4); otherwise, proceed to (6.1.4).

[0091] (6.1.4) Task Generation Module Stealing vertex set To generate a single-vertex extended task, the method is as follows: (6.1.4.1) Let the vertex index .

[0092] (6.1.4.2) Initialize the stealing task ,in, ,Will Substituting into formula (2) to calculate... ,make .

[0093] (6.1.4.3) If the task buffer in the task buffer module If full, proceed to (6.1.4.3) and wait for a time interval. Otherwise, proceed to (6.1.4.4).

[0094] (6.1.4.4) The task Add to task buffer , will the vertex The request queue is placed in the vertex request module. middle.

[0095] (6.1.4.5) ,like Go to (6.1.4.2); otherwise, it indicates that the vertex set has been stolen. All vertices in the array have been generated as single-vertex scalable embeddings, see (6.1.5).

[0096] (6.1.5) Order ,like This indicates that there are still stealable graph partitioning modules. If yes, proceed to (6.1.3); otherwise, explain. The light vertices of the graph partitioning module have all been generated as single-vertex scalable embeddings, and the task generation module... Once completed, proceed to (6.4).

[0097] (6.2) The vertex request module, vertex response module, task buffer module, and vertex cache module of each NUMA node cooperate to obtain and store the list of vertex neighbors required for task execution in parallel. The vertex request module... Vertex Response Module Task buffer module and vertex cache module For example, , The method is: (6.2.1) If the vertex request module The first in Request queues The vertex request module is filled. Vertex Response Module send Set the vertex set in the data and clear it. .

[0098] (6.2.2) Vertex Response Module Receive Vertex Request Module The set of vertices sent from the graph partitioning module The vertex request module retrieves a list of vertex neighbors from the vertex set. .

[0099] (6.2.3) Vertex Request Module Receive vertex response module Send the vertex neighbor list, and then send the vertex neighbor list to the task buffer module. and vertex cache module Task buffer module and vertex cache module Store the list of vertex neighbors.

[0100] (6.2.4) If the task execution module No more intermediate extension tasks are generated; vertex request module and vertex response module If execution is complete, proceed to (6.4); otherwise, proceed to (6.2.1).

[0101] (6.3) The task buffer module, task scheduling module and task execution module of each NUMA node cooperate with each other to execute tasks in parallel, generate new intermediate extended tasks, and repeat this process until the co-purchase relationship data graph is obtained. Diagram of the relationship between China and co-purchasing All isomorphic embedded instances, and continuously update the set of embedded instances. . It is the frequency of co-purchase. A large set of embedded instances, where the set of products represented by each vertex of an embedded instance constitutes a co-purchase combination recommendation result. Wherein... The task buffer module, task scheduling module, and task execution module of each NUMA node cooperate to execute tasks in parallel, generate new intermediate extended tasks, and continuously update the embedded instance set Recommend using the following method: (6.3.1) Task Buffer Module Waiting for the module to be requested from the vertex Receive the vertex neighbor list and complete the task data. The method is as follows: (6.3.1.1) If the task buffer module No request received from the vertex module Send the vertex neighbor list, go to (6.3.1.1), and wait for a time interval. , If a request is received from the vertex request module If the list of vertex neighbors is sent, then proceed to (6.3.1.2).

[0102] (6.3.1.2) Task Buffer Module The task list corresponding to the received vertex neighbor list is denoted as The total number of tasks , of which Each task is recorded as , task sequence number .

[0103] (6.3.1.3) Find the vertex neighbor list from the received vertex neighbor list The required list of vertex neighbors is assigned to The third item in the list.

[0104] (6.3.1.4) will From the task buffer Delete it.

[0105] (6.3.1.5) If the task ready queue If full, proceed to (6.3.1.5) and wait for a time interval. Otherwise, the task ready queue Not yet, proceed to (6.3.1.6).

[0106] (6.3.1.6) The task Add to ready queue area .

[0107] (6.3.1.7) Order ,like Proceed to (6.3.1.3); otherwise, the task buffer module... All extended tasks corresponding to the vertex neighbor list have been prepared. The ready extended tasks corresponding to the vertex neighbor list are obtained. Proceed to (6.3.2).

[0108] (6.3.2) Task Scheduling Module Receive from the task buffer module The ready-to-expand tasks form a task mapping scheme, the method being: (6.3.2.1) Task Execution Module Open One worker thread, It is a positive integer.

[0109] (6.3.2.2) Task Execution Module ready queue When the task list is full, a pop-up will appear. And send it to the task scheduling module. .

[0110] (6.3.2.3) Task Scheduling Module Based on cost Average score A cost-equilibrium task group, of which the first... Group tasks are denoted as binary groups. , indicating the first Group tasks include a task list The task sequence number is located in The task. For ease of description, In and They are respectively denoted as and The method is: (6.3.2.3.1) Let Number of tasks , of which Each task is recorded as Calculation task list The sum of the costs of the tasks is denoted as . .

[0111] (6.3.2.3.2) Let the task group index Task Index .

[0112] (6.3.2.3.3) Order .

[0113] (6.3.2.3.4) Calculate the average cost of the task group , that is to say .

[0114] (6.3.2.3.5) Command the task group Cost .

[0115] (6.3.2.3.6) Order ,in yes The estimated cost equals The fourth item.

[0116] (6.3.2.3.7) Order .if Task group If the cost is less than the average cost of the task group, it means that the current cost of the task group is insufficient and a task needs to be added. Proceed to (6.3.2.3.6); otherwise, it means that the cost of the task group has reached the average and no task needs to be added. Proceed to (6.3.2.3.8).

[0117] (6.3.2.3.8) Order .

[0118] (6.3.2.3.9) Order ,like If the task groups are divided and cost-equilibrium task groups are obtained, proceed to (6.3.2.3.3); otherwise, if the task groups are divided and cost-equilibrium task groups are obtained, proceed to (6.3.2.4).

[0119] (6.3.2.4) The generated by (6.3.2.3) A cost-equilibrium task group is randomly assigned to Each thread obtains a task mapping scheme, and then combines the task mapping scheme with... A cost-balanced task group is sent to the task execution module. .

[0120] (6.3.3) Task Execution Module Receive from the task scheduling module Task mapping scheme and A cost-equilibrium task group is assigned to a task group according to the task mapping scheme. One thread.

[0121] (6.3.4) Task Execution Module middle Threads execute in parallel Tasks in a cost-balanced task group. Among them, the first... The assigned thread executes the first... Task groups If the task expands the matching order The last vertex in the extended task (partial embedding) Include If there are vertices, then the final matching result is obtained through calculation and updated. Otherwise, an intermediate extension task will be generated. Send intermediate extended tasks to the task buffer module. If an intermediate extension task If all four entries have been assigned values, the intermediate extension task is ready; otherwise, the intermediate extension task is not ready. Task Buffer Module Store ready intermediate extension tasks into the task ready queue. Store unread intermediate extended tasks in the task buffer. Recommended combinations Storage co-purchase frequency value The highest front An embedding, This refers to embedding elements in the co-purchase relationship data graph that are isomorphic to the co-purchase relationship pattern graph and have a high co-purchase frequency value. The method is: (6.3.4.1) Let the task index Z= .

[0122] (6.3.4.2) For the first Task groups The first in Task Through calculation The intersection of the vertex neighbor lists in the array is used to obtain the vertices to be expanded. (i.e., matching order) The first in Candidate set of vertices , express The number of partially embedded vertices.

[0123] (6.3.4.3) The candidate sets are respectively Vertex in Match to the vertex to be expanded If the task expands the matching order The last vertex (i.e.) If so, the embedded instance is obtained directly, and then updated. Otherwise, generate a new intermediate scalable task set. This is possible within the graph partitioning module. Or vertex cache module If the list of vertex neighbors required for all extended tasks is obtained, a ready intermediate scalable task is generated; otherwise, a not-ready intermediate scalable task is generated. The method is as follows: (6.3.4.3.1) Calculate the first entry of the intermediate scalable task, partially embedded. If it is the last expansion (i.e. , express (the number of vertices), then the result is For embedded instances, the calculation is performed according to the co-purchase frequency model formulas (7) to (9). Co-purchase frequency value , for The set of edge labels, if There are co-purchase frequency values ​​lower than Embedded instance Then from Delete, join in Proceed to (6.3.4.5) to execute the next task; otherwise, proceed according to the execution plan. Obtain the vertex set of the intermediate scalable task , , then (6.3.4.3.2).

[0124] , formula (7); , formula (8); , formula (9); in, , For embedded instances The number of middle edges, For balancing parameters, .

[0125] (6.3.4.3.2) Let This leads to a new set of tasks that are not yet ready. The set of tasks ready .like In Excluding multiple vertices, go to (6.3.4.3.3); if It contains heavy vertices, see (6.3.4.3.6).

[0126] (6.3.4.3.3) Task Execution Module From the vertex cache module HeTu Partition Module Get from The set of neighbor lists of vertices in ,make If the vertex set Does it exist that are not stored in the graph partition module? With vertex cache module If the vertex is reached, proceed to (6.3.4.3.4); otherwise, All vertices in the graph are stored in the graph partitioning module. Or vertex cache module In the middle, turn (6.3.4.3.5).

[0127] (6.3.4.3.4) Task Execution Module Generate unread intermediate extension tasks , ,in, Only includes data stored in the graph partition module With vertex cache module Vertex neighbor list, cost Temporarily initialized to 0, stored in the remote graph partitioning module. Vertex neighbor list and cost This needs to be completed through subsequent steps (6.3.6). This will allow for the creation of a set of tasks that are not yet ready. (6.3.4.4)

[0128] (6.3.4.3.5) Calculate the cost of intermediate extension tasks according to formula (10). The cost is The sum of the cardinality of each set generates a ready intermediate extension task. , and the task Add to the ready extended task set, i.e., the set of tasks that are ready. (6.3.4.4)

[0129] , formula (10); in, Indicates task In .

[0130] (6.3.4.3.6) Task Execution Module From the vertex cache module HeTu Partition Module Get from The set of neighbor lists of light vertices in ,make If the vertex set There are light vertices that are not stored in the graph partitioning module. With vertex cache module In the middle, proceed to (6.3.4.3.7); otherwise, vertex set. All light vertices in the graph are stored in the graph partitioning module. or vertex cache module In the middle, turn (6.3.4.3.10).

[0131] (6.3.4.3.7) Task Execution Module From the graph partitioning module Get from Each heavy vertex in The vertex neighbor list, where and heavy vertex The neighbor list is recorded as , The number of intermediate vertices is denoted as Select the vertex with the largest degree and denote it as . Task execution module From the graph partitioning module China receives Vertex-balanced neighbor groups .

[0132] (6.3.4.3.8) Let the number of unread intermediate tasks be... The task execution module is based on the vertex with the highest degree of repetition. The vertex-balanced neighbor group splits the costly intermediate extension task into smaller parts, generating... An incomplete intermediate extension task, denoted as , order the The task is ,in , including neighbor groups of heavy vertices and stored in the graph partitioning module With vertex cache module Vertex neighbor list, cost Temporarily set to 0, stored in the remote graph partitioning module. Vertex neighbor list and cost It needs to be completed through subsequent steps (6.3.6).

[0133] (6.3.4.3.9) Order (6.3.4.4)

[0134] (6.3.4.3.10) Task Execution Module From the graph partitioning module Obtain each heavy vertex The vertex neighbor list, where and Its neighbor list is recorded as , The number of multiple vertices in the array is denoted as . Select the vertex with the largest degree and denote it as . From the graph partitioning module China receives Neighbor Group .

[0135] (6.3.4.3.11) Order Task execution module generates A ready intermediate extension task, denoted as , of which The task is ,in, , whereby by Substitute into formula (10) to calculate the estimated cost of the task. ,make .

[0136] (6.3.4.3.12) Order .

[0137] (6.3.4.4) Task Execution Module Send the newly generated intermediate extended task to the task buffer module. Task caching module Store ready intermediate scalable tasks and non-ready intermediate scalable tasks into the ready queue respectively. and task buffer The method is: (6.3.4.4.1) If the task buffer module Task ready queue Full, proceed to (6.3.4.4.1) and wait for a time interval. Otherwise, proceed to (6.3.4.4.2).

[0138] (6.3.4.4.2) The task Add to the task ready queue .

[0139] (6.3.4.4.3) If the task buffer module Task buffer Full, proceed to (6.3.4.4.3) and wait for a time interval. Otherwise, proceed to (6.3.4.4.4).

[0140] (6.3.4.4.4) The task Add to task buffer .

[0141] (6.3.4.5) Order ,like , No. Task groups If there are still unfinished tasks, proceed to (6.3.4.2); otherwise, proceed to step 1. Task groups Once all tasks have been completed, proceed to (6.3.5).

[0142] (6.3.5) If the task execution module If no further intermediate extension tasks are generated, proceed to (6.3.7); otherwise, proceed to (6.3.6).

[0143] (6.3.6) Task Buffer Module Prepare vertex neighbor list data for the unread intermediate extension tasks in the task buffer and calculate the cost of the tasks, thereby converting the unread intermediate extension tasks into ready intermediate extension tasks. The method is as follows: (6.3.6.1) Task Buffer Module Send the set of vertices in the task buffer that are missing neighbor lists to the vertex request module. The vertex request module groups the vertex set according to the NUMA nodes where the vertices are stored, dividing it into... The nth vertex subset will be the nth vertex subset. Add a subset of vertices to the request queue , .

[0144] (6.3.6.2) Task Buffer Module From the vertex request module Receive the required vertex neighbor list, find the vertex neighbor list required by the incomplete intermediate extension task from the required vertex neighbor list, and add it to the incomplete intermediate extension task. item.

[0145] (6.3.6.3) Task caching module Calculate the cost of each task according to formula (10) and add it to the unread intermediate extension tasks. This allows an unread intermediate extension task to become a ready intermediate extension task.

[0146] (6.3.6.4) If the task buffer module Task ready queue Full, proceeding to (6.3.6.4), waiting for a time interval. Otherwise, proceed to (6.3.6.5).

[0147] (6.3.6.5) Task caching module Remove ready intermediate extended tasks from the task buffer. Delete and add to the task ready queue. , see (6.3.1).

[0148] (6.3.7) Task Execution Module Output Embedded instances represent co-purchase relationship data graphs. Diagram of the relationship between China and co-purchasing Isomorphic subgraphs. Embedded instances. A larger value indicates that the co-purchase relationship between embedded instances occurs more frequently. The set of products represented by the vertex of each embedded instance is a co-purchase combination recommendation result, see (6.4).

[0149] (6.4) End.

[0150] The following beneficial effects can be achieved by using the present invention: This invention proposes a distributed co-purchasing recommendation method based on graph pattern matching. The following technical effects can be achieved by using this invention: 1. The third step of this invention proposes a cost model to estimate the computational load of task execution. Based on the cost model, the light vertices of the co-purchase relationship data graph are horizontally partitioned and the heavy vertices are vertically partitioned, so that the initial distribution of computational load on each NUMA node is relatively balanced. The fourth step uses the vertex neighbor list partitioning method to divide the neighbor list of heavy vertices into cost-balanced neighbor groups and vertex-balanced neighbor groups, realizing finer-grained parallelism and improving response speed. 2. In steps five and six of this invention, cost-balanced neighbor groups and vertex-balanced neighbor groups are used to generate cost-balanced single-vertex extension tasks and intermediate extension tasks. A cost-based task-stealing method is used to achieve dynamic load balancing, thereby improving the matching speed. Subgraphs that are isomorphic to the co-purchase relationship pattern graph are mined in the co-purchase relationship data graph. Several subgraphs with higher co-purchase frequencies are selected as the combined recommendation results using the co-purchase frequency model, thereby realizing efficient combined recommendation on e-commerce platforms and improving recommendation efficiency. 3. This invention achieves accurate recommendations by constructing a group-buying relationship diagram, providing technical support for large e-commerce platforms to conduct efficient, accurate, and real-time recommendations. Attached Figure Description

[0151] Figure 1 is an architecture diagram of the distributed co-purchasing recommendation system based on graph pattern matching constructed in the first step of this invention; Figure 2 This is the logical structure diagram of any two NUMA nodes in the distributed co-purchasing recommendation system based on graph pattern matching constructed in the first step of this invention; Figure 3 This is the overall flowchart of the present invention; Figure 4This is a diagram illustrating the co-purchase relationship model used in the embodiments of the present invention. Detailed Implementation

[0152] Specific embodiments of the present invention will now be described with reference to the accompanying drawings. Figure 3 As shown, the embodiments of the present invention include the following steps: The first step is to build a distributed co-purchasing recommendation system based on graph pattern matching. For example... Figure 1 As shown, a distributed co-purchasing recommendation system based on graph pattern matching is built on a graph containing... On a cluster of computer nodes. The computer nodes use a NUMA architecture, and each computer node contains NUMA nodes. NUMA is a memory design for multiprocessor computers, designed to address the memory access latency and bandwidth bottlenecks in traditional Symmetric Multi-Processing (SMP) architectures. NUMA divides multiple CPU cores and memory resources into multiple NUMA nodes. CPUs within each NUMA node can directly access the memory within their respective NUMA node, resulting in lower latency and higher bandwidth. Accessing the memory of remote NUMA nodes requires an interconnect bus, leading to higher latency and lower bandwidth compared to local memory access. The distributed co-purchasing recommendation system based on graph pattern matching includes... There are 10 NUMA nodes, each of which deploys a graph partitioning module, a task generation module, a task buffering module, a task scheduling module, a task execution module, a vertex request module, a vertex response module, and a vertex cache module. Identical modules on each NUMA node execute in parallel. Figure 2 This demonstrates the interaction between modules within any two NUMA nodes, including the first... The data interaction relationships between modules within each NUMA node, and the data interaction relationships between the .... Some modules in the NUMA node are related to the NUMA node. Data interaction relationships between some modules in a NUMA node. For ease of description, the present invention will refer to the first... , The modules on each NUMA node are denoted as modules. and modules .

[0153] Each graph partitioning module executes in parallel. To avoid additional data transfer, each graph partitioning module simultaneously loads the co-purchase relationship data graph, divides the graph into partitions, and stores one of the partitions in local memory. (The last sentence appears to be incomplete and possibly refers to a separate process.) The and the first Taking a NUMA node as an example, the graph partitioning module With the task generation module Task generation module Task execution module Vertex Response Module Connected. The set of vertices with lower degrees (i.e., degrees below the degree threshold) in the co-purchase relationship data graph. The set of vertices, This set of vertices (called light vertices) has a low probability of being visited, hence the graph partitioning module. Horizontally partition the vertex set, that is, divide the light vertex set into... A set of disjoint subsets is defined, and one subset and a list of neighbors of the vertices in that subset are stored in local memory; vertices with higher degree (i.e., degrees not lower than the degree threshold) are defined. Vertices that are frequently visited (called heavy vertices) have a higher probability of being accessed. To avoid frequent communication, this invention requires each computer node to store a complete list of its vertex neighbors. To save memory space, the graph partitioning module... Perform vertical partitioning on the multiple vertices, that is, divide the neighbor list of the multiple vertices evenly into... The graph partitioning module divides the graph into disjoint subsets and stores one subset of its neighbor lists in local memory. This subset is then shared with other NUMA nodes on the same computer node to store the neighbor lists of the heavy vertices. Furthermore, since the degree of the graph follows a power-law distribution, the expansion task involving heavy vertices is costly. Therefore, the graph partitioning module... The neighbor list of a heavy vertex is divided into a cost-balanced neighbor group and a vertex-balanced neighbor group for generating cost-balanced tasks. (Graph Partitioning Module) Send the vertex neighbor list and neighbor group to the task generation module. and task execution module Send the vertex set to the task generation module. Send the vertex neighbor list to the vertex response module. .

[0154] The task generation modules execute in parallel. (The sentence is incomplete and ends abruptly.) The and the first Taking a NUMA node as an example. Task generation module for each NUMA node With graph partitioning module Task buffer module and located in the Graph partitioning module with NUMA nodes Connected. Task generation module. From the graph partitioning module Receive the vertex neighbor list and neighbor group, generate a cost-balanced single-vertex expansion task based on the vertex neighbor list and neighbor group, and send the single-vertex expansion task to the task buffer module. To achieve runtime load balancing, in the graph partitioning module After all vertices in the task are used to generate single-vertex extended tasks, the task generation module... From the graph partitioning module The system receives a set of vertices, generates a cost-balanced single-vertex extension task based on the set, and then sends the single-vertex extension task to the task caching module. .

[0155] Each task buffer module executes in parallel. Task buffer module for each NUMA node and task generation module Task execution module Task scheduling module Vertex Request Module Connected. Task buffer module. From the task generation module Receive single-vertex extended tasks from the task execution module. Receive intermediate extended tasks. Task buffer module. Collect data from extended tasks that participate in set operations but are not stored in the graph partitioning module. and vertex cache module The vertex set is sent to the vertex request module. Request module from vertex Receive the vertex neighbor list of these vertices. Once the required vertex neighbor list is ready, convert the expansion task into a ready expansion task and send the ready expansion task to the task scheduling module. .

[0156] The task scheduling modules execute in parallel. (The sentence is incomplete and requires more context to translate accurately.) Taking a NUMA node as an example, the task scheduling module With task buffer module Task execution module Connected. Task scheduling module. From the task buffer module Upon receiving ready extension tasks, a mapping scheme (referred to as a task mapping scheme) is formed from the cost of the ready extension tasks to the computation threads. The task mapping scheme and the ready extension tasks are then sent to the task execution module. .

[0157] Each task execution module executes in parallel. (The sentence is incomplete and ends abruptly.) Taking a NUMA node as an example. Task execution module. With graph partitioning module Vertex caching module Task scheduling module and task buffer module Connected. Task execution module. Load the co-purchase relationship schema diagram, and generate the matching order and execution plan for the co-purchase relationship schema diagram. (Task Execution Module) From the task scheduling module Receive the task mapping scheme and ready extension tasks, and execute the ready extension tasks. If embedded instances are obtained after the ready extension tasks are completed, calculate the co-purchase frequency of the embedded instances based on the co-purchase frequency model, and update the set of embedded instances with higher frequencies; otherwise, proceed from the graph partitioning module. Receive the vertex neighbor list and neighbor group from the vertex cache module. Receive the vertex neighbor list and partition it according to the graph partitioning module. The received vertex neighbor list, neighbor group, and information from the vertex cache module. The received vertex neighbor list generates a cost-balanced intermediate extension task, which is then sent to the task buffer module. .like Once all ready extension tasks in the task execution module have been completed and no new intermediate extension tasks have been generated, the co-purchase combination recommendation result will be output to the user.

[0158] Each vertex request module executes in parallel. (The sentence is incomplete and requires more context to translate accurately.) The and the first Taking the nth NUMA node as an example, located at the nth Vertex request module for each NUMA node With task buffer module Vertex caching module and located in the Vertex response module of NUMA node Connected. Vertex Request Module From the task buffer module Obtain the vertex set (i.e., the task buffer module) The intermediate extension tasks required by it, but not stored in the graph partitioning module. and vertex cache module The set of vertices), packaged according to the NUMA node number of the vertex, will contain the vertex located at the NUMA node number. The set of vertices on each NUMA node is sent to the vertex response module. Then from the vertex response module Receive the vertex neighbor list and send it to the task buffer module. If the vertex neighbor list meets the caching criteria, it is sent to the vertex cache module. .

[0159] Each vertex response module executes in parallel. (The sentence is incomplete and requires more context to translate accurately.) The and the first Taking the nth NUMA node as an example, located at the nth Vertex response module of NUMA node With graph partitioning module Located in the first Vertex request module for each NUMA node Connected. Vertex Response Module From the vertex request module Receive vertex set from graph partitioning module Receive the vertex neighbor list, and select the neighbor list of vertices in the vertex set from the received vertex neighbor list to send to the vertex request module. .

[0160] Each vertex cache module executes in parallel. (The sentence is incomplete and requires more context to translate accurately.) Taking a NUMA node as an example, the vertex cache module With the task execution module Vertex Request Module Connected. Vertex cache module From the vertex request module Receive the list of vertex neighbors that need to be cached, store it locally, and then execute the task module. The required list of vertex neighbors is sent to the task execution module. .

[0161] The second step is to construct a data diagram and a schema diagram of the co-purchase relationship. The method is as follows: (2.1) Construct a co-purchase relationship data graph, the method is as follows: The Amazon co-purchasing network dataset (see "J. Leskovec, L. Adamic and B. Adamic. The Dynamics of Viral Marketing. ACM Transactions on the Web (ACMTWEB), 1(1), 2007") was used as the co-purchasing relationship data graph. This dataset contains purchase network data from the Amazon e-commerce platform on March 2nd, March 12th, May 5th, and June 1st, 2003. Vertices in the graph represent products; if there is an edge between two vertices, it means that customers simultaneously purchased the products corresponding to those two vertices. Edge labels were randomly constructed for all edges in the data graph. These edge labels simulated the frequency of co-purchasing relationships between the products represented by the two vertices connected to the edge. The co-purchasing relationship data graph is denoted as... ,in, For the set of vertices in the co-purchase relationship data graph, Let the set of edges be the data graph of co-purchase relationships. The number of vertices is denoted as .

[0162] (2.2) This invention aims to find recommended product combinations with co-purchase relationships. Similar to constructing a co-purchase relationship data graph, products are abstracted as vertices, and co-purchase relationships are abstracted as edges to construct a co-purchase relationship pattern graph. Taking a combination recommendation of 3 products as an example, if there are co-purchase relationships between product 1 and product 2, product 2 and product 3, and product 1 and product 3, then these three products can be recommended to the user as a combination set. Based on this idea, this invention prioritizes the existence of a co-purchase relationship between any two products in the product combination recommendation, that is, there is an edge between any two vertices in the graph, thereby constructing a group-type co-purchase relationship pattern graph. A group refers to a graph structure where any two vertices are interconnected. In addition, to increase the types of co-purchase combination recommendations, the condition of "there is an edge between any two points" can be appropriately relaxed, thereby constructing a pseudo-group-type co-purchase relationship pattern graph. A pseudo-group is a dense graph structure where the internal vertices are "approximately fully connected". Figure 4 As shown, A group of 3 indicates that there is a pairwise co-purchase relationship between the three products. Based on the matching results of this co-purchase relationship pattern diagram, a recommended "three-piece set" combination can be derived. A group of 4 indicates that there is a co-purchase relationship among the four products. Group 4 indicates that there are two co-purchase relationships between the four products, based on... Co-purchase relationship model diagram and The matching results of the co-purchase relationship diagram can all yield a recommended "four-piece set" combination. Let the co-purchase relationship diagram be denoted as... ,in, yes The set of vertices, yes The set of edges, The number of vertices is denoted as .

[0163] The third step involves the graph partitioning modules on each NUMA node executing in parallel. To avoid additional data transfer, each graph partitioning module simultaneously loads the co-purchase relationship data graph. ,right The graph is partitioned into light and heavy vertices, and one partition from the light vertex partition and one partition from the heavy vertex partition are stored in local memory. Light vertices are accessed less frequently, so a cost model is built to estimate the cost of each vertex. Based on this cost model, the graph is partitioned horizontally. The light vertices in the middle are divided into Each subset contains vertices and their neighbors, forming a graph partition, thus yielding... A cost-balanced graph partition is created, with one partition stored in local memory to achieve load balancing. Since duplicate vertices are accessed more frequently, each computer node stores a complete list of vertex neighbors to avoid frequent communication. Simultaneously, to save memory space, [the following is omitted as the original text is incomplete and likely refers to further details about memory allocation]. Vertical partitioning is performed on the multiple vertices in the array, that is, the neighbor list of each multiple vertex is divided into... Each NUMA node stores a set of three equally sized and disjoint neighbor subsets, and a subset of the neighbor list after vertical partitioning is stored by the graph partitioning module located on the same computer node. The graph partitioning module on each NUMA node executes the same process, with the one located on the 1st node... Graph partitioning module on each NUMA node ( )right The method for partitioning a graph using light and heavy vertices is as follows: (3.1) Graph Partitioning Module Read the co-purchase relationship data graph ,statistics middle The degree of each vertex, The maximum degree among the degrees of the vertices and By obtaining key information such as the two-hop degree of each vertex, we obtain the vertex degree array. Vertex 2-hop degree array , The Middle vertices second hop degree refer to The sum of the degrees of the neighboring vertices. The method is: (3.1.1) Graph Partitioning Module Read And statistics The degree of each vertex is stored in a vertex degree array. , The CCP There are elements, among which correspond The degree.

[0164] (3.1.2) Traversal of Each element, obtain Maximum degree in and obtain middle Average degree of each element .

[0165] (3.1.3) Graph Partitioning Module statistics middle The two-hop degree of each vertex is stored in a vertex two-hop degree array. And calculate the total cost. The method is: (3.1.3.1) Let .

[0166] (3.1.3.2) Let the vertex index .

[0167] (3.1.3.3) vertices second hop Initialize to 0.

[0168] (3.1.3.4) Graph Partitioning Module from Reading Vertex neighbor vertex set Find the vertex according to formula (1) second hop degree ,Will Put into the vertex two-hop degree array middle.

[0169] , formula (1); For the set of neighboring vertices Mid-vertex The degree.

[0170] (3.1.3.5) Order ,in, It is the vertex The cost is calculated according to formulas (2) to (3).

[0171] , formula (2); , formula (3); (3.1.3.6) Order ,like , see (3.1.3.3), if , turn to (3.2).

[0172] (3.2) Let the degree threshold ,in As this is an adjustable parameter, it is set to 0.5 in this embodiment. Medium degree less than The vertex that is not a light vertex is called a light vertex, and the remaining vertices are called heavy vertices. There is A light vertex, A single vertex .

[0173] (3.3) Graph Partitioning Module in accordance with and right middle Light vertices are horizontally partitioned. To ensure a relatively balanced load across NUMA nodes, a cost model is constructed to estimate the computational cost of each graph partition, dividing the light vertices into... A cost equilibrium diagram partition . It is the first Each graph partition can be formally represented as a pair of tuples. , , The meaning of this pair is the first... Individual map partitions Including vertex index The light vertex. Formula (4) is the cost model used to calculate Cost .

[0174] , formula (4); For ease of description, of Value and The values ​​are respectively denoted as and The method for horizontal partitioning is: (3.3.1) Let the vertex index .

[0175] (3.3.2) Let the partition index .

[0176] (3.3.3) Let .

[0177] (3.3.4) Calculate the mean cost of the partition , .

[0178] (3.3.5) Let the first Cost per partition .

[0179] (3.3.6) If This indicates the current vertex. If it is a light vertex, proceed to (3.3.7); otherwise, indicate that the current vertex... It is a heavy vertex, does not participate in horizontal partitioning, and does not need to be partitioned. Cost join in , directly transfer to (3.3.8).

[0180] (3.3.7) Let .

[0181] (3.3.8) Order ,if That is, the first If the cost of a partition is less than the average cost of the partitions, vertices need to be added, go to (3.3.6); otherwise, it means that the cost of the partitions has reached the average, and no vertices need to be added, go to (3.3.9).

[0182] (3.3.9) Order .

[0183] (3.3.10) Let the partition index ,like , see (3.3.3); if This indicates that the partitioning is complete and the graph partitioning results for light vertices are obtained. Proceed to (3.4).

[0184] (3.4) Graph Partitioning Module Read And collect the first Individual map partitions The list of neighbors of the middle vertex is stored in local memory.

[0185] (3.5) Graph Partitioning Module Will In The set of multiple vertices is denoted as the set of multiple vertices. , , It is the first A single vertex Because heavy vertices are accessed more frequently, to avoid frequent communication and save memory space, [the following is omitted as the text is incomplete and cannot be translated]. Perform vertical partitioning, dividing the neighbor list of each heavy vertex into... A set of equally sized and disjoint neighbor subsets, graph partitioning module. Storage number A subset is selected such that each computer node stores a copy of the heavy vertices. The method for vertical partitioning is: (3.5.1) Let the index of the multiple vertices be... .

[0186] (3.5.2) Read Find the neighboring vertices and obtain the neighbor list. .

[0187] (3.5.3) will Divided into A set of neighboring subsets that are of equal size and do not overlap.

[0188] (3.5.4) Graph Partitioning Module Storage number A subset of neighbors.

[0189] (3.5.5) Order ,like Go to (3.5.2); otherwise, for middle After processing all heavy vertices, the partitioning and storage of heavy vertices are completed. Proceed to (3.6).

[0190] (3.6) Graph Partitioning Module Send the locally stored list of neighbors for light and heavy vertices to the task generation module. and task execution module .

[0191] Fourthly, since the degree of the graph follows a power-law distribution, the cost of expanding tasks involving multiple vertices is high. Therefore, the graph partitioning modules of each NUMA node are executed in parallel. In The neighbor lists of each heavy vertex are divided into cost-balanced neighbor groups and vertex-balanced neighbor groups based on cost and number of vertices, respectively. These are used to generate the cost-balanced task in the subsequent sixth step, enabling finer-grained task parallelism and load balancing. (The last sentence appears to be incomplete and possibly refers to a different topic.) Graph partitioning module on each NUMA node For example, The method is: (4.1) Graph Partitioning Module right In The neighbor list of each heavy vertex is divided according to cost. A cost-equilibrium neighbor group is obtained. The cost-equilibrium neighbor group of all heavy vertices will be the first Each vertex The A cost-equilibrium neighbor group is denoted as , The resulting cost-balanced neighbor groups are used in the subsequent fifth step to decompose the computationally intensive single-vertex extension tasks, achieving fine-grained task parallelism and load balancing. The method is as follows: (4.1.1) Let the index of the multiple vertices be... .

[0192] (4.1.2) will The Middle Each vertex The neighbor list is recorded as , , ,for The number of vertices in the middle. Calculate. The estimated cost of each vertex in the middle, of which Estimated cost Calculate according to formula (5), and The estimated cost of each vertex is temporarily stored in the cost array. ,right middle The costs are summed up to obtain the total cost. .

[0193] , formula (5); (4.1.3) Calculate the first using formula (6). Each vertex The Neighborhood group Cost : , formula (6); (4.1.4) Based on Will The neighbor list is divided into A cost-equilibrium neighbor group. For ease of description, the first... A group of neighbors is denoted as a binary group. ,express The Each neighbor group contains a list of neighbors. The middle index belongs to the range The vertices inside will In , They are respectively denoted as and .Will The method for dividing the neighbor list into neighbor groups is: (4.1.4.1) Let the neighbor vertex index .

[0194] (4.1.4.2) Let the neighbor group index .

[0195] (4.1.4.3) Let .

[0196] (4.1.4.4) Graph Partitioning Module Calculate the mean cost of the neighbor group , .

[0197] (4.1.4.5) Cost of new neighbor groups .

[0198] (4.1.4.6) Let .

[0199] (4.1.4.7) Let .if , then proceed to (4.1.4.6); otherwise, proceed to the next step. Neighborhood group The cost exceeds the average cost of the neighboring group, see (4.1.4.8).

[0200] (4.1.4.8) Order .

[0201] (4.1.4.9) Order ,like If yes, then proceed to (4.1.4.3); otherwise, repeat the vertex. The neighbor list has been divided into 1 neighbor group, get The cost-equilibrium neighbor group, see (4.1.5).

[0202] (4.1.5) Order ,like Go to (4.1.2), otherwise, The neighbor list of all heavy vertices has been partitioned into The neighbor group received The cost-equilibrium neighbor group of all heavy vertices is determined, see (4.2).

[0203] (4.2) Graph Partitioning Module right In Each vertex The neighbor list is divided into several vertex-balanced neighbor groups based on the number of vertices. Among them, the first... vertices Neighbor list Divided into The neighbor group of the th vertex is balanced, except for the th vertex. In addition to the one neighbor group, all other neighbor groups include One vertex, The resulting balanced neighbor groups are used in the subsequent sixth step to decompose the computationally intensive intermediate extension tasks, achieving fine-grained task parallelism and load balancing. The partitioning method is as follows: (4.2.1) Let the threshold parameter for the number of vertices in the neighbor group be... .

[0204] (4.2.2) Let .

[0205] (4.2.3) will The first in Each vertex neighbor vertex set The number of vertices is of The last neighbor group is the _th neighbor group, and the last neighbor group is the _th neighbor group. The number of vertices in a neighboring group can be ,in, The Middle Each vertex The A balanced neighbor group of vertices is denoted as , .

[0206] (4.2.4) Let ,like Go to (4.2.3), otherwise, the neighbor lists of all heavy vertices have been divided into neighbor groups with balanced vertices, go to (4.3).

[0207] (4.3) Graph Partitioning Module Will middle The cost-balanced neighbor groups and vertex-balanced neighbor groups of each heavy vertex are sent to the task generation module. and task execution module .

[0208] Fifth, the task buffer modules of each NUMA node execute in parallel, the vertex request modules of each NUMA node execute in parallel, and the task execution modules of each NUMA node execute in parallel to initialize the task ready queue. Task cache area Vertex request queue and embedded instance collection (i.e., combined recommendation results). The task execution module calculates... Matching order and the corresponding execution plan With the first Taking a NUMA node as an example The method is: (5.1) Task buffer module Initialize a task ready queue and a task cache .

[0209] (5.2) Vertex Request Module initialization The vertex request queue, where the first vertex... The vertex request queue is denoted as .

[0210] (5.3) Task Execution Module Initialize a collection of embedded instances , used to record the indivual Recommended co-purchase packages at the node.

[0211] (5.4) Task Execution Module Loading co-purchase relationship diagram ,calculate Matching order and the corresponding execution plan The method is: (5.4.1) Selection The vertex with the highest degree As and Matching order The first vertex in, followed by the next vertex in Choose from the remaining vertices in the middle. The vertex with the most adjacent vertices is selected as the next vertex in the matching order. Matching order , , , yes An ordered set of vertices. yes The number of vertices, It is the first in the matching order One vertex.

[0212] (5.4.2) Based on Calculate the corresponding execution plan ,in, , No. A set of vertices yes Central Previous vertex set Zhongyu A set of connected vertices. (This is achieved through calculation.) The intersection of the neighbor lists of the vertices mapped to the co-purchase relationship data graph in the graph can be used to obtain the matching order of the vertices. A candidate set of vertices.

[0213] Step 6: Utilizing the cost-balanced neighbor groups and vertex-balanced neighbor groups formed in step (4.3), the task generation module, vertex request module, vertex response module, task buffer module, task scheduling module, and task execution module cooperate to use a distributed pattern graph matching algorithm in parallel. Perform pattern matching to obtain Diagram of the relationship between China and co-purchasing Homogeneous embedded instances with high frequency of co-purchase represent the product set of each embedded instance's vertex set as the combined recommendation result. The task generation module and task buffer module cooperate to process the data according to the procedure in (6.1). In the matching order, the first vertex is matched to One vertex is used to generate a cost-balanced single-vertex extension task; at the same time, the vertex request module and the vertex response module cooperate with each other and execute according to the process in (6.2), obtaining the vertex neighbor list required for task execution through communication; at the same time, the task buffer module, the task scheduling module and the task execution module cooperate with each other and continuously execute the single-vertex extension task according to the process in (6.3), generating intermediate extension tasks or embedded instances, and selecting several embedded instances with higher frequency of co-purchase to store. Execute intermediate extension tasks, repeating this process until no more intermediate extension tasks are generated, ultimately yielding a result containing the combined recommendation results. Extend the task Represented as a quadruple, , express exist Partial embedding on; Represents a set of vertices. The vertices in the diagram are matched vertices connected to the vertex to be expanded (i.e., the vertex to be expanded is partially embedded). (neighboring vertices in the data). express The neighbor list or neighbor group of the middle vertex can be calculated. We obtain the intersection of the neighbor lists of the mid-vertex. The candidate set of the next vertex to be expanded (i.e., the set of vertices that the vertex to be expanded can match in the vertices of the co-purchase relationship data graph). Indicate execution The cost. The method is: (6.1) The task generation modules of each NUMA node work in parallel to generate cost-balanced single-vertex extension tasks and send them to the local task buffer module. After all local single-vertex extension tasks have been generated, the vertex set is stolen from the graph partitioning module of the remote NUMA node to generate the stolen single-vertex extension task. (The sentence is incomplete and ends abruptly.) Taking a NUMA node as an example Task generation module Based on graph partitioning module The obtained vertex neighbor list and neighbor groups generate a cost-balanced single-vertex expansion task, which is then sent to the task buffer module. When the first After all single-vertex tasks on each NUMA node have been generated, to achieve dynamic load balancing, this invention employs a task-stealing mechanism, selecting a suitable NUMA node based on a priority order: local computer node first, then remote computer node. ( ), from the graph partitioning module Steal a set of vertices from the dataset and generate a single-vertex extension task from the stolen vertex. The method is as follows: (6.1.1) Since the degree of a heavy vertex is large, generating a single-vertex extension task for each heavy vertex would be computationally expensive. Therefore, this invention utilizes the cost-balanced neighbor group generated in step four to generate a single-vertex extension task for each heavy vertex. A cost-balanced, single-vertex scaling task. Based on the task generation module. For example, let the task generation module Located in the The first computer node Each NUMA node, at this time , ,1 .for In Each key vertex, task generation module For each heavy vertex, a low-cost single-vertex extension task is generated based on a group of its neighbors. The method is as follows: (6.1.1.1) Let .

[0214] (6.1.1.2) Task Generation Module generate The first in Each vertex Single-vertex extension task . Re-vertices Match to Matching order The first vertex in Therefore exist Partial embedding on The neighbors of the vertex to be expanded are only multiple vertices. Therefore To reduce the amount of computation, Only for The expansion will be carried out on some of the neighbors, therefore, we choose... A neighbor group As , yes The index of the cost-balanced neighbor group. The neighbor list is divided into in step (3.5) Each partition, graph partition module Storage number Each partition, simultaneously. The neighbor list is divided in step (4.1) The neighbor group can be approximated as the th neighbor group. The partition contains the first To the Each neighboring group, therefore , making Calculate the neighbor set of the candidate set It is stored in the memory of the local NUMA node, thereby reducing access across NUMA nodes and lowering memory access latency. It is based on the neighbor group The computational cost of extending the current embedding is therefore... Substituting into formula (6) to calculate... ,make .

[0215] (6.1.1.3) Task Generation Module Will Send to task buffer module .

[0216] (6.1.1.4) Task Buffer Module Will Store in the task ready queue If it is already full, then , This embodiment represents the maximum capacity of the task ready queue. Proceed to (6.1.1.4), and wait for a time interval. ,like If not yet complete, proceed to (6.1.1.5).

[0217] (6.1.1.5) Order ,like If yes, proceed to (6.1.1.2); otherwise, it indicates that a single-vertex extension task has been generated for all vertices, proceed to (6.1.2).

[0218] (6.1.2) The task generation modules execute in parallel. (The sentence is incomplete and ends abruptly.) Task generation module on each NUMA node For example Task generation module From the graph partitioning module Get The task involves generating a list of neighbors for each light vertex and then extending that list to a single vertex. Each light vertex is denoted as , The method is: (6.1.2.1) Task Generation Module Initialize the index of the local partition light vertices, let .

[0219] (6.1.2.2) Task Generation Module Initialization by the first Single-vertex extended task generated by a light vertex . Light vertex Match to Matching order The first vertex in Therefore, partial embedding Light vertex It is a vertex connected to the vertex to be expanded, therefore ; The neighbor list of the middle vertex is Therefore ; It is to light vertex The cost of extending to full embedding, i.e. The cost, therefore Substituting into formula (2) to calculate... ,make .

[0220] (6.1.2.3) Task Generation Module Will Send to task buffer module .

[0221] (6.1.2.4) Task Buffer Module Will Store in the ready queue If the process is full, proceed to (6.1.2.4) and wait for a time interval. ;like Not yet, proceed to (6.1.2.5).

[0222] (6.1.2.5) Task Generation Module make ,like Proceed to (6.1.2.2); otherwise, proceed to the graph partitioning module. All light vertices in the array have been used to generate single-vertex extension tasks, see (6.1.3).

[0223] (6.1.3) To achieve dynamic load balancing, storage in the remote graph partitioning module is dynamically stolen based on cost. The set of vertices in the , . Values ​​are retrieved according to the following strategy: First, the remote NUMA nodes on the local computer node are searched, then the NUMA nodes on the remote computer node are searched. (i.e., the diagram partitioning module) The task generation module (not all light vertices on the module have been generated yet) is a single-vertex scalable embedding module. Task generation module From the graph partitioning module Obtain several vertices such that the sum of the costs of these vertices approaches the cost threshold. , The set of vertices in this group is denoted as the stolen vertex set. ,Will The Middle Each vertex is denoted as , .like Number of mid vertices Task generation module If the operation is complete, proceed to (6.4); otherwise, proceed to (6.1.4).

[0224] (6.1.4) Task Generation Module Stealing vertex set To generate a single-vertex extended task, the method is as follows: (6.1.4.1) Let the vertex index .

[0225] (6.1.4.2) Initialize the stealing task ,in ,Will Substituting into formula (2) to calculate... ,make .

[0226] (6.1.4.3) If the task buffer in the task buffer module If full, proceed to (6.1.4.3) and wait for a time interval. Otherwise, proceed to (6.1.4.4).

[0227] (6.1.4.4) The task Add to task buffer , will the vertex The request queue is placed in the vertex request module. middle.

[0228] (6.1.4.5) ,like Go to (6.1.4.2); otherwise, it indicates that the vertex set has been stolen. All vertices in the array have been generated as single-vertex scalable embeddings, see (6.1.5).

[0229] (6.1.5) Order ,like This indicates that there are still stealable graph partitioning modules. If yes, proceed to (6.1.3); otherwise, explain. The light vertices of the graph partitioning module have all been generated as single-vertex scalable embeddings, and the task generation module... Once completed, proceed to (6.4).

[0230] (6.2) The vertex request module, vertex response module, task buffer module, and vertex cache module of each NUMA node cooperate to obtain and store the list of vertex neighbors required for task execution in parallel. The vertex request module... Vertex Response Module Task buffer module and vertex cache module For example, , The method is: (6.2.1) If the vertex request module The first in Request queues The vertex request module is filled. Vertex Response Module send Set the vertex set in the data and clear it. .

[0231] (6.2.2) Vertex Response Module Receive Vertex Request Module The set of vertices sent from the graph partitioning module The vertex request module retrieves a list of vertex neighbors from the vertex set. .

[0232] (6.2.3) Vertex Request Module Receive vertex response module Send the vertex neighbor list, and then send the vertex neighbor list to the task buffer module. and vertex cache module Task buffer module and vertex cache module Store the list of vertex neighbors.

[0233] (6.2.4) If the task execution module No more intermediate extension tasks are generated; vertex request module and vertex response module If execution is complete, proceed to (6.4); otherwise, proceed to (6.2.1).

[0234] (6.3) The task buffer module, task scheduling module and task execution module of each NUMA node cooperate with each other to execute tasks in parallel, generate new intermediate extended tasks, and repeat this process until the co-purchase relationship data graph is obtained. Diagram of the relationship between China and co-purchasing All isomorphic embedded instances, and continuously update the set of embedded instances. . It is the frequency of co-purchase. A large set of embedded instances, where the set of products represented by each vertex of an embedded instance constitutes a co-purchase combination recommendation result. Wherein... The task buffer module, task scheduling module, and task execution module of each NUMA node cooperate to execute tasks in parallel, generate new intermediate extended tasks, and continuously update the embedded instance set Recommend using the following method: (6.3.1) Task Buffer Module Waiting for the module to be requested from the vertex Receive the vertex neighbor list and complete the task data. The method is as follows: (6.3.1.1) If the task buffer module No request received from the vertex module Send the vertex neighbor list, go to (6.3.1.1), and wait for a time interval. , If a request is received from the vertex request module If the list of vertex neighbors is sent, then proceed to (6.3.1.2).

[0235] (6.3.1.2) Task Buffer Module The task list corresponding to the received vertex neighbor list is denoted as The total number of tasks , of which Each task is recorded as , task sequence number .

[0236] (6.3.1.3) Find the vertex neighbor list from the received vertex neighbor list The required list of vertex neighbors is assigned to The third item in the list.

[0237] (6.3.1.4) will From the task buffer Delete it.

[0238] (6.3.1.5) If the task ready queue If full, proceed to (6.3.1.5) and wait for a time interval. Otherwise, the task ready queue Not yet, proceed to (6.3.1.6).

[0239] (6.3.1.6) The task Add to ready queue area .

[0240] (6.3.1.7) Order ,like Proceed to (6.3.1.3); otherwise, the task buffer module... All extended tasks corresponding to the vertex neighbor list have been prepared. The ready extended tasks corresponding to the vertex neighbor list are obtained. Proceed to (6.3.2).

[0241] (6.3.2) Task Scheduling Module Receive from the task buffer module The ready-to-expand tasks form a task mapping scheme, the method being: (6.3.2.1) Task Execution Module Open One worker thread, It is a positive integer.

[0242] (6.3.2.2) Task Execution Module ready queue When the task list is full, a pop-up will appear. And send it to the task scheduling module. .

[0243] (6.3.2.3) Task Scheduling Module Based on cost Average score A cost-equilibrium task group, of which the first... Group tasks are denoted as binary groups. , indicating the first Group tasks include a task list The task sequence number is located in The task. For ease of description, In and They are respectively denoted as and The method is: (6.3.2.3.1) Let Number of tasks , of which Each task is recorded as Calculation task list The sum of the costs of the tasks is denoted as . .

[0244] (6.3.2.3.2) Let the task group index Task Index .

[0245] (6.3.2.3.3) Order .

[0246] (6.3.2.3.4) Calculate the average cost of the task group , that is to say .

[0247] (6.3.2.3.5) Command the task group Cost .

[0248] (6.3.2.3.6) Order ,in yes The estimated cost equals The fourth item.

[0249] (6.3.2.3.7) Order .if Task group If the cost is less than the average cost of the task group, it means that the current cost of the task group is insufficient and a task needs to be added. Proceed to (6.3.2.3.6); otherwise, it means that the cost of the task group has reached the average and no task needs to be added. Proceed to (6.3.2.3.8).

[0250] (6.3.2.3.8) Order .

[0251] (6.3.2.3.9) Order ,like If the task groups are divided and cost-equilibrium task groups are obtained, proceed to (6.3.2.3.3); otherwise, if the task groups are divided and cost-equilibrium task groups are obtained, proceed to (6.3.2.4).

[0252] (6.3.2.4) The generated by (6.3.2.3) A cost-equilibrium task group is randomly assigned to Each thread obtains a task mapping scheme, and then combines the task mapping scheme with... A cost-balanced task group is sent to the task execution module. .

[0253] (6.3.3) Task Execution Module Receive from the task scheduling module Task mapping scheme and A cost-equilibrium task group is assigned to a task group according to the task mapping scheme. One thread.

[0254] (6.3.4) Task Execution Module middle Threads execute in parallel Tasks in a cost-balanced task group. Among them, the first... The assigned thread executes the first... Task groups If the task expands the matching order The last vertex in the extended task (partial embedding) Include If there are vertices, then the final matching result is obtained through calculation and updated. Otherwise, an intermediate extension task will be generated. Send intermediate extended tasks to the task buffer module. If an intermediate extension task If all four entries have been assigned values, the intermediate extension task is ready; otherwise, the intermediate extension task is not ready. Task Buffer Module Store ready intermediate extension tasks into the task ready queue. Store unread intermediate extended tasks in the task buffer. Recommended combinations Storage co-purchase frequency value The highest front An embedding, This refers to embedding elements in the co-purchase relationship data graph that are isomorphic to the co-purchase relationship pattern graph and have a high co-purchase frequency value. The method is: (6.3.4.1) Let the task index Z= .

[0255] (6.3.4.2) For the first Task groups The first in Task Through calculation The intersection of the vertex neighbor lists in the array is used to obtain the vertices to be expanded. (i.e., matching order) The first in Candidate set of vertices , express The number of partially embedded vertices.

[0256] (6.3.4.3) The candidate sets are respectively Vertex in Match to the vertex to be expanded If the task expands the matching order The last vertex (i.e.) If so, the embedded instance is obtained directly, and then updated. Otherwise, generate a new intermediate scalable task set. This is possible within the graph partitioning module. Or vertex cache module If the list of vertex neighbors required for all extended tasks is obtained, a ready intermediate scalable task is generated; otherwise, a not-ready intermediate scalable task is generated. The method is as follows: (6.3.4.3.1) Calculate the first entry of the intermediate scalable task, partially embedded. If it is the last expansion (i.e. , express (the number of vertices), then the result is For embedded instances, the calculation is performed according to the co-purchase frequency model formulas (7) to (9). Co-purchase frequency value , for The set of edge labels, if There are co-purchase frequency values ​​lower than Embedded instance Then from Delete, join in Proceed to (6.3.4.5) to execute the next task; otherwise, proceed according to the execution plan. Obtain the vertex set of the intermediate scalable task , , then (6.3.4.3.2).

[0257] , formula (7); , formula (8); , formula (9); in, , For embedded instances The number of middle edges, For balancing parameters, .

[0258] (6.3.4.3.2) Let This leads to a new set of tasks that are not yet ready. The set of tasks ready .like In Excluding multiple vertices, go to (6.3.4.3.3); if It contains heavy vertices, see (6.3.4.3.6).

[0259] (6.3.4.3.3) Task Execution Module From the vertex cache module HeTu Partition Module Get from The set of neighbor lists of vertices in ,make If the vertex set Does it exist that are not stored in the graph partition module? With vertex cache module If the vertex is reached, proceed to (6.3.4.3.4); otherwise, All vertices in the graph are stored in the graph partitioning module. Or vertex cache module In the middle, turn (6.3.4.3.5).

[0260] (6.3.4.3.4) Task Execution Module Generate unread intermediate extension tasks , ,in, Only includes data stored in the graph partition module With vertex cache module Vertex neighbor list, cost Temporarily initialized to 0, stored in the remote graph partitioning module. Vertex neighbor list and cost This needs to be completed through subsequent steps (6.3.6). This will allow for the creation of a set of tasks that are not yet ready. (6.3.4.4)

[0261] (6.3.4.3.5) Calculate the cost of intermediate extension tasks according to formula (10). The cost is The sum of the cardinality of each set generates a ready intermediate extension task. , and the task Add to the ready extended task set, i.e., the set of tasks that are ready. (6.3.4.4)

[0262] , formula (10); in, Indicates task In .

[0263] (6.3.4.3.6) Task Execution Module From the vertex cache module HeTu Partition Module Get from The set of neighbor lists of light vertices in ,make If the vertex set There are light vertices that are not stored in the graph partitioning module. With vertex cache module In the middle, proceed to (6.3.4.3.7); otherwise, vertex set. All light vertices in the graph are stored in the graph partitioning module. or vertex cache module In the middle, turn (6.3.4.3.10).

[0264] (6.3.4.3.7) Task Execution Module From the graph partitioning module Get from Each heavy vertex in The vertex neighbor list, where and heavy vertex The neighbor list is recorded as , The number of intermediate vertices is denoted as Select the vertex with the largest degree and denote it as . Task execution module From the graph partitioning module China receives Vertex-balanced neighbor groups .

[0265] (6.3.4.3.8) Let the number of unread intermediate tasks be... The task execution module is based on the vertex with the highest degree of repetition. The vertex-balanced neighbor group splits the costly intermediate extension task into smaller parts, generating... An incomplete intermediate extension task, denoted as , order the The task is ,in , including neighbor groups of heavy vertices and stored in the graph partitioning module With vertex cache module Vertex neighbor list, cost Temporarily set to 0, stored in the remote graph partitioning module. Vertex neighbor list and cost It needs to be completed through subsequent steps (6.3.6).

[0266] (6.3.4.3.9) Order (6.3.4.4)

[0267] (6.3.4.3.10) Task Execution Module From the graph partitioning module Obtain each heavy vertex The vertex neighbor list, where and Its neighbor list is recorded as , The number of multiple vertices in the array is denoted as . Select the vertex with the largest degree and denote it as . From the graph partitioning module China receives Neighbor Group .

[0268] (6.3.4.3.11) Order Task execution module generates A ready intermediate extension task, denoted as , of which The task is ,in, , whereby by Substitute into formula (10) to calculate the estimated cost of the task. ,make .

[0269] (6.3.4.3.12) Order .

[0270] (6.3.4.4) Task Execution Module Send the newly generated intermediate extended task to the task buffer module. Task caching module Store ready intermediate scalable tasks and non-ready intermediate scalable tasks into the ready queue respectively. and task buffer The method is: (6.3.4.4.1) If the task buffer module Task ready queue Full, proceed to (6.3.4.4.1) and wait for a time interval. Otherwise, proceed to (6.3.4.4.2).

[0271] (6.3.4.4.2) The task Add to the task ready queue .

[0272] (6.3.4.4.3) If the task buffer module Task buffer Full, proceed to (6.3.4.4.3) and wait for a time interval. Otherwise, proceed to (6.3.4.4.4).

[0273] (6.3.4.4.4) The task Add to task buffer .

[0274] (6.3.4.5) Order ,like , No. Task groups If there are still unfinished tasks, proceed to (6.3.4.2); otherwise, proceed to step 1. Task groups Once all tasks have been completed, proceed to (6.3.5).

[0275] (6.3.5) If the task execution module If no further intermediate extension tasks are generated, proceed to (6.3.7); otherwise, proceed to (6.3.6).

[0276] (6.3.6) Task Buffer Module Prepare vertex neighbor list data for the unread intermediate extension tasks in the task buffer and calculate the cost of the tasks, thereby converting the unread intermediate extension tasks into ready intermediate extension tasks. The method is as follows: (6.3.6.1) Task Buffer Module Send the set of vertices in the task buffer that are missing neighbor lists to the vertex request module. The vertex request module groups the vertex set according to the NUMA nodes where the vertices are stored, dividing it into... The nth vertex subset will be the nth vertex subset. Add a subset of vertices to the request queue , .

[0277] (6.3.6.2) Task Buffer Module From the vertex request module Receive the required vertex neighbor list, find the vertex neighbor list required by the incomplete intermediate extension task from the required vertex neighbor list, and add it to the incomplete intermediate extension task. item.

[0278] (6.3.6.3) Task caching module Calculate the cost of each task according to formula (10) and add it to the unread intermediate extension tasks. This allows an unread intermediate extension task to become a ready intermediate extension task.

[0279] (6.3.6.4) If the task buffer module Task ready queue Full, proceeding to (6.3.6.4), waiting for a time interval. Otherwise, proceed to (6.3.6.5).

[0280] (6.3.6.5) Task caching module Remove ready intermediate extended tasks from the task buffer. Delete and add to the task ready queue. , see (6.3.1).

[0281] (6.3.7) Task Execution Module Output Embedded instances represent co-purchase relationship data graphs. Diagram of the relationship between China and co-purchasing Isomorphic subgraphs. Embedded instances. A larger value indicates that the co-purchase relationship between embedded instances occurs more frequently. The set of products represented by the vertex of each embedded instance is a co-purchase combination recommendation result, see (6.4).

[0282] (6.4) End.

[0283] To verify the effectiveness of the present invention, the Amazon platform co-purchasing relationship network constructed in step 2.1 was selected as the co-purchasing relationship data graph, including purchase network data from the Amazon e-commerce platform on March 2, March 12, May 5, and June 1, 2003. Figure 4 shown , , As a co-purchase relationship pattern diagram, runtime comparisons were made. The experiment was conducted on a distributed cluster with four computer nodes, using Ubuntu 20.04 (a version of Linux). Each computer node contained eight NUMA nodes, two 32-core x86 728H 2.5GHz processors, and 256GB of memory. The combination of the aforementioned co-purchase relationship data diagram and co-purchase relationship pattern diagram was input into the distributed co-purchase recommendation and matching system of this invention. , , The matching process was performed, and the system response time (in milliseconds) was statistically analyzed. This represents the time required from when a user inputs a recommendation request (i.e., a co-purchase relationship pattern graph) to when the system returns a recommendation result within an e-commerce platform (given a co-purchase relationship data graph). The response time of this invention was compared with that of existing distributed graph pattern matching systems G-thinker and Khuzdul to measure the real-time efficiency of this invention for combined recommendations on e-commerce platforms. Experimental results are shown in Table 1. It can be seen that the response time of this invention is shorter than that of G-thinker and Khuzdul in most cases, thus verifying that this invention can improve matching speed to a certain extent. Furthermore, this invention achieves accurate recommendations by constructing a group-based co-purchase relationship pattern graph; and by constructing a relaxed pseudo-group-based co-purchase relationship pattern graph, it expands the range of products that can be combined for recommendations, achieving diversified recommendations and providing technical support for efficient and rapid recommendations on large e-commerce platforms.

[0284] Table 1:

Claims

1. A distributed co-purchasing recommendation method based on graph pattern matching, characterized in that... Includes the following steps: The first step is to build a distributed co-purchasing recommendation system based on graph pattern matching; A distributed group-buying recommendation system based on graph pattern matching is established on a graph pattern matching platform. On a cluster of computer nodes; the computer nodes adopt a NUMA architecture, and each computer node contains One NUMA node; , All are positive integers; the distributed co-purchasing recommendation system based on graph pattern matching contains a total of Each NUMA node is equipped with a graph partitioning module, a task generation module, a task buffer module, a task scheduling module, a task execution module, a vertex request module, a vertex response module, and a vertex cache module. Identical modules on each NUMA node execute in parallel. , The modules on each NUMA node are denoted as modules. and modules , , ; The second step is to construct a data diagram and a schema diagram of the co-purchase relationship. The method is to first construct the data diagram of the co-purchase relationship. , For the set of vertices in the co-purchase relationship data graph, Let the set of edges be the data graph of co-purchase relationships. The number of vertices is denoted as ; Next, abstract the products as vertices and the co-purchase relationship as edges to construct a co-purchase relationship pattern diagram. , yes The set of vertices, yes The set of edges, The number of vertices is denoted as ; The third step involves the graph partitioning module of each NUMA node simultaneously loading the co-purchase relationship data graph. Parallel pairs The graph is partitioned into light vertices and heavy vertices, and one partition from the light vertex partition and one partition from the heavy vertex partition are stored in local memory. Based on the cost model, horizontal partitioning will be used to divide... The light vertices in the middle are divided into Each subset contains vertices and their neighbor lists, forming a graph partition. Each computer node stores a complete list of vertex neighbors, with each node having a cost-balanced graph partition and storing one of these partitions in local memory. Vertical partitioning is performed on the multiple vertices in the array, that is, the neighbor list of each multiple vertex is divided into... A set of neighbor subsets of equal size and disjointness, each stored in a neighbor list subset after vertical partitioning by a graph partitioning module located on the same computer node; The execution process of the graph partitioning module is the same for each NUMA node, located at the . Graph partitioning module on each NUMA node right The method for partitioning a graph using light and heavy vertices is as follows: (3.1) Graph Partitioning Module Read ,statistics middle The degree of each vertex, The maximum degree among the degrees of the vertices and The two-hop degree of each vertex is used to obtain the vertex degree array. Vertex 2-hop degree array , In correspond The degree, refer to The sum of the degrees of the neighboring vertices; (3.2) Let the degree threshold ,in It is an adjustable parameter. ,Will Medium degree less than The vertex that is not a light vertex is called a light vertex, and the remaining vertices are called heavy vertices. There is A light vertex, A single vertex ; (3.3) Graph Partitioning Module A cost model is constructed to estimate the computational cost of each map partition, based on... and right middle The light vertices are horizontally partitioned into groups. A cost equilibrium diagram partition , ; It is the first Each graph partition is a binary tuple. , , The meaning of a pair is Including vertex index The light vertex; (3.4) Graph Partitioning Module Read And collect the first Individual map partitions The list of neighbors of the middle vertex is stored in local memory; (3.5) Graph Partitioning Module Will In The set of multiple vertices is denoted as the set of multiple vertices. , , It is the first A single vertex ;right Perform vertical partitioning, dividing the neighbor list of each heavy vertex into... A set of equally sized and disjoint neighbor subsets, graph partitioning module. Storage number Each computer node stores a copy of the heavy vertex in a subset; (3.6) Graph Partitioning Module Send the locally stored list of neighbors for light and heavy vertices to the task generation module. and task execution module ; Fourth step, the graph partitioning modules of each NUMA node will run in parallel. In The neighbor lists of each heavy vertex are divided into cost-balanced neighbor groups and vertex-balanced neighbor groups according to cost and number of vertices, respectively. The graph partitioning module... The method is: (4.1) Graph Partitioning Module right In The neighbor list of each heavy vertex is divided according to cost. A cost-equilibrium neighbor group is obtained. The cost-equilibrium neighbor group of all heavy vertices will The A cost-equilibrium neighbor group is denoted as , ; (4.2) Graph Partitioning Module right In The neighbor list of each heavy vertex is divided into several vertex-balanced neighbor groups according to the number of vertices. middle The neighbor group of a vertex with multiple vertices is balanced. Neighbor list Divided into The neighbor group of the nth vertex is balanced. Number of vertices in each neighbor group The remaining neighbor groups all contain One vertex, ;Will The A balanced neighbor group of vertices is denoted as , ; (4.3) Graph Partitioning Module Will middle The cost-balanced neighbor groups and vertex-balanced neighbor groups of each heavy vertex are sent to the task generation module. and task execution module ; Fifth, the task buffer module, vertex request module, and task execution module of each NUMA node are executed in parallel to initialize the task ready queue. Task cache area Vertex request queue and embedded instance collection That is, the recommendation results are combined, and the execution modules of each task perform computation in parallel. Matching order and the corresponding execution plan , of which The methods for the task buffer module, vertex request module, and task execution module on each NUMA node are as follows: (5.1) Task buffer module Initialize a task ready queue and a task cache ; (5.2) Vertex Request Module initialization The vertex request queue, where the first vertex... The vertex request queue is denoted as ; (5.3) Task Execution Module Initialize a collection of embedded instances , used to record the indivual Recommended co-purchase packages at the node; (5.4) Task Execution Module Loading co-purchase relationship diagram ,calculate Matching order and the corresponding execution plan , , , yes An ordered set of vertices. yes The number of vertices, It is the first in the matching order One vertex; Task execution module based on Calculate the corresponding execution plan , ,in, , No. A set of vertices yes Central Previous vertex set Zhongyu A set of connected vertices; The sixth step involves utilizing cost-balanced neighbor groups and vertex-balanced neighbor groups. The task generation module, vertex request module, vertex response module, task buffer module, task scheduling module, and task execution module work together, employing a distributed pattern graph matching algorithm to perform parallel processing. Perform pattern matching to obtain Zhongyu Homogeneous embedded instances with high frequency of co-purchase, the set of products represented by the vertex set of each embedded instance is the combined recommendation result; among them, the task generation module and the task buffer module cooperate with each other to process according to the process in (6.1) In the matching order, the first vertex is matched to One vertex is used to generate a cost-balanced single-vertex extension task; at the same time, the vertex request module and the vertex response module cooperate with each other and execute according to the process in (6.2), obtaining the vertex neighbor list required for task execution through communication; at the same time, the task buffer module, the task scheduling module and the task execution module cooperate with each other and continuously execute the single-vertex extension task according to the process in (6.3), generating intermediate extension tasks or embedded instances, and selecting several embedded instances with higher frequency of co-purchase to store. Execute intermediate extension tasks, repeating this process until no more intermediate extension tasks are generated, ultimately yielding a result containing the combined recommendation results. Extend the task Represented as a quadruple, , express exist Partial embedding on, Represents a set of vertices. The vertices in the equation are matched vertices connected to the vertex to be expanded, meaning the vertex to be expanded is partially embedded. Neighboring vertices in express The neighbor list or neighbor group of the middle vertex is calculated. We obtain the intersection of the neighbor lists of the mid-vertex. The candidate set of the next vertex to be expanded. Indicate execution The cost; the method is: (6.1) The task generation modules of each NUMA node work in parallel to generate cost-balanced single-vertex extension tasks and send them to the local task buffer module. After all local single-vertex extension tasks have been generated, the vertex set is stolen from the graph partitioning module of the remote NUMA node to generate the stolen single-vertex extension tasks; among them, the task generation module Based on graph partitioning module The obtained vertex neighbor list and neighbor groups generate a cost-balanced single-vertex expansion task, which is then sent to the task buffer module. When the first After all single-vertex tasks on each NUMA node have been generated, a task-stealing mechanism is employed to select a suitable NUMA node based on the priority of local computer nodes first, followed by remote computer nodes. From the graph partitioning module Steal a set of vertices from the set and generate a single-vertex extension task from the stolen vertex. All light vertices of the graph partitioning module have been generated as single-vertex scalable embeddings, see (6.4). (6.2) The vertex request module, vertex response module, task buffer module and vertex cache module of each NUMA node cooperate with each other to obtain and store the vertex neighbor list required for task execution in parallel. If the task execution module no longer generates intermediate extended tasks, go to (6.4). (6.3) The task buffer module, task scheduling module and task execution module of each NUMA node cooperate with each other to execute tasks in parallel, generate new intermediate extended tasks, and repeat this process until the co-purchase relationship data graph is obtained. Diagram of the relationship between China and co-purchasing All isomorphic embedded instances, and continuously update the set of embedded instances. ; It is a set of embedded instances. The set of products represented by each embedded vertex is a co-purchase combination recommendation result, see (6.4). (6.4) End.

2. The distributed co-purchasing recommendation method based on graph pattern matching as described in claim 1, characterized in that... The , satisfy .

3. The distributed co-purchasing recommendation method based on graph pattern matching as described in claim 1, characterized in that... In the distributed co-purchasing recommendation system based on graph pattern matching described in the first step, the graph partitioning module... With the task generation module Task generation module Task execution module Vertex Response Module Connected; diagram partitioning module Horizontally partition the vertex set, that is, divide the light vertex set into... Each computer node stores a set of disjoint subsets and a list of neighbors for each vertex within that subset in its local memory; each computer node stores a complete list of vertex neighbors; graph partitioning module. Perform vertical partitioning on the multiple vertices, that is, divide the neighbor list of the multiple vertices evenly into... The graph partitioning module stores a set of disjoint subsets of nodes and its neighbor list in local memory, which is then shared with other NUMA nodes on the same computer node to store the neighbor list of the heavy vertices. The neighbor list of heavy vertices is divided into cost-balanced neighbor groups and vertex-balanced neighbor groups for generating cost-balanced tasks; Graph partitioning module Send the vertex neighbor list and neighbor group to the task generation module. and task execution module Send the vertex set to the task generation module. Send the vertex neighbor list to the vertex response module. ; No. Task generation module for each NUMA node With graph partitioning module Task buffer module and located in the Graph partitioning module with NUMA nodes Connected; Task Generation Module From the graph partitioning module Receive the vertex neighbor list and neighbor group, generate a cost-balanced single-vertex expansion task based on the vertex neighbor list and neighbor group, and send the single-vertex expansion task to the task buffer module. In the graph partitioning module After all vertices in the task are used to generate single-vertex extended tasks, the task generation module... From the graph partitioning module The system receives a vertex set, generates a cost-balanced single-vertex extension task based on the vertex set, and sends the single-vertex extension task to the task caching module. ; No. Task buffer module for each NUMA node and task generation module Task execution module Task scheduling module Vertex Request Module Connected; Task buffer module From the task generation module Receive single-vertex extended tasks from the task execution module. Receive intermediate extended tasks; Task buffer module Collect data from extended tasks that participate in set operations but are not stored in the graph partitioning module. and vertex cache module The vertex set is sent to the vertex request module. Request module from vertex Receive the vertex neighbor list of these vertices. Once the required vertex neighbor list is ready, convert the expansion task into a ready expansion task and send the ready expansion task to the task scheduling module. ; Task scheduling module With task buffer module Task execution module Connected; Task scheduling module From the task buffer module Upon receiving ready extension tasks, a mapping scheme from tasks to computation threads (i.e., a task mapping scheme) is formed based on the cost of the ready extension tasks. This task mapping scheme and the ready extension tasks are then sent to the task execution module. ; Task execution module With graph partitioning module Vertex caching module Task scheduling module and task buffer module Connected; Task execution module Load the co-purchase relationship schema diagram, generate the matching order and execution plan for the co-purchase relationship schema diagram; Task execution module. From the task scheduling module Receive the task mapping scheme and ready extension tasks, and execute the ready extension tasks; if embedded instances are obtained after the ready extension tasks are completed, calculate the co-purchase frequency of the embedded instances based on the co-purchase frequency model, and update the set of embedded instances with higher frequencies; otherwise, proceed from the graph partitioning module. Receive the vertex neighbor list and neighbor group from the vertex cache module. Receive the vertex neighbor list and partition it according to the graph partitioning module. The received vertex neighbor list, neighbor group, and information from the vertex cache module. The received vertex neighbor list generates a cost-balanced intermediate extension task, which is then sent to the task buffer module. ;like Once all ready extension tasks in each task execution module have been completed and no new intermediate extension tasks have been generated, the co-purchase combination recommendation result will be output to the user. Located in the Vertex request module for each NUMA node With task buffer module Vertex caching module and located in the Vertex response module of NUMA node Connected; Vertex Request Module From the task buffer module Get Task Buffer Module The intermediate extension tasks required by it, but not stored in the graph partitioning module. and vertex cache module The set of vertices is packaged according to the index of the NUMA node where the vertex is located, and the vertex located at the NUMA node is packaged. The set of vertices on each NUMA node is sent to the vertex response module. From the vertex response module Receive the vertex neighbor list and send it to the task buffer module. If the vertex neighbor list meets the caching criteria, it is sent to the vertex cache module. ; Located in the Vertex response module of NUMA node With graph partitioning module Located in the first Vertex request module for each NUMA node Connected; Vertex Response Module From the vertex request module Receive vertex set from graph partitioning module Receive the vertex neighbor list, and select the neighbor list of vertices in the vertex set from the received vertex neighbor list to send to the vertex request module. ; Vertex Cache Module With the task execution module Vertex Request Module Connected; Vertex cache module From the vertex request module Receive the list of vertex neighbors that need to be cached, store it locally, and then execute the task module. The required list of vertex neighbors is sent to the task execution module. .

4. The distributed co-purchasing recommendation method based on graph pattern matching as described in claim 1, characterized in that... The method for constructing the co-purchase relationship data graph and co-purchase relationship pattern graph in the second step is as follows: (2.1) Construct a co-purchase relationship data graph, the method is as follows: The Amazon co-purchasing network dataset is used as the co-purchasing relationship data graph; vertices in the graph represent products, and if there is an edge between two vertices, it means that there are customers who have purchased the products corresponding to these two vertices at the same time; edge labels are randomly constructed for all edges in the data graph, and the edge labels are used to simulate the frequency of co-purchasing relationships between the products represented by the two vertices connected to the edge; The co-purchase relationship data diagram is denoted as ; (2.2) Abstracting products as vertices and co-purchase relationships as edges to construct a co-purchase relationship pattern diagram: Prioritizing the expectation that any two products in the product combination recommendation have a co-purchase relationship, i.e., an edge exists between any two vertices in the graph, thus constructing a group-type co-purchase relationship pattern diagram. A group refers to a graph structure where any two vertices are interconnected. Appropriately relaxing the condition of "an edge exists between any two points," constructing a pseudo-group-type co-purchase relationship pattern diagram. A pseudo-group is a dense graph structure where internal vertices are "approximately fully connected." The co-purchase relationship pattern diagram is denoted as... .

5. The distributed co-purchasing recommendation method based on graph pattern matching as described in claim 1, characterized in that... Step (3.1) graph partitioning module statistics middle The degree of each vertex, The maximum degree among the degrees of the vertices and The method for calculating the two-hop degree of a vertex is: (3.1.1) Graph Partitioning Module Read And statistics The degree of each vertex is stored in a vertex degree array. , The CCP There are elements, among which correspond The degree; (3.1.2) Traversal of Each element, obtain Maximum degree in and obtain middle Average degree of each element ; (3.1.3) Graph Partitioning Module statistics middle The two-hop degree of each vertex is stored in a vertex two-hop degree array. And calculate the total cost. The method is: (3.1.3.1) Let ; (3.1.3.2) Let the vertex index ; (3.1.3.3) vertices second hop Initialize to 0; (3.1.3.4) Graph Partitioning Module from Reading Vertex neighbor vertex set Find the vertex according to formula (1) second hop degree ,Will Put into the vertex two-hop degree array middle; Formula (1); For the set of neighboring vertices Mid-vertex The degree; (3.1.3.5) Order ,in, It is the vertex The cost is calculated according to formulas (2) to (3); Formula (2); Formula (3); (3.1.3.6) Order ,like , see (3.1.3.3), if , turn to (3.2).

6. The distributed co-purchasing recommendation method based on graph pattern matching as described in claim 1, characterized in that... The cost model described in step (3.3) is shown in formula (4), and is used to calculate... Cost : , formula (4); ； ； middle The average degree of each element, of Value and The values ​​are respectively denoted as and ;Graph partitioning module in accordance with and right middle The method for horizontal partitioning of light vertices is: (3.3.1) Let the vertex index ; (3.3.2) Let the partition index ; (3.3.3) Let ; (3.3.4) Calculate the mean cost of the partition , ; (3.3.5) Let the first Cost per partition ; (3.3.6) If This indicates the current vertex. If it is a light vertex, proceed to (3.3.7); otherwise, indicate that the current vertex... It is a heavy vertex, does not participate in horizontal partitioning, and does not need to be partitioned. Cost join in Directly transfer to (3.3.8); (3.3.7) Let ; (3.3.8) Order ,if That is, the first If the cost of a partition is less than the average cost of the partitions, vertices need to be added; go to (3.3.6); otherwise, it means that the cost of the partitions has reached the average cost, and no vertices need to be added; go to (3.3.9). (3.3.9) Order ; (3.3.10) Let the partition index ,like , see (3.3.3); if This indicates that the partitioning is complete and the graph partitioning results for light vertices are obtained. Proceed to (3.4).

7. The distributed co-purchasing recommendation method based on graph pattern matching as described in claim 1, characterized in that... Step (3.5) graph partitioning module right The method for vertical partitioning is: (3.5.1) Let the index of the multiple vertices be... ; (3.5.2) Read Find the neighboring vertices and obtain the neighbor list. ; (3.5.3) will Divided into A set of neighboring units of equal size and non-overlapping size; (3.5.4) Graph Partitioning Module Storage number A subset of neighbors; (3.5.5) Order ,like Go to (3.5.2); otherwise, for middle After processing all heavy vertices, the partitioning and storage of heavy vertices are completed. Proceed to (3.6).

8. The distributed co-purchasing recommendation method based on graph pattern matching as described in claim 1, characterized in that... Step (4.1) graph partitioning module right In The neighbor list of each heavy vertex is divided according to cost. The method for finding a cost-equilibrium neighbor group is: (4.1.1) Let the index of the multiple vertices be... ; (4.1.2) will The Middle Each vertex The neighbor list is recorded as , , ,for The number of vertices in the middle; calculate The estimated cost of each vertex in the middle, of which Estimated cost Calculate according to formula (5), and The estimated cost of each vertex is temporarily stored in the cost array. ,right middle The costs are summed up to obtain the total cost. ; , formula (5); (4.1.3) Calculate the first using formula (6). Each vertex The Neighborhood group Cost : Formula (6); (4.1.4) Based on Will The neighbor list is divided into The cost-equilibrium neighbor group; the first... A group of neighbors is denoted as a binary group. ,express The Each neighbor group contains a list of neighbors. The middle index belongs to the range The vertices inside will In , They are respectively denoted as and ;Will The method for dividing the neighbor list into neighbor groups is: (4.1.4.1) Let the neighbor vertex index ; (4.1.4.2) Let the neighbor group index ; (4.1.4.3) Let ; (4.1.4.4) Graph Partitioning Module Calculate the mean cost of the neighbor group , ; (4.1.4.5) Cost of new neighbor groups ; (4.1.4.6) Let ; (4.1.4.7) Let ;if , then proceed to (4.1.4.6); otherwise, proceed to the next step. Neighborhood group The cost exceeds the average cost of the neighboring group, see (4.1.4.8). (4.1.4.8) Order ; (4.1.4.9) Order ,like If yes, then proceed to (4.1.4.3); otherwise, repeat the vertex. The neighbor list has been divided into 1 neighbor group, get The cost-equilibrium neighbor group, see (4.1.5). (4.1.5) Order ,like Go to (4.1.2), otherwise, The neighbor list of all heavy vertices has been partitioned into The neighbor group received The cost-equilibrium neighbor group of all heavy vertices is determined, see (4.2).

9. The distributed co-purchasing recommendation method based on graph pattern matching as described in claim 1, characterized in that... Step (4.2) graph partitioning module right In The method for dividing the neighbor list of a heavy vertex into several balanced neighbor groups based on the number of vertices is as follows: (4.2.1) Let the threshold parameter for the number of vertices in the neighbor group be... ; (4.2.2) Let ; (4.2.3) will The first in Each vertex neighbor vertex set The number of vertices is of There are 10 neighbor groups, among which... middle The A balanced neighbor group of vertices is denoted as , ; (4.2.4) Let ,like Go to (4.2.3), otherwise, the neighbor lists of all heavy vertices have been divided into neighbor groups with balanced vertices, go to (4.3).

10. The distributed co-purchasing recommendation method based on graph pattern matching as described in claim 1, characterized in that... The task execution module described in step (5.4) Loading co-purchase relationship diagram ,calculate Matching order and the corresponding execution plan The method is: (5.4.1) Selection The vertex with the highest degree As and Matching order The first vertex in, followed by the next vertex in Choose from the remaining vertices in the middle. The vertex with the most adjacent vertices is selected as the next vertex in the matching order. Matching order , , , yes An ordered set of vertices. yes The number of vertices, It is the first in the matching order One vertex; (5.4.2) Based on Calculate the corresponding execution plan ,in, , No. A set of vertices yes Central Previous vertex set Zhongyu A set of connected vertices; through calculation The intersection of the neighbor lists of the vertices mapped to the co-purchase relationship data graph in the graph yields the matching order of the vertices. A candidate set of vertices.

11. The distributed co-purchasing recommendation method based on graph pattern matching as described in claim 1, characterized in that... As described in step (6.1); Task generation module A task-stealing mechanism is adopted, selecting a suitable NUMA node based on the priority of local computer nodes first, followed by remote computer nodes. From the graph partitioning module The method for stealing a set of vertices and generating a stolen single-vertex extension task is as follows: (6.1.1) Generate a neighbor group for each heavy vertex using cost equilibrium. For a cost-balanced single-vertex scaling task, In Each key vertex, task generation module For each heavy vertex, generate a single-vertex extension task based on a group of its neighbors, using the following method: (6.1.1.1) Let ; (6.1.1.2) Task Generation Module generate In Single-vertex extension task ; Will Match to Matching order The first vertex in , exist Partial embedding on ; The neighbors of the vertex to be expanded are only multiple vertices. , ; Only for Expand to include some neighbors, select A neighbor group As , yes A cost-equilibrium neighbor group index; The neighbor list is divided into in step (3.5) Each partition, graph partition module Storage number Each partition, simultaneously. The neighbor list is divided in step (4.1) The neighborhood group, the first The partition contains the first To the Each neighbor group, ; It is based on the neighbor group The computational cost of extending the current embedding will be Substitute into the formula Calculation obtained ,make ; (6.1.1.3) Task Generation Module Will Send to task buffer module ; (6.1.1.4) Task Buffer Module Will Store in the task ready queue If it is already full , The maximum capacity of the task ready queue is 64. Go to (6.1.1.4) and wait for a time interval. , ;like Not yet completed, proceed to (6.1.1.5). (6.1.1.5) Order ,like If yes, proceed to (6.1.1.2); otherwise, it indicates that a single-vertex extension task has been generated for all vertices, proceed to (6.1.2). (6.1.2) The task generation modules execute in parallel, among which the first... Task generation module on each NUMA node From the graph partitioning module Get The task involves generating a list of neighbors for each light vertex and then extending the task to a single vertex. Each light vertex is denoted as , The method is: (6.1.2.1) Task Generation Module Initialize the index of the local partition light vertices, let ; (6.1.2.2) Task Generation Module Initialization by the first Single-vertex extended task generated by a light vertex ; Light vertex Match to Matching order The first vertex in Partially embedded Light vertex It is a vertex connected to the vertex to be expanded. ; The neighbor list of the middle vertex is , ; yes The cost will Substitute into the formula Calculation obtained ,make ; (6.1.2.3) Task Generation Module Will Send to task buffer module ; (6.1.2.4) Task Buffer Module Will Store in the ready queue If the process is full, proceed to (6.1.2.4) and wait for a time interval. ;like Not yet complete, proceed to (6.1.2.5); (6.1.2.5) Task Generation Module make ,like Proceed to (6.1.2.2); otherwise, proceed to the graph partitioning module. All light vertices in the array have been used to generate single-vertex extension tasks, see (6.1.3). (6.1.3) Dynamically steal storage in remote graph partitioning module based on cost The set of vertices in the , Values ​​are retrieved according to the following strategy: First, remote NUMA nodes on the local computer node are searched, then NUMA nodes on the remote computer node are searched. i.e., diagram partitioning module The light vertices on the top have not yet all been generated. Single-vertex scalable embedded task generation module Task generation module From the graph partitioning module Obtain several vertices such that the sum of the costs of these vertices approaches the cost threshold. , The set of vertices in this group is denoted as the stolen vertex set. ,Will The Middle Each vertex is denoted as , ;like Number of mid vertices Task generation module If execution is complete, proceed to (6.4); otherwise, proceed to (6.1.4). (6.1.4) Task Generation Module Stealing vertex set To generate a single-vertex extended task, the method is as follows: (6.1.4.1) Let the vertex index ; (6.1.4.2) Initialize the stealing task ,in ,Will Substitute into the formula Calculation obtained ,make ; (6.1.4.3) If the task buffer in the task buffer module Full, proceed to (6.1.4.3) and wait for a time interval. Otherwise, proceed to (6.1.4.4). (6.1.4.4) The task Add to task buffer , will the vertex The request queue is placed in the vertex request module. middle; (6.1.4.5) ,like Go to (6.1.4.2); otherwise, it indicates that the vertex set has been stolen. All vertices in the array have been generated as single-vertex scalable embeddings, see (6.1.5). (6.1.5) Order ,like This indicates that there are still stealable graph partitioning modules. If yes, proceed to (6.1.3); otherwise, explain. The light vertices of the graph partitioning module have all been generated as single-vertex scalable embeddings, and the task generation module... Once completed, proceed to (6.4).

12. The distributed co-purchasing recommendation method based on graph pattern matching as described in claim 1, characterized in that... In step (6.2), the vertex request module, vertex response module, task buffer module, and vertex cache module of each NUMA node cooperate with each other to obtain and store the vertex neighbor list required for task execution in parallel. The vertex request module... Vertex Response Module Task buffer module and vertex cache module The method for obtaining and storing the list of vertex neighbors required for task execution is: (6.2.1) If the vertex request module The first in Request queues The vertex request module is filled. Vertex Response Module send Set the vertex set in the data and clear it. ; (6.2.2) Vertex Response Module Receive Vertex Request Module The set of vertices sent from the graph partitioning module The vertex request module retrieves a list of vertex neighbors from the vertex set. ; (6.2.3) Vertex Request Module Receive vertex response module Send the vertex neighbor list, and then send the vertex neighbor list to the task buffer module. and vertex cache module Task buffer module and vertex cache module Cache the list of vertex neighbors; (6.2.4) If the task execution module No more intermediate extension tasks are generated; vertex request module and vertex response module If execution is complete, proceed to (6.4); otherwise, proceed to (6.2.1).

13. The distributed co-purchasing recommendation method based on graph pattern matching as described in claim 1, characterized in that... Step (6.3) The task buffering module, task scheduling module, and task execution module of each NUMA node cooperate to execute tasks in parallel, generate new intermediate extension tasks, and continuously update the set of embedded instances. The method is: (6.3.1) Task Buffer Module Waiting for the module to be requested from the vertex Receive the vertex neighbor list and complete the task data. The method is as follows: (6.3.1.1) If the task buffer module No request received from the vertex module Send the vertex neighbor list, then proceed to (6.3.1.1) and wait for a time interval. , If a request is received from the vertex request module Send the list of vertex neighbors, see (6.3.1.2). (6.3.1.2) Task Buffer Module The task list corresponding to the received vertex neighbor list is denoted as The total number of tasks , of which Each task is recorded as , task sequence number ; (6.3.1.3) Find the vertex neighbor list from the received vertex neighbor list The required list of vertex neighbors is assigned to The third item in; (6.3.1.4) will From the task buffer Delete; (6.3.1.5) If the task ready queue Full, proceed to (6.3.1.5) and wait for a time interval. Otherwise, the task ready queue Not yet, proceed to (6.3.1.6). (6.3.1.6) The task Add to ready queue area ; (6.3.1.7) Order ,like Proceed to (6.3.1.3); otherwise, the task buffer module... All extended tasks corresponding to the vertex neighbor list have been prepared. The ready extended tasks corresponding to the vertex neighbor list are obtained. Proceed to (6.3.2). (6.3.2) Task Scheduling Module Receive from the task buffer module The ready-to-expand tasks form a task mapping scheme, the method being: (6.3.2.1) Task Execution Module Open One worker thread, It is a positive integer; (6.3.2.2) Task Execution Module ready queue When the task list is full, a pop-up will appear. And send it to the task scheduling module. ; (6.3.2.3) Task Scheduling Module Based on cost Average score A cost-equilibrium task group, of which the first... Group tasks are denoted as binary groups. , indicating the first Group tasks include a task list The task sequence number is located in The task; will In and They are respectively denoted as and The method is: (6.3.2.3.1) Let Number of tasks , of which Each task is recorded as Calculation task list The sum of the costs of the tasks is denoted as . ; (6.3.2.3.2) Let the task group index Task Index ; (6.3.2.3.3) Order ; (6.3.2.3.4) Calculate the average cost of the task group , that is to say ; (6.3.2.3.5) Command the task group Cost ; (6.3.2.3.6) Order ,in yes The estimated cost equals The fourth item; (6.3.2.3.7) Order ;if Task group If the cost is less than the average cost of the task group, it means that the current cost of the task group is insufficient and a task needs to be added. Proceed to (6.3.2.3.6); otherwise, it means that the cost of the task group has reached the average and no task needs to be added. Proceed to (6.3.2.3.8). (6.3.2.3.8) Order ; (6.3.2.3.9) Order ,like Proceed to (6.3.2.3.3); otherwise, once the task groups are divided and cost-equilibrium task groups are obtained, proceed to (6.3.2.4). (6.3.2.4) The generated by (6.3.2.3) A cost-equilibrium task group is randomly assigned to Each thread obtains a task mapping scheme, and then combines the task mapping scheme with... A cost-balanced task group is sent to the task execution module. ; (6.3.3) Task Execution Module Receive from the task scheduling module Task mapping scheme and A cost-equilibrium task group is assigned to a task group according to the task mapping scheme. One thread; (6.3.4) Task Execution Module middle Threads execute in parallel Tasks in a cost-equilibrium task group; where the first The assigned thread executes the first... Task groups If the task expands the matching order The last vertex in the sequence is then used to calculate the final matching result and update the sequence. Otherwise, an intermediate extension task will be generated; ; Send intermediate extended tasks to the task buffer module If an intermediate extension task If all four entries have been assigned values, the intermediate extension task is ready; otherwise, the intermediate extension task is not ready; Task buffer module Store ready intermediate extension tasks into the task ready queue. Store unread intermediate extended tasks in the task buffer. Recommended combinations Storage co-purchase frequency value The highest front An embedding, That is, embeddings in the co-purchase relationship data graph that are isomorphic to the co-purchase relationship pattern graph and have a high co-purchase frequency value; the method is: (6.3.4.1) Let the task index Z= ; (6.3.4.2) For the first Task groups The first in Task Through calculation The intersection of the vertex neighbor lists in the array is used to obtain the vertices to be expanded. candidate set , express The number of partially embedded vertices; (6.3.4.3) The candidate sets are respectively Vertex in Match to the vertex to be expanded If the task expands the matching order The last vertex is Then the embedded instance is obtained directly, and the update is performed. Otherwise, generate a new intermediate scalable task set. If it is possible to partition the graph module Or vertex cache module If the list of vertex neighbors required for all extended tasks is obtained, then a ready intermediate scalable task is generated; otherwise, a not-ready intermediate scalable task is generated. The method is as follows: (6.3.4.3.1) Calculate the first entry of the intermediate scalable task, partially embedded. If it is the last expansion, then... , express The number of vertices, then the result is For embedded instances, the calculation is performed according to the co-purchase frequency model formulas (7) to (9). Co-purchase frequency value , for The set of edge labels, if There are co-purchase frequency values ​​lower than Embedded instance Then from Delete, join in If the above steps are not followed, proceed to (6.3.4.5) to execute the next task; otherwise, proceed according to the execution plan. Obtain the vertex set of the intermediate scalable task , , , turn to (6.3.4.3.2); , formula (7); , formula (8); Formula (9); in, , For embedded instances The number of middle edges, For balancing parameters, ; (6.3.4.3.2) Let This leads to a new set of tasks that are not yet ready. The set of tasks ready ;like In Excluding multiple vertices, go to (6.3.4.3.3); if It contains multiple vertices, see (6.3.4.3.6). (6.3.4.3.3) Task Execution Module From the vertex cache module HeTu Partition Module Get from The set of neighbor lists of vertices in ,make If the vertex set Does it exist that are not stored in the graph partition module? With vertex cache module If the vertex is reached, proceed to (6.3.4.3.4); otherwise, All vertices in the graph are stored in the graph partitioning module. Or vertex cache module In the middle, transfer (6.3.4.3.5); (6.3.4.3.4) Task Execution Module Generate unread intermediate extension tasks , ,in, Only includes data stored in the graph partition module With vertex cache module Vertex neighbor list, cost Temporarily initialize to 0; set the set of tasks not yet ready. ; turn to (6.3.4.4); (6.3.4.3.5) Calculate the cost of intermediate extension tasks according to formula (10). The cost is The sum of the cardinality of each set generates a ready intermediate extension task. , and the task Add to the ready extended task set, i.e., the set of tasks that are ready. ; turn to (6.3.4.4); , formula (10); in, Indicates task In ; (6.3.4.3.6) Task Execution Module From the vertex cache module HeTu Partition Module Get from The set of neighbor lists of light vertices in ,make If the vertex set There are light vertices that are not stored in the graph partitioning module. With vertex cache module In the middle, proceed to (6.3.4.3.7); otherwise, vertex set. All light vertices in the graph are stored in the graph partitioning module. or vertex cache module In the middle, transfer (6.3.4.3.10); (6.3.4.3.7) Task Execution Module From the graph partitioning module Get from Each heavy vertex in The vertex neighbor list, where and heavy vertex The neighbor list is recorded as , The number of intermediate vertices is denoted as Select the vertex with the largest degree and denote it as . Task execution module From the graph partitioning module China receives Vertex-balanced neighbor groups ; (6.3.4.3.8) Let the number of unread intermediate tasks be... The task execution module is based on the vertex with the highest degree of repetition. The vertex-balanced neighbor group splits the costly intermediate extension task into smaller parts, generating... An incomplete intermediate extension task, denoted as , order the The task is ,in , including neighbor groups of heavy vertices and stored in the graph partitioning module With vertex cache module Vertex neighbor list, cost Set to 0 for now; (6.3.4.3.9) Order ; turn to (6.3.4.4); (6.3.4.3.10) Task Execution Module From the graph partitioning module Obtain each heavy vertex The vertex neighbor list, where and Its neighbor list is recorded as , The number of multiple vertices in the array is denoted as . Select the vertex with the largest degree and denote it as . From the graph partitioning module China receives Neighbor Group ; (6.3.4.3.11) Order Task execution module generates A ready intermediate extension task, denoted as , of which The task is ,in, , whereby by Substitute into formula (10) to calculate the estimated cost of the task. ,make ; (6.3.4.3.12) Order ; (6.3.4.4) Task Execution Module Send the newly generated intermediate extended task to the task buffer module. Task caching module Store ready intermediate scalable tasks and non-ready intermediate scalable tasks into the ready queue respectively. and task buffer The method is: (6.3.4.4.1) If the task buffer module Task ready queue Full, proceed to (6.3.4.4.1) and wait for a time interval. Otherwise, proceed to (6.3.4.4.2). (6.3.4.4.2) The task Add to the task ready queue ; (6.3.4.4.3) If the task buffer module Task buffer Full, proceed to (6.3.4.4.3) and wait for a time interval. Otherwise, proceed to (6.3.4.4.4). (6.3.4.4.4) The task Add to task buffer ; (6.3.4.5) Order ,like , No. Task groups If there are still unfinished tasks, proceed to (6.3.4.2); otherwise, proceed to step 1. Task groups Once all tasks in the middle have been completed, proceed to (6.3.5). (6.3.5) If the task execution module If no further intermediate extension tasks are generated, proceed to (6.3.7); otherwise, proceed to (6.3.6). (6.3.6) Task Buffer Module Prepare vertex neighbor list data for the unread intermediate extension tasks in the task buffer, calculate the cost of the tasks, and convert the unread intermediate extension tasks into ready intermediate extension tasks. The method is as follows: (6.3.6.1) Task Buffer Module Send the set of vertices in the task buffer that are missing neighbor lists to the vertex request module. The vertex request module groups the vertex set according to the NUMA nodes where the vertices are stored, dividing it into... The nth vertex subset will be the nth vertex subset. Add a subset of vertices to the request queue , ; (6.3.6.2) Task Buffer Module From the vertex request module Receive the required vertex neighbor list, find the vertex neighbor list required by the incomplete intermediate extension task from the required vertex neighbor list, and add it to the incomplete intermediate extension task. item; (6.3.6.3) Task caching module Calculate the cost of each task according to formula (10) and add it to the unread intermediate extension tasks. This allows unread intermediate extension tasks to become ready intermediate extension tasks; (6.3.6.4) If the task buffer module Task ready queue Full, proceeding to (6.3.6.4), waiting for a time interval. Otherwise, proceed to (6.3.6.5); (6.3.6.5) Task caching module Remove ready intermediate extended tasks from the task buffer. Delete and add to the task ready queue. , see (6.3.1); (6.3.7) Task Execution Module Output Embedded instances represent co-purchase relationship data graphs Diagram of the relationship between China and co-purchasing A homogeneous subgraph; the set of products represented by the vertices of each embedded instance is a co-purchase combination recommendation result.

Images