Hogyan működnek a Redis hash-ek és set-ek?

Question

Accepted Answer

A **hash-ek** mezőérték-párokat tárolnak (mint egy objektum/rekord) egy kulcs alatt; a **set-ek** rendezetlen, egyedi karakterlánc-gyűjteményeket tárolnak gyors tagságvizsgálattal és halmazműveleti lehetőségekkel. Mindkettő fontos Redis-struktúra a gyakori adatmodellezési igényekhez.

## Hash-ek — objektumok/rekordok tárolása

```bash
# a hash groups multiple fields under one key (like an object)
HSET user:1 name "Ann" age 30 email "ann@x.com"
HGET user:1 name           # => "Ann" (one field)
HGETALL user:1             # => all fields and values
HMGET user:1 name age      # => multiple fields
HINCRBY user:1 age 1       # increment a numeric field atomically
HDEL user:1 email          # delete a field
HEXISTS user:1 name        # field exists? => 1
```

A hash-ek egy entitás mezőit együtt tárolják egy kulcs alatt — hatékonyabb és szervezett, mint külön kulcsok mezőnként (pl. felhasználó-objektum tárolása). A mezők egyedileg olvashatók/írhatók.

## Set-ek — egyedi gyűjtemények és tagságvizsgálat

```bash
SADD tags "redis" "cache" "db"   # add members (duplicates ignored — unique)
SISMEMBER tags "redis"           # is it a member? => 1 (fast O(1))
SMEMBERS tags                     # all members
SCARD tags                        # count of members
SREM tags "db"                    # remove a member
```

A set-ek **egyedi** értékeket tárolnak **gyors tagságvizsgálattal** (`SISMEMBER`) — ideális a címkékhez, egyedi elemek nyomon követéséhez és az "már láttam ezt?" ellenőrzésekhez.

## Halmazműveletek (kulcsfontosságú jellemző)

```bash
# set algebra across multiple sets
SADD user:1:follows "a" "b" "c"
SADD user:2:follows "b" "c" "d"
SINTER user:1:follows user:2:follows   # INTERSECTION => "b","c" (common follows)
SUNION user:1:follows user:2:follows   # UNION => all
SDIFF user:1:follows user:2:follows    # DIFFERENCE => "a" (only user:1 follows)
```

A **halmazműveletek** (metszet, unió, különbség) hatékonyan számítják ki az összefüggéseket — kiváló a "közös barátok", "közös címkék", javaslatok és hasonló célokhoz.

## Miért fontos

A hash-ek és set-ek fontos Redis-adatstruktúrák a gyakori modellezési igényekhez, így értékes, gyakran alkalmazott tudás megértésük. A **hash-ek** a **objektumok/rekordok** Redis-ben való tárolásának természetes módja — egy entitás mezőit (név, kor, e-mail) egy kulcs alatt csoportosítva, ahelyett, hogy szétszórnák azokat külön kulcsok között, ami hatékonyabb (egy kulcs, egyedileg elérhető mezők) és szervezett strukturált adatok, például felhasználói profilok vagy munkamenet-objektumok tárolásához; az egyes mezők olvasásának/írásának lehetősége és a numerikus mezők atomi növelése (`HINCRBY`) praktikussá teszi a hash-eket entitások tárolásához. A **set-ek** **egyedi gyűjteményeket biztosítanak gyors tagságvizsgálattal** — ideális a címkékhez, egyedi elemek nyomon követéséhez (egyedi látogatók, megtekintett elemek) és a "létezik-e ez?" ellenőrzésekhez (`SISMEMBER` O(1) időben) — ezek gyakori igények számos alkalmazásban.

Különösen erősek a **halmazműveletek** (metszet, unió, különbség), amelyek hatékonyan számítják ki a halmazok közötti összefüggéseket — olyan jellemzőket engedélyezve, mint a "közös barátok" (követési halmazok metszete), "közös érdeklődések" és ajánlások közvetlenül a Redis-ben, amelyeket máskülönben körülményes lenne kiszámítani.

Az ismerete, hogy mikor használjunk mindegyiket (hash-ek objektumok/rekordokhoz, set-ek egyedi gyűjteményekhez és összefüggés-számításokhoz) része a megfelelő Redis-struktúra kiválasztásának.

Mivel az objektumok tárolása és az egyedi gyűjtemények/összefüggések kezelése gyakori igény, és mivel a hash-ek (hatékony objektumtároláshoz) és a set-ek (egyedi gyűjteményekhez, gyors tagsághoz és erős halmazműveleti lehetőségekhez) természetes módon oldják meg ezeket, a Redis hash-ek és set-ek megértése értékes, gyakorlatban használható tudás az adatok hatékony Redis-ben való modellezéséhez, kettő az alapvető adatstruktúrák közül, amelyek a Redis-t a sima kulcs-érték tárolón túl sokoldalúvá teszik.