Каков рекомендуемый подход к мультитенантным базам данных в MongoDB?

Question

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

Я могу придумать три стратегии:

1. Все арендаторы в одной коллекции, использующие специфичные для арендатора поля для безопасности
2. 1 Сбор за каждого арендатора в одной общей базе данных
3. 1 База данных на каждого арендатора

Голос в моей голове наводит на мысль, что я выбрал вариант 2.

Мысли и последствия, кто-нибудь?

Answer 1

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

Во время моего исследования я нашел эту статью на сайте поддержки mongodb (путь назад был добавлен, поскольку он пропал): https://web.archive.org/web/20140812091703/http://support.mongohq.com/use-cases/multi-tenant.html

Ребята заявили, что избегают 2-х вариантов любой ценой, что, как я понимаю, не особенно характерно для mongodb. У меня сложилось впечатление, что это применимо к большинству исследованных мной баз данных NoSQL (CoachDB, Cassandra, CouchBase Server и т. Д.) Из-за особенностей дизайна базы данных.

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

Конечно, вы можете использовать безопасность на основе ролей mongodb для ограничения доступа на уровне базы данных / сервера. (http://docs.mongodb.org/manual/core/authorization/)

Я бы порекомендовал 1-й вариант, когда:

• У вас достаточно времени и ресурсов, чтобы справиться со сложностью разработка, реализация и тестирование этого сценария.
• Если вы не собираетесь иметь много различий в структуре и функциональность в базе данных для разных арендаторов.
• Дизайн вашего приложения позволит арендаторам сделать только минимальные настройки во время выполнения.
• Если вы хотите оптимизировать пространство и минимизировать использование оборудования ресурсы.
• Если у вас будут тысячи арендаторов.
• Если вы хотите быстро и с хорошей стоимостью.
• Если вы НЕ собираетесь создавать резервные копии данных на основе арендаторов (держите отдельно резервные копии для каждого арендатора). Это можно сделать даже в этом сценарий, но усилия будут огромны.

Я бы пошел на вариант 3, если:

• У вас будет небольшой список арендаторов (несколько сотен).
• Специфика бизнеса требует от вас поддержки больших различий в структуре базы данных для разных арендаторов (например, интеграция со сторонними системами, импорт-экспорт данных).
• Дизайн вашего приложения позволит клиентам (арендаторам) вносить существенные изменения во время выполнения приложения (добавление модулей, настройка полей и т. Д.).
• Если у вас достаточно ресурсов для быстрого масштабирования с новыми аппаратными узлами.
• Если вам необходимо хранить версии / резервные копии данных для каждого клиента. Также восстановление будет легким.
• Существуют законодательные / нормативные ограничения, которые заставляют вас держать разных арендаторов в разных базах данных (даже в центрах обработки данных).
• Если вы хотите полностью использовать готовые функции безопасности mongodb, такие как роли.
• Существуют большие различия в размере между арендаторами (у вас много маленьких арендаторов и мало очень крупных арендаторов).

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

Answer 2

Я нашел хороший ответ в комментариях по этой ссылке:

http://blog.boxedice.com/2010/02/28/notes-from-a-production-mongodb-deployment/

В общем, вариант № 2, кажется, лучший путь.

Цитата из комментария Дэвида Миттона:

Мы решили не иметь базы данных на клиент из-за способа MongoDB выделяет свои файлы данных. каждый база данных использует собственный набор файлов:

Первый файл для базы данных dbname.0, затем dbname.1 и т. д. dbname.0 будет 64 МБ, dbname.1 128 МБ и т. д. до 2 ГБ. Как только файлы достигают 2 ГБ в размер, каждый последующий файл также 2 Гб.

Таким образом, если последний присутствующий файл данных скажем, 1 ГБ, этот файл может быть на 90% пустым если он был недавно достигнут.

из руководства.

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

Sharding будет в каждой коллекции основа в качестве стандарта, который представляет проблема, когда коллекция никогда достигает минимального размера для начала осколок, как это имеет место для довольно некоторые из наших (например, коллекции просто хранение данных для входа в систему). Тем не мение, мы просили, чтобы это также быть в состоянии сделать на основе базы данных уровень. Увидеть http://jira.mongodb.org/browse/SHARDING-41

Нет компромиссов в производительности используя много коллекций. Увидеть http://www.mongodb.org/display/DOCS/Using+a+Large+Number+of+Collections

Answer 3

Я бы выбрал вариант 2.

Однако вы можете установить параметр командной строки mongod.exe --smallfiles. Это означает, что самый большой размер файла экстента будет 0,5 гигабайта, а не 2 гигабайта. Я проверил это с Монго 1.42. Так что вариант 3 не является невозможным.

Answer 4

В MSDN есть разумная статья о мультитенантной архитектуре данных , на которую вы, возможно, захотите сослаться. Некоторые ключевые темы, затронутые в этой статье:

• Экономические соображения
• Безопасность
• Арендатор
• Нормативный (юридический)
• Навыки набора навыков

Также затронуты некоторые шаблоны конфигурации программного обеспечения как услуги (SaaS).

Кроме того, стоит потрудиться - интересная статья от ребят из SQL Anywhere .

Мое личное мнение - если вы не уверены в принудительной безопасности / доверии, я бы выбрал вариант 3 или если проблемы масштабируемости запрещают как минимум вариант 2. Тем не менее ... Я не профессионал с MongoDB. Я довольно нервничаю, используя общую «схему», но я с радостью откажусь от более опытных практикующих.

Answer 5

Согласно моим исследованиям в MongoDB. Trucos y consejos. Aplicaciones мультитенант. этот вариант не рекомендуется, если вы не знаете, сколько у вас может быть арендаторов, их может быть несколько тысяч, и это будет сложно, когда дело доходит до шардинга, также представьте, что в одной базе данных есть тысячи коллекций ... Так что в вашем случае это Рекомендуется использовать первый вариант. Теперь, если у вас будет ограниченное количество пользователей, оно уже другое, и да, вы можете использовать второй вариант, как вы думали.

Answer 6

Хотя здесь обсуждается NoSQL и, прежде всего, MongoDB, мы, Citus , используем PostgreSQL и создаем распределенную / сегментированную многопользовательскую базу данных.

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

Для более неструктурированных данных мы используем столбец JSONB PostgreSQL для хранения таких и специфичных для арендатора данных.