NoSQL: meer dan vergaarbak voor Big Data

ObamaCare is een verrassende referentie voor wie zich de IT-problemen bij de introductie van dit Amerikaanse gezondheidszorgsysteem nog herinnert. Maar bij MarkLogic is men er trots op dat een dermate ingewikkeld project met zijn NoSQL-database gerealiseerd is. En het illustreert treffend dat met NoSQL meer kan dan Big Data verzamelen.

MarkLogic ontwikkelt en verkoopt onder de bedrijfsnaam een zogeheten NoSQL-database. Althans, zo noemen we dat tegenwoordig. Toen het Amerikaanse bedrijf zijn database ontwikkelde, heette deze nog een XML-­database. Dat was in 2001, toen de hoofdontwerper Christopher Lindblad van de inmiddels in vergetelheid geraakte zoekmachine UltraSeek – van Infoseek – besloot zijn eigen weg te gaan. Die weg was de ontwikkeling van een database met ingebouwde zoekmachine die de tekortkomingen van bestaande zoek- en databaseproducten moest verhelpen. Op de achtergrond speelde daarbij de gedachte dat met betere IT-hulpmiddelen de aanslagen van 11 september 2001 op het World Trade Center in New York en op het ­Pentagon voorkomen hadden kunnen worden, zegt directeur Jurriaan Krielaart van MarkLogic Nederland.

Het resultaat van die ontwikkelinspanningen was een database waarin de data in XML-vorm werden opgeslagen en waarbij het datamodel – anders dan bij de relationele database – niet vooraf gedefinieerd hoefde te worden; het datamodel werd door de ingebouwde zoekmachine automatisch gegenereerd. Daardoor kon de database ook goed overweg met ongestructureerde data.

Nieuwere versies van MarkLogic kunnen behalve met XML overweg met in JSON vastgelegde gegevens, terwijl via ondersteuning van XSLT (Extensible Stylesheet Language Transformations) ook bijvoorbeeld ­tabellen uit relationele databases en gegevens uit geografische informatiesystemen binnen het bereik van MarkLogic zijn gebracht. In versie 8 is daarnaast ondersteuning van JavaScript geïntroduceerd; dat moet de afhankelijkheid van de relatief schaarse experts in XQuery verminderen, de programmeer- en zoektaal die tot versie 8 als enige beschikbaar was bij MarkLogic.

MarkLogic is wel een vreemde eend in de bijt met NoSQL-producten in die zin, dat het claimt de enige leverancier van een NoSQL-oplossing te zijn die ook inzetbaar is in bedrijfskritische toepassingen. Cruciaal element daarbij is dat de MarkLogic-database over ACID-eigenschappen beschikt. Die ACID-eigenschappen zijn belangrijk omdat ze garanderen dat een database gegevens op betrouwbare wijze verwerkt, wat voor ­bedrijfstoepassingen vaak een ‘sine qua non’ is. De inzetbaarheid voor bedrijfskritische toepassingen wordt in MarkLogic verder ondersteund met hoge beschikbaarheid, onder andere doordat de database gebaseerd is op een ‘shared nothing’-architectuur waardoor er geen ‘single points of failure’ zijn. MarkLogic maakt ook incrementele back-ups mogelijk en ondersteunt het geautomatiseerd overnemen van processen die draaien op hardware waar een storing ontstaat. Disaster recovery wordt eveneens vergemakkelijkt in de vorm van ondersteuning van volledige datareplicatie voor snel herstel bij een crash. Tevens biedt de database beveiliging tot op het laagste niveau. Deze faciliteiten zijn standaard aanwezig, en hoeven dus niet door de ontwikkelaars ingebouwd te worden.

 

Obamacare

