ਤੁਸੀਂ 10 ਅਰਬ records ਨੂੰ 100ms ਦੇ ਹੇਠ ਕਿਵੇਂ query ਕਰਦੇ ਹੋ?

Question

IT Interview Practice · Accepted Answer

ਪਹਿਲਾਂ **access pattern** ਲਈ design ਕਰੋ, ਫਿਰ partitioning + ਸਹੀ index/PK ਚੁਣੋ ਤਾਂ ਜੋ ਕੋਈ ਵੀ single query ਇੱਕ ਛੋਟੀ, bounded slice ਨੂੰ ਛੂਹੇ — ਕਦੇ 10 ਅਰਬ 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 ਇਸ ਨਾਲ ਬਿਲਕੁਲ match ਕਰਨ। "ਇਸ ਮਹੀਨੇ region ਅਨੁਸਾਰ revenue sum ਕਰੋ" ਇੱਕ analytical scan ਹੈ — ਇੱਕ row store ਗਲਤ tool ਹੈ। ਪਹਿਲਾਂ query ਨੂੰ model ਕਰਨਾ ਹੀ ਓਹ ਹੈ ਜੋ ਇੱਕ ਕੰਮ ਕਰਨ ਵਾਲੇ design ਨੂੰ ਓਸ ਤੋਂ ਵੱਖ ਕਰਦਾ ਹੈ ਜੋ ਵਾਜਬ ਲੱਗਦਾ ਹੈ ਪਰ full-scan ਕਰਦਾ ਹੈ।

## Partitioning search space ਨੂੰ ਛਾਂਟਦੀ ਹੈ

table ਨੂੰ ਇੱਕ ਅਜਿਹੇ key ਨਾਲ ਵੰਡੋ ਜੋ ਹਰ query ਵਿੱਚ ਦਿਸਦਾ ਹੈ — ਆਮ ਤੌਰ ਉੱਤੇ **tenant_id + time**। time partitions ਨਾਲ, "ਆਖਰੀ 7 ਦਿਨ" ਲਈ ਇੱਕ query 7 partitions ਪੜ੍ਹਦੀ ਹੈ ਅਤੇ ਬਾਕੀ 3 ਸਾਲ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਦੀ ਹੈ। ਇਹ *partition pruning* ਹੈ: router ਕਿਸੇ index ਦੀ ਸਲਾਹ ਲੈਣ ਤੋਂ ਪਹਿਲਾਂ 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 ਕਰਨ ਅਤੇ ਸਿਰਫ਼ matching blocks ਪੜ੍ਹਨ ਦਿੰਦਾ ਹੈ। ਇੱਕ covering index ਵਾਧੂ row fetch ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਟਾਲ ਦਿੰਦਾ ਹੈ।

## Store ਦੀ ਚੋਣ

- **Point lookups, high write:** NoSQL key-value (DynamoDB, Cassandra) — key ਨਾਲ O(1)-ਵਰਗਾ, horizontally scale ਕਰਦਾ ਹੈ।
- **Analytics/aggregates:** columnar (ClickHouse, BigQuery) — ਸਿਰਫ਼ ਲੋੜੀਂਦੇ columns ਪੜ੍ਹਦਾ ਹੈ, vectorized।
- **hot 1% ਨੂੰ cache ਕਰੋ:** ਸਾਹਮਣੇ Redis <5ms ਉੱਤੇ ਦੁਹਰਾਏ reads ਜਜ਼ਬ ਕਰਦਾ ਹੈ; 10 ਅਰਬ rows ਪਰ ਕੁਝ ਲੱਖ hot keys।

## ਇੰਟਰਵਿਊ ਦਾ ਨਜ਼ਰੀਆ

ਇੰਟਰਵਿਊਅਰ ਚਾਹੁੰਦਾ ਹੈ ਕਿ ਤੁਸੀਂ **"queries ਕੀ ਹਨ?"** ਕਹੋ "ਕਿਹੜਾ database?" ਤੋਂ ਪਹਿਲਾਂ। ਵਧੀਆ candidates indexes ਵੱਲ ਹੱਥ ਵਧਾਉਂਦੇ ਹਨ; ਸ਼ਾਨਦਾਰ ਧਿਆਨ ਦਿੰਦੇ ਹਨ ਕਿ 10 ਅਰਬ rows ਉੱਤੇ ਇੱਕ index ਖੁਦ ਬਹੁਤ ਵੱਡਾ ਹੁੰਦਾ ਹੈ — ਇਸ ਲਈ ਤੁਸੀਂ *ਪਹਿਲਾਂ partition ਕਰਦੇ ਹੋ ਤਾਂ ਜੋ index ਜਿਸਨੂੰ cover ਕਰੇ ਓਹ ਛੋਟਾ ਹੋ ਜਾਵੇ*। row-vs-columnar split ਅਤੇ cache tier ਦਾ ਨਾਂ ਲੈਣਾ ਅਸਲੀ scale ਤਜਰਬੇ ਦਾ signal ਹੈ।

**ਆਮ ਫੰਦਾ:** ਜਵਾਬ ਵਜੋਂ ਇੱਕ ਵਿਸ਼ਾਲ B-tree index ਦਾ ਪ੍ਰਸਤਾਵ ਕਰਨਾ। ਇਹ point lookups ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ ਪਰ analytical scans ਲਈ ਕੁਝ ਨਹੀਂ ਕਰਦਾ, ਅਤੇ ਇਸ ਦੇ writes ingestion ਨੂੰ bottleneck ਕਰਦੇ ਹਨ।

## ਟ੍ਰੇਡ-ਆਫ ਅਤੇ ਫੇਲੀਅਰ ਮੋਡ

- **ਗਲਤ partition key** = cross-partition scatter-gather, latency ਫੁੱਲ ਜਾਂਦੀ ਹੈ। ਇੱਕ ਅਜਿਹਾ key ਚੁਣੋ ਜੋ queries ਵਿੱਚ ਮੌਜੂਦ ਹੋਵੇ।
- **Hot partition:** ਇੱਕ celebrity tenant ਇੱਕ shard ਨੂੰ overwhelm ਕਰਦਾ ਹੈ — ਇੱਕ salting suffix ਜੋੜੋ।
- **Cache staleness:** write ਉੱਤੇ invalidate ਕਰੋ ਜਾਂ TTL lag ਸਵੀਕਾਰ ਕਰੋ।
- **Denormalization cost:** ਤੁਸੀਂ ਅਕਸਰ ਹਰ access pattern ਲਈ data ਦੁਹਰਾਉਂਦੇ ਹੋ; storage ਸਸਤਾ ਹੈ, ਇੱਕ 10-ਸਕਿੰਟ query ਨਹੀਂ।

Access patterns ਸਭ ਕੁਝ ਚਲਾਉਂਦੇ ਹਨ

Partitioning search space ਨੂੰ ਛਾਂਟਦੀ ਹੈ

ਸਹੀ index / PK design

Store ਦੀ ਚੋਣ

ਇੰਟਰਵਿਊ ਦਾ ਨਜ਼ਰੀਆ

ਟ੍ਰੇਡ-ਆਫ ਅਤੇ ਫੇਲੀਅਰ ਮੋਡ

ਸੰਬੰਧਿਤ ਸਵਾਲ