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

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

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

Ответ 2

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

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 и т.д., вверх   до 2 ГБ. Как только файлы достигнут 2 ГБ в   размер, каждый последующий файл также   2 Гб.

     

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

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

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

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

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

Ответ 3

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

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

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

Кроме того, стоит gander интересная запись из парней SQL Anywhere.

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

Ответ 4

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

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

Ответ 5

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

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

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

Ответ 6

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