Twitter ruilt MySQL voor Cassandra

twitter.Foto:Twitter

Gepubliceerd: Woensdag 3 maart 2010

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.

Toon volledig artikel

Stefan op Woensdag 3 Maart 2010 13:47

image

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).

eMilt ! op Woensdag 3 Maart 2010 14:24

image

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.

Erik Geurts op Woensdag 3 Maart 2010 14:34

image

"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.

GJvdZ op Woensdag 3 Maart 2010 17:49

image

Wat je er nog aan toe kan voegen is dat als een systeem "goed schaalbaar" is, capaciteitsuitbreiding met minimale operationele impact kunnen worden uitgevoerd.

spatieman op Woensdag 3 Maart 2010 13:55

image

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.

fritsbolkys op Woensdag 3 Maart 2010 14:24

image

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?

Anonymous Coward op Woensdag 3 Maart 2010 14:49

image

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.

eMilt ! op Woensdag 3 Maart 2010 14:26

image

Net als bijvoorbeeld CouchDB, Hadoop, Voldemort en MongoDB is het een ‘NoSQL’ database, die dus geen gebruik maakt van de SQL taal.
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.

b3r3nd op Woensdag 3 Maart 2010 17:07

image

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.

Om te kunnen reageren, dient u ingelogd te zijn.

Nieuwsbrief

Ontvang dagelijks een overzicht van het laatste ICT-Nieuws in uw mailbox

Peiling

Loading Poll

Video: World Tech Update: Darpa's robot oorl...

World Tech Update: Darpa's robot oorlogspaard (video)

Verleden nieuws