# NoSQL

**NoSQL** betydde opprinnelig «**ikke-SQL**» eller «**ikke-relasjonell**», og viser til en database med mekanismer for lagring og henting av data som er modellert på andre måter enn tabell (eller «tabular») -relasjonene som brukes i relasjonsdatabaser. Slike databaser har eksistert siden slutten av 1960-årene, men navnet NoSQL ble først brukt på begynnelsen av det 2000-tallet sammen med Web 2.0. NoSQL-databaser har blitt brukt i stordata- og sanntidssystemer.

Noen ganger brukes NoSQL-begrepet i betydningen «**ikke bare SQL**» for å omfatte *både* relasjonelle og ikke-relasjonelle databaser. I slike systemer kan man gjerne ha støtte for å bruke SQL som spørrespråk.

## Fordeler

Motivasjoner for NoSQL kan være enkelt design, enklere "horisontal" skalering av regneklynger (en utfordring med relasjonsdatabaser), bedre styring av tilgjengelighet, og begrensning av impedans ved objekt-relasjonell mismatch. Datastrukturer i NoSQL-databaser (for eksempel nøkkelverdipar-database, bredt kolonnelager, grafdatabase, eller dokumentorienert database) er forskjellige fra de som brukes som standard i relasjonsdatabaser, hvilket gjør enkelte operasjoner raskere i NoSQL. Hvorvidt en NoSQL-database er egnet avhenger av problemet som skal løses. Noen ganger blir datastrukturene som brukes av NoSQL-databaser også sett på som "mer fleksible" enn relasjonsdatabasetabeller.

## Ulemper

CAP-teoremet (*consistency*, *availability*, *partition tolerance*, på norsk: konsistens, tilgjengelighet, partisjoneringsstoleranse) sier at et distribuert datalager må avveie mellom konsistens, tilgjengelighet og partisjoneringstoleranse (bare to kan velges). Mange NoSQL-databaser kompromitterer konsistensen til fordel for tilgjengelighet, partisjonstoleranse og hastighet.

Barrierer for større adopsjon av NoSQL-databaser inkluderer bruk av spørrespråk på lavt nivå (i stedet for høynivåspråk som for eksempel SQL), manglende evne til å utføre *ad hoc*-skjøtinger (*joins*) på tvers av tabeller, mangel på standardiserte grensesnitt, og enorme tidligere investeringer i eksisterende relasjonsdatabaser.

### ACID

De fleste NoSQL-lagre mangler ekte støtte for ACID-transaksjoner (atomisk, konsistent, isolert, durabel), selv om noen få databaser har gjort dem til en sentral del av designet. I stedet tilbyr de fleste NoSQL-databaser konseptet endelig konsistens (*eventual consistency*) hvor databaseendringer forplantes til alle noder til slutt (vanligvis innen millisekunder), slik at spørringer etter data kanskje ikke returnerer oppdaterte data umiddelbart og kan føre til lesing av data som ikke er nøyaktige, et problem kjent som "foreldet lesing".

I tillegg kan noen NoSQL-systemer miste skrivinger eller ha andre former for datatap. Noen NoSQL-systemer gir konsepter som loggføring med fremskrivning for å unngå tap av data.

For distribuert transaksjonsbehandling på tvers av flere databaser er datakonsistens en enda større utfordring som er vanskelig for både NoSQL og relasjonsdatabaser. Relasjonsdatabaser tillater ikke å spenne begrensninger for referanseintegritet på tvers av databaser. Få systemer opprettholder både ACID-transaksjoner og X/Open XA-standarder for distribuert transaksjonsbehandling. Interaktive relasjonsdatabaser har teknikker for konformasjons-reléanalyser som et vanlig trekk. Begrensninger i grensesnitt overvinnes ved hjelp av semantiske virtualiseringsprotokoller, slik at NoSQL-tjenester er tilgjengelige for de fleste operativsystemer.

## Typer

* Bredt kolonnelager
* Dokumentorientert database
* Grafdatabase
* Nøkkelverdipar-database

## Se også

* C++
* Fasettert søk

## Referanser