Få tekniker har var varit etablerade så länge inom it-branschen som relationsdatabaser med språket sql. Det har varit självklart att det är relationsmodellen som ger den rätta bilden av hur data ska struktureras.

Men på senare tid har dataintensiva webbtillämpningar med många användare tvingat fram alternativa lösningar som utmanar jättar som Oracle och IBM.

Även analyser av enorma datamängder och komplicerade datamodeller som är svåra att representera med relationsmodellen ställer krav på nya lösningar.

En yvig samling nya databa-ser, som går under samlingsnamnet nosql, erbjuder lösningar på de här problemen.

Ett exempel hittar vi på KTH i Stockholm. Webbtjänsten KTH Social, som används för diskussioner, schemainformation och annan interaktion, utvecklades till en början med en relationsdatabas för att hantera data, men det blev för krångligt.

– Datamodellen blev allt mer komplex och det blev för svårt att översätta användarnas behov till traditionell lagring i en relationsdatabas. Med dokumentdatabasen MongoDB för att lagra innehåll blev det mycket smidigare och prestanda blev bra, säger Peter Lundberg, seniorkonsult på Valtech som stått för utvecklingen av KTH Social.

Relationsdatabasen an-vänds fortfarande för delar av tjänsten, till exempel för att lagra kursinformation.

– Jag tolkar begreppet nosql som not only sql, säger Peter Lundberg och syftar på att olika tekniska lösningar är bra i olika situationer.

Att valet föll på MongoDB förklarar han med att det är en mogen dokumentdatabas.

Sven Johansson, som är konsult på Mejsla och har erfarenhet av flera nosql-databaser, håller med om att det ofta blir enklare att representera data med de nya databaserna.

– Nosql-databaserna har bidragit till andra sätt att tänka för att modellera data. De kan ofta erbjuda bättre sätt att representera data än omformning till relationer.

Ett exempel på det är att lagra dokument med olika typer av innehåller. Det blir enklare att lagra dokumentet i en dokumentdatabas än att försöka återge dess struktur i en relationsdatabas.

Ju enklare en datastruktur är, desto mer vinner man på att använda en enkel databasstruktur. Om en datamängd kan beskrivas med enbart ett id-begrepp och ett datavärde blir det enklare och går snabbare att hantera den i en databas som enbart arbetar med den datastrukturen.

Fakta

  •  Bra prestanda i vissa situationer.
  • Bättre skalbarhet.
  • Enklare utveckling, eftersom datamodellerna blir enklare.
  • Datamodeller som passar bättre ihop med en del tilllämpningar än för relationsdatabaser. Ett exempel är när flera förekomster av personbeskrivningar kan ha väldigt olika typer av innehåll.
  • Avsaknad av formella beskrivningar av databasstruktur, så kallade scheman, i många nosql-databaser. Det gör att det blir enklare att ändra applikationer som tagits i drift.

Nosql-databaser kan delas in i, minst, fem undergrupper:

  • Key-value stores. Den enklaste typen, med produkter som Cassandra, Riak, Bigtable, Redis, Azure Table Storage och den äldre Berkeley DB. Det finns även en inbyggd lokal key-value store i webbläsare som stöder html5.
  • Dokumentdatabaser. Här märks MongoDB, CouchDB och SimpleDB. Även den gamla Lotus Notes kan räknas hit.
  • Grafdatabaser. Till exempel Neo4j och FlockDB.
  • Objektdatabaser, som Objectivity DB och Versant.
  • Övriga – inte minst populära Hadoop.