Dużo czytałem o dostępnych opcjach. Dostałem też w swoje ręce drugą edycję High Performance MySQL, którą gorąco polecam.
Oto, co udało mi się poskładać:
Klastrowanie
Klastrowanie w ogólnym sensie polega na rozłożeniu obciążenia na wiele serwerów, które dla aplikacji zewnętrznej są widoczne jako jeden serwer.
Klaster MySQL NDB
MySQL NDB Cluster to rozproszony, działający w pamięci, współdzielony silnik pamięci masowej z synchroniczną replikacją i automatycznym partycjonowaniem danych (przepraszam, pożyczam dosłownie z książki High Performance, ale bardzo ładnie to tam umieścili). 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 generalnie będzie musiał szukać danych w kilku węzłach, co pozwala na wkradanie się opóźnień w sieci i znaczne spowolnienie czasu realizacji zapytań. Ponieważ aplikacja traktuje klaster jako jeden komputer, nie może powiedzieć, z którego węzła pobrać dane.
Ponadto wymóg dotyczący pamięci nie działa w przypadku wielu dużych baz danych.
Ciągła sekwoja
Jest 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 kilka dobre rzeczy na nim i ogólnie brzmi to całkiem obiecująco.
Federacja
Federacja jest podobna do klastrowania, więc tu też ją wciągnąłem. MySQL oferuje federację za pośrednictwem sfederowanego silnika pamięci masowej. Podobnie jak rozwiązanie klastrowe NDB, działa dobrze tylko z prostymi zapytaniami - ale jeszcze gorzej klaster dla skomplikowanych (ponieważ opóźnienie sieci jest znacznie wyższe).
Replikacja i równoważenie obciążenia
MySQL ma wbudowaną zdolność tworzenia replikacji bazy danych na różnych serwerach. Można to wykorzystać do wielu rzeczy - dzielenia obciążenia między serwerami, tworzenia kopii zapasowych na gorąco, tworzenia serwerów testowych i przełączania awaryjnego.
Podstawowa konfiguracja replikacji obejmuje jeden serwer główny obsługujący głównie zapisy i co najmniej jeden serwer podrzędny obsługujący tylko odczyty. Bardziej zaawansowaną odmianą jest master-master konfiguracja, która pozwala również na skalowanie zapisów poprzez posiadanie kilku serwerów zapisujących w tym samym czasie.
Każda konfiguracja ma swoje wady i zalety, ale jednym wspólnym problemem 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 uwzględniała zapytania uwzględniają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, sprawy się nieco komplikują.
Replikacja wymaga równoważenia obciążenia, aby podzielić obciążenie między węzły. Może to być tak proste, jak niektóre modyfikacje kodu aplikacji lub użycie dedykowanego oprogramowania i rozwiązań sprzętowych.
Sharding i partycjonowanie
Sharding jest powszechnie stosowanym podejściem do skalowania rozwiązań bazodanowych. Dzielisz dane na mniejsze fragmenty i dzielisz je na różne węzły serwerów. Wymaga to, aby aplikacja była świadoma modyfikacji magazynu danych, aby działała wydajnie, ponieważ musi wiedzieć, gdzie znaleźć potrzebne informacje.
Dostępne są frameworki abstrakcji, które pomagają radzić sobie z fragmentacją danych, takie jak Hibernate Shards , rozszerzenie do Hibernate ORM (które niestety jest w Javie. Używam PHP). HiveDB to kolejne takie rozwiązanie, które obsługuje również rebalansowanie odłamków.
Inne
Sfinks
Sfinks to wyszukiwarka pełnotekstowa, która może być używana do znacznie więcej niż wyszukiwania testowego. W przypadku wielu zapytań jest znacznie szybszy niż MySQL (zwłaszcza w przypadku grupowania i sortowania) i może równolegle odpytywać systemy zdalne i agregować wyniki - co czyni go bardzo przydatnym w użyciu z shardingiem.
Ogólnie rzecz biorąc, sfinksa należy używać z innymi rozwiązaniami skalującymi, aby uzyskać więcej dostępnego sprzętu i infrastruktury. Minusem 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. Dla nas i dla większości aplikacji internetowych uważam, że replikacja (prawdopodobnie multi-master) jest sposobem, aby przejść z load balancerem rozprowadzającym obciążenie. Oddzielenie określonych obszarów problemowych (ogromne tabele) jest również niezbędne, aby móc skalować w poziomie.
Zamierzam również spróbować Continuent Sequoia i zobaczę, czy naprawdę może zrobić to, co obiecuje, ponieważ będzie wymagała najmniejszej ilości zmian w kodzie aplikacji.
