Czy bazy danych wielu dzierżawców mają wiele baz danych lub wspólnych tabel?

25

Czy baza danych dla wielu dzierżawców:

  • Serwer DB, który ma inną (identyczną) bazę danych / schemat dla każdego klienta / najemcy ?; lub
  • Serwer DB, który ma bazę danych / schemat, w której klienci / najemcy współużytkują rekordy w tych samych tabelach?

Na przykład, zgodnie z Opcją 1 powyżej, mogę mieć serwer MySQL na, powiedzmy mydb01.example.com, i może mieć w nim customer1bazę danych. Ta customer1baza danych może mieć, powiedzmy, 10 tabel, które zasilają moją aplikację dla tego konkretnego klienta (Klient nr 1). Może także zawierać customer2bazę danych zawierającą dokładnie te same 10 tabel, ale zawierającą tylko dane dla klienta nr 2. Może mieć customer3bazę danych, customer4bazę danych itd.

W Opcji # 2 powyżej istniałaby tylko jedna baza danych / schemat, powiedzmy myapp_db, znowu z 10 tabelami (takimi samymi jak powyżej). Ale tutaj dane wszystkich klientów istnieją w tych 10 tabelach, dlatego też „dzielą się” nimi. A w warstwie aplikacji logika i kontrola bezpieczeństwa, do których klienci mają dostęp, które rekordy w tych 10 tabelach, i należy dołożyć wszelkich starań, aby Klient nr 1 nigdy nie logował się do aplikacji i nie widział danych Klienta nr 3 itp.

Który z tych paradygmatów stanowi tradycyjną bazę danych „wielu dzierżawców”? A jeśli nie, to czy ktoś może podać mi przykład (przy użyciu opisanych powyżej scenariuszy), czym jest baza danych dla wielu dzierżawców?

database-design  multitenancy 
— smeeb
źródło
„wielu dzierżawców” oznacza silne bezpieczeństwo - gdzieś zaimplementowane - tak, że jeden dzierżawca nie widzi danych innych, nie może ich modyfikować, nie może odmówić dostępu do nich itp. To bezpieczeństwo musi być jakoś wdrożone. Opcje 1 i 2 PO działają, ale analiza bezpieczeństwa i praca wymagana do wdrożenia bezpieczeństwa jest inna. Za to, co jest warte, pracowałem w startupie, który zaimplementował wielodostępność za pomocą opcji nr 2, w której tabele - z wierszami należącymi do wielu dzierżawców - były ukryte (przez uprawnienia) przed wszystkimi użytkownikami końcowymi, a bezpieczeństwo zostało całkowicie wdrożone w procedurach przechowywanych.
— davidbak
3
— JeffO
1
Jeśli to ostatecznie zostanie zamknięte jako duplikat, myślę, że powinniśmy oflagować, aby połączyć go z celem dupe, ponieważ oba pytania mają naprawdę dobre odpowiedzi.

Odpowiedzi:

30

Który z tych paradygmatów stanowi tradycyjną bazę danych „wielu dzierżawców”

Obie koncepcje nazywane są wielodostępem, ponieważ jest to logiczna koncepcja „, w której jedno wystąpienie oprogramowania działa na serwerze i obsługuje wielu najemców” (z Wikipedii ). Ale to, jak wdrożysz tę koncepcję „fizycznie”, zależy od ciebie.

Oczywiście aplikacja potrzebuje koncepcji bazy danych, która pozwala oddzielić dane różnych dzierżawców, a ideą wielodostępności jest współdzielenie niektórych zasobów serwera (przynajmniej sprzętu) w celu lepszego wykorzystania zasobów i łatwiejszej administracji. Tak więc „DB dla wielu dzierżawców” to taki, który obsługuje to bezpośrednio , gdzie części modelu DB lub tabele są współużytkowane.

Mówiąc ściślej, możliwe jest zbudowanie aplikacji dla wielu dzierżawców z bazą danych niebędącą dzierżawą, zapewniając indywidualną instancję bazy danych dla klienta. Wyklucza to jednak współdzielenie dowolnych zasobów DB bezpośrednio między dzierżawcami, a warstwa aplikacji musi się upewnić, że odpowiedni dzierżawca jest podłączony do właściwej bazy danych.

