NoSQL-databases

Inleiding

Als we het over databases hebben dan verwijst men vrijwel altijd naar relationele databases. Voor het relationele model in 1970 bedacht werd waren er andere vormen van elektronische databases.

Relationele databases zijn de standaard geworden omdat bij dit model de opbouw en organisatie los staan van de manier van opslag: gegevens worden op een gestandaardiseerde manier opgeslagen buiten de applicatie die de gegevens gebruikt. Dit maakt de databases meer toekomst bestendig omdat de manier waarop de data gebruikt wordt kan veranderen dan waar de data in eerste instantie voor opgeslagen is.

Toch is het relationele model niet overal geschikt voor. Wanneer men met grote hoeveelheden data werkt of gegevens serveert onder hoge druk merkt men al snel op dat relationele databases hier niet in uitblinken, tenzij fors geïnvesteerd wordt in de onderliggende hardware. Maar hardware die 2x zo snel is in theorie schaalt niet 2x zo snel mee in praktijk. De performance van het systeem is niet lineair evenredig met de snelheid van de onderdelen.

In sommige gevallen is een relationele database gewoonweg niet nodig, bijvoorbeeld omdat informatie helemaal geen relatie met iets heeft en dus maar op één manier opgeslagen wordt. Of als er geen complexe queries op de data uitgevoerd hoeven te worden. In weer andere gevallen biedt een relationele database niet genoeg functionaliteit, bijvoorbeeld bij het leggen van een groot aantal verbanden tussen punten.

NoSQL-databases zijn ontwikkeld om in te springen waar SQL niet praktisch is. NoSQL is ten eerste een verwijzing naar SQL, een door IBM ontwikkelde taal voor het werken met gegevens binnen een relationele database. Voorbeelden van database software die zwaar op SQL leunen zijn o.a. MySQL – de meest gebruikte web database -, Microsoft SQL Server, Oracle Database en PostgreSQL.

De No in NoSQL verwijst niet naar geen zoals velen denken maar naar not only. Hiermee wordt bedoeld dat relationele databases niet overal voor geschikt zijn. Er is daardoor ook geen complete definitie van NoSQL-databases omdat er veel verschillende gebieden zijn waar verschillende NoSQL oplossingen uit voortgekomen zijn. Er is echter wel één eigenschap die NoSQL-databases verenigt: ze verschillen op een of meer punten van traditionele relationele databases.

Relationele schema’s

Een relationele database bestaat over het algemeen uit schema’s: tabelachtige logische gegevensstructuren. Binnen de tabellen worden entiteiten opgeslagen. Een voorbeeld van een entiteit is een gebruiker. Elke entiteit neemt één tabelrij in beslag en heeft een of meer attributen. Deze attributen worden opgeslagen als de kolommen van de tabelrij en komen bij entiteiten uit een zelfde tabel overeen.

Voorbeeld 1

Gebruiker

id naam voornaam leeftijd
1 Smit Jan 43
2 Molenaar Ad 32
3 Bakker Fred 51

Een relationele database bestaat altijd uit een tweedimensionale matrix wat zich vertaalt als een tabel. Tussen verschillende schema’s kunnen ook relaties gelegd worden: informatie uit meerdere tabellen kan op deze manier gecombineerd worden.

Voorbeeld 2

Gebruiker

id naam voornaam leeftijd
1 Smit Jan 43
2 Molenaar Ad 32
3 Bakker Fred 51

Contact

id gebruiker_id adres huisnummer postcode plaats
1 1 Ergenshuizenweg 2 1111AA Ergens
2 1 Nergenshuizenweg 4 2222BB Nergens
3 3 Blaauweogenstraat 7 3333CC Verreweg

SELECT Gebruiker.id, Gebruiker.naam, Gebruiker.voornaam, Contact.id, Contact.gebruiker_id, Contact.adres, Contact,huisnummer, Contact.plaats FROM Gebruiker,Contact WHERE Gebruiker.id = Contact.gebruiker_id

Gecombineerde schema’s

Gebruiker.id naam voornaam Contact.id adres huisnummer plaats
1 Smit Jan 1 Ergenshuizenweg 2 Ergens
1 Smit Jan 2 Nergenshuizenweg 4 Nergens
3 Bakker Fred 3 Blaauweogenstraat 7 Verreweg

De populariteit van NoSQL is de afgelopen jaren bijzonder snel toegenomen. NoSQL zet veel van de relationele principes overboord. Een NoSQL-database heeft juist de mogelijkheid ééndimensionaal te zijn, zoals MemcacheDB en SimpleDB. Maar ook zijn er NoSQL-databases die meer dan tweedimensionaal zijn, zoals Cassandra en Big Table. Andere NoSQL-databases zijn weer ontworpen voor het leggen van verbanden tussen een grote hoeveelheid data.

Flexibiliteit

NoSQL-databases hebben vaak geen of beperkte mogelijkheden om schema’s te combineren. Bij NoSQL-databases zou dat namelijk zeer inefficiënt zijn. In plaats daarvan is de ontwikkelaar verantwoordelijk om dit soort functionaliteit zelf in te bouwen in zijn applicatie. Het ontbreken van zogeheten joins kan een nadeel zijn als de complexiteit van een applicatie hierdoor toeneemt, maar zorgt ervoor dat NoSQL-databases een belangrijk voordeel behalen: horizontaal schalen.

