Welche Datentypen unterstützt Redis?

Question

Accepted Answer

Redis unterstützt mehrere **Datenstrukturen** als Werte — Strings, Listen, Hashes, Sets, Sorted Sets sowie spezialisierte Typen (Streams, Bitmaps, HyperLogLog, Geospatial). Die richtige Auswahl des Typs für jeden Use-Case ist entscheidend für die effektive Nutzung von Redis.

## Kern-Datentypen

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

## Spezialisierte Typen

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

## Wahl des richtigen Typs

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

## Warum es wichtig ist

Das Verständnis der Datentypen von Redis ist grundlegend für die effektive Nutzung von Redis, da die Stärke von Redis genau in seinen **reichhaltigen Datenstrukturen** (nicht nur simpler Schlüssel-Wert-Speicherung) liegt, weshalb das Kennen dieser Typen und das Wissen um deren Einsatz wesentliches praktisches Wissen ist.

Jeder der **Kern-Typen** eignet sich für unterschiedliche Anforderungen: **Strings** (einfache Werte und atomare Zähler), **Listen** (geordnete Sammlungen für Queues, Stacks und Feeds mit neuesten Elementen), **Hashes** (Speicherung von Objekten/Datensätzen mit mehreren Feldern zusammen — effizient für Entitäten), **Sets** (eindeutige Sammlungen für Mitgliedschaftstests, Tags und Beziehungen mit Set-Operationen wie Intersection) und **Sorted Sets** (Elemente nach Score bewertet — das natürliche Mittel für Leaderboards, Rankings und Priority Queues).

Das Verständnis der **spezialisierten Typen** — Streams (Append-only Logs mit Consumer Groups für Message Queues und Event Sourcing), Bitmaps (kompakte Flags), HyperLogLog (ungefähre Zählung eindeutiger Elemente mit minimalem Speicher) und Geospatial (Standortabfragen) — erweitert die Möglichkeiten, was Redis effizient bewerkstelligen kann.

Am wichtigsten ist die **Wahl des richtigen Typs** für jeden Use-Case (ein Sorted Set für ein Leaderboard, ein Hash für ein Objekt, eine Liste für eine Queue), die Redis-Operationen effizient und natürlich macht — die Verwendung der falschen Struktur führt zu unbeholfen und langsamen Lösungen.

Da der Wert von Redis aus seinen Datenstrukturen kommt und deren angemessene Nutzung die Kernkompetenz im Umgang mit Redis ist, und da die Wahl der Struktur direkt darüber entscheidet, ob Operationen effizient sind und Code sauber ist, ist das Verständnis der Redis-Datentypen — der Kern-Typen und spezialisierten Typen und wann man jeden nutzt — essentielles, häufig angewendetes Wissen für jeden, der Redis nutzt, und die Grundlage, um Redis effektiv über triviale Schlüssel-Wert-Speicherung hinaus zu nutzen.