คุณจะ partition ตารางเดียวที่มีหลายพันล้าน row อย่างไร?

Question

IT Interview Practice · Accepted Answer

**แยกตารางยักษ์เป็น physical child table ที่เล็กลงตาม partition key เพื่อให้แต่ละ query แตะเฉพาะ partition ที่ต้องการ (partition pruning) แทนที่จะสแกนพันล้าน row** ตารางที่มี order 5B row ยังทำตัวเหมือนตาราง logical เดียว แต่ engine ข้าม 99% ของมันเมื่อ `WHERE` filter บน partition key

## รูปร่างของตารางที่ partition แล้ว

```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

- **Range** — ตามช่วง date/id ดีที่สุดสำหรับ time-series (order, log, event) ข้อมูลล่าสุดอยู่ hot และ range เก่า drop ได้ง่าย
- **Hash** — กระจายสม่ำเสมอข้าม N partition ด้วย `hash(key) % N` ใช้เมื่อไม่มี range ตามธรรมชาติและคุณต้องการ load ที่สมดุล (เช่น `user_id`)
- **List** — bucket ที่ระบุชัดเจน (`region IN ('EU','US')`) ดีสำหรับการแยก tenant หรือ region

```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, index, maintenance

- **Partition pruning** ทำงานเฉพาะเมื่อ query filter บน **partition key** filter บนอย่างอื่นแล้วคุณสแกนทุก partition — ความผิดพลาดอันดับ 1
- **Local index** = หนึ่ง index ต่อ child (ค่าเริ่มต้นใน Postgres) build และ drop ถูกพร้อม partition **Global index** (Oracle) ครอบคลุมทุก partition — ช่วย unique lookup ข้าม partition แต่ต้อง rebuild เมื่อคุณ drop อันหนึ่ง
- **Maintenance** กลายเป็น O(partition): archive ข้อมูลเก่าด้วย `DROP TABLE orders_2019` (ทันที ไม่มี `DELETE` ยักษ์) และ `ATTACH`/`DETACH` สำหรับ rolling window

## มุมมองการสัมภาษณ์

ผู้สัมภาษณ์จี้ว่าคุณเข้าใจหรือไม่ว่า **partitioning ไม่ใช่ indexing** — มันลดข้อมูลที่สแกน ส่วน index ลด row ที่ตรวจภายในการสแกน คุณมักต้องการทั้งสอง คำตอบที่ดีระบุ range/hash/list คำตอบที่เยี่ยมเน้นว่า **partition key ต้องตรงกับ filter ของ query หลัก**, เตือนว่า key ที่ผิดฆ่า pruning และกล่าวถึง archival ราคาถูกผ่าน `DROP`

**ข้อแลกเปลี่ยน:** cross-partition query (ไม่มี key filter หรือ unique constraint ข้าม partition) ช้าลงและการบังคับ unique ยากขึ้น อย่า partition ตาราง 10M row — คุณเพิ่มความซับซ้อนในการดำเนินงานโดยไม่ได้อะไร partition เมื่อตารางใหญ่มาก **และ** query scope ตาม key โดยธรรมชาติ

รูปร่างของตารางที่ partition แล้ว

การเลือกกลยุทธ์ partition

Pruning, index, maintenance

มุมมองการสัมภาษณ์

คำถามที่เกี่ยวข้อง