RU2761136C1 - Method and system for cyclic distributed asynchronous messaging with weak synchronization for working with big graphs - Google Patents

Abstract

FIELD: information technology.

SUBSTANCE: invention relates to the field of information technology. The expected result is achieved due to the stages at which: a) the set of network messaging points is determined, where each point is a computing node; b) a graph model for exchanging messages between network exchange points is formed, in which the vertices are network exchange points, and the edges are the fact of sending messages.; c) the point of network exchange, the coordinator of the execution of messaging is determined; d) messages from the point of the coordinator to at least one point of network exchange are sent; e) a response from the point of network exchange that received the message at step d) is received, and the said response contains the identifiers of adjacent network exchange points to which messages will be sent from this network exchange point, while the said network exchange point forms routes for subsequent messaging; f) at the coordinator point, the formed message exchange routes are taken into account for each network exchange point of the graph, based on messages from each network exchange point; g) steps e)-f) are iteratively repeated until the coordinator point informs that there are no network exchange points.

EFFECT: increasing the efficiency and speed of message transmission between the computing nodes of the network.

3 cl, 3 dwg, 2 tbl

Description

FIELD OF TECHNOLOGY

[0001] The present technical solution relates to the field of information technology, as well as to the field of managing large graph data, in particular, to methods of transferring graph information between network nodes using cyclic distributed asynchronous messaging with weak synchronization.

LEVEL OF TECHNOLOGY

[0002] From the prior art, a message passing approach is known by building a graph model of exchange nodes, for example, various implementations of the Bulk Synchronous Parallel (BSP) model (https://en.wikipedia.org/wiki/Bulk_synchronous_parallel), in particular, the model, implemented in Apache Giraph (http://giraph.apache.org/intro.html). This model is based on the algorithm for finding the shortest path between exchange nodes, for which the distance between the nodes in the graph structure is determined.

[0003] Known solutions for finding the shortest path is - finding the shortest path between two vertices of a weighted graph (Weighted graph is called a graph whose edges have weights). The most efficient algorithm for finding the shortest path on graphs with non-negative weights is the Dijkstra algorithm (https://en.wikipedia.org/wiki/Diikstra%27s_algorithm). The algorithm requires a sequential search for a path from the nearest (at the current moment) vertex in the first place. Those. if it is known that the path can pass through both vertices, then the algorithm continues the search from the nearest of the two vertices.

[0004] Algorithm CMMS (criterion - OUT) allows you to search for the shortest path in parallel. The algorithm, according to a certain criterion, selects a subset of vertices through which the shortest path can pass. Further, these vertices can be processed in parallel (see https://people.mpi-inf.mpg.de/~mehlhorn/ftp/ParallelizationDiikstra.pdf).

[0005] The disadvantages of the known solutions are that in the Giraph solution, the vertex within the super step receives messages once and sends once. In the case of massively parallel computing systems, in some cases, a strong synchronization system prevents the full load of all processors and increases the algorithm's running time.

[0006] Thus, in the claimed solution, it is proposed to perform multiple transfers between nodes due to weaker synchronization.

SUMMARY OF THE INVENTION

[0007] The technical problem to be solved using the claimed invention is the creation of a new method of circular distributed asynchronous messaging between network nodes with weak synchronization, for working with large graphs.

[0008] The technical result consists in increasing the efficiency and speed of message transmission between network nodes, which contributes to the rapid solution of applied problems in a large graph management system (FastGraph).

[0009] The claimed result is achieved by a computer-implemented method of cyclical distributed asynchronous messaging with weak synchronization, performed using a processor and containing the steps at which:

a) define a set of network messaging points, where each point represents a computing node;

b) form a graph model for the exchange of messages between network exchange points, in which the vertices are the network exchange points, and the edges are the fact of sending messages;

c) define the point of network exchange - the coordinator of the execution of the exchange of messages;

d) send messages from the coordinator point to at least one network exchange point;

e) receive a response from the network exchange point that received the message in step d), said response containing identifiers of adjacent network exchange points to which messages will be sent from this network exchange point, said network exchange point generating subsequent messaging routes;

f) at the coordinator point, the generated message exchange routes are recorded for each network exchange point of the graph, based on messages from each network exchange point;

