Neo4j вместо реляционной базы данных

Question

Я реализую веб-портал, основанный на синатре/рельсах, который, возможно, в конечном итоге может содержать несколько: много связей между таблицами/моделями. Это команда одного человека и неполный рабочий день, но приложение для реального мира.

Я обсуждал свое сущность с кем-то и посоветовал попробовать neo4j. Исходя из настоящего «несексуального» корпоративного мира, моя склонность - использовать реляционный db, пока он не перестанет масштабироваться или не станет кошмаром из-за осколков и т. Д., А затем подумайте о чем-нибудь еще.

ОДНАКО

• Я использую Postgres впервые в этом проекте вместе с DataMapper и его берет меня время, чтобы начать очень быстро
• Я просто попробовать несколько вещей, и строить больше пользы поэтому я должен обновить свою схему (идея прототипирования и отзывы от бета-версии). Я не буду делать это в neo4j (кроме изменения моих запросов)
• Кажется, что его очень легко настроить, используя neo4j. Но Postgres также может выполнять полный текстовый поиск.
• Postgres недавно объявила о поддержке json и javascript. Удивление, если я должен просто придерживаться PG и инвестировать больше времени на изучение PG (у которого есть хорошее сообщество) вместо neo4j.

Ищем для нас, где neo4j лучше, особенно при пропинге/начальной стадии проекта. Я понимаю, что если сайт растет, я могу в конечном итоге иметь несколько постоянных технологий, таких как s3, реляционный (PG), mongo и т. Д.

Также было бы хорошо знать, как это происходит с экосистемой Rails/Ruby.

---

Update1:

Я получил много хороших ответов и, кажется, как правильно сделать, это палка с Postgres сейчас (особенно, так как я развернуть на Heroku)

Однако идея отсутствие схемы - заманчиво. В основном я подумываю о подходе, когда вы не определяете datamodel, пока не скажете 100-150 пользователей, и вы сами разобрались в хорошей схеме (бизнес-кейсах) для своего продукта, в то время как вы просто демонстрируете концепцию и получаете обратная связь с ограниченными регистрациями. Тогда можно решить схему и начать с реляционной.

Было бы неплохо знать, если есть простой в использовании схемы/меньше параметр сохраняемости (основанный на простоте использования/установки для нового пользователя), которые могут отказаться сказать масштабирование и т.д.

Answer 1

Graph базы данных следует учитывать, если у вас действительно хаотичная модель данных. Они необходимы для выражения очень сложных отношений между сущностями. Для этого они сохраняют отношения на уровне данных, тогда как СУРБД используют декларативный подход. Сохранение отношений имеет смысл только в том случае, если эти отношения очень разные, иначе вы просто будете дублировать данные снова и снова, занимая много места ни для чего. Чтобы требовать такого разнообразия во взаимоотношениях, вам придется обрабатывать огромное количество данных. Это то, где графические базы данных светят, потому что инстант делает тонны объединений, они просто выбирают запись и следуют его отношениям. Чтобы поддержать мое заявление: вы заметите, что каждый use cases на веб-сайте Neo4j имеет дело с очень сложными данными.

Вкратце, если вы не чувствуете себя обеспокоенным тем, что я сказал выше, я думаю, вы должны использовать другую технологию.Если это касается масштабирования, схематизации или быстрого запуска проекта, посмотрите другие решения NoSQL (более конкретно, базы данных, основанные на столбцах или документах). В противном случае вы должны придерживаться PostgreSQL. Вы также можете, как и вы сказали, рассмотреть polyglot persistence,

О своем обновлении, вы можете рассмотреть hStore. Я думаю, это соответствует вашим требованиям. Это модуль PostgreSQL, который также работает на Heroku.

Answer 2

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

Если у вас нет прежнего опыта работы с Neo4j или Postgres, то, скорее всего, оба они займут довольно много времени, чтобы хорошо учиться.

Некоторые вещи, чтобы иметь в виду при выборе:

1. Это не только о развитии против технологии баз данных. Вы также должны рассмотреть возможность развертывания. Насколько легко развертывать и масштабировать Postgres/Neo4j?

2. Рассмотрите сообщество и инструменты вокруг каждой технологии. Является ли сборщик данных для Neo4j похожим на Postgres?

3. Учитывайте, что модели данных значительно разные между двумя. Если вы уже можете думать реляционно, то я, вероятно, придерживаюсь Postgres. Если вы поедете с Neo4j, вы будете совершать много ошибок в течение нескольких месяцев с вашими моделями данных.

4. Со временем я научился сохранять его простым, когда смогу. Postgres может быть скучным выбором по сравнению с Neo4j, но скучно не держать вас в ночное время. =)

Кроме того, я никогда не видел никого говорить, но вы должны смотреть на Riak (http://basho.com/riak/) тоже. Это база данных документов, которая также обеспечивает отношения (ссылки) между объектами. Не так зрелый, как база данных графа, но он может быстро подключить несколько объектов.

Answer 3

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

Если у вас всего несколько таблиц много-много, реляционная база данных может быть прекрасной. В общем, существует лучшая поддержка OR-mapper для реляционных баз данных, поскольку они намного старше и имеют стандартизованный интерфейс и структуру столбцов столбцов. Они также были улучшены в течение длительного времени, поэтому они стабильны и оптимизированы для того, что они делают.

Графическая база данных лучше, если, например, ваша проблема связана скорее с соединениями между сущностями, особенно если вам нужны соединения с более высоким расстоянием, например «обнаружение циклов (неопределенной длины)», некоторые «то, что любят друзья-друг». Такие вещи становятся громоздкими, когда они ограничены объединением SQL. Специфический для проблемы язык, например, cypher, в случае Neo4j делает это гораздо более кратким. С другой стороны, существуют карты между графиками dbs и объектами, но не для всех фреймворков и языков под солнцем.

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

Другие хранилища данных NoSQL, такие как документ, столбцы, ключевые значения, также охватывают определенные операции. Настойчивость Polyglot - это, безусловно, что-то, на что можно обратить внимание, так что держите свой выбор в стороне, разумно отделенный от вашей бизнес-логики, чтобы вы могли позже изменить свою технологию, если узнаете что-то новое.