Big data en NoSQL

Alles wat we onder de noemer ‘niet gestructureerde data’ kunnen vatten, noemen we voor het gemak big data. Maar vooralsnog zet dit begrip de fundamenten van dataopslag en -verwerking op hun kop.

Kent u het bedrijf Rapleaf? Misschien niet. Toch was het een van de belangrijkste steunpilaren van de online marketingcampagne in de aanloop naar de laatste Amerikaanse presidentsverkiezingen. Alleen dit bedrijf kon de politieke partijen de zekerheid geven dat hun advertenties aan het juiste publiek getoond zouden worden. Rapleaf houdt immers van elk van ons een zeer gedetailleerd profiel bij, zonder dat we hiervoor expliciet ingetekend hebben.


Rapleaf doet niets illegaals: het baseert zich op datasporen die we achterlaten op internet. Via trackers die het – met medeweten van de gebruikers – op een aantal belangrijke websites en online banneringbedrijven geïnstalleerd heeft, volgt Rapleaf ons surfgedrag. Daar is op zich niets nieuws of origineels aan. Daarnaast stuurt het bedrijf echter ook web­crawlers internet op om dit anonieme, op surfgedrag gebaseerde profiel te verrijken met publiekelijk bekende persoonlijke informatie. Gegevens uit uw Facebook-profiel bijvoorbeeld, een Flickr-account enzovoort.


Rapleaf wist tijdens de Amerikaanse presidentsverkiezingen of iemand republikein dan wel democraat was, door slimme segmentatie aan de hand van dit verrijkte profiel. Het bedrijf weet zelfs of u hetero of homo bent, kent uw leeftijd met een afwijking van drie à vijf jaar en weet of u houdt van tuinieren dan wel astrologie. Rapleaf weet alles, soms tot en met uw echte naam en e-mailadres, de holy grail voor de gemiddelde onlinereclamejongen. Als u zich ooit hebt afgevraagd waarom die contextafhankelijke banneradvertenties toch zo akelig accuraat zijn, dan weet u het nu: Rapleaf.


Zaak van leven of dood


Het spreekt voor zich dat even uw surfgedrag bijhouden of even internet op gaan met een webcrawler eenvoudiger klinkt dan het is. Zo’n activiteit genereert immers een waanzinnige hoeveelheid data, vaak vele honderden megabytes of terabytes per dag. En dan is Rapleaf nog een kleine speler in vergelijking met de écht grote databoeren van internet: Google, Yahoo!, Facebook, Twitter, Amazon, StumbleUpon enzovoort. Daar wordt intussen al vlot met petabytes gehandeld en is een datacluster vaak samengesteld uit duizenden nodes of servers.


Het klinkt ons niet meer zo gek in de oren dat de waardebepaling van dit soort bedrijven minder en minder gebaseerd wordt op omzet of andere klassieke parameters; de waarde van pakweg Facebook of Google wordt vaak uitgedrukt in dollar per profiel. Correcte, robuuste en schaalbare dataopslag en -verwerking is voor deze bedrijven dan ook een zaak van leven of dood. 


Laat ik u één verrassing alvast niet onthouden: ze gebruiken voor de opslag en verwerking van die data géén relationele databases van Oracle, IBM of Microsoft. Google, Facebook, Yahoo! en Amazon zijn de bedenkers van een volledig nieuwe aanpak rond dataopslag en -verwerking, die momenteel gegroepeerd wordt onder de vlag ‘big data’. Het was deze bedrijven al snel duidelijk dat de voormalige state of the art – de klassieke enterprise-relationele database – niet volstaat om te schalen naar de volumes van 
dataopslag en -gebruik waarmee ze nu worden geconfronteerd.


Aspecten van schaalbaarheid


