Czy istnieje ograniczenie liczby baz danych, które można umieścić na jednym serwerze SQL?

Konfiguruję system SaaS, w którym planujemy udostępnić każdemu klientowi własną bazę danych. System jest już skonfigurowany, dzięki czemu możemy łatwo skalować się do dodatkowych serwerów, jeśli obciążenie staje się zbyt duże; mamy nadzieję, że będziemy mieć tysiące, a nawet dziesiątki tysięcy klientów.

pytania

• Czy istnieje jakieś praktyczne ograniczenie liczby mikrodanych, które możesz / powinieneś mieć na jednym serwerze SQL?
• Czy może to wpłynąć na wydajność serwera?
• Czy lepiej jest mieć 10 000 baz danych po 100 MB każda, czy jedną bazę danych o pojemności 1 TB?

Dodatkowe informacje

Kiedy mówię „mikro-bazy danych”, tak naprawdę nie mam na myśli „mikro”; Chodzi mi o to, że naszym celem są tysiące klientów, więc każda pojedyncza baza danych stanowiłaby tylko jedną tysięczną lub mniej całkowitej ilości danych. W rzeczywistości każda baza danych miałaby około 100 MB znaku, w zależności od tego, ile zużywa.

Głównym powodem korzystania z 10 000 baz danych jest skalowalność. Faktem jest, że V1 systemu ma jedną bazę danych i mieliśmy pewne niewygodne momenty, gdy DB obciążało się.

To obciążało procesor, pamięć, wejścia / wyjścia - wszystkie powyższe. Mimo że rozwiązaliśmy te problemy, uświadomiliśmy sobie, że w pewnym momencie, nawet przy najlepszym indeksowaniu na świecie, jeśli odniesiemy taki sukces, jaki mamy nadzieję, po prostu nie możemy umieścić wszystkich naszych danych w jednym wielkim szczerciu ' Baza danych. W przypadku wersji V2 dzielimy fragmenty, abyśmy mogli podzielić obciążenie między wiele serwerów DB.

Ostatni rok spędziłem na opracowywaniu tego odłamkowego rozwiązania. Jest to jedna licencja na serwer, ale i tak jest to załatwione, ponieważ używamy maszyn wirtualnych na platformie Azure. Powodem, dla którego pojawia się teraz pytanie, było to, że wcześniej oferowaliśmy tylko duże instytucje i zakładaliśmy każdą z nich sami. Nasze następne zamówienie to model samoobsługowy, w którym każda osoba posiadająca przeglądarkę może zarejestrować się i stworzyć własną bazę danych. Ich bazy danych będą znacznie mniejsze i znacznie liczniejsze niż duże instytucje.

Wypróbowaliśmy elastyczne pule bazy danych SQL Azure . Wydajność była bardzo rozczarowująca, więc wróciliśmy do zwykłych maszyn wirtualnych.

Pracowałem na serwerach SQL z 8 do 10 tysiącami baz danych w jednym wystąpieniu. To nie jest ładne.

Ponowne uruchomienie serwera może potrwać nawet godzinę. Pomyśl o procesie odzyskiwania dla 10 000 baz danych.

Nie można użyć programu SQL Server Management Studio do niezawodnego zlokalizowania bazy danych w Eksploratorze obiektów.

Kopie zapasowe są koszmarem, ponieważ aby kopie zapasowe były opłacalne, musisz mieć funkcjonalne rozwiązanie do odzyskiwania po awarii. Mamy nadzieję, że Twój zespół świetnie radzi sobie ze skryptowaniem wszystkiego .

Zaczynasz robić takie rzeczy, jak nazywanie baz danych liczbami, jak M01022i T9945. Próba upewnienia się, że pracujesz w odpowiedniej bazie danych, np. M001022Zamiast M01022, może być denerwująca.

Przydzielanie pamięci dla tak wielu baz danych może być dręczące; W efekcie SQL Server wykonuje wiele operacji we / wy, co może znacznie obniżyć wydajność. Rozważ system, który rejestruje szczegóły zużycia węgla w 4 tabelach dla 10 000 firm. Jeśli zrobisz to w jednej bazie danych, potrzebujesz tylko 4 tabel; jeśli zrobisz to w 10 000 bazach danych, nagle potrzebujesz 40 000 tabel w pamięci. Obciążenie związane z obsługą tej liczby tabel w pamięci jest znaczne. Każde projektowane zapytanie, które zostanie uruchomione dla tych tabel, będzie wymagało co najmniej 10 000 planów w pamięci podręcznej planu, jeśli jest używanych 10 000 baz danych.

Powyższa lista to tylko niewielka próbka problemów, które musisz zaplanować, pracując w tego rodzaju skali.

