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

Ett försvarstal för ramverk
I den här branschen är det mer regel än undantag att en konsultprofil eller ett CV ska proppas full med, inte bara programmeringsspråk och tekniker, utan också ramverk. Begreppet “ramverk” i sig är väldigt brett och kan handla om allt från tekniknära användningar, som till exempel Spring, Hibernate eller Wicket, till mer verksamhets- och metodnära tillämpningar, som exempelvis Scrum (även om de mer bokstavstrogna Scrum-anhängarna föredrar termen “processkelett” snarare än benämningen metod- eller processramverk). När jag här och nu använder begreppet är det först och främst i programmeringsvärlden jag befinner mig.
Oavsett hur ramverket fungerar eller vilket problem det ska lösa är dess syfte detsamma. Tanken är att erbjuda återanvändbar kod som görs tillgänglig via ett tydligt definierat API för att på så sätt öka produktiviteten i ett utvecklingsprojekt. Genom att låta utvecklarna koncentrera sig på vad som gör systemet unikt krav- och verksamhetsmässigt behöver man inte lägga värdefull tid på att till exempel skapa en fungerande infrastruktur för applikationen.
Inga konstigheter, eller hur? Det är klart att det uppfattas som en lockande tanke för alla inblandade parter i ett IT-projekt.
Saken är bara den att jag på sistone uppmärksammat någon sorts backlash mot ramverk. Opponenterna verkar inte klaga på något specifikt ramverk i sig, utan på själva tanken att det finns andra som gjort tankearbetet åt en och så att säga redan trampat upp stigarna. Jag har identifierat två huvudspår i kritiken:
Den första kategorin av kritik handlar om att ramverken faktiskt inte löser de problem man som programmerare har eller att det rent av löser fel problem. Många gånger tycker man att det känns skönt att få en massa färdig funktionalitet gratis, men ganska snart inser man att ramverken snarare stjälper än hjälper vid utvecklingsarbetet. Om den tänkta koden inte hjälper till att lösa ett problem, utan i stället sätter käppar i hjulet för utvecklarna och tvingar fram ett arbetssätt där man försöker ”komma runt” ramverket upplevs det enbart frustrerande.
Den andra gruppen av kritiker fokuserar på att det inte längre är roligt att programmera. Tidigare har arbetet som programmerare handlat mycket om att arbeta från grunden och att klura på effektiva algoritmer. Numera har yrket skiftat fokus till att snarare sätta ihop färdiga block av teknikkomponenter. Jag har pratat med bekanta i branschen som tidigare sett sig själva som hantverkare, men som numera tycker att arbetet reducerats till att bygga en byggsats av givna byggklossar. Genom att arbetet inte längre går ut på att hitta den smartaste algoritmen eller det mest effektiva sättet att hämta en koppling till en databas upplevs det som att en del av yrkesstoltheten gått förlorad. Att titta i ett API och lista ut vilken metod som ska anropas känns helt enkelt inte lika utmanande eller stimulerande.
Min respons mot den första typen av kritik grundar sig i att IT-branschen är oerhört driven av tanken på förbättringar och genvägar. Nya programmeringsspråk och utvecklingsmodeller är alltid runt hörnet. När någonting vuxit sig för komplext eller långsamt ersätts det av något lättviktigare, något mer effektivt, något mer tidsbesparande eller något som är lättare att lära sig. Ett bra exempel på det här behovet av ständiga förbättringar hittar vi om vi tittar närmare på webben. När användare, kravställare och utvecklare plötsligt insåg att en webbsida kunde uppträda mer som en ”riktig” applikation med hjälp av Ajax ville alla ha den typen av system. Att göra webbapplikationer så att de vanligaste webbläsarna kan kommunicera asynkront kräver egentligen inte många rader egenutvecklad kod, men som svampar ur jorden dök det ena Ajax-ramverket efter det andra upp. En snabb koll på Wikipedia räknar just nu, förutom de två stora ramverken ”Prototype” och ”jQuery”, upp ytterligare trettiofem exempel under rubriken ”List of Ajax frameworks”. Det råder med andra ord ingen brist på de genvägar som erbjuds rent tekniskt för en utvecklare. Beställarmässigt då? Ja, många IT-arkitekter och kravställare frestas självklart av tanken på ett färdigutvecklat och färdigtestat mjukvarubibliotek eller -ramverk av tidsbesparingsskäl. Den här tidsbesparingen syns inte bara vid nyutveckling utan också vid förvaltning när ny personal tas in och denne kan fokusera på den egenutvecklade koden. Och här är vi nu – för att övervägas som konsult i ett projekt räcker det inte längre med att vara kompetent i till exempel Java. Du förväntas också ha jobbat med Spring, JSF, Struts, Hibernate, Wicket för att bara nämna några exempel. Den här bredden jag ser som en naturlig utveckling på konsultrollen och det här min respons på den andra typen av kritik kommer in i bilden. Yrkesrollen och därmed yrkesstoltheten har fått en annan fokus – Vilka ramverk gör jobbet bäst? Vilka fallgropar bör man undvika? Hur gör vi vårt system så strömlinjeformat som möjligt och undviker att ta in mjukvarubibliotek som är onödigt komplexa eller stora? Hur gör vi teknikvalet så transparent som möjligt? Det här är frågor som den nya tidens konsult måste kunna svara på. Det betyder självklart inte att själva grunden, programmeringskunskaperna, ska stå tillbaka, utan bara att en modern systemutvecklare eller IT-arkitekt måste ha en högre grad av omvärldsbevakning och större bredd än vad som tidigare behövts.
Jag hävdar inte på något sätt att ramverken i sig är ofelbara eller ens nödvändiga alla gånger. Min poäng är snarare följande – Om det du behöver är ett hjul, varför uppfinna ett eget? Vill man förlänga hjulanalogin kan man lite krystat hävda att så länge du vet vilka sorters hjul som finns tillgängliga där ute behöver du bara välja bästa sorten för just din uppgift och kan i stället lägga din kraft på att pumpa det fullt med luft.
//Mathias