Jedna duża baza danych a kilka mniejszych

Mamy sytuację, w której możemy (A) wdrożyć instancje aplikacji w jednej bazie danych MySQL przy użyciu prefiksu tabeli lub (B) użyć różnych baz danych MySQL dla każdej instancji aplikacji, na przykład:

Ustawić":

central_database
  app1_table1
  app1_table2
  app1_tablen
...
  appn_table1
  appn_table2
  appn_tablen

Efektem końcowym jest duża db z wieloma tabelami.

Konfiguracja „B”:

app1_db
  table1
  table2
  tablen

...

appn_db
  table1
  table2
  tablen

Rezultatem końcowym jest wiele baz danych z niektórymi tabelami.

Wszystkie rzeczy są równe (np. Ilość danych, liczba wystąpień aplikacji itp.), Jakie są zalety i wady korzystania z obu metod? Co byłoby niekorzystne dla wydajności i konserwacji bazy danych? Aplikacja oparta jest na PHP 5, działa na Apache 2.x, a my MySQL 5.x.

Wielkie dzięki za poświęcony czas i przemyślenia!

Prowadziłem system z najlepszą częścią tysiąca baz danych, rozproszonych na wielu serwerach. Wszystkie miały identyczną strukturę i zostały zsynchronizowane z bazą danych szablonów, która była na każdym komputerze.

To pozwoliło mi na migrację baz danych z jednej bazy danych na drugą, jeśli ktoś był nadmiernie przeciążony, a ponieważ zmieniła się mieszanka klientów, mogłem tworzyć nowe bazy danych na różnych serwerach, aby ładować równowagę między serwerami. To była największa zaleta, jaką uzyskałem z systemu, ponieważ miałem wiele dużych brył cyny wykonujących wiele skomplikowanych zapytań jednocześnie na osobnych serwerach.

Wspaniałą rzeczą jest to, że możesz dodawać serwery do konfiguracji z własną prędkością, ponieważ każdy serwer zaczyna się przeciążać, dodawać kolejne do miksu, migrować trochę dbs na nowy serwer i ładnie zestaw serwerów z równoważeniem obciążenia. Naprawdę ładny i prosty sposób na dodanie skali do systemu, kiedy i kiedy jest to wymagane!

Powodem, dla którego zdecydowałem się na takie podejście, a nie na jedną ogromną bazę danych, była sama wielkość potencjalnej bazy danych, która zostałaby utworzona ... każda z 1000 baz danych miała 200 tabel i wiele indywidualnych tabel w każdej z bazy danych zawierały setki milionów wierszy danych!

Pojedyncza konfiguracja bazy danych wymagałaby, aby niektóre tabele (około 8 z nich) miały wielomiliardowe wiersze danych, a całkowity rozmiar bazy danych przekraczałby 10 TB. Byliśmy w stanie mieć wiele serwerów z 5 TB pamięci RAID 10, z wieloma bazami danych na każdym.

Tak bym zrobił! Mam nadzieję, że pomoże to w podejmowaniu decyzji ... :)

Czy aplikacja, którą budujesz, jest aplikacją SaaS? Jeśli tak, proponuję rozważyć trzecie podejście - mieć jedną bazę danych ze wspólną strukturą dla wszystkich instancji aplikacji z jedną różnicą - dodać kolumnę userid / applicationid we wszystkich tabelach. To znacznie obniży koszty opracowania / utrzymania aplikacji. Z mojego doświadczenia wynika, że ​​jest to jedno z najlepszych podejść do przechowywania danych wielu najemców.

Zobacz także ten wspaniały dokument firmy Microsoft na temat architektury danych dla wielu dzierżawców

Podkreśla także zalety / wady wspomnianych podejść.

Konfiguracja B jest znacznie łatwiejsza w zarządzaniu

Każdy tablensiedzi w innym folderze. Może to być bardzo korzystne, jeśli nie chcesz testować limitów systemu operacyjnego .

Na przykład mój pracodawca hostuje MySQL dla systemu CRM dla salonów samochodowych. Klient ma 800 przedstawicielstw. Każda baza dealerska ma 160 tabel. To 128 000 stolików.

• W Instalacji A wszystkie 128 000 tabel mieściłoby się w jednej bazie danych.
• W Instalacji B każdy zestaw 160 tabel znajduje się w podfolderze w katalogu / var / lib / mysql.

Z punktu widzenia systemu operacyjnego i jego zdolności do obsługi i-węzłów (lub tabel FAT dla Windows), co obejmuje posiadanie maksymalnej liczby plików na folder:

• W instalacji A martwisz się o 128 000 plików w jednym folderze. Czy Twój system operacyjny może obsłużyć tyle plików w jednym folderze?
• W konfiguracji B nie martw się.

Gdybyś musiał poprawić struktury tabel za pomocą ALTER TABLElub innego DDL:

• W Instalatorze A trzeba uzyskać skrypt wymaganego DDL przy użyciu PHP (lub specjalnych skryptów MySQL) względem konkretnej nazwy tabeli i odpowiednich zapytań przed uzyskaniem do niej dostępu i wprowadzeniem zmian
• W obszarze Konfiguracja B połącz się z właściwą bazą danych, a następnie za każdym razem uzyskuj dostęp do tej samej nazwanej tabeli. Paradygmat dostępu zawsze byłby czysty:
  • Określona baza danych
  • Określony folder pod /var/lib/mysql
  • Specyficzna nazwa tabeli.

