PostgreSQL Partitioning Home Lab Setup — คู่มือฉบับสมบูรณ์ 2026 | SiamCafe Blog

รู้จักกับ PostgreSQL Partitioning และความสำคัญในโลกยุคข้อมูลใหญ่

ในยุคที่ข้อมูลเติบโตอย่างก้าวกระโดด การจัดการฐานข้อมูลให้มีประสิทธิภาพสูงสุดกลายเป็นความท้าทายอันดับต้นของนักพัฒนาและผู้ดูแลระบบ PostgreSQL (หรือที่เรียกกันติดปากว่า “โพสเกรส”) ได้นำเสนอฟีเจอร์ที่ทรงพลังอย่าง Partitioning หรือการแบ่งตารางออกเป็นส่วนย่อย เพื่อเพิ่มประสิทธิภาพในการค้นหา ลดภาระการจัดการข้อมูล และทำให้ระบบทำงานได้รวดเร็วขึ้นอย่างมีนัยสำคัญ

บทความนี้จะพาคุณไปรู้จักกับ PostgreSQL Partitioning ตั้งแต่พื้นฐานจนถึงการติดตั้งจริงในห้องแล็บส่วนตัว (Home Lab) สำหรับปี 2026 โดยเน้นการปฏิบัติจริงพร้อมตัวอย่างโค้ดที่สามารถนำไปปรับใช้ได้ทันที ไม่ว่าคุณจะเป็นผู้ดูแลระบบมือใหม่หรือมืออาชีพที่ต้องการเพิ่มประสิทธิภาพให้กับฐานข้อมูลขนาดใหญ่

ทำไมต้อง Partitioning?

ลองนึกภาพตารางที่มีข้อมูลมากกว่า 100 ล้านแถว เช่น ตารางบันทึกการเข้าชมเว็บไซต์ (access logs) หรือธุรกรรมการเงินที่เพิ่มขึ้นวันละหลายแสนรายการ การ Query ข้อมูลจะช้าลงเรื่อยๆ แม้จะมี Index ที่ดีแล้วก็ตาม Partitioning จะช่วยแบ่งข้อมูลออกเป็นส่วนย่อยตามเกณฑ์ที่กำหนด ทำให้ Database Engine สามารถข้ามส่วนที่ไม่เกี่ยวข้องได้ (Partition Pruning) ส่งผลให้ความเร็วในการค้นหาเพิ่มขึ้นหลายเท่า

ประเภทของ Partitioning ใน PostgreSQL (2026)

PostgreSQL รองรับ Partitioning หลายรูปแบบ ขึ้นอยู่กับลักษณะข้อมูลและความต้องการในการจัดการ:

การตั้งค่า Home Lab สำหรับ PostgreSQL Partitioning

การเริ่มต้นใน Home Lab ช่วยให้คุณทดลองและเรียนรู้โดยไม่กระทบระบบจริง สำหรับปี 2026 เราจะใช้ PostgreSQL 16 หรือ 17 ซึ่งมีฟีเจอร์ Partitioning ที่สมบูรณ์และมีประสิทธิภาพสูง

1. การติดตั้ง PostgreSQL ใน Docker (แนะนำสำหรับ Home Lab)

การใช้ Docker ช่วยให้การติดตั้งและล้างระบบทำได้ง่าย สะดวกสำหรับการทดลอง:

# สร้าง Docker container สำหรับ PostgreSQL 17
docker run --name pg17-lab \
  -e POSTGRES_PASSWORD=mysecretpassword \
  -e POSTGRES_DB=partition_lab \
  -p 5432:5432 \
  -d postgres:17-alpine

# เข้าไปใน container
docker exec -it pg17-lab psql -U postgres -d partition_lab

2. การเชื่อมต่อและเตรียมฐานข้อมูล

เมื่อเข้าสู่ psql แล้ว ให้สร้างฐานข้อมูลและเปิดใช้งาน extension ที่จำเป็น:

-- สร้างฐานข้อมูล (ถ้ายังไม่มี)
CREATE DATABASE partition_lab;

-- เชื่อมต่อฐานข้อมูล
\c partition_lab

