0

我有一个应用程序，其消息传递粒度可以用两种方式编写——发送许多小消息与（可能远）更少的大消息。从概念上讲，移动的是一组“活动”顶点 ID，它们可能会在每个超级步骤中根据顶点管理的已处理列表（顶点值）进行过滤。活到最后的人是幸运的赢家。compute()计算一组非常适合传出消息的“新来我”传入 ID，但我可以轻松地一次发送每个 ID。我的猜测是发送更少的消息更重要，但是每组可能包含数千个 ID。谢谢你。

PS 一个附带问题：我发现的少数自定义消息类型示例是具有一些原始实例变量的相对简单的对象，而不是集合。将一组 ID 作为消息发送是不是很疯狂？

4

3 回答 3

1

我已经使用列表甚至地图来发送或存储为顶点数据，所以这不是问题。我认为你想选择哪个 giraph 并不重要，我宁愿使用许多简单的小消息，因为你会适当地使用 Giraph。相反，您需要通过消息列表进入计算函数，并通过 ID 列表进入每条消息。

就性能而言，它不应该有任何区别。我发现有一个很大的不同是，尝试在循环中尽可能多地计算，因为循环之间的切换和同步消息，......需要很多时间。只要不改变它应该或多或少相同，并且当您保持较小的消息大小时可能更容易阅读和维护。

于 2014-09-12T09:44:46.077 回答
0

为了回答您的问题，您需要了解MessageStore接口及其实现。

简而言之，在引擎盖下，它采取了以下步骤：

  1. 工作人员接收消息的字节原始输入和目标 ID
  2. 工作人员对消息进行排序并将它们放入 A Map of A Map 中。第一个map的key是partition ID，section map的key是vertex ID。（有点像邮局。工作就像中心枢纽，它先将字母分类成不同的邮政编码，然后在每个邮政编码中按地址排序）
  3. 当轮到顶点计算时，Iterable该顶点的一条消息被传递给顶点的compute方法，这就是你获取消息并使用它的地方。

因此，如果两种情况的总字节数相同，则更少和更大的消息会更好，因为排序更少。

于 2016-10-29T16:08:31.330 回答
0

此外，您可以发送许多小消息，但让 Giraph（几乎）自动将其转换为长消息。您可以使用组合器。

Giraph 站点上有关此主题的文档很糟糕，但您也许可以从《 Practical Graph Analytics with Apache Giraph》一书中提取一个示例。

这主要取决于您发送的消息类型。

于 2016-11-01T17:27:39.313 回答