તમે અબજો rows વાળા એક table ને કેવી રીતે partition કરશો?

Question

IT Interview Practice · Accepted Answer

**વિશાળ table ને partition key વડે નાના physical child tables માં split કરો, જેથી દરેક query અબજો 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: 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 સાથે build અને drop કરવું સસ્તું. **Global index** (Oracle) બધા partitions પર ફેલાય — partitions પર unique lookups માં મદદ કરે પણ partition drop કરો ત્યારે rebuild કરવો પડે.
- **Maintenance** O(partition) બની જાય છે: `DROP TABLE orders_2019` વડે જૂનું data archive કરો (instant, વિશાળ `DELETE` નહીં), અને rolling windows માટે `ATTACH`/`DETACH`.

## ઇન્ટરવ્યૂ દૃષ્ટિકોણ

ઇન્ટરવ્યૂઅર probe કરે છે કે તમે સમજો છો કે **partitioning એ indexing નથી** — તે scan થતો data ઘટાડે છે, index scan ની અંદર examine થતા rows ઘટાડે છે; તમને ઘણી વાર બંને જોઈએ. Good answer range/hash/list નું નામ આપે છે; great answer ભાર મૂકે છે કે **partition key તમારા dominant query filter સાથે match થવો જ જોઈએ**, ચેતવે છે કે ખોટો key pruning મારે છે, અને `DROP` વડે સસ્તા archival નો ઉલ્લેખ કરે છે.

**Trade-off:** cross-partition queries (no key filter, અથવા partitions પર unique constraints) ધીમી થાય અને unique enforcement મુશ્કેલ છે. 10M-row table ને partition ન કરો — તમે કોઈ ફાયદા વગર operational complexity ઉમેરો છો. ત્યારે partition કરો જ્યારે table વિશાળ હોય **અને** queries key વડે naturally scoped હોય.

partitioned table નો આકાર

partition strategy પસંદ કરવી

Pruning, indexes, maintenance

ઇન્ટરવ્યૂ દૃષ્ટિકોણ

સંબંધિત પ્રશ્નો