-- เปิดใช้งาน pg_partman (optional แต่แนะนำ)
CREATE EXTENSION IF NOT EXISTS pg_partman;
CREATE EXTENSION IF NOT EXISTS pg_stat_statements;

การสร้าง Partitioned Table: ตัวอย่างจริง

กรณีศึกษา: การบันทึกข้อมูลการเข้าใช้งานเว็บไซต์ (Access Logs)

สมมติว่าเรามีตารางบันทึกการเข้าใช้งานที่มีข้อมูลมากกว่า 50 ล้านแถวต่อเดือน การใช้ Range Partitioning ตามวันที่ (รายเดือน) จะช่วยให้การ Query ข้อมูลในเดือนล่าสุดทำได้เร็วขึ้น และการลบข้อมูลเก่าก็ทำได้ง่ายเพียงแค่ DROP Partition

-- สร้าง Master Table (Partitioned Table)
CREATE TABLE access_logs (
    log_id BIGSERIAL,
    user_id INT NOT NULL,
    ip_address INET,
    access_time TIMESTAMPTZ NOT NULL,
    page_url TEXT,
    http_status INT,
    duration_ms INT,
    PRIMARY KEY (log_id, access_time)
) PARTITION BY RANGE (access_time);

-- สร้าง Partition รายเดือน (ตัวอย่างปี 2026)
CREATE TABLE access_logs_2026_01 PARTITION OF access_logs
    FOR VALUES FROM ('2026-01-01') TO ('2026-02-01');

CREATE TABLE access_logs_2026_02 PARTITION OF access_logs
    FOR VALUES FROM ('2026-02-01') TO ('2026-03-01');

CREATE TABLE access_logs_2026_03 PARTITION OF access_logs
    FOR VALUES FROM ('2026-03-01') TO ('2026-04-01');

-- เพิ่ม Index ในแต่ละ partition (หรือใช้ Index บน Master Table ก็ได้)
CREATE INDEX idx_access_logs_2026_01_time ON access_logs_2026_01 (access_time);
CREATE INDEX idx_access_logs_2026_02_time ON access_logs_2026_02 (access_time);
CREATE INDEX idx_access_logs_2026_03_time ON access_logs_2026_03 (access_time);

การเพิ่มข้อมูลและทดสอบ Partition Pruning

เมื่อ Insert ข้อมูลลงใน Master Table PostgreSQL จะจัดเก็บข้อมูลไปยัง partition ที่ถูกต้องโดยอัตโนมัติ:

-- เพิ่มข้อมูลตัวอย่าง
INSERT INTO access_logs (user_id, ip_address, access_time, page_url, http_status, duration_ms)
VALUES 
    (1, '192.168.1.10', '2026-01-15 10:30:00+07', '/home', 200, 45),
    (2, '10.0.0.5', '2026-02-20 14:15:00+07', '/products', 200, 120),
    (3, '172.16.0.1', '2026-03-10 08:00:00+07', '/checkout', 404, 30);

-- ทดสอบ Partition Pruning: EXPLAIN จะแสดงว่า scan เฉพาะ partition ที่เกี่ยวข้อง
EXPLAIN (ANALYZE, BUFFERS)
SELECT * FROM access_logs 
WHERE access_time >= '2026-02-01' AND access_time < '2026-03-01';

ผลลัพธ์จาก EXPLAIN จะแสดงให้เห็นว่า PostgreSQL ทำการ Seq Scan เฉพาะ partition access_logs_2026_02 เท่านั้น โดยไม่แตะ partition อื่น ซึ่งเป็นหัวใจของประสิทธิภาพ

การจัดการ Partition อัตโนมัติด้วย pg_partman

การสร้าง partition ด้วยมือทุกเดือนอาจไม่สะดวก โดยเฉพาะเมื่อต้องจัดการหลายตาราง pg_partman เป็น extension ที่ช่วยให้การสร้างและบำรุงรักษา partition เป็นไปโดยอัตโนมัติ

การติดตั้งและตั้งค่า pg_partman

