Имам същия проблем за решаване и също така обмислям варианти. Тъй като имам дългогодишен опит в създаването на SaaS приложения с множество наематели, също щях да избера втората опция въз основа на предишния си опит с релационните бази данни.
Докато правех проучването си, намерих тази статия на сайта за поддръжка на mongodb (добавена назад, тъй като я няма):https://web.archive.org/web/20140812091703/http://support.mongohq.com/use-cases/multi -наемател.html
Момчетата заявиха да избягват 2-ри опции на всяка цена, което, както разбирам, не е особено специфично за mongodb. Впечатлението ми е, че това е приложимо за повечето NoSQL dbs, които изследвах (CoachDB, Cassandra, CouchBase Server и др.) поради спецификата на дизайна на базата данни.
Колекциите (или кофи или както го наричат в различни DBs) не са едно и също нещо като схемите за сигурност в RDBMS, въпреки че се държат като контейнер за документи, те са безполезни за прилагане на добро разделяне на наематели. Не можах да намеря база данни NoSQL, която може да прилага ограничения за сигурност въз основа на колекции.
Разбира се, можете да използвате сигурност, базирана на ролята на mongodb, за да ограничите достъпа на ниво база данни/сървър. (http://docs.mongodb.org/manual/core/authorization/)
Бих препоръчал 1-ва опция, когато:
- Имате достатъчно време и ресурси, за да се справите със сложността на дизайна, изпълнението и тестването на този сценарий.
- Ако няма да имате големи различия в структурата и функционалността в базата данни за различните наематели.
- Дизайнът на вашето приложение ще позволи на наемателите да правят само минимални персонализации по време на изпълнение.
- Ако искате да оптимизирате пространството и да сведете до минимум използването на хардуерни ресурси.
- Ако ще имате хиляди наематели.
- Ако искате да мащабирате бързо и на добра цена.
- Ако НЯМА да архивирате данни въз основа на наематели (съхранявайте отделни резервни копия за всеки наемател). Възможно е да се направи това дори в този сценарий, но усилията ще бъдат огромни.
Бих избрал вариант 3, ако:
- Ще имате малък списък с наематели (няколкостотин).
- Спецификата на бизнеса изисква да можете да поддържате големи различия в структурата на базата данни за различни наематели (напр. интеграция със системи на трети страни, импортиране-експорт на данни).
- Дизайнът на вашето приложение ще позволи на клиентите (наемателите) да правят значителни промени във времето за изпълнение на приложението (добавяне на модули, персонализиране на полетата и т.н.).
- Ако имате достатъчно ресурси за бързо мащабиране с нови хардуерни възли.
- Ако се изисква да съхранявате версии/резервни копия на данни за всеки клиент. Също така възстановяването ще бъде лесно.
- Има законови/регулаторни ограничения, които ви принуждават да държите различни наематели в различни бази данни (дори центрове за данни).
- Ако искате да използвате напълно готовите функции за сигурност на mongodb, като например роли.
- Има големи разлики по отношение на размера между наемателите (имате много малки наематели и няколко много големи наематели).
Ако публикувате допълнителни подробности за вашата кандидатура, може би мога да ви дам по-подробен съвет.
