آپ اربوں rows والی ایک واحد table کو کیسے partition کرتے ہیں؟

Question

IT Interview Practice · Accepted Answer

**بڑی table کو ایک partition key سے چھوٹی physical child tables میں تقسیم کریں، تاکہ ہر query صرف انہی partitions کو چھوئے جن کی اسے ضرورت ہو (partition pruning) بجائے اربوں rows scan کرنے کے۔** 5 ارب order rows والی table اب بھی ایک logical table کی طرح برتاؤ کرتی ہے، مگر جب آپ کا `WHERE` partition key پر filter کرتا ہے تو engine اس کا 99% چھوڑ دیتا ہے۔

## ایک partitioned table کی شکل

```text
                 orders (logical parent)
                        │  partition key = created_at
       ┌────────────────┼────────────────┬───────────────┐
       ▼                ▼                ▼               ▼
 orders_2024_q1   orders_2024_q2   orders_2024_q3   orders_2025_q1
  (child table)    (child table)    (child table)    (child, active)
       │                                                  │
   local index                                        local index
   (per child)                                        (per child)
```

## ایک partition strategy چننا

- **Range** — date/id ranges سے۔ time-series کے لیے بہترین (orders، logs، events)؛ حالیہ ڈیٹا hot رہتا ہے اور پرانے ranges drop کرنا آسان ہے۔
- **Hash** — `hash(key) % N` سے N partitions میں یکساں پھیلاؤ۔ استعمال کریں جب کوئی قدرتی range نہ ہو اور آپ متوازن load چاہتے ہوں (مثلاً `user_id`)۔
- **List** — واضح buckets (`region IN ('EU','US')`)۔ tenant یا region isolation کے لیے اچھا۔

```sql
-- Postgres: month سے range partition، created_at پر prune
CREATE TABLE orders (id bigint, created_at date, amount numeric)
  PARTITION BY RANGE (created_at);

CREATE TABLE orders_2025_01 PARTITION OF orders
  FOR VALUES FROM ('2025-01-01') TO ('2025-02-01');

-- یہ صرف orders_2025_01 scan کرتا ہے، پوری table نہیں
SELECT sum(amount) FROM orders
 WHERE created_at >= '2025-01-01' AND created_at < '2025-02-01';
```

## Pruning، indexes، maintenance

- **Partition pruning** صرف تب کام کرتا ہے جب query **partition key** پر filter کرے۔ کسی اور چیز پر filter کریں اور آپ ہر partition scan کرتے ہیں — #1 غلطی۔
- **Local index** = فی child ایک index (Postgres میں default)؛ partition کے ساتھ بنانا اور drop کرنا سستا۔ **Global index** (Oracle) تمام partitions پر پھیلتا ہے — partitions کے پار unique lookups میں مدد کرتا ہے مگر جب آپ ایک drop کریں تو اسے rebuild کرنا پڑتا ہے۔
- **Maintenance** O(partition) بن جاتی ہے: پرانا ڈیٹا `DROP TABLE orders_2019` سے archive کریں (فوری، کوئی بڑا `DELETE` نہیں)، اور rolling windows کے لیے `ATTACH`/`DETACH`۔

## انٹرویو کا نقطۂ نظر

انٹرویو لینے والا جانچتا ہے کہ کیا آپ سمجھتے ہیں کہ **partitioning indexing نہیں ہے** — یہ scan کیے گئے ڈیٹا کو کم کرتی ہے، ایک index ایک scan کے اندر جانچی گئی rows کو کم کرتا ہے؛ آپ کو اکثر دونوں چاہئیں۔ اچھا جواب range/hash/list کا نام لیتا ہے؛ عمدہ جواب زور دیتا ہے کہ **partition key کو آپ کے غالب query filter سے میل کھانا چاہیے**، خبردار کرتا ہے کہ ایک غلط key pruning ختم کر دیتا ہے، اور `DROP` کے ذریعے سستے archival کا ذکر کرتا ہے۔

**توازن:** cross-partition queries (کوئی key filter نہیں، یا partitions کے پار unique constraints) سست ہو جاتی ہیں اور unique enforcement مشکل ہے۔ ایک 1 کروڑ row table کو partition نہ کریں — آپ بلا فائدہ operational پیچیدگی بڑھاتے ہیں۔ تب partition کریں جب table بہت بڑی ہو **اور** queries قدرتی طور پر key سے scoped ہوں۔

ایک partitioned table کی شکل

ایک partition strategy چننا

Pruning، indexes، maintenance

انٹرویو کا نقطۂ نظر

متعلقہ سوالات