பில்லியன் கணக்கான rows கொண்ட ஒரே table-ஐ எப்படி partition செய்வீர்கள்?

Question

IT Interview Practice · Accepted Answer

**பெரிய table-ஐ ஒரு partition key மூலம் சிறிய physical child tables ஆகப் பிரியுங்கள், இதனால் ஒவ்வொரு 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 முழுவதும் சம பரவல். ஒரு natural range இல்லாதபோது மற்றும் balanced load வேண்டும்போது பயன்படுத்துங்கள் (எ.கா. `user_id`).
- **List** — வெளிப்படையான buckets (`region IN ('EU','US')`). tenant அல்லது region isolation-க்கு நல்லது.

```sql
-- Postgres: month மூலம் 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, 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-ஐப் பொருத்த வேண்டும்** என்பதை வலியுறுத்தி, ஒரு தவறான key pruning-ஐக் கொல்கிறது என்று எச்சரித்து, `DROP` மூலம் மலிவான archival-ஐக் குறிப்பிடுகிறது.

**சமரசம்:** 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

நேர்காணல் கண்ணோட்டம்

தொடர்புடைய கேள்விகள்