अर्बौं row भएको एउटै table कसरी partition गर्नुहुन्छ?

Question

IT Interview Practice · Accepted Answer

**विशाल table लाई partition key अनुसार साना physical child table मा विभाजन गर्नुहोस्, ताकि प्रत्येक query ले अर्बौं row scan गर्नुको सट्टा आवश्यक partition मात्र छुओस् (partition pruning)।** 5 अर्ब order row भएको 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 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: महिना अनुसार range partition, created_at मा prune
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 गर्नुहुन्छ — #1 गल्ती।
- **Local index** = प्रति child एउटा index (Postgres मा default); partition सँगै बनाउन र drop गर्न सस्तो। **Global index** (Oracle) सबै partition मा फैलिन्छ — partition बीच unique lookup मा मद्दत गर्छ तर एउटा drop गर्दा rebuild गर्नुपर्छ।
- **Maintenance** O(partition) हुन्छ: पुरानो data `DROP TABLE orders_2019` (तत्काल, विशाल `DELETE` छैन) ले archive गर्नुहोस्, र rolling window का लागि `ATTACH`/`DETACH` गर्नुहोस्।

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

अन्तर्वार्ताकारले तपाईंले **partitioning indexing होइन** भनेर बुझ्नुहुन्छ कि probe गर्छन् — यसले 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 गाह्रो हुन्छ। 10 करोड-row table partition नगर्नुहोस् — तपाईं फाइदा बिना operational जटिलता थप्नुहुन्छ। table विशाल **र** query key ले स्वाभाविक रूपमा scope हुँदा partition गर्नुहोस्।

Partitioned table को आकार

Partition strategy छनौट

Pruning, index, maintenance

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

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