Under flera års tid har en kamp pågått mellan anhängare av nya så kallade nosql-databaser och de som hejar på relationsdatabaser. På nosql-sidan hittar vi en spretig samling av produkter för att hantera olika datamodeller, till exempel nyckel-värde, grafer, dokument och objekt.

Det enda de har gemensamt är egentligen att de inte är relationsdatabaser. Det främsta argumentet för dem är att traditionella relationsdatabaser inte räcker för att hantera dels moderna storskaliga webbapplikationer, dels stora tillämpningar för dataanalys.

Läs också: Nu dras pluggen ur för Sql Server 2005 – men 800 000 servrar har inte uppgraderats

Men relationsdatabasen, till exempel Oracle och Microsofts Sql Server, lever kvar i all välmåga. Det är fortfarande den största enskilda databaskategorin och förespråkarna framhäver gärna transaktionssäkerhet och andra stabilitetshöjande funktioner.

Måste man välja mellan nosql- och relationsdatabaser?

Inte från och med nästa år, om man ska tro analytikerna Nick Heudecker, Merv Adrian och Etisham Zaidi på Gartner. I rapporten Market Guide for NoSQL DBMSs skriver de ”framtiden för databasarkitekturer kommer att bygga på flera modeller”. De förutsäger att alla ledande databasleverantörer kommer att erbjuda plattformar som hanterar flera datamodeller, både relationsmodellen och olika nosql-modeller, redan nästa år, skriver IDG News.

Anledningen till att vi får se multimodelldatabaser är helt enkelt att de olika datamodellerna var för sig bjuder på för många nackdelar.

Vad gäller relationsdatabaser lyfts de här nackdelarna fram:

  • Arkitekturen av typen ”master-slave” begränsar både flexibilitet och upptid.
  • Begränsningar vad gäller skalbarhet och förmåga att distribuera information för stora webbtillämpningar.
  • Strikta datascheman begränsar flexibiliteten för applikationer.
  • En rigid datamodell gör det dyrt att hantera stora volymer med semi- och ostrukturerade data.
  • Uppdelning av databaser på flera noder, så kallad sharding, blir dyr.

För nosql-databaser finns bland annat följande nackdelar:
  • En stor spridning av olika datamodeller gör det svårt att använda flera olika nosql-databaser tillsammans. Man blir antingen tvungen att använda begränsade delar av olika datamodeller eller att köra dyra transformationer med hantering av master data.
  • Olika nosql-leverantörer har olika lösningar för att hantera data, vilket tvingar utvecklare att bygga abstraktionslager om de vill använda flera olika nosql-databaser.

Läs också: Kackerlackor och grafikprocessorer väcker nytt liv i relationsdatabasen

Bland kraven som ställs på multimodelldatabaser märks de följande:
  • Hantering av fler än en nosql-modell, till exempel Json eller graf, i ett och samma logiska lager. Det underlättar för utvecklare som kan hantera olika typer av data på ett så uniformt sätt som möjligt.
  • Alla modeller som stöds exponeras via en sammanhängande mekanism.
  • Ett lager som hanterar tillgänglighet, säkerhet, distribution, katastrofhantering, etcetera, för data som hanteras med olika datamodeller.
  • Stöd för olika användningsfall för båda transaktionshantering och analystillämpningar som olap.

Sammantaget ska det här ge så låga driftskostnader för databaser som möjligt.