Innovatie & Strategie

Analytics

Big Data inspireert tot NOSQL

9 november 2011

Kent u het bedrijf Rapleaf? Misschien niet. Toch was het één van de belangrijkste steunpilaren van de online marketingcampagne in aanloop naar de vorige Amerikaanse presidentsverkiezingen. Want alleen Rapleaf kon aan 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 hiervoor niks illegaals: het baseert zich puur op datasporen die we allemaal achterlaten op het 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 niks nieuws of origineels aan. Maar daarnaast stuurt het bedrijf ook webcrawlers het internet op om dit anonieme, op surfgedrag gebaseerde profiel te verrijken met publiek bekende persoonlijke informatie. Gegevens uit uw Facebook-profiel bijvoorbeeld, een Flickr-account, enz.

Rapleaf wist op die manier tijdens de vorige Amerikaanse presidentsverkiezingen of iemand Republikein dan wel Democraat was, door slimme segmentatie aan de hand van dit verrijkte profiel. Meer nog, Rapleaf weet of u hetero dan wel homo bent, kent uw leeftijd met een afwijking van nauwelijks drie tot vijf jaar, weet of u houdt van tuinieren danwel van astrologie. Rapleaf weet alles, soms tot en met uw echte naam en e-mailadres - de holy grail voor de gemiddelde online reclamejongen. Dus als u zich ooit afvraagt hoe het komt dat die contextafhankelijke banneradvertenties zo akelig accuraat zijn, dan weet u bij deze het antwoord: Rapleaf.

Honderden terabytes per dag

Het spreekt voor zich dat even uw surfgedrag bijhouden of even het internet opgaan met een webcrawler eenvoudiger klinkt dan het eigenlijk is. Zo’n activiteit genereert immers een waanzinnige hoeveelheid data, vaak vele honderden megabytes tot terabytes per dag. En dan is Rapleaf nog een kleinere speler, in vergelijking met de écht grote databoeren van het internet als Google, Yahoo!, Facebook, Twitter, Amazon enz. Bij die grote spelers 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 een aantal dollar per profiel. Correcte, robuuste en schaalbare dataopslag en -verwerking is voor hen dan ook een zaak van leven of dood. Laat ik u hierover één verrassing alvast niet onthouden: ze maken voor de opslag en verwerking van die data géén gebruik van 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’. Immers, het werd hen al snel duidelijk dat de toen geldende state of the art - de klassieke enterprise relationele database - niet zou volstaan om te schalen naar de volumes van dataopslag en -gebruik waarmee ze nu geconfronteerd worden.

Aspecten van schaalbaarheid

Bij het uittekenen van een enterprise-architectuur worden de zogenaamde niet-functionele requirements al snel op een 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 beperkt data- en gebruiksvolume zijn dit relatief courante systeemeigenschappen. Moeilijker wordt het echter als de hoeveelheid data (of gebruikers) zo groot wordt dat één fysieke server niet meer volstaat.

Het garanderen van die consistentievereiste bijvoorbeeld, de zogenaamde ACID-garantie (Atomicity, Consistency, Isolation en Durability) van een relationele database, is immers slechts eenvoudig (en dan nog) bij een single-node server. Het locken van een databaserecord bij een schrijfoperatie – om te vermijden dat twee processen op dezelfde plaats gelijktijdig data proberen weg te schrijven – in een multi-node gedistribueerde architectuur, wordt al snel een heel stuk complexer. Zeker als men daarbij wil vermijden een centrale lockingservice te bouwen (die dan immers een centraal Single Point of Failure wordt).

Het grote voordeel van een relationele database is de link tussen het datamodel en de querytaal - SQL: het staat de gebruiker vrij om ad hoc queries te bedenken. Wanneer bepaalde queries duur of traag worden in on-the-fly berekeningstijd is het relatief eenvoudig om indexen te definiëren, die ervoor zorgen dat trage queries weer snel (kunnen) worden. Op die manier offert men echter een stuk schrijfsnelheid op om snellere lees- en zoeksnelheid te garanderen, door een stuk van de mogelijke antwoorden op toekomstige vragen vooraf te gaan berekenen en op te slaan - in een index dus. Het niet ongebruikelijk om zo in een situatie te komen dat het bijhouden van vele indexen, gecombineerd met de vereisten van de ACID-garantie voor een zware belasting van de databaseserver kunnen zorgen. Het systeem kan dan zo overbelast raken door een toevloed aan schrijfoperaties dat het lezen wederom erg traag wordt.

Rekenkracht duizenden servers

