آپ 100ms سے کم میں 10 ارب records کیسے query کرتے ہیں؟

Question

IT Interview Practice · Accepted Answer

پہلے **access pattern** کے لیے ڈیزائن کریں، پھر partitioning + صحیح index/PK چنیں تاکہ کوئی بھی واحد query ایک چھوٹے، محدود slice کو چھوئے — کبھی 10 ارب rows scan نہ کرے۔ 10 ارب records پر 100ms سے کم کسی تیز disk کے بارے میں نہیں؛ یہ working set کو چھوٹا بنانے کے بارے میں ہے۔

```text
Query ─▶ Router ──▶ Partition (by tenant/time) ──▶ Index/PK lookup ─▶ ~thousands of rows
   │                    (prune 99.9% of data)         (B-tree / sort key)
   └─▶ Cache (Redis) ─▶ hit? return in <5ms
                        miss ▼
                   Columnar store (ClickHouse) for aggregates / scans
```

## Access patterns ہر چیز چلاتے ہیں

ٹیکنالوجی چننے سے پہلے پوچھیں: **point lookup یا range/aggregate؟** "صارف X کے آخری 20 orders لاؤ" ایک point/range query ہے — آپ چاہتے ہیں partition اور sort key اس سے بالکل میل کھائے۔ "اس مہینے region کے حساب سے revenue کا مجموعہ" ایک analytical scan ہے — یہاں row store غلط اوزار ہے۔ پہلے query کو ماڈل کرنا وہی چیز ہے جو کام کرنے والے ڈیزائن کو معقول نظر آنے والے مگر full-scan کرنے والے ڈیزائن سے الگ کرتی ہے۔

## Partitioning search space کو کم کرتی ہے

table کو ایک ایسے key سے تقسیم کریں جو ہر query میں آتا ہو — عموماً **tenant_id + time**۔ time partitions کے ساتھ، "آخری 7 دن" کی query 7 partitions پڑھتی ہے اور باقی 3 سال نظرانداز کرتی ہے۔ یہ *partition pruning* ہے: کسی بھی index سے مشورہ کرنے سے پہلے router 99.9% ڈیٹا ختم کر دیتا ہے۔

## صحیح index / PK ڈیزائن

ایک partition کے اندر، **primary key کو query کے filter columns کو آگے رکھنا چاہیے**۔ DynamoDB میں: partition key = `tenant`، sort key = `timestamp` → range queries O(log n) + sequential read ہیں۔ **ClickHouse** جیسے columnar store میں، sorting key (`ORDER BY (tenant, ts)`) engine کو granules چھوڑنے اور صرف میل کھاتے blocks پڑھنے دیتا ہے۔ ایک covering index اضافی row fetch کو مکمل طور پر ٹال دیتا ہے۔

## Store کا انتخاب

- **Point lookups، زیادہ write:** NoSQL key-value (DynamoDB، Cassandra) — key کے حساب سے O(1)-ish، horizontally scale ہوتا ہے۔
- **Analytics/aggregates:** columnar (ClickHouse، BigQuery) — صرف مطلوبہ columns پڑھتا ہے، vectorized۔
- **Hot 1% کو cache کریں:** آگے Redis بار بار reads کو <5ms پر جذب کرتا ہے؛ 10 ارب rows مگر چند ملین hot keys۔

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

انٹرویو لینے والا دیکھنا چاہتا ہے کہ آپ **"queries کیا ہیں؟" بمقابلہ "کون سا database؟"** سے پہلے کہیں۔ اچھے امیدوار indexes کی طرف بڑھتے ہیں؛ عمدہ یہ نوٹ کرتے ہیں کہ 10 ارب rows پر ایک index خود بہت بڑا ہے — لہٰذا آپ *پہلے partition کرتے ہیں تاکہ index جو کور کرتا ہے اسے چھوٹا کیا جا سکے*۔ row-vs-columnar تقسیم اور cache tier کا نام لینا حقیقی scale کے تجربے کا اشارہ ہے۔

**عام جال:** ایک بڑے B-tree index کو جواب کے طور پر تجویز کرنا۔ یہ point lookups میں مدد کرتا ہے مگر analytical scans کے لیے کچھ نہیں کرتا، اور اس کی writes ingestion کو bottleneck کرتی ہیں۔

## توازن اور ناکامی کے طریقے

- **غلط partition key** = cross-partition scatter-gather، latency بڑھ جاتی ہے۔ ایک ایسا key چنیں جو queries میں موجود ہو۔
- **Hot partition:** ایک celebrity tenant ایک shard کو مغلوب کر دیتا ہے — ایک salting suffix شامل کریں۔
- **Cache staleness:** write پر invalidate کریں یا TTL lag قبول کریں۔
- **Denormalization لاگت:** آپ اکثر فی access pattern ڈیٹا duplicate کرتے ہیں؛ storage سستا ہے، ایک 10-سیکنڈ query نہیں۔

Access patterns ہر چیز چلاتے ہیں

Partitioning search space کو کم کرتی ہے

صحیح index / PK ڈیزائن

Store کا انتخاب

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

توازن اور ناکامی کے طریقے

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