आप अरबों rows वाली एक अकेली table कैसे partition करते हैं?

Question

IT Interview Practice · Accepted Answer

**विशाल table को एक partition key से छोटी physical child tables में बांटें, ताकि हर query अरबों rows scan करने के बजाय केवल उन partitions को छुए जिनकी ज़रूरत है (partition pruning)।** 5 अरब order rows वाली एक table अब भी एक logical table की तरह व्यवहार करती है, पर जब आपका `WHERE` partition key पर filter करता है तो engine इसका 99% 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 ranges से। time-series (orders, logs, events) के लिए सबसे अच्छा; हाल का data hot रहता है और पुराने ranges drop करना आसान है।
- **Hash** — `hash(key) % N` से N partitions में समान फैलाव। जब कोई natural range न हो और आप balanced load चाहें तब इस्तेमाल करें (जैसे `user_id`)।
- **List** — स्पष्ट buckets (`region IN ('EU','US')`)। tenant या region isolation के लिए अच्छा।

```sql
-- Postgres: range partition by month, prune on created_at
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');

-- This scans ONLY orders_2025_01, not the whole table
SELECT sum(amount) FROM orders
 WHERE created_at >= '2025-01-01' AND created_at < '2025-02-01';
```

## Pruning, indexes, maintenance

- **Partition pruning** केवल तब काम करता है जब query **partition key** पर filter करती है। किसी और चीज़ पर filter करें और आप हर partition scan करते हैं — #1 गलती।
- **Local index** = प्रति child एक index (Postgres में default); partition के साथ बनाना और drop करना सस्ता। **Global index** (Oracle) सभी partitions में फैलता है — partitions में unique lookups में मदद करता है पर एक drop करने पर rebuild होना चाहिए।
- **Maintenance** O(partition) बन जाता है: पुराना data `DROP TABLE orders_2019` (तुरंत, कोई विशाल `DELETE` नहीं) से archive करें, और rolling windows के लिए `ATTACH`/`DETACH`।

## इंटरव्यू का नज़रिया

Interviewer परखता है कि क्या आप समझते हैं **partitioning indexing नहीं है** — यह scan किया गया data घटाता है, एक index एक scan के भीतर जांची गई rows घटाता है; आपको अक्सर दोनों चाहिए। अच्छा जवाब range/hash/list नाम लेता है; बढ़िया जवाब ज़ोर देता है कि **partition key को आपके dominant query filter से match करना चाहिए**, चेताता है कि एक गलत key pruning खत्म कर देती है, और `DROP` के ज़रिए सस्ते archival का उल्लेख करता है।

**ट्रेड-ऑफ़:** cross-partition queries (कोई key filter नहीं, या partitions में unique constraints) धीमी हो जाती हैं और unique enforcement कठिन है। एक 1 करोड़-row table को partition न करें — आप बिना लाभ के operational complexity जोड़ते हैं। तब partition करें जब table विशाल हो **और** queries स्वाभाविक रूप से key से scoped हों।

एक partitioned table का आकार

एक partition strategy चुनना

Pruning, indexes, maintenance

इंटरव्यू का नज़रिया

संबंधित प्रश्न