Jak utworzyć wielodostępną bazę danych ze współdzielonymi strukturami tabel?

Question

Jak utworzyć wielodostępną bazę danych ze współdzielonymi strukturami tabel?

Nasze oprogramowanie działa obecnie na MySQL. Dane wszystkich dzierżawców są przechowywane w tym samym schemacie. Ponieważ używamy Ruby on Rails, możemy łatwo określić, które dane należą do którego dzierżawcy. Jednak niektóre firmy oczywiście obawiają się, że ich dane mogą zostać naruszone, więc oceniamy inne rozwiązania.

Do tej pory widziałem trzy opcje:

Multi-Baza Danych (każdy dzierżawca otrzymuje swój własny - prawie taki sam jak 1 serwer na klienta)
Multi-Schema (nie dostępne w MySQL, każdy dzierżawca otrzymuje własny schemat we współdzielonej bazie danych)
Shared Schema (nasze obecne podejście, może z dodatkowym rekordem identyfikującym w każdej kolumnie)

Multi-Schema jest moim ulubionym (biorąc pod uwagę koszty). Jednak tworzenie nowego konta i wykonywanie migracji wydaje się być dość bolesne, ponieważ musiałbym iterację wszystkich schematów i zmieniać ich tabele/kolumny / definicje.

P: Multi-Schema wydaje się być zaprojektowany tak, aby mieć nieco różne stoliki dla każdego lokatora - nie chcę tego. Czy istnieje system RDBMS, który pozwala mi korzystać z rozwiązania multi-schema multi-tenant, w którym struktura tabeli jest współdzielona między wszystkimi lokatorami?

P. S. przez multi mam na myśli coś w rodzaju ultra-multi (10.000 + lokatorów).

107

mysql sql database-design multi-tenant

Author: Marcel Jackwerth, 2010-02-06

Source

4 answers

Moje doświadczenie (aczkolwiek SQL Server) jest takie, że multi-database jest drogą, gdzie każdy klient ma swoją własną bazę danych. Więc chociaż nie mam doświadczenia z mySQL lub Ruby On Rails, mam nadzieję, że mój wkład może dodać jakąś wartość.

Powody, dla których to:

bezpieczeństwo danych/odzyskiwanie danych po awarii. Dane każdej firmy są przechowywane całkowicie oddzielnie od innych, co zmniejsza ryzyko naruszenia danych (myślenie takie jak wprowadzenie błędu kodu, który oznacza coś omyłkowo patrzy na inne dane klienta, gdy nie powinien), minimalizuje potencjalne straty dla jednego klienta, jeśli jedna konkretna baza danych zostanie uszkodzona itp. Postrzegane korzyści bezpieczeństwa dla klienta są jeszcze większe(dodatkowy efekt uboczny!)
Tuning wydajności. Załóżmy, że masz jednego bardzo dużego klienta i jednego bardzo małego. Wzorce użytkowania, ilości danych itp. może się bardzo różnić. Możesz dostroić / zoptymalizować łatwiej dla każdego klienta, jeśli potrzebujesz.

Mam nadzieję, że to pomoże! Jest więcej powodów, ale mój umysł stracił przytomność. Jak zacznie działać to zaktualizuję :)

EDIT:
Odkąd opublikowałem tę Odpowiedź, Teraz jest jasne, że mówimy o 10,000 + najemcach. Moje doświadczenie jest w setkach dużych baz danych-nie sądzę, że 10,000 oddzielnych baz danych będzie zbyt zarządzalne dla Twojego scenariusza, więc teraz nie jestem zwolennikiem podejścia multi-db dla Twojego scenariusza. Zwłaszcza, że teraz jest jasne, że mówisz o małej ilości danych dla każdego najemcy!

Trzymanie mojej odpowiedzi tutaj tak, jak to może mieć jakiś pożytek dla innych osób w podobnej łodzi (z mniejszą liczbą lokatorów)

15

Author: AdaTheDev,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2010-02-06 15:46:43

Poniżej link do białej księgi na Salesforce.com o tym jak wdrażają multi-tenancy:

Http://www.developerforce.com/media/ForcedotcomBookLibrary/Force.com_Multitenancy_WP_101508.pdf

Mają 1 ogromną tabelę z 500 kolumnami łańcuchowymi (Value0, Value1, ... Wartość 500). Daty i liczby są przechowywane jako ciągi znaków w takim formacie, że mogą być konwertowane na ich natywne typy na poziomie bazy danych. Istnieją tabele metadanych, które definiują kształt danych model, który może być unikalny dla każdego najemcy. Istnieją dodatkowe tabele do indeksowania, relacji, unikalnych wartości itp.

Po co ten kłopot?

Każdy dzierżawca może dostosować swój własny schemat danych w czasie wykonywania bez konieczności wprowadzania zmian na poziomie bazy danych (alter table itp.). Jest to zdecydowanie trudny sposób na zrobienie czegoś takiego, ale jest bardzo elastyczny.

14

Author: dana,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2012-04-18 21:05:46

Jak wspomniałeś, jedna baza danych na dzierżawcę jest opcją i ma z nią większe kompromisy. Może działać dobrze na mniejszą skalę, na przykład w przypadku pojedynczej cyfry lub niskiej liczby 10 najemców, ale poza tym zarządzanie nim staje się trudniejsze. Zarówno tylko migracje, ale także utrzymywanie i działanie baz danych.

Model per schema jest przydatny nie tylko dla unikalnych schematów dla każdego z nich, ale nadal migracje między wszystkimi lokatorami stają się trudne, a na 1000 schematów Postgres może zacząć mieć kłopoty.

