Jak funguje perzistence v Redisu (RDB vs AOF)?

Question

Accepted Answer

Ačkoli je Redis in-memory, může **uchovávat data na disku**, aby data přežila restartování. Nabízí dva mechanismy — **RDB** (snímky v určitém čase) a **AOF** (append-only log operací) — s různými kompromisy mezi trvanlivostí a výkonem.

## RDB — snímky v určitém čase

```text
RDB takes SNAPSHOTS of the dataset at intervals, saving a compact binary file.
  ✓ Compact single-file backups; fast restarts (load the snapshot)
  ✓ Good for backups and disaster recovery; less impact on performance
  ✗ You can LOSE data since the last snapshot (e.g. last few minutes) if Redis crashes
→ Configure save points: e.g. "save after 900s if ≥1 change, 300s if ≥10 changes"
```

RDB pravidelně ukládá celý dataset do kompaktního souboru — efektivní a skvělé pro zálohy, ale havárie ztratí změny provedené od poslední snímku.

## AOF — append-only log

```text
AOF logs EVERY write operation to a file; on restart, Redis replays the log to rebuild data.
  ✓ More DURABLE — less data loss (can fsync every second, or every write)
  ✓ The log can be rewritten/compacted to stay manageable
  ✗ Larger files; can be slower than RDB; restart (replay) can be slower
→ fsync policies: always (safest, slowest), everysec (good balance), no (fastest, riskiest)
```

AOF zapisuje každý zápis a přehrává jej při restartu pro obnovení dat — více trvanlivý (menší ztráta dat), ale s většími soubory a potenciálně pomalejším výkonem/restarty.

## RDB vs AOF — kompromis

```text
RDB → better performance, compact backups, faster restart, BUT more potential data loss
AOF → better durability (minimal data loss), BUT larger files, slower

BEST PRACTICE: use BOTH together → RDB for backups + AOF for durability
  → Redis can use both; AOF for recovery, RDB for snapshots/backups
OR: pure cache use → you may DISABLE persistence entirely (data is recreatable)
```

## Proč je to důležité

Porozumění perzistenci Redisu je důležité pro **zajištění trvanlivosti dat** vhodným způsobem, když Redis drží data, která jsou důležitá, takže je to cenné znalosti pro správné používání Redisu.

Ačkoli je Redis primárně in-memory, skutečnost, že **může uchovávat data na disku** (aby data přežila restarty a havárie), je důležité pochopit, spolu se dvěma mechanismy a jejich kompromisy. **RDB** (snímky v určitém čase) nabízí kompaktní zálohy, rychlé starty a nízký dopad na výkon, ale riskuje **ztrátu dat od poslední snímku** v případě havárie — vhodné pro zálohy a přijatelné, když je určitá ztráta dat tolerovatelná. **AOF** (záznamy každé operace zápisu, přehrávané při startu) nabízí **lepší trvanlivost** (minimální ztráta dat, konfigurabilní přes fsync zásady), ale s většími soubory a potenciálně pomalejším výkonem/starty.

Porozumění **kompromisu** (RDB pro výkon a kompaktní zálohy vs AOF pro trvanlivost) a běžné **best practice používání obojího dohromady** (RDB pro snímky/zálohy plus AOF pro trvanlivost) odráží zdravý úsudek při konfiguraci.

Důležité je také rozpoznat, že pro **čistě cachingové** použití (kde jsou data obnovitelná ze zdroje), lze perzistenci úplně zakázat — Redis nemusí mít trvanlivost.

Volba správné konfiguraci perzistence na základě use case (potřeba trvanlivosti vs výkon, nebo žádná pro čisté cachování) je klíčová praktická dovednost.

Keďže trvanlivost dat záleží, když Redis drží důležitá data (relace, fronty, primární data), a protože pochopení RDB, AOF, jejich kompromisů a best practices (oba dohromady, nebo žádný pro cachování) je nezbytné pro vhodnou konfiguraci Redisu, je pochopení perzistence Redisu cenné, prakticky relevantní znalosti pro odpovědné používání Redisu — zajištění správné úrovně trvanlivosti pro data, která Redis drží, téma, které odráží porozumění Redisu mimo jednoduché cachování.