Bij het uittekenen van een enterprise­architectuur worden de zogenaamde niet-functionele requirements al snel op één hoop gegooid als ‘verondersteld geïmplementeerd’. Dan spreken we over architectuureigenschappen als consistentie, schaalbaarheid, beschikbaarheid en robuustheid. Bij gebruik van een klassieke, RDBMS-gebaseerde aanpak en beperkte data- en gebruiksvolumes zijn dit relatief courante systeemeigenschappen. Moeilijker wordt het als de hoeveelheid data (of gebruikers) zo groot wordt, dat één fysieke server niet meer volstaat.


Het garanderen van consistentie bijvoorbeeld – de zogenaamde ACID-garantie 
(atomicity, consistency, isolation en durability) van een relationele database – is slechts eenvoudig (en dan nog) bij een single-nodeserver. Het locken van een databaserecord bij een schrijfoperatie in een multi-nodegedistribueerde architectuur – om te vermijden dat twee processen op dezelfde plaats gelijktijdig data proberen weg te schrijven – wordt al snel een heel stuk complexer. Zeker als men daarbij het bouwen van een central locking service wil vermijden (die op zijn beurt een central single point of failure zou worden).


Het grote voordeel van een relationele database is de link tussen het datamodel en de querytaal SQL: het staat de gebruiker vrij om ad-hocquery’s te bedenken. Wanneer bepaalde query’s duur of traag worden in on the fly berekeningstijd, is het relatief eenvoudig om indexen te definiëren, die ervoor zorgen dat trage query’s weer snel (kunnen) worden. Men offert echter een stuk schrijf­snelheid op om snellere lees- en zoeksnelheid te garanderen, door een deel van de mogelijke antwoorden op toekomstige vragen vooraf te berekenen en op te slaan; in een index dus.


Het bijhouden van vele indexen, gecombineerd met de vereisten van de ACID-garantie, kan de databaseserver zwaar belasten; het systeem kan zo overbelast raken door de toevloed aan schrijfoperaties, dat het lezen wederom erg traag wordt. Mocht u zich ooit hebben afgevraagd waarom een goede database administrator van onschatbare waarde is en dus ook veel kost: de ideale balans kennen tussen lees- en schrijfoptimalisatie is specialistenwerk en slechts weinigen gegeven. Wanneer men door het volume aan gegevens verplicht wordt over verschillende servers te schalen, is het vrij logisch die gedistribueerde verwerkingscapaciteit ook te gebruiken om te parallelliseren. En zo komen we aan bij zoo van gedistribueerde systemen.


Google


In 2003 en 2004 publiceerde Google een aantal researchpapers over zijn data­centertechnologie.1,2 Het bedrijf maakte, zoals intussen breed bekend, gebruik van grote hoeveelheden commodityservers, die het op applicatieniveau integreerde alsof ze één groot systeem vormden. Het gebruik van vele, goedkope servers verplichtte 
Google om het falen van één fysieke node als een normale gebeurtenis te beschouwen. De robuustheid van zijn datacenters werd dan ook mede mogelijk gemaakt door het opvangen van systeemfalen op applicatieniveau. 


Immers, en dat is misschien wel de belangrijkste observatie die in dezen te maken is: relationele databases en de klassieke 
enterprisearchitecturen hebben ons jarenlang in slaap gewiegd met het zogenaamd transparant opvangen van infrastructuurfalen, terwijl elk van ons weet dat zoiets in de praktijk quasi-onmogelijk is. Door dit soort falen op applicatieniveau op te vangen, verplicht de applicatieontwikkelaar zich ertoe om op een correcte manier na te denken over transactionaliteit, dataopslag en -toegang, en interprocescommunicatie (al dan niet over het netwerk). Op een coherente manier nadenken over deze boundary use cases kan leiden tot gigantische winsten aan schaalbaarheid, doorvoersnelheid en robuustheid.


