janusgraph simplepath查询在6节点和3节点cassandra集群上比较慢

zhte4eai  于 2021-06-09  发布在  Cassandra
关注(0)|答案(0)|浏览(283)

我目前正在使用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节点集群上需要约130ms,而在6节点集群上需要约400ms。
我已经对大约10个查询进行了基准测试,这是两个集群之间性能有显著差异的唯一一个查询。
我试过跑步 .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        -

注意:你可能已经注意到上面的配置文件步骤显示的时间大于1000ms。我相信这是另一个与本文无关的问题。
其他一些可能有用的观点:
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倍的输入。
很高兴按要求提供更多信息!
谢谢您!

暂无答案!

目前还没有任何答案,快来回答吧!

相关问题