Het project waar MarkLogic het meest prominent mee in beeld kwam, was meteen ook een omstreden project: ObamaCare. Wie het nieuws gevolgd heeft zal zich herinneren, dat de introductie van de officieel Healthcare.gov geheten dienst nu niet bepaald vlekkeloos tot stand kwam. Het ontwikkelproject verliep moeizaam. En de site kwam vrijwel direct na livegang, oktober 2013, piepend en krakend tot stilstand. Het kostte daarna nog de nodige hoofdbrekens om die werkend te krijgen op een acceptabel niveau. Die problemen werden op zich echter niet veroorzaakt door de keus voor MarkLogic, constateerden analisten achteraf. Die keuze leverde in zoverre wel problemen op dat systeemontwikkelaar CGI niet erg vertrouwd was met deze techniek, en daardoor in eerste instantie codegeneratietools inzette die voor een NoSQL-omgeving niet echt geschikt waren. Maar dat zegt natuurlijk niets over de kwaliteiten van de software. Na verandering van aanpak behoorden de projectproblemen snel tot het verleden. Ook de performanceproblemen bij introductie bleken bij nadere inspectie niet te wijten aan de software, maar aan gebreken in het platform waarop het systeem ­draaide.

In dat licht wordt het een stuk begrijpelijker waarom men bij Mark­Logic zo trots is op dit project. Het systeem krijgt dag in, dag uit zo’n 35.000 gelijktijdige sessies voor de kiezen, met pieken rond de 85.000. Daarbij verwerkt de database 170.000 transacties per minuut. Die transacties zijn bovendien behoorlijk ingewikkeld. Het systeem verwerkt de registratie en de claims van zo’n 8 miljoen Amerikanen uit verschillende staten, en moet daarbij rekening houden met de verschillen in belastingheffing en wetgeving tussen die staten en met het feit dat binnen de afzonderlijke staten verschillende verzekeraars actief kunnen zijn met ieder weer afwijkende voorwaarden. Hoewel ze dat zelf niet zeggen, zal het bij de MarkLogic-medewerkers ongetwijfeld ook enig leedvermaak oproepen dat bouw van de Healthcare.gov-site in Oregon – in één staat dus – op basis van Oracles database zodanig ­mislukte dat de partijen nu in de rechtszaal staan.

 

Olympische prestaties

Healthcare.gov is niet het enige grote project waar MarkLogic op kan bogen. Dat de XML-database grote volumes aankan blijkt bijvoorbeeld ook uit de inzet door de BBC tijdens de Olympische Spelen van 2012. De BBC gebruikte MarkLogic destijds voor het beheren van de verschillende informatiebronnen die het via zijn website beschikbaar maakte. ­Tijdens de Spelen hielp MarkLogic 106 miljoen verzoeken voor videofragmenten te verwerken, op de drukste dag 2,8 petabytes aan informatie te ontsluiten en 55 miljoen browsersessies te ondersteunen.

In Nederland heeft MarkLogic nu een dozijn klanten. Jammer genoeg gaf geen van deze klanten tekst en uitleg over zijn gebruik van Mark­Logic op de klantendag die het onlangs organiseerde in Amsterdam. Wel werden er twee pilots gepresenteerd. Een daarvan was van Boskalis, dat met MarkLogic een systeem heeft ontwikkeld om snel vast te stellen waar bepaalde expertise in zijn organisatie te vinden is. Dat is een taak die wat ingewikkelder is dan op het eerste gezicht lijkt: de werknemers van het bedrijf werken veelal op afgelegen locaties en wisselen ook ­regelmatig van plek. In een vervolgpilot gaat Boskalis kijken of het met MarkLogic het onderhoud aan zijn schepen kan optimaliseren en noodreparaties kan voorkomen door meer informatie over de schepen te ­verzamelen.

