Jednak są oczywiście firmy, które obawiają się, że ich dane mogą zostać naruszone, dlatego rozważamy inne rozwiązania.
Jest to niefortunne, ponieważ klienci czasami błędnie uważają, że tylko fizyczna izolacja może zapewnić wystarczające bezpieczeństwo.
Istnieje interesujący artykuł MSDN zatytułowany Multi-Tenant Data Architecture , który możesz chcieć sprawdzić. W ten sposób autorzy odnieśli się do błędnego przekonania o wspólnym podejściu:
Powszechne jest przekonanie, że tylko fizyczna izolacja może zapewnić odpowiedni poziom bezpieczeństwa. W rzeczywistości dane przechowywane przy użyciu wspólnego podejścia mogą również zapewniać duże bezpieczeństwo danych, ale wymagają użycia bardziej wyrafinowanych wzorców projektowych.
Jeśli chodzi o względy techniczne i biznesowe, artykuł zawiera krótką analizę tego, gdzie pewne podejście może być bardziej odpowiednie niż inne:
Liczba, charakter i potrzeby dzierżawców, których oczekujesz, że będą służyć wszystkim, wpływają na decyzje dotyczące architektury danych na różne sposoby. Niektóre z poniższych pytań mogą skłaniać Cię do bardziej odosobnionego podejścia, podczas gdy inne mogą skłaniać Cię do bardziej wspólnego podejścia.
-
Do ilu potencjalnych najemców zamierzasz dotrzeć? Być może nie jesteś w stanie z autorytetem oszacować przyszłego wykorzystania, ale pomyśl w kategoriach rzędów wielkości:czy tworzysz aplikację dla setek lokatorów? Tysiące? Dziesiątki tysięcy? Więcej? Im większa będzie Twoja baza najemców, tym bardziej prawdopodobne jest, że będziesz chciał rozważyć bardziej wspólne podejście.
-
Ile przestrzeni dyskowej według przewidywań zajmą dane przeciętnego najemcy? Jeśli oczekujesz, że niektórzy lub wszyscy najemcy będą przechowywać bardzo duże ilości danych, prawdopodobnie najlepszym rozwiązaniem jest zastosowanie oddzielnej bazy danych. (W rzeczywistości wymagania dotyczące przechowywania danych i tak mogą zmusić Cię do przyjęcia modelu z osobną bazą danych. Jeśli tak, znacznie łatwiej będzie zaprojektować aplikację w ten sposób od początku, niż później przejść na podejście z osobną bazą danych.)
-
Ilu jednoczesnych użytkowników końcowych spodziewasz się obsługiwać przeciętny najemca? Im większa liczba, tym bardziej odpowiednie będzie bardziej izolowane podejście do spełnienia wymagań użytkowników końcowych.
-
Czy spodziewasz się oferować usługi o wartości dodanej dla poszczególnych dzierżawców, takie jak tworzenie kopii zapasowych i przywracanie dla każdego dzierżawcy? Takie usługi są łatwiejsze do zaoferowania dzięki bardziej izolowanemu podejściu.
AKTUALIZACJA: Dalsze aktualizacje dotyczące oczekiwanej liczby najemców.
Ta oczekiwana liczba najemców (10 tys.) powinna wykluczyć podejście oparte na wielu bazach danych w większości, jeśli nie we wszystkich scenariuszach. Nie sądzę, że spodoba ci się pomysł utrzymywania 10 000 instancji baz danych i konieczności tworzenia setek nowych każdego dnia.
Z samego tego parametru wygląda na to, że najbardziej odpowiednie jest podejście oparte na współużytkowanej bazie danych, oparte na jednym schemacie. Fakt, że będziesz przechowywać około 50 Mb na najemcę i nie będzie żadnych dodatków na najemcę, czyni to podejście jeszcze bardziej odpowiednim.
Cytowany powyżej artykuł MSDN wspomina o trzech wzorcach zabezpieczeń, które uwzględniają kwestie bezpieczeństwa w podejściu do współużytkowania baz danych:
Jeśli masz pewność co do środków bezpieczeństwa danych w swojej aplikacji, możesz zaoferować swoim klientom Umowę dotyczącą poziomu usług który zapewnia silne gwarancje bezpieczeństwa danych. W swojej umowie SLA, oprócz gwarancji, możesz również opisać środki, które podjąłbyś, aby zapewnić, że dane nie zostaną naruszone.
AKTUALIZACJA 2: Najwyraźniej chłopaki z Microsoftu przenieśli / napisali nowy artykuł na ten temat, oryginalny link zniknął, a to jest nowy:Wzorce dzierżawy bazy danych SaaS dla wielu dzierżawców (chwała dla Shai Kerera)
