Jak write concern i read concern wpływają na spójność danych?

Question

Accepted Answer

**Write concern** i **read concern** kontrolują gwarancje spójności i trwałości w MongoDB (w replikach) — balansując między **wydajnością** a **bezpieczeństwem/spójnością**. Pozwalają na dostrojenie, jak silnie potwierdzone są zapisy i jak spójne są odczyty, na podstawie wymagań danych.

## Write concern — trwałość zapisów

```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** kontroluje trwałość: `w: "majority"` zapewnia, że zapis jest zreplikowany na większość (przetrwa przełączenie failover bez straty), ale jest wolniejszy; `w: 1` jest szybszy, ale zapis może być utracony, jeśli primary padnie przed replikacją.

## Read concern — spójność odczytów

```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** kontroluje, jakie dane widzi odczyt: `majority` zwraca tylko dane zatwierdzone przez większość (nie zostaną wycofane — spójne), wobec `local` (najnowsze dane lokalne, ewentualnie nie zatwierdzone jeszcze przez większość).

## Balans między spójnością a wydajnością

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

## Dlaczego to ważne

Zrozumienie write concern i read concern jest ważne dla **zarządzania balansem między spójnością a wydajnością** w replikach MongoDB, dlatego jest to cenna wiedza na poziomie senior dla budowania poprawnych, odpowiednio strojonych rozproszonych aplikacji MongoDB.

Te ustawienia kontrolują gwarancje spójności i trwałości MongoDB, i zrozumienie ich jest niezbędne, aby zapewnić, że dane są obsługiwane z odpowiednim poziomem bezpieczeństwa dla ich znaczenia. **Write concern** jest szczególnie ważny dla **trwałości**: `w: "majority"` zapewnia, że zapis jest zreplikowany na większość węzłów (przetrwa failover primary bez utraty danych — krytyczne dla ważnych danych, takich jak płatności czy zamówienia), podczas gdy `w: 1` jest szybszy, ale ryzykuje utratę zapisu, jeśli primary padnie przed replikacją — znaczący balans, w którym zły wybór może oznaczać cichą utratę danych podczas failover. **Read concern** kontroluje **spójność odczytów**: `majority` zwraca tylko dane zatwierdzone przez większość (spójne, nie zostaną wycofane) wobec `local` (najnowsze dane, ewentualnie nie zatwierdzone jeszcze i podlegające wycofaniu) — wpływając na to, czy odczyty mogą zobaczyć dane, które później znikną.

Zrozumienie **balansu** — silniejsze gwarancje (majority) są bezpieczniejsze i spójniejsze, ale wolniejsze, podczas gdy słabsze są szybsze, ale ryzykują utratę danych lub niespójne odczyty — i wybór na podstawie krytyczności danych (silny dla ważnych danych, szybszy dla mniej krytycznych) jest kluczową oceną.

Istotny jest również fakt, że odczyt z replik secondaries wprowadza rozważania ostatecznej spójności (nieświeże odczyty).

Ponieważ spójność i trwałość danych są krytyczne (i odpowiedni poziom zależy od danych), a ponieważ write/read concern to sposób, w jaki dostrajasz te gwarancje wobec wydajności w rozproszonej architekturze (replik) MongoDB, zrozumienie ich — poziomów trwałości/spójności, balansu wydajności i odpowiedni wybór — jest ważną wiedzą na poziomie senior dla budowania poprawnych rozproszonych aplikacji MongoDB, temat demonstrujący zrozumienie kompromisów spójności w systemach rozproszonych, który jest szczególnie ważny dla aplikacji, w których utrata danych lub niespójność byłaby kosztowna.