Bij de politie is een proefsysteem ontwikkeld om de 112-meldkamer te ondersteunen. De uitdaging die men zich daarbij stelde was om informatie uit sociale media, zoals Twitter, beschikbaar en bruikbaar te ­maken om in de eerste 5 tot 10 minuten na melding van een incident zoveel mogelijk informatie te verzamelen van mogelijke getuigen. Dat vraagt om bijvoorbeeld het identificeren van tweets die betrekking hebben op een gemeld incident, en het automatisch in de gaten houden of de opsteller van zo’n tweet nog meer informatie via Twitter verspreidt. Medewerkers van de meldkamer kunnen dat met het pilotsysteem zelf doen, zonder interventie van data-analisten. Dat beviel zo goed dat men nu op zoek is naar budget om het systeem verder te ontwikkelen.

 

De uitdaging van open source

De stap naar daadwerkelijke implementatie is best nog wel een horde, blijkt uit deze voorbeelden. Binnen de NoSQL-wereld is MarkLogic een relatief onbekende speler. Namen als Cassandra, MongoDB, ­DynamoDB en SimpleDB van Amazon, Big Data van Google en CouchDB trekken meer aandacht. Dat heeft volgens Krielaart alles te maken met het feit dat MarkLogic – anders dan de concurrenten – niet open source is. “Open source is natuurlijk een pre bij adoptie. Dat je kosteloos kunt starten, trekt ontwikkelaars aan. Van MarkLogic is alleen een proeflicentie voor ontwikkelaars gratis. Als je een project wilt uitrollen, zul je wel een licentie moeten aanschaffen. Dat betekent dat je de IT-afdeling en Procurement erbij moet betrekken, vandaar dat ­ontwikkelaars liever met open source werken.”

Ook systemintegrators en adviesbedrijven hebben vaak een voorkeur voor open source omdat dat in de regel meer werk oplevert, stelt Krielaart. Bovendien is adoptie van NoSQL-technieken niet altijd in hun belang omdat werken met een relationele database ook vaak meer werk oplevert. “Je bespaart met NoSQL enorm op de ontwikkeltijd. In MarkLogic sla je data op zoals ze uit de bron komen. Een factuur sla je bijvoorbeeld op met alle elementen die daar onderdel van uitmaken bij elkaar. Je maakt daarvan niet eerst, zoals bij SQL, een genormaliseerd datamodel waarbij je de data via Extraction, Transformation en Load-technieken verdeelt over verschillende tabellen om doublures in de database te voorkomen. Dat kost bij een doorsnee project maanden aan tijd. En bij de verwerking van gegevens betaal je daar overigens weer een prijs voor; de joins die nodig zijn om de gegevens te verzamelen uit de tabellen waarover je ze uitgesplitst hebt, vragen veel verwerkingscapaciteit. Voor system integrators en consultants is het geen pre als ze projecten met veel minder mensen kunnen uitvoeren dan ze in huis hebben.”

Krielaarts woorden maken duidelijk dat MarkLogic zijn speelveld anders definieert dan de leveranciers van NoSQL-databases in de regel doen. NoSQL wordt gewoonlijk gepositioneerd als Big Data-tool, voor opslag en analyse van voornamelijk ongestructureerde data die overschieten bij bedrijfstoepassingen of gedestilleerd worden uit sociale ­media. MarkLogic zoekt ook, en misschien wel eerder een rol in toepassingen met een duidelijke component transactieverwerking, waar een investering in robuustheid en hoge beschikbaarheid eerder te rechtvaardigen valt dan bij analytische toepassingen. Daarmee positioneert MarkLogic zich als aanvulling op, en in veel toepassingen ook vervanger van SQL-databases.

Met die positionering timmert MarkLogic wel degelijk aan de weg. Het heeft wereldwijd meer dan 300 klanten. De jaaromzet ligt momenteel op een niveau van ruim 100 miljoen dollar. Eind mei wist MarkLogic een investering van 102 miljoen dollar aan kapitaal aan te trekken. Die gaat het gebruiken om zijn activiteiten uit te breiden; als onderdeel daarvan zal het personeelsbestand van nu zo’n 400 man uitgebreid worden met 200 man. In Nederland heeft MarkLogic een vestiging die momenteel 12 man telt.

 

