Каков рекомендуемый подход к многопользовательским базам данных в MongoDB?
Я думаю о создании многопользовательского приложения с помощью MongoDB. У меня пока нет никаких предположений о том, сколько у меня будет арендаторов, но я хотел бы иметь возможность масштабироваться на тысячи.
Я могу придумать три стратегии:
- все арендаторы в той же коллекции, используя арендатор полей для безопасности
- 1 коллекция на одного арендатора в одной общей БД
- 1 база данных на одного арендатора
голос в моей голове предлагает мне выбрать вариант 2.
мысли и выводы, кто-нибудь?
6 ответов
У меня такая же проблема для решения, а также рассмотрение вариантов. Поскольку у меня есть многолетний опыт создания многопользовательских приложений SaaS, я также собирался выбрать второй вариант на основе моего предыдущего опыта работы с реляционными базами данных.
во время моего исследования я нашел эту статью на сайте поддержки mongodb: http://support.mongohq.com/use-cases/multi-tenant.html
ребята заявили, чтобы избежать 2-х вариантов любой ценой, которые, как я понимание не особенно характерно для mongodb. Мое впечатление, что это применимо для большинства NoSQL dbs, которые я исследовал (CoachDB, Cassandra,Couchbase Server и т. д.) в связи со спецификой проектирования базы данных.
коллекции (или ведра или как они это называют в разных DBs) - это не то же самое, что схемы безопасности в СУБД, несмотря на то, что они ведут себя как контейнер для документов, они бесполезны для применения хорошего разделения арендаторов. Я не смог найти базу данных NoSQL, которая может применять ограничения безопасности на основе коллекций.
конечно, вы можете использовать безопасность на основе ролей mongodb для ограничения доступа на уровне базы данных/сервера. (http://docs.mongodb.org/manual/core/authorization/)
Я бы рекомендовал 1-й вариант, когда:
- у вас есть достаточно времени и ресурсов, чтобы справиться со сложностью проектирование, внедрение и тестирование этого сценария.
- если вы не собираетесь иметь много различия в структуре и функциональность в базе данных для разных арендаторов.
- ваш дизайн приложения позволит арендаторам сделать только минимальный настройки во время выполнения.
- если вы хотите оптимизировать пространство и минимизировать использование аппаратных ресурсы.
- если у вас будут тысячи арендаторов.
- если вы хотите масштабировать быстро и по хорошей стоимости.
- если вы не собираетесь создавать резервные копии данных на основе арендаторов (keep отделять резервные копии для каждого арендатора). Это возможно сделать даже в этом сценарий, но усилия будут огромными.
Я бы пошел на Вариант 3, Если:
- у вас будет небольшой список жильцов (несколько сотен).
- специфика бизнеса требует, чтобы вы могли поддерживать большие различия в структуре базы данных для разных арендаторов (например, интеграция с сторонними системами, импорт-экспорт данных).
- ваш дизайн приложения позволит клиентам (арендаторам) внести существенные изменения во время выполнения приложения (добавление модулей, настройка полей и т. д.).
- если у вас достаточно ресурсов, чтобы быстро масштабироваться с новыми аппаратными узлами.
- если требуется хранить версии / резервные копии данных для каждого клиента. Также восстановление будет легким.
- существуют правовые / нормативные ограничения, которые заставляют вас держать разных арендаторов в разных базах данных (даже данные центры.)
- если вы хотите полностью использовать встроенные функции безопасности mongodb, такие как роли.
- есть большие различия в вопросе размера между арендаторами (у вас есть много маленьких арендаторов и несколько очень больших арендаторов).
Если вы опубликуете дополнительные сведения о своем приложении, возможно, я смогу дать вам более подробный совет.
Я нашел хороший ответ в комментариях по этой ссылке:
http://blog.boxedice.com/2010/02/28/notes-from-a-production-mongodb-deployment/
в основном вариант #2, кажется, лучший способ пойти.
цитата из комментария Дэвида Миттона:
мы решили не иметь базу данных в клиент из-за пути MongoDB выделяет свои файлы данных. Каждый база данных использует собственный набор файлов:
первый файл для базы данных dbname.0, затем dbname.1, etc. dbname.Ноль будет 64MB, dbname.1 128МБ, и т. д., вверх 2 ГБ. Как только файлы до 2 ГБ в размер, каждый последующий файл также 2 ГБ.
таким образом, если последний файл данных присутствует скажем, 1GB, этот файл может быть на 90% пустым если он был недавно достигнут.
из руководства.
Как пользователи подписываются на пробную версию и дают вещи идти, мы бы вам еще и больше базы данных, которые были по крайней мере 2 ГБ размер, даже если все данные файл не использовался. Мы нашли это использовали огромное количество дискового пространства по сравнению иметь несколько баз данных для всех клиенты, где дисковое пространство может быть используется для максимальной эффективности.
Sharding будет в каждой коллекции основе как стандарт, который представляет собой проблема, где коллекция никогда достигает минимального размера для запуска шардинг, как в случае с довольно немногие из наших (например сборники just хранение данных входа пользователя). Однако, мы просили, чтобы это также можно сделать на базе данных уровень. Видеть http://jira.mongodb.org/browse/SHARDING-41
нет никаких компромиссов производительности используя множество коллекций. Видеть http://www.mongodb.org/display/DOCS/Using+в+большой+номер+в+коллекции
здесь разумная статья о MSDN об архитектуре данных с несколькими арендаторами на который вы могли бы сослаться. Некоторые ключевые темы, затронутые в этой статье:
- экономические соображения
- безопасность
- соображения арендатора
- нормативные (правовые)
- набор навыков касается
также затронуты некоторые шаблоны для программного обеспечения как Службы (SaaS) конфигурация.
кроме того, стоит Гандера интересная запись из SQL Anywhere guys.
мое личное взятие-если вы не уверены в принудительной безопасности / доверии, Я бы пошел с вариантом 3, или если проблемы масштабируемости запрещают отступление к варианту 2 как минимум. Вот и все... Я не про с MongoDB. Я очень нервничаю, используя общую "схему", но я с радостью уступлю более опытным практикам.
Я бы пошел на Вариант 2.
однако вы можете установить mongod.параметр командной строки exe --smallfiles. Это означает, что максимальный размер файла размер будет 0.5 гигабайта, а не 2 гигабайта. Я проверил это с mongo 1.42 . Таким образом, Вариант 3 Не невозможен.
в то время как обсуждение здесь идет на NoSQL и в первую очередь MongoDB, мы в Citusбыл используют PostgreSQL и создают распределенную/распределенную многопользовательскую базу данных.
наши использовать-дело руководства проходит через пример приложения, охватывающий схему и различные функции с несколькими арендаторами.
для более неструктурированных данных мы используем столбец JSONB PostgreSQL для хранения таких и специфичных для клиента данных.
согласно моим исследованиям в MongoDB. Взлом г с советами. Aplicaciones multitenant. этот вариант не рекомендуется, если вы не знаете, сколько арендаторов вы можете иметь, это может быть тысячи, и это будет сложно, когда дело доходит до шардинга, также представьте, что тысячи коллекций в одной базе данных ... Поэтому в вашем случае рекомендуется использовать Вариант номер один. Теперь, если у вас будет ограниченное количество пользователей, это уже другое, и да, вы можете использовать опцию два, как ты и думал.