0

我有一个g带有600k顶点和950k边的图。经过一些处理,我需要用这个查询清理350k+顶点:

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

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

使用 Java,tinkerpop/tinkergraph 3.4.6。

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

我做了一个 java profiling,结果显示73%的时间花在TinkerVertex.remove方法上,剩下的ExpandableStepIterator.next

有没有类似“散装”的东西?JanusGraph 或其他图形提供程序会更快吗?

4

2 回答 2

1

不太可能有比 TinkerGraph 快得多的图,因为 TinkerGraph 是纯内存实现。您可能会发现使用最初从 TinkerGraph 派生的OverflowDB之类的内存更有效,但我不知道它会使这个特定查询更快。

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

这里的“not”样式全局查询很简单,因为您必须触摸图表的大部分。当然,我有点惊讶 TinkerGraph 花了这么长时间来制作一个边数少于一百万的图。你没有提到你在做你的个人资料时是否经历了很多 GC。也许这是一个问题?如果是这样,我会尝试调整你的 JVM 内存配置——也许你只需要一个更大的-Xmx值或类似的简单的东西。

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

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

于 2021-06-19T11:05:38.320 回答
0

根据公认的答案,一个简单的并行化得到了足够的改进,这个操作不再是最关键的时间

为了将来参考,这个:

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 个线程的转储!

于 2021-06-21T21:34:04.990 回答