आप 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 सब कुछ तय करते हैं

tech चुनने से पहले पूछें: **point lookup या range/aggregate?** "यूज़र X के अंतिम 20 orders लाओ" एक point/range query है — आप चाहते हैं partition और sort key उससे बिल्कुल मेल खाएं। "इस महीने region के हिसाब से revenue का sum" एक analytical scan है — एक row store गलत उपकरण है। पहले query को model करना ही एक ऐसे डिज़ाइन को अलग करता है जो काम करता है और एक जो उचित दिखता है पर full-scans करता है।

## Partitioning search space को prune करता है

table को एक ऐसी key से बांटें जो हर query में आती है — आमतौर पर **tenant_id + time**। time partitions के साथ, "अंतिम 7 दिन" की एक query 7 partitions पढ़ती है और बाकी 3 साल को नज़रअंदाज़ करती है। यह *partition pruning* है: router किसी भी index को देखने से पहले 99.9% data हटा देता है।

## सही 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 skip करने और केवल matching blocks पढ़ने देता है। एक covering index अतिरिक्त row fetch को पूरी तरह टाल देता है।

## Store का चुनाव

- **Point lookups, high 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।

## इंटरव्यू का नज़रिया

Interviewer आपको **"queries क्या हैं?" "कौन सा database?" से पहले** कहते देखना चाहता है। अच्छे candidates indexes की ओर बढ़ते हैं; बढ़िया वाले नोट करते हैं कि 10 अरब rows पर एक index खुद विशाल है — इसलिए आप *पहले partition करते हैं ताकि index जो cover करता है वह छोटा हो*। row-vs-columnar विभाजन और cache tier नाम लेना असली scale अनुभव का संकेत देता है।

**आम जाल:** एक विशाल B-tree index को जवाब के रूप में प्रस्तावित करना। यह point lookups में मदद करता है पर analytical scans के लिए कुछ नहीं करता, और इसके writes ingestion को bottleneck करते हैं।

## ट्रेड-ऑफ़ और failure modes

- **गलत partition key** = cross-partition scatter-gather, latency फूल जाती है। queries में मौजूद key चुनें।
- **Hot partition:** एक celebrity tenant एक shard को अभिभूत कर देता है — एक salting suffix जोड़ें।
- **Cache staleness:** write पर invalidate करें या TTL lag स्वीकार करें।
- **Denormalization cost:** आप अक्सर प्रति access pattern data duplicate करते हैं; storage सस्ता है, एक 10-सेकंड query नहीं।

Access patterns सब कुछ तय करते हैं

Partitioning search space को prune करता है

सही index / PK डिज़ाइन

Store का चुनाव

इंटरव्यू का नज़रिया

ट्रेड-ऑफ़ और failure modes

संबंधित प्रश्न