g) repeat steps e) through f) iteratively until the point coordinator reports that there are no network exchange points.

[0010] In one of the particular examples of the method, each node contains a state store, which contains information about the sign of a visit.

[0011] The claimed technical result is also achieved due to a system of cyclic distributed asynchronous messaging with weak synchronization, containing at least one processor and at least one memory means that stores machine-readable instructions that, when executed by the processor, implement the above method.

BRIEF DESCRIPTION OF DRAWINGS

[0012] FIG. 1 illustrates a general view of the conical messaging model (implementation example)

[0013] FIG. 2 illustrates a block diagram of the implementation of the claimed method.

[0014] FIG. 3 illustrates an example of a computing system.

CARRYING OUT THE INVENTION

[0015] FIG. 1 shows an example of the implementation of the conical messaging model (100). Point (110) represents the node - the center of the cone, point (150) - the top of the cone, points (101) - (106) - data exchange nodes located on the circumference of the cone. As part of the implementation of the declared solution, the nodes of the conical model exchange the specified types of messages presented in Table 1.

[0016] It should be noted that this example shows only a particular implementation in the form of a conical architecture, which can be represented by various variations of the graph model while maintaining the declared functionality and the main computational nodes of the solution (Table 2).

[0017] The host located at the apex of the cone (150) is designated as the coordinator. No vertices (101-106, 110) of the graph are associated with the vertex of the cone (150). The coordinator stores the information necessary to perform the exchange and work (specific to the process).

[0018] Node (110) located at the center of the cone can send a message to itself (ie, the center of the cone can be at the periphery). Each next family of cones within one vertex can be initiated only after the end of the previous one. It is a framework function to detect the end of a cone family. This is the only synchronization point (barrier) in the conical model.

[0019] There may be multiple cone vertices operating in parallel. The families of cones they generate are independent of each other. At the same time, they use the same points, and the processing of messages within the point occurs sequentially and synchronously.

[0020] At each of the stages of the algorithm execution, the conical model provides interaction between the computing nodes and the coordinator (150), in particular, sending requests, receiving responses, synchronizing execution by waiting for responses from all nodes.

[0021] FIG. 2 shows a block diagram of the proposed method (200) of cyclical distributed asynchronous messaging with weak synchronization. At the first step (201), a plurality of network messaging points are determined, over which, in step (202), a graph model is formed for exchanging messages between network exchange points, in which the vertices are network exchange points, and the edges are the fact of sending messages.

[0022] In step (203), the network exchange point is determined - the coordinator of the messaging execution (150), i. E. the apex of the cone is Pv, and the dv algorithm trigger data for that point. The initiating cone in the family of cones using the Pv point differs from the following in that it is initiated using the CRAM message, while the subsequent ones - using the CBM messages.

