Bij het software bouwen, maken we meestal geen op zichzelf staande programma’s meer. We bouwen vandaag eerder Applicatie Ecosystemen. Wanneer we dus een stuk software schrijven, mogen we niet zomaar de ontwikkeling lokaal optimaliseren, maar moeten we ook continu rekening houden met het grotere geheel. In deze blog maken we een verkenning van een aantal zaken waar we rekening mee moeten houden bij het bouwen van een ecosysteem, en van concrete principes die we kunnen toepassen bij het uitbouwen van een erbij passende modulaire architectuur.

De Paradox van de Afhankelijkheid

Er heerst grote waarde in zaken met elkaar verbinden, en in reeds bestaande zaken te hergebruiken bij het bouwen van nieuwe dingen. Gegevens, en ook de manier waarop ze worden verwerkt, ja, soms zelfs hele stukken van een applicatie, van één instelling, kunnen ook van pas komen bij een andere. En uiteraard geldt hetzelfde ook al binnen één en dezelfde instelling. Er is dus een meerwaarde te vinden door zaken met elkaar te verbinden en door zaken van elkaar te gaan hergebruiken. Dit is ook het hele opzet achter het ReUse verhaal binnen onze sector. Connecties en communicaties tussen systemen creëren hergebruik, efficiëntie en business waarde.

Maar wanneer we zaken verbinden, maken we ze van elkaar afhankelijk. Die afhankelijkheid heeft op technisch vlak vooral nadelen. Denk maar aan het onbeschikbaar zijn van een dienst waarvan andere diensten rechtstreeks afhangen; vaak worden deze laatste dan eveneens onbeschikbaar. Maar ook semantisch maakt het de zaken moeilijker. We mogen niet zomaar puur lokaal nadenken over alle concepten die we in onze computerprogramma’s verwerken; nee, we moeten er rekening mee houden dat ze geïntegreerd of hergebruikt kunnen worden. We moeten ervoor proberen te zorgen dat de betekenis ervan voorbijgaat aan wat puur noodzakelijk is voor ons specifieke geval. Dat soort zaken maakt het ontwikkelen van software een stuk moeilijker. Dit niet doen is echter nog erger: de “technical debt” die ontstaat door teveel kortetermijn- en lokaal denken, zal dan op termijn alleen maar onbeheersbaarder worden.

En dat is dus de paradox: de afhankelijkheid tussen de systemen binnen een applicatie ecosysteem creëert enorme business waarde, maar maakt de IT een stuk lastiger (en duurder).

De “Mesh” Architectuur

Een goede architectuur kan echter soelaas brengen in dit verhaal, en consequent rekening houden met hergebruik kan uiteindelijk zelfs geld gaan besparen. Het gebruik van een Service Oriented Architecture (SOA) is daarbij één van onze belangrijkste wapens om de afhankelijkheden in ons ecosysteem de baas te kunnen, met de Microservices Architectuur als ultieme voorbeeld. Dit zijn echter slechts voorbeeld technische implementaties van het belangrijke concept Modulariteit (dat men in principe zelfs binnenin een monolithisch systeem kan implementeren). Wat proberen we hiermee te bereiken?

• Modules zijn zo onafhankelijk van elkaar als maar kan (maar maken toch van elkaar gebruik vanwege de waarde die dit heeft): ze zijn liefst “loosely coupled”: veranderingen in de werking of het ontwerp van één module hebben zo weinig mogelijk impact op de werking of het ontwerp van een andere. Dit laat toe om ze apart van elkaar te laten werken en ze te laten onderhouden door aparte teams, zonder dat er continu overleg of downtime moet zijn (in het geval van een monoliet verliest men wel dit downtime voordeel).
• Modules zijn voldoende klein. Men volgt hier de Unix filosofie “do one thing and do it well”. In de praktijk wil dit zeggen dat modules gericht zijn op het aanbieden van één bepaalde business capabiliteit, die in principe apart kan worden gedeployed. Hoe men precies de context van een service afbakent, is één van de belangrijkste onderdelen van de Domain Driven Design (DDD) ontwikkelingsmethode.

