Який рекомендований підхід до баз даних із кількома орендарями в 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/ )

Я б рекомендував перший варіант, коли:

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

Я піду на варіант 3, якщо:

• У вас буде невеликий список орендарів (кілька сотень).
• Специфіка бізнесу вимагає від вас можливості підтримувати великі відмінності в структурі баз даних для різних орендарів (наприклад, інтеграція із сторонніми системами, імпорт-експорт даних).
• Дизайн вашого додатка дозволить клієнтам (орендарям) внести суттєві зміни в час роботи програми (додавання модулів, налаштування полів тощо).
• Якщо у вас є достатньо ресурсів, щоб швидко масштабувати нові апаратні вузли.
• Якщо вам потрібно зберігати версії / резервні копії даних для кожного орендаря. Також відновлення буде легким.
• Існують законодавчі / регулятивні обмеження, які змушують тримати різних орендарів у різних базах даних (навіть центрах обробки даних).
• Якщо ви хочете повністю використовувати нестандартні функції безпеки 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

Існує розумна стаття про MSDN про архітектуру даних із кількома орендарями, на яку ви, можливо, хочете звернутися. Деякі ключові теми, яких торкається ця стаття:

• Економічні міркування
• Безпека
• Міркування орендарів
• Нормативна (юридична)
• Проблеми, що стосуються набору навичок

Також торкаються деяких моделей конфігурації програмного забезпечення як послуги (SaaS).

До того ж, варто розібратися - це цікаве видання від хлопців SQL Anywhere .

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

Я б вибрав варіант 2.

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

Згідно з моїми дослідженнями в MongoDB. Trucos y consejos. Aplicaciones multitenant. цей варіант не рекомендується, якщо ви не знаєте, скільки орендарів ви можете мати, це може бути тисячі, і це буде складно, коли справа доходить до шардінгу, також уявіть, що у одній базі даних є тисячі колекцій ... Отже, у вашому випадку це рекомендується використовувати варіант перший. Тепер, якщо у вас буде обмежена кількість користувачів, це вже інше, і так, ви можете використовувати варіант два, як ви думали.

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

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

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