cassandra - Janusgraph SimplePath 查询在 6 节点与 3 节点 Cassandra 集群上较慢

Question

我目前正在使用 Janusgraph 0.5.2 版。我有一个大约有 1800 万个顶点和 2500 万条边的图。

我有这个图的两个版本，一个由 3 节点 Cassandra 集群支持，另一个由 6 个 Cassandra 节点支持（都具有 3 倍复制因子）

我对它们都运行以下查询：

g.V().hasLabel('label_A').has('some_id', 123).has('data.name', 'value1').repeat(both('sample_edge').simplePath()).until(has('data.name', 'value2')).path().by('data.name').next()

问题是这个查询在 3 节点集群上需要 ~130 毫秒，而在6 节点集群上需要~400 毫秒。

我已经对大约十个查询进行了基准测试，这是唯一一个两个集群之间的性能存在显着差异的查询。

我已经尝试.profile()在这两个版本上运行，并且输出在步骤和所用时间方面几乎相同：

g.V().hasLabel('label_A').has('some_id', 123).has('data.name', 'value1').repeat(both('sample_edge').simplePath()).until(has('data.name', 'value2')).path().by('data.name').limit(1).profile()

==>Traversal Metrics
Step                                                               Count  Traversers       Time (ms)    % Dur
=============================================================================================================
JanusGraphStep([],[~label.eq(label_A), o...                     1           1           4.582     0.39
    \_condition=(~label = label_A AND some_id = 123 AND data.name = value1)
    \_orders=[]
    \_isFitted=true
    \_isOrdered=true
    \_query=multiKSQ[1]@8000
    \_index=someVertexByNameComposite
  optimization                                                                                 0.028
  optimization                                                                                 0.907
  backend-query                                                        1                       3.012
    \_query=someVertexByNameComposite:multiKSQ[1]@8000
    \_limit=8000
RepeatStep([JanusGraphVertexStep(BOTH,[...                     2           2        1167.493    99.45
  HasStep([data.name.eq(...                                                          803.247
  JanusGraphVertexStep(BOTH,[...                           12934       12934         334.095
    \_condition=type[sample_edge]
    \_orders=[]
    \_isFitted=true
    \_isOrdered=true
    \_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812d311c
    \_multi=true
    \_vertices=264
    optimization                                                                               0.073
    backend-query                                                    266                       5.640
    \_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812d311c
    optimization                                                                               0.028
    backend-query                                                  12689                     312.544
    \_query=org.janusgraph.diskstorage.keycolumnvalue.SliceQuery@812d311c
  PathFilterStep(simple)                                           12441       12441          10.980
  JanusGraphMultiQueryStep(RepeatEndStep)                           1187        1187          11.825
  RepeatEndStep                                                        2           2         810.468
RangeGlobalStep(0,1)                                                   1           1           0.419     0.04
PathStep([value(data.name)])                                 1           1           1.474     0.13
                                            >TOTAL                     -           -        1173.969        -

注意：您可能已经注意到上面的配置文件步骤显示了 > 1000 毫秒的时间。我相信这是另一个与这篇文章无关的问题。

其他一些可能有用的点：

• 3 节点和 6 节点集群在硬件方面是相同的
• 我们没有在嵌入式模式下运行 Janusgraph（它与 Cassandra 位于同一位置），而是在自己的服务器节点上单独运行
• 如前所述，仅在path查询中观察到缓慢。例如，这是另一个遍历查询的示例，我们在其中观察到 3 和 6 节点集群的相同延迟： g.V().hasLabel('label_B').has('some_id', 123).has('data.name', 1234567).both('sample_edge').valueMap('data.field1', 'data.field2').next(10)

我真的很感激任何关于弄清楚为什么查询在 6 个节点上慢 3 倍的输入。

很高兴根据需要提供更多信息！

谢谢！

标签： cassandragremlingraph-databasestinkerpopjanusgraph