Jeśli chcesz umieścić różne bazy danych na różnych dyskach:

• W Instalacji A dowiązania symboliczne dla każdej tabeli przeniesionej na osobny dysk tylko pogorszą problem „liczby i-węzłów w folderze”. Dyskowe operacje we / wy i ogólny dostęp do tabeli bardziej komplikują i zwiększają ogólne obciążenie serwera, ponieważ .frmpliki są wielokrotnie dostępne.
• W Instalacji B po prostu przenieś cały folder bazy danych do osobnego montowania danych. Dysk I / O może być dystrybuowany na żądanie.
• CAVEAT: Odradzane dla InnoDB

Mówiąc metaforycznie, co wolisz?

• gigantyczny apartament z jedną sypialnią, jedną łazienką i kuchnią (SetupA)
• wiele mieszkań, każdy z własną sypialnią, łazienką i kuchnią (SetupB)

Jeśli chodzi o mocowanie grzejnika w mieszkaniu:

• Dzięki Instalacji A każdy najemca może być niewygodny i musi być zaangażowany, ponieważ musisz rozmawiać z najemcami przed wszystkimi tak, jakby to była sprawa każdego
• Dzięki Instalacji B, oprócz słyszenia uderzeń w ścianę lub rury, najemcy mogą kontynuować swoje prywatne życie
• Ta lista i jej metafory mogą się ciągnąć

IHMO Chociaż budżety mogą być siłą napędową przy podejmowaniu decyzji dotyczących projektowania / infrastruktury, z łatwością opowiedziałbym się za oddzielnymi bazami danych dla każdego klienta.

Mam również produkt SaaS i korzystam z tej samej konfiguracji, o której wspomniał Dave Rix.

Każdy klient ma własną bazę danych

Zrobiłbym jeszcze kilka sugestii:

• Powinieneś mieć „kontroler” bazy danych z równoważeniem obciążenia (master-master), który przechowuje lokalizację bazy danych (ip), nazwę bazy danych i nazwę klienta. W tym kontrolerze aplikacja wie, gdzie znajduje się baza danych każdego klienta.

• Twoja aplikacja może być w dowolnym miejscu - możesz mieć bazy danych dla wielu centrów danych na całym świecie.

• Twoja aplikacja może rosnąć tyle, ile chcesz. Jeśli jest to usługa Web SaaS, możesz utworzyć farmę serwerów serwerów WWW z równoważeniem obciążenia, wskazując każdą bazę danych w czasie logowania klienta.

• Jesteś w stanie stworzyć dostosowany WIDOK / bazę danych dla niektórych klientów - bez wpływu na innych. Jest to ważne, jeśli próbujesz oferować dostosowanie w ramach swojej działalności.

• Możesz skonfigurować dwie farmy internetowe + farmy baz danych: jedną dla wersji „EDGE”, a drugą dla wersji „STABILNYCH”. Następnie musisz mieć niewielką grupę klientów chętnych do testowania rzeczy i potwierdzenia, że ​​wszystko działa zgodnie z oczekiwaniami (innymi słowy zapewnienie jakości [QA]), zanim złożysz wniosek do wszystkich swoich klientów.

• Powinieneś mieć zautomatyzowane zadanie tworzenia kopii zapasowej dla bazy danych przynajmniej raz dziennie.

• Powinieneś mieć inny serwer do replikacji. Ten sam host może replikować wiele baz danych (używać różnych portów dla każdego serwera na tym samym hoście), jeśli nie stać Cię na taką samą liczbę serwerów hosta „master” i „slave”.

  Na przykład 5 serwerów nadrzędnych + 1 serwer podrzędny z 5 bazami danych działającymi na różnych portach - wystarczy pamięć RAM, aby to zrobić.

• Powinieneś zrobić narzędzie „migracji”, aby przenieść jedną bazę danych na inny serwer w dowolnym momencie.

• Powinieneś migrować klientów VIP na bardziej bezpieczny / dostępny serwer bazy danych, aby chronić swoje przychody. Pamiętaj, że wielokrotnie 20% klientów stanowi 80% twoich przychodów. Zadbaj o specjalnych klientów.

• Powinieneś mieć narzędzie do usuwania kopii zapasowych „śmieci”, aby wykonać „ostatnią kopię zapasową” i usunąć bazę danych, gdy klient opuszcza Twoją firmę.

• Musisz mieć obraz bazy danych, w którym eksportujesz i używasz dla nowych kont.

• Musisz mieć narzędzie do łatania bazy danych, aby zastosować nowe łatki do istniejących kont.

• Zachowaj wersje wszystkich łatek SQL, korzystając z narzędzia do kontroli wersji, takiego jak subversion lub git, i stwórz własną numerację. xxx-4.3.0.sql - czasami łatanie się nie udaje i musisz wiedzieć, jak odzyskać / wykonać zadanie łatania.

Cóż, to wszystko, co robię w mojej firmie z produktem, który ma około 5 000 baz danych z około 600 tabelami.