Het tweede punt is niet te onderschatten en één van de moeilijkste zaken, reeds bij de business en functionele analyse en ook verderop in het ontwerp van software. In deze blog richten we ons echter op de aspecten van een groter ecosysteem, en daarom zullen we ons hier beperken tot de eerste vraag:

Hoe houden we onze modules zo goed mogelijk onafhankelijk, terwijl we ze toch laten communiceren?

Een aantal helpende Principes

We gaan er vanaf hier van uit dat we onze modules verpakken in aparte services, en we zullen nu een aantal ontwerpprincipes overlopen die ons gaan helpen bij het uitbouwen van een ecosysteem architectuur waarin we een grote onafhankelijkheid, maar ook herbruikbaarheid, van onze services nastreven.

1. Het gebruik van APIs. Dit principe is reeds goed gekend en vormt een basissteen van SOA: Een service stelt zich open naar de buitenwereld toe via zijn API, en deze API is dan ook het enige waarvan andere services afhankelijk kunnen zijn. Op die manier beperkt men dus de afhankelijkheid die andere zaken m.b.t. een service zullen hebben, tot wat strikt noodzakelijk is. Men is hier echter wel nog semantisch en syntactisch afhankelijk van de APIs van andere services die men wenst te gebruiken, en ook technisch afhankelijk van het online zijn van die andere services.

2. Het gebruik van Events. Event Driven Architecture is ook al oud, maar maakt meer recent furore dankzij de Reactive beweging. In plaats van (of naast) communicatie via een API, kan men de communicatie tussen services ook via het versturen van events laten gebeuren. Daar hoort bij dat een service die een event verstuurt, niet op voorhand weet welke andere services dit event zullen ontvangen. Services hebben hier enkel controle over de events die ze zelf versturen en dewelke ze zelf wensen te ontvangen. Het is duidelijk dat hier de onafhankelijkheid nog sterker is dan in het geval van APIs: men is niet langer rechtstreeks afhankelijk van de interface, noch van het online zijn, van een andere service. Men is enkel nog technisch afhankelijk van het online zijn van de Event Bus (een middleware systeem dat men met grote redundantie kan opzetten), en semantisch afhankelijk van de definitie van de betrokken events (een niet te vermijden afhankelijkheid die wordt opgelegd door de business vereiste van het gebruik van de betreffende business capabiliteit die door het event mede wordt ondersteund).

3. CQRS. Wanneer we microservices bouwen die zo klein en onafhankelijk mogelijk zijn, betekent dit eigenlijk dat we een onderscheid moeten beginnen maken tussen services die data binnenkrijgen en/of (deels) verwerken, en services die daarop verder bouwen om informatie te verschaffen en vragen te kunnen beantwoorden. Typisch zullen dit verschillende business capabilities zijn, en dus een aparte service vereisen. Bovendien maken we de microservices liefst zo klein, dat er vaak data van meerdere microservices afkomstig, nodig zal zijn om bepaalde queries te beantwoorden, waardoor het sowieso minder vanzelfsprekend wordt om de queries te implementeren als onderdeel van één van die microservices; ook daardoor wordt het dus logischer om ze in een aparte dienst te deployen. Dit principe noemen we Command Query Responsability Segregation (CQRS): we scheiden de ver-antwoordelijkheid voor het behandelen van commando’s (opnemen en verwerken van data) en die voor het beantwoorden van queries (teruggeven van, meestal verwerkte, data) in aparte services.

