ਤੁਸੀਂ ਅਰਬਾਂ rows ਵਾਲੀ ਇੱਕ single table ਨੂੰ ਕਿਵੇਂ partition ਕਰਦੇ ਹੋ?

Question

IT Interview Practice · Accepted Answer

**ਵਿਸ਼ਾਲ table ਨੂੰ ਇੱਕ partition key ਨਾਲ ਛੋਟੀਆਂ physical child tables ਵਿੱਚ ਵੰਡੋ, ਤਾਂ ਜੋ ਹਰ query ਸਿਰਫ਼ ਉਹਨਾਂ partitions ਨੂੰ ਛੂਹੇ ਜਿਨ੍ਹਾਂ ਦੀ ਇਸਨੂੰ ਲੋੜ ਹੈ (partition pruning) ਨਾ ਕਿ ਅਰਬਾਂ rows scan ਕਰੇ।** 5B order rows ਵਾਲੀ ਇੱਕ table ਅਜੇ ਵੀ ਇੱਕ logical table ਵਾਂਗ ਵਿਹਾਰ ਕਰਦੀ ਹੈ, ਪਰ engine ਇਸਦਾ 99% skip ਕਰ ਦਿੰਦਾ ਹੈ ਜਦੋਂ ਤੁਹਾਡਾ `WHERE` partition key ਉੱਤੇ filter ਕਰਦਾ ਹੈ।

## ਇੱਕ 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 ਵਿੱਚ ਬਰਾਬਰ spread। ਓਦੋਂ ਵਰਤੋ ਜਦੋਂ ਕੋਈ natural 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) ਬਣ ਜਾਂਦੀ ਹੈ: ਪੁਰਾਣੀ data ਨੂੰ `DROP TABLE orders_2019` ਨਾਲ archive ਕਰੋ (ਤੁਰੰਤ, ਕੋਈ ਵਿਸ਼ਾਲ `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 ਜੋੜਦੇ ਹੋ। ਤਦ partition ਕਰੋ ਜਦੋਂ table ਵਿਸ਼ਾਲ ਹੋਵੇ **ਅਤੇ** queries natural ਤੌਰ ਉੱਤੇ key ਨਾਲ scoped ਹੋਣ।

ਇੱਕ partitioned table ਦੀ ਸ਼ਕਲ

ਇੱਕ partition strategy ਚੁਣਨਾ

Pruning, indexes, maintenance

ਇੰਟਰਵਿਊ ਦਾ ਨਜ਼ਰੀਆ

ਸੰਬੰਧਿਤ ਸਵਾਲ