NoSQL – en överblick

Ett begrepp som börjat dyka upp allt oftare i IT-bruset är NoSQL. Vad innebär då detta?
Begreppet NoSQL har existerat sedan slutet av 90-talet som benämning på databaser där utsökningar görs på annat sätt än via SQL-uttryck. Sedan ett par år har dock NoSQL blivit mer ett samlingsbegrepp för databaser som inte är relationsdatabaser (ett bättre namn vore ‘non-relational’ eller liknande). Andra begrepp är objekt-, dokument- och kolumndatabaser. Vad kännetecknar då en relationsdatabas? Vi rekapitulerar:
– Data lagras i tabeller som kan ha relationer till andra tabeller via främmande nycklar
– Tabeller och deras relationer definieras av ett statiskt databasschema
– Databasen uppfyller egenskaperna ACID (atomicity, consistency, isolation, durability), egenskaper som ska garantera att skrivoperationer sker på ett kontrollerat sätt
– Utsökning av lagrat data sker i (någon variant av) frågespråket SQL, där JOIN är vanligt förekommande (sammanslagning av data från relaterade tabeller)

En NoSQL-databas kan förenklat sägas vara en databas som saknar någon eller alla av ovanstående egenskaper. En gemensam nämnare är dock att tabeller och deras relationer saknas. Många har heller inte ambitionen att uppfylla alla delar av ACID. Och varför inte det då? Relationsdatabaser har ju vissa problem och en NoSQL-databas är en reaktion på detta där man försöker lösa problemen genom nya angreppssätt. Några problem som identifierats:
– Skalbarhet; t ex att en JOIN mellan några tabeller skalar dåligt när dessa blivit stora, eller problematiskt att bygga ett feltolerant, dynamiskt kluster av noder för mycket stora datamängder (man använder begreppet ‘web scale’ för applikationer av typen Facebook och Twitter).
– ORM, object-relational mapping. Att översätta en objektorienterad representation av data till en tabellorienterad motsvarighet har länge varit ett nödvändigt ont som man helst vill slippa.
– Statiska scheman; datamodeller tenderar att förändras över tiden och sådana förändringar kan vara besvärliga att införa i ett etablerat, stort system.

Hur har man då adresserat dessa problem? Vad gäller skalbarhet så handlar det om att från början bygga på en distribuerad infrastruktur, liknande det som länge funnits för applikationsservrar. Som exempel använder Google sitt distribuerade filsystem GFS till detta. Att hålla ett stort kluster synkroniserat där data replikeras på många noder, innebär en rad utmaningar och det finns också många olika sätt att angripa problemet. Ofta gör man valet att prioritera tillgänglighet och feltolerans framför absolut datakonsistens (‘C’ i ACID); via avancerade algoritmer propageras uppdateringar ut till noderna ungefär som en bakgrundsprocess efter att skrivoperationen avslutats. Ett konsekvens blir dock att relationer mellan tabeller (foreign key constraints) blir svåra att uppfylla under sådana omständigheter, så därför har man helt enkelt skippat hela tabellbegreppet och valt enklare strukturer för datat. Istället för JOIN tillåter man hellre dubbellagring, eller tvingar klienten att göra flera utsökningar. På köpet blir man av med en del av ORM-problematiken också.
NoSQL-databaser är i allmänhet schemalösa, vilket innebär att det är upp till klienten att lagra vilka attribut den vill om ett visst objekt (egenskapen kallas elasticitet). Däremot är det ofta så att ett nytt objekt inte kan läggas till hur som helst. En annan skillnad mot relationsdatabaser är att ett objekt i detta fall inte nödvändigtvis mappar mot ett affärsobjekt utan snarare mot ett tänkt sökresultat, vilket kan vara rätt förvirrande i början för den som är van vid MySQL t ex.
Observera att det jag här kallar objekt i praktiken kallas för något annat, t ex ColumnFamily i Cassandra, eller Document i MongoDB (se referenslistan nedan för mer info).
SQL finns heller inte såsom vi är vana vid, men beroende på produkt så görs utsökningar på väldigt olika sätt. Dessutom ska man skilja på utsökningar och aggregationer för ofta är tekniken olika i de fallen (utsökning innebär att hitta objekt med ett vissa attributvärden, medans aggregation innebär att applicera en funktion på att antal objekt t ex för att få fram statistik). Aggregationer görs ofta enligt MapReduce (en teknik framtagen och patenterad av Google, men öppen källkod finns också som ett subprojekt till Apache Hadoop), ett effektivt sätt att bearbeta stora, distribuerade datamängder.

