Sinds de komst van Web 2.0 is de hoeveelheid informatie die opgeslagen en verwerkt moet worden gigantisch toegenomen: elke dag genereren miljoenen mensen massa’s ongestructureerde data — documenten, emails, tweets, foto’s,etc…

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