[0023] At step (203), when performing initialization, an execution coordinator (150) and a predetermined number of computing nodes - the centers of the cones - are created to carry out the messaging process. At this stage (203), an algorithm for the distribution (partitioning) of the graph is also determined, intended for the formation of computational nodes, since each computational node is responsible for processing a part of the graph - it generates its own family of cones. An example of such an algorithm is the algorithm for calculating the hash function of the identifier mod K (http://personal.kent.edu/~rmuhamma/Algorithms/MyAlgoritlmis/h

[0024] At the coordinator node (150), the algorithm function Av calculates the node - the center of the cone (110) Pc and the associated data dvc, which constitutes the CRAM message:

Av (dv) → (Pc, dvc).

[0025] The next step (204) is the coordinator (150) sending a CRAM message to the network exchange point - the center of the cone (110). A detailed description of the step is presented in the section describing an example of the implementation of the method using the example of the CMMS-OUT algorithm.

[0026] In step (205), the following occurs - at node (110) (center of the cone), the function of the Ac algorithm calculates the list of vertices (101) - (106) at the periphery Pbn and the associated data dcbn, which constitutes the CBM set; CAM is also calculated, which includes a list of peripheral vertices (needed to track the completion of the family of cones in the coordinator node):

[0027] At step (206), the CAM is sent with data from the previous point from the network exchange point (the center of the cone (110)) to the coordinator node (150). A detailed description of this step is presented in the section describing an example of the implementation of the method using the example of the CMMS-OUT algorithm.

[0028] At step (207), at the point coordinator (150), the generated messaging routes for each network exchange point of the graph (101) - (106), (110) are taken into account based on the received messages from each network exchange point. The processing principle depends on the process. One of the possible principles is to maintain two queues - one with a list of all network exchange points that need to be visited, and the second one with a list of visited vertices.

[0029] At step (208), it is checked whether all network exchange points have been visited, whether all parallel operations have been completed. If so, the exchange ends. If not, a new iteration occurs and steps (205-207) are repeated.

[0030] Next, consider an example of implementation of the method (200) using the example of the CMMS-OUT algorithm.

[0031] Let us give an example of implementation of the method (200) using the example of the CMMS-OUT algorithm (see Fig. 1). The CMMS-OUT algorithm in the conical model describes an algorithm for finding the shortest paths (in the classical version, unidirectional), which allows finding the shortest paths and distances between a certain vertex (source) and all other vertices in the graph - dist (n).

[0032] The algorithm is iterative. Vertices are divided into unvisited Q, visited and current C. Each vertex is matched dynamically (iteratively) updated time distance tdist (n) - the minimum of the currently known distances from the source to the given vertex (preliminary distance). At the visited vertices tdist (n) = dist (n).

[0033] In the first step (iteration), tdist (s) = 0 for the source and tdist (n) = Infinity for all other vertices n.

[0034] At each step (iteration), the time distance from the current vertices to their incidents (the vertices to which the outgoing edges go) is updated, after which the current vertices are declared visited. The next current peaks (the next peaks to visit) are determined by the condition:

С = {n | tdist (n) ≤ min {tdist (u) + w (u, z) | u in Q, u connected to z}}

The quantity L = min {tdist (u) + w (u, z) | u in Q, u connected to z} (which is part of condition C) is hereinafter referred to as a threshold.

[0035] For convenience of description, let us describe the search for the shortest path from two points of network exchange - from point left (101) to point right (106), that is, find dist (right). The description of the algorithm will be related to the steps of the model described above (steps from Fig. 2).

[0036] The first steps of the model are the same for all algorithms (and for CMMS-OUT in particular), and prepare the algorithms to work. Steps (201) - (203) are performed similarly to the above-described implementation method.

[0037] In the coordinator (150), two prioritized queues of points are maintained, one with priority according to the threshold, and the second with priority according to the minimum path weight - minPathWeight = min {tdist on the vertices of the point}.

[0038] A coordinator is placed at the cone vertex. No vertices of the graph are associated with the vertex of the cone.

[0039] The operation of the algorithm involves network exchange points (vertices) and computing nodes (VU). A computing node is associated with a set of nodes - that is, each VU includes several nodes (network exchange points). Each of the vertices (network exchange point) is associated with exactly one VU.

[0040] With each VU there is an associated node state store (process specific). The storage for each VU vertex contains:

preliminary distance (tdist);

sign of visiting;

value minCEW (u) = min {w (u, z) | u connected to z} - minimum connected edge weight, which specifies the minimum weight of the outgoing edge.

[0041] The storage also stores the current threshold value, consolidated for all nodes of the VC.

[0042] As noted above, at step (203), the execution coordinator is determined, and partitioning also occurs - the selection of a given number (X) of computational nodes (VN), which will determine the construction of a family of cones and will provide parallel execution of the algorithm.

[0043] The coordinator does not know where the starting point for calculating the shortest path (left) and the ending point nyra (right) are located.

[0044] In order to find the starting point left (to initiate the algorithm), the coordinator sends a message to the computational nodes (CA) and receives a response in which computational node the starting vertex is located.

[0045] Next, the coordinator at step (204) sends a message to the found VU where the left point is.

[0046] At this stage (204), the CRAM Init message (left (101)) is sent to the network exchange point left (101) (the beginning of the path). The vertex left (101) is visited (all paths to it = 0). This happens on the first iteration of the algorithm.

[0047] Subsequently, the coordinator (150) (in further iterations) at step (204) sends the input data for step (205) —which is a set of vertices to be visited during step (205), which are distributed across different VUs, in pairs with the weight of the path to it associated with the vertex.

[0048] Thus, the coordinator (150) can send these messages in step (204) to several TDs in parallel, and accordingly, steps (205) - (206) will be performed in parallel for each TD. Each VU has its own set of vertices associated with it.

[0049] In step (205), the VU, having received the message from the coordinator (150), generates routes for the subsequent exchange of messages. The VU retrieves a list of adjacent vertices and distributes the work of adding these graph vertices to the queue for visiting between the corresponding VU.

[0050] Each computing node must calculate the distance limit L for the next hop and report it to the coordinator (150).

[0051] At step (205), subsequent message exchange routes are generated at the WU.

[0052] For each network exchange point that received the message sent in the previous step (204):

a) The sign of a visit is set (in the state store)

