ライトコンサーンとリードコンサーンはどのように一貫性に影響するのか？

Question

IT Interview Practice · Accepted Answer

**ライトコンサーン**と**リードコンサーン**は、MongoDB（レプリカセット内）の一貫性と耐久性の保証を制御します。**パフォーマンス**と**安全性・一貫性**の間でトレードオフを行い、書き込みがどの程度確認されるのか、またリードがどの程度一貫性を持つのかを、データのニーズに基づいてチューニングできます。

## ライトコンサーン — 書き込みの耐久性

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

**ライトコンサーン**は耐久性を制御します。`w: "majority"` は書き込みがマジョリティにレプリケートされることを保証し（フェイルオーバーで損失なく生き残ります）ただし遅くなります。一方、`w: 1` は高速ですが、プライマリがレプリケーション前に障害になると書き込みが失われる可能性があります。

## リードコンサーン — 読み取りの一貫性

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

**リードコンサーン**はリードが見るデータを制御します。`majority` はマジョリティがコミットしたデータのみを返します（ロールバックされません — 一貫性があります）。一方、`local` は最新のローカルデータを返します（おそらくまだマジョリティーコミットされていない可能性があります）。

## 一貫性対パフォーマンスのトレードオフ

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

## なぜ重要なのか

ライトコンサーンとリードコンサーンを理解することは、MongoDB レプリカセットにおける**一貫性対パフォーマンスのトレードオフを管理する**ために重要であり、正しく適切にチューニングされた分散 MongoDB アプリケーションを構築するためのシニアレベルの知識として価値があります。

これらの設定は MongoDB の一貫性と耐久性の保証を制御し、データがその重要性に応じた適切なレベルの安全性で処理されることを保証するために不可欠です。**ライトコンサーン**は特に**耐久性**に重要です。`w: "majority"` は書き込みがノードのマジョリティにレプリケートされることを保証します（プライマリフェイルオーバーでもデータ損失なく生き残ります — 支払いや注文のような重要なデータにとって極めて重要です）。一方、`w: 1` は高速ですがプライマリがレプリケーション前に障害になると書き込みが失われるリスクがあります — 選択を誤ると無言のデータ損失につながる可能性のある重大なトレードオフです。**リードコンサーン**は**読み取りの一貫性**を制御します。`majority` はマジョリティがコミットしたデータのみを返します（一貫性があり、ロールバックされません）。一方、`local` は最新のデータを返します（おそらくまだ耐久的ではなく、ロールバック対象の可能性があります）。これは、リードが後で消えるかもしれないデータを見る可能性があるかどうかに影響します。

トレードオフを理解すること — より強い保証（マジョリティ）はより安全で一貫性がありますが遅い、弱い保証はより高速だがデータ損失のリスクや不整合なリードのリスクがある — およびデータの重要性に基づいて選択すること（重要なデータには強い保証、あまり重要でないデータには高速な設定）が重要な判断です。

セカンダリから読み取ることは最終的な一貫性の考慮（遅延リード）も関連があります。

データの一貫性と耐久性は重大な問題である（そして適切なレベルはデータに依存する）ため、またライト・リードコンサーンは MongoDB の分散（レプリカセット）アーキテクチャにおけるこれらの保証をパフォーマンスに対してチューニングする方法であるため、それらを理解すること — 耐久性・一貫性レベル、パフォーマンストレードオフ、適切な選択 — は正しい分散 MongoDB アプリケーションを構築するためのシニアレベルの重要な知識です。これは、データ損失や不整合が高くつくアプリケーションに特に重要な、分散システムの一貫性トレードオフについての理解を示しているトピックです。

ライトコンサーン — 書き込みの耐久性

リードコンサーン — 読み取りの一貫性

一貫性対パフォーマンスのトレードオフ

なぜ重要なのか

関連する質問