Jag har läst MYCKET om de tillgängliga alternativen. Jag fick också tag på High Performance MySQL 2nd edition, som jag varmt rekommenderar.
Det här är vad jag har lyckats få ihop:
Klustring
Klustring i allmän mening är att fördela belastningen över många servrar som för en extern applikation verkar som en server.
MySQL NDB-kluster
MySQL NDB Cluster är en distribuerad, i minnet, delad-ingenting-lagringsmotor med synkron replikering och automatisk datapartitionering (ursäkta att jag lånar bokstavligen från High Performance-boken, men de uttryckte det väldigt snyggt där). Det kan vara en högpresterande lösning för vissa applikationer, men webbapplikationer fungerar i allmänhet inte bra på den.
Det stora problemet är att utöver mycket enkla frågor (som bara rör en tabell), kommer klustret i allmänhet att behöva söka efter data på flera noder, vilket gör att nätverkslatens kan smyga sig in och avsevärt sakta ner slutförandetiden för frågor. Eftersom applikationen behandlar klustret som en dator kan den inte tala om vilken nod den ska hämta data från.
Dessutom är minneskravet inte användbart för många stora databaser.
Continuent Sequoia
Detta är en annan klustringslösning för MySQL, som fungerar som en middleware ovanpå MySQL-servern. Den erbjuder synkron replikering, lastbalansering och failover. Det säkerställer också att förfrågningar alltid hämtar data från den senaste kopian, och väljer automatiskt en nod som har färska data.
Jag har läst några bra saker på den, och överlag låter det ganska lovande.
Federation
Federation liknar klustring, så jag drog det här också. MySQL erbjuder federation via den federerade lagringsmotorn. I likhet med NDB-klusterlösningen fungerar den bara bra med enkla frågor - men ännu värre än klustret för komplicerade (eftersom nätverkslatensen är mycket högre).
Replikering och lastbalansering
MySQL har den inbyggda kapaciteten att skapa replikeringar av en databas på olika servrar. Detta kan användas till många saker - dela belastningen mellan servrar, heta säkerhetskopieringar, skapa testservrar och failover.
Den grundläggande inställningen av replikering involverar en masterserver som mestadels hanterar skrivningar och en eller flera slavar som endast hanterar läsningar. En mer avancerad variant är den av master-master konfiguration, som gör det möjligt att skala skrivningar också genom att ha flera servrar som skriver samtidigt.
Varje konfiguration har sina för- och nackdelar, men ett problem som de alla delar är replikeringsfördröjning - eftersom MySQL-replikering är asynkron, har inte alla noder den senaste informationen hela tiden. Detta kräver att applikationen är medveten om replikeringen och innehåller replikeringsmedvetna frågor för att fungera som förväntat. För vissa applikationer kanske detta inte är ett problem, men om du alltid behöver den senaste informationen blir det något komplicerat.
Replikering kräver viss lastbalansering för att dela upp lasten mellan noderna. Detta kan vara så enkelt som några ändringar av applikationskoden, eller att använda dedikerade mjukvaru- och hårdvarulösningar.
Skärning och partitionering
Sharding är en vanlig metod för att skala databaslösningar. Du delar upp data i mindre skärvor och sprider dem runt olika servernoder. Detta kräver att applikationen är medveten om modifieringen av datalagringen för att fungera effektivt, eftersom den behöver veta var den ska hitta informationen den behöver.
Det finns abstraktionsramverk tillgängliga för att hantera datadelning, till exempel Hibernate Shards , ett tillägg till Hibernate ORM (som tyvärr finns i Java. Jag använder PHP). HiveDB är en annan sådan lösning som också stöder ombalansering av skärvor.
Andra
Sfinx
Sphinx är en fulltextsökmotor som kan användas för mycket mer än testsökningar. För många frågor är det mycket snabbare än MySQL (särskilt för gruppering och sortering), och kan parallellförfråga fjärrsystem och aggregera resultaten - vilket gör det mycket användbart i användning med sharding.
I allmänhet bör sfinx användas med andra skalningslösningar för att få ut mer av tillgänglig hårdvara och infrastruktur. Nackdelen är att du återigen behöver applikationskoden för att vara medveten om sfinx för att använda den på ett klokt sätt.
Sammanfattning
Skalningslösningar skiljer sig beroende på behoven hos den applikation som behöver det. För oss och för de flesta webbapplikationer tror jag att replikering (förmodligen multi-master) är rätt väg att gå med en lastbalanserare som fördelar belastningen. Uppdelning av specifika problemområden (stora tabeller) är också ett måste för att kunna skala horisontellt.
Jag ska också ge Continuent Sequoia ett försök och se om det verkligen kan göra vad det lovar eftersom det kommer att innebära minsta möjliga mängd ändringar av applikationskoden.