sharding ทำงานอย่างไรใน MongoDB?

Question

Accepted Answer

**sharding** คือวิธีการ **horizontal scaling** ของ MongoDB — กระจายข้อมูลไปยังหลายเซิร์ฟเวอร์ (**shard**) เพื่อให้ฐานข้อมูลสามารถจัดการชุดข้อมูลและ throughput ที่เกินกว่าเซิร์ฟเวอร์เดี่ยวจะรับไหว มันแบ่งข้อมูลด้วย **shard key** โดย MongoDB จะ route query ไปยัง shard ที่ถูกต้อง

## ทำไมต้อง shard: scale เกินกว่าเซิร์ฟเวอร์เดียว

```text
A single server has limits (storage, RAM, write throughput). When data/load exceeds
what one server (even a powerful one) can handle, SHARDING distributes it:
  → data is split across multiple SHARDS (each a replica set)
  → each shard holds a SUBSET of the data → combined capacity scales horizontally
  → handles huge datasets and high write throughput
```

## sharding ทำงานอย่างไร

```text
The sharded cluster has three parts:
  SHARDS    → each holds a portion of the data (each shard is itself a replica set)
  mongos    → query ROUTER — apps connect here; it routes queries to the right shard(s)
  CONFIG SERVERS → store metadata (which data is on which shard)

Data is partitioned by the SHARD KEY into CHUNKS, distributed across shards.
MongoDB balances chunks across shards automatically.
```

## shard key — การตัดสินใจที่สำคัญที่สุด

```js
sh.shardCollection("mydb.orders", { customerId: 1 });   // shard by customerId
```

```text
The SHARD KEY determines how data is distributed — choosing it well is CRITICAL:
  ✓ HIGH CARDINALITY (many distinct values) → data spreads evenly
  ✓ EVEN DISTRIBUTION of reads/writes → no hot shards
  ✓ Queries include the shard key → routed to ONE shard (targeted, fast)
  ✗ A BAD shard key → uneven distribution (hotspots), or queries hitting ALL shards
    (scatter-gather, slow) → poor scaling. Hard to change later!
Strategies: ranged sharding, HASHED sharding (even distribution), zoned sharding.
```

## targeted กับ scatter-gather query

```text
Query INCLUDES the shard key → routed to the specific shard(s) → fast (targeted)
Query WITHOUT the shard key → must query ALL shards (scatter-gather) → slower
→ Design the shard key around your common query patterns.
```

## ทำไมจึงสำคัญ

sharding เป็นความรู้ที่สำคัญสำหรับ **การ scale MongoDB ไปสู่ชุดข้อมูลขนาดใหญ่มากและ throughput สูง** ดังนั้นการเข้าใจมันจึงเป็นความรู้ระดับ senior ที่มีคุณค่าสำหรับการ deploy MongoDB ขนาดใหญ่

คุณค่าหลักคือ **horizontal scaling**: เมื่อข้อมูลหรือโหลดเกินกว่าเซิร์ฟเวอร์เดี่ยวจะรับไหว sharding จะกระจายข้อมูลไปยังหลาย shard scale ความจุในแนวนอนเพื่อจัดการชุดข้อมูลขนาดใหญ่และ throughput การ write สูงที่ vertical scaling (เซิร์ฟเวอร์ที่ใหญ่ขึ้น) ไม่อาจไปถึง — เป็นความสามารถสำคัญสำหรับระบบขนาดใหญ่

การเข้าใจ **สถาปัตยกรรม** (shard แต่ละตัวเก็บข้อมูลส่วนหนึ่ง, query router `mongos` ที่นำทาง query, config server ที่เก็บ metadata) เป็นพื้นฐาน

ที่สำคัญที่สุด การเข้าใจ **shard key** — ฟิลด์ที่กำหนดการกระจายข้อมูล — เป็นสิ่งจำเป็นเพราะ **มันเป็นการตัดสินใจ sharding ที่ส่งผลมากที่สุดและเปลี่ยนยากที่สุด**: shard key ที่ดี (cardinality สูง, กระจายสม่ำเสมอ, สอดคล้องกับรูปแบบ query) จะกระจายข้อมูลและโหลดอย่างสม่ำเสมอและเปิดให้ทำ targeted query ได้ ขณะที่ตัวที่ไม่ดีจะทำให้เกิด hotspot (โหลดไม่สม่ำเสมอ), scatter-gather query (กระทบทุก shard, ช้า) และการ scale ที่ไม่ดี

การเข้าใจ **targeted กับ scatter-gather query** (query ที่มี shard key จะ route ไปยัง shard เฉพาะอย่างมีประสิทธิภาพ; ที่ไม่มีจะกระทบทุก shard) ตอกย้ำการออกแบบ shard key รอบ ๆ รูปแบบ query

เนื่องจากการ scale ไปสู่ข้อมูลขนาดใหญ่มากเป็นความท้าทายจริงสำหรับแอปพลิเคชันที่เติบโตสูง และเนื่องจาก sharding (กลไก horizontal scaling ของ MongoDB) ต้องการความเข้าใจอย่างรอบคอบ — โดยเฉพาะการตัดสินใจ shard key ที่สำคัญและเปลี่ยนยากและผลกระทบต่อการกระจายและประสิทธิภาพ query — การเข้าใจ sharding จึงเป็นความรู้ระดับ senior ที่สำคัญสำหรับการ scale MongoDB เป็นหัวข้อที่แสดงถึงความเข้าใจในการ scale ฐานข้อมูลแนวนอน และเป็นจุดที่การตัดสินใจ shard key สะท้อนถึงความเชี่ยวชาญในการ scale MongoDB ที่ลึกซึ้งและมีผลตามมา ซึ่งคาดหวังสำหรับตำแหน่ง senior ที่จัดการระบบขนาดใหญ่