Каков рекомендуемый подход к многопользовательским базам данных в MongoDB?
Я думаю о создании многопользовательского использования приложения MongoDB. У меня нет предположений с точки зрения того, сколько арендаторов я имел бы все же, но я хотел бы смочь масштабироваться в тысячи.
Я могу думать о трех стратегиях:
- Все арендаторы в том же наборе, с помощью определенных для арендатора полей для безопасности
- 1 Набор на арендатора в единственном общем DB
- 1 База данных на арендатора
Речь в моей голове предлагает, чтобы я пошел с опцией 2.
Мысли и последствия, кто-либо?
3 ответа
Я бы выбрал вариант 2.
Однако вы можете установить опцию командной строки mongod.exe --smallfiles. Это означает, что самый большой размер файла в экстенте будет 0,5 гигабайта, а не 2 гигабайта. Я тестировал это с mongo 1.42. Так что вариант 3 не является невозможным.
В MSDN есть разумная статья о мультитенантной архитектуре данных , на которую вы, возможно, захотите сослаться. Некоторые ключевые темы, затронутые в этой статье:
- Экономические соображения
- Безопасность
- Соображения арендатора
- Нормативные (юридические)
- Проблемы, связанные с набором навыков
Также затронуты некоторые шаблоны для программного обеспечения как услуги (SaaS) конфигурация.
Кроме того, стоит обратить внимание на интересную запись от ребят из SQL Anywhere .
Мое личное мнение - если вы не уверены в принудительной безопасности / доверии, я бы выбрал вариант 3, или если проблемы масштабируемости запрещают откат к варианту 2 как минимум. Тем не менее ... Я не профессионал в MongoDB. Я очень нервничаю, используя общую «схему», но я с радостью предоставлю помощь более опытным практикующим.
Я нашел хороший ответ в комментариях по этой ссылке:
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 ГБ , даже если весь файл данных не использовался. Мы обнаружили, что при этом используется огромный объем дискового пространства по сравнению с наличием нескольких баз данных для всех клиентов, где дисковое пространство может использоваться с максимальной эффективностью.
По стандарту сегментирование будет производиться для каждой коллекции , что представляет проблему, когда коллекция никогда не достигает минимального размера для начала сегментирования, поскольку так обстоит дело со некоторыми из наших (например, коллекции, в которых просто хранятся данные для входа в систему). Однако мы запросили, чтобы это также можно было сделать на уровне каждой базы данных . См. http://jira.mongodb.org/browse/SHARDING-41
Нет никаких компромиссов в производительности при использовании большого количества коллекций. См. http://www.mongodb.org/display/DOCS/Using+a+Large+Number+of+Collections