10 अर्ब record लाई 100ms भित्र कसरी query गर्नुहुन्छ?

Question

IT Interview Practice · Accepted Answer

पहिले **access pattern** का लागि डिजाइन गर्नुहोस्, अनि partitioning + सही index/PK छान्नुहोस् ताकि कुनै एउटै query ले सानो, सीमित slice मात्र छुओस् — 10 अर्ब row कहिल्यै scan नगरोस्। 10 अर्ब record माथि 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 pattern ले सबै कुरा चलाउँछ

tech छान्नु अघि सोध्नुहोस्: **point lookup कि range/aggregate?** "user X को अन्तिम 20 order पाऊ" एउटा point/range query हो — तपाईं partition र sort key लाई त्यसैसँग ठ्याक्कै मिलाउन चाहनुहुन्छ। "यो महिना region अनुसार revenue sum गर" एउटा analytical scan हो — row store गलत tool हो। पहिले query model गर्नु नै काम गर्ने डिजाइन र देख्दा उचित लाग्ने तर full-scan गर्ने डिजाइन बीच फरक पार्ने कुरा हो।

## Partitioning ले search space छाँट्छ

table लाई प्रत्येक query मा देखिने key — प्रायः **tenant_id + time** — अनुसार विभाजन गर्नुहोस्। time partition सँग, "अन्तिम 7 दिन" को query ले 7 partition पढ्छ र अरू 3 वर्ष बेवास्ता गर्छ। यो *partition pruning* हो: कुनै index हेर्नुअघि नै router ले 99.9% data हटाउँछ।

## सही index / PK डिजाइन

partition भित्र, **primary key ले query को filter column अगाडि राख्नैपर्छ**। DynamoDB मा: partition key = `tenant`, sort key = `timestamp` → range query O(log n) + sequential read हुन्छ। **ClickHouse** जस्तो columnar store मा, sorting key (`ORDER BY (tenant, ts)`) ले engine लाई granule skip गर्न र मिल्ने block मात्र पढ्न दिन्छ। covering index ले अतिरिक्त row fetch पूरै टार्छ।

## Store छनौट

- **Point lookup, उच्च write:** NoSQL key-value (DynamoDB, Cassandra) — key अनुसार O(1)-जस्तो, horizontally scale हुन्छ।
- **Analytics/aggregate:** columnar (ClickHouse, BigQuery) — आवश्यक column मात्र पढ्छ, vectorized।
- **hot 1% cache गर्नुहोस्:** अगाडि Redis ले दोहोरिने read <5ms मा सोस्छ; 10 अर्ब row तर केही लाख hot key।

## अन्तर्वार्ता दृष्टिकोण

अन्तर्वार्ताकारले तपाईंले **"कुन database?" अघि "query हरू के हुन्?"** भन्नुभएको हेर्न चाहन्छन्। राम्रो candidate index तिर पुग्छन्; उत्कृष्टले 10 अर्ब row माथिको index आफैँ विशाल छ भन्ने बताउँछन् — त्यसैले तपाईं *पहिले partition गर्नुहुन्छ ताकि index ले ढाक्ने कुरा सानो होस्*। row-बनाम-columnar विभाजन र cache tier नाम दिनु वास्तविक scale अनुभवको संकेत हो।

**साधारण जाल:** उत्तरको रूपमा एउटा विशाल B-tree index प्रस्ताव गर्नु। यसले point lookup लाई मद्दत गर्छ तर analytical scan लाई केही गर्दैन, र यसको write ले ingestion bottleneck गर्छ।

## ट्रेड-अफ र failure mode

- **गलत partition key** = cross-partition scatter-gather, latency फुल्छ। query मा उपस्थित key छान्नुहोस्।
- **Hot partition:** एउटा celebrity tenant ले एउटा shard अत्यधिक भार्छ — salting suffix थप्नुहोस्।
- **Cache staleness:** write मा invalidate गर्नुहोस् वा TTL lag स्वीकार गर्नुहोस्।
- **Denormalization लागत:** तपाईं प्रायः प्रति access pattern data duplicate गर्नुहुन्छ; storage सस्तो छ, 10-second query छैन।

Access pattern ले सबै कुरा चलाउँछ

Partitioning ले search space छाँट्छ

सही index / PK डिजाइन

Store छनौट

अन्तर्वार्ता दृष्टिकोण

ट्रेड-अफ र failure mode

सम्बन्धित प्रश्नहरू