Bardziej skalowalne podejście polega na tym, że lokatorzy są losowo rozdzielani, przechowywani w tej samej bazie danych, ale w różnych odłamkach logicznych (lub tabele). W zależności od języka istnieje wiele bibliotek, które mogą w tym pomóc. Jeśli korzystasz z Rails to jest biblioteka do acts_as_tenant, pomaga to zapewnić, że zapytania dzierżawców pobierają tylko te dane. Jest też klejnot apartment - choć używa schematu modelowanie pomaga w migracji we wszystkich schematach. Jeśli używasz Django, jest tam numer, ale jeden z bardziej popularnych wydaje się być na schematach . Wszystko to pomaga bardziej na poziomie aplikacji. Jeśli szukasz czegoś więcej bezpośrednio na poziomie bazy danych, Citus koncentruje się na tworzeniu tego typu shardingu dla multi-tenancy bardziej od pudełka z Postgres.

7

Author: CraigKerstiens,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2016-09-07 21:07:23

score 76 · Accepted Answer

Istnieją jednak pewne firmy kurs, którzy obawiają się, że ich dane mogą być narażone, więc oceniamy inne rozwiązania.

Jest to niefortunne, ponieważ klienci czasami cierpią z powodu błędnego przekonania, że tylko fizyczna izolacja może zapewnić wystarczające bezpieczeństwo.

Istnieje ciekawy artykuł MSDN, zatytułowany Multi-Tenant Data Architecture , który warto sprawdzić. W ten sposób autorzy zwrócili się do autorów z błędnym przekonaniem o udostępnionym "podejście": {]}

Powszechne błędne przekonanie głosi, że tylko fizyczna izolacja może zapewnić odpowiedni poziom bezpieczeństwa. W fakt, dane przechowywane przy użyciu współdzielonego podejście może również dostarczyć mocnych danych bezpieczeństwa, ale wymaga użycia więcej wyrafinowane wzorce projektowe.

Jeśli chodzi o względy techniczne i biznesowe, artykuł zawiera krótką analizę, gdzie pewne podejście może być bardziej odpowiednie niż inne:

Liczba, charakter i potrzeby najemców, których oczekujesz, aby służyć wszystkim wpływom twoja decyzja o architekturze danych w na różne sposoby. Niektóre z następujących pytania mogą skłaniać cię ku bardziej odosobnione podejście, podczas gdy inne mogą stronniczość w kierunku bardziej wspólnego podejdźcie.

Ilu potencjalnych najemców spodziewasz się wycelować? You may be nowhere blisko możliwości oszacowania perspektywiczne wykorzystanie z władzą, ale myśl w kategoriach rzędów wielkości: czy budujesz aplikację na setki lokatorów? Tysiące? Tens tysięcy? Więcej? Im większy ty spodziewaj się, że Twoja baza najemców będzie, bardziej prawdopodobne, że będziesz chciał rozważyć bardziej wspólne podejście.

Ile powierzchni magazynowej według Ciebie zajmą dane przeciętnego najemcy? Jeśli oczekujesz, że niektórzy lub wszyscy najemcy będą przechowywać bardzo duże ilości danych, osobne - podejście bazodanowe jest prawdopodobnie najlepszy. (Rzeczywiście, przechowywanie danych wymagania mogą zmusić cię do przyjęcia model oddzielnej bazy danych w każdym razie. Jeśli tak, znacznie łatwiej będzie zaprojektować zastosowanie w ten sposób z początek niż przenieść się do osobne podejście do bazy danych później.)

Ilu jednoczesnych użytkowników końcowych oczekuje Pan od przeciętnego najemcy? Im większa liczba, tym więcej odpowiednie bardziej odosobnione podejście będzie spełniać wymagania użytkowników końcowych.

Czy spodziewasz się oferować usługi o wartości dodanej dla każdego najemcy, takie kopia zapasowa i przywracanie według dzierżawcy możliwości? Takie usługi są łatwiejsze oferować poprzez bardziej odizolowane podejdźcie.

Aktualizacja: dalsze informacje o oczekiwanej liczbie najemców.

Ta oczekiwana liczba lokatorów (10k) powinna wykluczać podejście oparte na wielu bazach danych, dla większości, jeśli nie wszystkich scenariuszy. Nie sądzę, że spodoba ci się pomysł utrzymywania 10,000 instancji bazy danych i konieczności tworzenia setek nowych każdego dnia.

Z samego tego parametru wynika, że wygląda na to, że podejście shared-database, single-schema jest najbardziej odpowiednie. Fakt, że będziesz przechowywać tylko około 50 MB na dzierżawcę i że nie będzie żadnych dodatków na dzierżawcę, sprawia, że takie podejście jest jeszcze bardziej odpowiednie.

Przytoczony powyżej artykuł MSDN wymienia trzy wzorce zabezpieczeń, które rozwiązują kwestie bezpieczeństwa związane z podejściem do współdzielonej bazy danych:

Jeśli jesteś przekonany o środkach bezpieczeństwa danych swojej aplikacji, możesz zaoferować swoim klientom umowę o poziomie usług , która zapewnia silne gwarancje bezpieczeństwa danych. W umowie SLA oprócz gwarancji można również opisać środki, które należy podjąć w celu zapewnienia, że dane nie zostaną naruszone.

UPDATE 2: najwyraźniej chłopaki z Microsoftu przenieśli / zrobili nowy artykuł dotyczący tego tematu, oryginał link zniknął, a to jest nowy: Multi-tenant Saas database tenancy patterns (kudos to Shai Kerer)