NoSQL-stukjes completeren de puzzel

Wanneer je afgelopen drie jaar iets met IT te maken hebt gehad, heb je ongetwijfeld gehoord van "de cloud" en "NoSQL".

In 2007 publiceerde Amazon een whitepaper over Dynamo. Dit document verhaalde over hoe Dynamo, een verzameling technieken die te maken hadden met fouttolerantie, ervoor zorgden dat issues met online winkelmandjes opgelost konden worden.

Toen ik in 2008 deel uitmaakte van het Software Infrastructure team van Netflix, kregen we te horen dat we vanwege het "CAP-theorema" we ons datacenter moesten verlaten om voor cloud computing te kiezen. Huh?

Een maand later dachten we na over onze Oracle-database. Hoe gingen we die in 's hemelsnaam naar de cloud verplaatsen? Toen kregen we te horen dat we ons complete RDBMS ook vaarwel moesten zeggen. We zouden overstappen op "AP"-geoptimaliseerde systemen. "AP's" (lees: systemen met een hoge beschikbaarheid) waren cruciaal voor Netflix tussen 2008 en 2010 omdat het de video streaming business betrad. Televisie moest altijd beschikbaar zijn, downtime was niet langer toegestaan.

Even doorspoelen naar 2011: de afgelopen drie jaar waren een fantastisch avontuur. Ik heb Netflix met twee migraties geholpen in 2010: de eerste was van Netflix' datacenter naar de Amazon Web Services cloud, de tweede was van Oracle naar SimpleDB. 2011 was niet minder spannend: we gingen van SimpleDB naar Cassandra, waarna Netflix ook in Groot-Brittannië en Ierland is gaan opereren. Aangezien Cassandra alle routing laat configureren, kan een cluster worden verspreid over meerdere continenten.

Even doorspoelen naar vandaag: Ik ben nu een maand werkzaam voor LinkedIn. Afgelopen maand heb ik geprobeerd me vertrouwd te maken met de verschillende NoSQL-systemen die LinkedIn in-house gebouwd heeft. Hiertoe behoren onder andere Voldemort (ook een Dynamo-gebaseerd systeem), Krati (single-machine dataopslag) en Espresso (een hagelnieuw systeem wat LinkedIn in gebruik neemt). LinkedIn staat nu voor dezelfde veranderingen die drie jaar geleden bij Netflix doorgevoerd werden. Traffic groeit en zowel Oracle als het eigen datacenter zijn binnenkort wellicht verleden tijd. Lossen NoSQL en cloud computing alles op?

De huidige staat van NoSQL

Je kunt tegenwoordig goed voor NoSQL kiezen, aangezien er behoorlijk wat alternatieven voorhanden zijn. Sommige worden ondersteund door startups (bijvoorbeeld Cassandra, Riak, MongoDB, etc.), sommige indirect door bedrijven (Voldemort door LinkedIn en HBase door Facebook en StumbleUpon) en sommige direct door bedrijven (AWS' S3, SimpleDB, DynamoDB, etc.).

Wanneer je een besluit neemt over implementatie van NoSQL, houd dan rekening met het volgende:

• Ieder systeem dat je kiest vereist 24/7 operationele ondersteuning. Als het niet wordt gehost (zoals bijvoorbeeld bij AWS), dan heb je een vloot ondersteunend personeel nodig. Als je daar niet de mensen voor hebt, raad ik aan om het bij AWS' DynamoDB te houden.
• Een bedrijf dat eerst alles deed met een grote machine van Oracle, moet er rekening mee gehouden dat een vergelijkbare NoSQL-optie resulteert in 36 kleinere machines.
• Houd rekeningen met de beperkingen bij de gekozen oplossing:
- MongoDB kampt op moment van schrijven met een write-blokkade. Wil je heel veel tegelijkertijd naar de database schrijven, kies dan iets anders.
- Cassandra (dat te vergelijken is met andere Dynamo-systemen) schaalt niet goed op voor bepaalde secundaire indices,
- Cassandra heeft veel instellingen en een enorme hoeveelheid interne processen. Zorg ervoor dat je het een en ander uitschakelt in de productiefase om voor consistente prestaties te zorgen.

Veel van de NoSQL-leveranciers vergelijken de "strijd tussen NoSQL's" met de RDBMS-strijd die in de jaren '80 woedde: een strijd waarin de winnaar direct alles wint. Maar in de wereld van NoSQL is dit absoluut niet het geval. Gedistribueerde systemen draaien juist om compromissen.

Ieder NoSQL-systeem kent een eigen specialiteit

Een gedistribueerd systeem kiest specifieke ontwerpelementen om op bepaalde onderdelen goed te presteren. Die ontwerpelementen bepalen het DNA van het systeem. Het resultaat is dat het systeem niet op alle vlakken goed presteert. In een poging om meer marktaandeel te winnen, hebben sommige NoSQL-leveranciers features toegevoegd die, kijkend naar het DNA van het systeem, onlogisch zijn.

Ik zal met een voorbeeld komen. Systemen die data versplinteren op basis van een primaire sleutel, doen dit goed wanneer gerouteerd wordt via deze sleutel. Wanneer routering plaatsvindt op basis van een secundaire sleutel, moet het systeem dit 'uitspreiden' over meerdere splinters (shards). Als een van die shards een hoge vertraging (latency) kent, zal het systeem geen of incomplete resultaten tonen. Om deze reden is het logisch om de secundaire index op een unsharded (maar gerepliceerd) systeem te plaatsen. Dit concept wordt toegepast bij Netflix. Secundaire indices worden daar opgeslagen in Lucene en verwijzen naar data in Cassandra.

LinkedIn doet hetzelfde bij het ontwerp in het nieuwe systeem Espresso. Secundaire indices worden geserveerd vanaf Lucene. De secundaire index verwijst naar de primaire opslag.

Dit brengt me tot een andere observatie. Toen ik laatst de broncode van Voldemort reviewde, was ik onder de indruk van de helderheid en kwaliteit van de code. In core systemen, of ze nu gedistribueerd werken of niet, is codekwaliteit en helderheid niet altijd een gegeven. Hoewel Voldemort een open-source project is en al jaren bestaat, is het met een hoge mate van discipline onderhouden. Het is een voorbeeld van een systeem dat dichtbij zijn eigen DNA is gebleven en geen functionaliteit die er niet in thuishoort heeft toevoegd.

Daarnaast zijn ook Krati, Kafka en Zookeeper open-source projecten die gebrand zijn op heldere designprincipe en simpele commando's. Hierdoor worden het uitstekende puzzelstukjes die zich lenen voor het gedistribueerde systeem dat jij wilt bouwen. Het gevolg is dat het systeem dat we bij LinkedIn bouwen, wellicht wordt opgetuigd met gespecialiseerde componentsystemen die onafhankelijk van elkaar getuned kunnen worden. De perfecte puzzel.

Siddharth Anand is technologie/softwarearchitect bij LinkedIn's infrastructuur team. Hij heeft een eigen blog en stelt het op prijs wanneer mensen hem op twitter toevoegen./i]

[i]In hoeverre experimenteert jouw organisatie met NoSQL om traditionele relationele databases te vervangen? Draait NoSQL al in productie? Laat het hieronder weten in de commentaren.