Hvilke datatyper understøtter Redis?

Question

Accepted Answer

Redis understøtter flere **datastrukturer** som værdier — strings, lister, hashes, sets, sorterede sets, plus specialiserede typer (streams, bitmaps, HyperLogLog, geospatial). At vælge den rigtige type for hver use case er nøglen til at bruge Redis effektivt.

## Core datatyper

```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
```

## Specialiserede 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)
```

## At vælge den rigtige 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 betyder noget

At forstå Redis's datatyper er fundamental for at bruge Redis effektivt, fordi Redis's kraft kommer netop fra dets **rige datastrukturer** (ikke blot simpel key-value-lagring), så at kende dem og hvornår man bruger hver enkelt er essentiel praktisk viden.

De **core-typer** passer hver til forskellige behov: **strings** (simple værdier og atomare tællere), **lister** (ordnede samlinger for køer, stakke og feeds med seneste elementer), **hashes** (lagring af objekter/poster med flere felter sammen — effektivt for entiteter), **sets** (unikke samlinger til medlemskabstests, tags og relationer, med set-operationer som intersection), og **sorterede sets** (medlemmer rangeret efter score — det naturlige valg for leaderboards, ranglister og prioritetskøer).

At forstå de **specialiserede typer** — streams (append-only logs med consumer groups, til message queues og event sourcing), bitmaps (kompakte flag), HyperLogLog (omtrentlige unikke tællinger i minimal hukommelse), og geospatial (location queries) — udvider hvad Redis kan gøre effektivt.

Vigtigst af alt, **at vælge den rigtige type** for hver use case (en sorteret set for en leaderboard, en hash for et objekt, en liste for en kø) er det, der gør Redis-operationer effektive og naturlige — at bruge den forkerte struktur fører til ubehjælpsomme, langsomme løsninger.

Da Redis's værdi kommer fra dets datastrukturer og brugen af dem på passende måde er kernekompetencen ved arbejde med Redis, og da valget af struktur direkte bestemmer, om operationer er effektive og koden er ren, er forståelsen af Redis datatyper — core- og specialiserede typer og hvornår man bruger hver enkelt — essentiel, hyppigt anvendt viden for alle der bruger Redis, fundamentet for at udnytte Redis effektivt ud over trivial key-value-lagring.