Jakie problemy wystąpią podczas tworzenia bazy danych dla każdego klienta?

Pamiętam z podcastów stackoverflow, że Fog Creek korzysta z bazy danych dla klienta Fogbugz . Zakładam, że oznacza to, że serwery Fogbugz na żądanie mają 10 tysięcy baz danych.

Właśnie zaczynamy opracowywać aplikację internetową i mamy podobny problem do rozwiązania (wielu klientów z własnymi odizolowanymi danymi).

Jakich problemów należy się spodziewać przy korzystaniu z bazy danych na klienta? Jak mogę je rozwiązać?

Moje początkowe myśli

Zalety bazy danych na klienta

• Prostszy schemat bazy danych
• Prostsze kopie zapasowe - możesz tworzyć kopie zapasowe dla każdego klienta po kolei, bez faktycznego wpływu na innych klientów.
• Ułatwia eksport danych danego klienta.
• Lepsza wydajność pamięci podręcznej - zapis do jednej z bardziej aktywnych tabel wpływa tylko na jednego klienta, który wykonał zapis.
• Łatwiej skalować na różnych urządzeniach. Na przykład, gdy musimy przejść z 1 do 2 serwerów, po prostu przenosimy połowę naszych klientów na nowy serwer.

Niedogodności

• Czy MySQL może poradzić sobie z 5000 bazami danych? Czy wydajność byłaby do bani?
• Zmiany w schemacie mogą być trudne do zreplikowania we wszystkich bazach danych. Naprawdę musielibyśmy mieć do tego zautomatyzowany plan, taki jak wersjonowanie schematu i skrypt, który rozumie, jak przenieść bazę danych z jednej wersji do drugiej.
• Robienie czegokolwiek wspólnego dla wszystkich naszych klientów może być niezręczne lub niemożliwe
• Podobnie jak powyżej, ale wszelkie analizy, które chcemy przeprowadzić dla wszystkich naszych klientów, mogą być niemożliwe. Jak na przykład powinniśmy śledzić wykorzystanie przez wszystkich klientów?

To rozwiązanie nazywa się projektowaniem wielu dzierżawców, w którym każdy najemca (klient) ma własną bazę danych. Biorąc to pod uwagę, istnieją inne rozważania dotyczące alternatywnego podejścia, którym jest pojedyncza baza danych:

1. Dzięki jednej bazie danych wszyscy muszą być w tej samej wersji bez względu na wszystko. Uaktualnienie niektórych klientów nie jest możliwe. Może to być problematyczne, jeśli klient chce poprawki aplikacji, która nie jest gotowa do szerokiej wersji.
2. Dzięki jednej bazie danych podczas aktualizacji każdy klient nie działa. Jeśli coś pójdzie nie tak, każdy klient ma problemy.
3. Dzięki jednej bazie danych znacznie trudniej jest dławić zasoby. To znaczy, jeśli jeden klient wbija bazę danych, trudniej jest zapewnić im więcej zasobów oddzielnie od wszystkich innych.
4. Znacznie trudniej jest zezwolić użytkownikom na hostowanie własnych wersji aplikacji. Jeśli budujesz rozwiązanie, które będzie wykorzystywane przez duże przedsiębiorstwa, często nie jest to program startowy. Ich dział IT chce mieć pełną kontrolę nad dostępem do systemu.
5. Prawdopodobnie tańsze jest skalowanie baz danych niż skalowanie ich. Tj. Konieczność inwestowania w szybszy sprzęt do obsługi jednej bazy danych, aby rządzić nimi wszystkimi, jest prawdopodobnie droższa niż możliwość skalowania klientów do mniejszych, tańszych serwerów baz danych. Nie mogę tego ostatecznie powiedzieć, ponieważ zależy to w dużej mierze od oprogramowania serwera. Jeśli trzymasz się MySQL, prawdopodobnie jest to prawdą, ponieważ koszty licencjonowania są znikome. Jeśli jednak przejdziesz na przykład na SQL Server, skalowanie w dół staje się znacznie droższe, chyba że korzystasz ze środowiska VPS, a koszty i korzyści w skalowaniu w górę w porównaniu ze skalowaniem w górę. Mogę jednak powiedzieć, że gdy baza danych stanie się bardzo duża, zarządzanie wymaga coraz większego poziomu wiedzy specjalistycznej. Bardzo duże bazy danych wymagają zabawy z wieloma aplikacjami i wypychania niektórych indeksów do różnych wrzecion, aby uzyskać lepszą wydajność. Krótko mówiąc, mogą się bardzo szybko skomplikować.

Posiadanie osobnych baz danych oznacza, że ​​musisz zbudować mechanizm aktualizacji, który pasuje do wersji bazy danych z wersją aplikacji / witryny. Jednak oddzielne bazy danych zapewniają lepszą izolację danych, a IMO mają niższe koszty hostingu. To nie jest rozwiązanie dla wszystkich scenariuszy. Jeśli Twój system nigdy nie miałby być hostowany poza hostingiem i musiałby szybko skalować klientów, a pożądane było posiadanie wszystkich użytkowników w tej samej wersji aplikacji i schematu bazy danych, to z pewnością lepsze byłoby posiadanie jednej bazy danych.

Z mojego doświadczenia wynika, że ​​nie powinieneś tworzyć jednej bazy danych na klienta. Dam ci przykład:

W zeszłym roku pracowałem z 70 bazami danych (dużo mniej niż 5000), każda z tym samym schematem i wszystkimi innymi. Teoretycznie wszystko potoczyłoby się zgodnie z planem (jak wspomniałeś w rozdziale o zaletach), ale w rzeczywistości nie tak bardzo. Mieliśmy wiele problemów z aktualizacją schematów, obsługą użytkowników, aktualizacją oprogramowania, nazywacie to. To było okropne.

