10B records ను 100ms లోపు మీరు ఎలా query చేస్తారు?

Question

IT Interview Practice · Accepted Answer

ముందుగా **access pattern** కోసం design చేయండి, తర్వాత partitioning + సరైన index/PK ను ఎంచుకోండి తద్వారా ఏ single query అయినా చిన్న, bounded slice ను తాకుతుంది — ఎప్పుడూ 10B rows ను scan చేయదు. 10 billion records పై sub-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?** "user X యొక్క చివరి 20 orders ను పొందండి" ఒక point/range query — partition మరియు sort key దానికి సరిగ్గా match కావాలని మీరు కోరుకుంటారు. "ఈ నెల region వారీగా revenue ను sum చేయండి" ఒక analytical scan — ఒక row store తప్పు tool. ముందుగా query ను model చేయడమే పనిచేసే design ను reasonable గా కనిపించే కానీ full-scan చేసే దాని నుండి వేరు చేస్తుంది.

## Partitioning search space ను prune చేస్తుంది

ప్రతి query లో కనిపించే ఒక key ద్వారా table ను విభజించండి — సాధారణంగా **tenant_id + time**. time partitions తో, "last 7 days" కోసం ఒక query 7 partitions ను read చేసి ఇతర 3 years ను విస్మరిస్తుంది. ఇది *partition pruning*: ఏ index ను consult చేయడానికి ముందు 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 చేసి matching blocks ను మాత్రమే read చేయనిస్తుంది. ఒక 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 ను మాత్రమే read చేస్తుంది, vectorized.
- **hot 1% ను Cache చేయండి:** ముందు Redis పునరావృత reads ను <5ms వద్ద శోషిస్తుంది; 10B rows కానీ కొన్ని million hot keys.

## ఇంటర్వ్యూ దృక్కోణం

**"what database?" కంటే ముందు "what are the queries?"** అని మీరు చెప్పడం ఇంటర్వ్యూయర్ చూడాలనుకుంటారు. మంచి candidates indexes కోసం చేరుకుంటారు; గొప్పవారు 10B rows పై ఒక index దానిలోనే భారీ అని గమనిస్తారు — కాబట్టి మీరు *index ఏమి cover చేస్తుందో కుదించడానికి ముందుగా partition చేస్తారు*. row-vs-columnar split మరియు cache tier ను పేర్కొనడం నిజమైన scale అనుభవాన్ని సూచిస్తుంది.

**సాధారణ ఉచ్చు:** సమాధానంగా ఒక్క giant B-tree index ను ప్రతిపాదించడం. ఇది point lookups కి సహాయపడుతుంది కానీ analytical scans కి ఏమీ చేయదు, మరియు దాని writes ingestion ను bottleneck చేస్తాయి.

## ట్రేడ్-ఆఫ్‌లు & వైఫల్య మోడ్‌లు

- **తప్పు partition key** = cross-partition scatter-gather, latency ఉబ్బుతుంది. queries లో ఉన్న ఒక key ను ఎంచుకోండి.
- **Hot partition:** ఒక celebrity tenant ఒక shard ను overwhelm చేస్తుంది — ఒక salting suffix జోడించండి.
- **Cache staleness:** write పై invalidate చేయండి లేదా TTL lag ను అంగీకరించండి.
- **Denormalization cost:** మీరు తరచుగా ఒక్కో access pattern కి data ను duplicate చేస్తారు; storage చవక, 10-second query కాదు.

Access patterns అన్నింటినీ నడిపిస్తాయి

Partitioning search space ను prune చేస్తుంది

సరైన index / PK design

Store ఎంపిక

ఇంటర్వ్యూ దృక్కోణం

ట్రేడ్-ఆఫ్‌లు & వైఫల్య మోడ్‌లు

సంబంధిత ప్రశ్నలు