Wie geeft er nu om een databank?

Ik heb lang gedacht dat software eigenlijk om business logica draaide. Zolang je maar een goed idee had over wat je wilde bouwen, over de functionaliteit die je ter beschikking wilde stellen aan je eindgebruikers, kon je een toepassing maken die - met behulp van de “logica” die de toepassing zou automatiseren - iets maken dat werkelijke problemen voor eindgebruikers zou oplossen. En zo is het eigenlijk ook zo - maar toch ook eigenlijk alleen maar ten dele.

Want ondertussen weten we denk ik wel dat toepassingen - goed geschreven toepassingen althans - bestaan uit meer dan alleen maar automatiseringslogica. Je hebt bijvoorbeeld ook een sexy frontend nodig, nietwaar? Het moet er mooi uit zien, nietwaar? Het moet klikken en swipen en geluid maken - en gewoon fijn zijn om te gebruiken. Daar is iedereen het over eens. Maar volgens mij moet er ook een deftige data-laag, een deftige databank achter zitten - anders gaat het ook niet werken. Maar wie, o wie, geeft er nog om een databank? Hadden we dat probleem al niet opgelost ergens in de jaren zeventig/tachtig? Nee dus. Echt. Niet.

Voor mij een databank! Een blauwe met roze stippen!

Er zijn immers echt heel wat dingen in een databank die nefast kunnen zijn voor de feestvreugde. De twee belangrijkste problemen die ik in projecten al ben tegengekomen zijn

• “Het ding is niet vooruit te branden”. Met andere woorden: performantieproblemen die in databank-systemen opduiken, vaak uit het niets, naarmate de grootte van de databank groeit. Het ding werkt prima op mijn machine, maar in productie zakt het als een pudding in elkaar! Why o why?

• “Dat stukje nieuwe functionaliteit kunnen we niet in dit model realiseren - we gaan moeten migreren.” Databanken maken gebruik van schema’s die de structuur en de integriteit van de data bewaken. Ze zijn daar erg goed in geworden. Zo goed, dat het vaak haast onmogelijk is om dingen te veranderen en te laten evolueren op een vlotte, transparante manier. Elke nieuwe versie wordt daardoor een pijnlijke oefening.

Dat moet toch beter kunnen, zou je denken? We betalen die databank-leveranciers toch genoeg aan licentie-kosten? 

En ja hoor, de voorbije tien jaar is er enorm veel geïnnoveerd in de databank-wereld. Gedreven door giganten als Amazon, Google en Facebook, heeft de software-industrie enorme stappen voorwaarts gezet om het databank-vraagstuk op te lossen. Veel mensen hebben die beweging de “NOSQL” beweging genoemd - en die term is al even vaak geroemd als verguisd geweest. Sommigen interpreteren het als “Weg met SQL”, maar de meeste weldenkende professionals hebben het naar mijn mening opgevat als “Niet alleen maar SQL”. Met andere woorden: laat ons eens goed kijken wat we precies willen van die databanken, en dan eens nadenken over welke databank we zouden moeten gebruiken, voor welke specifieke taken. Een “taakgerichte” benadering dus - waarbij de “use case” voorhanden zou bepalen welke databank we zouden kunnen of moeten gebruiken.

Op zich super interessant. En als we even terugblikken op de voorbije tien jaar, dan zijn er ook enorme schreden voorwaarts gemaakt. Vandaag de dag zijn er echt ongelooflijk veel verschillende soorten databanken bijgekomen, zoals je mooi kan zien op de Data Platforms Map van de adviesgroep 451 Research:

Daar staan dus letterlijk honderden databank systemen op die allemaal voor een bepaalde taak, in een bepaalde context, wellicht superformidabelexpiallidocious zijn. Dus hoe door het bos de bomen te zien? Wat gebruik je waarvoor? Da’s een goeie, een zeer goeie vraag.

4 soorten NOSQL

De bovenstaande overview van alle verschillende databank-systemen lijkt misschien op een grote warrige haarbal - en dat is het wellicht ook. Maar als je er een beetje over nadenkt dan kan je eigenlijk wel een aantal “types” databanken onderscheiden die echt gespecialiseerd zijn in het bevraagbaar maken van data-structuren - dingen waar je een query op kan afvuren. Ik heb geprobeerd ze schematisch hieronder samen te vatten, en zal ze ook kort even toelichten:

1. Ten eerste maken we het onderscheid tussen data “processing” en data “querying”. Het eerste doe je tussen het avondeten en het ontbijt, het tweede tussen een web-request en een web-response. Het eerste is typisch batch-georiënteerd, het tweede is (near) real time. 
2. Ten tweede maken we - binnen de data querying tools - het onderscheid tussen relationele en niet-relationele systemen. Sure, er zijn nog andere databank-structuren (denk aan object-databanken, hierarchische databanken, CODASYL databanken op de mainframe, etc), maar ik wil graag duidelijk maken dat de “NOSQL” systemen eigenlijk zijn ontstaan als reactie op een paar aanhoudende problemen in het relationele model.
3. Ten derde zijn er de NOSQL stores, die soms worden aangewend om relationele systemen te vervangen, maar vaker ingezet worden samen met die “oudere” systemen. Binnen de NOSQL categorie vind je eigenlijk twee categorieën van systemen, die ook twee problemen van het relationele model proberen aan te pakken 

• je hebt de “aggregate stores”. Dit is een term die eigenlijk het eerst gebruikt werd door Martin Fowler, en waarmee we willen aanduiden dat het gaat om een “geaggregeerd” datamodel, waarin gewerkt wordt met “eenvoudiger”, minder genormaliseerde datastructuren. Het grote voordeel van dat model is dat het veel makkelijker schaalt - en dat ze daarmee het volume-probleem van het relationele model effectief oplossen. Het is immers zo dat relationele systemen de nare bijwerking hadden dat ze typisch trager werden naarmate de dataset groeide. Da’s ook logisch - dingen zoals join-operaties zijn ook moeilijker uit te rekenen over grote tabellen. In een “aggregate store” heb je dat probleem niet. Je geeft eigenlijk query-kracht op voor schaalbaarheid - wat, afhankelijk van de use case, spectaculaire en positieve resultaten kan bieden.
• je hebt de “graph stores”, zoals Neo4j - het product van het bedrijf waar ik voor werk. Die systemen lossen eigenlijk een ander probleem op van de relationele systemen - met name het probleem met complexe, join-intensieve queries. Die zijn haast onoplosbaar in het relationele model, maar worden super-performant en heel beheersbaar wanneer mensen kiezen voor het veel verfijnder, genormaliseerder en granulairder model van de “property graph”. 

Daarmee weten we welke databank systemen we vandaag de dag tot onze beschikking hebben - wanneer zou je nu wat moeten gebruiken? Bestaan er daar regeltjes voor?

Niet alleen big, ook dark data

Niet echt, natuurlijk. In echte “consultancy-speak” zou je eigenlijk moeten kunnen zeggen “dat het er van afhangt”, en dat is natuurlijk het enige juiste antwoord - maar kunnen we geen algemene, veralgemeende richtlijnen geven? Ik denk persoonlijk van wel.


In onderstaande tabel heb ik geprobeerd die richtlijnen samen te vatten - uiteraard onvolledig maar hopelijk toch nuttig:



Ik hoop met bovenstaand overzichtje te hebben duidelijk gemaakt dat de verschillende NOSQL databanken eigenlijk heel erg verschillende problemen proberen op te lossen. De Aggregate stores gaan allemaal over een oplossing van het schaalbaarheidsprobleem - en de Graph stores willen eigenlijk eerder een probleem rond complexiteit en inzicht oplossen. De eersten gaan over BIG DATA problems, de tweeden gaan over big DATA PROBLEMS. Als u begrijpt wat ik bedoel.

Geen exotische technologie!

Om af te sluiten wil ik nog wel even benadrukken dat het hier niet over een of andere super-exotische technologie gaat. Het voorbije decennium heeft zowat elk bedrijf dat op een serieuze manier met data bezig is (dus: zowat alle bedrijven dezer dagen) aandacht besteed aan de manier waarop die data moest verzameld, opgeslagen en behandeld worden. Daarom zijn er heel wat nieuwe databanken opgestaan - waaronder dus de NOSQL systemen, waaronder de grafendatabanken die wij met Neo Technology proberen te promoten. Vele van die databanken, waaronder Neo4j, worden onder een open source ontwikkelmodel beschikbaar gemaakt. Dat betekent dat in de eerste plaats dat het erg makkelijk is voor mensen om er mee aan de slag te gaan en voor zichzelf uit te maken of ze met deze technologie toegevoegde waarde kunnen creëren. Daarom ook dat ik iedereen uitnodig om een aantal van de volgende resources eens te bekijken om een idee te krijgen van de technologie en er mee aan de slag te gaan:

• http://neo4j.com/use-cases-c/ voor een overzicht van de verschillende use cases voor grafendatabanken
• http://neo4j.com/book-learning-neo4j/ voor een gratis boek waarin de concepten en een aantal voorbeelden worden uitgelegd
• http://graphgist.neo4j.com/ voor een grote collectie met voorbeelden van grafenmodellen en -queries.
• http://neo4j.com/download/ voor een download van de Neo4j Community en/of Enterprise edities.

Voor vragen of opmerkingen, kan je steeds terecht bij rik@neotechnology.com. 

Hopelijk was dit nuttig.

Rik