b) A macro step (Cone) is performed. The associated point becomes cone center.

c) A list of vertices is built, where the edges go from the given vertex (incident nodes), in pairs with the associated weight of the path to it (through the current vertex). Filtering of edges and vertices is applied, if necessary.

d) ThresholdRequest ([(node, pathWeight)]) is sent according to the list. Messages are aggregated by VUs to which the target vertices belong.

[0053] Within each vertex (network exchange point) upon receipt of the ThresholdRequest:

1. In the storage of vertex states for each of the unvisited vertices:

a) If there is no state (the vertex was not previously visible), a state object is added for this vertex. When a new vertex is opened, the vertex is considered unvisited, tdist is equal to infinity, minCEW is calculated when the state is initialized and does not change further.

b) the preliminary distances of unvisited vertices are updated: if the new preliminary distance of pathWeight is less than the current tdist, the new one becomes the current one.

2. The sentence is calculated by the threshold value from the VU: the threshold value for all unvisited vertices from the list belonging to the given computational node (VU) (using the weight of the path to it and the minimum weight of the outgoing edge minCEW). This value is stored in the storage.

[0054] After the proposals are generated in step (205), they are sent to the coordinator in step (206).

[0055] At step (206), the message CAM VisitReport (thresholdOffer, minPathWeight) is sent to the coordinator - information on visiting the VU containing the current threshold value for this VU, taken from the storage, and with the minPath Weight value equal to the minimum tdist for the VC vertices.

[0056] Also at this stage, a CSM ThresholdOffer (thresholdOffer, minPath Weight) message is sent from each vertex to the coordinator (150) with a thresholdOffer proposal value and a minPathWeight value equal to the minimum tdist for the VC vertices.

[0057] In step (207), the coordinator (150) selects the smallest limit and instructs the computational nodes to visit those vertices that fall within this limit.

[0058] The coordinator calculates the threshold value L and visits those vertices that fall within this limit.

[0059] At the next stage (207) on the coordinator (150), the information about the generated message exchange routes is taken into account, namely:

a) Upon receipt of the VisitReport CAM, the coordinator updates the prioritized queues of points.

b) In the coordinator, all CSM ThresholdOffer messages are aggregated and the effective threshold value is calculated. Prioritized queues are updated.

[0060] Also at step (207), the vertices for the next visit are calculated - from the prioritized queue in the coordinator, all VUs that have unvisited vertices that satisfy the threshold value are selected.

[0061] Also, after taking into account the generated routes at step (207), the algorithm completion is checked: if the previously received routes contain information about the vertex right, then terminate the algorithm and return the tdist value associated with right as a result of the algorithm. If this vertex is not found, then flow to step 208.

[0062] At step (208), it is checked whether there are new vertices to visit (information about this was generated in the previous step). If there are no new vertices, then terminate the algorithm with the result infinity (the target vertex right was not found, i.e. there is no path going to it from left).

[0063] If there are vertices, then steps (204_ - (207) of the algorithm of method (200) are iteratively repeated).

[0064] The transition to step (204) is carried out based on the fact that a CRAM VisitNodes (threshold) message is sent to each of the selected nodes, then at step (205) each VU selects the nodes corresponding to the threshold value. These vertices are declared selected. The path weights to them are their current tdist values.

