archives.cropped

Databehandling med NoSql

NoSql og relasjonsdatabaser kan fungere side om side, mener Rafael Godlewski.

NoSql-teknologien har vært på fremmarsj en stund nå, og vi begynner å få et stort utvalg av NoSql-produkter. Alle disse kan skilte med ytelser og skaleringsevne som er langt overlegen relasjonsdatabasene. Men har vi virkelig kommet til punktet hvor vi kan takke vår trofaste venn, relasjonsdatabasen, for samarbeidet fordi vi har en fått en bedre kompis i NoSql?

Som den store fordelen til NoSql-teknologien nevner man ofte bedre evne til å skalere horisontalt, mens den store ulempen er mangelen på transaksjonsstøtte og relasjonsintegritet. Men hvordan er denne teknologien til å behandle data?

Tradisjonelt er vi er vant til å se at datastrukturen i en relasjonsdatabase er en datamodell som består av objekter som representerer den virkeligheten som vårt system er en del av. Disse objektene kalles entiteter. Entitetene er beskrevet ved hjelp av tabeller, hvor entitetens egenskaper ligger i kolonner.  Entiteter kan ha relasjoner til andre entiteter i databasen.  Når man utformer en datamodell, forholder man seg til regler, slik at entitetene vil være unike og man unngår redundans i databasen.

NoSql-databasene skiller seg fra relasjonsdatabasen på den måten at dataene lagres mindre strukturert. Den tradisjonelle konsistensen ofres til fordel for andre egenskaper.  Databasene krever ikke at det defineres et skjema, dvs at datastrukturen blir gjerne til underveis. Der er man mer interessert i en forenklet modell som beskriver et aspekt av virkeligheten som man har fokus på, i motsetning til å modellere objektene i virkeligheten. På den måten kan flere ulike entiteter lagres i samme tabell og til og med i samme post.

Vi ser også at prinsippene bak struktureringen av dataene varierer mellom de ulike NoSql-databasene. Det finnes fire typer NoSql-databaser:

Key/Value

Eks: Redis, MemcacheDB

Hver post består av en verdi assosiert med en nøkkel

***

Kolonnebasert

Eks: Cassandra, HBase

Hver post består av flere verdier assosiert med en nøkkel

***

Dokumentbasert

Eks: MongoDB, Couchbase

Hver post består av verdier i relasjon til andre verdier i den samme posten, ved hjelp av et format som for eksempel Json.

***

Grafbasert

Eks: OrientDB, Neo4J

Poster i databasen har relasjoner til andre poster. Kan for eksempel brukes til å representere et sosialt nettverk med venner og venners venner.

***

Når strukturene som råder i de ulike databasetypene er så forskjellige, er det mulig at den ene typen kan erstatte den andre uten at det går på bekostning av noe? Hvilken skal man i så fall velge?

Fra skolen husker jeg en øvelse som gikk ut på å skille begrepene data og informasjon. Husker jeg korrekt så var forklaringen ca. slik:

Data er en mengde med uavhengige symboler som f.eks. tall og bokstaver. Uten at disse symbolene blir satt i en sammenheng med noe, gir de ingen mening. Det er når disse symbolene / dataene blir satt i en kontekst at de blir til informasjon.

Basert på denne definisjonen, viser figuren under transformasjonen fra data til informasjon, når man bruker en relasjonsdatabase.

På den grovt forenklede figuren over ser vi hvordan data blir transformert til informasjon. På det laveste nivået blir all data lagret i form av nuller og enere. Nuller og enere gir ingen mening, med mindre man ser dem som uttrykk for bytes. Har man kommet så langt at man har bytes, vil man kunne sette dem sammen til en eller flere filer som danner en relasjonsdatabase. I relasjonsdatabasen finner vi tabeller med data som beskriver entiteter som sted og måling. Nå har vi mulighet til å trekke ut ulik informasjon som f.eks.:

  • Hvilken temperatur var på et sted på et visst tidspunkt?
  • Hvilke steder finnes det målinger for i en periode?
  • Hvor mange målinger ble det tatt i Drammen i august?
  • Hvor var gjennomsnittstemperaturen over et visst tall i Oslo i august?

Kan man ikke bare lagre informasjon istedenfor å transformere data hver gang for å få opp ytelsen, kan man spørre. Jo, det kan man, og det er akkurat det som NoSql-databasene baserer seg på. Man kan riktignok ha brent sine broer for å utlede ny type informasjon. Har man så pass konkrete behov og vet at dette behovet vil aldri oppstå er man i mål. I motsatt tilfelle bør man gjøre en ekstra vurdering med hensyn til hvordan man modellerer dataene og hvilken type database man bruker.

Figuren under viser det samme eksemplet, hvor dataene er modellert i en dokumentbasert NoSql-database.

Vi ser på figuren nedenfor ser vi at også ved hjelp av NoSql-teknologi er vi i stand til å få ut mye av den samme informasjonen, selv om vi møter på noen utfordringer.

r 1 Databehandling med NoSql

For å få lettere og raskere tilgang til målingsdata knyttet til et sted, har man denne gangen valgt å modellere dataene i form av dokumenter bestående av steder med tilhørende målinger. På den måten er databasen optimalisert for uthenting av målingsdata stedvis. Skulle man derimot være interessert i å få ut statistisk informasjon på tvers av steder, f.eks. om hvilke steder som hadde temperaturer over 20°C på en viss dato, måtte man tvunget databasen til å jobbe mot logikken bak datamodellen. Databasen ville nemlig måttet søke gjennom alle dokumentene for å finne forekomster av målinger som tilfredsstiller disse kriteria. Med andre ord har man allerede på designtidspunktet avgjort hvilken informasjon som skal være lettest tilgjengelig.

r 2 Databehandling med NoSql

Eksemplet ovenfor viser at teknologiene er langt fra jevnbyrdige og at relasjonsdatabasen ikke trenger å føle seg truet, da begge teknologiene er gode på hvert sitt område. NoSql-databasene er i stand til å produsere informasjon veldig fort og for mange brukere på en gang. Ønsker man imidlertid å være å være fleksibel på hva slags informasjon man ønsker å utvinne, vil man definitivt ønske å behørig plassere sine data i en relasjonsdatabase.

Alle systemer tjener ulike behov og har sine kostnadsrammer. Men jeg frydes ved tanken på hvilke muligheter man hadde fått ved å kombinere relasjonsdatabasen med en av de nevnte NoSql-databasene, for eksempel ved å benytte seg av CQRS-pattern (Command and Query Responsibility Separation). Kort sagt ville et slikt system lagre alle data under hygieniske forhold i en relasjonsdatabase. Samtidig ville det produseres lett tilgjengelig informasjon i en dokumentbasert NoSql-database for umiddelbar opphenting av brukerne.

 

 

Publisert