Korzystaliśmy z Firebird i zostałem zatrudniony znacznie po wysłaniu produktu, ale to dało mi wiedzę, aby nigdy nie pracować z oddzielnymi bazami danych.

Nie mówię, że nie możesz tego zrobić, mówię, że sprawy mogą pójść bardzo źle i szczerze mówiąc, twoja lista korzyści nie była wystarczająco atrakcyjna, aby zaryzykować. Większość z nich można osiągnąć za pomocą jednej bazy danych.

Prawdopodobnie zechcesz mieć inną bazę danych, aby śledzić, w jakiej wersji jest każdy klient, abyś mógł sprawdzić, które z nich przeszły lub nie przeszły ostatniej rundy modyfikacji.

Skryptowanie aktualizacji nie byłoby takie trudne ... możesz napisać coś, co przegląda katalog baz danych i zastosować niezbędne zmiany, aby doprowadzić każdą bazę do najnowszej wersji, być może pomijając te, które z jakiegoś powodu nie powinny być aktualizowane.

Ponieważ „bazy danych” mysql to tylko schematy, jak zauważył Gajusz, jeśli wszystko działa z tej samej instancji serwera, możesz po prostu określić nazwy tabel, które próbujesz zmodyfikować, lub uzyskać informacje z:

alter schema.table ...
select ... from schema.table

...

Jeśli zaczniesz rozbijać rzeczy na wielu serwerach, nadal możesz napisać skrypt, który łączy się z wieloma serwerami, abyś mógł zastosować wszystkie zmiany; dla celów analitycznych ponownie można ustawić kilka łączy do bazy danych za pomocą tabel stowarzyszonych w głównej bazie danych, aby uzyskać dostęp do danych z jednego miejsca, tak jak po prostu czytać z tabel.

...

Pamiętaj też, że nie używają mySQL do wymiany stosów, używają SQL Server.

I nie mam pojęcia, jaki byłby narzut wydajności w mysql na taką skalę, nie sądzę, żebym kiedykolwiek przekroczył 30 „baz danych” w mysql.

Mam klienta hostingowego Web / DB, który ma ponad 750 baz danych klientów z taką samą liczbą tabel (162) i tymi samymi strukturami tabel. Łącznie wszystkie dane klientów mojego klienta wynoszą łącznie 524 GB (95% InnoDB)

Wyobraź sobie, że wszystkie te bazy danych konkurują o 13G puli buforów innodb na dziewięciu serwerach DB poprzez cykliczną replikację. Skalowanie przy takiej konfiguracji sprzętowej nie wystarczyło. Natychmiast zalecamy klientowi zwiększenie skali.

Niedawno przenieśliśmy tego klienta na 3 serwery DB o znacznie większej mocy (za wszelką cenę trzymaj się z dala od SSD w środowiskach o wysokim zapisie, ZAWSZE !!!). Uaktualniliśmy je z MySQL 5.0.90 do MySQL 5.5.9. Dramatyczne różnice były widoczne niemal natychmiast.

Skalowanie należy również wziąć pod uwagę, ponieważ jeśli setki klientów uderzają w te same zasoby pamięci i dysku, skalowanie zmniejsza ich użycie liniowe (O (n)), gdzie n zależy od liczby serwerów DB w środowisku multimaster.

W przypadku mojego klienta moja firma redukuje go z 9 serwerów DB (Quad Code, 32 GB RAM, 824G RAID10) do szybszych serwerów DB (Dual HexaCore [to prawda 12 procesorów], 192 GB RAM, 1,7 TB RAID10) MySQL 5.5 .9 (w celu wykorzystania wielu procesorów). Ponadto wyobraź sobie 150 GB puli buforów innodb w 50 partycjach po 3 GB każda (Wiele pul buforów InnoDB to nowa funkcja w MySQL 5.5). Mniejsza skala, ale ogromna skala, działała dla unikalnej infrastruktury mojego klienta.

MORAL OF THE STORY : Zwiększanie lub zmniejszanie nie zawsze jest rozwiązaniem, jeśli masz źle zaprojektowane stoły. Mam na myśli to: jeśli strony indeksowe mają przekrzywioną populację kluczy dla indeksów wielokolumnowych, zapytanie o klucze z krzywych części indeksów prowadzi do skanowania tabeli po skanowaniu tabeli lub przynajmniej indeksów, które nigdy nie są używane z powodu wykluczenia przez zapytanie MySQL Optymalizator Po prostu nie ma substytutu dla właściwego projektu.

MySQL tworzy bazy danych w oddzielnych katalogach, więc wiele zależy od systemu operacyjnego i liczby obsługiwanych folderów / plików. Nie powinno to stanowić problemu w przypadku nowoczesnych systemów operacyjnych, ale właśnie z tego wynika wiele wąskich gardeł.

Nic nie mówi, że musisz obsługiwać różne wersje bazy danych lub aplikacji. Co jest złego w zwykłym izolowaniu danych, wykonując jedną bazę danych na klienta i mając jedną wersję bazy danych i aplikacji? Oczywiście każdy klient bazy danych musiałby zostać sklonowany z szablonu bieżącej wersji roboczej. Z punktu widzenia bezpieczeństwa i izolacji danych uważam, że jest to idealne rozwiązanie.

Jedynym minusem, jaki widzę, jest konieczność ręcznej aktualizacji każdej bazy danych podczas tworzenia nowej wersji. Można to jednak łatwo zautomatyzować.