Wanneer Oracle en SQLserver niet volstaan…

De populariteit van databases als Oracle en SQL Server is in belangrijke mate te danken aan de kracht van SQL, de Structured Query Language, als tool voor het definiëren en bevragen van de relationele database. Maar in een tijd waarin grote volumes ongestructureerde data van ­belang zijn, is SQL niet langer het antwoord op alle databasekwesties. Eén van de problemen met SQL-databases is, dat ze lastig te gebruiken zijn in een gedistribueerde opzet waar het aantal te gebruiken verwerkings- en opslagsystemen snel moet kunnen meegroeien met de datatoevloed. Dat botst met de functionaliteit om integriteit, kwaliteit en beschikbaarheid van de gegevens te garanderen – waar SQL-databases juist in uitblinken en hun marktdominantie mee veroverd hebben. SQL-databases zijn ook niet de gedroomde oplossing om ongestructureerde gegevenstypes te ­incorporeren en raken makkelijk overvoerd wanneer massale hoeveelheden gegevens uit sensoren of logs van websites verwerkt moeten worden.

De voordelen van NoSQL

NoSQL wil een antwoord geven op die problemen. Dat antwoord is in vijf punten samen te vatten.

Anders dan relationele databases, waar zwaardere verwerkingslast uitbreiding van de server vraagt, kunnen NoSQL-databases goed overweg met het uitbreiden van de verwerkingscapaciteit door het snel bijschakelen van goedkope standaardservers. De hoeveelheden data die NoSQL-systemen kunnen behappen, zijn veel groter dan wat relationele databases aankunnen. NoSQL-databases vragen minder specialistische – en dus dure – beheerders dan relationele databases. NoSQL-databases werken op clusters van goedkope hardware; daardoor liggen de kosten per gigabyte dan wel per transactie per seconde factoren lager dan bij relationele databases. NoSQL-databases kennen weinig beperkingen aan het datamodel en het aanbrengen van veranderingen daarin. Daardoor zijn applicaties sneller en eenvoudiger aan te passen, wat enorm scheelt in flexibiliteit en in ontwikkeltijd en -kosten.

Niet ACID, maar BASE

Daarvoor betaalt men vaak wel een prijs. In de regel geven No­SQL-databases niet de garantie dat alle gegevens en regels op ieder willekeurig moment consistent zijn. In databaseland staat deze eigenschap bekend als ACID. Dat staat voor:

Atomair: de garantie dat een transactie geheel wordt uitgevoerd, of wordt teruggedraaid als die niet geheel uit te voeren is. Een bijboeking op één rekening kan bijvoorbeeld niet worden afgerond als de afboeking op de tegenrekening faalt. Consistent: de garantie dat na afronding van een transactie onder alle omstandigheden alle (integriteits)regels die voor de database gelden, onverkort en ongewijzigd blijven gelden. Isolated (geïsoleerd): de garantie dat transacties die tegelijkertijd worden uitge­voerd, niet door elkaar lopen en dus niet beïnvloed worden door elkaars tussen­resultaten. Duurzaam: de garantie dat de resultaten van een voltooide transactie ongewijzigd blijven, ook bij stroomverlies, ­vastlopers of fouten.

