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

49

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?
Rik Heywood
źródło
2
Pamiętaj, że „baza danych” oznacza różne rzeczy dla różnych osób. W świecie Oracle baza danych na użytkownika byłaby ogromną nadwyżką. Ale w MySQL „baza danych” jest synonimem „schematu”.
Gajusz
Mam na myśli to w sensie mysql. USE CompanyData;
Rik Heywood
1
Microsoft ma szczegółowy artykuł na temat architektury danych dla wielu dzierżawców .
Nick Chammas,
nie powiedziałbym, że wersjonowanie schematu jest wadą ... więcej pracy, ale ogólnie lepsza
Neil McGuigan

Odpowiedzi:

41

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.

Tomasz
źródło
2
Prowadzę usługi sieciowe z zarówno wspólną bazą danych, jak i oddzielnymi konfiguracjami baz danych dla wielu dzierżawców. Są chwile, w których oba są właściwym wyborem. W aplikacji, w której mam osobną bazę danych dla klienta, znalazłem dokładnie te same 5 powodów, dla których był to właściwy wybór dla tej aplikacji.
Dan Grossman
Niedawna bezserwerowa baza danych w chmurze Aurora firmy Amazon rzekomo automatycznie zapewnia więcej zasobów, gdy jest potrzebna do większego obciążenia, i wydaje się, że zachęcają do projektowania pojedynczej bazy danych. Ale nie do końca to rozumiem. Myślę jednak, że pójdę z jednym DB, z osobnymi tabelami dla każdego użytkownika. To może ułatwić podział ich na osobne bazy danych, jeśli zajdzie taka potrzeba, i ułatwi agregowanie zapytań względem wszystkich danych użytkownika.
Buttle Butkus
Tylko na co należy uważać: mam wszystkich moich klientów w jednym pliku db i używam warstwy kodu db, która zapewnia, że ​​każde zapytanie zawiera kryteria specyficzne dla klienta. Niebezpieczne jest to, że musisz wyjść poza warstwę bazy danych, aby zrobić coś bardzo konkretnego - na przykład straszne, skomplikowane zapytanie, w którym dane mogą dostać się z nieoczekiwanego miejsca.
Enigma Plus
14

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.

eiefai
źródło
Wdrożyliśmy bazę danych wielu ofert, która obsługuje kilku klientów. Skończyło się na tym, że klienci zaczęli chcieć niestandardowych wyników. Aby rozwiązać ten problem, sklonowaliśmy przechowywane procy i nadaliśmy im unikalne prefiksy nazw klientów, a następnie wywołaliśmy je z poziomu aplikacji. Z drugiej strony sprzedaliśmy 150 sklepów internetowych, każdy z własną oddzielną bazą danych (97% to samo). Oba można zrobić, to zależy od sytuacji.
Michael Riley - AKA Gunny
Miły. Nie twierdzę, że nie da się tego zrobić, tylko że to nie jest tak proste, jak się wydaje, dobrze dla ciebie Gunny.
eiefai
1
Byłoby miło, gdybyś mógł podać przykłady tego, co dokładnie poszło nie tak. Pewnie trudniej jest aktualizować wszystkie bazy danych, ale musimy zdecydować, że musimy być w stanie zmierzyć zalety i wady.
Boris Callens,
9

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.

Joe
źródło
Dlaczego nie przechowywać tabeli informacji o wersji w samym db?
Boris Callens,
@ Boris: ponieważ znacznie trudniej jest osiołowi połączyć się z każdą bazą danych i poprosić o jej wersję, gdy masz dziesiątki lub setki baz danych. Śledzenie siebie nie jest złym pomysłem, ale warto też mieć główną listę dla DBA
Joe
7

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.

RolandoMySQLDBA
źródło
2
Wiem, że to naprawdę stare, ale zastanawiam się, jakie jest uzasadnienie twojego komentarza na temat dysków SSD w środowiskach o wysokim poziomie zapisu. Czy możesz mnie oświecić?
elixenide
4
@EdCottrell Domyślam się, że było to ostrzeżenie o ograniczonych zapisach na dyskach SSD. W pewnym momencie powoduje to dyskietkę do tego stopnia, że ​​nie można jej już używać, wierzę, że w ciągu ostatnich kilku lat TRIM i inna technologia została wypalona w układach kontrolera SSD, aby w większości rozwiązać te problemy, więc zapis SSD nie stanowi większego problemu, ale jestem pewien, że nadal może być problemem.
shaunhusain
2

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ł.

David Hall
źródło
1

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ć.

Sean Siegel
źródło