10B records-ஐ 100ms-க்குள் எப்படி query செய்வீர்கள்?

Question

IT Interview Practice · Accepted Answer

முதலில் **access pattern**-க்காக design செய்யுங்கள், பிறகு partitioning + சரியான index/PK தேர்ந்தெடுங்கள், இதனால் எந்த single query-ம் ஒரு சிறிய, bounded slice-ஐ மட்டும் தொடுகிறது — ஒருபோதும் 10B rows-ஐ scan செய்யாது. 10 பில்லியன் 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 அதற்குச் சரியாகப் பொருந்த விரும்புகிறீர்கள். "இந்த மாதம் region வாரியாக revenue-ஐ sum செய்" ஒரு analytical scan — ஒரு row store தவறான tool. முதலில் query-ஐ model செய்வது தான் வேலை செய்யும் design-ஐ நியாயமானதாகத் தோன்றி முழு-scan செய்யும் ஒன்றிலிருந்து பிரிக்கிறது.

## Partitioning search space-ஐ prune செய்கிறது

ஒவ்வொரு query-இலும் தோன்றும் ஒரு key மூலம் table-ஐப் பிரியுங்கள் — வழக்கமாக **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-ஐ முன்னிலைப்படுத்த வேண்டும்**. 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 அளவிடுகிறது.
- **Analytics/aggregates:** columnar (ClickHouse, BigQuery) — தேவையான columns-ஐ மட்டும் படிக்கிறது, vectorized.
- **hot 1%-ஐ cache செய்:** முன்னால் Redis மீண்டும் மீண்டும் வரும் reads-ஐ <5ms-இல் உறிஞ்சுகிறது; 10B rows ஆனால் சில மில்லியன் hot keys.

## நேர்காணல் கண்ணோட்டம்

"எந்த database?" என்பதற்கு முன் **"என்ன queries?"** என்று நீங்கள் சொல்வதை நேர்காணல் செய்பவர் பார்க்க விரும்புகிறார். நல்ல வேட்பாளர்கள் indexes-ஐ நோக்குகிறார்கள்; சிறந்தவர்கள் 10B rows மீதான ஒரு index-ஆல் மிகப் பெரியது என்பதைக் குறிப்பிடுகிறார்கள் — எனவே நீங்கள் *index எதை cover செய்கிறது என்பதைச் சுருக்க முதலில் 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-second query அல்ல.

Access patterns எல்லாவற்றையும் இயக்குகின்றன

Partitioning search space-ஐ prune செய்கிறது

சரியான index / PK design

Store தேர்வு

நேர்காணல் கண்ணோட்டம்

சமரசங்களும் தோல்வி முறைகளும்

தொடர்புடைய கேள்விகள்