NoSQL – nye, spennende muligheter for datalagring

Databaser er ikke hva de var. «NoSQL» er en betegnelse som ofte benyttes om databasesystemer spesielt godt tilpasset skalérbarhet og ytelse. Denne artikkelen gir et kort blikk på fordeler og ulemper med NoSQL – og litt om et neste steg: «NewSQL».

Siden 1980-tallet har såkalte «relasjonsdatabaser» (RDBMS – Relational Database Management Systems) og språket SQL (Structured Query Language) vært nesten enerådende for datalagring. Men siden RDBMS typisk er tilpasset å kjøre på én enkelt server, har de også iboende begrensninger – spesielt i forhold til diskstørrelse og antall samtidige brukere. Skalering utover dette kan være komplekst og utfordrende.

Røttene til dagens bruk av «NoSQL» strekker tilbake til om lag midtveis i forrige tiår da Amazon og Google begynte å ta i bruk egenutviklede systemer («Amazon Dynamo» og «Google BigTable») for å imøtekomme spesielt store behov for skalérbarhet og ytelse. Disse systemene har vært til inspirasjon for utvikling av senere NoSQL-databaser.

Effektiv utvikling med nøkkel-verdi- og dokumentdatabaser

Det er vanlig å gruppere NoSQL i fire typer systemer: 1) nøkkel-verdi-databaser, 2) dokumentdatabaser, 3) kolonnedatabaser og 4) grafdatabaser. Et fellestrekk ved NoSQL-databaser er at språket SQL vanligvis ikke brukes for kommunikasjon med databasesystemet. I tillegg muliggjør NoSQL-databaser i mange tilfeller lette og raske utviklingsprosesser, samt har gjerne som standard kraftige mekanismer for å håndtere skalering og store datamengder. (Disse mekanismene fører ofte med seg ulemper i forhold til datakonsistens, men det kommer vi tilbake til.)

En av styrkene til klassiske relasjonsdatabaser er at det finnes en fast beskrivelse – et såkalt skjema – av hva som er tillatt å lagre i en database. Med et kjent skjema og felles språk (SQL) blir det enkelt for ulike typer applikasjoner å integrere mot én og samme database. Men både skjemaer og SQL kan være til hinder for effektiv, evolusjonær systemutvikling. Ofte har nemlig applikasjoner bare behov for å lagre relativt enkle data spesifikke for applikasjonen. Da kan det være tidkrevende og unødvendig å sette opp et skjema i forkant.

I slike tilfeller vil såkalte nøkkel-verdi-databaser kunne være nyttige. Disse databasene gjør at utvikleren av en internettjeneste (f.eks. en nettbutikk) lett kan lagre et sett med vilkårlige verdier (f.eks. e-post-adresse, gateadresse og postnummer) koblet til en gitt nøkkel (f.eks. et brukernavn). Eksempler på populære nøkkel-verdi-databaser er Redis og Riak KV.

Hvis det er behov for mer struktur på de lagrede dataene, kan dokumentdatabaser være en mulighet. Dokumentdatabaser muliggjør for hver nøkkel lagring av et helt «dokument» – en samling av felter og tilhørende verdier, samt gjerne et antall nøstede undernivåer med ytterligere felter og verdier. Dette muliggjør (i kontrast til enkle nøkkel-verdi-databaser) avansert søkefunksjonalitet fordi søk kan gjøres basert på hvilken som helst kombinasjoner av felter (enten feltene eksisterer eller ikke i dokumentet) – og uavhengig av hvilket undernivå feltene befinner seg på.

En annen fordel med dokumentdatabaser er at de kan vokse dynamisk og i samspill med vekslende krav underveis i evolusjonære systemutviklingsprosesser. Etterhvert som et prosjekt får behov for å lagre nye typer data kan det fortløpende legges til relevante felt i nyopprettede dokumenter – uten at allerede lagrede dokumenter blir berørt eller behøver endring. Slik unngås en vanlig utfordring med klassiske relasjonsdatabaser: at mye tid brukes på å lage databaseskjemaer, og at databaseskjemaene i praksis må endres mange ganger underveis. Eksempel på en populær dokumentdatabase er MongoDB.

Kraftige søk med kolonne- og grafdatabaser

Såkalte kolonnedatabaser lagrer ofte data i tabellform – og er derfor den typen NoSQL-databaser som i forhold til dataenes logiske struktur har flest likheter med tradisjonelle relasjonsdatabaser. Den vesentlige forskjellen er at kolonnedatabaser lagrer tabellene kolonne for kolonne – mens relasjonsdatabaser lagrer tabellene rad for rad. En av hovedfordelene til kolonnedatabaser er effektiviteten som kan oppnås ved enkelte typer analyseoperasjoner. I en tabell med mange kolonner, og ved behov for å gjennomføre en analyseoperasjon på kun én eller et fåtall av disse kolonnene, vil en kolonnedatabase kun trenge å lese de kolonnene som er nødvendige for å utføre analysen. I databaser med store tabeller kan dette utgjøre store tidsmessige besparelser. Et eksempel på en populær kolonnedatabase er Cassandra.

