كيف يعمل التجزئة (Sharding) في MongoDB؟

Question

Accepted Answer

**التجزئة (Sharding)** هي طريقة MongoDB للتوسع **الأفقي** — توزيع البيانات عبر خوادم متعددة (**shards**) بحيث تستطيع قاعدة البيانات التعامل مع مجموعات بيانات وإنتاجية تتجاوز ما يمكن لخادم واحد القيام به. تقسم البيانات بناءً على **shard key**، مع توجيه MongoDB للاستعلامات إلى الـ shards الصحيحة.

## لماذا التجزئة: توسع يتجاوز خادم واحد

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

## كيف تعمل التجزئة

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

## الاستعلامات الموجهة مقابل scatter-gather

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

## لماذا يهم

التجزئة معرفة مهمة **لتوسيع MongoDB إلى مجموعات بيانات ضخمة جداً وإنتاجية عالية**، لذا فهم هذا المفهوم يعتبر معرفة قيمة على مستوى كبار المهندسين في نشرات MongoDB الكبيرة الحجم.

القيمة الأساسية هي **التوسع الأفقي**: عندما تتجاوز البيانات أو الحمل ما يمكن لخادم واحد التعامل معه، تقوم التجزئة بتوزيع البيانات عبر عدة shards، مما يوسع القدرة بشكل أفقي للتعامل مع مجموعات بيانات ضخمة وإنتاجية كتابة عالية لا يستطيع التوسع الرأسي (خادم أكبر) تحقيقها — وهي قدرة أساسية للأنظمة واسعة النطاق.

فهم **البنية المعمارية** (كل shard يحتوي على مجموعة فرعية من البيانات، موجه الاستعلامات `mongos` الذي يوجه الاستعلامات، خوادم التكوين التي تخزن البيانات الوصفية) أمر أساسي.

الأهم بكثير، فهم **shard key** — الحقل أو الحقول التي تحدد توزيع البيانات — ضروري لأن **هذا هو القرار الأكثر أهمية والأصعب في التغيير في التجزئة**: إن shard key جيد (عالي الأساسية، توزيع متساوٍ، متوافق مع نمط الاستعلام) يوزع البيانات والحمل بالتساوي ويمكّن من الاستعلامات الموجهة، بينما shard key سيء يسبب نقاط ساخنة (حمل غير متساوٍ)، استعلامات scatter-gather (تضرب جميع الـ shards، بطيء)، وتوسع ضعيف.

فهم **الاستعلامات الموجهة مقابل scatter-gather** (الاستعلامات التي تتضمن shard key توجه إلى shards معينة بكفاءة؛ تلك بدونه تضرب جميع الـ shards) يعزز تصميم shard key حول أنماط الاستعلام.

بما أن التوسع إلى بيانات ضخمة جداً يشكل تحدياً حقيقياً للتطبيقات سريعة النمو، وبما أن التجزئة (آلية التوسع الأفقي في MongoDB) تتطلب فهماً دقيقاً — خاصة قرار shard key الحرج والصعب التغيير وتأثيره على التوزيع وكفاءة الاستعلام — فإن فهم التجزئة يعتبر معرفة مهمة على مستوى كبار المهندسين لتوسيع MongoDB، وهو موضوع يظهر فهماً للتوسع الأفقي لقواعد البيانات والمجال الذي يعكس خبرة MongoDB العميقة والحاسمة بشكل خاص في قرار shard key، والذي يتوقع له من أولئك الذين يتولون أدواراً كبيرة في الأنظمة واسعة النطاق.