Har man lyckats lösa relationsdatabasernas problem? Låt oss titta på ett företag som verkligen har gjort sin hemläxa, nämligen Google. Man insåg tidigt att en relationsdatabas inte kommer klara av de datamängder som man tänkt sig, så man tog fram Google Bigtable med dessa kännetecken:
– Databasen ska kunna distribueras på ett robust, transparent och kostnadseffektivt sätt
– Den lagrade datastrukturen har förenklas till nyckel/värde-par (som en HashMap i Java), på ett sätt som möjliggör effektiv distribution av data inom ett kluster
– JOIN existerar inte utan vid behov dubbellagras data istället (“disk är billigt”…)
– Datakonsistens sker enligt begreppet Eventual consistency med betydelsen att datakonsistens uppnås i klustret först när (och om) förändringar asynkront blivit propagerad i det
– Scheman är dynamiska, en klient kan ändra strukturen (t ex lägga till attribut på ett objekt) i körtid
Bigtable används idag i ett 60-tal av Googles applikationer och hanterar flera petabyte i ett kluster bestående av tusentals servrar, så man törs nog påstå att de har lyckats. En annan framgångsrik aktör är Amazon med sitt Dynamo. Dessa system är förstås extrema i sin storlek men principerna kan sägas gälla de flesta NoSQL-databasena. Skillnaden ligger bl a i att utvecklingen vanligen sker av intressegrupper (open source-community). Vidare brukar produkterna kategoriseras efter formen som data hanteras i (utöver nyckel/värde-par kan databasen vara av typen dokumentorienterad, graforienterad, objektlager).

Här följer några exempel på NoSQL-databaser som man kan ladda ned och testa själv:
Apache Cassandra – Används bl a av Facebook och ska likna Google Bigtable. Skriven i Java, aktuell version 0.6.5.
Apache CouchDB – Dokumentorienterad databas skriven i Erlang. Aktuell version 1.0.1.
MongoDB – Sägs kombinera det bästa från dokument-, nyckel/värde- och relationsdatabaser. Relativt mogen, aktuell version är 1.62, skriven i C++.
Terrastore – Dokumentorienterad, skriven i Java, baserad på Terracotta (distributionsteknik för JVM:er). Version 0.7.
Neo4j – svensk grafdatabas skriven i Java, aktuell version 1.1.
Det finns många, många fler, se referenslistan!

Slutsatser:
NoSQL-databaser är utvecklade som en reaktion på de problem man upplever med relationsdatabaser bl a rörande skalbarhet. För att klara detta har man varit tvungen att överge många principer som vi vant oss vid från relationsdatabaserna. Google Bigtable och Amazon Dynamo får i sammanhanget ses som extrema system i teknikens framkant som visat att distribuerad datalagring i kolossalformat verkligen fungerar.
Har man någon nytta av dessa nya teknologier även om man inte tänker lansera ett nytt Facebook? Ja, nu är det ju så att det finns en hel uppsjö av olika produkter klassade som NoSQL (se referenslistan nedan), som är mer eller mindre mogna och som erbjuder olika typer av lösningar som alla har sina för- och nackdelar. Om man är van vid relationsdatabaser så får man dock vara beredd på ett smärre paradigmskifte vad gäller datamodellering.
Kommer relationsdatabaserna att konkurreras ut nu av någon NoSQL-motsvarighet? Nej, inte på väldigt länge. Relationsdatabaserna fungerar väldigt bra i många tillämpningar och det finns mogna produkter för de flesta behov, dessutom är det lätt att hitta kompetens inom området. En NoSQL-databas kan dock vara ett intressant och kostnadseffektivt alternativ i specifika fall, särskilt om man avser hantera stora datamängder, eller om man tröttnat på objekt/relationsmappning och statiska scheman. Om ens data till sin natur är av graftyp (alltså sammankopplade noder, t ex som vänner i Facebook som har relationer till andra vänner) så kan en grafdatabas passa avsevärt mycket bättre än en relationsdatabas.

Referenser:

http://en.wikipedia.org/wiki/NoSQL

http://nosql-database.org

Produktexempel:

http://cassandra.apache.org

http://couchdb.apache.org

http://www.mongodb.org

http://code.google.com/p/terrastore

http://neo4j.org

//Keijo Kurkinen