Maar goed, Google dus. Onderaan in hun applicatiestack was er Google File System of GFS, een zeer schaalbaar gedistribueerd filesysteem dat gebruikt werd om enorme hoeveelheden data in op te slaan; de index van het web met name. Om die enorme hoeveelheden data op een ordentelijke manier te verwerken werd boven op GFS een applicatieraamwerk voorzien: Map/Reduce, dat de ontwikkelaar ondersteunde in het uitsplitsen en parallelliseren van de dataverwerking. 


Op conceptueel niveau biedt Map/
Reduce de gecombineerde rekenkracht van tientallen tot zelfs duizenden servers aan als één grote parallelle verwerkingsmachine. Map/Reduce zorgt voor de taakverdeling, vangt het falen van individuele servers op en biedt een eenvoudig model aan voor de gedistribueerde batchverwerking van datafiles boven op het gedistribueerde filesysteem. 


Voor interactieve applicaties boven op GFS en Map/Reduce en het beheren van meer gestructureerde, tabulaire gegevens bedacht Google vervolgens BigTable,3 een data­managementtoepassing die low-latency read/write-operaties aanbiedt en die uiteindelijk ook de ‘database’ is waar bovenop 
Google de eindgebruikersapplicaties implementeert (Gmail, Picasa et cetera).


Hadoop het gele olifantje 


Parallel aan Googles eigen implementaties van deze concepten werkte onder meer Doug Cutting aan opensourcevarianten van al dit moois. De bedenker van Lucene en Nutch had immers ook behoefte aan een schaalbaar, gedistribueerd filesysteem. Zo ontstond, in de schoot van Yahoo! maar onder de vlag van de Apache Software Foundation, Hadoop: een Java-gebaseerde opensourcekloon van GFS en Map/Reduce. Ook BigTable kreeg een Apache-variant, HBase genaamd. Het verhaal wil dat Hadoop zijn naam en logo ontleent aan de gele olifantenknuffel van Cuttings zoontje.


Voor de datarepositorytoepassing van Outerthought, Lily genaamd, maken wij gebruik van Hadoop en HBase, net zoals klassieke repository’s vaak gebaseerd zijn op relationele databases. HBase biedt ons echter een mate van schaalbaarheid, robuustheid en interactiviteit waarvan we vroeger alleen maar konden dromen. 


Om de geschiedschrijving helemaal rond te maken is het niet onbelangrijk de rol van Amazon in dit alles te vermelden. Onder leiding van de Nederlander Werner Vogels vulgariseerde Amazon – in de vorm van de Dynamo-researchpaper4 – een andere manier van denken rond dataconsistentie en transactionaliteit in gedistribueerde systemen. Dynamo, Map/Reduce en BigTable zijn dan ook verplichte kost voor ieder ICT-curriculum die naam waardig: het zijn de papers die aan de basis liggen van de hele bigdata- en NoSQL-beweging.


We weten allemaal dat de ICT-sector onderhevig is aan cyclische evolutie. Het is dan ook niet zo gek dat de mainframe- en hiërarchische-databasejongens uit de vroege jaren tachtig in die hele bigdatabeweging een retour à l’ancienne bespeuren. Het grote verschil – en dat verliezen zij soms uit het oog in het vuur van hun betoog – is echter de vrije beschikbaarheid van al deze nieuwe technologie in de vorm van opensourceprojecten, plus daarnaast natuurlijk het contextuele gegeven van de data-economie; data is nog nooit zo eenvoudig toegankelijk geweest en de valorisatiemogelijkheden annex datacentrische businessmodellen zijn legio. Die magische combinatie van beschikbaarheid van data én toepassingen creëert momenteel een investerings- en ondernemingsklimaat dat doet denken aan de internetbubbel van een tiental jaar geleden.


Niet-relationele databases


Niet iedereen heeft de behoefte om terabytes en meer aan data op te slaan en te verwerken. Het nieuwe denken rond data betekent evengoed dat applicatieontwikkelaars het klassieke relationele model als one size fits all voor datapersistentie in twijfel durven trekken.


