Czy to dobry pomysł, aby użyć jednej bazy danych dla ponad 50 000 sklepów?

Wiem, że Shopify używa tylko jednej bazy danych dla wszystkich sklepów. Ale w jaki sposób mogą obsługiwać swoją bazę danych przy tak dużych danych? Czy to dobry pomysł, aby użyć jednej bazy danych dla ponad 50 000 sklepów?

Uwaga: odpowiadam z perspektywy programu SQL Server, dlatego wymieniam niektóre koncepcje specyficzne dla SQL Server, ale uważam, że wszystkie te koncepcje mają odpowiedniki na innych głównych platformach RDBMS, z podobnymi korzyściami i ograniczeniami.

Prawdopodobnie nadal będę edytować tę odpowiedź, gdy myślę o innych potencjalnych zaletach i wadach.

Cóż, tak naprawdę zależy to od schematu, objętości itp. Czym dokładnie jest sklep? Czym różni się od przechowywania danych około 50 000 kotów lub 50 000 produktów lub 50 000 orzechów skrzydełkowych?

Istnieje kilka powodów (innych niż sam aspekt wielkości), dlaczego możesz nie chcieć przechowywać danych dla 50 000 różnych klientów w jednej bazie danych, jeśli rzeczywiście dane mogą być całkowicie posegregowane przez klienta (nie włączając tabel wyszukiwania takich jak kody pocztowe lub tabele specyficzne dla aplikacji, które mogłyby przejść do jednej centralnej bazy danych):

• jeśli jeden klient przerośnie aplikację, nie ma łatwego sposobu na wyodrębnienie tylko swoich danych i przeniesienie ich do innej instancji, serwera itp. w celu skalowania, chyba że planujesz z wyprzedzeniem i partycjonujesz na coś podobnego CustomerIDi masz 50 000 grup plików (jesteś ograniczony w każdym razie do 15 000 partycji lub 1000, jeśli korzystasz ze starszej wersji programu SQL Server, a zbyt duża grupa plików może być katastrofalna ). Należy również pamiętać, że partycjonowanie wymaga wersji Enterprise.

• jeśli okaże się, że wszyscy twoi klienci są po prostu zbyt duzi dla tego przypadku, skalowanie oznacza pozyskiwanie nowego sprzętu i przenoszenie do niego całej bazy danych (i potencjalnie robienie tego ponownie).

• usunięcie klienta może być równie bolesne, ponieważ będziesz musiał usunąć niektóre% wierszy z bardzo dużych tabel, a to nie będzie tanie.

• prawdopodobnie będziesz mieć szeroką dystrybucję danych klientów (jeden klient z miliardem wierszy, inny klient z 5000). Może to prowadzić do takich rzeczy, jak wąchanie parametrów i szkodliwa wydajność obejmująca liczność i jakość planu (ponieważ prawdopodobnie ponownie użyjesz tych samych planów dla tych samych zapytań wobec bardzo różnych zestawów danych).

• wszyscy twoi klienci podlegają dokładnie takim samym umowom SLA i HA / DR. Albo masz całą bazę danych w trybie pełnego odzyskiwania z n-minutowymi kopiami zapasowymi dziennika, albo jesteś prosty i polegasz na pełnych + różnicowych kopiach zapasowych. Jeśli musisz przywrócić z powodu błędu klienta lub chcesz przywrócić bazę danych do punktu w czasie, wpływa to na każdego klienta.

• mogą wystąpić błędy w pobieraniu danych - błędy, w których na przykład klauzule mogą prowadzić do tego, że jeden klient widzi dane innego klienta lub wszystkie dane innych klientów.

• mogą wystąpić konsekwencje prawne (niektóre firmy będą miały ścisłe wymagania, aby nie umieszczać ich danych w tej samej bazie danych, co każda inna firma, a zwłaszcza konkurentów).

• jeśli bezpieczeństwo danych jednego klienta jest ważne, wówczas osiągnięcie tego jest znacznie łatwiejsze przy użyciu separacji bazy danych niż separacji w tabeli.

Niektóre zalety posiadania każdego klienta w osobnej bazie danych (lub przynajmniej posiadania wielu baz danych, każda dla grupy klientów):

• jeśli chodzi o rozmiar, zajmie to mniej więcej taki sam rozmiar na dysku.
• skalowanie jest łatwiejsze, ponieważ możesz po prostu przenieść bazę danych (lub wiele) na inny serwer.
• usunięcie klienta i wszystkich jego danych jest mniej więcej równe DROP DATABASE.
• używasz więcej pamięci na plany (lub masz mniej planów w pamięci podręcznej na klienta), ale przynajmniej te plany są odpowiednie dla danych w ich odpowiednich bazach danych i są mniej podatne na problemy ze statystykami / wąchaniem parametrów.
• możesz łatwo mieć różne SLA i plany DR, umieszczając niektóre bazy danych w całości, a inne w prosty sposób. Cofanie lub przywracanie do określonego momentu wpływa tylko na tego klienta.
• możesz z łatwością umieszczać różne bazy danych (powiedzmy, twoi klienci o wysokim priorytecie) na szybszych I / O. Możesz to zrobić w jednej bazie danych z aplikacjami, ale jest to o wiele trudniejsze do zarządzania (przynajmniej IMHO).

Pewne wady:

• pomijając rozmiar, prawdopodobnie nie będziesz chciał mieć 50 000 baz danych w jednym wystąpieniu programu SQL Server, więc prawdopodobnie oznacza to skalowanie do wielu serwerów.
• czas uruchamiania wydłuża się, ponieważ uruchomienie bazy danych wiąże się z pewnymi narzutami.
• aplikacja musi być nieco mądrzejsza - zamiast mieć CustomerID na klauzuli where, musi dynamicznie łączyć się z bazą danych CustomerID. Nie jest to trudne przy odpowiednim środkowym poziomie, ale jest zmianą.
• tak, masz wiele kopii tych samych tabel i procedur, ale kod i schemat są identyczne w bazach danych, tylko dane są inne. Wdrażanie zmian kodu / schematu jest teraz tylko pętlą zamiast pojedynczego wykonania.
• konserwacja jest nieco inna, gdy zarządzasz 50 000 baz danych - znowu ogólny rozmiar jest mniej więcej taki sam, ale proces musi się zmienić - nie możesz po prostu defragmentować / ponownieindeksować / wykonać kopii zapasowej wszystkich 50 000 baz danych na raz. Powiedziawszy to, w poprzednim zadaniu zarządzałem instancjami z 500-1 000 identycznych baz danych, a różnica między zarządzaniem 3 identycznymi bazami danych i 750 identycznymi bazami danych to po prostu czas.