Использование нескольких типов баз данных для моделирования данных в одном приложении

Question

Имеет ли смысл разбивать модель данных приложения на разные системы баз данных?Например, приложение хранит все пользовательские данные и отношения в графической базе данных (идеально подходит для хранения отношений), сохраняя при этом другие данные в базе данных документов, например CouchDB или MongoDB?Это потребовало бы, чтобы база данных пользовательских графов ссылалась на уникальные идентификаторы в базах документов и наоборот.

Это слишком усложняет модель данных и приложение?Или это лучшее использование обоих типов систем баз данных для масштабирования вашего приложения?

Answer 1

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

Взять, к примеру, полнотекстовый поиск. Конечно, вы можете выполнять более или менее сложный полнотекстовый поиск с помощью реляционной базы данных, такой как MySql. Но есть такие системы, как, например, Lucene / Solr, которые оптимизированы для таких вещей и могут быстро искать в миллионах документов. Таким образом, вы могли бы использовать эти системы для их специальной задачи (здесь: сделать отличный полнотекстовый поиск), затем вы возвращаете идентификаторы и, возможно, загружаете реляционные структурированные данные из RDBMS.

Или CouchDB. Я использую couchDB в некоторых проектах в качестве систем кеширования. В сочетании с реляционной базой данных. Конечно, мне нужно заботиться о последовательности, но это определенно стоит усилий. Это значительно повысило производительность в проектах и, например, снизило нагрузку на сервер с 2 до 0,2. :)

Answer 2

Примерно так называется постоянство в разных магазинах. Как вы упомянули, вы будете хранить определенные данные в своей реляционной базе данных, социальные отношения в graphdb, пользовательские данные (документы) в document-db и предоставленные пользователем мультимедийные файлы (изображения, аудио, видео) в хранилище больших двоичных объектов, например S3. .

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

Некоторые фреймворки, такие как Spring Data , предоставляют некоторые начальные виды постоянства между хранилищами из коробки, в основном интегрируя JPA с другим хранилищем данных NOSQL. Например, Spring Data Graph позволяет хранить ваши сущности в JPA и добавлять социальные графы или другие сильно взаимосвязанные данные в качестве вторичной проблемы и использовать graphdb для типичных операций обхода и других операций с графами. (например, рейтинг, предложения и т. д.)

Answer 3

Другой термин для этого - постоянство полиглота.

Вот две противоположные позиции по вопросу:

Pro: «Вопреки этому, я большой поклонник постоянства полиглота.просто означает использование подходящего серверного хранилища для каждого из ваших вариантов использования: например, хранилища файлов, SQL, графические базы данных, хранилища данных, базы данных в памяти, сетевые кэши, NoSQL. Сегодня в основном используются два хранилища, файлы и базы данных SQL.Оба не оптимальны для каждого варианта использования. "

• http://codemonkeyism.com/nosql-polyglott-persistence/

Con:" Я не думаю, что мне нужно говорить, что я сторонник полиглотанастойчивость. И я верю в философию инструментов Unix. Но, добавляя больше компонентов в вашу систему, вы должны понимать, что такая сложность системы «взрывается», и поэтому эксплуатационные расходы тоже возрастут (примечание: вы помните, почему Twitter началиспользуя Cassandra?). Не говоря уже о том, что чем больше компонентов в вашей системе, тем больше внимания нужно уделять тому, чтобы придумать критику.К таким аспектам, как общая доступность системы, задержка, пропускная способность и согласованность. "

• http://nosql.mypopescu.com/post/1529816758/why-redis-and-memcached-cassandra-lucene