#cassandra #gremlin #graph-databases #tinkerpop #janusgraph
#cassandra #gremlin #графические базы данных #tinkerpop #janusgraph
Вопрос:
В настоящее время я использую Janusgraph версии 0.5.2. У меня есть график с примерно 18 миллионами вершин и 25 миллионами ребер.
У меня есть две версии этого графика, одна из которых поддерживается 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()
Проблема в том, что этот запрос занимает ~ 130 мс для кластера с 3 узлами, тогда как для кластера с 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)
Я был бы очень признателен за любую информацию о том, почему запрос выполняется в 3 раза медленнее на 6 узлах.
Рад предоставить дополнительную информацию по мере необходимости!
Спасибо!