提高移除 TinkerGraph 顶点的性能

如何解决提高移除 TinkerGraph 顶点的性能

我有一个图 g，有 600k 个顶点和 950k 个边。经过一些处理后，我需要使用此查询清理大约 350k+ 个顶点：

g.V().hasLabel(LABEL_INTERMEDIATE_COLUMN).not(inE(EDGE_DEPEND)).drop().iterate();

即使我排除了没有“依赖”边的顶点，它们仍然与其他边相连。

使用 Java，tinkerpop/tinkergraph 3.4.6。

目前，删除所有这些顶点大约需要 45 分钟。

我进行了 Java 分析，结果显示 73% 的时间花在 TinkerVertex.remove 方法上，其余时间花在 ExpandableStepIterator.next

有没有像“批量投放”这样的东西？ JanusGraph 或其他图形提供者会更快吗？

解决方法

不太可能有比 TinkerGraph 快得多的图，因为 TinkerGraph 是纯内存中的实现。您可能会发现使用该内存更有效的方法，例如最初从 TinkerGraph 分叉的 OverflowDB，但我不知道它会使此特定查询运行得更快。

TinkerGraph，也不是我所知道的任何图表，都有过滤的“批量删除”操作。

此处的“not”样式全局查询简单而昂贵，因为您必须接触图形的大部分。当然，我有点惊讶 TinkerGraph 为一个少于一百万条边的图花费这么长时间。你没有提到你在做你的个人资料时是否遇到了很多 GC。也许这是一个问题？如果是这样，我会尝试调整您的 JVM 内存配置 - 也许您只需要一个更大的 -Xmx 值或类似的东西。

从查询的角度来看，您可以尝试反转遍历的 not() 部分以积极地找到要删除的内容。它可能会导致读取不那么简洁的查询，但可能会加快速度，但另一方面，您仍在尝试删除 50% 的数据，因此成本可能不仅仅是找到要删除的顶点。

另一种想法是尝试并行化 drop()。您可能会遇到并发错误，因此您可能需要重试策略，但您可以考虑采用 Iterator 的 g.V().hasLabel(LABEL_INTERMEDIATE_COLUMN).not(inE(EDGE_DEPEND))，然后将对每个（或批次）Vertex.remove() 的调用委托给单独的工作线程.

基于接受的答案，简单的并行化改进到足以使此操作不再是最关键的时间

为了将来参考，这个：

g.V().hasLabel(LABEL_INTERMEDIATE_COLUMN).not(inE(EDGE_DEPEND)).drop().iterate();

现在是这样的：

ExecutorService executor = Executors.newFixedThreadPool(4);
int iterator = 0;
final int batchsize = 10000;
Long count = g.V().hasLabel(LABEL_INTERMEDIATE_COLUMN).not(inE(EDGE_DEPEND)).count().next();
List<Callable<Object>> callableList = new ArrayList<Callable<Object>>();

// splitting current set into tasks to be executed in para
while (iterator * batchsize < count) {
    final Set<Object> vSet =  g.V().hasLabel(LABEL_INTERMEDIATE_COLUMN).not(inE(EDGE_DEPEND)).skip(iterator * batchsize).limit(batchsize).id().toSet();
    callableList.add(() -> g.V(vSet).drop().iterate());
    iterator++;
}
List<Future<Object>> results = executor.invokeAll(callableList);

经过一些测试，我决定将迭代保留在单个线程中。这样分布式任务就真正相互独立了（例如：完成一个任务不会影响其他任务的查询）。

请记住，实际删除仍然是单线程，因为顶点节点映射修改在并发访问锁之后。

效果是增加线程并不会得到更好的结果（个人试了8个）。根据一些线程转储，即使是 4 个也可能太多（总是有 1 个或多个线程处于等待状态）——尽管我确实得到了 3 个线程正在运行的转储！