— Doktor Brown
źródło
Dzięki @Doc Brown (+1), ale potem, jak można ewentualnie mieć dowolną bazę danych, która była nie multi-tenant?!?
— smeeb
4
@smeeb: wielodostępność jest właściwością aplikacji używanej przez różnych dzierżawców, a nie bazą danych „za” aplikacją. Oczywiście koncepcja db musi obsługiwać wiele najemców, aby było to możliwe.
— Doc Brown
4
@smeeb: załóżmy, że masz tabelę użytkowników z ograniczeniem, że nazwa użytkownika jest unikalna, teraz jakiś pracownik najemcy nie może już używać nazwy użytkownika tylko dlatego, że inna osoba pracująca u innego najemcy już go używa.
— RemcoGerlich,
5
@smeeb: jeśli jedynym sposobem obsługi dwóch dzierżawców jest zainstalowanie i uruchomienie aplikacji dwa razy, na dwóch różnych serwerach, z dwiema osobnymi bazami danych, myślę, że nie można nazwać tej wielodostępności.
— Doc Brown
1
Kiedyś poszedłem na prezentację na platformie Azure, która mówiła, że ​​MYOB uruchamia swoje rozwiązanie chmurowe na platformie Azure, a każdy najemca otrzymuje własną bazę danych (i prawdopodobnie także serwery sieciowe); mają po prostu świetne narzędzia automatyzacji do zarządzania setkami instancji DB, które muszą tego wymagać. Z drugiej strony organizacja, dla której obecnie pracuję, prowadzi setki klientów z jednej bazy danych, w oprogramowaniu jest tylko sporo pracy, aby wymusić izolację danych klientów. Rozważaliśmy również hybrydę, w której nasi najwięksi klienci otrzymaliby własną bazę danych, podczas gdy inni udostępnili oryginał.
— David Keaveny,
36

Według Microsoft termin ma 3 potencjalne znaczenia (jedna baza danych dla wszystkich najemców lub jedna baza danych na najemcę).

Na przykład każdy klient byłby własnym najemcą.

  1. Baza danych najemcy (klienta)

    • Każdy najemca jest odizolowany od innych (brak przypadkowego dostępu do danych innych najemców)
    • Izolacja ułatwia także zarządzanie przywracaniem danych, a także dostosowywanie potrzeb pamięci do potrzeb najemców.

  2. Wspólna baza danych, oddzielny schemat.

    • Każdy najemca ma swój własny schemat, a jego dane znajdują się we własnych tabelach.
    • Przywracanie może być bardziej czasochłonne, ponieważ wszyscy są w tej samej bazie danych, nie można po prostu przywrócić bazy danych do wcześniejszej kopii zapasowej (spowoduje to przywrócenie danych wszystkich najemców). Opcją jest przywrócenie do nowej bazy danych, a następnie scalenie / skopiowanie tylko danych 1 najemców.

  3. Udostępniona baza danych, wspólny schemat.

    • Dane każdego najemcy znajdują się w tych samych tabelach. Jeśli na przykład śledzisz zamówienia, zamówienia każdego najemcy będą znajdować się w „dbo.Orders”.
    • Dane najemców są oddzielone kolumną w każdej tabeli (może to być TenantId), która pokazuje właściciela wiersza.

Istnieją zalety i wady dla każdego, dobrze wyjaśnione w tym artykule: https://msdn.microsoft.com/en-us/library/aa479086.aspx

Bonus: możesz myśleć o tym jak o kwaterach mieszkalnych (rażąco uproszczonych).

  1. Każdy najemca ma własny dom. Mogą robić, co chcą, a jeśli się spali, tak naprawdę nie wpływa to na nikogo innego.

  2. Każdy najemca jest w tym samym budynku, ale ma własne mieszkanie.

  3. Wszyscy mieszkają w tym samym mieszkaniu, a wszystkie rzeczy są oznaczone karteczką, aby pokazać, kto jest właścicielem.

— lmms90
źródło
2
Dziękuję za Twoją odpowiedź. Czy mógłbyś podać trochę odpowiedzi. To stworzyłoby lepszą odpowiedź.
— Thomas Junk
1
Twój przykładowy bonus jest niesamowity @ imms90
— Aravin
3
Microsoft upuścił stronę, którą podłączyłeś z MSDN. Maszyna Wayback wciąż ma kopię.
— Mike Sherrill „Cat Recall”
1
Podobny artykuł z MS (być może ten sam, który się przeniósł): docs.microsoft.com/en-us/azure/sql-database/…
— Pierre Henry
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.