Hvilke datatyper støtter Redis?

Question

IT Interview Practice · Accepted Answer

Redis støtter flere **datastrukturer** som verdier — strings, lister, hashes, sets, sorted sets, pluss spesialiserte typer (streams, bitmaps, HyperLogLog, geospatial). Å velge riktig type for hver bruksscenario er nøkkelen til å bruke Redis effektivt.

## Kjernedatatyper

```bash
# STRING — the simplest (text, numbers, even binary up to 512MB)
SET key "value"
INCR counter            # atomic increment (strings can be counters)

# LIST — ordered list of strings (a linked list — fast push/pop at ends)
LPUSH mylist "a"        # push left
RPUSH mylist "b"        # push right
LRANGE mylist 0 -1      # get all → useful for queues, recent-items

# HASH — a map of field→value (like an object/record)
HSET user:1 name "Ann" age 30
HGET user:1 name        # => "Ann"  → great for storing objects

# SET — unordered unique strings
SADD tags "redis" "cache"
SISMEMBER tags "redis"  # membership test; SINTER/SUNION for set operations

# SORTED SET (ZSET) — unique members each with a SCORE, kept ordered by score
ZADD leaderboard 100 "Ann" 90 "Bob"
ZRANGE leaderboard 0 -1 WITHSCORES   # ranked → leaderboards, priority queues
```

## Spesialiserte typer

```text
STREAM      → an append-only log (like a message queue/event log with consumer groups)
BITMAP      → bit operations on strings (compact flags, e.g. daily active users)
HYPERLOGLOG → approximate unique counts using tiny memory (cardinality estimation)
GEOSPATIAL  → store/query locations (geo radius queries)
```

## Å velge riktig type

```text
String      → simple values, counters, cached serialized data
List        → queues, stacks, recent-items, activity feeds
Hash        → objects/records (store fields of an entity together)
Set         → unique collections, membership tests, tags, relationships
Sorted Set  → leaderboards, rankings, priority queues, time-ordered data
→ Picking the right structure makes operations efficient and natural.
```

## Hvorfor det er viktig

Å forstå Redis's datatyper er fundamental for å bruke Redis effektivt, fordi Redis's styrke kommer nettopp fra dets **rike datastrukturer** (ikke bare enkel nøkkel-verdi-lagring), så å kjenne dem og når man skal bruke hver enkelt er essensiell praktisk kunnskap.

De **kjerne-typene** passer hver for seg til ulike behov: **strings** (enkle verdier og atomiske tellere), **lists** (ordnede samlinger for køer, stakker og feeds for nylige elementer), **hashes** (lagring av objekter/poster med flere felt sammen — effektivt for entiteter), **sets** (unike samlinger for medlemskapstest, tagger og relasjoner, med set-operasjoner som interseksjon), og **sorted sets** (medlemmer rangert etter score — det naturlige valget for ranglister, rangeringer og prioritetskøer).

Å forstå de **spesialiserte typene** — streams (append-only logger med forbrukergrupper, for meldingskøer og event sourcing), bitmaps (kompakte flagg), HyperLogLog (tilnærmet unike tellinger i minimal minne), og geospatial (posisjonsforespørsler) — utvider hva Redis kan gjøre effektivt.

Viktigst av alt er det å **velge riktig type** for hver bruksscenario (en sorted set for en rangliste, en hash for et objekt, en liste for en kø) som gjør Redis-operasjoner effektive og naturlige — å bruke feil struktur fører til uelegante og langsomme løsninger.

Siden Redis's verdi kommer fra dets datastrukturer og å bruke dem riktig er kjernekompetansen ved arbeid med Redis, og siden valget av struktur direkte bestemmer om operasjoner er effektive og kode er ren, er forståelse av Redis datatyper — kjerne- og spesialiserte typer og når man skal bruke hver enkelt — essensiell, hyppig benyttet kunnskap for alle som bruker Redis, grunnlaget for å utnytte Redis effektivt ut over trivial nøkkel-verdi-lagring.

Kjernedatatyper

Spesialiserte typer

Å velge riktig type

Hvorfor det er viktig

Relaterte spørsmål