-- ติดตั้ง pg_partman (ถ้ายังไม่ได้ทำ)
CREATE EXTENSION IF NOT EXISTS pg_partman;

-- สร้างตารางที่จะใช้ pg_partman จัดการ
CREATE TABLE sensor_data (
    sensor_id INT NOT NULL,
    reading_time TIMESTAMPTZ NOT NULL,
    temperature NUMERIC(5,2),
    humidity NUMERIC(5,2),
    PRIMARY KEY (sensor_id, reading_time)
) PARTITION BY RANGE (reading_time);

-- กำหนดให้ pg_partman จัดการ partition แบบรายวัน
SELECT partman.create_parent(
    p_parent_table := 'public.sensor_data',
    p_control := 'reading_time',
    p_type := 'native',
    p_interval := '1 day',
    p_premake := 30
);

-- ตรวจสอบสถานะ partition
SELECT * FROM partman.part_config;

เมื่อตั้งค่าแล้ว pg_partman จะสร้าง partition ล่วงหน้า 30 วัน และเมื่อถึงเวลาเปลี่ยนวัน ก็จะสร้าง partition ใหม่ให้โดยอัตโนมัติ (ต้องตั้ง cron job หรือใช้ pg_cron เพื่อเรียกฟังก์ชัน partman.run_maintenance() เป็นระยะ)

การจัดการข้อมูลเก่า: Archiving และ Dropping Partition

หนึ่งในประโยชน์สำคัญของ Partitioning คือการจัดการข้อมูลเก่าได้อย่างมีประสิทธิภาพ โดยไม่ต้องทำ DELETE ครั้งใหญ่ที่ทำให้เกิด bloat และ lock ตาราง

กลยุทธ์การเก็บถาวร (Archiving)

สำหรับข้อมูลที่ต้องเก็บไว้ตามกฎหมาย (เช่น 7 ปี) เราสามารถ Detach Partition แล้วย้ายไปยัง tablespace ที่ช้ากว่า (เช่น HDD) หรือ export ออกเป็นไฟล์:

-- Detach partition ที่เก่ากว่า 90 วัน
ALTER TABLE access_logs DETACH PARTITION access_logs_2025_12;

-- ย้ายไปยัง tablespace สำหรับ archive (สมมติมี tablespace archive_ts)
ALTER TABLE access_logs_2025_12 SET TABLESPACE archive_ts;

-- หรือ export ออกเป็น CSV
COPY access_logs_2025_12 TO '/backup/access_logs_2025_12.csv' DELIMITER ',' CSV HEADER;

-- หลังจาก export เสร็จก็สามารถ DROP partition ได้
DROP TABLE IF EXISTS access_logs_2025_12;

การลบข้อมูลเก่าอัตโนมัติด้วย Function

เราสามารถสร้างฟังก์ชันที่ทำงานตามกำหนดเวลา (เช่น ทุกวันเที่ยงคืน) เพื่อลบ partition ที่เก่าเกินกำหนด:

CREATE OR REPLACE FUNCTION drop_old_partitions()
RETURNS VOID AS $$
DECLARE
    part_name TEXT;
BEGIN
    FOR part_name IN 
        SELECT inhrelid::regclass::text
        FROM pg_inherits
        WHERE inhparent = 'access_logs'::regclass
          AND to_timestamp(
              substring(inhrelid::regclass::text from 'access_logs_(\d{4})_(\d{2})'),
              'YYYY-MM'
          ) < NOW() - INTERVAL '6 months'
    LOOP
        EXECUTE format('DROP TABLE IF EXISTS %I', part_name);
        RAISE NOTICE 'Dropped partition: %', part_name;
    END LOOP;
END;
$$ LANGUAGE plpgsql;

-- ทดสอบเรียกใช้
SELECT drop_old_partitions();

การเปรียบเทียบประสิทธิภาพ: Partitioned vs Non-Partitioned

เพื่อให้เห็นภาพชัดเจน เราจะทำการทดสอบอย่างง่ายใน Home Lab โดยใช้ข้อมูลจำลอง 10 ล้านแถว:

