Afgelopen tijd zijn verschillende grote websites overgestapt van traditionele databases op SQL-basis naar zogeheten NoSQL-databases. Bekende voorbeelden zijn: digg, Twitter (beiden van MySQL naar Cassandra) LinkedIn (van Oracle en MySQL naar Voldemort), Craigslist (van MySQL naar MongoDB) en natuurlijk Facebook (van MySQL naar HBase).
Bij nadere beschouwing van dit overstapgeweld naar de nieuwe, veelbelovende database-soort blijkt dat er eigenlijk geen sprake is van simpelweg vervanging van regulier SQL door NoSQL. Dergelijke echt grote websites hebben namelijk nooit een eenvoudige, homogene architectuur. Vaak gebruiken zij al verschillende soorten databasesystemen en caching-lagen. Tijd dus om dergelijke hybride architecturen eens nader te bekijken.
Hybride systemen
De inzet van verschillende soorten databasesystemen is op zichzelf niets nieuws, en ook zeker niet beperkt tot alleen grote websites. Voor veel bedrijven geldt dat zij al sinds jaar en dag voor specifieke doeleinden ook een specifiek (relationeel) databaseplatform inzetten.
Dus bijvoorbeeld een geavanceerd general-purpose RDBMS (relational database management system) als Oracle voor bedrijfskritische gegevens, een meer recht-toe-recht-aan RDBMS als MySQL voor websites, en een gespecialiseerd analytisch databasesysteem (ADBMS) zoals Sybase IQ voor datawarehousing. Omdat deze systemen deels dezelfde gegevens beheren, is een gecontroleerde uitwisseling van gegevens vereist. Dit geheel vormt dus een hybride oplossing.
Diversiteit in databases
De laatste jaren laten een toename zien in de diversiteit binnen het database-landschap. Met name uit de wereld van de grote websites komen er steeds vaker berichten over de inzet van 'NoSQL'-databasesystemen. De NoSQL-databasesystemen kennen een aantal gemeenschappelijke kenmerken: in het algemeen gaat het om niet-relationele gedistribueerde databasesystemen, die ontworpen zijn met een nadruk op schaalbaarheid en hoge beschikbaarheid. Dit staat haaks op de meer traditionele databasesystemen; die leggen vooral de nadruk op gegevensconsistentie.
NoSQL-databases zijn meestal 'schemaloos': ze stellen in het algemeen weinig eisen aan de organisatie en structuur (metadata) van de gegevens. Ook dit staat haaks op de opzet van relationele databasesystemen: die vereisen juist dat alle gegevensverzamelingen netjes in de vorm van tabellen worden opgeslagen.
Verder bieden de meeste NoSQL-systemen alleen tamelijk basale (en daardoor simpele) API's (application program interfaces) om direct vanuit toepassingsprogramma’s gegevens te bewerken en op te vragen. Er zijn enkele NoSQL-systemen die toch een query-taal bieden, maar deze is dan aanzienlijk minder geavanceerd dan SQL, de de-facto query-taal voor relationele databasesystemen.
Deze grote verschillen zorgen ervoor dat de twee soorten databases geheel andere functies vervullen. En dus ook goed samengaan. Om te begrijpen op welke wijze de NoSQL-systemen samen met traditionele databases worden ingezet, is het goed om naar een aantal voorbeelden te kijken.
Twee voorbeelden
Voorbeeld #1: Linkedin is begonnen met één centrale database, en daarbij een in-memory “social graph”, blogt Jay Kreps (principal engineer & engineering manager bij Linkedin). De ontwikkelaars bij dat sociale netwerk hebben die database in de loop van de tijd vanwege groei moeten opsplitsen. Als belangrijkste reden daarvoor noemt Kreps de schaalbaarheid van de grote hoeveelheden schrijfacties. Die enorme aantallen schrijfacties zijn vereist om bijvoorbeeld te tonen wie een profiel bezocht heeft. Inmiddels heeft Linkedin hiertoe zijn eigen NoSQL-oplossing ontworpen: Project Voldemort.
In een meer uitgebreid artikel op het blog van Linkedin's SNA (search, network & analytics team) valt te lezen hoe het sociale netwerk nog steeds gebruik maakt van traditionele databases voor een deel van diens services. Tegelijkertijd wordt met behulp van Hadoop (een platform voor zoekopdrachten en analyse van grote hoeveelheden semi-gestructureerde data) informatie uit deze databases geëxtraheerd om er analyses op te doen (zoals bezoekers van profielen). De resultaten van die analyses komen vervolgens via Voldemort beschikbaar voor de eigenlijke webservices.
De vraag rijst waarom Linkedin er nog steeds een verzameling traditionele databases op na houdt. Dit wordt niet met zoveel woorden in het SNA-blog genoemd, maar het is opvallend dat de data die in Voldemort wordt opgeslagen afgeleide data is. Mocht er iets mis gaan in Hadoop of Voldemort, dan kan die informatie in principe weer gerecreëerd worden. Kennelijk is Voldemort (nog) niet het soort systeem dat betrouwbaar genoeg geacht wordt voor de permanente opslag van de basisgegevens. Het is in elk geval niet met dat doeleinde ontworpen. Al met al lijkt het wel waarschijnlijk dat juist de hybride oplossing optimaal is voor Linkedin's behoeften.
Voorbeeld #2: Twitter is begonnen als een site die voor bijna alle back-end storage doeleinden het open source MySQL gebruikte, en daarbovenop memcached ter verbetering van de responsetijden. In februari 2010 verscheen er een interview met Ryan King (teamleider Cassandra activiteiten bij Twitter) waarin gewag werd gemaakt van een migratietraject van MySQL naar de NoSQL-database Cassandra.
Daarbij was het aanvankelijk de bedoeling om alle MySQL gebaseerde systemen door Cassandra te vervangen. Dat moest één systeem opleveren dat minder arbeidsintensief in het beheer is, en dat tevens de beschikbaarheid en schaalbaarheid voor met name schrijfacties vergroot. Het interview suggereert dat er bijvoorbeeld al een begin gemaakt was met het migreren van de statussen (tweets en retweets) en dat Cassandra in een later stadium ook voor andere projecten dienst zou doen.
In juli 2010 verscheen er een bericht dat Cassandra inmiddels succesvol is ingezet door het geo-team voor de opslag van plaatsgebonden gegevens. Het wordt ook gebruikt voor het opslaan van analyseresultaten, van waaruit Twitter-features zoals @toptweets en locale trending worden gevoed. Maar uit dat bericht bleek ook dat het oorspronkelijke plan om de tweets in Cassandra op te slaan voorlopig op de lange baan is geschoven. Helaas zijn er maar weinig details bekend over waarom Twitter zijn koers in deze gewijzigd heeft. Maar het moge duidelijk zijn dat het eindresultaat is dat Twitter voorlopig op een hybride MySQL/Cassandra-architectuur draait.
Schaalbaarheid een probleem
Er zijn nog meer voorbeelden te vinden van dergelijke hybride architecturen. Bijvoorbeeld Facebook heeft voor zijn nieuwe messaging-systeem gekozen voor Hbase (eveneens onderdeel van het eerder genoemde Hadoop), maar ook dat is geen volledige overstap. Centrale gegevens zoals gebruikersprofielen worden nog steeds met behulp van een groot aantal MySQL-databases onderhouden.
Ondanks dat het bij al deze voorbeelden om functioneel heel verschillende toepassingen gaat, is er toch een verbindend thema: de schaalbaarheid van met name de schrijfoperaties. Met name voor MySQL-replicatieclusters, waarbij gegevens van één enkele masterdatabase automatisch naar meerdere slaves worden gekopieerd, is die schaalbaarheid een probleem. Bij toename van het aantal verzoeken kan de master namelijk overvoerd raken.
Bij een site als Linkedin zou dat in het gunstigste geval betekenen dat bepaalde functionaliteit, zoals het aanmaken van nieuwe connecties, verminderd beschikbaar is. Voor een site als Twitter zal zo'n overbelasting van de masterdatabase grotere gevolgen hebben voor de gebruikers. Op zo'n moment is namelijk de kernfunctie, het posten van berichten, niet beschikbaar.
Aanvullende functie
Een tweede overeenkomst tussen de genoemde voorbeelden is dat de NoSQL-oplossing voorlopig ingezet wordt voor het opslaan en beschikbaar maken van analytische gegevens, die afgeleid worden uit de basisdata. Kennelijk is dit voldoende om – althans voorlopig – de minimaal noodzakelijke schrijfcapaciteit te behouden.
De NoSQL-oplossingen zijn nog jong, en het is zeer de vraag of zij in de toekomst de traditionele RDBMS-systemen zullen vervangen, of dat juist de hybride oplossingen blijven voortbestaan. Wel lijkt het erop dat NoSQL-databases in ieder geval voor de grote internetsites een noodzakelijke aanvulling zijn, tenminste, als die sites willen doorgroeien. De kans is dan ook groot dat de nabije toekomst meer van zulke hybride oplossingen te zien zal geven.