તમે 10B records ને 100ms ની અંદર query કેવી રીતે કરશો?

Question

IT Interview Practice · Accepted Answer

**access pattern પહેલાં** ડિઝાઇન કરો, પછી partitioning + યોગ્ય index/PK પસંદ કરો જેથી કોઈપણ એક query નાનો, bounded slice સ્પર્શે — ક્યારેય 10B rows scan ન કરે. 10 અબજ records પર sub-100ms એ ઝડપી disk વિશે નથી; તે working set ને tiny બનાવવા વિશે છે.

```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 કરવું એ જ કામ કરતી ડિઝાઇન ને એવી ડિઝાઇનથી અલગ કરે છે જે વાજબી લાગે પણ full-scan કરે.

## Partitioning search space prune કરે છે

tech પસંદ કરતાં પહેલાં, દરેક query માં દેખાતા key વડે table ને split કરો — સામાન્ય રીતે **tenant_id + time**. time partitions સાથે, "છેલ્લા 7 દિવસ" માટે query 7 partitions વાંચે છે અને બાકીના 3 વર્ષ ignore કરે છે. આ *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 વાંચવા દે છે. 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 પર શોષે છે; 10B rows પણ થોડા લાખ hot keys.

## ઇન્ટરવ્યૂ દૃષ્ટિકોણ

ઇન્ટરવ્યૂઅર તમને **"queries શું છે?" "કઈ database?" પહેલાં** કહેતા જોવા માંગે છે. Good candidates indexes તરફ પહોંચે છે; great candidates નોંધે છે કે 10B rows પર એક index પોતે વિશાળ છે — તેથી તમે *index જે cover કરે તે ઘટાડવા પહેલાં partition કરો*. row-vs-columnar split અને cache tier નું નામ આપવું real scale experience દર્શાવે છે.

**સામાન્ય trap:** જવાબ તરીકે એક વિશાળ B-tree index પ્રસ્તાવવો. તે point lookups માં મદદ કરે છે પણ analytical scans માટે કંઈ કરતું નથી, અને તેની writes ingestion ને bottleneck કરે છે.

## Trade-offs અને failure modes

- **ખોટો 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 પસંદગી

ઇન્ટરવ્યૂ દૃષ્ટિકોણ

Trade-offs અને failure modes

સંબંધિત પ્રશ્નો