4. Sagas. Soms is het nodig dat in een applicatie zaken gebeuren die ofwel gezamenlijk slagen, ofwel gezamenlijk falen. Dit noemt men een transactie. Zoals reeds in een eerdere blog vermeld, is het nuttig om transacties binnen onze systemen te minimaliseren en goed na te denken op business niveau of ze echt wel nodig zijn. Desalniettemin zullen we ze toch niet geheel kunnen vermijden. Binnen één microservice is de implementatie hiervan doorgaans geen probleem: de onderliggende database zal dit ondersteunen volgens het tweefasig “commit” protocol (2 Phase Commit, 2PC). Wat we echter absoluut moeten vermijden, is om dit protocol toe te passen op meerdere services tegelijk in een gedistribueerde omgeving. Om dan toch tegemoet te komen aan de nood aan gedistribueerde transacties, kunnen we sagas gebruiken. Een saga bestaat uit een reeks lokale transacties (binnen één service), waarbij elke service een event zal publiceren om de volgende transactie binnen de saga te triggeren in de volgende service die eraan meedoet. Indien één van de lokale transacties faalt, dan zal het verstuurde event verschillen van wat het normaal is, en dan volgen compenserende transacties in de services die reeds aan beurt kwamen, om de eerdere veranderingen terug ongedaan te maken. Men kan sagas op 2 manieren implementeren: de eerste is een choreografie, waarbij de services zelf weten wat ze wanneer moeten doen (op basis van de events die ze binnenkrijgen). De tweede optie is de orchestratie, waarbij één service zal optreden als de organisator van het gebeuren en de transactie stap voor stap opvolgt. De communicatie met participerende services kan hier ook met events plaatsvinden, maar eventueel ook via rechtstreekse API calls om de opeenvolgende opdrachten te geven (de antwoorden komen dan wel best via events terug binnen in de orchestrator, anders zondigt men tegen CQRS). Een voorbeeld van een saga (met choreografie) is het verhaal van de webshop in de vorige blog over Event-Driven APIs.

Naast deze 4 principes zijn er nog een aantal secundaire ondersteunende zaken die we mogelijk kunnen doen binnen ons ecosysteem. Denk bijvoorbeeld aan het gebruik van Event Sourcing, of het inzetten van NewSQL databases om een microservice met toestand goed te kunnen schalen. Deze zaken bespraken we reeds voldoende in vorige blogposts.

Besluit: even Wennen

Een moderne architectuur voor een complex Applicatie Ecosysteem bestaat uit meer dan alleen maar APIs, en kan best stevig gebruik maken van de toegevoegde waarde die EDA en CQRS bieden. Wanneer men eerder traditionele architecturen gewend is, is de verhoogde complexiteit natuurlijk even wennen. De voordelen overwegen volgens ons echter op de nadelen van deze leercurve. Eens men deze zaken in de vingers heeft en een aantal keer heeft toegepast, zal men zowel op technisch vlak als op business vlak de pluspunten beginnen ondervinden.

Om het allemaal een beetje behapbaarder te maken, zullen we in een volgende blog trachten deze principes verder te illustreren aan de hand van een voorbeeld applicatie ecosysteem.

Vorige herfst schreven we onze eerste blog over de veelbelovende technologie NewSQL. Na een pauze en een periode met enkele testen, kunnen we nu bevestigen dat deze nieuwe databases effectief een positieve evolutie zijn.

Evolutie, geen Revolutie

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.

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 b.v. een beperkte ondersteuning voor SQL of SQL-achtige talen aan, en soms ook transacties. De traditionele relationele databases, op hun beurt, bieden allerlei manieren aan om horizontaal te gaan schalen en dus een gedistribueerd systeem op te zetten met een verhoogde beschikbaarheid. Men kan dus stellen dat de verschillende categorieën van databases dichter naar elkaar toegroeien.

Ook NewSQL kan men, zoals we reeds aanhaalden in de vorige blog, 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 nul af zijn opgebouwd met de problematiek van dit spanningsveld tussen consistentie en beschikbaarheid in gedachten, en die met een cloud native aanpak zijn ontworpen. Dit wil o.a. zeggen dat dit vanaf het begin een gedistribueerd ontwerp betreft. De basis architectuur en de opzet zijn aldus voldoende verschillend 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.

Om te zien hoe dit spanningsveld precies wordt aangepakt bij NewSQL, moeten we nog eens terugkomen op het befaamde CAP-theorema…

Van CAP naar PACELC

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 men dus, in principe, volgens het CAP theorema, zorgen voor beschikbaarheid en consistentie tegelijkertijd. In de praktijk zal dit, indien alles naar wens verloopt en er geen al te zware load op het platform inwerkt, ook zo zijn. Zelfs de “eventual” consistency van NoSQL systemen zal dan slechts seconden zijn i.p.v. de langere tijd die men van “eventual” zou verwachten.

