Архитектура приложения на основе Neo4j - придерживайтесь API ванили с использованием простых узлов и связей или используйте Spring/GORM?

Question

Я надеюсь услышать от любого из вас, кто архивировал и реализовал приложение Neo4j с приличным размером (10 миллионов узлов/rels) - и ваши рекомендации особенно подходят для моделирования и различных API (ванильный java/groovy Neo4j vs Spring -Data-Neo4j против Grails GORM/Neo4j).

Мне интересно, если он действительно окупается, чтобы добавить дополнительный OGM (объект-граф-сопоставление) и связанные с ним абстракции?

Имеет ли кто-либо опыт, что лучше придерживаться «простого» графического моделирования с помощью узлов + свойств, отношений + свойств, обходов и (например,) Cypher для моделирования и хранения своих данных?

Мое беспокойство заключается в том, что «принудительное» выделение OGM в базе данных графа повлияет на будущую гибкость при адаптации/изменении модели домена и/или гибкости при запросе данных.

Мы магазин Grails, и я экспериментировал с GORM/Neo4J, а также с spring-data-neo4j.

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

Должен признаться, я изо всех сил пытаюсь найти вескую причину использовать слой OGM, когда я могу использовать (например) POJO или POGO, небольшую магию Groovy и некоторый простой ручной объект домена < -> node/отношения. Насколько я могу судить, я думаю, я был бы счастлив, просто имея дело с узлами & обходов & Cypher (aka KISS). Но я был бы очень рад услышать опыт и рекомендации других людей.

Спасибо за ваше время & мысли,

TP

Answer 1

, так как я являюсь автором плагина Grails Neo4j, я мог бы быть неточными. Основной причиной создания плагина было использование легкости классов домена Grails с их мощными готовыми строительными блоками до Neo4j для ~ 80% случаев использования. Для других 20%, где для конкретных требований требуются такие вещи, как обход и т. Д., Мы используем API-интерфейс Neo4j напрямую (traversals/cypher) и не используем API GORM.

Текущая версия плагина Neo4j страдает от проблемы супернода, поскольку каждый экземпляр домена подключен к узлу подреференции. Если несколько параллельных запросов (aka threads) добавляют новые экземпляры домена, есть шанс получить исключение блокировки. Я собираюсь исправить это либо подпоследовательным подходом, либо с помощью индексации.

Cypher также может использоваться в плагине Neo4j Grails.

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

Мы используем предшествующую версию плагина в продуктивном приложении с ~ 60k пользователями и ~ 10^6 rels. Из-за NDA я не могу предоставить более подробную информацию об этом.

Answer 2

Мы не используем grails, но используем гибридное решение neo4j/spring-data-neo4j.Причина основана на том факте, что некоторые данные нашего домена имеют фиксированную схему, а некоторые нет. SDN отнимает много бремени и может быть смешано с простым neo4j, если возникнет такая необходимость.

У нас есть классы, которые описывают модель данных, объекты для этих классов, которые мы сохраняем с использованием SDN, без дополнительных трюков, мы просто используем основы SDN. Затем мы имеем классы, которые содержат данные для модели, которая не известна заранее. Они хранятся в узлах, содержат специальные свойства для описания того типа модели, к которому относятся данные. Когда neo4j 2 будет выпущен, мы, вероятно, переместим эту информацию в метки. Между этими узлами могут быть отношения, также описанные вышеупомянутой моделью данных, управляемой sdn. Мы также имеем отношения от общих узлов к узлам SDN, которые прекрасно работают, поскольку все заканчивается тем же: узлы.

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