Het zijn juist deze eigenschappen die SQL-databases hun populariteit hebben bezorgd. Dat is ook niet verwonderlijk. Hun opkomst is gekoppeld aan de opkomst van financiële pakketten, magazijnsystemen en ERP-software waar de mogelijkheid van het bestaan van ­verschillende werkelijkheden in één ­systeem niet wenselijk is. In andere ­toepassingen, denk bijvoorbeeld aan senti­men­tanalyse op grote verzamelingen tweets, is dat een stuk minder problematisch. NoSQL-databases beloven voor het merendeel dan ook de ­BASE-eigenschappen te garanderen: ­Basically Available, Soft-State en Eventually Consistent. Door de keuze voor een term die in de chemie de tegenhanger van ‘zuur’ is, wordt het verschil met ACID meteen helder gemaakt; de prijs daarvoor is dat dit acroniem minder helder gedefinieerd is dan ACID. BASE geeft aan dat beschikbaarheid in oplossingen die zich met dit acroniem tooien, zwaarder weegt dan consistentie van de database. Op de achtergrond speelt daarbij het CAP-theorema van prof. Dr. Eric A Brewer een rol. In dat theorema ontvouwde Brewer eind vorige eeuw de stelling dat gedistribueerde systemen niet tegelijkertijd een 100 procent garantie van consistentie, beschikbaarheid en tolerantie voor al of niet tijdelijke problemen in partities van dat gedistribueerde systeem kunnen bieden. Men zal om die reden altijd een afweging moeten maken van wat het zwaarst moet wegen, stelt Brewer. Bij de keuze voor een NoSQL-systeem zal men deze afweging heel bewust moeten maken. Waarbij er zeker twee NoSQL-databases zijn die stellen wel ACID-eigenschappen te implementeren. Behalve MarkLogic claimt ook FoundationDB dat; deze NoSQL-database werd onlangs overgenomen door Apple.

Veel onrijpe technologie

Andere nadelen bij NoSQL kunnen zijn, dat expertise lastiger te vinden is, dat er minder tools voor beheer en integratie zullen zijn en dat het ook nog al eens kan ontbreken aan ondersteuning voor het product in bijvoorbeeld BI-oplossingen. Sommige NoSQL-producten zijn ook nogal kort op de markt, en zijn nog niet echt uitgekristalliseerd. Dat betekent dat men de doopceel van de leverancier moet lichten, wanneer men echt serieus gaat investeren in een bepaalde NoSQL-oplossing. Er zijn momenteel zo’n 150 NoSQL-databases te verkrijgen van veelal kleine leveranciers. Dat daarvan vele zullen verdwijnen, is evident. En omdat standaarden op dit terrein nog goeddeels ontbreken, kan het een hoofdpijndossier worden als men veel tijd en moeite heeft besteed aan de ontwikkeling van een NoSQL-toepassing op basis van een product dat de bocht niet haalt.

NoSQL kent soorten en maten

De technologie die onder de NoSQL-vlag vaart, bestaat uit databaseproducten die op verschillende leest geschoeid zijn. NoSQL kent verschillende opslagmechanismes. Men onderscheidt in de regel:

Documentdatabases slaan data-elementen op in documentachtige structuren; ze zijn daardoor geschikt in situaties dat men met veel dataformaten moet werken. Key-value stores koppelen unieke sleutels aan data-elementen; daarmee kan in relatief simpel gestructureerde datasets heel snel informatie boven tafel gehaald worden. Wide column stores slaan gegevens op in tabellen die buitensporig grote aantallen kolommen kunnen bevatten. Dat geeft hoge prestaties en dito schaalbaarheid bij het verwerken van grote dataset – zoals inventarisaties van zoekopdrachten of DNA-vergelijkingen. Graph databases slaan data-elementen op in graaf-achtige structuren waarmee de associaties tussen elementen bewaard blijven. Daardoor zijn ze heel geschikt voor toepassing in sociale netwerken en bijvoorbeeld ook automatisch gegenereerde aanbevelingen.

Wat de beste keus is, hangt af van de toepassing die men voor ogen heeft.

Tag

Onderwerp



Niet gevonden? Vraag het de redactie!

Heeft u het antwoord op uw vraag niet gevonden, of bent u op zoek naar specifieke informatie? Laat het ons weten! Dan zorgen we ervoor dat deze content zo snel mogelijk wordt toegevoegd, of persoonlijk aan u wordt geleverd!

Stel uw vraag