1000 कोटी records 100ms च्या आत तुम्ही कसे query कराल?

Question

IT Interview Practice · Accepted Answer

आधी **access pattern** साठी design करा, नंतर partitioning + योग्य index/PK निवडा जेणेकरून कोणतीही एकच query एका लहान, बांधलेल्या slice ला स्पर्श करते — 1000 कोटी rows कधीही scan करत नाही. 1000 कोटी 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 बेरीज करा" हा analytical scan आहे — row store चुकीचे साधन आहे. आधी query model करणे हेच चालणारे design आणि वाजवी दिसणारे पण full-scan करणारे design यांना वेगळे करते.

## Partitioning शोध जागा कमी करते

table ला अशा key ने विभागा जी प्रत्येक query मध्ये येते — सहसा **tenant_id + time**. time partitions सह, "शेवटचे 7 दिवस" ची query 7 partitions वाचते आणि उरलेली 3 वर्षे दुर्लक्ष करते. हे *partition pruning* आहे: कोणताही index तपासण्याआधी router 99.9% data काढून टाकतो.

## योग्य index / PK design

एका partition आत, **primary key ने query च्या filter columns ना front-load केले पाहिजे**. 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 करू देते आणि फक्त जुळणारे 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 मध्ये शोषून घेते; 1000 कोटी rows पण काही लाख hot keys.

## मुलाखतीचा दृष्टिकोन

मुलाखत घेणारा तुम्ही **"queries काय आहेत?"** हे **"कोणते database?"** आधी म्हणता का हे पाहू इच्छितो. चांगले उमेदवार indexes कडे वळतात; उत्तम उमेदवार लक्षात घेतात की 1000 कोटी rows वरील index स्वतः प्रचंड आहे — म्हणून तुम्ही *index जे कव्हर करतो ते लहान करण्यासाठी आधी partition करता*. row-vs-columnar विभाजन आणि cache tier नावाने सांगणे खरा scale अनुभव दर्शवते.

**सामान्य सापळा:** उत्तर म्हणून एक विशाल B-tree index सुचवणे. ते point lookups ना मदत करते पण analytical scans साठी काहीही करत नाही, आणि त्याचे writes ingestion ला bottleneck करतात.

## तडजोडी आणि अपयश

- **चुकीची 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 शोध जागा कमी करते

योग्य index / PK design

Store निवड

मुलाखतीचा दृष्टिकोन

तडजोडी आणि अपयश

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