Table partitioning คืออะไร?

Question

Accepted Answer

**Partitioning** แบ่งตารางขนาดใหญ่ออกเป็นชิ้นทางกายภาพที่เล็กกว่า (**partitions**) ตามค่าของคอลัมน์ — ในขณะที่ยังคงปรากฏเป็นตารางเชิงตรรกะเดียวสำหรับ query มันปรับปรุงประสิทธิภาพและการจัดการสำหรับตารางขนาดใหญ่มาก โดยให้ฐานข้อมูลสแกนหรือดูแลรักษาเฉพาะ partition ที่เกี่ยวข้อง

## Partitioning ทำงานอย่างไร

```sql
-- a huge `orders` table partitioned BY RANGE on the order date
CREATE TABLE orders (id INT, order_date DATE, amount DECIMAL)
PARTITION BY RANGE (order_date);

CREATE TABLE orders_2023 PARTITION OF orders
  FOR VALUES FROM ('2023-01-01') TO ('2024-01-01');
CREATE TABLE orders_2024 PARTITION OF orders
  FOR VALUES FROM ('2024-01-01') TO ('2025-01-01');
-- orders is ONE logical table, but stored as separate per-year partitions
```

ตารางเป็นเอนทิตีเชิงตรรกะเดียว แต่ถูกจัดเก็บทางกายภาพใน partitions Query และ inserts จะไปยัง partition ที่ถูกต้องโดยอัตโนมัติ

## ประโยชน์หลัก: partition pruning

```sql
-- a query filtered by the partition key only scans RELEVANT partitions
SELECT * FROM orders WHERE order_date >= '2024-06-01';
-- → the database skips orders_2023 entirely, scanning only orders_2024 ("partition pruning")
```

**Partition pruning** เป็นชัยชนะด้านประสิทธิภาพหลัก: query ที่กรองบน partition key จะแตะเฉพาะ partition ที่เกี่ยวข้อง โดยข้ามที่เหลือ — เปลี่ยนการสแกนหลายพันล้านแถวให้เป็นการสแกนเฉพาะส่วนย่อยที่เกี่ยวข้อง

## กลยุทธ์ partitioning

```text
RANGE → by a value range (dates, numeric ranges) — common for time-series data
LIST  → by a list of discrete values (region, category)
HASH  → by a hash of the key (even distribution across partitions)
```

## ประโยชน์อื่น ๆ

```text
✓ Maintenance — drop/archive old data by dropping a whole partition (instant vs DELETE)
  e.g. DROP TABLE orders_2020 — far faster than DELETE WHERE year = 2020
✓ Smaller indexes per partition; parallel operations across partitions
✓ Manage huge tables in manageable pieces
```

## เมื่อใดควรใช้ partitioning

```text
✓ VERY LARGE tables (hundreds of millions / billions of rows) where queries filter
  on a natural partition key (often time/date for logs, events, orders)
✓ Time-series data where you regularly archive/drop old data
✗ Small/medium tables — partitioning adds complexity with little benefit
  (proper indexing usually suffices)
→ Partitioning complements indexing for VERY large tables; it's not a substitute.
```

## ทำไมจึงสำคัญ

Table partitioning เป็นเทคนิคสำคัญสำหรับการจัดการและ query **ตารางขนาดใหญ่มาก** และการเข้าใจมันเป็นความรู้ระดับ senior ที่มีคุณค่าสำหรับการทำงานกับฐานข้อมูลในระดับใหญ่

เมื่อตารางเติบโตถึงหลายร้อยล้านหรือหลายพันล้านแถว แม้แต่ query ที่มี index และการดำเนินการดูแลรักษาก็อาจช้าลง และ partitioning จัดการกับสิ่งนี้ด้วยการแบ่งตารางออกเป็นชิ้นทางกายภาพที่เล็กกว่า

ประโยชน์ด้านประสิทธิภาพหลักคือ **partition pruning** — query ที่กรองบน partition key จะสแกนเฉพาะ partition ที่เกี่ยวข้อง (ข้ามที่เหลือ) ซึ่งลดข้อมูลที่สแกนสำหรับตารางขนาดใหญ่อย่างมาก (พบบ่อยเป็นพิเศษสำหรับข้อมูล time-series ที่กรองตามวันที่)

นอกเหนือจากประสิทธิภาพของ query แล้ว partitioning ยังให้ **ประโยชน์ด้านการดูแลรักษา** ที่สำคัญ: การ archive หรือลบข้อมูลเก่ากลายเป็นทันที (การ drop ทั้ง partition แทนที่จะเป็น `DELETE` ที่ช้าและมีต้นทุนสูงของข้อมูลหลายล้านแถว — ข้อได้เปรียบด้านการดำเนินงานที่สำคัญสำหรับข้อมูล log/event ที่มีนโยบายการเก็บรักษา) บวกกับ index ต่อ partition ที่เล็กกว่าและการดำเนินการแบบขนาน

การเข้าใจ **กลยุทธ์** (RANGE สำหรับช่วงวันที่/ตัวเลข — พบบ่อยสำหรับ time-series; LIST สำหรับค่าที่ไม่ต่อเนื่อง; HASH สำหรับการกระจายที่สม่ำเสมอ) และที่สำคัญคือ **เมื่อใดควรใช้ partitioning** (ตารางขนาดใหญ่มากที่มี partition key ตามธรรมชาติ โดยเฉพาะ time-series ที่มีการ archive เป็นประจำ — *ไม่ใช่* ตารางขนาดเล็ก/กลางที่การทำ index ก็เพียงพอและ partitioning เพียงเพิ่มความซับซ้อน) สะท้อนถึงวิจารณญาณที่เป็นผู้ใหญ่

เนื่องจากการจัดการตารางขนาดใหญ่มากเป็นความท้าทายที่แท้จริงในระบบที่ scale แล้ว และเนื่องจาก partitioning (ด้วย partition pruning และการดูแลรักษาที่มีประสิทธิภาพ) เป็นเครื่องมือมาตรฐานสำหรับมัน — เสริมแทนที่จะแทนที่การทำ index — การเข้าใจ table partitioning จึงเป็นความรู้ระดับ senior ที่มีคุณค่าสำหรับความสามารถในการ scale ของฐานข้อมูล โดยเฉพาะเกี่ยวข้องกับระบบข้อมูลขนาดใหญ่, time-series หรือปริมาณสูง และเป็นหัวข้อที่แสดงถึงความเข้าใจการจัดการฐานข้อมูลในระดับใหญ่