จากตารางจะเห็นว่า Partitioning ไม่เพียงแต่เพิ่มความเร็วในการ Query แต่ยังช่วยลดภาระการบำรุงรักษา (Maintenance) ลงได้อย่างมาก โดยเฉพาะในระบบที่ต้องจัดการข้อมูลขนาดใหญ่เป็นประจำ

ข้อควรระวังและ Best Practices

1. การเลือก Partition Key ที่เหมาะสม

Partition Key ควรเป็นคอลัมน์ที่ใช้ใน WHERE clause บ่อยๆ เช่น วันที่ หรือรหัสภูมิภาค หาก Query ส่วนใหญ่ไม่ได้กรองตาม Partition Key ก็จะไม่เกิด Partition Pruning และประสิทธิภาพอาจแย่ลง

2. การจัดการ Primary Key และ Unique Constraint

ใน PostgreSQL Partitioned Table คอลัมน์ที่ใช้เป็น Primary Key หรือ Unique Constraint ต้องรวม Partition Key ด้วย มิฉะนั้นจะเกิดข้อผิดพลาด:

-- ตัวอย่างที่ถูกต้อง
CREATE TABLE orders (
    order_id BIGSERIAL,
    order_date DATE NOT NULL,
    customer_id INT,
    amount NUMERIC(10,2),
    PRIMARY KEY (order_id, order_date)  -- ต้องรวม partition key
) PARTITION BY RANGE (order_date);

3. จำนวน Partition ที่เหมาะสม

อย่าสร้าง partition มากเกินไป (เช่น รายชั่วโมงสำหรับข้อมูลที่ไม่เยอะมาก) เพราะจะทำให้ overhead ในการจัดการสูง PostgreSQL แนะนำให้มี partition ไม่เกิน 1000-2000 partition ต่อตาราง (แล้วแต่เวอร์ชัน) สำหรับ Home Lab ควรเริ่มจากรายเดือนหรือรายสัปดาห์

4. การใช้ Tablespace แยกตาม Partition

สำหรับระบบที่มีหลายดิสก์ (เช่น NVMe + HDD) สามารถจัดเก็บ partition ที่ใช้งานบ่อยไว้ใน SSD และ partition เก่าไว้ใน HDD:

-- สร้าง tablespace
CREATE TABLESPACE fast_ssd LOCATION '/mnt/ssd/postgres_data';
CREATE TABLESPACE slow_hdd LOCATION '/mnt/hdd/postgres_archive';

-- สร้าง partition บน tablespace ต่างกัน
CREATE TABLE access_logs_2026_01 PARTITION OF access_logs
    FOR VALUES FROM ('2026-01-01') TO ('2026-02-01')
    TABLESPACE fast_ssd;

CREATE TABLE access_logs_2025_01 PARTITION OF access_logs
    FOR VALUES FROM ('2025-01-01') TO ('2025-02-01')
    TABLESPACE slow_hdd;

5. การ Monitor และ Alerting

ควรตั้งค่า Monitoring เพื่อตรวจสอบขนาดของแต่ละ partition และแจ้งเตือนเมื่อ partition ใกล้เต็มหรือมีจำนวนมากเกินไป เครื่องมือเช่น pgAdmin, pg_stat_statements หรือ Grafana + Prometheus สามารถช่วยได้

กรณีการใช้งานจริง (Real-World Use Cases)

1. ระบบบันทึก IoT Sensor Data

บริษัทที่ติดตั้งเซ็นเซอร์หลายพันตัวจะส่งข้อมูลทุกนาที ทำให้มีข้อมูลวันละหลายล้านแถว การใช้ Range Partitioning แบบรายวันช่วยให้ Query ข้อมูลย้อนหลัง 7 วันทำได้รวดเร็ว และสามารถลบข้อมูลที่เก่ากว่า 90 วันโดยการ DROP Partition โดยตรง

2. ระบบ E-commerce และธุรกรรมการเงิน

ร้านค้าออนไลน์ที่มีธุรกรรมวันละหลายแสนรายการ สามารถใช้ List Partitioning แบ่งตามสถานะคำสั่งซื้อ (pending, confirmed, shipped, cancelled) เพื่อให้การ Query สถานะใดสถานะหนึ่งทำได้เร็วขึ้น หรือใช้ Range Partitioning ตามวันที่เพื่อการรายงานรายเดือน

