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?
database-design
sql-server-2012
NibblyPig
źródło
źródło
Odpowiedzi:
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.
źródło
Polecam przeczytać Multi-Tenant Data Architecture , oficjalny dokument omawiający dostępne opcje oraz zalety i wady. Podsumowując, daje trzy opcje:
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:
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.
źródło
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ł.
źródło