Grafdatabaser er kanskje den mest spesielle formen for NoSQL-databaser. Grafdatabaser muliggjør effektiv lagring av data i form av nettverk. Nyttige anvendelser av grafdatabaser kan derfor være sosiale nettverk og systemer for tilgangskontroll. En kraftig egenskap ved grafdatabaser er muligheten til å søke i databasen basert på karakteristika ved selve grafstrukturen. F.eks. vil det i en grafdatabase for et sosialt nettverk være svært enkelt å skrive et kort søkeuttrykk som returnerer alle «venners venner» for en gitt person. Å gjøre tilsvarende søk i en tradisjonell relasjonsdatabase kan bli komplekst. En populær grafdatabase er Neo4J.

Utfordringer med datakonsistens i NoSQL

For å gi raske og brukervennlige tjenester til et høyt antall samtidige brukere – gjerne over hele verden – er internettapplikasjoner avhengige av høy grad av skalérbarhet. Skalering innebærer typisk at en database må kunne distribueres utover en rekke servere i datasentre fordelt geografisk, herunder også at de samme dataene lagres parallelt i flere datasentre. Mange NoSQL-databaser støtter avanserte former for skaléring.

Men heller ikke NoSQL-databaser kommer forbi en grunnleggende utfordring med skaléring og distribuert lagring av data: å sikre at data er fullstendig konsistent på tvers av servere og datasentre – uten at dette går på bekostning av tilgjengeligheten for en tjeneste. I tradisjonelle relasjonsdatabaser sikres konsistens gjennom å låse deler av databasen mens skriveoperasjoner gjennomføres. Men låsing er vanligvis mye mer utfordrende å gjennomføre i distribuerte databaser. For det første vil låsing for å sikre konsistens typisk måtte ta låser hos en rekke distribuerte servere, og slik i praksis kunne redusere mye av nytten ved i det hele tatt å ha en distribuert tjeneste. For det andre må det i store, distribuerte systemer forventes at både servere og kommunikasjonsforbindelser jevnlig kan feile – noe som i praksis kan umuliggjøre både låsing og konsistens av data for en distribuert database.

Konsistens – til slutt

På grunn av utfordringene relatert til å kombinere fullstendig datakonsistens med rask responstid i distribuerte systemer har man til nå i NoSQL-databaser typisk valgt å prioritere høy grad av tilgjengelighet foran fullstendig og rask datakonsistens. I NoSQL-sammenheng er det derfor vanlig å snakke om eventual consistency («konsistens til slutt»). Dette vil i praksis bety at det ofte vil kunne risikeres at en NoSQL-database ikke er helt konsistent, og at samtidige, identiske leseforespørsler sendt til ulike servere vil kunne gi forskjellige resultater.

I en del scenarier vil denne typen mangel på konsistens kunne være akseptabel. F.eks. vil det kunne argumenteres at det i mange tilfeller er lite viktig om en bruker av et sosialt nettverk i Europa ikke alltid har en like raskt oppdatert nyhetsstrøm som en bruker av det samme nettverket i USA. I andre sammenhenger kan «eventual consistency» få mindre heldige effekter – eksempelvis i en nettbutikk hvor det kan risikeres at flere brukere samtidig kjøper det siste eksemplaret av en vare. I noen sammenhenger vil «eventual consistency» være helt uakseptabelt. Dette gjelder for eksempel systemer hvor man er avhengig av helt sikker sanntidsinformasjon – som posisjoneringssystemer.

«NewSQL» – kan framtiden likevel være konsistent?

Selv om «eventual consistency» vil være akseptabelt i mange situasjoner, er utviklingen av databasesystemer som omtales som «NewSQL» en indikasjon på at konsistens i tradisjonell transaksjonsforstand ikke er en tapt skanse for distribuerte miljøer. Gjennom til dels komplekse strategier for kontroll av lese- og skriveoperasjoner har distribuerte databaser som Clustrix, VoltDB og Google Spanner (sistnevnte proprietær for Google) gjort nybrottsarbeid ved å satse på å kombinere full konsistens («strict consistency») og høy tilgjengelighet i sine løsninger. I tillegg tilbyr en database som Clustrix et nærmest tradisjonelt SQL-grensesnitt.

I distribuerte sammenhenger virker det altså som at «NewSQL»-databasesystemer vil kunne levere høyere grad av datakonsistens enn de mest populære «NoSQL»-databasene. Likevel er «NoSQL» et spennende og viktig tilskudd i databaseverdenen i kraft av at systemutvikling vil kunne gjøres raskere, smidigere og mer skalerbart.

Interessert i å vite mer? Vi anbefaler:

Igaidi IKT