Neo4j super node проблема - разворачивание шаблона

Ответ 1

Это хороший вопрос. На самом деле это не ответ, но почему бы нам не обсудить это здесь? Технически я думаю, что я должен обозначить ваш вопрос как "основанный прежде всего на мнениях", поскольку вы явно запрашиваете мнения, но я думаю, что это стоит обсуждения.

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

Суперноды - проблемы и в других областях. Графические базы данных иногда очень сложно масштабировать в некотором роде, потому что данные в них трудно разбить. Если бы это была реляционная база данных, мы могли бы разбиться по вертикали или по горизонтали. В графе DB, когда у вас есть суперноды, все "близко" ко всему остальному. (Аляскинский фермер любит Леди Гагу, а также нью-йоркский банкир). Moreso, чем просто скорость перемещения по графу, суперноды - большая проблема для всех видов масштабируемости.

Предложение Рика сводится к тому, чтобы побудить вас создать "подкластеры" или "разделы" супер- node. Для некоторых шаблонов запросов это может быть хорошей идеей, и я не отказываюсь от этой идеи, но я думаю, что скрытое здесь понятие кластерной стратегии. Сколько мета-узлов вы назначаете? Сколько максимальных ссылок на meta- node? Как вы решили назначить этого пользователя этой метатеге node (а не какой-либо другой)? В зависимости от ваших запросов эти вопросы будут очень трудно ответить, их сложно реализовать правильно или и того и другого.

Другой (но концептуально очень похожий) подход заключается в том, чтобы клонировать Леди Гага около тысячи раз, дублировать ее данные и синхронизировать их между узлами, а затем утверждать кучу "то же, что" отношения между клонами. Это не то, что отличается от подхода "мета", но оно имеет то преимущество, что оно копирует данные Lady Gaga в клон, а "Meta" node - это не просто тупик для навигации. Большинство из тех же проблем применяются, хотя.

Здесь другое предложение: у вас есть проблема с отображением большого числа множителей. Возможно, если это для вас действительно большая проблема, вам лучше разобраться с ней в одной реляционной таблице с двумя столбцами (from_id, to_id), каждый из которых ссылается на идентификатор neo4j node. Тогда у вас может быть гибридная система, в основном графическая (но с некоторыми исключениями). Здесь много компромиссов; конечно, вы не могли бы пройти это переключение в cypher вообще, но оно масштабировалось бы и разбилось бы намного лучше, и запросы на конкретный rel, вероятно, были бы намного быстрее.

Одно общее наблюдение здесь: обсуждаем ли мы реляционные, графические, документы, базы данных K/V или что-то еще - когда базы данных становятся действительно большими, а требования к производительности становятся очень интенсивными, почти неизбежно, что люди заканчивают с каким-то гибридным решением с более чем одним видом СУБД. Это из-за неизбежной реальности, что все базы данных хороши в некоторых вещах, а не хороши для других. Поэтому, если вам нужна система, которая подходит максимум, вам придется использовать несколько баз данных.:)

Скорее всего, в этих случаях можно оптимизировать neo4j для оптимизации, но мне кажется, что системе понадобится несколько советов по шаблонам доступа, чтобы сделать действительно хорошую работу. Из присутствующих 2 000 000 отношений, как конечным точкам лучше всего кластер? Старые отношения важнее, чем новые, или наоборот?

Ответ 2

Re. блог Neo4j, плотная поддержка node должна быть улучшена в Neo4j 2.1 (и выше), см. также http://neo4j.com/blog/neo4j-2-1-graph-etl/

Ответ 3

(отказ от ответственности: не ответ, но некоторое обсуждение)

В блоге neo4j в 2013 году вы упомянули ссылки на github commit, где обсуждалась предполагаемая область проблемы и ее решение. Подводя итог, он не затрагивает общую проблему supernode. Вместо этого он устраняет проблему, когда среди нескольких типов отношений (и направлений), которые имеет supernode, некоторые типы (направления) имеют несоразмерно меньшее количество ребер, чем другие. Двигатель может фильтровать на основе типов и направлений.

Более общим решением является подход vertex centric от Titan (fooobar.com/info/251071/...), который сортирует ребра по одному или составному из свойств, приводит к O (log (E)), где E - количество ребер в/из supernode.

Neo4j имеет понятие индекса отношений. В отличие от подхода vertex centric Титана, индекс глобальный. Однако индекс отношений является устаревшим в Neo4j. Это обсуждается в другом потоке fooobar.com/info/251073/....

Другая проблема с supernode - проблема хранения, которая приводит к проблеме хранения и стоимости ввода-вывода.