Dużo czytałem na temat dostępnych opcji. Dostałem też w swoje ręce 2. wydanie High Performance MySQL, które bardzo polecam.
Oto, co udało mi się złożyć razem:
Grupowanie
Klastrowanie w sensie ogólnym polega na rozkładaniu obciążenia na wiele serwerów, które dla zewnętrznej aplikacji wyglądają jak jeden serwer.
Klaster MySQL NDB
MySQL NDB Cluster jest rozproszonym, działającym w pamięci, silnikiem pamięci masowej bez współdzielenia z synchroniczną replikacją i automatycznym partycjonowaniem danych (przepraszam, zapożyczam dosłownie z książki High Performance, ale bardzo ładnie to ujęli). Może to być rozwiązanie o wysokiej wydajności dla niektórych aplikacji, ale aplikacje internetowe generalnie nie działają na nim dobrze.
Główny problem polega na tym, że poza bardzo prostymi zapytaniami (które dotykają tylko jednej tabeli), klaster będzie zazwyczaj musiał wyszukiwać dane w kilku węzłach, umożliwiając wkradanie się opóźnień w sieci i znaczne spowolnienie czasu wypełniania zapytań. Ponieważ aplikacja traktuje klaster jak jeden komputer, nie może jej powiedzieć, z którego węzła ma pobierać dane.
Ponadto wymaganie dotyczące pamięci nie działa w przypadku wielu dużych baz danych.
Ciągła sekwoja
To kolejne rozwiązanie klastrowe dla MySQL, które działa jako oprogramowanie pośredniczące na serwerze MySQL. Oferuje replikację synchroniczną, równoważenie obciążenia i przełączanie awaryjne. Zapewnia również, że żądania zawsze otrzymują dane z najnowszej kopii, automatycznie wybierając węzeł, który ma świeże dane.
Przeczytałem o nim kilka dobrych rzeczy i ogólnie brzmi to całkiem obiecująco.
Federacja
Federacja jest podobna do klastrowania, więc tutaj też ją ściągnąłem. MySQL oferuje federację za pośrednictwem federacyjnego mechanizmu magazynowania. Podobnie jak rozwiązanie klastrowe NDB, działa dobrze tylko z prostymi zapytaniami - ale jeszcze gorzej z klastrem dla skomplikowanych (ponieważ opóźnienie sieci jest znacznie wyższe).
Replikacja i równoważenie obciążenia
MySQL ma wbudowaną możliwość tworzenia replikacji bazy danych na różnych serwerach. Można to wykorzystać do wielu celów - dzielenia obciążenia między serwerami, tworzenia kopii zapasowych na gorąco, tworzenia serwerów testowych i przełączania awaryjnego.
Podstawowa konfiguracja replikacji polega na tym, że jeden serwer główny obsługuje głównie zapisy, a co najmniej jeden serwer podrzędny obsługuje tylko odczyty. Bardziej zaawansowaną odmianą jest konfiguracja master-master , która umożliwia skalowanie zapisów poprzez jednoczesne zapisywanie przez kilka serwerów.
Każda konfiguracja ma swoje wady i zalety, ale jednym z problemów, które wszyscy dzielą, jest opóźnienie replikacji - ponieważ replikacja MySQL jest asynchroniczna, nie wszystkie węzły mają zawsze najświeższe dane. Wymaga to, aby aplikacja była świadoma replikacji i zawierała zapytania obsługujące replikację, aby działały zgodnie z oczekiwaniami. W przypadku niektórych aplikacji może to nie stanowić problemu, ale jeśli zawsze potrzebujesz najświeższych danych, sytuacja nieco się komplikuje.
Replikacja wymaga równoważenia obciążenia, aby rozdzielić obciążenie między węzłami. Może to być tak proste, jak modyfikacje kodu aplikacji lub użycie dedykowanych rozwiązań programowych i sprzętowych.
Sharding i partioning
Sharding to powszechnie stosowane podejście do skalowania rozwiązań bazodanowych. Dzielisz dane na mniejsze fragmenty i rozprowadzasz je po różnych węzłach serwera. Wymaga to od aplikacji świadomości modyfikacji sposobu przechowywania danych, aby działała wydajnie, ponieważ musi wiedzieć, gdzie znaleźć potrzebne informacje.
Istnieją ramy abstrakcji, które pomagają radzić sobie z fragmentowaniem danych, takie jak Hibernate Shards , rozszerzenie Hibernate ORM (który niestety jest w Javie. Używam PHP). HiveDB to kolejne takie rozwiązanie, które obsługuje również równoważenie fragmentów.
Inni
Sfinks
Sphinx to pełnotekstowa wyszukiwarka, której można używać nie tylko do wyszukiwania testowego. W przypadku wielu zapytań jest znacznie szybszy niż MySQL (zwłaszcza w przypadku grupowania i sortowania) i może równolegle odpytywać zdalne systemy i agregować wyniki - co czyni go bardzo użytecznym w użyciu z fragmentowaniem.
Ogólnie rzecz biorąc, sphinx powinien być używany z innymi rozwiązaniami skalującymi, aby uzyskać więcej dostępnego sprzętu i infrastruktury. Wadą jest to, że ponownie potrzebujesz kodu aplikacji, aby być świadomym sfinksa, aby mądrze go używać.
Podsumowanie
Rozwiązania skalujące różnią się w zależności od potrzeb aplikacji, która tego potrzebuje. Uważam, że zarówno dla nas, jak i dla większości aplikacji internetowych, replikacja (prawdopodobnie multi-master) jest drogą do rozwiązania z systemem równoważenia obciążenia rozprowadzającym obciążenie. Dzielenie określonych obszarów problemowych (ogromne tabele) jest również konieczne, aby móc skalować w poziomie.
Zamierzam też dać szansę Continuent Sequoia i sprawdzić, czy naprawdę może zrobić to, co obiecuje, ponieważ będzie wymagał najmniejszej ilości zmian w kodzie aplikacji.