Mam ten sam problem do rozwiązania, a także rozważam warianty. Ponieważ mam wieloletnie doświadczenie w tworzeniu aplikacji dla wielu dzierżawców SaaS, zamierzałem również wybrać drugą opcję w oparciu o moje wcześniejsze doświadczenia z relacyjnymi bazami danych.
Podczas moich poszukiwań znalazłem ten artykuł na stronie wsparcia mongodb (dodano go z powrotem, ponieważ zniknął):https://web.archive.org/web/20140812091703/http://support.mongohq.com/use-cases/multi -tenant.html
Chłopaki stwierdzili, że będą unikać drugiej opcji za wszelką cenę, co, jak rozumiem, nie jest szczególnie specyficzne dla mongodb. Mam wrażenie, że dotyczy to większości baz danych NoSQL, które przebadałem (CoachDB, Cassandra, CouchBase Server itp.) ze względu na specyfikę projektu bazy danych.
Kolekcje (lub wiadra lub jak je nazywają w różnych bazach danych) to nie to samo, co schematy bezpieczeństwa w RDBMS, mimo że zachowują się jak kontener na dokumenty, są bezużyteczne przy stosowaniu dobrej separacji dzierżawców. Nie mogłem znaleźć bazy danych NoSQL, która może nakładać ograniczenia bezpieczeństwa na podstawie kolekcji.
Oczywiście można użyć zabezpieczeń opartych na rolach mongodb, aby ograniczyć dostęp na poziomie bazy danych/serwera. (http://docs.mongodb.org/manual/core/authorization/)
Polecam pierwszą opcję, gdy:
- Masz wystarczająco dużo czasu i zasobów, aby poradzić sobie ze złożonością projektowania, implementacji i testowania tego scenariusza.
- Jeśli nie będziesz mieć dużych różnic w strukturze i funkcjonalności bazy danych dla różnych najemców.
- Twój projekt aplikacji pozwoli najemcom na dokonywanie tylko minimalnych dostosowań w czasie wykonywania.
- Jeśli chcesz zoptymalizować przestrzeń i zminimalizować wykorzystanie zasobów sprzętowych.
- Jeśli zamierzasz mieć tysiące najemców.
- Jeśli chcesz szybko i tanio skalować skalę.
- Jeśli NIE zamierzasz tworzyć kopii zapasowych danych na podstawie dzierżawców (zachowaj oddzielne kopie zapasowe dla każdego dzierżawcy). Można to zrobić nawet w tym scenariuszu, ale wysiłek będzie ogromny.
Wybrałbym wariant 3, jeśli:
- Będziesz mieć małą listę najemców (kilkuset).
- Specyfika firmy wymaga, abyś był w stanie obsługiwać duże różnice w strukturze bazy danych dla różnych najemców (np. integracja z systemami innych firm, import-eksport danych).
- Projekt Twojej aplikacji umożliwi klientom (dzierżawcom) wprowadzanie znaczących zmian w środowisku wykonawczym aplikacji (dodawanie modułów, dostosowywanie pól itp.).
- Jeśli masz wystarczającą ilość zasobów, aby szybko skalować nowe węzły sprzętowe.
- Jeśli wymagane jest przechowywanie wersji/kopii zapasowych danych na dzierżawę. Również przywracanie będzie łatwe.
- Istnieją ograniczenia prawne/regulacyjne, które zmuszają do utrzymywania różnych najemców w różnych bazach danych (nawet centrach danych).
- Jeśli chcesz w pełni wykorzystać gotowe funkcje bezpieczeństwa mongodb, takie jak role.
- Istnieją duże różnice w wielkości między najemcami (masz wielu małych i kilku bardzo dużych).
Jeśli opublikujesz dodatkowe informacje na temat swojej aplikacji, być może będę mógł udzielić Ci bardziej szczegółowych porad.
