Как правильно «соединить» два узла графа в gremlin? - PullRequest
Новая
       4

Как правильно «соединить» два узла графа в gremlin?

0 голосов
/ 28 февраля 2020

Предположим, у меня есть график, похожий на приведенный ниже 

graph = TinkerGraph.open()
g = graph.traversal()
v1 = g.addV('CC').property('name','t1')
v2 = g.addV('KK').property('name','t1')

Я хочу найти все CC, которые имеют такие же 'name', что и KK. Я могу написать: 

g.V().hasLabel('CC').as('c').values('name').as('cn').V().hasLabel('KK').values('name').as('k').where('cn',eq('k')).select('c')

Это имитирует объединение в SQL, но запись, поэтому производительность кажется очень плохой. Начиная с SQL2Gremlin , у них есть пример «соединения» двух узлов, если между двумя есть ребро. Мне было интересно, есть ли какой-нибудь подход к объединению в gremlin, что существует ли путь, соединяющий два узла, заранее неизвестно? Другими словами, каков наилучший подход для написания «соединения» в gremlin, и мы не знаем, связаны ли такие два узла напрямую или через путь?

Большое спасибо!

1 Ответ

0 голосов
/ 28 февраля 2020

Ваша интуиция в значительной степени права. «Соединение» - это реализованное отношение (то есть ребро) между двумя вершинами. Как правило, это выигрыш в базе данных графа. Выполнение соединений вершин к вершинам для свойств в стиле SQL обычно неэффективно для графа.

Что касается вашего запроса, вы можете переписать его в этой форме для большей ясности: 

gremlin> g.V().hasLabel('CC').as('c').
......1>   V().hasLabel('KK').
......2>   where(eq('c')).
......3>     by('name').
......4>   select('c')
==>v[0]

, однако производительность, скорее всего, останется такой же, как я не думаю, что какой-либо график Система в настоящее время оптимизирует этот обход. Индекс не будет использоваться, и вам будут предоставлены полные сканы графиков "CC" и "KK", чтобы получить ваши результаты. Очевидно, что это очень дорого на большом графике.

Об этом topi c было что-то обсуждено в списке рассылки пользователей Gremlin здесь , где было высказано несколько приятных замечаний. Следует отметить, что Джо sh Перриман писал (среди прочих приятных замечаний):

* * * * * * * * * * * * * * * * * * * * * * * * * * В стиле соединения очень плохое использование движка Graph DB. Как Даниэль предлагает, чтобы соединения были предварительно вычислены, а ребра добавлены во время записи / данных, я шучу.

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

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

...