अब्जावधी rows असलेली एकच table तुम्ही कशी partition कराल?

Question

IT Interview Practice · Accepted Answer

**विशाल table ला एका partition key ने लहान physical child tables मध्ये विभागा, जेणेकरून प्रत्येक query फक्त तिला लागणाऱ्या partitions ला स्पर्श करते (partition pruning) अब्जावधी rows scan करण्याऐवजी.** 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 मध्ये समान पसरवा. नैसर्गिक range नसताना आणि balanced load हवे तेव्हा वापरा (उदा. `user_id`).
- **List** — explicit 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) बनते: `DROP TABLE orders_2019` ने जुना data archive करा (तत्काळ, विशाल `DELETE` नाही), आणि rolling windows साठी `ATTACH`/`DETACH`.

## मुलाखतीचा दृष्टिकोन

मुलाखत घेणारा तुम्हाला समजते का की **partitioning हे indexing नाही** — ते scan केलेला data कमी करते, एक index scan आत तपासलेल्या rows कमी करते; तुम्हाला अनेकदा दोन्ही लागतात. चांगले उत्तर range/hash/list नावाने सांगते; उत्तम उत्तर जोर देते की **partition key तुमच्या dominant query filter शी जुळली पाहिजे**, चेतावणी देते की एक चुकीची key pruning मारते, आणि `DROP` द्वारे स्वस्त archival चा उल्लेख करते.

**तडजोड:** cross-partition queries (no key filter, किंवा partitions पलीकडे unique constraints) slow होतात आणि unique enforcement कठीण आहे. एक 1 कोटी-row table partition करू नका — तुम्ही काही फायद्याशिवाय operational complexity जोडता. table विशाल असेल **आणि** queries नैसर्गिकरित्या key ने scoped असतील तेव्हा partition करा.

एका partitioned table चा आकार

एक partition strategy निवडणे

Pruning, indexes, maintenance

मुलाखतीचा दृष्टिकोन

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