Nochtans moet men in dit geval ook nog keuzes maken… Het PACELC theorema, een uitbreiding op het CAP theorema, stelt namelijk dat men in afwezigheid van netwerkpartities, moet kiezen tussen latency en consistentie. NoSQL trekt hier duidelijk de kaart van latency: men 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 daarentegen, kiezen consistentie: vooraleer de request wordt aanvaard, zorgt men ervoor dat voldoende nodes akkoord zijn en wanneer de request aanvaard is, zal dit 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 natuurlijk enigszins vertragen.

De afkorting PACELC kan men dan via het volgende zinnetje opbouwen: Bij netwerkpartitie (P), moet men kiezen tussen beschikbaarheid (Availability) en Consistentie (C), en anders (Else), tussen latency (L) en consistentie (C).

Wanneer men over voldoende performantie beschikt, het systeem niet overbelast is, en er geen fouten optreden, zal men in de praktijk weinig merken van dit verschil tussen latentie en consistentie. Maar de specifieke garanties die worden geboden zijn echter wel heel belangrijk om weten wanneer men deze databases gaat gebruiken, vermits er altijd wel iets zal misgaan en er altijd wel een situatie kan optreden die het systeem te zwaar belast. Wil men ten allen tijde kunnen rekenen op consistentie, of 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: Testresultaten

We testten 3 verschillende NewSQL producten tijdens deze studie: CockroachDB, TiDB en NuoDB. Het voornaamste doel van de test 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 concensus worden bereikt betreffende transacties.

De test ging als volgt: eerst bouwen we een cluster van 3 nodes voor elk van deze producten; daar wordt eventueel nog een load balancer aan toegevoegd en ook voorzien we een machine die als client zal optreden. Daarna volgen er twee testen waarbij we de cluster vanaf de client machine bestoken met requests. We gebruiken hierbij de TPCC, dit is een gestandaardiseerde test voor OnLine Transaction Processing (OLTP) Databases, het soort databases die we typisch gebruiken als backend voor online toepassingen (de typische tegenhangers zijn databases die zich focussen op analytics). De TPCC is “test C” van de TPC (transaction processing performance council), en wordt vandaag beschouwd als de meest typische maatstaf.

De twee testen verschillen in het volgende: de eerste keer gaat er niets mis: alle drie de nodes blijven netjes werken. Bij de tweede test-run zullen we echter 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.

De TPCC is in principe ook een performantietest, dus we kunnen eigenlijk ook zien hoeveel verkeer deze databases aankunnen. Dit was echter niet het hoofdopzet van de test en de resultaten kunnen hierdoor wat meer uit elkaar liggen. Ook spelen er bepaalde aspecten aan sommige NewSQL databases, die een impact hebben op de performantie, niet mee in onze test, vanwege de setup (verschillende nodes op virtuele machines, echter allen op dezelfde fysieke machine). Zo is de fysieke afstand tussen nodes belangrijk, en vaak is het ook van belang of de systeemklokken op de verschillende nodes niet teveel van elkaar afwijken (Voor Google Spanner rolt men hiertoe atoomklokken uit in de verschillende datacenters; 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 dit echter extra configuratiewerk. Voor CockroachDB en TiDB was dit 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.

Besluit

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’), waardoor ze zich veel gemakkelijker dan de traditionele relationele databases laten uitrollen in clusters van meerdere evenwaardige nodes (‘multi-master‘, i.t.t. de zgn. ‘master-slave’ setup), waarvan slechts een meerderheid operationeel moet blijven om het systeem beschikbaar te houden.

We kunnen echter ook enkele aandachtspunten aanduiden. Om een effectief systeem met hoge beschikbaarheid te hebben, moet men deze databases in principe uitrollen op verschillende locaties (eventueel zelfs in verschillende datacenters). Dit om ervoor te zorgen dat de kans zo klein mogelijk is dat verschillende nodes tegelijk falen. Tegelijk is het van belang dat deze nodes vlot met elkaar kunnen communiceren (en dat dit verkeer niet wordt onderschept) en op systemen draaien met een zo gelijk mogelijke systeemklok (voor sommige architecturen), anders wordt de performantie aangetast.

Deze aandachtspunten in beschouwing genomen, kunnen we echter besluiten dat NewSQL databases een goede keuze vormen wanneer men een cluster van redundante databases wil uitrollen voor verhoogde beschikbaarheid.

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.

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.