Prawdopodobnie wystąpią problemy z uruchomieniem usługi SQL Server, co może powodować błędy kontrolera usług. Możesz samodzielnie wydłużyć czas uruchamiania usługi, utwórz następujący wpis rejestru:

Podklucz: HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control
Nazwa: ServicesPipeTimeout
Wpisz: REG_DWORD
Dane: liczba milisekund przed upływem limitu czasu podczas uruchamiania usługi

Na przykład, aby poczekać 600 sekund (10 minut) przed upływem limitu czasu usługi, wpisz 600000.

Od czasu napisania odpowiedzi zdałem sobie sprawę, że pytanie dotyczy platformy Azure. Być może robienie tego w bazie danych SQL nie jest tak problematyczne; być może jest to bardziej problematyczne. Osobiście prawdopodobnie zaprojektowałbym system z wykorzystaniem jednej bazy danych, być może podzielonej pionowo na wiele serwerów, ale na pewno nie jednej bazy danych na klienta.

Są więc zalety i wady obu metod. Nie wiedząc więcej o Twojej aplikacji lub usługach, które chcesz świadczyć, nie będę w stanie udzielić ostatecznej odpowiedzi, ale podzielę się swoimi przemyśleniami na ten temat.

Mój przypadek, dlaczego warto używać 1 bazy danych dla wszystkich klientów.

Plusy

• Łatwa konserwacja. Posiadanie jednego DB oznacza, że ​​musisz wykonać zadanie konserwacyjne tylko w jednym miejscu zamiast w wielu. Wyobraź sobie koszmar obsługi 1000 różnych baz danych, których kopie zapasowe chcesz wykonać. Co powiesz na aktualizację statystyk na 1000 DB lub przebudowanie indeksów lub DBCC CHECKDB?

• Wdrażanie kodu. Załóżmy, że masz problem z procedurą przechowywaną w kodzie aplikacji lub raportowaniu. Musisz dokonać szybkiej zmiany ... Teraz musisz wdrożyć tę zmianę na ponad 1000 baz danych. Nie, dziękuję, wolałbym nie.

• Dobra widoczność. Wyobraź sobie, że SSMS próbuje otworzyć ponad 1000 DB (dreszcz) . Praktycznie sprawiłoby, że problem byłby bezużyteczny, a otwarcie i renderowanie SSMS zająłoby zaskakująco dużo czasu. Pamiętaj, że jeśli jesteś w stanie wymyślić porządną konwencję nazewnictwa.

Cons

• Bezpieczeństwo. Łatwiej byłoby uniemożliwić ludziom przeglądanie danych innych klientów, gdybyś miał je jako osobne bazy danych. Istnieją jednak bardzo proste rzeczy, które możesz zrobić, aby temu zapobiec.

• Występ. Można argumentować, że ograniczenie go do jednego DB na klienta oznacza, że ​​SQL Server będzie musiał skanować mniej danych, aby uzyskać informacje, o które pytasz. Jednak przy odpowiedniej strukturze danych i dobrym indeksowaniu (i możliwym partycjonowaniu) możesz to wyeliminować jako problem, jeśli zostanie to wykonane ostrożnie. Poleciłbym dać każdej tabeli, która zawiera dane specyficzne dla klienta, jakiś sposób prowadzący CompanyIDdo zmniejszenia tego narzutu.

Ostatecznie myślę, że najlepszym rozwiązaniem jest posiadanie jednego DB dla Twojej aplikacji i po prostu dzielenie danych klientów w samym DB. Problemy, które ci to przyniesie, nie będą niczym w porównaniu z koszmarem zarządzania ponad 1000 bazami danych.

Specyfikacje maksymalnej pojemności dla SQL Server stwierdzają, że istnieje limit 32 767.

Jeśli chodzi o to, czy wpłynie to na wydajność, odpowiedź brzmi tak, ale sposób, w jaki wpłynie na wydajność i czy będzie znaczny, będzie zależeć od niezliczonych czynników.

Wybrałbym jedną bazę danych, chyba że istnieje dobry powód, aby podzielić ją na 10 000 baz danych. Jedna kopia zapasowa czy 10 000 kopii zapasowych? Jedna kontrola integralności, czy 10 000? Może istnieć dobry powód, aby użyć 10 000 małych baz danych, ale nie podałeś wystarczających szczegółów, aby to ustalić. Pytanie, które zadałeś, jest dość szerokie i po prostu nie ma wystarczających informacji, aby ktokolwiek wiedział, jaka jest najlepsza odpowiedź.

Mówisz tutaj o architekturze z wieloma dzierżawcami a architekturą z wieloma instancjami . Po prostu przywołuję te warunki, ponieważ nie używasz ich w swoim pytaniu, ale to, o czym rozmawiasz, nazywa się, a jeśli po prostu podłączysz do Google „architekturę wielu dzierżawców”, znajdziesz bogactwo zasobów i dyskusji o tym, napisano na nim całe książki.

