Notre site utilise des cookies pour rendre votre navigation plus agréable sur le site.

NewSQL, een Upgrade voor je oude Database ?

Posted on 10/10/2019 by Koen Vanderkimpen

logo-newsql

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.

Definitie: BASE

BASE staat voor Basically Available, Soft state, Eventual consistency. Het principe betekent dat men de voorkeur geeft aan het beschikbaar houden van de dienst (Basically Available), zelfs als verschillende nodes van de dienst elkaar niet meer kunnen bereiken (typisch door netwerk falen). De nodes zullen hierdoor ongesynchroniseerd worden met elkaar (vermits ze onafhankelijk blijven werken), maar wanneer ze terug verbonden geraken, zullen ze de consistentie herstellen (Eventual Consistency). Magie bestaat echter niet en het kan zijn dat dit een onvoldoende goed resultaat geeft. Daarom moeten applicatiebouwers extra aandacht schenken aan het omgaan met de consistentie wanneer ze van een dergelijke database gebruik maken (Soft state). Meer uitleg vind je hier

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.

Definitie: ACID

De ACID principes zijn Atomicity, Consistency, Isolation, Durability.

Deze set van eigenschappen werd in het leven geroepen om de validiteit van transacties te kunnen garanderen, zelfs wanneer er fouten zouden optreden in het systeem. Typisch aan ACID is het gebruik van transacties: een sequentie van database operaties die aan de ACID principes voldoet en nooit onvolledig kan worden uitgevoerd, waardoor het systeem in een inconsistente toestand zou achterblijven. Zulk een transactie wordt dus altijd ofwel niet uitgevoerd, ofwel in haar geheel uitgevoerd (ze is atomair), laat het systeem in een consistente toestand achter, is geïsoleerd van andere transacties, en het resultaat ervan heeft een blijvend effect op het database systeem, zelfs indien het ná het uitvoeren van de transactie snel zou falen (durabiliteit). Meer uitleg vind je hier

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.

Cap Theorema

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.

Over Availability en de SLA

Bij het bespreken van het CAP theorema wordt gesproken over volledige Availability. Wil dit dan zeggen dat "A" systemen, zoals de "AP" NOSQL databases, een up-time hebben van 100% ? Spijtig genoeg niet. Het gaat hier nog steeds over een theoretische bovengrens. De availability waarvan sprake in het CAP theorema is een beetje kunstmatig: ze gaat ervan uit dat een enkele node niet zal falen (men beschouwt enkel netwerkfalen). In de praktijk is dat natuurlijk niet het geval, vandaar dat de SLA van een "A" systeem ook geen 100% zal zijn. Traditionele single-node databases, die geen rekening moeten houden met netwerk partities, zijn dus uiteraard ook niet 100% beschikbaar.
Bij gedistribueerde systemen tracht men dit echter wel te benaderen, doordat de kans dat verschillende nodes tegelijk falen, veel lager ligt dan de kans dat één node faalt, waardoor men dus voor een stuk beschikbaarheid behoudt, zelfs bij falen. Het feit dat één node op zich makkelijker kan falen, is dan ook net één van de redenen om over te stappen op een gedistribueerd systeem (naast verhoogde schaal en performantie). Bij NewSQL databases bekomt men dan uiteindelijk op die manier óók een verhoogde beschikbaarheid, ook al zijn het systemen die de "A" uit het CAP theorema niet mee opnemen: zolang een meerderheid van de nodes actief blijft (en kan communiceren), blijft dit deel van het totale systeem beschikbaar, en aldus bekomt men ook voor NewSQL systemen een hogere SLA.

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.

Source: Smals Research