Kako se write concern i read concern utječu na konzistentnost?

Question

Kako se write concern i read concern utječu na konzistentnost?

Accepted Answer

**Write concern** i **read concern** kontroliraju konzistentnost i trajnost garancija u MongoDB-u (u replica setovima) — nudeći kompromis između **performansi** i **sigurnosti/konzistentnosti**. Omogućuju vam da prilagodite kako su snažno potvrđena pisanja i kako konzistentna čitanja su, na temelju potreba podataka.

## Write concern — trajnost pisanja

```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** kontrolira trajnost: `w: "majority"` osigurava da je pisanje repliciran na većinu (preživjet će failover bez gubitka), ali je sporije; `w: 1` je brže, ali se pisanje moglo izgubiti ako primarni čvor padne prije replikacije.

## Read concern — konzistentnost čitanja

```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** kontrolira koje podatke čitanja vide: `majority` vraća samo podatke potvrdene od većine (neće biti vraćeni — konzistentni), naspram `local` (najnoviji lokalni podaci, mogućno još ne potvrđeni od većine).

## Kompromis između konzistentnosti i performansi

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

## Zašto je važno

Razumijevanje write concern i read concern važno je za **upravljanje kompromisom konzistentnosti-vs-performansi** u MongoDB replica setovima, stoga je dragocjeno znanje za stariju razinu za gradnju ispravnih, pravilno podešenih distribuiranih MongoDB aplikacija.

Ove postavke kontroliraju konzistentnost i trajnost MongoDB-a, te je razumijevanje neophodno za osiguranje da se podaci rabe s pravom razinom sigurnosti za njihovu važnost. **Write concern** je posebno važan za **trajnost**: `w: "majority"` osigurava da je pisanje repliciran na većinu čvorova (preživjeti će failover primarnog bez gubitka podataka — kritično za važne podatke poput plaćanja ili narudžbi), dok je `w: 1` brži, ali riskirate gubitak pisanja ako primarni padne prije replikacije — značajan kompromis gdje krivi izbor mogao bi značiti tiho gubljenje podataka pri failoveru. **Read concern** kontrolira **konzistentnost čitanja**: `majority` vraća samo podatke potvrdene od većine (konzistentni, neće biti vraćeni) naspram `local` (najnoviji podaci, mogućno još nisu trajni i podložni su vraćanju) — utječući na to mogu li čitanja vidjeti podatke koji kasnije nestanu.

Razumijevanje **kompromisa** — jače garancije (majority) su sigurnije i konzistentnije, ali sporije, dok slabije su brže, ali riskiraju gubitak podataka ili nekonzistentna čitanja — i izbor na temelju kritičnosti podataka (snažan za važne podatke, brži za manje kritične) je ključan odsudak.

Također relevantno je čitanje sa sekundarnih čvorova što dodaje razmatranja konačne konzistentnosti (zastarjela čitanja).

Budući da su konzistentnost i trajnost podataka kritični (i prava razina ovisi o podacima), te budući da su write/read concern načini na koje prilagođavate ove garancije prema performansama u MongoDB-ovoj distribuiranoj (replica set) arhitekturi, razumijevanje — nivoi trajnosti/konzistentnosti, kompromis performansi, i pravilnog izbora — je važno znanje starije razine za gradnju ispravnih distribuiranih MongoDB aplikacija, tema koja pokazuje razumijevanje kompromisa konzistentnosti distribuiranih sustava koja je posebno važna za aplikacije gdje bi gubitak ili nekonzistentnost podataka bili skupi.