write concern และ read concern ส่งผลต่อความสอดคล้องอย่างไร?

Question

Accepted Answer

**write concern** และ **read concern** ควบคุมการรับประกันความสอดคล้องและความทนทานใน MongoDB (ใน replica set) — แลกเปลี่ยนระหว่าง **ประสิทธิภาพ** กับ **ความปลอดภัย/ความสอดคล้อง** มันให้คุณปรับแต่งว่าการ write ถูกยืนยันแข็งแกร่งเพียงใดและการ read สอดคล้องเพียงใด ตามความต้องการของข้อมูล

## write concern — ความทนทานของการ write

```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** ควบคุมความทนทาน: `w: "majority"` รับประกันว่าการ write ถูก replicate ไปยังโหนดส่วนใหญ่ (รอดจาก failover โดยไม่สูญหาย) แต่ช้ากว่า; `w: 1` เร็วกว่าแต่การ write อาจสูญหายหาก primary ล้มเหลวก่อน replication

## read concern — ความสอดคล้องของการ read

```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** ควบคุมว่าการ read เห็นข้อมูลใด: `majority` คืนเฉพาะข้อมูลที่ majority-committed (จะไม่ถูก roll back — สอดคล้อง) เทียบกับ `local` (ข้อมูล local ล่าสุด อาจยังไม่ majority-committed)

## ข้อแลกเปลี่ยนระหว่างความสอดคล้องกับประสิทธิภาพ

```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 มีความสำคัญต่อ **การจัดการข้อแลกเปลี่ยนระหว่างความสอดคล้องกับประสิทธิภาพ** ใน replica set ของ MongoDB จึงเป็นความรู้ระดับ senior ที่มีคุณค่าสำหรับการสร้างแอปพลิเคชัน MongoDB แบบ distributed ที่ถูกต้องและปรับแต่งอย่างเหมาะสม

การตั้งค่าเหล่านี้ควบคุมการรับประกันความสอดคล้องและความทนทานของ MongoDB และการเข้าใจมันจำเป็นต่อการทำให้ข้อมูลถูกจัดการด้วยระดับความปลอดภัยที่เหมาะสมกับความสำคัญของมัน **write concern** สำคัญเป็นพิเศษต่อ **ความทนทาน**: `w: "majority"` รับประกันว่าการ write ถูก replicate ไปยังโหนดส่วนใหญ่ (รอดจาก failover ของ primary โดยไม่สูญเสียข้อมูล — วิกฤตสำหรับข้อมูลสำคัญเช่นการชำระเงินหรือคำสั่งซื้อ) ขณะที่ `w: 1` เร็วกว่าแต่เสี่ยงสูญเสียการ write หาก primary ล้มเหลวก่อน replication — เป็นข้อแลกเปลี่ยนที่มีผลตามมา ซึ่งหากเลือกผิดอาจหมายถึงการสูญเสียข้อมูลอย่างเงียบ ๆ ตอน failover **read concern** ควบคุม **ความสอดคล้องของการ read**: `majority` คืนเฉพาะข้อมูลที่ majority-committed (สอดคล้อง จะไม่ถูก roll back) เทียบกับ `local` (ข้อมูลล่าสุด อาจยังไม่ทนทานและอาจถูก roll back) — ส่งผลว่าการ read อาจเห็นข้อมูลที่ภายหลังหายไปหรือไม่

การเข้าใจ **ข้อแลกเปลี่ยน** — การรับประกันที่แข็งแกร่งกว่า (majority) ปลอดภัยและสอดคล้องกว่าแต่ช้ากว่า ขณะที่ที่อ่อนกว่าเร็วกว่าแต่เสี่ยงสูญเสียข้อมูลหรืออ่านข้อมูลที่ไม่สอดคล้อง — และการเลือกตามความวิกฤตของข้อมูล (แข็งแกร่งสำหรับข้อมูลสำคัญ, เร็วกว่าสำหรับที่สำคัญน้อยกว่า) คือวิจารณญาณสำคัญ

ที่เกี่ยวข้องเช่นกันคือการอ่านจาก secondary เพิ่มข้อพิจารณาเรื่อง eventual consistency (การอ่านที่ล้าหลัง)

เนื่องจากความสอดคล้องและความทนทานของข้อมูลวิกฤต (และระดับที่เหมาะสมขึ้นอยู่กับข้อมูล) และเนื่องจาก write/read concern เป็นวิธีปรับแต่งการรับประกันเหล่านี้เทียบกับประสิทธิภาพในสถาปัตยกรรม distributed (replica set) ของ MongoDB การเข้าใจมัน — ระดับความทนทาน/ความสอดคล้อง, ข้อแลกเปลี่ยนด้านประสิทธิภาพ และการเลือกอย่างเหมาะสม — จึงเป็นความรู้ระดับ senior ที่สำคัญสำหรับการสร้างแอปพลิเคชัน MongoDB แบบ distributed ที่ถูกต้อง เป็นหัวข้อที่แสดงถึงความเข้าใจในข้อแลกเปลี่ยนความสอดคล้องของ distributed system ที่สำคัญเป็นพิเศษสำหรับแอปพลิเคชันที่การสูญเสียข้อมูลหรือความไม่สอดคล้องจะมีต้นทุนสูง