write concern और read concern consistency को कैसे प्रभावित करते हैं?

Question

Accepted Answer

**Write concern** और **read concern** MongoDB में (replica sets में) consistency और durability गारंटी को नियंत्रित करते हैं — **performance** और **safety/consistency** के बीच trade-off करते हुए। वे आपको data की जरूरतों के आधार पर tune करने देते हैं कि writes कितनी मजबूती से confirm किए जाते हैं और reads कितने consistent हैं।

## Write concern — writes की durability

```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** durability को नियंत्रित करता है: `w: "majority"` यह सुनिश्चित करता है कि write एक majority में replicate हो (failover को बिना loss के झेलना) लेकिन धीमा है; `w: 1` तेज़ है लेकिन यदि primary replication से पहले विफल हो जाए तो एक write खो सकता है।

## Read concern — reads की consistency

```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** नियंत्रित करता है कि reads क्या देखते हैं: `majority` केवल majority-committed data लौटाता है (rolled back नहीं होगा — consistent), बनाम `local` (नवीनतम local data, संभवतः अभी तक majority-committed नहीं)।

## Consistency बनाम performance trade-off

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

## यह क्यों महत्वपूर्ण है

Write concern और read concern को समझना MongoDB replica sets में **consistency-बनाम-performance trade-off को प्रबंधित करने** के लिए महत्वपूर्ण है, इसलिए यह सही, उपयुक्त रूप से tuned distributed MongoDB applications बनाने के लिए मूल्यवान senior-स्तरीय ज्ञान है।

ये settings MongoDB की consistency और durability गारंटी को नियंत्रित करती हैं, और इन्हें समझना यह सुनिश्चित करने के लिए आवश्यक है कि data को इसके महत्व के लिए सही स्तर की सुरक्षा के साथ संभाला जाए। **Write concern** विशेष रूप से **durability** के लिए महत्वपूर्ण है: `w: "majority"` यह सुनिश्चित करता है कि एक write majority nodes में replicate हो (primary failover को data loss के बिना झेलना — payments या orders जैसे महत्वपूर्ण data के लिए महत्वपूर्ण), जबकि `w: 1` तेज़ है लेकिन यदि primary replication से पहले विफल हो जाए तो एक write खोने का जोखिम है — एक परिणामकारी trade-off जहाँ गलत चुनना failover पर silent data loss का अर्थ हो सकता है। **Read concern** **read consistency** को नियंत्रित करता है: `majority` केवल majority-committed data लौटाता है (consistent, rolled back नहीं होगा) बनाम `local` (नवीनतम data, संभवतः अभी तक durable नहीं और rollback के अधीन) — यह प्रभावित करता है कि reads ऐसा data देख सकते हैं जो बाद में गायब हो जाए।

**Trade-off** को समझना — मजबूत गारंटी (majority) अधिक सुरक्षित और अधिक consistent है लेकिन धीमी, जबकि कमजोर तेज़ हैं लेकिन data loss या असंगत reads का जोखिम रखती हैं — और data की महत्वता के आधार पर चुनना (महत्वपूर्ण data के लिए मजबूत, कम महत्वपूर्ण के लिए तेज़) प्रमुख निर्णय है।

यह भी प्रासंगिक है कि secondaries से reading eventual-consistency विचार जोड़ती है (stale reads)।

चूँकि data consistency और durability महत्वपूर्ण हैं (और सही स्तर data पर निर्भर करता है), और चूँकि write/read concern MongoDB की distributed (replica set) architecture में performance के विरुद्ध इन गारंटियों को tune करने का तरीका हैं, इन्हें समझना — durability/consistency स्तर, performance trade-off, और उपयुक्त रूप से चुनना — सही distributed MongoDB applications बनाने के लिए महत्वपूर्ण senior-स्तरीय ज्ञान है, distributed-systems consistency trade-offs की समझ को दर्शाने वाला एक विषय जो विशेष रूप से उन applications के लिए महत्वपूर्ण है जहाँ data loss या inconsistency महँगी होगी।