Nie jest to łatwa odpowiedź, ponieważ wiele zależy od architektury aplikacji, użycia i wzorców zapytań, dystrybucji między klientami (np. czy poziomy użycia będą mniej więcej takie same dla klientów, czy też 10% klientów będzie korzystać z 90% zasobów), ile możesz wydać na zarządzanie kodem vs zarządzaniem operacjami i całą masę innych kwestii. Oto kilka rzeczy do rozważenia:
1) posiadanie jednej bazy danych ułatwi zarządzanie operacjami, wymaga mniej zasobów obliczeniowych i może pozwolić na lepsze skalowanie, ale kodowanie warstwy dostępu będzie trudniejsze i naprawdę musisz dobrze zaprojektować warstwę bezpieczeństwa z oczywistych powodów. Zużyjesz również mniej zasobów po stronie klienta/serwera internetowego, ponieważ będzie znacznie mniej połączeń.
Istnieją dwie popularne opcje schematu przy podejściu do jednej monolitycznej bazy danych:
- Możesz umieścić wszystkie podobne dane w jednym zbiorze (np. profile dla wszystkich kont należą do tego samego zbioru) i nadać każdemu dokumentowi klucz identyfikatora klienta w celu zidentyfikowania, które dane należą do którego konta. Może to zapewnić najlepsze opcje (w zależności od architektury schematu) skalowania w poziomie przy najmniejszej liczbie zasobów obliczeniowych.
- Inną opcją jest oddzielenie danych klienta według kolekcji - każdy klient będzie miał własne kolekcje w bazie danych identyfikowanej prefiksem clientid (np. clientid_userprofiles).
2) opcja bazy danych na klienta spowoduje więcej problemów z zarządzaniem operacjami i będzie kosztować więcej, ponieważ będziesz potrzebować więcej zasobów obliczeniowych. Z drugiej strony koszty kodowania powinny być mniejsze, ponieważ kod będzie łatwiejszy do napisania. Umożliwi to również lepszą dystrybucję zasobów pomiędzy ciężkimi i lekkimi użytkownikami. Na przykład można przenieść klientów intensywnie użytkowanych na bardziej wydajne maszyny i udostępniać fragmenty dla poszczególnych klientów.
3) możesz dostarczyć kombinację dwóch opcji - dedykowane bazy danych dla użytkowników z wyższej półki (konta, które płacą więcej), a następnie współdzieloną bazę danych z danymi oddzielonymi zbiorami dla klientów z niższej półki i kont testowych/freemium.
Zauważ, że jeśli wybierzesz trasę wielu baz danych, powinieneś zajrzeć do opcji uruchamiania --smallfiles. Pomoże ci to w sytuacjach, w których wiele osób tworzy „konta testowe”, ale nie robią z nimi zbyt wiele.
W każdym razie, miejmy nadzieję, że powyższe daje do myślenia. Przeprowadź wyszukiwanie na https://groups.google.com /forum/?fromgroups#!searchin/mongodb-user/multitenant ponieważ na forach Mongo toczyło się wiele dyskusji na ten konkretny temat.
Jeśli chodzi o implikacje audytu, zależy to od poziomu zgodności audytu, którego musisz przestrzegać. Jeśli spodziewasz się klientów z fortuną 1000, Twoje wymagania dotyczące zgodności będą znacznie wyższe (i znacznie droższe – powiedzmy od 10 do 100 dolarów z tysięcy dolarów), niż gdyby Twoimi klientami były startupy, które być może nigdy nie słyszały o SAS70 itp. Odpowiedź zależy również od rodzaju danych, które przechowujesz - czy są to dane finansowe użytkownika, czy tylko fora użytkowników? Zasadniczo, jeśli istnieją jakiekolwiek obawy dotyczące konieczności przejścia audytów bezpieczeństwa dla dużych firm w przyszłości, nawet nie myśl o podejściu ze współdzieloną bazą danych.
