NoSQL (Not Only SQL) omfattar databastyper som hanterar ostrukturerad eller semi-strukturerad data. De prioriterar ofta skalbarhet och flexibilitet framför strikt relationsintegritet.


CAP-satsen

CAP-satsen säger att ett distribuerat system bara kan uppfylla två av dessa tre egenskaper samtidigt:

EgenskapBetydelse
ConsistencyAlla noder ser samma data samtidigt
AvailabilityVarje begäran får ett svar (lyckat eller misslyckat)
Partition ToleranceSystemet fungerar trots nätverksavbrott mellan noder

De flesta NoSQL-databaser väljer AP eller CP — relationsdatabaser väljer ofta CA (men kan inte vara partitionstoleranta i distribuerade miljöer).


Dokumentdatabaser (MongoDB, CouchDB)

Dokumentdatabaser lagrar data som JSON-liknande dokument med flexibla scheman.

// Ett dokument i MongoDB
{
  "_id": "user-42",
  "name": "Victor Hernandez",
  "email": "victor@bytebase.se",
  "addresses": [
    { "type": "home", "street": "Storgatan 1", "city": "Stockholm" },
    { "type": "work", "street": "Drottninggatan 10", "city": "Stockholm" }
  ],
  "orders": [
    { "order_id": "ord-1", "total": 2499, "items": 3 },
    { "order_id": "ord-2", "total": 599, "items": 1 }
  ]
}

När använda: Catalogsystem, innehållshantering, användarprofiler, applikationer med föränderliga scheman.

När undvika: Komplexa relationer, strikt relationsintegritet, många joins.


Key-Value databaser (Redis, DynamoDB)

Enkel lagring med nyckel-värde-par. Extremt snabb, ofta i minnet.

# Redis
SET user:42 '{"name":"Victor","email":"victor@bytebase.se"}'
GET user:42
# → '{"name":"Victor","email":"victor@bytebase.se"}'

# Med TTL (time-to-live)
SETEX session:abc123 3600 '{"user_id":42,"role":"admin"}'

Användningsområden:

  • Cache (CDN, API-svar, databasfrågor)
  • Sessionhantering
  • Realtidsdata (räknare, leaderboards, köer)
  • Distributed locking (SETNX)

Kolumnfamiljsdatabaser (Cassandra, HBase)

Data lagras i kolumnfamiljer istället för rader. Varje rad kan ha olika kolumner.

Users:
  user-42:  name = "Victor"     email = "victor@bytebase.se"  age = 19
  user-99:  name = "Anna"       email = "anna@example.com"    role = "admin"

Orders_by_user:
  user-42:  ord-1 = { total: 2499, status: "shipped" }
            ord-2 = { total: 599,  status: "pending" }

Använd när:

  • Tidsseriedata (loggar, sensorvärden, IoT)
  • Stora datamängder med förutsägbara accessmönster
  • Hög skrivprestanda krävs

Graph-databaser (Neo4j, ArangoDB)

Graph-databaser lagrar data som noder och kanter — perfekt för relationstunga domäner.

// Neo4j — hitta rekommendationer
MATCH (user:User {name: "Victor"})
      -[:BOUGHT]->(product:Product)
      <-[:BOUGHT]-(other:User)
      -[:BOUGHT]->(recommendation:Product)
WHERE NOT (user)-[:BOUGHT]->(recommendation)
RETURN DISTINCT recommendation.name, COUNT(*) AS relevans
ORDER BY relevans DESC;

Använd när:

  • Sociala grafer (vänner, följare, nätverk)
  • Rekommendationsmotorer
  • Nätverkstopologi (vägar, fiber, elnät)
  • Bedrägeridetektering

SQL vs NoSQL — när välja vad?

ScenarioVälj
Data är starkt relationellSQL (PostgreSQL, MySQL)
Flexibelt eller växlande schemaDokument (MongoDB)
Extremt hög läsprestandaKey-Value (Redis)
Tidsserier eller hög skrivvolymKolumnfamilj (Cassandra)
Relationer är datatGraph (Neo4j)
FulltextsökningSökdatabas (Elasticsearch)

Polyglot Persistence

Använd rätt verktyg för rätt jobb. En modern applikation använder ofta flera databaser:

Applikation
├── PostgreSQL  →  orders, customers (ACID-krav)
├── Redis       →  sessioner, cache, köer
├── MongoDB     →  produktkatalog (flexibelt schema)
└── Elasticsearch →  fulltextsökning

Av Victor Hernandez från Bytebase.se