5.4 NoSQL og alternative datalagring

NoSQL og alternativ datalagring

Relasjonsdatabasar er fantastiske for strukturerte data med klare relasjonar. Men kva når dataa dine ikkje passar i tabellar? Kva om du treng ekstrem skalerbarheit eller fleksibilitet?

Då kan NoSQL-databasar vere løysinga.

I dette kapittelet lærer du:
- Kva NoSQL er og kvifor det eksisterer
- Ulike typar NoSQL-databasar
- MongoDB som eksempel på dokumentdatabase
- Når bruke SQL vs. NoSQL

Kva er NoSQL?

NoSQL står for "Not Only SQL" (ikkje berre SQL). Det er eit samlebegrep for databasar som ikkje følgjer den tradisjonelle relasjonsdatabasemodellen.

Kvifor NoSQL?

Relasjonsdatabasar har utfordringar med:
- Skalerbarheit: Vanskeleg å spreie data over mange serverar
- Fleksibilitet: Krev fast skjema (schema) på førehand
- Yting: JOIN-operasjonar kan bli trege på store datasett

NoSQL-databasar er designa for:
- Horizontal skalering: Spreie data over mange serverar
- Skjemafridom: Endre struktur undervegs utan å migrere heile databasen
- Spesialiserte bruksområde: Optimalisert for spesifikke typar data

Typar NoSQL-databasar

1. Dokumentdatabasar (MongoDB, CouchDB)
- Lagrar data som dokument (vanlegvis JSON)
- Eksempel: Blogginnlegg med kommentarar

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 kolonnar
- Eksempel: Tidsseriedata, loggfiler

4. Grafdatabasar (Neo4j, ArangoDB)
- Optimalisert for data med mange relasjonar
- Eksempel: Sosiale nettverk, tilrådingssystem

Dokumentdatabasar

Den mest populære typen NoSQL. Data blir lagra som dokument (vanlegvis 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"
}

Fordelar:
- Nesta strukturar (adresse inne i brukar)
- Arrays (interesser) utan eigen tabell
- Fleksibelt skjema (eitt dokument kan ha felt andre manglar)

Ulemper:
- Kan føre til dataredundans
- Mindre støtte for komplekse spørjingar over relasjonar
- Ingen garanterte ACID-eigenskapar (avhengig av database)

MongoDB-konsept

MongoDB er den mest populære dokumentdatabasen.

Terminologi (SQL → MongoDB)

Grunnleggjande operasjonar (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" })

Nesta strukturar

{
  "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 kravd 3 tabellar i SQL (Blogg, Forfattar, Kommentar).

Nøkkel-verdi-lagring

Den enklaste forma for NoSQL. Fungerer som ein 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åde:

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

Ulemper:
- Inkje spørjespråk (berre GET/SET)
- Ingen relasjonar mellom data
- Avgrensa til minne (RAM) for mange implementasjonar

SQL vs. NoSQL – når bruke kva?

Det er ikkje eitt svar som passar alle. Vel basert på behov:

Bruk SQL (relasjonsdatabasar) når:

✅ Dataa har klare relasjonar (kundar, ordrar, produkt)
✅ Du treng ACID-garantiar (bank, booking-system)
✅ Skjemaet er stabilt og velkjent på førehand
✅ Du treng komplekse spørjingar med JOIN
✅ Dataintegritet er kritisk

Eksempel: Banksystem, e-handel, HR-system

Bruk NoSQL når:

✅ Du treng ekstrem skalerbarheit (millionar av brukarar)
✅ Dataa endrar struktur ofte
✅ Du har hierarkiske/nesta data (JSON-liknande)
✅ Du treng høg yting på enkle operasjonar
✅ Du jobbar med store mengder ustrukturerte data

Eksempel: Sosiale medium, sanntidsanalyse, IoT-data, loggar

Hybrid-løysingar

Mange system brukar både SQL og NoSQL:
- SQL for kritiske transaksjonar (ordrar, betalingar)
- NoSQL for produktkatalogar og brukarprofilar
- Redis for caching av ofte brukte data

Eksempel:

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

Dokumentdatabase: NoSQL-database som lagrar data som dokument (JSON/BSON).

Collection: Gruppe av dokument i MongoDB (tilsvarar tabell i SQL).

Nøkkel-verdi-lagring: Enkel database som mappar nøklar til verdiar (som ein dictionary).

Skjemafridom: Moglegheit til å endre datastruktur utan å definere fast skjema på førehand.

Horizontal skalering: Spreie data over mange serverar for å handtere større last.

ACID: Atomicity, Consistency, Isolation, Durability – garantiar i relasjonsdatabasar.

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

Oppsummering

I dette kapittelet har du lært:

- NoSQL: ikkje-relasjonelle databasar for fleksible data.
- Dokumentdatabasar: lagrar data som dokument (MongoDB).
- Nøkkel-verdi-lagring: rask tilgang (Redis).
- SQL vs. NoSQL: vel ut frå datastruktur og behov.
- Hybrid-løysingar: kombinere begge typar.

Nøkkelbegrep