Titan vertex centric indices vs Neo4j labels

Question

Я пытался сравнить эти две технологии при приближении к этому, и мне было интересно, есть ли у кого-нибудь из вас опыт работы с любым или обоими из них? В основном меня интересуют показатели производительности при работе с аналогичными вариантами использования.

Answer 1

соглашаясь со всем, что Марко сказал, можно было бы принять его дальше и утверждают, что в мире граф базы данных локальных индексов можно (и даже нужно) заменить глобальные. На мой взгляд, единственным преимуществом модели данных графа является то, что он позволяет кодировать вашу модель данных в топологию графа, получая качественные преимущества с точки зрения гибкости, простоты эволюции и производительности. Имея это в виду, я бы сказал, что ярлыки в Neo4j фактически умаляют все это; воссоздание метки в узел со смежными ребрами, указывающими на источник, имеющий эту метку, намного больше соответствует философии «схема является графиком».

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

v -[L]-> L

означает, что v имеет метку L. Теперь, если вы хотите, чтобы это в Титане вел себя как лейбл Neo4j, просто сделайте отношение -[L]-> «многоголовым» (см. Titan cardinality constraints) и создайте индекс, ориентированный по вершине. Этот шаблон позволяет получить все, что вы могли бы с помощью ярлыков и многое другое; Вы можете

• эффективно использовать это в качестве пространства имен для свойств, связанных с этим ярлыком
• рода ваши элементы внутри одной этикетки
• гнездо этикетки легко и без потери производительности (просто использовать составной ключ)
• отделят декларирование метки L с доступом к элементам с надписью

Answer 2

Разница между двумя концепциями заключается в различии между глобальным и локальным индексированием.

Как я понимаю, Neo4j Этикетки вершин позволяют разбивать ваше индексное пространство на «категории» вершин. Таким образом, поиск O(log(|V|)) теперь равен O(log(|V|/c)), где c - количество категорий/меток, которые у вас есть над вашим набором вершин, и (уравнение) принимает равное количество вершин в каждой категории. Таким образом, поддержка вершинной метки в глобальных индексах называется функцией V.

Далее, Титановые точечные индексы Titan сортируют и индексируют края инцидентности вершины. Стоимость поиска конкретного ребра по его метке/свойствам, зависящим от вершины, равна O(log(inc(v))), где inc(v) - размер края инцидента, установленного на вершину v. Таким образом, индексы, ориентированные по вершинам, являются локальными индексами, так как это функция от v.

Как я понимаю, Neo4j не поддерживает индексы с вершинами. Вы видите эту концепцию в настоящее время в Titan, OrientDB, и TinkerGraph (... и RDF хранят сортировку таким же образом, как и через споганные пары). Далее, все известные базы данных графов поддерживают глобальные индексы, хотя (я считаю, что только Neo4j и OrientDB), поддерживают раздел набора вершин через концепцию метки.

Опять же, если предположить, что мои предположения верны относительно использования вершинных меток в Neo4j, мы говорим о двух разных вариантах использования - глобальном или локальном индексировании. С точки зрения проблемы супернода глобальные индексы не подавляют проблему прохождения через большую вершину, в то время как это единственная цель локальных индексов с вершинами.

Вы можете прочитать о проблеме supernode и вершинных ориентированных индексов здесь:
http://thinkaurelius.com/2012/10/25/a-solution-to-the-supernode-problem/

Answer 3

Наклейки могут позволить себе некоторые образцы дизайна, которые улучшают производительность за счет де-модифицирующим график. Например: они устраняют необходимость в узлах типа, которые часто могут быть довольно плотными. Ярлыки могут быть необязательно связаны с уникальным индексом. Здесь способность индексировать свойство не нова, но способность ограничить его однозначно. Если вы ранее выполняли работу в своем приложении, вы можете столкнуться с некоторой прирост производительности, позволив базе данных справиться с этим. (Это, безусловно, гораздо удобнее.) Наконец, если вы не присвоите уникальный ярлык ярлыку, он все равно будет проиндексирован, чтобы помочь производительности для определенных типов запросов (например, «дайте мне все узлы с меткой ")

Все сказанное, в то время как ярлыки могут помочь с исполнением в определенных случаях, они были введены с большей простотой в использовании. Мы только начинаем с Neo4j 2.1, который специально учитывает производительность плотных узлов (что-то, что я знаю, чего вы ждали), наряду с другими улучшениями масштабирования производительности & ... включая удаление (для устранения практически всех целей) верхнего размера пределы.

Филипп