Relationele databases zijn – tot op een zekere hoogte – flexibel, maar creëren een relatief zware last op een server. Wanneer veel dynamische gegevens opgevraagd worden neemt de kans dat de databaseserver overbelast raakt toe. Er wordt vaak geïnvesteerd in hardware als oplossing voor dit probleem.

Horizontaal schalen – dat wil zeggen: het bijplaatsen van extra servers – is met relationele databases echter erg lastig. Dat heeft te maken met de aard van relationele databases: de relatie tussen data. Alle items die een relatie met elkaar hebben zouden vanwege efficiëntie bij elkaar op dezelfde node/server moeten staan. Vandaar dat, om de performance te vergroten, databaseservers van relationele databases vaak verticaal geschaald worden: de server zal beter moeten presteren dus wordt er snellere of een veelvoud aan hardware bijgezet. Financieel is dit uiteraard een rampzalige investering. Krachtige databaseserver van bijvoorbeeld Oracle en IBM kosten als snel in de honderdduizenden of zelfs miljoenen euro’s. Horizontaal schalen is relatief goedkoper. Servers met relatief eenvoudige hardware kunnen worden toegevoegd aan het cluster van servers zodat de performance winst die daarmee behaald wordt naar verhouding goedkoop is.

NoSQL flavours

Sleutels en waarden

Een key-value store is een type NoSQL-database dat zich makkelijk horizontaal laat schalen. Dit systeem is bedoeld voor de opslag van grote hoeveelheden gegevens die heel vaak moeten worden uitgelezen.

Een voorbeeld van een key-value storage systeem is de Dynamo-database van Amazon. Amazon moet blijven werken als harde schijven, routers, serverracks of zelfs hele datacenters uitvallen. Gegevens moeten op elk willekeurig moment beschikbaar zijn. Volgens Amazon is een relationele database te veel van het goede: in de meeste gevallen wordt data alleen via primary keys benaderd; complexe queries worden veel minder vaak uitgevoerd. Daar Dynamo niet heel veel anders doet dan een bepaalde waarde bij een primary key opslaan/ophalen kan deze veel efficiënter werken dan een complexe relationele database.

Documenten

Enigzins verwant aan de key-value stores zijn de document-orientated databases, zoals MongoDB en CouchDB. Een “tabel” in een document database bestaat – om het even simpel te zeggen – uit een verzameling key-value paren. In elke document-entry kunnen verschillende soorten informatie worden opgeslagen, zonder dat de tabelstructuur hoeft te worden gewijzigd. Een handig voordeel van document-orientated databases is het opslaan van nested key-value paren.

Voorbeeld 3


{
    _id: ObjectId("507f1f77bcf86cd799439011"),
    naam: "Smit",
    voornaam: "Jan",
    leeftijd: 43,
    adressen: [
        {
            adres: "Ergenshuizenweg",
            huisnummer: 2,
            postcode: "1111AA",
            plaats: "Ergenshuizen",
        },
        {
            adres: "Nergenshuizenweg",
            huisnummer: 4,
            postcode: "2222BB",
            plaats: "Nergenshuizen",
        },
    ]
}

Op het moment is MongoDB de populairste document-orientated database. Deze storage oplossing werkt met opslag van JSON achtige documenten (BSON) zoals in Voorbeeld 3 beschreven wordt. MongoDB biedt bepaalde functionaliteiten die SQL ook biedt zoals indexen en dynamische queries. Queries op MongoDB zijn in feite JavaScript-expressies.

Brede kolommen

Zogenaamde wide-column stores, zoals Cassandra en Apache HBase, zijn geoptimaliseerd voor queries over enorme datasets en slaan kolommen aan data op in plaats van rijnen. In feite zijn wide-column stores de tweedimensionale versie van key-value stores. Een entry kan miljaden dynamische kolommen hebben; de kolommen en de entry-keys staan niet vast.

Voorbeeld 4

image7

Graafdatabases

Tot slot zijn er ook nog graafdatabases. Dit heeft niks met zand en een schep te maken; wie bekend is met grafen begrijpt dat onderlinge verbanden tussen entiteiten het uitgangspunt zijn. Er is geen centrale index, verbanden tussen entry’s worden door middel van recursie vastgelegd. Dit maakt graafdatabases minder schaalbaar dan andere NoSQL-databases.

Voorbeeld 5

RequestInGraph

Graafdatabases kunnen bijvoorbeeld worden gebruikt voor wiki’s of sociale-netwerksites omdat er veel sprake is van onderlinge verbanden. Het zou inefficiënt zijn om voor elk mogelijk verband een query uit te moeten voeren als rechtstreekse verwijzingen naar andere data opgeslagen kunnen worden.

Tot slot

Hoewel NoSQL databases de afgelopen jaren steeds meer voeten in de aarde hebben gekregen, onder andere vanwege de mogelijkheid tot efficiënt horizontaal schalen, betekent niet dat relationele databases gaan verdwijnen. Voor veel doeleinden zijn SQL databases prima geschikt.

Door de explosie aan data onder andere door de grootte van het internet is er echter behoefte ontstaan naar alternatieve opslagmethoden. NoSQL databases worden steeds stabieler en krijgen ook steeds meer functionaliteit. Toch moet er ook rekening gehouden worden dat net als cloud computing, het begrip NoSQL net zo uitgebreid als nietszeggend is. Het is belangrijk in het achterhoofd te houden dat NoSQL-databases niet overal de oplossing voor zijn.