graph.traversal().V(vertexId).drop().iterate() 删除此顶点，但这需要很长时间（无法在 20 分钟内删除）。我想知道是否有人遇到过类似的问题并想出任何解决方法。任何线索都会非常有帮助。
【问题讨论】：
标签： database graph janusgraph
我的信息可能已经过时了，也许有修改过的方法可以做到这一点，但由于这个问题没有得到任何答复，我想我会提供我所知道的建议。在 JanusGraph 之前的日子里，当这个图被称为 Titan 时，我遇到了像你描述的那样的情况，我发现了类似的结果，你在直接 g.V(id).drop() 时发现了类似的结果，并且完全摆脱那个大小的顶点意味着拥有一些耐心。我用来摆脱它的策略涉及修剪其边缘的顶点，以便删除顶点本身成为可能。
如何修剪边缘取决于您的数据以及这 5M 边缘的组成方式。它可以很简单，比如按标签或一次在每个标签内按 10000 个块或其他有意义的方法将过程分解成块。
while(g.V(vertexId).outE('knows').limit(1).hasNext()) {
g.V(vertexId).outE('knows').limit(10000).drop().iterate();
}
我想我记得我能够并行运行这些类型的操作，这稍微加快了进程。在任何情况下，当您得到所有边的顶点（或至少减小到明显更小的度数大小）时，您就可以g.V(vertexId).drop() 和它说再见了。
我没有使用 ScyllaDB，但我想我记得这么多的删除可能会为 Cassandra 造成墓碑类型的问题，因此值得关注。您还可以考虑增加在此过程中可能发挥作用的各种超时。
对我来说，多年来我在这个问题上学到的教训是构建基于 OLAP 的监控器来跟踪图表统计信息，以确保您在图表中获得适当和预期的增长（即学位分布、标签分布、 ETC）。这对于从 Kafka 等大容量流中提供的图表尤其重要，您可以在其中转过头几个小时，然后回来发现您的图表处于丑陋的意外状态。我认为以解决进入这些超级节点状态的可能性的方式进行建模也很重要。在许多情况下，边缘 TTL 和单向边缘可以帮助解决这个问题。
我很想听到这个答案不再相关，并且有巧妙的新方法来做这些类型的下降，或者有一些 ScyllaDB 特定的方法来处理这个问题，但是，如果没有，也许这将是对您有用并帮助您解决问题。
【讨论】：