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

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

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

1. Все арендаторы в одной коллекции с использованием полей для конкретных клиентов в целях безопасности
2. 1 коллекция на каждого арендатора в одной общей БД
3. 1 база данных на арендатора

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

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

Мне нужно решить ту же проблему и тоже рассмотреть варианты. Поскольку у меня есть многолетний опыт создания мультитенантных приложений 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, такие как роли.
• Между арендаторами существуют большие различия в размере (у вас много мелких арендаторов и мало очень крупных).

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

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

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

По сути, вариант №2 кажется лучшим выходом.

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

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

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

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

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

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

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

Нет никаких компромиссов в производительности при использовании большого количества коллекций. См. Http://www.mongodb.org/display/DOCS/Using+a+Large+Number+of+Collections

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

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

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

Вдобавок стоит присмотреться к интересной статье ребят из SQL Anywhere .

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

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

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

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

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

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

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