Я думаю о создании мультитенантного приложения с использованием MongoDB. У меня нет никаких предположений относительно того, сколько у меня арендаторов, но я хотел бы иметь возможность масштабироваться до тысяч.
Я могу придумать три стратегии:
- Все арендаторы в одной коллекции с использованием полей для конкретных клиентов в целях безопасности
- 1 коллекция на каждого арендатора в одной общей БД
- 1 база данных на арендатора
Голос в моей голове предлагает мне выбрать вариант 2.
Мысли и последствия, кто-нибудь?
mongodb
multi-tenant
Braintapper
источник
источник
Ответы:
Мне нужно решить ту же проблему и тоже рассмотреть варианты. Поскольку у меня есть многолетний опыт создания мультитенантных приложений 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, если:
Если вы опубликуете дополнительную информацию о своем приложении, возможно, я дам вам более подробный совет.
источник
Я нашел хороший ответ в комментариях по этой ссылке:
http://blog.boxedice.com/2010/02/28/notes-from-a-production-mongodb-deployment/
По сути, вариант №2 кажется лучшим выходом.
Цитата из комментария Дэвида Миттона:
источник
В 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 для хранения таких и специфичных для клиента данных.
источник