১০০০ কোটি record-এ ১০০ms-এর নিচে কীভাবে query করবেন?

Question

IT Interview Practice · Accepted Answer

**access pattern-এর জন্য প্রথমে** ডিজাইন করুন, তারপর partitioning + সঠিক index/PK বাছুন যাতে যেকোনো একক query একটি ছোট, সীমাবদ্ধ slice স্পর্শ করে — কখনও ১০০০ কোটি row scan না করে। ১০০০ কোটি 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?** "ইউজার X-এর শেষ ২০টি order আনুন" একটি point/range query — আপনি চান partition ও sort key ঠিক এর সঙ্গে মিলুক। "এই মাসে region অনুযায়ী revenue sum করুন" একটি analytical scan — একটি row store ভুল টুল। প্রথমে query মডেল করাই একটি কার্যকর ডিজাইনকে একটি যুক্তিসঙ্গত দেখতে কিন্তু full-scan করা ডিজাইন থেকে আলাদা করে।

## Partitioning search space ছাঁটে

প্রতিটি query-তে থাকা একটি key দিয়ে table split করুন — সাধারণত **tenant_id + time**। time partition দিয়ে, "শেষ ৭ দিন"-এর একটি query ৭টি partition পড়ে এবং বাকি ৩ বছর উপেক্ষা করে। এটি *partition pruning*: কোনো index পরামর্শ করার আগেই router ৯৯.৯% 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 করে কেবল matching block পড়তে দেয়। একটি covering index অতিরিক্ত row fetch পুরোপুরি এড়ায়।

## Store পছন্দ

- **Point lookup, high write:** NoSQL key-value (DynamoDB, Cassandra) — key দিয়ে O(1)-মতো, অনুভূমিকভাবে scale করে।
- **Analytics/aggregate:** columnar (ClickHouse, BigQuery) — কেবল প্রয়োজনীয় column পড়ে, vectorized।
- **hot ১% cache করুন:** সামনে Redis <5ms-এ পুনরাবৃত্ত read শোষণ করে; ১০০০ কোটি row কিন্তু কয়েক মিলিয়ন hot key।

## ইন্টারভিউ দৃষ্টিভঙ্গি

ইন্টারভিউয়ার দেখতে চান আপনি **"কোন database?"-এর আগে "query কী?"** বলছেন কিনা। ভালো প্রার্থীরা index-এর দিকে হাত বাড়ায়; দারুণরা লক্ষ্য করে যে ১০০০ কোটি row-এর উপর একটি index নিজেই বিশাল — তাই আপনি *প্রথমে partition করেন যাতে index যা cover করে তা ছোট হয়*। row-বনাম-columnar বিভাজন ও cache tier নাম ধরে বলা প্রকৃত স্কেল অভিজ্ঞতার সংকেত দেয়।

**সাধারণ ফাঁদ:** উত্তর হিসেবে একটি বিশাল B-tree index প্রস্তাব করা। এটি point lookup-এ সাহায্য করে কিন্তু analytical scan-এ কিছুই করে না, এবং এর write ingestion-কে bottleneck করে।

## ট্রেড-অফ ও ব্যর্থতার ধরন

- **ভুল 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 সস্তা, একটি ১০-সেকেন্ডের query নয়।

Access pattern সবকিছু চালায়

Partitioning search space ছাঁটে

সঠিক index / PK ডিজাইন

Store পছন্দ

ইন্টারভিউ দৃষ্টিভঙ্গি

ট্রেড-অফ ও ব্যর্থতার ধরন

সম্পর্কিত প্রশ্ন