In de afgelopen twee, drie jaar is dan ook een legioen aan alternatieve databases ontstaan, vaak met alternatieve datamodellen en een primaire focus op schaalbaarheid en robuustheid. Vaak laten deze databases enkel query’s toe via primaire sleutels en ondersteunen ze geen ad-hocquerytaal zoals relationele databases met SQL. 


Sommige nieuwe databases laten gegarandeerde dataconsistentie bij updates vallen in ruil voor enorme schrijfsnelheden, andere bieden op het niveau van datamodel een variabel aantal kolommen aan per rij. Weer andere databases slaan geen tabulaire informatie meer op, maar arbitrair gestructureerde documentbomen of al dan niet complexe key-valueparen. De onderliggende programmeertaal van deze databases varieert dan weer van Java (dat via bigdatatoepassingen aan een heuse heropleving toe is als lingua franca voor infrastructuur­software), over Erlang en C++ tot OCaml. Deze databases worden momenteel onder de noemer ‘NoSQL’ gegroepeerd. ‘Big data’ en ‘NoSQL’ rollen vaak samen over de tong, maar hoeven niet per se samen gebruikt te worden. Ze hebben eigenlijk ook niet zo heel veel met elkaar te maken.


Veel van deze databases bezitten inderdaad een gedistribueerde (of eerder: distribueerbare) architectuur en kunnen dus ook gebruikt worden voor grote datasets. Het verdient echter de aanbeveling om dergelijke claims zorgvuldig te controleren. Zeker wanneer het (soms immateriële) dataschema gewijzigd wordt, wanneer fysieke opslagnodes toegevoegd moeten worden, enzovoort.


Hoewel in de gemeenschap van databaseanalisten al enkele pogingen ondernomen zijn om deze NoSQL-systemen onder te verdelen in verschillende systeemtypes, kies ik er hier voor om een dergelijke classificatie niet verder te behandelen. NoSQL-databases zouden de applicatieontwikkelaar ertoe moeten aanzetten om zelf het nodige denkwerk te verrichten over dataopslag en -verwerking. En als één ding duidelijk is, dan is het wel dat de NoSQL-databasesystemen géén one size fits all zijn.


Bij de bouw van ons dataplatform­product Lily opteerde Outerthought voor Apache HBase. Hieraan lagen vrij specifieke noden ten grondslag rond automatische schaalbaarheid, automatische updates en consistentie, maar ook het datamodel (BigTable) en robuustheid. U zult mij hier echter niet horen zeggen dat voor andere toepassingen Apache Cassandra, MongoDB, neo4j of 
CouchBase geen geschikte kandidaten zijn.


Tot slot


Big data en NoSQL zorgen ervoor dat de applicatieontwikkelaars zichzelf weer de juiste vragen moeten stellen: hoe ga ik om met opslag en verwerking van gegevens in mijn applicatie, zeker wanneer mijn dataset groter wordt dan de grootste server die het budget toelaat?


Op zich is dat goed nieuws. Al te vaak leidt een gebrek aan vooraf denken over dergelijke – moeilijke – problemen ertoe dat men kiest voor de veilige thuishaven van de relationele database – en daar achteraf ook de dure rekening voor gepresenteerd krijgt. Nu ook softwaregiganten als EMC en IBM voor bigdataplatformen beginnen te kiezen, wordt vanuit de markt bevestigd dat het tijdperk van databasepluriculturaliteit eindelijk aangebroken is. Doe vooral uw huiswerk, maar doe er uiteindelijk ook uw voordeel mee.

Steven Noels

Voetnoten

1. http://labs.google.com/papers/gfs.html

2. http://labs.google.com/papers/mapreduce.html

3. http://labs.google.com/papers/bigtable.html

4. www.allthingsdistributed.com/files/amazon-
dynamo-sosp2007.pdf



Steven Noels is zaakvoerder van Outerthought, een Belgisch softwarebedrijf en bouwer van Lily, een platform voor large-scale content- en data-applicaties (stevenn@outerthought.org).