Jak se write concern a read concern podílejí na konzistenci dat?

Question

Accepted Answer

**Write concern** a **read concern** řídí záruky konzistence a trvanlivosti v MongoDB (v replica setech) — vytvářejí kompromis mezi **výkonem** a **bezpečností/konzistencí**. Umožňují vám nastavit, jak silně se zápisy potvrzují a jak konzistentní jsou čtení, na základě potřeb dat.

## Write concern — trvanlivost zápisů

```js
// write concern: how many nodes must acknowledge a write
db.orders.insertOne(doc, { writeConcern: { w: 1 } });           // primary only — fast
db.orders.insertOne(doc, { writeConcern: { w: "majority" } });   // majority of nodes — safe
db.orders.insertOne(doc, { writeConcern: { w: "majority", j: true } }); // + journaled to disk
```

```text
w: 1          → only the PRIMARY acknowledges (fast, but a write could be LOST on failover)
w: "majority" → a majority of nodes acknowledge → the write SURVIVES primary failover
               (no data loss) — safer but slower (waits for replication)
j: true       → also wait for the write to be written to the JOURNAL (disk durability)
```

**Write concern** řídí trvanlivost: `w: "majority"` zajišťuje, že zápis je replikován na majoritu (přežití selhání bez ztráty), ale je pomalejší; `w: 1` je rychlejší, ale zápis by mohl být ztracen, pokud se primární uzel selže před replikací.

## Read concern — konzistentnost čtení

```js
db.orders.find().readConcern("majority");   // read data acknowledged by a majority
```

```text
local        → returns the most recent data on the node (may not be majority-committed,
               could be rolled back) — default, fast
majority     → returns only data acknowledged by a majority (won't be rolled back) — consistent
linearizable → strongest (reflects all prior majority writes) — slowest
```

**Read concern** řídí, jaká data čtení vidí: `majority` vrací pouze data potvrzená majoritou (nebudou vrácena — konzistentní), oproti `local` (nejnovější lokální data, možná ještě nepotvrzená majoritou).

## Kompromis mezi konzistencí a výkonem

```text
Stronger guarantees (w: majority, readConcern: majority) → safer, consistent, but SLOWER
Weaker guarantees (w: 1, readConcern: local) → faster, but risk of data loss on failover
  or reading not-yet-durable data
→ Choose based on the data: critical data (payments) → strong; less critical → faster.
→ Reading from secondaries adds eventual-consistency considerations (stale reads).
```

## Proč na tom záleží

Pochopení write concern a read concern je důležité pro **správu kompromisu mezi konzistencí a výkonem** v MongoDB replica setech, takže je to cenná znalost na senior level pro budování správných a vhodně laděných distribuovaných MongoDB aplikací.

Tato nastavení řídí záruky konzistence a trvanlivosti MongoDB a jejich pochopení je nezbytné pro zajištění, že data jsou zpracována s vhodnou úrovní bezpečnosti pro jejich důležitost. **Write concern** je obzvláště důležitý pro **trvanlivost**: `w: "majority"` zajišťuje, že zápis je replikován na majoritu uzlů (přežití selhání primáru bez ztráty dat — kritické pro důležitá data jako platby nebo objednávky), zatímco `w: 1` je rychlejší, ale riskuje ztrátu zápisu, pokud se primární uzel selže před replikací — významný kompromis, kde špatná volba by mohla znamenat tiché ztracení dat při selhání. **Read concern** řídí **konzistentnost čtení**: `majority` vrací pouze data potvrzená majoritou (konzistentní, nebudou vrácena) oproti `local` (nejnovější data, možná ještě nově a podléhající vrácení) — ovlivňující, zda čtení může vidět data, která později zmizí.

Pochopení **kompromisu** — silnější záruky (majority) jsou bezpečnější a konzistentnější, ale pomalejší, zatímco slabší jsou rychlejší, ale riskují ztrátu dat nebo nekonzistentní čtení — a volba na základě kritičnosti dat (silná pro důležitá data, rychlejší pro méně kritická) je klíčový úsudek.

Také relevantní je, že čtení ze sekundárních uzlů přidává úvahy o konečné konzistenci (zastaralá čtení).

Protože konzistentnost a trvanlivost dat jsou kritické (a správná úroveň závisí na datech) a protože write/read concern jsou způsob, jak v MongoDB ladit tyto záruky proti výkonu v distribuované architektuře (replica set), jejich pochopení — úrovně trvanlivosti/konzistence, kompromis výkonu a vhodná volba — je důležitá znalost na senior level pro budování správných distribuovaných MongoDB aplikací, téma demonstrující pochopení kompromisů konzistence v distribuovaných systémech, která je obzvláště důležitá pro aplikace, kde by ztráta dat nebo nekonzistentnost byla nákladná.