Het is databasetechniek waarvan de opkomst vooral onder ontwikkelaars met veel interesse wordt gevolgd. Ook bedrijven durven steeds vaker de sprong te maken, en de communities achter de NoSQL-beweging professionaliseren in rap tempo. Recent nog is CouchDB toegekomen aan zijn eerste commerciële versie. Andere voorbeelden zijn Cassandra en MongoDB.

Dat terwijl de techniek niet geheel nieuw is, zo zegt Roland Bouman, database-ontwikkelaar en auteur van meerdere boeken. “Maar je ziet dat ze pas nu als 'NoSQL-database' worden aangegeven. De reden daarvoor is dat ze voor veel applicaties problemen oplossen die SQL met zich meebracht.” Dat betekent alleen niet dat NoSQL geschikt is voor alle soorten applicaties.

De Zin

Zeker in de webapplicatie-sferen lost NoSQL diverse problemen op die relationele databases intrinsiek met zich meebrengen, zo zegt Bouman. “We hebben het dan over de echte webtoepassingen, zoals sociale netwerken. Mensen die in de BI (business intelligence - red.) zitten, of in banken of het verzekeringswezen, hebben het helemaal niet over Cassandra”, zegt Bouman.

Hij benadrukt dat een aantal genoemde problemen die aan relationele databases toegeschreven worden, specifiek te maken hebben met het meestgebruikte exemplaar: MySQL. Bouman heeft daar in het verleden ook mee gewerkt.

De problemen zijn volgens hem tweeledig: Slechte schaalbaarheid op recente hardware, en de omslachtigheid van de software.

“Het voordeel van bijvoorbeeld MySQL was vooral dat het ontzettend veel leesoperaties ondersteunt en scale-out replicatie biedt. Het aantal ondersteunde leesverzoeken kon je met MySQL enorm verhogen door servers bij te plaatsen.” Maar de laatste jaren staat dit voordeel onder druk, omdat de hardware anders is gaan schalen. “Servers werken nu met meerdere processors, en elke processor heeft meerdere kernen”, legt Bouman uit.

“De rekenkracht is enorm toegenomen, terwijl de kloksnelheid nagenoeg gelijk is gebleven. Een MySQL-database schaalt gebrekkig in die richting, hoewel daar wel verbetering in is te bemerken.”

Ook het type applicatie is veranderd. Bouman: “Het zijn steeds vaker webcentrische sociale netwerken die je niet kunt vergelijken met de traditionele client-serverapplicatie die je bij de Oracle DB en dat soort dingen tegenkomt. Het is een hele specifieke workload, waarbij het workloadaccent ligt op het lezen.” In de SQL-databases zorgt dat voor prestatieproblemen.

Daar zijn wel lapmiddelen voor, zegt Bouman, zoals caching en sharding. Maar die 'oplossingen achteraf' brengen weer hun eigen problemen mee.

Dan is er de SQL-taal zelf. “Het is redelijk ouderwets. Een beetje zoals COBOL ook ouderwets is, maar nog steeds de kern vormt van heel veel applicaties.” Omdat de webapplicatie-wereld steeds meer rekenwerk naar de client toeduwt, toont SQL zijn leeftijd steeds duidelijker.

“Met bijvoorbeeld Javascript worden enorm rijke client-side webapplicaties gebouwd, maar de interface tussen programmeertaal en SQL is daar eigenlijk enorm onhandig voor. In de PHP-pagina moet je bijvoorbeeld strings in elkaar timmeren om de SQL-statements bij de database af te leveren. Vervolgens komt er weer data terug van de server, dat moet je dan converteren naar een array of iets dergelijks, daar moet je weer doorheen lopen. Dat is een heel gedoe”, verzucht Bouman.

“Het manco zit vooral in de manier waarop je de data van de server terugkrijgt. Als je bijvoorbeeld bij een webwinkel klantgegevens opvraagt, wil je ook de ordergegevens enzovoorts hebben. SQL kan alleen tabellen terugsturen, waardoor je de databehoefte moet vullen met meerdere queries. Je zit met de latency die een verzoek inneemt. Dat zou niet het geval zijn geweest als SQL in staat was om alle gegevens met een enkele query op te vragen.”

Dat probleem speelt bij NoSQL helemaal niet. “Bij CouchDB bijvoorbeeld stuur je een query, en krijg je direct een document terug met alle mogelijke gegevens. Voor veel ontwikkelaars is dat veel beter.” Ook ondersteunt CouchDB bijvoorbeeld native HTTP, en zijn documenten in JSON opgesteld. Door dat laatste kunnen ze direct worden aan clientzijde verwerkt in Javascript, een proces dat bij MySQL een extra laag aan serverzijde vereist.

De onzin

NoSQL lost de genoemde problemen dus grotendeels op. Maar, zo waarschuwt Bouman, je moet als ontwikkelaar voor al die voordelen wel een prijs betalen. “Je moet zelf aan gegevensbeheer doen. Je moet er zelf voor zorgen dat het bestand niet vervuild raakt en er geen dubbelingen in voorkomen. En bij een update moet door de hele database heen gewandeld worden.”

Daar ligt het belangrijkste probleem met de NoSQL-databases: dit beheer wordt niet altijd accuraat gedaan. “Relationele databases zijn niet voor niks ontstaan”, merkt Bouman op. “Voor veel traditionele applicaties zal NoSQL absoluut niet voldoen.”

“Hoewel dat beheer uiteindelijk goed moet zijn, is het bij veel diensten niet van levensbelang dat dit direct gebeurt”, stelt Bouman. Als voorbeeld noemt hij Twitter. “Bij Barack Obama wordt getoond hoeveel volgers hij heeft. Dat getal verandert per seconde. Maar voor bezoekers maakt het niet uit of dat aantal afwijkt in tientallen, honderdtallen of zelf duizendtallen.”

Anders ligt het bij bijvoorbeeld applicaties voor banken. “Stel je voor dat je ergens geld pint en 50 euro opneemt. Naderhand wordt door een data-beheerfout 100 euro van je bankrekening gehaald. Dat kan een bank niet maken, zelfs niet als het 'maar sporadisch' voorkomt”, zegt Bouman.

Er bestaat bij NoSQL wel zoiets als eventual consistency, maar daar zit zoals de naam al aangeeft een vertraging in, waarschuwt Bouman. “Je kunt op dat moment niet meer spreken van feiten. Bij CouchDB, maar ook bij Cassandra, staan meerdere versies van de waarheid in de database.”

Maar, zo benadrukt hij: dat is in veel gevallen minder verontrustend dan het lijkt. “Een getal als het aantal followers van Obama is constant aan het wijzigen, en is niet vast te pinnen”, zegt Bouman. “Dat soort database is voor dat soort gegevens dus helemaal zo gek niet is. Het logische databeheer moet altijd in orde zijn, maar absolute consistentie is geen vereiste.”

Bouman wijst ook op het CAP-theorema: Consistency, availability, performance. De theorie luidt dat je in een database twee van deze factoren kunt verkrijgen, maar nooit alledrie. “Je kunt dus een database bouwen die altijd beschikbaar is en goed presteert, maar dan is hij niet consistent. Dat is de keus die je met NoSQL eigenlijk maakt. Relationele databases zullen altijd kiezen voor consistency, in combinatie met availability óf performance.” [Oorspronkelijk staat de P in het CAP-theorema overigens voor Partition Tolerance en niet Performance, red.]