Twitter ruilt MySQL voor Cassandra

Het schalen van je database is nodig omdat je steeds meer data en steeds meer bezoekers op je website krijgt (in dit geval). Een server kan maar een bepaalde hoeveelheid data opslaan (diskcapaciteit) en kan ook maar een X aantal queries per seconde uitvoeren (processor / geheugen).

De eerste stap is dan om verticaal te schalen. Dit betekent simpelweg gewoon een grote server kopen. Meerdere processoren, meerdere cores per processor, meer geheugen, grotere harddisks (RAID arrays). Maar dat kun je niet oneindig lang blijven doen omdat de kosten exponentieel gaan toenemen. Bovendien creëer je dan ook een groot single-point-of-failure. Als die ene server kapot gaat dan ligt alles plat.

De tweede stap is dan horizontaal schalen. Je zet dus meerdere database servers naast elkaar. Dit kan je doen door ze te clusteren en zo de belasting te verdelen. Clusters schalen behoorlijk goed maar ook daar zitten uiteindelijk beperkingen aan. Eén van de servers in de cluster moet namelijk de master zijn, alle andere slaves. Een master kan maar een beperkt aantal slaves tegelijk bedienen. Dit is afhankelijk van de hoeveelheid queries en data die wordt uitgevoerd. Daarnaast is die master dan nog steeds een single-point-of-failure. In clusters kun je echter vaak wel (semi-)automatisch een slave promoten naar master maar dit heeft toch vaak wel een korte downtijd tot gevolg.

Als je tegen de beperkingen van een cluster aanloopt dan is een derde stap vaak om de data te gaan verdelen over meerdere clusters. Dit noemt met sharding. Dit kan op verschillende manieren. Je kan bijvoorbeeld in het geval van een webshop alle klantgegevens op cluster A opslaan en alle bestellingen op cluster B. Je kan er echter ook voor kiezen om alle klanten met een oneven klantnummer op cluster A op te slaan en alle klanten met een even klantnummer op cluster B. Er zijn verschillende methodes en de juiste keuze hangt meestal af van de applicatie.

Groot probleem (nadeel) van sharding is dat je geen transacties of joins kan uitvoeren over data die over verschillende shards is verdeeld. Je kan dus niet in één query de bestellingen ophalen van alle klanten in plaats XYZ. Je zult dan eerst alle klanten in plaats XYZ moeten ophalen op cluster A en met die lijst de bijbehorende bestellingen op cluster B.

Join operaties zijn over het algemeen de bottleneck bij het schalen van relationele databases. Je ziet dan ook vaak dat data wordt gedenormaliseerd om join operaties uit te sparen. Daarmee vervalt een deel van het voordeel van relationele databases en daarom zie je nu ook een opkomst van niet-relationele database. Voor sommige toepassingen is het gewoon handiger.

"Schalen" is niet een functie van MySQL. Schalen is eigenlijk een slechte vertaling van "to scale", wat in het Engels ook al een erg vaag begrip is in de IT. Een beter Nederlands woord is denk ik "opschalen". Er wordt mee bedoeld dat je de servercapaciteit of netwerkcapaciteit of verwerkingscapaciteit gaat uitbreiden als het gebruik van de applicatie (in dit geval dus Twitter of Facebook) groeit.

Zolang je nog toe kunt met een standaard hostingpakketje bij een webhoster, is dit helemaal niet aan de orde voor je. Pas wanneer je MySQL-database zo groot wordt, of zoveel traffic krijgt, dat een enkele dedicated server het niet meer aankan.. dan wordt dit soort oplossingen interessant. Maar dan nog zou ik eerst eens kijken naar een clustering-oplossing voor MySQL zelf, want de DB-interface van je applicatie helemaal verbouwen is meestal ook geen pretje.