NewSQL, een Upgrade voor je oude Database ?

De nieuwe Databases als kruising van NOSQL en SQL...

NewSQL (uitspraak: “new sequel”) is een recente, moderne klasse van DataBase Management Systemen (DBMS), of, kortweg, databases. Deze klasse positioneert zich tegenover de reeds bestaande klasses van Relationele DBMS (RDBMS) en de zogenaamde NOSQL (“no sequel”) databases, waarbij NOSQL staat voor “Not Only SQL”, maar echter nog vaak als “No SQL” wordt begrepen.

Deze laatste categorie maakte een decennium geleden furore als alternatief voor de traditionele RDBMS, en had als doel om zaken als performantie, schaalbaarheid, beschik-baarheid en distribueerbaarheid te verhogen, ten koste van de consistentie. Bij NOSQL databases sprak men vaak van “eventual consistency”, wat betekent dat men niet via transacties werkt, maar er eerder op rekent dat het systeem na verloop van tijd altijd opnieuw in een consistente toestand zal geraken. Dit maakt onderdeel uit van de "BASE principes" (zie kader). NOSQL databases bekeken we bij onderzoek reeds 9 jaar geleden, en recent gingen we dieper in op de subcategorie graph databases.

Voor vele toepassingen gebruikt men echter nog graag de traditionele RDBMS, nu smalend "Old SQL databases" genoemd. De reden is dat deze databases de verantwoordelijkheid om de data consistent te houden voor een groot stuk naar zich toetrekken, door het aanbieden van transactielogica. Deze logica zit vervat in de zogenaamde ACID principes (zie kader), die door deze databases worden ondersteund. Daarnaast kunnen applicatiebouwers ook moeilijk afscheid nemen van het gemak van SQL ondersteuning. Deze taal neemt heel wat werk uit handen van de developers (vaak wordt SQL ook gegenereerd door een library).

Met de NewSQL databases probeert men nu de voordelen van zowel NOSQL als RDBMS te verenigen. Dit type databases wordt beschreven als de oplossing om, zoals bij NOSQL mogelijk is, een horizontaal schaalbare en gedistribueerde database op te zetten. Men streeft er dus naar om de performantie van NOSQL databases, die typisch hoger is dan die van RDBMS, te evenaren. Tegelijk probeert men dit te doen zonder aan de traditionele ACID principes te raken, die door RDBMS naar voren worden geschoven.

Hoe de NewSQL databases erin slagen deze eigenschappen te combineren, verschilt van geval tot geval. Een paar zaken hebben ze echter gemeen: ze ondersteunen, in tegenstelling tot de meeste NOSQL databases, het relationele model en ze gebruiken de taal SQL als de belangrijkste manier om met de database te interageren. Dit zijn typisch ook de belangrijkste kenmerken voor een RDBMS.

De vraag kan dus gesteld worden hoe gemakkelijk het is om een RDBMS te vervangen door een NewSQL database, gezien de manier om ermee om te gaan zo gelijkaardig is. Het is dus mogelijk dat NewSQL databases de resiliëntie van applicaties kunnen verhogen, doordat de resiliëntie van de onderliggende database verhoogt, en dit mogelijks met een beperkte migratie-effort, vanwege de compatibiliteit met de huidige gebruikte RDBMS. Verschillende NewSQL databases claimen compatibiliteit met een bestaande RDBMS (b.v. PostgreSQL) en slagen hier dus redelijk in. Er zijn echter soms toch enige beperkingen op hoeveel men precies ondersteunt van SQL in vergelijking met de RDBMS. Dit komt doordat men niet ontsnapt aan het fundamentele CAP theorema.

Het CAP theorema voor gedistribueerde systemen kwam reeds lang geleden aan bod op deze blog. Kort uitgelegd komt het erop neer dat je hoogstens twee van de volgende 3 zaken tegelijk kan hebben: Availability (je krijgt altijd een antwoord van het systeem), Consistency (je ziet ten allen tijde de meest recent geschreven data), Partition tolerance (het systeem blijft werken, ook al functioneert het netwerk tussen de nodes van het systeem niet meer). Ook het CAP theorema werd bij onderzoek reeds uitvoerig belicht.

Fig. 1: Het CAP theorema zegt dat de doorsnede van Availability, Consistency en Partition Tolerance leeg blijft. Enkel in de doorsnede van telkens slechts 2 van de 3 zaken kan men oplossingen hebben. De verschillende types databases kan men hier goed in plaatsen.

Sowieso zal je in een gedistribueerd systeem altijd te maken krijgen met netwerk falen, dus je moet "iets" doen daarmee en dus de "P" ondersteunen. Dan rest dus nog de keuze of je voor "A" of "C" gaat. NOSQL databases kiezen voor "A": alle nodes blijven werken, ook al zijn ze niet meer verbonden. Bijgevolg verliezen ze "C": de data in de losgekoppelde nodes kan verschillen. Dit noemt men een "AP" systeem. NewSQL databases kiezen voor de andere aanpak: een aantal van de nodes die niet meer bereikbaar zijn, zullen een foutmelding geven en dus niet beschikbaar zijn. Zolang er een bepaalde meerderheid van nodes met elkaar kan communiceren, zullen deze beschikbaar blijven, maar het systeem is dus niet "100% beschikbaar", enkel de nodes die de meerderheid vormen zijn dat. Dit wordt dan een "CP" systeem genoemd, want de nodes die nog werken zijn wel consistent. In Fig. 1 zie je het CAP theorema grafisch uitgebeeld; wanneer er geen rekening wordt gehouden met Partition Tolerance (de bovenste van de drie doorsnedes), zit je met het type database "SQL", t.t.z. de traditionele RDBMS die niet gedistribueerd werken.

Wordt Vervolgd...

NewSQL databases lijken erg veelbelovend. Ze bieden een consistente gegevensopslag aan, bovenop een performant en resiliënt gedistribueerd systeem. Ondanks het feit dat ze de Availability uit het CAP theorema laten vallen, bieden ze een hogere SLA aan dan niet-gedistribueerde databases. Daarnaast vertonen ze een vrij grote compatibiliteit met de traditionele RDBMS databases.

Momenteel loopt er bij Smals Onderzoek een studie naar deze soort databases, waarbij we deze claims verder zullen toetsen aan de hand van een paar testen, en waarin we ook enkele concrete producten zullen uitproberen. Meer hierover in een latere blog.

_________________________

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.