Гремлин и индексы

В последнее время я использую индексы и заметил, что если я сделаю индексированный ключ на dmdid, следующий запрос будет быстрым:

graph.query().has("firstname", "Joan").has("lastname", "Dupont").vertices()

Это тоже быстро:

new GremlinPipeline(graph.getVertices("firstname", "Joan")).has("lastname", "Dupont").cast(classOf[Vertex]).toList()

Но этот медленный, как будто у меня нет индексации:

new GremlinPipeline(graph.getVertices()).has("firstname", "Joan").has("lastname", "Dupont").cast(classOf[Vertex]).toList()

Я думаю, что мой вопрос разделен на 2 части (или 3):

  • Во-первых, кажется невозможным оптимизировать запрос начальных вершин, если мне нужно фильтровать по 2 индексированным ключам (здесь имя и фамилия)?
  • Во-вторых, кажется, не работает возможность оптимизировать обход графика с помощью конвейеров?
  • Две первые концепции кажутся полностью разделенными, хотя, похоже, они сталкиваются с одной и той же проблемой. Для меня получение всех вершин и фильтрация по ним (последний пример) должны быть такими же, как и первые 2, потому что запрос выполняется в БД, вам так не кажется?

gremlin graph-databases
person Joan    schedule 09.06.2014    source источник

Ответы (1)


arrow_upward
2
arrow_downward

Не думаю, что ваш последний запрос поддержит оптимизацию. Разбираем ваш запрос:

new GremlinPipeline(graph.getVertices()).has("dmdid", id).has("type", type).cast(classOf[Vertex]).toList()

Вы загружаете все вершины графа в конвейер, который затем перебирает их в has, где находится ваш индекс. Таким образом, остальная часть конвейера, начинающаяся с этого has, рассматривает его как линейное сканирование. Гремлин не может правильно скомпилировать запрос, так как не знает всего.

То, что вы можете делать с индексами, очень сильно зависит от нижележащего графа. Реализация графа многое говорит о том, как будет происходить оптимизация. Касательно,

Во-первых, возможность оптимизировать запрос начальных вершин кажется невозможной, если мне нужно фильтровать по 2 индексированным ключам (здесь имя и фамилия)?

Получив «начальные вершины» с индексом ключа в смысле Blueprints, обобщенный подход будет заключаться в создании составного ключа, объединяющего имя и фамилию в одно свойство. Касательно,

Во-вторых, кажется, не работает возможность оптимизировать обход графа через конвейеры?

Вы не говорите, какую базу данных графов вы используете, но не все графы поддерживают передачу has операций в базу данных. Titan наилучшим образом использует такие возможности и будет использовать преимущества вершинно-ориентированных индексов. везде, где они встречаются в выражении gremlin. Касательно:

Две первые концепции кажутся полностью разделенными, хотя, похоже, они сталкиваются с одной и той же проблемой. Для меня получение всех вершин и фильтрация по ним (последний пример) должны быть такими же, как и первые 2, потому что запрос выполняется в БД, вам так не кажется?

Как вы, вероятно, поняли из моего предыдущего утверждения, ваш запрос не выполняется в БД. Gremlin не компилируется в какое-то выражение, которое каждая база данных графов понимает и может оптимизировать. Gremlin - отличный код, работающий через Blueprints. Некоторые графические базы данных (например, Titan и OrientDB в некоторой степени) способны оптимизировать обходы на основе их реализации. Как я упоминал выше, Titan будет использовать индексы, ориентированные на вершины, где это возможно, чтобы ограничить, какие данные обрабатываются в памяти Gremlin. Такая оптимизация может привести к хорошему повышению производительности. .

person stephen mallette    schedule 10.06.2014
comment
Итак, если мы предположим то, что вы говорите, это означает, что индексы используются ТОЛЬКО для одного ключа для поиска точки входа, а индексы НЕ используются в любое время при перемещении по графику? Это кажется невозможным для использования на больших графиках. - person Joan; 10.06.2014
comment
Я думаю, здесь есть две темы; 1-й - должен ли ваш последний запрос поддерживать оптимизацию. Второе - это более общее утверждение, что, если у нас есть начальная точка для запроса, нам все еще нужно иметь возможность использовать индекс для перемещения по графику (вместо того, чтобы переходить по ссылкам на другие точки на графике). Правильно ли у меня вторая часть? Если да, то каков вариант использования? Вы ожидаете найти только одну вершину с помощью точного совпадения или ищете коллекцию элементов? Это что-то, что нужно связать вместо этого? Спасибо. (Я думал, что можно использовать канал idx.) - person Paul Jackson; 10.06.2014
comment
Вы правы, @Paul Jackson. Я отредактировал свой вопрос, чтобы разбить его на некоторые моменты, как вы указали. Мои вопросы общие о том, как это работает (получение точной вершины или коллекции). idx - для ручных индексов. Я использую автоматические индексы. - person Joan; 10.06.2014
comment
я обновил свой ответ. вы не сказали, какую базу данных графов вы использовали, но я думаю, что мой ответ в целом применим. - person stephen mallette; 10.06.2014
comment
Я бы также добавил, что у titan есть дополнительные возможности для создания составных индексов за счет интеграции с внешними механизмами индексирования: github.com/thinkaurelius/titan/wiki/Indexing-Backend-Overview для возврата больших наборов вершин, это может быть полезным подходом, если Titan - ваша база данных. - person stephen mallette; 10.06.2014
comment
Значит, вы имеете в виду, что каждый раз, когда я обновляю свойство помимо составного, мне придется обновлять также составной индекс? Или есть какие-то настройки для автоматического ведения сводных индексов? Потому что запрос оптимизирован только по первому индексу в моих тестах (независимо от того, проиндексирован второй или нет) - person Joan; 10.06.2014
comment
Да, при таком подходе вы должны вручную поддерживать свой составной индекс, чтобы вы обновляли это свойство fullName всякий раз, когда изменялись свойства имени или фамилии. - person stephen mallette; 10.06.2014
comment
Я могу ошибаться, но я не думаю, что какие-либо графики поддерживают настоящий составной индекс так же, как реляционные базы данных. Я только что быстро проверил основные графические базы данных, в которых есть реализации Blueprints, и нигде не видел этой функциональности. Я думаю, что этот шаблон ручного поддержания составного свойства довольно распространен. - person stephen mallette; 10.06.2014
comment
Это утомительно ... Надеюсь, мы увидим функцию автоматической оптимизации, которую мы можем активировать, как автоматическое индексирование в Titan. - person Joan; 10.06.2014
comment
Если вам действительно не нравится идея делать это вручную, уловка будет заключаться в создании пользовательского Blueprint WrapperGraph (примерами других оболочек могут быть ReadOnlyGraph, PartitionGraph и т. Д.), Который обнаруживает изменения свойств, связанных с составными ключами, а затем автоматизирует обновление составных ключей. сам ключ. Это, вероятно, было бы несложно реализовать. По крайней мере, тогда ваша логика для индексов будет скрыта и централизована в одном месте. - person stephen mallette; 10.06.2014
comment
Это хорошая идея. Таким образом, я бы сделал вывод, что есть решения, но все еще есть улучшения, которые можно сделать, особенно в операторах has() после getVertices(), которые следует оптимизировать. И некоторые автокомпозитные индексы. Если я прав. - person Joan; 10.06.2014
comment
Titan 0.5.x поддерживает составные индексы - groups.google.com/forum/#! topic / aureliusgraphs / cNb4fKoe95M - person stephen mallette; 16.06.2014