W którym momencie jedna baza danych na klienta staje się niewykonalna?

W jednym z naszych systemów mamy poufne dane klienta i przechowujemy dane każdego klienta w osobnej bazie danych. Mamy około 10-15 klientów dla tego systemu.

Jednak opracowujemy nowy system, który będzie miał 50-100 klientów, może więcej. Myślę, że w tym przypadku może być niewykonalne posiadanie jednej bazy danych na klienta (do przechowywania poufnych zapisów i historii kontroli). Nie wiem jednak, czy jest to całkowicie normalne, czy nie, czy istnieje inny sposób utrzymania bezpieczeństwa.

Masz jakieś przemyślenia na ten temat?

Zarządzanie 100 lub 500 bazami danych tak naprawdę nie różni się tak bardzo od zarządzania 5 lub 10 - wystarczy zastosować automatyzację i wprowadzić plan skalowalności (i nie planować korzystania z funkcji kosztownych dla bazy danych, takich jak tworzenie kopii lustrzanych we wszystkich klienci).

W mojej poprzedniej pracy korzystaliśmy z tej architektury i nigdy nie pomyślałem o połączeniu dwóch klientów w jedną bazę danych, nawet jeśli niektóre wyzwania mogą być „trudne”.

Dużymi zaletami są niezależne modele odzyskiwania ( amogą być proste, bpełne itp.), Możliwość przywracania klienta do określonego momentu (lub całkowitego usunięcia) bez zakłócania pracy innych, możliwość płynnego przenoszenia klienta o dużych zasobach do własnego magazynu lub na zupełnie inny serwer z bardzo małą przezroczystością (aktualizujesz plik konfiguracyjny lub tabelę, która informuje aplikację, gdzie znaleźć tego klienta).

W kilku postach odnoszę się do kilku zastrzeżeń i / lub podejścia do problemów:

• Obsługa rosnącej liczby najemców w architekturze baz danych wielu dzierżawców

• Baza danych wielu dzierżawców korzystająca z SQL Server 2008?

• Automatyzacja tworzenia kopii zapasowych dużej liczby baz danych

To powiedziawszy, nie sądzę, aby ktokolwiek z nas mógł powiedzieć , w którym momencie zarządzanie staje się dla ciebie niepraktyczne - po prostu wiedz, że niezależnie od konkretnych napotkanych wyzwań możesz zapytać o te problemy indywidualnie.

Polecam przeczytać Multi-Tenant Data Architecture , oficjalny dokument omawiający dostępne opcje oraz zalety i wady. Podsumowując, daje trzy opcje:

• osobne bazy danych
• osobne schematy
• wspólny schemat

Jesteś teraz na osobnym etapie DB, który oferuje najlepszą separację (izolację między najemcami), ale jest najtrudniejszy do zarządzania. W miarę, jak wyrastasz na setki najemców, zdajesz sobie sprawę, że logistyka administrowania setkami DB nie jest trywialna. Pomyśl o przywracaniu kopii zapasowych (lokalizacja plików, zadań, harmonogramów itp.). Zastanów się, jak będziesz monitorować i zarządzać alokacją plików, wykorzystywanym miejscem na dysku i wzrostem bazy danych w setkach baz danych. Zastanów się, jaki będzie scenariusz dotyczący wysokiej dostępności / odzyskiwania po awarii w najbliższej przyszłości z udziałem 1000 najemców? 1000 kopii lustrzanych DB, 1000 sesji wysyłania dziennika? Pomyśl, co się stanie, jeśli za 6 miesięcy Twój zespół deweloperów przyjdzie do Ciebie i powie „Wiem, jak dać tę niesamowitą funkcję naszemu produktowi, użyjemy replikacji transakcyjnej!”, Co powiesz? „jasne, pozwól mi skonfigurować 500 wydawców,„! Nie jest niemożliwe zarządzanie setkami baz danych, ale jeśli masz na to ochotę, lepiej dopracuj swoje umiejętności PowerShell i przestań używać narzędzi do zarządzania interfejsem w tej chwili .

Ponadto należy wziąć pod uwagę, że wiele (setki) baz danych ma mierzalny wpływ na wydajność i koszt:

• fizycznego miejsca na dysku jest mniej efektywnie wykorzystane (każda baza danych musi mieć trochę wolny pokój, trzeba to wolny pokój pomnożonej przez liczbę DB)
• Nie ma możliwości utworzenia dedykowanego dysku dziennika do zadań intensywnie zapisujących. Będziesz musiał przenieść wszystkie te pliki LDF na jeden (lub więcej) dysk SSD
• zapisywanie dziennika będzie mniej wydajne w przypadku częstych zatwierdzeń, ponieważ są one rozłożone na wiele pojedynczych rekordów bloków dziennika w porównaniu z agregacją w jeden (otrzymamy niewykorzystane bloki dziennika). Zobacz Co to jest LSN: numer sekwencji dziennika, aby zrozumieć, o czym mówię.

Oddzielne bazy danych mają pewne zalety, choć wynikają z izolacji, a główną zaletą jest niezależne tworzenie kopii zapasowych / przywracanie.

Scenariusz podobny do twojego jest jednak idealnym kandydatem do baz danych SQL Azure . Bez administracji miejsca na dysku, bez konieczności podawania HA / DR, rosną do setek / tysięcy baz danych itp.

W mojej poprzedniej pracy hostowaliśmy nie tylko jedną bazę danych na klienta - w większości przypadków było to coś więcej! Kiedy wyszedłem, w jednym klastrze MariaDB działało ponad 4500 baz danych, prawie 7000 w innym (ironicznie mniejszym) klastrze i 4 „odłamki” (całkowicie oddzielne, niezależne serwery sieciowe i bazy danych, nawet w całkowicie oddzielnym centrum danych), każdy hostujący 200-500 baz danych na jednym serwerze MySQL. I ta firma wciąż rośnie w dobrym stanie.

Długa i krótka jest to, że sukces tej firmy dowodzi, że taka architektura jest rzeczywiście wykonalna. (Zastrzeżenie: W przeciwieństwie do pozornych korzyści w izolacji dzięki zastosowaniu osobnych baz danych, dostęp do wszystkich danych uzyskano dzięki trzem ściśle powiązanych aplikacjom, z których wszystkie korzystały z tego samego użytkownika bazy danych / przepustki! Podejrzewam, że wydajność mogłaby ulec nieznacznemu pogorszeniu, gdyby każdy klient miał osobnego użytkownika / przepustkę - ale tylko nieznacznie.)

Z moich doświadczeń ścisłej współpracy z administratorami sys (technicznie rzecz biorąc, byłem programistą w firmie, ale w rzeczywistości byłem najlepszym DBA, jaki mieli, i jedyną osobą, która wiedziała, jak skonfigurować zaporę ogniową!), Związane z wydajnością dotyczy sprowadzonych do współbieżnych dostępów, złożoności / czasu zapytania, wydajności indeksu itp. - innymi słowy, wszyscy zwykli podejrzani, innymi słowy, i liczba baz danych na serwerze nie odgrywała żadnej widocznej roli, wniosek potwierdzony przez wysoko opłacanego specjalistę konsultanci konsultowaliśmy się regularnie.

Najważniejsze jest to, że powinieneś skupić się na swojej aplikacji, na infrastrukturze, a nie na liczbie posiadanych baz danych. Wszystkie pozostałe czynniki będą wystarczające, abyś był zajęty rozwiązywaniem problemów z wydajnością i wąskich gardeł.