5.4 NoSQL og alternative datalagring

NoSQL og alternative datalagring

Relasjonsdatabaser er fantastiske for strukturerte data med klare relasjoner. Men hva når dataene dine ikke passer i tabeller? Hva hvis du trenger ekstrem skalerbarhet eller fleksibilitet?

Da kan NoSQL-databaser være løsningen.

I dette kapittelet lærer du:
- Hva NoSQL er og hvorfor det eksisterer
- Ulike typer NoSQL-databaser
- MongoDB som eksempel på dokumentdatabase
- Når bruke SQL vs. NoSQL

Hva er NoSQL?

NoSQL står for "Not Only SQL" (ikke bare SQL). Det er et samlebegrep for databaser som ikke følger den tradisjonelle relasjonsdatabasemodellen.

Hvorfor NoSQL?

Relasjonsdatabaser har utfordringer med:
- Skalerbarhet: Vanskelig å spre data over mange servere
- Fleksibilitet: Krever fast skjema (schema) på forhånd
- Ytelse: JOIN-operasjoner kan bli trege på store datasett

NoSQL-databaser er designet for:
- Horizontal skalering: Spre data over mange servere
- Skjemafrihet: Endre struktur underveis uten å migrere hele databasen
- Spesialiserte bruksområder: Optimalisert for spesifikke typer data

Typer NoSQL-databaser

1. Dokumentdatabaser (MongoDB, CouchDB)
- Lagrer data som dokumenter (vanligvis JSON)
- Eksempel: Blogginlegg med kommentarer

2. Nøkkel-verdi-lagring (Redis, DynamoDB)
- Enkel lagring av nøkkel → verdi
- Eksempel: Sessions, cache

3. Kolonneorienterte (Cassandra, HBase)
- Optimalisert for store datasett med mange kolonner
- Eksempel: Tidsseriedata, loggfiler

4. Grafdatabaser (Neo4j, ArangoDB)
- Optimalisert for data med mange relasjoner
- Eksempel: Sosiale nettverk, anbefalingssystemer

Dokumentdatabaser

Den mest populære typen NoSQL. Data lagres som dokumenter (vanligvis JSON eller BSON).

Eksempel: MongoDB-dokument

{
  "_id": "507f1f77bcf86cd799439011",
  "navn": "Ole Olsen",
  "epost": "ole@example.com",
  "adresse": {
    "gate": "Storgata 1",
    "postnummer": "0001",
    "by": "Oslo"
  },
  "interesser": ["programmering", "gaming", "fotball"],
  "registrert": "2024-01-15"
}

Fordeler:
- Nestede strukturer (adresse inne i bruker)
- Arrays (interesser) uten egen tabell
- Fleksibelt skjema (ett dokument kan ha felt andre mangler)

Ulemper:
- Kan føre til dataredundans
- Mindre støtte for komplekse spørringer over relasjoner
- Ingen garantert ACID-egenskaper (avhengig av database)

MongoDB-konsepter

MongoDB er den mest populære dokumentdatabasen.

Terminologi (SQL → MongoDB)

Grunnleggende operasjoner (pseudo-kode)

db.users.insertOne({
  navn: "Kari Hansen",
  epost: "kari@example.com",
  alder: 25
})

// Finn alle over 18 år
db.users.find({ alder: { $gt: 18 } })

// Finn én bruker
db.users.findOne({ epost: "kari@example.com" })

db.users.updateOne(
  { epost: "kari@example.com" },
  { $set: { alder: 26 } }
)

Delete:

db.users.deleteOne({ epost: "kari@example.com" })

Nestede strukturer

{
  "tittel": "Min blogg",
  "innhold": "Dette er en bloggpost...",
  "forfatter": {
    "navn": "Ole",
    "epost": "ole@example.com"
  },
  "kommentarer": [
    {
      "bruker": "Kari",
      "tekst": "Bra innlegg!",
      "dato": "2024-01-15"
    },
    {
      "bruker": "Per",
      "tekst": "Enig!",
      "dato": "2024-01-16"
    }
  ]
}

Dette ville krevd 3 tabeller i SQL (Blogg, Forfatter, Kommentar).

Nøkkel-verdi-lagring

Den enkleste formen for NoSQL. Fungerer som en gigantisk Python-dictionary.

Eksempel: Redis

# Lagre verdi
redis.set("bruker:1001:navn", "Ole Olsen")
redis.set("bruker:1001:poeng", 1500)

# Hente verdi
navn = redis.get("bruker:1001:navn")  # "Ole Olsen"
poeng = redis.get("bruker:1001:poeng")  # "1500"

# Lagre JSON som verdi
import json
bruker_data = json.dumps({"navn": "Kari", "alder": 25})
redis.set("bruker:1002", bruker_data)

# Utløpstid (TTL - Time To Live)
redis.setex("session:abc123", 3600, "user_id:1001")  # Utløper etter 1 time

Bruksområder:

Fordeler:
- Ekstremt rask (ofte i RAM)
- Enkel å forstå og bruke
- Perfekt for midlertidig data

Ulemper:
- Ingen spørrespråk (bare GET/SET)
- Ingen relasjoner mellom data
- Begrenset til minne (RAM) for mange implementasjoner

SQL vs. NoSQL – når bruke hva?

Det er ikke ett svar som passer alle. Velg basert på behov:

Bruk SQL (relasjonsdatabaser) når:

✅ Dataene har klare relasjoner (kunder, ordrer, produkter)
✅ Du trenger ACID-garantier (bank, booking-systemer)
✅ Skjemaet er stabilt og velkjent på forhånd
✅ Du trenger komplekse spørringer med JOIN
✅ Dataintegritet er kritisk

Eksempler: Banksystemer, e-handel, HR-systemer

Bruk NoSQL når:

✅ Du trenger ekstrem skalerbarhet (millioner av brukere)
✅ Dataene endrer struktur ofte
✅ Du har hierarkiske/nestede data (JSON-lignende)
✅ Du trenger høy ytelse på enkle operasjoner
✅ Du jobber med store mengder ustrukturerte data

Eksempler: Sosiale medier, sanntidsanalyse, IoT-data, logger

Hybrid-løsninger

Mange systemer bruker både SQL og NoSQL:
- SQL for kritiske transaksjoner (ordrer, betalinger)
- NoSQL for produktkataloger og brukerprofiler
- Redis for caching av ofte brukte data

Eksempel:

PostgreSQL (ordrer) + MongoDB (produkter) + Redis (sessions)

Dokumentdatabase: NoSQL-database som lagrer data som dokumenter (JSON/BSON).

Collection: Gruppe av dokumenter i MongoDB (tilsvarer tabell i SQL).

Nøkkel-verdi-lagring: Enkel database som mapper nøkler til verdier (som en dictionary).

Skjemafrihet: Mulighet til å endre datastruktur uten å definere fast skjema på forhånd.

Horizontal skalering: Spre data over mange servere for å håndtere større last.

ACID: Atomicity, Consistency, Isolation, Durability – garantier i relasjonsdatabaser.

CAP-teoremet: Du kan bare ha 2 av 3: Consistency, Availability, Partition tolerance.

Oppsummering

I dette kapittelet har du lært:

- NoSQL: ikke-relasjonelle databaser for fleksible data.
- Dokumentdatabaser: lagrer data som dokumenter (MongoDB).
- Nøkkel-verdi-lagring: rask tilgang (Redis).
- SQL vs. NoSQL: velg ut fra datastruktur og behov.
- Hybrid-løsninger: kombinere begge typer.

Noekkelbegreper