Я надеюсь услышать от любого из вас, кто проектировал и реализовал приложение Neo4j с приличным размером (10 миллионов узлов /rels ), и какие ваши рекомендации особенно подходят для моделирования и различных API (vanilla java/ groovy Neo4j vs Spring -Data-Neo4j vs Grails GORM/Neo4j).
Мне интересно, действительно ли он рассчитывает добавить дополнительный слой OGM (сопоставление объекта-графика) и связанные с ним абстракции?
Имеет ли кто-нибудь опыт, что лучше всего придерживаться "простого" графического моделирования с узлами + свойствами, отношениями + свойствами, обходами и (например,) Cypher для моделирования и хранения своих данных?
Я обеспокоен тем, что "принудительное" выделение OGM в базе данных графиков повлияет на будущую гибкость при адаптации/изменении модели домена и/или гибкости при запросе данных.
Мы магазин Grails, и я экспериментировал с GORM/Neo4J, а также с Spring -data-neo4j.
Основная цель набора данных - моделировать и запрашивать отношения между широкими числами людей, их псевдонимами, их сотрудниками и всеми видами преступной деятельности и истории. Будет более 50 основных классов домена. В модели должна быть гибкость (которая должна быстро развиваться на ранних этапах проекта), а также в скорости и гибкости запросов.
Я должен признаться, я изо всех сил стараюсь найти вескую причину использовать слой OGM, когда я могу использовать (например) POJO или POGO, немного волшебства Groovy и некоторый простой ручной объект домена ↔ node/код сопоставления отношений. Насколько я могу судить, я думаю, что я был бы счастлив, просто имея дело с узлами и обходами и Cypher (иначе KISS). Но я был бы очень рад услышать опыт и рекомендации других людей.
Спасибо за ваше время и мысли,
ТР