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.

Pour mener cette étude, nous sommes partis de la définition suivante de l’archivage (déjà exposées ici) :

« Archiver consiste à prendre un objet et à le transférer sous certaines conditions dans un système qui permettra d’en assurer la préservation pendant un certain laps de temps avec toute la sécurité requise ».[1] Ce qui implique les actions suivantes :

• sélection de l’information ;
• transfert dans un autre système pour en assurer la sécurité (gestion de l’intégrité et de l’authenticité) ;
• préservation de l’information, c’est-à-dire aussi la couche physique que la couche logique et sémantique ;
• gestion de la durée de conservation de l’information.

Il s’agit donc d’une définition et d’une acceptation plus large (issues du domaine du « records management ») que le transfert de vieilles données « à la cave », conception encore largement répandue et reprise sous le terme anglais « archiving ».

Nous avons envoyé cette définition, accompagnées d’autres éléments importants (Database Archiving – General information about existing solutions), aux fournisseurs que nous avons contactés en leur demandant de positionner leur solution par rapport à ces différents points. Sur cette base, nous avons pu distinguer différentes familles :

• Au niveau de la forme d’archivage : certains systèmes vont archiver les données sous la forme d’une autre base de données, de même type que la base de données de production ou non, tandis que d’autres vont archiver les données sous forme de fichiers, eux-mêmes référencés à l’aide de métadonnées. Si la forme « base de données » peut présenter des avantages, notamment en termes d’accès et de consultation, elle ne représente pas une solution à long terme. La conservation des données sous forme de fichiers est donc vivement recommandée à long terme.
• Au niveau du processus de capture : certaines solutions (dites PULL) se connectent à la base de données source en vue d’extraire elles-mêmes les données sur la base des paramètres introduits. Ces solutions proposent des fonctionnalités avancées de data profiling, d’extraction, … Les autres systèmes (dits PUSH) sont plus passifs : les données sont extraites de la base de données de production et poussées vers la solution d’archivage (on parle de versement). Les systèmes PULL offrent une aide non négligeable aux utilisateurs mais posent néanmoins des questions de sécurité (puisque la solution d’archivage doit disposer de droits de suppression dans la base de données de production) et gèrent rarement les questions d’intégrité (cf. point suivant).
• Au niveau de la gestion de l’intégrité : certains systèmes font de la gestion et du contrôle de l’intégrité des données une fonctionnalité au cœur de la solution, tandis que d’autres laissent ce soin à un outil tiers (que ce soit au niveau software ou hardware).

Voici le tableau récapitulatif des solutions examinées (les solutions ont été anonymisées) :

Sur cette base, les éléments suivants ont pu être mis en évidence :

• Les solutions positionnées sur le marché du « Database Archiving » sont toutes de type PULL. Ce positionnement est en cohérence avec la définition du terme anglais « archiving » qui consiste à déplacer des données moins utilisées ou ‘obsolètes’ vers un espace tiers afin d’optimiser les applications en production. Ces solutions ne traitent quasiment jamais de l’intégrité des données archivées. Par conséquent ces solutions ne répondent pas de manière complète à la problématique de l’archivage selon la définition que nous y avons donnée.
  Ces solutions présentent toutefois des fonctionnalités avancées pour l’extraction des données.
• Les solutions de type PUSH se situent davantage sur le marché du records management. Dans ce cas, l’intégrité fait partie inhérente des solutions mais elles disposent de fonctionnalités de gestion du cycle de vie.
• Pour une couverture fonctionnelle complète de la définition de l’archivage que nous avons proposée, deux outils seront donc nécessaires, quoique la partie extraction puisse être exécutée manuellement, c’est-à-dire par des administrateurs de la base à l’aide de requêtes SQL.
• La méthode PULL est transactionnelle, ce qui correspond davantage à la manière de travailler dans le monde des bases de données. La transaction est terminée quand les données sont archivées, alors que dans le cas de la méthode PUSH, la transaction se terminerait par le dépôt des données sur un file system où la solution d’archivage les capture. Par conséquent, la méthode PUSH ne permet pas une transaction unique positionnant d’abord l’archivage effectif des données et ensuite la suppression desdites données.
• Les fonctionnalités d’extraction sont uniquement disponibles pour les bases de données relationnelles. Aucun fournisseur n’a de connecteurs vers des bases de données non relationnelles, même ceux qui ont des relations historiques avec ce type de base de données.
• La consultation des données archivées issues d’un DBMS est plus mures dans le cas des outils PULL que PUSH. Ces solutions proposent généralement des fonctionnalités d’accès soit via IHM, soit via des connecteurs ODBC/JDBC (ce qui rend les accès applicatifs possibles). Dans le cas des outils PUSH, des fonctionnalités de consultation et d’accès sont possibles mais plus génériques et elles prennent donc moins en compte les spécificités des données issues d’un DBMS.
• Enfin, plusieurs solutions archivent les données dans un format ouvert et documenté (CSV, XML, containeur tar.gz), ce qui est un atout pour un archivage pérenne. Les solutions proposant des formats propriétaires ne sont donc pas à privilégier.

