Гремлин коррелированные запросы снижают производительность

Question

Я понимаю, что в этом вопросе учитывается специфика реализации, но я также понимаю, что, возможно, я что-то здесь не так делаю. Если так, что я мог сделать лучше? Если у Gremlin есть пакетная функция отправки запросов с несколькими результатами, о которой я не знаю, это решит проблему. Например, Гремлин, запустите эти три запроса параллельно и дайте мне их результаты.

По сути, мне нужно знать, когда у вершины есть определенное ребро, и если у него нет этого ребра, мне нужновытащить пробел. Итак ...

g.V().as("v").coalesce(outE("someLabel").has("someProperty","someValue"),constant()).as("e").select("v","e")

Этот запрос 10x дороже, чем просто получение краев с помощью:

g.V().outE("someLabel").has("someProperty","someValue")

Так что, если я хочу получить наборвершины с их ребрами или пустые заполнители, у меня есть два варианта: сделать два дискретных запроса и «объединить» данные в API или сделать один очень дорогой запрос.

Я работаю с предположением, что в Gremlin,мы " делаем это за одну поездку ", и это на самом деле может быть совершенно неверным. Тем не менее, я также знаю, что извлечение фрагментов данных и эффективное объединение в API - плохая практика, потому что это нарушает принцип инкапсуляции. Это также добавляет накладные расходы туда и обратно.

Answer 1

Ваш исходный запрос вернул пары вершин-ребер, где в качестве вашего ответа возвращаются только ребра.

Вы можете просто запустить g.E().hasLabel("somelabel"), чтобы получить тот же результат.

Возможно, более быстрой альтернативой вашему исходному запросу может быть:

g.E().hasLabel("somelabel").as("e").outV().as("v").select("v","e")

или

g.V().as("v").outE("somelabel").as("e").select("v","e")

Answer 2

Если в Gremlin есть несколько пакетных функций для отправки запросов, о которых я не знаю, это решит проблему

В Gremlin / TinkerPop такой встроенной функции нет. по крайней мере один график, который имеет некоторую форму пакетирования Gremlin - DataStax Graph ... не уверен насчет других.

Я также не уверен, что у меня действительно есть какой-либо ответ, который может оказаться полезным, но пока яЯ не ожидал бы, что разница в производительности между этими двумя обходами будет в 10 раз выше, я ожидаю, что первая будет работать хуже в большинстве графовых баз данных. По сути, использование именованных шагов с as() включает требования расчета пути при обходе, что увеличивает затраты. При оптимизации Gremlin, один из моих первых шагов - попытаться найти способы выделить что-то, что может сделать это.

Этот вопрос, похоже, связан с вашим другим вопросом по Jagged Result Array , но у меня возникают проблемы с поддержанием контекста из одного вопроса в другой, чтобы понять, как его изложить дальше.

Answer 3

ОК, поэтому я нашел решение, которое смешно, но быстро. Это включает в себя фальсификацию обхода, поэтому позвольте мне заранее извиниться, если есть лучший способ ...

g.inject(true).
union(
  __.V().not(outE("someLabel")).constant().as("ridiculous"),
  __.V().outE("someLabel").as("ridiculous")
).
select("ridiculous")

По сути, я должен написать запрос дважды. Один раз для обхода с краем, который я хочу, и еще раз для обхода, где край отсутствует. Таким образом, если у меня есть n представленных / отсутствующих проверок, мне понадобится 2 ^ n копий запроса, каждая из которых будет иметь свою собственную комбинацию проверок, чтобы получить наиболее оптимальную производительность. К сожалению, такой подход может привести к переполнению стека, не говоря уже о невозможности надежного управления кодом.