5.4 NoSQL og alternative datalagring

Når dataene ikke passer i tabeller

Relasjonsdatabaser er fantastiske for strukturerte data med klare relasjoner. Men hva når dataene dine ikke passer pent i tabeller? Hva hvis du trenger ekstrem skalerbarhet eller fleksibilitet til å endre struktur underveis? Da kan NoSQL-databaser være løsningen.

NoSQL står for «Not Only SQL» – ikke bare SQL. Det er et samlebegrep for databaser som ikke følger den tradisjonelle relasjonsmodellen. De oppsto fordi relasjonsdatabaser sliter med tre ting når skalaen blir enorm: skalerbarhet, fordi det er vanskelig å spre data over mange servere; fleksibilitet, fordi de krever et fast skjema definert på forhånd; og ytelse, fordi JOIN-operasjoner kan bli trege på svært store datasett. NoSQL er designet for horisontal skalering (spre data over mange servere), skjemafrihet (endre struktur underveis), og spesialiserte bruksområder.

Det finnes fire hovedtyper. Dokumentdatabaser som MongoDB lagrer data som dokumenter, vanligvis JSON. Nøkkel-verdi-lagring som Redis lagrer enkelt en nøkkel som peker til en verdi. Kolonneorienterte databaser som Cassandra er optimalisert for store datasett med mange kolonner, som tidsseriedata og loggfiler. Og grafdatabaser som Neo4j er optimalisert for data med mange relasjoner, som sosiale nettverk og anbefalingssystemer.

Dokumenter og nøkkel-verdi

Den mest populære NoSQL-typen er dokumentdatabasen, der data lagres som dokumenter, vanligvis JSON eller BSON. Et brukerdokument i MongoDB kan ha en adresse som et nestet objekt og interesser som en array – alt i ett dokument. Fordelene er klare: du får nestede strukturer, arrays uten egen tabell, og fleksibelt skjema der ett dokument kan ha felt et annet mangler. Ulempene er dataredundans, mindre støtte for komplekse spørringer over relasjoner, og ikke alltid garanterte ACID-egenskaper. MongoDB har sin egen terminologi som speiler SQL: en collection tilsvarer en tabell, et document tilsvarer en rad, og et field tilsvarer en kolonne. Grunnoperasjonene er insertOne (create), find/findOne (read), updateOne (update) og deleteOne (delete). Et blogginnlegg med forfatter og en liste av kommentarer kan lagres som ett enkelt dokument – noe som ville krevd tre tabeller i SQL.

Den enkleste NoSQL-formen er nøkkel-verdi-lagring, som fungerer som en gigantisk Python-dictionary. Redis er det mest kjente eksempelet, med set for å lagre og get for å hente. Du kan til og med lagre JSON som verdi, og sette en utløpstid (TTL) med setex, slik at data forsvinner automatisk etter en gitt tid. Dette gjør nøkkel-verdi-lagring perfekt for caching (ofte brukte data midlertidig), sessions i webapplikasjoner, rate limiting og enkle køer. Det er ekstremt raskt, ofte fordi det ligger i RAM, og veldig enkelt å bruke – men det har intet egentlig spørrespråk utover GET og SET, ingen relasjoner, og er ofte begrenset av tilgjengelig minne.

SQL eller NoSQL – og hybridene

Det finnes ikke ett svar som passer alle. Valget avhenger av behovet. Du bør bruke SQL når dataene har klare relasjoner (kunder, ordrer, produkter), når du trenger ACID-garantier (banker, bookingsystemer), når skjemaet er stabilt og kjent på forhånd, når du trenger komplekse spørringer med JOIN, og når dataintegritet er kritisk. Typiske eksempler er banksystemer, e-handel og HR-systemer.

Du bør vurdere NoSQL når du trenger ekstrem skalerbarhet til millioner av brukere, når dataene ofte endrer struktur, når du har hierarkiske eller JSON-lignende data, når du trenger høy ytelse på enkle operasjoner, eller når du jobber med store mengder ustrukturerte data. Typiske eksempler er sosiale medier, sanntidsanalyse, IoT-data og logger. Et nyttig teoretisk bakteppe er CAP-teoremet, som sier at du i et distribuert system bare kan ha to av tre egenskaper samtidig: Consistency, Availability og Partition tolerance.

I praksis trenger du sjelden å velge bare én. Mange moderne systemer er hybrider som bruker begge: SQL for kritiske transaksjoner som ordrer og betalinger, NoSQL for produktkataloger og brukerprofiler, og Redis for caching av ofte brukte data. En typisk arkitektur kan være PostgreSQL for ordrer, MongoDB for produkter og Redis for sessions – hver database brukt til det den er best på.

Oppsummering

Når data ikke passer i tabeller, eller når skala og fleksibilitet blir avgjørende, trer NoSQL inn – «Not Only SQL». De fire hovedtypene er dokumentdatabaser (MongoDB), nøkkel-verdi-lagring (Redis), kolonneorienterte (Cassandra) og grafdatabaser (Neo4j). Dokumentdatabaser lagrer JSON-lignende dokumenter med nestede strukturer, mens nøkkel-verdi-lagring er lynraskt og perfekt for caching og sessions.

Valget mellom SQL og NoSQL avhenger av behovet: SQL for klare relasjoner og ACID, NoSQL for skalerbarhet og fleksibilitet, med CAP-teoremet som teoretisk bakteppe. Og i praksis bruker mange systemer hybridløsninger som kombinerer flere databasetyper. I neste kapittel ser vi på datamodellering for komplekse systemer.