Un conseil pour finir : indiquez bien aux fournisseurs votre définition de l’archivage afin de pouvoir examiner leurs solutions de manière critique.

Traditionele relationele databanken (gebaseerd op SQL) zijn van nature niet goed geschikt om met deze vormen van gegevens om te gaan omdat ongestructureerde data zich niet goed vertaalt in een vast schema.  Schaalbaarheid wordt dan ook een probleem.

Om deze reden heeft er zich sinds enkele jaren de trend ingezet om af te stappen van de doctrine van relationele-databanken.  Deze beweging wordt aangeduid met de term “NoSQL”  en bestaat sinds ongeveer 1998.

Geschiedenis

NoSQL (soms ook “not-only-SQL” genoemd) is een controversiële benaming bedoeld om developers wakker te schudden en te confronteren met het feit dat er naast SQL nog andere types databanken bestaan, die efficiënter of eenvoudiger zijn. Kort komt het erop neer dat men voor elke toepassing een aangepast databankalgoritme gaat gebruiken, in plaats van RDBM systemen te gebruiken in een  “one-size-fits-all” aanpak.

De idee van niet-relationele databanken is uiteraard niet nieuw, ze gaan al mee sinds de jaren ’60.  De recente explosie van ongestructureerde data en de mogelijkheden van Cloud Computing hebben ze echter nieuw leven ingeblazen.

Definitie

Conceptueel komt het erop neer dat men afstapt van één universeel model voor alle databanken, zoals bij Relationele Databank systemen het geval is. 

In de plaats daarvan gaat men specifieke, conceptueel simpele databanken gebruiken die een hogere performantie bieden, eenvoudig te begrijpen zijn en (meestal) horizontaal extreem schaalbaar. Vooral bij ongestructureerde data blijkt deze aanpak erg vruchtbaar, in tegenstelling tot relationele databanken.

NoSQL databanken zijn minder flexibel en hierdoor ook conceptueel eenvoudiger. Ze zijn zogenaamd “schema free”, kennen geen JOINs en worden niet gequeried aan de hand van SQL maar aan de hand van een simpele API.  Omwille van deze redenen zijn ze dan ook performant. NoSQL databanken kunnen, omwille van hun beperkte functionaliteit en flexibiliteit, erg performant en vaak ook extreem schaalbaar geïmplementeerd worden.  Er wordt echter meer verantwoordelijkheid doorgeschoven naar de ontwerper.

Types NoSQL databanken

Momenteel bestaan NoSQL databanken grofweg uit volgende vier categorieën:

Key-value stores

Een key-value store is niets meer dan een hash: een vlakke gestructureerde databank die bestaat uit een verzameling unieke paren van keys en bijhorende value. Door hun grote eenvoud zijn ze extreem snel & schaalbaar.  De value is van het type “blob” en kan dus vanalles zijn. Voorbeelden: Amazon Dynamo, Voldemort,…

Column-Oriented databases

Kolom-georienteerde databanken bewaren sterk-gestructureerde gegevens in een tabel gebaseerd op kolommen in plaats van rijen.  Ze worden vaak gebruikt in datawarehouses en andere data-intensieve applicaties omdat ze kolom-gerelateerde bewerkingen (zogenaamde geaggregeerde bewerkingen) in een gedistribueerde omgeving versimpelen & versnellen: de disk seek time wordt aanzienlijk verkleind als alle gegevens uit één kolom achtereen staat op disk….

