Не е лесен отговор, защото много зависи от архитектурата на вашето приложение, моделите на използване и заявки, разпределението между клиентите (т.е. дали нивата на използване ще бъдат приблизително еднакви при различните клиенти или може да имате 10% от клиентите, използващи 90% от ресурси), колко можете да похарчите за код срещу управление на операции и цял набор от други проблеми. Ето някои неща, които трябва да имате предвид:
1) наличието на една база данни ще улесни управлението на вашите операции, ще изисква по-малко изчислителни ресурси и може да ви позволи да мащабирате по-добре, но кодирането на слоя за достъп ще бъде по-трудно и наистина трябва да проектирате добре слоя си за сигурност по очевидни причини. Освен това ще консумирате по-малко ресурси от страна на клиент/уеб сървър, тъй като ще има много по-малко връзки.
Има две популярни опции за схема при подход към една монолитна база данни:
- Можете да поставите всички подобни данни в една колекция (т.е.:профилите за всички акаунти влизат в една и съща колекция) и да дадете на всеки документ клиентски ключ, за да идентифицирате кои данни към кой акаунт принадлежат. Това може да ви предостави най-добрите опции (в зависимост от архитектурата на вашата схема) за мащабиране с най-малко изчислителни ресурси.
- Друга опция е да се разделят клиентските данни по колекции - всеки клиент ще има свои собствени колекции в рамките на базата данни, идентифицирани с клиентски префикс (т.е.:clientid_userprofiles).
2) опцията за база данни на клиент ще ви създаде повече главоболия при управлението на операциите и ще струва повече, тъй като ще ви трябват повече компютърни ресурси. От друга страна, вашите разходи за кодиране трябва да са по-малко, тъй като кодът ще бъде по-лесен за писане. Освен това ще ви позволи да разпределите по-добре ресурсите си между тежки и леки потребители. Например, можете да преместите клиенти с интензивно използване на по-мощни машини и да предоставите шардинг на базата на клиент.
3) бихте могли да предоставите комбинация от двете опции - специализирани бази данни за високи крайни потребители (акаунти, които плащат повече) и след това споделена база данни с данни, разделени чрез събиране за клиенти от нисък клас и тестови/безплатни акаунти.
Обърнете внимание, че ако тръгнете по пътя на множество бази данни, трябва да разгледате опцията за стартиране --smallfiles. Това ще ви помогне в ситуации, в които имате много хора, настройващи „тестови акаунти“, но които не правят много с тях.
Както и да е, надяваме се, че горното ви дава храна за размисъл. Направете търсене на https://groups.google.com /forum/?fromgroups#!searchin/mongodb-user/multitenant тъй като във форумите на Mongo имаше редица дискусии по този конкретен въпрос.
Що се отнася до последиците от одита, зависи какво ниво на съответствие на одита трябва да спазвате. Ако очаквате клиенти от Fortune 1000, вашите изисквания за съответствие ще бъдат много по-високи (и много по-скъпи - помислете за $10 до $100 хиляди долари), отколкото ако вашите клиенти са стартиращи фирми, които може никога да не са чували за SAS70 и т.н. Отговорът също зависи от това какъв тип данни съхранявате - финансови данни на потребителите ли са, или са само потребителски форуми? По принцип, ако има някакви опасения относно необходимостта от преминаване на одити за сигурност за големи компании в бъдеще, дори не си помисляйте за подхода на споделената база данни.