Kilka dobrych zasobów dotyczących SQL Servera tutaj:

https://msdn.microsoft.com/en-us/library/ff966499.aspx

https://docs.microsoft.com/en-us/azure/sql-database/sql-database-design-patterns-multi-tenancy-saas-applications

Byłbym z innymi odpowiedziami, ponieważ zdecydowanie skłaniałbym się ku wielu dzierżawcom jako domyślnemu, chyba że masz ważne powody, by faworyzować wiele wystąpień.

Aby skalować, nie trzeba dzielić na tysiące indywidualnych baz danych klientów, istnieje wiele innych sposobów, które mogą być lepsze. Jak klastrowanie, replikacja, dzielenie na fragmenty, partycjonowanie itp. Nie wymyślaj ponownie koła. Nie ma nic nieodłącznego, co mówi, że musisz to ręcznie rozdzielić na poziomie pojedynczego klienta, a faktycznie może to znacznie zwiększyć koszty dodawania każdego nowego klienta.

Mówisz o „milionach” klientów, myślisz o jakimkolwiek wielkoskalowym oprogramowaniu chmurowym jako usłudze, Gmailu, cokolwiek, nie wydaje ci się, żeby tworzyli zupełnie nową bazę danych dla każdej nowej rejestracji, prawda?

Mogą istnieć powody, dla których chcesz to ułatwić, na przykład, jeśli sprzedajesz produkt klientowi, który MUSI mieć go hostować we własnej infrastrukturze. Ale jako ogólna zasada SAAS, domyślnie należy zastosować architekturę wielodostępną.

Jedną z wad, które widzę w przypadku sugestii pojedynczej bazy danych, jest wycofywanie danych - jeśli masz bazę danych dla każdego najemcy, możesz przywrócić dane każdego klienta niezależnie (i do określonego momentu). Jeśli wszystkie znajdują się w jednej bazie danych, staje się to znacznie trudniejsze (i znacznie bardziej podatne na błędy, ponieważ prawdopodobnie trzeba tego dokonać za pomocą instrukcji INSERT / UPDATE / DELETE).

Dziękuję wszystkim, którzy odpowiedzieli - naprawdę doceniam punkty, o których mi pomyślałeś. Mam ogólne wrażenie, że preferowana jest jedna baza danych, ale chciałbym dodać pewne punkty równoważące na korzyść architektury dzielonej i odpowiedzieć na niektóre obawy, o których wspominali inni ludzie.

Motywacja do dzielenia

Jak wspomniano w (zaktualizowanym) pytaniu, dążymy do masowej sprzedaży na całym świecie, z dosłownie milionami użytkowników. Przy najlepszym sprzęcie i indeksowaniu na świecie pojedynczy serwer DB nie wytrzyma obciążenia, więc musimy być w stanie dystrybuować go na wielu serwerach. A kiedy musisz sprawdzić, na którym serwerze są dane danego klienta, nie jest już dużo pracy, aby dać im dedykowaną bazę danych, co upraszcza, utrzymując porządek w segregacji danych.

Odpowiedź na obawy

• Ponowne uruchomienie serwera zajmuje dużo czasu: OK, ale podczas normalnej pracy nie zamierzamy restartować żadnych serwerów. System ostatecznie musi być online 24 godziny na dobę, 7 dni w tygodniu, więc jeśli będziemy mieli przestoje, to i tak będzie musiało zostać zaplanowane.
• Kopie zapasowe / odzyskiwanie po awarii: Używamy CloudBerry, który automatyzuje wszystko. Żaden problem.
• Nazewnictwo baz danych / lokalizowanie ich w SSMS: Konwencja nazewnictwa jest łatwa, oparta tylko na nazwie klienta. Dodaj numery seryjne, jeśli nazwy są wspólne.
• Konserwacja: Jeśli każda baza danych jest tak mała, jak to sobie wyobrażam, nie powinno być potrzeby ręcznej odbudowy indeksów.
• Wdrażanie kodu: używamy Entity Framework, więc każda zmiana schematu będzie automatycznie wdrażana do każdej bazy danych z nowymi wersjami. Prawdą jest jednak, że jeśli odkryjemy problem związany z wydajnością, który można naprawić za pomocą prostej modyfikacji indeksu, nie jest tak łatwo go wypchnąć. Z drugiej strony, ponieważ każda baza danych jest tak mała, jest mało prawdopodobne, że wystąpią problemy z wydajnością showstopper na odłamkach produkcyjnych. Wspólna baza danych pozostaje pojedynczą bazą danych, do której te obawy nie mają zastosowania.

Z przyjemnością odpowiem od ciebie w komentarzach, jeśli uważasz, że czegoś mi brakuje!