จาก blog เรื่อง PostgreSQL 19 beta ทำการปรับปรุงความสามารถของ partitioning table
คือการเพิ่มการ merge และ split partition เข้ามา (maintenance partition)
เพื่อช่วยแยกหรือรวมข้อมูลหลังจากที่ข้อมูลเกิดขึ้นมา
ซึ่งอาจจะไม่ตรงตามที่คิดหรือคาดหวังไว้
โดยมีคำถามเกี่ยวกับ partition table มันเป็นอย่างไร ?
จึงทำการอธิบายให้นิดหน่อยดังนี้
ก่อนอื่นต้องเข้าใจเรื่องของ partition table ก่อน
เป็นแนวทางในการแบ่งข้อมูลใน table เดียวกันออกเป็นกลุ่ม ๆ ตามความต้องการ
เช่นแบ่งตามวันเวลา
เช่นแบ่งตามกลุ่มของข้อมูล
เช่นแบ่งตามการ hash หรือใช้ modulo เอาก็ได้
เพื่อช่วยให้การจัดเก็บข้อมูล และ การเข้าถึงข้อมูลง่ายและรวดเร็วมากขึ้น
ยกตัวอย่างของปัญหา
เช่นการจัดเก็บข้อมูล order หรือ การคำสั่งซื้อในระบบ e-commerce
ปกติก็จะทำการเก็บลง table order ไปเรื่อย ๆ
ซึ่งจะใช้ disk/memory มาขึ้นเรื่อย ๆ
ไม่ใช้มีแค่ข้อมูลเท่านั้น แต่ยังไม่ index ต่าง ๆ ที่สร้างขึ้นมา
คำถามคือ
ข้อมูล order ที่จัดเก็บไปนั้นมีจำนวนเยอะหรือไม่ ?
การดึงข้อมูลเริ่มช้าลง เมื่อมีจำนวนข้อมูลมากขึ้น (table bloat) และ ผู้ใช้งานมากขึ้นไหม ?
แก้ไขเบื้องต้นด้วยการ restart database server เรื่อย ๆ ไหม ?
แก้ไขต่อมาด้วยการเพิ่ม Memory/CPU ของเครื่องให้เยอะขึ้นไหม ?
เริ่มทำการ ANALYZE Query และแก้ไขให้ดีขึ้น แต่ก็ยังช้าไหม ?
ไม่พอ ในการดึงข้อมูล order นั้น ส่วนใหญ่ใช้ข้อมูลอย่างไร ?
เช่น ส่วนใหญ่ดึงข้อมูล order เฉพาะในวันนั้น ๆ
ซึ่งอาจจะเป็นการใช้งาน 70-80% ของระบบงานเลย
แต่พอกลับมาดูการ query ข้อมูล แล้วพบว่า
ยัง query ข้อมูล order ทั้งหมด แล้วมา filter เฉพาะของวันนี้ !!
แบบนี้คิดว่า เป็นแนวทางที่ดีหรือไม่ ?
ถ้าบอกว่า ใช่ ก็จบตรงนี้
แต่ถ้าไม่ก็ไปต่อกัน
หนึ่งในแนวทางที่น่าสนใจคือ การใช้งาน partition data/table
โดยมีทั้งการแบ่ง partitioning table/data ใน PostgreSQL แบบเครื่องเดียวกัน
ดังนั้นจะติด limit ที่ resource ของเครื่องนั้น ๆ นั่นเอง
เพื่อความเข้าใจมาลองใช้งาน partition table กันดู
โดยการใช้งานนั้นจะมีขั้นตอนง่าย ๆ ดังนี้
- ต้องรู้การใช้งานข้อมูลใน table นั้นเป็นอย่างไร
- ทำการสร้าง table + partition key
- ทำการสร้าง partition table ขึ้นมาตาม partition key
- อย่าลืมสร้าง default partition table ด้วย เพราะว่า ถ้าไม่มี partition แล้ว ข้อมูลจะ insert/update ไม่ได้
สิ่งที่ควรรู้คือ สามารถเข้าถึงผ่านชื่อ table หลัก หรือ partition table ตรง ๆ ก็ได้
และ index ก็จะถูกสร้างแยกตาม partition table ไปเลย ทำให้ขนาดเล็ก และ การเข้าถึงเร็วขึ้น
และสิ่งที่สำคัญสุด ๆ อย่าดึงข้อมูลข้าม partition !!
ตัวอย่างเช่น table order จะแบ่งตาม order creation date เป็นรายเดือน
ส่วนการ query นั้นอย่าข้าม partition แบบนี้
นั่นหมายความว่า แทนที่จะแก้ปัญหา กลับสร้างปัญหาใหม่ขึ้นมามากกว่า !!
ลองใช้งานกันดูครับ
เป็นอีกหนึ่งแนวทางในการแก้ไขปัญหา