Bovendien wordt ook compressie efficiënter omdat gelijkaardige data (gegevens uit één kolom) waarschijnlijk meer gelijkaardige patronen bevat.  Daartegenover staat dat random access trager wordt. Voorbeelden: Cassandra (Facebook), Google BigTable, Apache HBase,…

Document-based stores

Dit type databank is in feite een uitbreiding van de key-value store, waarbij de value een heel record (bv. XML) is waarvan de structuur gekend is door de databank en door haar ook gequeried kan worden. Voorbeelden: Apache CouchDB, Amazon SimpleDB,…

Graph databases

In Graph Databases worden gegevens voorgesteld door een geheel van entiteiten (nodes) en verbindingen (edges) en relaties (properties) tussen deze entiteiten. Er worden door de API verschillende methodes aangeboden die de manipulatie van de grafen en het doorzoeken ervan mogelijk maakt.  Ze zijn niet gebaseerd op JOINs en bovendien is de structuur (relatie tussen de entiteiten) vrij, in tegenstelling tot relationele databases.  Voorbeelden: InfoGrid, Neo4j,…

High availability

Theoretische achtergrond

NoSQL databanken worden vaak geassocieerd met High Availability. De reden hiervoor wordt in volgende paragrafen uitgelegd, maar eerst moeten we dat dieper ingaan op de theoretische achtergrond van High Availability.

Het CAP theorema poneert dat bij gedistribueerde systemen (dus bij schaalbare systemen), van de volgende drie niet-functionele requirements (NFR’s):

• Consistency (elk deelsysteem geeft hetzelfde antwoord)
• Availability (we krijgen steeds antwoord)
• Partition tolerance (we zijn niet gevoelig aan uitvallen van een  netwerkverbinding noch van een ander deelsysteem)

er slechts twéé tegelijk voldaan kunnen zijn.  

ACID vs. BASE

RDBMS systemen kiezen voor Consistency en Partition Intolerance en worden daarom ACID systemen genoemd:

• Atomic: de mate waarin het DBMS garandeert dat een transactie ofwel geheel wordt uitgevoerd, ofwel geheel nietig is.

• Consistency: Een transactie creëert ofwel een nieuwe geldige staat of herstelt de staat die er was (in geval van een fout of een probleem). Dit impliceert dat na de transactie alle integriteitsregels van de database moeten gelden.

• Isolated: transacties worden geïsoleerd van elkaar uitgevoerd, dat wil zeggen dat transacties die tegelijkertijd worden uitgevoerd geen inzicht hebben in elkaars tussenresultaten.

• Durability: waardoor een voltooide transactie later niet ongeldig gemaakt kan worden.

Een van de gevolgen van het CAP theorema is dat deze RDBMs systemen erg moeilijk High Available te maken zijn (omdat ze voor P & C kiezen).  NoSQL systemen daarentegen kiezen (meestal) voor de zogenaamde BASE aanpak:

• (Basically) Available: Availability wordt bereikt door het falen van deelcomponenten toe te laten zonder het geheel unavailable te maken.  Inconsistenties worden op hoger, business level opgelost (de B werd toegevoegd voor het acroniem)

• Soft-State: De database is niet consistent op elk moment maar in voortdurende transitie.  Consistentie wordt niet afgedwongen na elke transactie. De verschillende transacties kunnen invloed op elkaar hebben.

• Eventually Consistent: In geval van falen en de problemen op business niveau op te vangen eerder dan op lager, programmatorisch niveau.  Vaak kan de availability enorm verhoogd worden met minimale gevolgen voor de gebruiker door hiermee rekening te houden tijdens het ontwerp van de software.  De truc is dat de inconsistenties op business niveau worden geresolved.

Merk op dat de zwakke, tijdelijke inconsistentie enkel optreedt op momenten dat een strikter systeem volledig onbeschikbaar zou zijn!!

Besluit

Door deze inconsistenties toe te laten, kan een hoge Availability bereikt worden voor een lagere kost in vergelijking met traditionele relationele databanken… Indien goed gebruikt zijn de voordelen van NoSQL databanken dus:

• hoge performantie
• hoge beschikbaarheid
• hoge schaalbaarheid
• eenvoudig te begrijpen

Daartegenover staat echter dat:

• er meer werk aan de designer wordt overgelaten om de reliability te garanderen
• er nagedacht moet worden over het oplossen van inconsistenties
• minder documentatie en “ecostructure” (database management tools, …) beschikbaar is