Czy powinienem używać jednej lub wielu konfiguracji bazy danych dla aplikacji dla wielu klientów?

Posłuchaj podcastu Stackoverflow, w którym Joel i Jeff rozmawiają o tym samym pytaniu. Joel opowiada o ich doświadczeniu w oferowaniu hostowanej wersji oprogramowania. Zwraca uwagę, że dodawanie identyfikatorów klientów w całym DB komplikuje projekt i Kod (czy na pewno przypadkiem nie zapomniałeś dodać go do jakiejś klauzuli WHERE?) i komplikuje funkcje hostingu, takie jak kopie zapasowe specyficzne dla klienta.

To było w odcinku # 20 lub # 21 (sprawdź stenogramy po szczegóły).

Moim zdaniem, będzie to zależało od twojej prawdopodobnej bazy klientów. Jeśli można dostać się do sytuacji, w której arch-rywale są zarówno za pomocą systemu, to byłoby lepiej z osobnymi bazami danych. Zależy to również od tego, jak wiele baz danych zostanie zaimplementowanych przez system DBMS. Jeśli każda baza danych ma oddzielną kopię infrastruktury, to sugeruje to pojedynczą bazę danych (lub zmianę DBMS). Jeśli jedna kopia infrastruktury może obsługiwać wiele baz danych, to wybrałbym osobne bazy danych.

Pomyśl o kopii zapasowej bazy danych. Klient A mówi "prześlij mi kopię moich danych". Dużo, dużo łatwiej w oddzielnej konfiguracji bazy danych niż w przypadku współdzielenia pojedynczej bazy danych. Pomyśl o usunięciu klienta; ponownie, znacznie łatwiej z oddzielnymi bazami danych.

(część "infrastructure" jest obmacywana, ponieważ istnieją duże różnice między różnymi DBMS co do tego, co stanowi "bazę danych", a na przykład "instancję serwera". Dodaj : pytanie jest oznaczone 'mysql' , więc może te myśli nie są do końca istotne.)

Dodaj : Jeszcze jeden problem - z wieloma klientami w jednej bazie danych, każde zapytanie SQL będzie musiało zapewnić, że dane dla właściwego klienta są wybierane. Oznacza to, że SQL będzie trudniejszy do napisania i odczytu, a DBMS będzie musiał ciężej pracować nad przetwarzaniem danych, a indeksy będą większe i ... Naprawdę wybrałbym osobną bazę danych na klienta dla wielu cele.

Oczywiście, StackOverflow (jako przykład) nie ma oddzielnej bazy danych dla każdego użytkownika; wszyscy używamy tej samej bazy danych. Ale gdybyś prowadził systemy księgowe dla różnych firm, nie wydaje mi się, aby było dopuszczalne (dla firm, a być może nie dla osób prawnych) udostępnianie baz danych.

• Rozwój W celu szybkiego rozwoju, użyj bazy danych na klienta. Pomyśl, jak łatwo będzie wykonać kopię zapasową, przywrócić lub usunąć dane Klienta. Lub do pomiaru/monitorowania / wykorzystania rachunku. Nie będziesz musiał pisać kodu, aby zrobić to samodzielnie, po prostu użyj swoich baz danych.

• Wydajność Aby uzyskać wydajność, użyj bazy danych dla wszystkich. Pomyśl o łączeniu połączeń, pamięci współdzielonej, buforowaniu itp.

• Biznes Jeśli twój biznes plan jest masz dużo małych klientów (myślę, że hotmail) powinieneś prawdopodobnie pracować na jednym DB. I mają wszystkie zadania administracyjne, takie jak rejestracja, usuwanie, migracja danych itp. w pełni zautomatyzowany i wyeksponowany w przyjaznym interfejsie. Jeśli planujesz mieć dziesiątki lub nawet kilkaset dużych klientów, możesz pracować w jednym DB na klienta i mieć Skrypty administracyjne systemu, które mogą być obsługiwane przez personel obsługi klienta.

Poniższy screencast wyjaśnia, jak to się robi na salesforce.com. używają jednej bazy danych ze specjalną kolumną OrgId, która identyfikuje dane każdego dzierżawcy. Jest o wiele więcej, więc powinieneś się temu przyjrzeć. Wybrałbym ich podejście.

Jest kolejny świetny Artykuł o tym na MSDN. Wyjaśnia dogłębnie, kiedy należy używać podejścia współdzielonego lub izolowanego. Pamiętaj, że posiadanie wspólnego DB dla wszystkich najemców ma kilka ważnych implikacji w zakresie bezpieczeństwa i jeśli wszystkie z nich mają te same obiekty DB, możesz chcieć użyć [row level security] - w zależności od używanego DBMS (jestem pewien, że jest to możliwe w MS SQL Server i Oracle, prawdopodobnie również w IBM DB2). Możesz użyć trików, takich jak row level security w mySQL, aby osiągnąć podobne wyniki (widoki + wyzwalacze).

