Hoe verhoudt NewSQL zich tot bestaande databases zoals OldSQL en NoSQL? En vooral: wat gebeurt er wanneer er een node wegvalt in een redundante setup? We onderwerpen drie voorname NewSQL-producten aan een praktijktest.
Wat het database-gebruik in de IT sector betreft, zien we nog steeds een ruime meerderheid voor traditionele databases. Leidende spelers zijn daarbij MySQL en PostgreSQL. Daarnaast weet ook de NoSQL database MongoDB aardig wat marktaandeel te veroveren. Van een revolutionaire opmars van NewSQL databases kan dus nog geen sprake zijn.
Verschillende smaakjes SQL
De reeds bestaande databases, zowel OldSQL als NoSQL, staan dan ook niet stil in hun evolutie, en groeien op verschillende vlakken naar elkaar toe. Enkele NoSQL producten bieden bijvoorbeeld een beperkte ondersteuning voor SQL of SQL-achtige talen aan, en soms ook transacties. De traditionele relationele databases bieden op hun beurt allerlei manieren aan om horizontaal te schalen en dus een gedistribueerd systeem op te zetten met een verhoogde beschikbaarheid. De verschillende categorieën van databases groeien dus dichter naar elkaar toe.
Ook NewSQL kan je eigenlijk beschouwen als een soort naar elkaar toegroeien van beide andere categorieën. Zit er dan nog een effectieve vernieuwing in?
Het antwoord op die vraag situeert zich in een aantal producten die van de grond af zijn opgebouwd met de problematiek van dit spanningsveld tussen consistentie en beschikbaarheid in gedachten. Ze zijn met een cloud native aanpak ontworpen. Dat wil onder andere zeggen dat de toepassingen vanaf het begin een gedistribueerd ontwerp hebben. De basis architectuur en de opzet verschillen dus voldoende van de andere producten om er effectief het label ‘NewSQL’ aan te hangen. Het resultaat zijn systemen die de gewenste eigenschappen combineren, zonder dat de installatie en het onderhoud nodeloos complex worden.
NewSQL kan je eigenlijk beschouwen als een soort naar elkaar toegroeien van OldSQL en noSQL.
Om te zien hoe dit spanningsveld precies wordt aangepakt bij NewSQL, moeten we nog eens terugkomen op het befaamde CAP-theorema…
Van CAP naar…
Het CAP-theorema stelt dat we in een gedistribueerd systeem steeds keuzes zullen moeten maken. We willen namelijk drie dingen: de verschillende componenten van het systeem moeten zo goed mogelijk hun data consistent houden. De gegevens moeten dus hetzelfde zijn op elke plek (dat is de C). Ten tweede moet het systeem zo goed mogelijk beschikbaar blijven, zelfs bij deels falen (dit is availability, de A). Ten slotte moet het systeem er tegen kunnen dat het netwerk uitvalt, of dat verschillende delen van het systeem elkaar op een andere manier niet meer kunnen terugvinden. Dat heet “Partition Tolerance” (P). Het theorema zegt ons: je kan ze nooit alle drie tegelijk perfect krijgen.
Omdat het om een gedistribueerd systeem gaat, moeten we er steeds voor zorgen dat we P hebben, dus in de praktijk zal er steeds een keuze moeten worden gemaakt tussen beschikbaarheid en consistentie.
Het CAP theorema gaat vooral in op wat theoretisch niét kan (C, A én P tegelijk hebben). Het vertelt ons echter iets te weinig over wat men dan wel kan doen binnen de grenzen van wat theoretisch mogelijk is.
Wanneer alles redelijk normaal verloopt voor een gedistribueerd systeem, treden er geen netwerkpartities op. Op dat ogenblik kan je volgens het theorema zorgen voor beschikbaarheid en consistentie tegelijkertijd. In de praktijk zal dat ook zo zijn, indien alles naar wens verloopt en er geen al te zware belasting op het platform inwerkt. Zelfs de eventual consistency (geen harde consistentie garantie, maar het systeem doet zijn best om de data uiteindelijk overal gesynchroniseerd te krijgen) van NoSQL systemen zal dan slechts seconden duren in de plaats van de langere tijd die men van eventual zou verwachten.
…naar PACELC
Nochtans moet je in dit geval ook keuzes maken. Het PACELC-theorema is een uitbreiding op het CAP theorema. Het stelt dat men in afwezigheid van netwerkpartities moet kiezen tussen latency en consistentie. NoSQL trekt hier duidelijk de kaart van latency: het systeem aanvaardt onmiddellijk een request van een client en rekent op de eventual consistency om alle nodes van het systeem op een redelijke tijd in orde te krijgen.
NewSQL systemen kiezen consistentie.
NewSQL systemen kiezen daarentegen consistentie: vooraleer de request wordt aanvaard, wordt ervoor gezorgd dat voldoende nodes akkoord zijn. Wanneer de request aanvaard is, zal dat ook zo zijn op de meeste nodes, zodat de consistentie gegarandeerd is over het gehele systeem. Deze fase van ‘akkoord bereiken’ tussen de nodes zal de werking enigszins vertragen.
De afkorting PACELC kan je dan via het volgende zinnetje opbouwen: Bij netwerkpartitie (P), moet je kiezen tussen beschikbaarheid (Availability) en consistentie (C), en anders (Else), tussen latency (L) en consistentie (C).
Kiezen en verliezen
Wanneer het systeem over voldoende performantie beschikt, het niet overbelast is en er geen fouten optreden, zal je in de praktijk weinig merken van dit verschil tussen latency en consistentie. De specifieke garanties die worden geboden door de systemen en hun makers zijn wel heel belangrijk om weten wanneer je deze databases gaat gebruiken. Er zal immers altijd wel iets misgaan en er kan altijd wel een situatie optreden die het systeem te zwaar belast.
Wil je te allen tijde kunnen rekenen op consistentie, of eerder op een zo hoog mogelijke beschikbaarheid en het zo weinig mogelijk missen en zo snel mogelijk afhandelen van requests? Een banktoepassing zal typisch het eerste willen, een webshop misschien eerder het tweede (en als er iets misgaat door inconsistentie in de data, maakt men dit achteraf wel goed met de klant).
In de praktijk is PACELC eigenlijk nuttiger dan CAP: indien men een systeem met hoge beschikbaarheid wil voorzien, moet men de facto aan duplicatie gaan doen, ook van data. Vanaf het moment dat data gedupliceerd wordt en verspreid over meerdere plaatsen, zal men een afweging moeten maken tussen hoe consistent men deze wil houden, en hoe snel men er mee wil kunnen werken.
NewSQL in de praktijk
We testten drie verschillende NewSQL producten voor dit onderzoek: CockroachDB, TiDB en NuoDB. Het voornaamste doel was om het gedrag bij het uitvallen van nodes te testen. De theorie stelt dat deze databases netjes blijven werken zolang een meerderheid van de nodes draait en deze elkaar kunnen zien. Op die manier kan er altijd een consensus worden bereikt betreffende transacties.
De test ging als volgt: eerst bouwen we een cluster van drie nodes voor elk van deze producten. Daar wordt eventueel nog een load balancer aan toegevoegd. We voorzien tot slot een machine die als client zal optreden.
Daarna volgen er twee testen waarbij we de cluster vanaf de clientmachine bestoken met requests volgens een standaard die TPCC heet.
De twee testen verschillen als volgt. De eerste keer gaat er niets mis: alle drie de nodes blijven netjes werken. Bij de tweede test zullen we na een tijdje één van de nodes geforceerd uitschakelen, alsof deze een stroompanne ondervindt. Deze node zal dan de helft van de testperiode uitgeschakeld blijven, om dan nog tijdens de test terug op te worden gestart.
Wat is het resultaat?
De TPCC is in principe ook een performantietest, dus we kunnen meteen zien hoeveel verkeer deze databases aankunnen. Dat was echter niet het hoofdopzet van de test en de resultaten kunnen daardoor wat meer uit elkaar liggen.
Ook spelen er bepaalde aspecten aan sommige NewSQL-databases niet mee in onze test. Die kunnen een impact hebben op de performantie vanwege de setup met verschillende nodes op virtuele machines, echter allen op dezelfde fysieke machine. Zo is de fysieke afstand tussen nodes belangrijk mogen de systeemklokken op de verschillende nodes doorgaans niet teveel van elkaar afwijken. Voor Google Spanner rolt men hiertoe atoomklokken uit in de verschillende datacenters maar er bestaan echter ook aanvaardbare goedkopere oplossingen.
Voor de drie geteste databases bekwamen we gelijkaardige resultaten. Alle drie bleven ze functioneel bij het falen van één van de drie nodes. Bij de laatste, NuoDB, vroeg dat echter extra configuratiewerk. Voor CockroachDB en TiDB was dat wel out-of-the-box ondersteund.
Daarnaast werd de performantie weinig beïnvloed door het node-falen. Er waren nauwelijks minder transacties in de testperiode. Enkel voor NuoDB was het verschil iets groter. Wat wel opviel, was dat enkele transacties een stuk langer duurden. We vermoeden dat deze transacties werden gedaan op het moment van het node-falen, waardoor ze werden benadeeld. Al bij al voldeden de drie geteste producten echter wel goed aan onze verwachtingen van beschikbaarheid. Hieronder een voorbeeld van de cijfers van de test van CockroachDB.
Volwassen optie
NewSQL-databases beginnen vrij matuur te zijn. Ze zijn een prima keuze wanneer we voor een toepassing de voorkeur geven aan het gemak van data die consistent blijft en ondersteuning voor SQL, maar tegelijk toch een zeer goede beschikbaarheid willen. Het gedistribueerd karakter is ingebouwd in de technologie . Ze zijn dus cloud native. Daardoor laten ze zich veel gemakkelijker dan de traditionele relationele databases uitrollen in clusters van meerdere evenwaardige nodes, waarvan slechts een meerderheid operationeel moet blijven om het systeem beschikbaar te houden.
We duiden toch ook enkele aandachtspunten aan. Om een effectief systeem met hoge beschikbaarheid te hebben, moet je deze databases in principe uitrollen op verschillende locaties en eventueel zelfs in verschillende datacenters. Dat zorgt ervoor dat de kans zo klein mogelijk is dat verschillende nodes tegelijk falen. Tegelijk is het van belang dat de nodes vlot met elkaar kunnen communiceren, dat dit verkeer niet wordt onderschept, en dat ze voor sommige architecturen op systemen draaien met een zo gelijk mogelijke systeemklok. Anders wordt de performantie aangetast.
Ook met deze aandachtspunten in het achterhoofd besluiten we dat NewSQL-databases een goede keuze vormen wanneer je een cluster van redundante databases wil uitrollen voor verhoogde beschikbaarheid.
Dit is een ingezonden bijdrage van Koen Vanderkimpen, IT consultant bij Smals Research. Dit artikel werd geschreven in eigen naam en neemt geen standpunt in namens Smals.