3. ระบบ Logging และ Audit Trail

องค์กรที่ต้องเก็บ log ตามกฎหมาย (เช่น การเงิน หรือสาธารณสุข) มักต้องเก็บข้อมูลไว้หลายปี Partitioning ช่วยให้สามารถแยก partition ตามปี และเมื่อถึงกำหนดลบ ก็สามารถ DROP partition ทั้งปีได้ทันที โดยไม่ต้องทำ DELETE ที่ใช้เวลานาน

4. ระบบวิเคราะห์ข้อมูล (Analytics) แบบ Time-Series

สำหรับ Data Warehouse ขนาดเล็กในองค์กร การใช้ Partitioning ร่วมกับ Materialized Views ช่วยให้การทำ Reporting รายวัน/รายเดือนทำได้รวดเร็ว โดยเฉพาะเมื่อใช้กับเครื่องมืออย่าง Apache Superset หรือ Metabase

การแก้ไขปัญหาที่พบบ่อย (Troubleshooting)

ปัญหา: Query ไม่ใช้ Partition Pruning

สาเหตุหลักคือเงื่อนไข WHERE ไม่ตรงกับ Partition Key หรือมีการใช้ฟังก์ชันกับ Partition Key เช่น WHERE DATE(access_time) = '2026-01-15' แทนที่จะเป็น WHERE access_time >= '2026-01-15' AND access_time < '2026-01-16'

วิธีแก้: ใช้ Range condition แทน function call เสมอ หรือสร้าง functional index เพิ่มเติม

ปัญหา: การ Insert ข้อมูลช้าลงหลังทำ Partition

ถ้าพบว่า Insert ช้าลง อาจเกิดจากจำนวน partition ที่มากเกินไป หรือการตั้งค่า constraint_exclusion ไม่เหมาะสม ลองปรับ:

SET constraint_exclusion = partition;
-- หรือตั้งค่าใน postgresql.conf
-- constraint_exclusion = partition

ปัญหา: Partition มีขนาดไม่เท่ากัน (Data Skew)

เมื่อใช้ List Partitioning หรือ Hash Partitioning ข้อมูลอาจกระจายไม่เท่ากัน ควรตรวจสอบด้วย Query:

SELECT 
    inhrelid::regclass AS partition_name,
    pg_size_pretty(pg_total_relation_size(inhrelid::regclass)) AS size
FROM pg_inherits
WHERE inhparent = 'access_logs'::regclass
ORDER BY pg_total_relation_size(inhrelid::regclass) DESC;

ถ้าพบ partition ใดมีขนาดใหญ่เกินไป ควรปรับกลยุทธ์การแบ่ง เช่น เพิ่มจำนวน partition หรือเปลี่ยนเป็น Hash Partitioning

การอัปเกรดและย้ายข้อมูลจากระบบเดิมสู่ Partitioned Table

สำหรับฐานข้อมูลที่มีอยู่แล้วและต้องการเปลี่ยนเป็น Partitioned Table โดยไม่หยุดระบบ (Zero Downtime) สามารถทำได้หลายวิธี:

วิธีที่ 1: สร้างตารางใหม่แล้วค่อยๆ ย้ายข้อมูล

-- สร้าง partitioned table ใหม่
CREATE TABLE access_logs_new (LIKE access_logs INCLUDING ALL)
PARTITION BY RANGE (access_time);

-- สร้าง partition สำหรับข้อมูลที่มีอยู่
CREATE TABLE access_logs_2025_12 PARTITION OF access_logs_new
    FOR VALUES FROM ('2025-12-01') TO ('2026-01-01');

-- ย้ายข้อมูลในรอบที่ระบบว่าง
INSERT INTO access_logs_new SELECT * FROM access_logs 
WHERE access_time >= '2025-12-01' AND access_time < '2026-01-01';

