Hodně jsem četl o dostupných možnostech. Do rukou se mi také dostala High Performance MySQL 2nd edition, kterou vřele doporučuji.
Tohle se mi podařilo dát dohromady:
Shlukování
Klastrování v obecném smyslu znamená rozložení zátěže na mnoho serverů, které se vnější aplikaci jeví jako jeden server.
MySQL NDB Cluster
MySQL NDB Cluster je distribuovaný, in-memory, sdílený-nothing storage engine se synchronní replikací a automatickým rozdělováním dat (promiňte, půjčuji si doslova z knihy High Performance, ale dali to tam moc pěkně). Pro některé aplikace to může být vysoce výkonné řešení, ale webové aplikace na něm obecně nefungují dobře.
Hlavním problémem je, že kromě velmi jednoduchých dotazů (které se dotýkají pouze jedné tabulky) bude cluster obecně muset hledat data na několika uzlech, což umožní vplížení se latence sítě a výrazně zpomalí čas dokončení dotazů. Protože aplikace zachází s clusterem jako s jedním počítačem, nemůže jí říct, ze kterého uzlu má data načíst.
Požadavek in-memory navíc není funkční pro mnoho velkých databází.
Pokračující Sequoia
Toto je další klastrovací řešení pro MySQL, které funguje jako middleware nad serverem MySQL. Nabízí synchronní replikaci, vyvažování zátěže a převzetí služeb při selhání. Zajišťuje také, že žádosti vždy získají data z nejnovější kopie, přičemž automaticky vybere uzel, který má čerstvá data.
Přečetl jsem několik dobré věci a celkově to zní docela slibně.
Federace
Federace je podobná shlukování, tak jsem to zatáhl i sem. MySQL nabízí federaci prostřednictvím federovaného úložiště. Podobně jako clusterové řešení NDB funguje dobře pouze s jednoduchými dotazy - ale ještě horší je cluster pro ty složité (protože latence sítě je mnohem vyšší).
Replikace a vyvažování zátěže
MySQL má vestavěnou kapacitu pro vytváření replikací databáze na různých serverech. Toho lze využít k mnoha věcem – rozdělení zátěže mezi servery, zálohování za chodu, vytváření testovacích serverů a převzetí služeb při selhání.
Základní nastavení replikace spočívá v tom, že jeden hlavní server zpracovává většinou zápisy a jeden nebo více podřízených serverů pouze čtení. Pokročilejší variantou je varianta master-master konfigurace, která umožňuje škálovat také zápisy tím, že několik serverů píše současně.
Každá konfigurace má své pro a proti, ale jeden problém, který všechny sdílejí, je zpoždění replikace – protože replikace MySQL je asynchronní, ne všechny uzly mají vždy ta nejčerstvější data. To vyžaduje, aby si aplikace byla vědoma replikace a začlenila dotazy s podporou replikace, aby fungovala podle očekávání. U některých aplikací to nemusí být problém, ale pokud potřebujete vždy ta nejčerstvější data, věci se poněkud zkomplikují.
Replikace vyžaduje určité vyvažování zátěže, aby bylo možné zátěž rozdělit mezi uzly. To může být tak jednoduché jako některé úpravy kódu aplikace nebo použití specializovaných softwarových a hardwarových řešení.
Sharding a partitioning
Sdílení je běžně používaný přístup k škálování databázových řešení. Data rozdělíte na menší úlomky a rozložíte je kolem různých serverových uzlů. To vyžaduje, aby si aplikace byla vědoma změn v datovém úložišti, aby fungovala efektivně, protože potřebuje vědět, kde najde potřebné informace.
K dispozici jsou abstraktní rámce, které vám pomohou vypořádat se se sdílením dat, jako je Hibernate Shards , rozšíření Hibernate ORM (které je bohužel v Javě. Používám PHP). HiveDB je dalším takovým řešením, které také podporuje rebalancování střepů.
Ostatní
Sfinga
Sfinga je fulltextový vyhledávač, který lze použít pro mnohem více než jen testovací vyhledávání. Pro mnoho dotazů je mnohem rychlejší než MySQL (zejména pro seskupování a třídění) a dokáže dotazovat vzdálené systémy paralelně a agregovat výsledky – díky čemuž je velmi užitečný při použití se shardováním.
Obecně by se sphinx měl používat s jinými škálovacími řešeními, abyste získali více dostupného hardwaru a infrastruktury. Nevýhodou je, že opět potřebujete kód aplikace, abyste věděli o sfingě, abyste ji mohli rozumně používat.
Shrnutí
Řešení škálování se liší v závislosti na potřebách aplikace, která to potřebuje. Pro nás a pro většinu webových aplikací věřím, že replikace (pravděpodobně multi-master) je způsob, jak jít s nástrojem pro vyrovnávání zatížení, který rozděluje zátěž. Sdílení specifických problémových oblastí (obrovských tabulek) je také nutností pro horizontální škálování.
Vyzkouším také společnost Continuent Sequoia a uvidím, zda skutečně dokáže to, co slibuje, protože to bude vyžadovat nejmenší množství změn v kódu aplikace.