[0065] Steps (206) - (208) are performed until the desired vertex is found, or it is not found that there is no path from the left point to the right point, or the algorithm will not stop on another stopping criterion - for example, the maximum number iterations.

[0066] FIG. 3 shows a general view of a computing device (300) suitable for performing the method (200). The device (300) can be, for example, a server or other type of computing device that can be used to implement the claimed method.

[0067] In the General case, the computing device (300) contains one or more processors (301) united by a common data exchange bus, memory means such as RAM (302) and ROM (303), input / output interfaces (304), input devices / output (305), and a device for networking (306).

[0068] The processor (301) (or multiple processors, multi-core processor) can be selected from a range of devices currently widely used, for example, Intel ™, AMD ™, Apple ™, Samsung Exynos ™, MediaTEK ™, Qualcomm Snapdragon ™ and etc. The processor (301) can also be a graphics processor, for example, Nvidia, AMD, Graphcore, etc.

[0069] RAM (302) is a random access memory and is intended for storing machine-readable instructions executed by the processor (301) for performing the necessary operations for logical processing of data. RAM (302), as a rule, contains executable instructions of the operating system and corresponding software components (applications, software modules, etc.).

[0070] ROM (303) is one or more persistent storage devices such as a hard disk drive (HDD), solid state data storage device (SSD), flash memory (EEPROM, NAND, etc.), optical storage media ( CD-R / RW, DVD-R / RW, BlueRay Disc, MD), etc.

[0071] Various types of I / O interfaces (304) are used to organize the operation of the components of the device (300) and to organize the operation of external connected devices. The choice of the appropriate interfaces depends on the specific version of the computing device, which can be, but are not limited to: PCI, AGP, PS / 2, IrDa, Fire Wire, LPT, COM, SATA, IDE, Lightning, USB (2.0, 3.0, 3.1, micro , mini, type C), TRS / Audio jack (2.5, 3.5, 6.35), HDMI, DVI, VGA, Display Port, RJ45, RS232, etc.

[0072] To ensure the interaction of the user with the computing device (300), various means (305) I / O information are used, for example, a keyboard, display (monitor), touch display, touch-pad, joystick, mouse manipulator, light pen, stylus, touch panel, trackball, speakers, microphone, augmented reality, optical sensors, tablet, light indicators, projector, camera, biometric identification (retina scanner, fingerprint scanner, voice recognition module), etc.

[0073] The means of networking (306) allows the device (300) to transmit data via an internal or external computer network, for example, Intranet, Internet, LAN, and the like. One or more means (306) may be used, but not limited to: Ethernet card, GSM modem, GPRS modem, LTE modem, 5G modem, satellite communication module, NFC module, Bluetooth and / or BLE module, Wi-Fi module, and dr.

[0074] In addition, satellite navigation aids can also be used as part of the device (300), for example, GPS, GLONASS, BeiDou, Galileo.

[0075] The presented materials of the application disclose the preferred examples of the implementation of the technical solution and should not be construed as limiting other, particular examples of its implementation, not going beyond the scope of the claimed legal protection, which are obvious to specialists in the relevant field of technology.

Claims (10)

1. Computer-implemented method of cyclical distributed asynchronous messaging with weak synchronization, performed using a processor and containing the stages at which: a) define a set of network messaging points, where each point represents a computing node; b) form a graph model for the exchange of messages between network exchange points, in which the nodes are network exchange points, and the edges are the fact of sending messages; c) define the point of network exchange - the coordinator of the execution of the exchange of messages; d) send messages from the coordinator point to at least one network exchange point; e) receiving a response from the network exchange point that received the message in step d), said response containing identifiers of adjacent network exchange points to which messages will be sent from this network exchange point, said network exchange point generating subsequent messaging routes; f) at the coordinator point, the generated message exchange routes are recorded for each network exchange point of the graph, based on messages from each network exchange point; g) repeat steps e) through f) iteratively until the point coordinator reports that there are no network exchange points. 2. The method according to claim 1, characterized in that each vertex contains a state store, which contains information about the sign of a visit. 3. A system of circular distributed asynchronous messaging with weak synchronization, containing at least one processor and at least one memory means that stores machine-readable instructions, which, when executed by the processor, implement the method according to any one of claims. 12.

Images