billions of rows ఉన్న ఒక్క table ను మీరు ఎలా partition చేస్తారు?

Question

IT Interview Practice · Accepted Answer

**giant table ను ఒక partition key ద్వారా చిన్న physical child tables గా split చేయండి, తద్వారా ప్రతి query billions of rows ను scan చేయడానికి బదులు దానికి అవసరమైన partitions ను మాత్రమే తాకుతుంది (partition pruning).** 5B 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 అంతటా even spread. natural range లేనప్పుడు మరియు balanced load (ఉదా. `user_id`) కావాలంటే వాడండి.
- **List** — explicit buckets (`region IN ('EU','US')`). tenant లేదా region isolation కి మంచిది.

```sql
-- Postgres: created_at పై range partition (నెల వారీగా), 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, indexes, maintenance

- **Partition pruning** query **partition key** పై filter చేస్తేనే పనిచేస్తుంది. వేరే దానిపై filter చేయండి మరియు మీరు ప్రతి partition ను scan చేస్తారు — #1 తప్పు.
- **Local index** = ఒక్కో child కి ఒక index (Postgres లో default); partition తో build చేయడం మరియు drop చేయడం చవక. **Global index** (Oracle) అన్ని partitions ను spans చేస్తుంది — partitions అంతటా unique lookups కి సహాయపడుతుంది కానీ మీరు ఒకదాన్ని drop చేసినప్పుడు rebuild చేయాలి.
- **Maintenance** O(partition) అవుతుంది: `DROP TABLE orders_2019` తో పాత data ను archive చేయండి (తక్షణం, giant `DELETE` లేదు), మరియు rolling windows కోసం `ATTACH`/`DETACH`.

## ఇంటర్వ్యూ దృక్కోణం

**partitioning అనేది indexing కాదు** అని మీకు అర్థమైందా అని ఇంటర్వ్యూయర్ పరిశీలిస్తారు — ఇది scan అయ్యే data ను తగ్గిస్తుంది, ఒక index ఒక scan లోపల examine అయ్యే rows ను తగ్గిస్తుంది; మీకు తరచుగా రెండూ అవసరం. మంచి సమాధానం range/hash/list ను పేర్కొంటుంది; గొప్ప సమాధానం **partition key మీ dominant query filter కు match కావాలి** అని నొక్కి, ఒక తప్పు key pruning ను చంపుతుందని హెచ్చరించి, `DROP` ద్వారా చవకైన archival ను ప్రస్తావిస్తుంది.

**Trade-off:** cross-partition queries (key filter లేదు, లేదా partitions అంతటా unique constraints) నెమ్మదవుతాయి మరియు unique enforcement కష్టం. ఒక 10M-row table ను partition చేయవద్దు — ఏ లాభం లేకుండా operational complexity ను జోడిస్తారు. table భారీగా ఉన్నప్పుడు **మరియు** queries సహజంగా key ద్వారా scoped అయినప్పుడు partition చేయండి.

ఒక partitioned table యొక్క ఆకారం

ఒక partition strategy ను ఎంచుకోవడం

Pruning, indexes, maintenance

ఇంటర్వ్యూ దృక్కోణం

సంబంధిత ప్రశ్నలు