Wanneer men door het volume aan gegevens verplicht wordt om over verschillende servers te gaan schalen, is het eigenlijk vrij logisch dat men die gedistribueerde verwerkingscapaciteit ook gaat gebruiken om te parallelliseren. Google publiceerde in 2003 en 2004 een aantal research papers over zijn datacentertechnologie. Het bedrijf maakt, zoals intussen breed bekend, gebruik van grote hoeveelheden ‘commodity servers’ die het op applicatieniveau met elkaar integreerde alsof het één groot systeem was. Onderaan de applicatiestack was er het ‘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 er bovenop 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 alsof het één grote parallelle verwerkingsmachine is. 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 bovenop het gedistribueerde filesysteem. Voor interactieve applicaties bovenop GFS en Map/Reduce en het beheren van meer gestructureerde, tabulaire gegevens bedacht Google vervolgens BigTable (3), een datamanagementtoepassing die low-latency, read/write-operaties aanbiedt, en die uiteindelijk ook de ‘database’ is waar bovenop Google de eindgebruikersapplicaties implementeert (GMail, Picasa, etc).

Open source

Parallel aan Googles eigen implementaties van deze concepten werkte onder meer Doug Cutting aan open source-varianten van al dit moois. Zo ontstond, in de schoot van Yahoo! maar onder de vlag van de Apache Software Foundation, Hadoop - een Java-gebaseerde open source-kloon van GFS en Map/Reduce. Het verhaal wil dat Hadoop zijn naam en logo ontleent aan de gele olifantenknuffel van Cutting’s zoontje. Ook BigTable kreeg zijn of haar Apache-variant, HBase genaamd. HBase biedt een mate van schaalbaarheid, robuustheid en interactiviteit waarvan we vroeger alleen maar konden dromen. Om de geschiedschrijving helemaal rond te maken is het tot slot 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 Research Paper - 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 Big Data- en NOSQL-beweging.

We weten allemaal dat de ICT-sector bij uitstek onderhevig is aan cyclische evolutie en het is dan ook niet zo gek dat de mainframe- en hiërarchische-databasejongens uit de vroege jaren '80 in die hele Big Data-beweging een ‘retour à l’ancienne’ bespeuren. Maar, en dat verliezen zij soms wel uit het oog in het vuur van hun betoog, hét grote verschil is de vrije beschikbaarheid van al deze nieuwe technologie in de vorm van opensourceprojecten, Daar komt natuurlijk ook het contextuele gegeven van de dataeconomie bij: data is nog nooit zo eenvoudig toegankelijk geweest en de mogelijkheden daar waarde mee te creëren 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 ter discussie durven te stellen als ‘one-size-fits-all’ voor datapersistentie. In de voorbije 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 queries via primaire sleutels toe en ondersteunen ze geen ad hoc querytaal zoals relationele databases met SQL. Sommige nieuwe databases laten gegarandeerde dataconsistentie bij updates vallen in ruil voor enorme schrijfsnelheden. Andere databases bieden op het niveau van het datamodel een variabel aantal kolommen aan per rij. Nog anderen 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 (die via Big Data-toepassingen aan een heuse heropleving toe is als lingua franca voor infrastructuursoftware), via Erlang en C++ tot OCaml. Deze databases worden momenteel onder de noemer NOSQL gegroepeerd. Big Data en NOSQL rollen dan ook vaak samen over de tong, maar hoeven niet per se samen gebruikt te worden en hebben op zich eigenlijk ook niet zo heel erg veel met elkaar te maken.

Vele van deze alternatieven bezitten inderdaad een gedistribueerde (of eerder: distribueerbare) architectuur en kunnen dus ook gebruikt worden voor grote datasets. Het verdient echter aanbeveling om dergelijke claims altijd zorgvuldig te controleren, zeker in scenario’s wanneer het (soms immateriële) dataschema gewijzigd wordt, wanneer fysieke opslagnodes toegevoegd moeten worden enz.

Big Data en NOSQL zorgen er voor 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, want al te vaak zorgt een gebrek aan vooraf denken over dergelijke - moeilijke - problemen ervoor dat men al gauw voor de bekende, veilige thuishaven van de relationele database kiest - en daar achteraf ook de dure rekening voor gepresenteerd krijgt. En aangezien nu ook softwaregiganten als EMC en IBM voor Big Data-platformen beginnen te kiezen, wordt ook vanuit de markt bevestigd dat het tijdperk van de database-pluriculturaliteit eindelijk aangebroken is. Doe vooral uw huiswerk, maar doe er uiteindelijk ook uw voordeel mee.

 
Lees het hele artikel
Je kunt dit artikel lezen nadat je bent ingelogd. Ben je nieuw bij AG Connect, registreer je dan gratis!

Registreren

  • Direct toegang tot AGConnect.nl
  • Dagelijks een AGConnect nieuwsbrief
  • 30 dagen onbeperkte toegang tot AGConnect.nl

Ben je abonnee, maar heb je nog geen account? Neem contact met ons op!