শত কোটি row সহ একটি একক table কীভাবে partition করবেন?

Question

IT Interview Practice · Accepted Answer

**বিশাল table-কে একটি partition key দিয়ে ছোট physical child table-এ split করুন, যাতে প্রতিটি query শত কোটি row scan করার বদলে কেবল যে partition দরকার তা স্পর্শ করে (partition pruning)।** ৫০০ কোটি order row সহ একটি table এখনও একটি logical table-এর মতো আচরণ করে, কিন্তু আপনার `WHERE` partition key-তে filter করলে engine এর ৯৯% skip করে।

## একটি partitioned table-এর আকার

```text
                 orders (logical parent)
                        │  partition key = created_at
       ┌────────────────┼────────────────┬───────────────┐
       ▼                ▼                ▼               ▼
 orders_2024_q1   orders_2024_q2   orders_2024_q3   orders_2025_q1
  (child table)    (child table)    (child table)    (child, active)
       │                                                  │
   local index                                        local index
   (per child)                                        (per child)
```

## একটি partition strategy বাছা

- **Range** — date/id range দিয়ে। time-series-এর (order, log, event) জন্য সেরা; সাম্প্রতিক data hot থাকে এবং পুরনো range drop করা সহজ।
- **Hash** — `hash(key) % N` দিয়ে N partition জুড়ে সমান ছড়ানো। কোনো natural range না থাকলে এবং balanced load চাইলে ব্যবহার করুন (যেমন `user_id`)।
- **List** — সুস্পষ্ট bucket (`region IN ('EU','US')`)। tenant বা region isolation-এর জন্য ভালো।

```sql
-- Postgres: created_at-এ prune করে month দিয়ে range partition
CREATE TABLE orders (id bigint, created_at date, amount numeric)
  PARTITION BY RANGE (created_at);

CREATE TABLE orders_2025_01 PARTITION OF orders
  FOR VALUES FROM ('2025-01-01') TO ('2025-02-01');

-- এটি পুরো table নয়, কেবল orders_2025_01 scan করে
SELECT sum(amount) FROM orders
 WHERE created_at >= '2025-01-01' AND created_at < '2025-02-01';
```

## Pruning, index, maintenance

- **Partition pruning** কেবল তখনই কাজ করে যখন query **partition key**-তে filter করে। অন্য কিছুতে filter করুন আর আপনি প্রতিটি partition scan করবেন — #১ ভুল।
- **Local index** = প্রতি child-এ একটি index (Postgres-এ ডিফল্ট); partition-এর সঙ্গে তৈরি ও drop করা সস্তা। **Global index** (Oracle) সব partition জুড়ে বিস্তৃত — partition জুড়ে unique lookup-এ সাহায্য করে কিন্তু একটি drop করলে rebuild করতে হবে।
- **Maintenance** হয়ে যায় O(partition): `DROP TABLE orders_2019` দিয়ে পুরনো data archive করুন (তাৎক্ষণিক, কোনো বিশাল `DELETE` নয়), এবং rolling window-এর জন্য `ATTACH`/`DETACH`।

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

ইন্টারভিউয়ার যাচাই করেন আপনি বোঝেন কিনা যে **partitioning indexing নয়** — এটি scan করা data কমায়, একটি index একটি scan-এর মধ্যে পরীক্ষিত row কমায়; আপনার প্রায়ই উভয়ই লাগে। ভালো উত্তর range/hash/list নাম ধরে বলে; দারুণ উত্তর জোর দেয় যে **partition key অবশ্যই আপনার প্রধান query filter-এর সঙ্গে মিলতে হবে**, সতর্ক করে যে একটি ভুল key pruning নিধন করে, এবং `DROP` দিয়ে সস্তা archival উল্লেখ করে।

**ট্রেড-অফ:** cross-partition query (কোনো key filter নেই, বা partition জুড়ে unique constraint) ধীর হয় এবং unique enforcement কঠিন। একটি ১ কোটি-row table partition করবেন না — আপনি কোনো লাভ ছাড়া operational জটিলতা যোগ করেন। partition করুন যখন table বিশাল **এবং** query স্বাভাবিকভাবে key দিয়ে scoped।

একটি partitioned table-এর আকার

একটি partition strategy বাছা

Pruning, index, maintenance

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

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