Twitter ruilt MySQL voor Cassandra
Twitter gaat al haar databases migreren naar de open source database Cassandra. In tegenstelling tot MySQL is dat automatisch schaalbaar. En dat is hard nodig bij de snel groeiende microblogdienst.
Twitter gaat al haar databases migreren naar de open source database Cassandra. In tegenstelling tot MySQL is dat automatisch schaalbaar. En dat is hard nodig bij de snel groeiende microblogdienst.
Twitter ruilt MySQL voor Cassandra
Twitter gaat al haar databases migreren naar de open source database Cassandra. In tegenstelling tot MySQL is dat automatisch schaalbaar. En dat is hard nodig bij de snel groeiende microblogdienst.
Twitter draait in de backend nu op MySQL, dat onlangs samen met Sun is overgenomen door Oracle. Maar binnenkort zal de database worden vervangen door Cassandra.
Cassandra is een hybride non-relationele database die is ontwikkeld door Facebook en vervolgens open source is gemaakt. Nu is het een Apache-project. Net als bijvoorbeeld CouchDB, Hadoop, Voldemort en MongoDB is het een ‘NoSQL’ database, die dus geen gebruik maakt van de SQL taal.
Automatisch schaalbaar
In een interview met MyNoSQL legt Ryan King, een software engineer van Twitter, uit dat MySQL in combinatie met memcache steeds duurder wordt om te beheren. Er gaan te veel manuren in zitten om de groeiende hoeveelheid data bij te houden die ze bij Twitter moeten beheren. Daarom waren ze op zoek naar een systeem dat automatisch kan schalen.
Daarvoor hebben ze overwogen om de MySQL setup te veranderen, maar ook hebben ze gekeken naar allerlei andere databases. Uiteindelijk hebben ze gekozen voor Cassandra, dat als enige aan alle voorwaarden voldeed. De voornaamste daarvan waren dat er geen single point of failure is, dat het erg schaalbaar is en dat er een gezonde en productieve open source gemeenschap achter staat, aldus Ryan King.
Op den duur zal Cassandra MySQL helemaal gaan vervangen, maar op dit moment zijn ze bezig met het overzetten van de grootste, en daardoor moeilijkst te beheren database met tweets en retweets.
Bron: Techworld.nl
Wat je er nog aan toe kan voegen is dat als een systeem "goed schaalbaar" is, capaciteitsuitbreiding met minimale operationele impact kunnen worden uitgevoerd.
Databases lopen, als ze groter worden, tegen een fundamenteel dilemma op, namelijk het "Brewer's CAP Theorem".
Het idee achter een database is dat je je gegevens altijd consistent ("waar") wilt hebben. Als de gegevens alleen gelezen hoeven te worden is dat niet moeilijk. Maar als gebruikers ook kunnen schrijven dan zouden twee schrijfbewerkingen van twee gebruikers weleens met elkaar in tegenspraak kunnen zijn. Dat mag niet, dus deze schrijfbewerkingen moeten één punt passeren waar ze tegen elkaar gecheckt worden. Met dat ene punt heb je de bottleneck van je systeem te pakken.
Wat noSQL databases doen is dat ze de absolute garantie op consistentie laten varen. In de praktijk betekent dat met name dat je als gebruiker (licht) verouderde informatie uit de database voorgeschoteld kunt krijgen. Dit effect kennen we uit de DNS database: het duurt een dag of twee voordat een nieuw domein wereldwijd naar het goede IP-nummer verwijst.
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.
"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.
Ter verduidelijking, 'NoSQL' betekent niet 'GeenSQL'. Het staat voor "Not Only SQL". Het sluit dus het gebruik van relationele SQL databases niet uit. Het is echter een beweging die het gebruik van alternatieve databases promoot omdat die soms / vaak een betere oplossing biedt voor het probleem.
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.
En is dat Cassandra ook beschikbaar voor de doe-het-zelfer?
Veel webhost-sites draaien MySQL. Dus daar zit je dan toch aan vast als klant, of niet?
Een zeer interessante vraag...
dat wil ik ook wel eens weten wat er mee bedoelt wordt.
ik heb eigen van Cassandra Dbase systeem ook nooit gehoord.
Kan iemand mij even uitleggen wat er wordt bedoeld met het schalen van de database?
Ben zelf wel af en toe bezig met mySQL, maar hier heb ik nog nooit van gehoord (logisch, want die functie zit dus niet in mySQL).
Reageer
Preview