-- ใช้トリกเกอร์เพื่อซิงค์ข้อมูลใหม่ระหว่างย้าย
CREATE OR REPLACE FUNCTION sync_access_logs()
RETURNS TRIGGER AS $$
BEGIN
    INSERT INTO access_logs_new VALUES (NEW.*);
    RETURN NEW;
END;
$$ LANGUAGE plpgsql;

CREATE TRIGGER trg_sync_access_logs
    AFTER INSERT ON access_logs
    FOR EACH ROW EXECUTE FUNCTION sync_access_logs();

-- เมื่อย้ายเสร็จทั้งหมด ให้เปลี่ยนชื่อตาราง
ALTER TABLE access_logs RENAME TO access_logs_old;
ALTER TABLE access_logs_new RENAME TO access_logs;
DROP TABLE access_logs_old;

วิธีที่ 2: ใช้ pg_partman สำหรับการย้ายข้อมูลอัตโนมัติ

pg_partman มีฟังก์ชัน partition_data_proc() ที่ช่วยย้ายข้อมูลจากตารางปกติไปยัง partitioned table ได้โดยอัตโนมัติ ตามช่วงเวลาที่กำหนด

สรุปแนวทางการตั้งค่า Home Lab สำหรับปี 2026

สำหรับผู้ที่ต้องการเริ่มต้นทดลอง PostgreSQL Partitioning ใน Home Lab ควรปฏิบัติตามขั้นตอนดังนี้:

1. ติดตั้ง PostgreSQL 17 บน Docker หรือเครื่องจริง พร้อมเปิดใช้งาน extensions ที่จำเป็น
2. ออกแบบ Partition Key โดยพิจารณาจากลักษณะการ Query ที่ใช้บ่อยที่สุด
3. สร้าง Partitioned Table โดยเลือกประเภทให้เหมาะสม (Range สำหรับ Time-series, List สำหรับกลุ่มค่า, Hash สำหรับการกระจาย)
4. ตั้งค่า pg_partman สำหรับการสร้าง partition อัตโนมัติ และกำหนด cron job หรือใช้ pg_cron เรียก maintenance
5. ทดสอบประสิทธิภาพ ด้วย EXPLAIN ANALYZE และเปรียบเทียบกับตารางปกติ
6. วางแผนการจัดการข้อมูลเก่า ทั้งการ Archive และ DROP Partition ตามนโยบายการเก็บข้อมูล
7. Monitor ขนาด partition และแจ้งเตือนเมื่อถึงเกณฑ์ที่กำหนด

Summary

PostgreSQL Partitioning เป็นเครื่องมือที่จำเป็นอย่างยิ่งสำหรับฐานข้อมูลขนาดใหญ่ในยุค 2026 ไม่ว่าคุณจะดูแลระบบ E-commerce, IoT, หรือระบบ Logging การแบ่งตารางอย่างเหมาะสมจะช่วยเพิ่มประสิทธิภาพการ Query ลดเวลาการบำรุงรักษา และทำให้การจัดการข้อมูลเก่าเป็นเรื่องง่าย

การเริ่มต้นใน Home Lab ช่วยให้คุณเรียนรู้และทดลองโดยไม่ต้องกังวลเรื่องผลกระทบต่อระบบจริง ด้วย Docker และ PostgreSQL 17 คุณสามารถจำลองสถานการณ์จริงได้อย่างใกล้ชิด และเมื่อเข้าใจหลักการแล้ว ก็สามารถนำไปปรับใช้กับระบบ Production ได้อย่างมั่นใจ

อย่าลืมว่า Partitioning ไม่ใช่ silver bullet ที่แก้ปัญหาทุกอย่าง ควรออกแบบให้เหมาะสมกับลักษณะข้อมูลและรูปแบบการใช้งานของแอปพลิเคชันของคุณ และหมั่นตรวจสอบประสิทธิภาพอย่างสม่ำเสมอเพื่อปรับแต่งให้เหมาะสมที่สุด

สำหรับข้อมูลเพิ่มเติม สามารถติดตามบทความ和技术อื่นๆ ได้ที่ SiamCafe Blog หรือร่วมพูดคุยในกลุ่มผู้ใช้ PostgreSQL ชุมชนคนไทย