MongoDB میں sharding کیسے کام کرتی ہے؟

Question

Accepted Answer

**Sharding** MongoDB کا **افقی توسیع** کا طریقہ ہے — ڈیٹا کو متعدد سرورز (**shards**) میں تقسیم کرنا تاکہ ڈیٹابیس اتنے بڑے ڈیٹاسیٹس اور throughput کو سنبھال سکے جو ایک واحد سرور سے زیادہ ہو۔ یہ ڈیٹا کو **shard key** کے ذریعے تقسیم کرتا ہے، اور MongoDB queries کو صحیح shards کی طرف روٹ کرتا ہے۔

## Shard کرنے کی وجہ: ایک سرور سے آگے توسیع

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

```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 اہم علم ہے **MongoDB کو بہت بڑے ڈیٹاسیٹس اور اعلیٰ throughput تک پہنچانے کے لیے**، اس لیے اسے سمجھنا بڑے پیمانے پر MongoDB deployments کے لیے قابل قدر سینئر لیول کا علم ہے۔

بنیادی قدر **افقی توسیع** ہے: جب ڈیٹا یا load ایک سرور کی صلاحیت سے تجاوز کر جائے، تو sharding ڈیٹا کو متعدد shards میں تقسیم کرتا ہے، صلاحیت کو افقی طور پر پھیلاتا ہے تاکہ بہت بڑے ڈیٹاسیٹس اور اعلیٰ write throughput کو سنبھالا جا سکے جو عمودی توسیع (بڑا سرور) حاصل نہیں کر سکتا — یہ بڑے پیمانے پر سسٹمز کی کلیدی صلاحیت ہے۔

**Architecture** کو سمجھنا (ہر shard ڈیٹا کا ایک حصہ رکھتا ہے، `mongos` query router queries کو براہ راست کرتا ہے، config servers metadata ذخیرہ کرتے ہیں) بنیادی ہے۔

سب سے اہم بات، **shard key** کو سمجھنا — وہ field(s) جو ڈیٹا کی تقسیم کا تعین کرتے ہیں — ضروری ہے کیونکہ **یہ شarding کا سب سے اہم اور تبدیل کرنے میں مشکل فیصلہ ہے**: ایک اچھی shard key (اعلیٰ cardinality، یکساں تقسیم، query patterns کے ساتھ ہم آہنگ) ڈیٹا اور load کو یکساں طور پر پھیلاتی ہے اور targeted queries کو فعال بناتی ہے، جبکہ ایک خراب key hotspots (غیر یکساں load)، scatter-gather queries (تمام shards کو ہٹانا، سست)، اور ناقص توسیع کا سبب بنتی ہے۔

**Targeted بمقابلہ scatter-gather queries** کو سمجھنا (queries جو shard key شامل ہوں وہ مخصوص shards کو موثر طریقے سے روٹ کرتے ہیں؛ بغیر والے تمام shards کو ہٹاتے ہیں) shard key کو query patterns کے گرد ڈیزائن کرنے کی اہمیت کو ظاہر کرتا ہے۔

چونکہ بہت بڑے ڈیٹا تک پہنچنا تیزی سے بڑھنے والی ایپلیکیشنز کے لیے ایک حقیقی چیلنج ہے، اور چونکہ sharding (MongoDB کا افقی توسیع کا طریقہ) احتیاط سے سمجھنے کی ضرورت ہے — خاص طور پر اہم، تبدیل کرنے میں مشکل shard key فیصلہ اور اس کا تقسیم اور query کی کارکردگی پر اثر — sharding کو سمجھنا MongoDB کو پیمانہ کرنے کے لیے اہم سینئر لیول کا علم ہے، یہ افقی ڈیٹابیس کی توسیع کی سمجھ کو ظاہر کرنے والا موضوع ہے اور ایک ایسا موضوع ہے جہاں shard-key کا فیصلہ خاص طور پر سینئر کردار میں توقع رکھنے والی گہری، اہم MongoDB کی توسیع کی مہارت کو منعکس کرتا ہے۔