W przypadku wielu dzierżaw, wydajność zazwyczaj zwiększa się, im więcej zasobów uda Ci się udostępnić między najemcami, zobacz

Http://en.wikipedia.org/wiki/Multitenancy

Więc jeśli możesz, przejdź do pojedynczej bazy danych. Zgadzam się, że problemy z bezpieczeństwem pojawią się tylko z powodu błędów, ponieważ można zaimplementować całą kontrolę dostępu w aplikacji. W niektórych bazach danych nadal można korzystać z kontroli dostępu do bazy danych poprzez ostrożne korzystanie z widoków (tak aby każdy uwierzytelniony użytkownik otrzymał inny widok).

Istnieją również sposoby zapewnienia rozciągliwości. Na przykład można utworzyć pojedynczą tabelę z atrybutami rozszerzenia (z kluczami dla dzierżawcy, rekordu podstawowego i identyfikatora atrybutu rozszerzenia). Można też utworzyć tabele rozszerzeń dla poszczególnych dzierżawców, tak aby każdy dzierżawca miał swój własny schemat rozszerzenia.

Kiedy projektujesz bazę danych dla wielu dzierżawców, zazwyczaj masz trzy opcje:

1. mieć jedną bazę danych na dzierżawcę
2. mieć jeden schemat na dzierżawcę
3. Czy wszyscy dzierżawcy mają tę samą tabelę(y)

Wybrana opcja ma wpływ na skalowalność, rozszerzalność i izolację. Implikacje te zostały szeroko omówione w różnych pytaniach Stoskoverflow i artykułach baz danych.

W praktyce każdy z trzech wzorów opcje-przy wystarczającym wysiłku - mogą rozwiązać pytania dotyczące skali, danych różniących się w zależności od najemców i izolacji. Decyzja zależy od podstawowego wymiaru, dla którego budujesz. Podsumowanie:

• jeśli budujesz na skalę: niech wszyscy Najemcy mają tę samą tabelę(y)
• jeśli budujesz dla izolacji: Utwórz jedną bazę danych na dzierżawcę

Na przykład, Google i Salesforce podążają za pierwszym wzorcem i mają te same tabele współdzielone przez najemców. Z drugiej strony, Stackoverflow podąża za drugim wzorcem i utrzymuje jedną bazę danych na dzierżawcę. Drugie podejście jest również bardziej powszechne w branżach regulowanych, takich jak Opieka zdrowotna.

Decyzja sprowadza się do podstawowego wymiaru, dla którego optymalizujesz projekt bazy danych. Ten artykuł o projektowaniu bazy danych SaaS dla skali mówi o kompromisach i zawiera podsumowanie w kontekście PostgreSQL.

Kolejną kwestią do rozważenia jest to, że możesz mieć prawny obowiązek oddzielenia danych jednej firmy od innych.

Posiadanie bazy danych na klienta zazwyczaj nie jest dobrze skalowane. MySQL (i prawdopodobnie inne bazy danych) przechowuje zasoby otwarte dla każdej tabeli, nie nadaje się to dobrze do tabel 10k+ na jednej instancji, co miałoby miejsce w sytuacji wielostanowiskowej na dużą skalę.

Oczywiście, jeśli masz jakiś inny problem, który powoduje inne problemy, zanim dojdziesz do tego poziomu, może to nie być istotne.

DODATKOWO, "sharding" aplikacji multi-tenant jest prawdopodobnie€ być właściwą rzeczą do zrobienia w końcu, gdy aplikacja staje się coraz większa.

Sharding nie oznacza jednak jednej bazy danych (lub instancji) na dzierżawcę, ale jedną na odłamek lub zestaw odłamków, które mogą mieć po kilka dzierżawców. Będziesz musiał odkryć odpowiednie parametry strojenia dla siebie, prawdopodobnie w produkcji (stąd prawdopodobnie musi być dość przestrajalny od samego początku)

€ nie mogę tego zagwarantować.

Możesz zacząć od pojedynczej bazy danych i podzielić ją na partycje w miarę rozwoju aplikacji. Jeśli to zrobisz, jest kilka rzeczy, które polecam:

1) Zaprojektuj bazę danych w taki sposób, aby można było ją łatwo podzielić na partycje. Na przykład, jeśli klienci mają udostępniać dane, upewnij się, że dane są łatwo replikowane w każdej bazie danych.

2) Jeśli masz tylko jedną bazę danych, upewnij się, że jest ona archiwizowana na innym fizycznym serwerze. W przypadku przełączania awaryjnego można przywrócić ruch do tego inny serwer i nadal mieć swoje dane nienaruszone.