Question

在我们的图形中，有很多顶点的输出边超过100k。我想知道有什么方法可以处理由此产生的所有情况。

假设我们在图形中定义了一个group_1。 group_1有100k members。我们有一些从member_x顶点开始的遍历，并计算了一些东西。这些遍历速度非常快，它们各自在〜2s内结束。

但是时间改变了，现在我们需要将单个小遍历的所有结果汇总为一个数。遍历必须包含group_1成员的所有结果。

首先，我们的方法是通过使用members_x和skip来创建发出limit束的遍历，然后在应用程序级别使用并行处理来计算我们的总和。但是，这种方法几乎没有问题：

g.V().has('group',y).out('member_of').skip(0).limit(10)-根据文档，遍历可以每次返回不同的结果。因此，以这种方式创建捆绑商品将是不正确的
g.V().has('group',y).out('member_of').skip(100_000).limit(10)花费的时间太长，因为正如我们所发现的，数据库仍然必须访问10万个顶点

因此，我们的下一个方法是存储一个遍历，该遍历发出members的束，然后在单独的线程中执行并行遍历，该遍历遍历先前获取的成员的总和：

while(is_not_the_end) {
   List<Members> members = g.V().has('group',y).out('member_of').next(100)`
   addMembersToExecutorThread(members) // done in async way
}

那么，当您遇到这种情况时，有哪些方法？基本上，如果可以找到一种快速获取某个顶点的所有祖先的方法，我们就可以解决该问题。在我们的情况下，这将是group_1。但是，仅通过使用g.V().has('group',y).out('member_of').properties('members_id')来获取ID会花费很多时间。

是否有解决此问题的方法？还是我们应该尝试在GraphComputer上执行此类查询？

Answer 1

听起来您的用例需要几乎（如果不是）完整的图形扫描。这是图形的非常常见的用例，您可以看到它的一些用例here。学位中心是最受欢迎的用例之一。

如果将聚合逻辑推到应用程序层，则会错过Tinkerpop图形库的最大好处。 OLAP遍历非常快。

请注意：

实际上，如果您确实使用图形计算机/游标遍历，则应该在图形相对静态的环境中使用。这是因为tinkerpop中的OLAP traversals将图形序列化为内存结构。因此，更改图表必须重新序列化。在瞬息万变的环境中，这会大大降低速度。

希望有帮助。

Answer 2

您的用例似乎是@Filipe提到的OLAP用例。

有多种实现方法，一种方法是使用Tinkerpop的图形库。但这可以通过使用存储在存储系统（JanusGraph后端）中的数据来实现，这最终可能会减慢其他实时图形查询的速度。

对于规模约为20B的类似用例，我们从JanusGraph存储后端中取出了它，并使用了带有spark的MapReduce方法。

Spark GraphX是另一个可以通过Spark加载数据的工具。最后，经过多次测试和失败，我们使用Conencted Component in MR and Beyond解决了用例。这是Google的研究论文。

如何处理具有大量边的顶点？

2 个答案: