Jakie typy danych obsługuje Redis?

Question

Accepted Answer

Redis obsługuje kilka **struktur danych** jako wartości — stringi, listy, hashe, zbiory, zbiory posortowane, plus specjalistyczne typy (streams, bitmapy, HyperLogLog, dane geoprzestrzenne). Wybór odpowiedniego typu dla każdego przypadku użycia jest kluczowy do efektywnego wykorzystania Redisa.

## Podstawowe typy danych

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

## Specjalistyczne typy

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

## Wybór odpowiedniego typu

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

## Dlaczego to ważne

Zrozumienie typów danych Redisa jest fundamentalne dla efektywnego wykorzystania Redisa, ponieważ potęga Redisa pochodzi dokładnie z jego **bogatych struktur danych** (nie tylko prostego magazynu klucz-wartość), więc znanie ich i umiejętność wyboru odpowiedniego typu jest niezbędną praktyczną wiedzą.

**Typy podstawowe** każdy służy innym potrzebom: **stringi** (proste wartości i liczniki atomowe), **listy** (kolekcje uporządkowane do kolejek, stosów i kanałów ostatnich elementów), **hashe** (przechowywanie obiektów/rekordów z wieloma polami razem — efektywne dla encji), **zbiory** (unikalne kolekcje do testów członkowstwa, tagów i relacji, z operacjami zbiorowymi takimi jak przecięcie), oraz **zbiory posortowane** (elementy klasyfikowane według wyniku — naturalny wybór dla tabel wyników, rankingów i kolejek priorytetowych).

Zrozumienie **specjalistycznych typów** — streams (dzienniki tylko do dołączania z grupami konsumentów, do kolejek wiadomości i sourcing zdarzeń), bitmapy (kompaktowe flagi), HyperLogLog (przybliżone liczby unikalnych wartości w małej pamięci) oraz dane geoprzestrzenne (zapytania dotyczące lokalizacji) — rozszerza możliwości efektywnego wykonywania przez Redisa.

Najważniejsze, że **wybór odpowiedniego typu** dla każdego przypadku użycia (zbiór posortowany dla tabeli wyników, hasz dla obiektu, listę dla kolejki) jest tym, co sprawia, że operacje Redisa są efektywne i naturalne — użycie złej struktury prowadzi do niezgrabnych i wolnych rozwiązań.

Ponieważ wartość Redisa pochodzi z jego struktur danych i właściwe ich wykorzystywanie jest podstawową umiejętnością pracy z Redisem, a wybór struktury bezpośrednio określa, czy operacje są efektywne i kod jest czysty, zrozumienie typów danych Redisa — typów podstawowych i specjalistycznych oraz kiedy każdy z nich używać — jest niezbędną, często stosowaną wiedzą dla każdego korzystającego z Redisa, fundamentem do efektywnego wykorzystania Redisa poza trywialnym magazynem klucz-wartość.