PostgreSQL Performance Tuning คู่มือปรับแต่งฐานข้อมูล

สวัสดีครับ! ในโลกของการพัฒนาซอฟต์แวร์และแอปพลิเคชันยุคใหม่ ฐานข้อมูลคือหัวใจสำคัญที่ขับเคลื่อนระบบให้ทำงานได้อย่างราบรื่นและมีประสิทธิภาพ แต่บ่อยครั้งที่ปัญหาคอขวดด้านประสิทธิภาพมักเกิดขึ้นที่ฐานข้อมูล โดยเฉพาะอย่างยิ่งเมื่อระบบเติบโตขึ้น มีข้อมูลมากขึ้น หรือมีผู้ใช้งานพร้อมกันจำนวนมาก PostgreSQL ซึ่งเป็นฐานข้อมูลเชิงวัตถุ-สัมพันธ์ (Object-Relational Database) โอเพนซอร์สที่ทรงพลังและได้รับความนิยมอย่างสูง ก็ไม่ใช่ข้อยกเว้นครับ การปรับแต่ง PostgreSQL ให้ทำงานได้อย่างเต็มศักยภาพจึงเป็นสิ่งจำเป็นอย่างยิ่ง เพื่อให้แอปพลิเคชันของคุณตอบสนองได้รวดเร็ว ลดเวลาการโหลด และมอบประสบการณ์ที่ดีที่สุดแก่ผู้ใช้งาน ในบทความนี้ SiamLancard.com จะพาคุณดำดิ่งสู่โลกของการปรับแต่ง PostgreSQL Performance Tuning อย่างละเอียด ตั้งแต่การทำความเข้าใจสถาปัตยกรรมเบื้องต้น ไปจนถึงเทคนิคการปรับแต่งไฟล์คอนฟิกูเรชัน การออกแบบ Index ที่มีประสิทธิภาพ การปรับแต่ง SQL Query และแม้กระทั่งการปรับแต่งระดับระบบปฏิบัติการ เราจะมาดูกันว่ามีกลยุทธ์อะไรบ้างที่จะช่วยให้ PostgreSQL ของคุณทำงานได้เร็วขึ้น เสถียรขึ้น และพร้อมรับมือกับทุกความท้าทายครับ

สารบัญ

• บทนำ: ทำไมต้องปรับแต่ง PostgreSQL?
• ทำความเข้าใจสถาปัตยกรรมของ PostgreSQL เบื้องต้น
  • กระบวนการหลัก (Processes)
  • หน่วยความจำ (Memory Areas)
  • การจัดเก็บข้อมูล (Storage Structures)
• การวิเคราะห์ปัญหาและตรวจสอบประสิทธิภาพ (Monitoring & Profiling)
  • เครื่องมือพื้นฐานในการตรวจสอบ
  • การตรวจสอบทรัพยากรระบบ (OS Level)
• การปรับแต่งไฟล์คอนฟิกูเรชัน (postgresql.conf) อย่างละเอียด
  • การจัดการหน่วยความจำ (Memory Management)
  • การจัดการ WAL (Write-Ahead Log)
  • การจัดการการเขียน/อ่านข้อมูล (Disk I/O)
  • การจัดการ Autovacuum
  • การจัดการ Connection
  • การปรับแต่งอื่นๆ ที่สำคัญ
• การปรับแต่ง SQL Query และ Indexing
  • การออกแบบ Index ที่มีประสิทธิภาพ
  • การเขียน Query ที่ดี
  • การใช้ VACUUM และ ANALYZE อย่างถูกวิธี
• การปรับแต่งระดับ Database และ Schema
  • การเลือกประเภทข้อมูลที่เหมาะสม
  • การ Normalization และ Denormalization
  • การ Partitioning Table
  • การใช้ Materialized Views
• การจัดการ Connection Pooling
• การปรับแต่งระดับระบบปฏิบัติการ (Operating System Tuning)
  • การจัดการ Disk I/O
  • การจัดการ Memory และ Swap
  • การปรับแต่ง Kernel Parameters (sysctl.conf)
• ตารางเปรียบเทียบ: กลยุทธ์การปรับแต่งที่พบบ่อย
• ข้อควรระวังและแนวทางปฏิบัติที่ดีที่สุด (Best Practices)
• คำถามที่พบบ่อย (FAQ)
• สรุปและ Call-to-Action

บทนำ: ทำไมต้องปรับแต่ง PostgreSQL?

ในยุคดิจิทัลที่ข้อมูลมีบทบาทสำคัญอย่างยิ่ง ประสิทธิภาพของฐานข้อมูลจึงเป็นปัจจัยชี้ขาดความสำเร็จของแอปพลิเคชันและบริการต่างๆ ครับ หากฐานข้อมูลทำงานช้า ไม่ว่าจะเป็นการตอบสนองต่อ Query ที่ใช้เวลานาน การเขียนข้อมูลที่ติดขัด หรือการประมวลผลธุรกรรมที่ล่าช้า ย่อมส่งผลกระทบโดยตรงต่อประสบการณ์ของผู้ใช้งาน (User Experience) และอาจนำไปสู่การสูญเสียโอกาสทางธุรกิจได้

PostgreSQL เป็นฐานข้อมูลที่เปี่ยมด้วยขีดความสามารถและฟีเจอร์มากมาย แต่ก็เหมือนกับเครื่องจักรประสิทธิภาพสูงอื่นๆ ครับ การที่จะดึงศักยภาพสูงสุดออกมาได้ จำเป็นต้องมีการปรับแต่ง (Tuning) ให้เหมาะสมกับภาระงาน (Workload) และทรัพยากรของระบบที่เรามีอยู่ หากไม่มีการปรับแต่งที่เหมาะสม PostgreSQL อาจใช้ทรัพยากรเกินความจำเป็น ทำงานได้ช้ากว่าที่ควร หรือแม้กระทั่งเกิดปัญหาคอขวดที่ทำให้ระบบล่มได้ครับ

วัตถุประสงค์ของบทความนี้คือการเป็นคู่มือที่ครอบคลุมและเจาะลึก เพื่อให้คุณสามารถเข้าใจหลักการและเทคนิคต่างๆ ในการปรับแต่ง PostgreSQL ได้อย่างถ่องแท้ ตั้งแต่ระดับสถาปัตยกรรมภายในไปจนถึงการปรับค่าคอนฟิกูเรชัน การเขียน Query ที่มีประสิทธิภาพ และการจัดการทรัพยากรระบบปฏิบัติการ เพื่อให้ฐานข้อมูลของคุณทำงานได้รวดเร็ว เสถียร และรองรับการเติบโตของธุรกิจได้อย่างมั่นใจครับ

ทำความเข้าใจสถาปัตยกรรมของ PostgreSQL เบื้องต้น

ก่อนที่เราจะเริ่มปรับแต่งสิ่งใดๆ การทำความเข้าใจว่า PostgreSQL ทำงานอย่างไรจากภายในเป็นสิ่งสำคัญอย่างยิ่งครับ การรู้ถึงส่วนประกอบหลักๆ และวิธีการที่พวกมันโต้ตอบกันจะช่วยให้เราสามารถวินิจฉัยปัญหาและตัดสินใจปรับแต่งได้อย่างถูกต้องแม่นยำขึ้นครับ

กระบวนการหลัก (Processes)

PostgreSQL เป็นระบบที่ใช้สถาปัตยกรรมแบบ Multi-process ซึ่งประกอบด้วยกระบวนการ (processes) หลายตัวที่ทำงานร่วมกัน เพื่อจัดการการเชื่อมต่อ ประมวลผล Query และบำรุงรักษาฐานข้อมูลครับ

• Postmaster (หรือ Postgres): นี่คือกระบวนการหลักที่ทำหน้าที่เป็นผู้จัดการสูงสุดครับ Postmaster รับผิดชอบในการเริ่มต้นและปิดฐานข้อมูล จัดการการเชื่อมต่อขาเข้า และเปิดใช้งานกระบวนการย่อยอื่นๆ เช่น Backend Processes, Background Writer, WAL Writer เป็นต้น หาก Postmaster ล่ม กระบวนการทั้งหมดของ PostgreSQL ก็จะหยุดทำงานครับ
• Backend Processes (หรือ Server Processes): ทุกครั้งที่มีการเชื่อมต่อใหม่จากไคลเอนต์ (เช่น แอปพลิเคชัน) Postmaster จะสร้าง Backend Process แยกต่างหากขึ้นมาหนึ่งตัวเพื่อจัดการการเชื่อมต่อและ Query ของไคลเอนต์นั้นๆ โดยเฉพาะ Backend Process จะรับผิดชอบในการประมวลผล SQL Query, อ่าน/เขียนข้อมูล และส่งผลลัพธ์กลับไปยังไคลเอนต์ครับ
• Background Writer: กระบวนการนี้มีหน้าที่เขียนข้อมูลที่ “สกปรก” (dirty pages) ซึ่งอยู่ใน Shared Buffers กลับลงสู่ดิสก์อย่างสม่ำเสมอ เพื่อลดปริมาณงานที่ Checkpointer ต้องทำ และช่วยให้ระบบตอบสนองได้ดีขึ้นเมื่อมี Write Workload สูงครับ
• WAL Writer: WAL ย่อมาจาก Write-Ahead Log ครับ เป็นกลไกสำคัญในการรับประกันความสมบูรณ์ของข้อมูล (Data Integrity) WAL Writer มีหน้าที่เขียนข้อมูล WAL ที่อยู่ใน WAL Buffers ลงสู่ดิสก์ทันที ก่อนที่ข้อมูลจริงจะถูกเขียนลงดิสก์ เพื่อให้แน่ใจว่าการเปลี่ยนแปลงข้อมูลจะไม่สูญหายไปแม้ระบบจะล่มครับ
• Autovacuum Launcher: กระบวนการนี้จะคอยตรวจสอบตารางต่างๆ ในฐานข้อมูล และหากพบว่ามี “dead tuples” (ข้อมูลเก่าที่ถูกลบหรืออัปเดตไปแล้วแต่ยังคงอยู่ในตาราง) เป็นจำนวนมาก หรือสถิติของตารางล้าสมัย Autovacuum Launcher ก็จะเปิดใช้งาน Autovacuum Worker เพื่อทำการ VACUUM และ ANALYZE ตารางเหล่านั้นโดยอัตโนมัติ ช่วยป้องกันปัญหา Bloat และรักษาประสิทธิภาพของ Query Planner ครับ
• Checkpointer: Checkpointer มีหน้าที่เขียนข้อมูลที่เปลี่ยนแปลงทั้งหมดจาก Shared Buffers ลงสู่ดิสก์ และอัปเดตไฟล์ควบคุม (control file) เพื่อระบุจุดที่ข้อมูลถูกเขียนลงดิสก์อย่างสมบูรณ์แล้ว (checkpoint) การทำ Checkpoint ช่วยให้การกู้คืนระบบเมื่อเกิดความผิดพลาดทำได้เร็วขึ้นครับ

หน่วยความจำ (Memory Areas)

PostgreSQL ใช้หน่วยความจำ (RAM) อย่างชาญฉลาดเพื่อเพิ่มประสิทธิภาพในการเข้าถึงข้อมูลและลดการเข้าถึงดิสก์ ซึ่งเป็นส่วนที่ช้าที่สุดในระบบครับ

• Shared Buffers: นี่คือพื้นที่หน่วยความจำที่ใหญ่ที่สุดและสำคัญที่สุดตัวหนึ่งครับ Shared Buffers ใช้สำหรับเก็บข้อมูลของตารางและ Index ที่ถูกเข้าถึงบ่อยๆ ไว้ใน RAM เพื่อให้การอ่านข้อมูลครั้งต่อไปทำได้เร็วยิ่งขึ้น การปรับค่า shared_buffers ให้เหมาะสมกับ RAM ที่มีอยู่เป็นสิ่งสำคัญมากครับ
• WAL Buffers: พื้นที่หน่วยความจำสำหรับเก็บข้อมูล Write-Ahead Log ชั่วคราวก่อนที่จะถูกเขียนลงดิสก์ WAL Buffers มีขนาดค่อนข้างเล็ก แต่มีผลต่อประสิทธิภาพการเขียนข้อมูลครับ
• Work Memory (work_mem): เป็นพื้นที่หน่วยความจำส่วนตัวสำหรับแต่ละ Backend Process ที่ใช้สำหรับดำเนินการ Sorting (เช่น ORDER BY, GROUP BY) และ Hashing (เช่น Hash Joins) หากงานเหล่านี้ต้องการหน่วยความจำมากกว่าที่ work_mem กำหนด PostgreSQL จะต้องใช้ Temp Files บนดิสก์ ซึ่งทำให้การทำงานช้าลงอย่างมากครับ
• Maintenance Work Memory (maintenance_work_mem): คล้ายกับ work_mem แต่เป็นพื้นที่หน่วยความจำที่ใช้สำหรับงานบำรุงรักษาฐานข้อมูลโดยเฉพาะ เช่น VACUUM, ANALYZE, CREATE INDEX, ALTER TABLE ADD FOREIGN KEY การเพิ่มค่านี้นอกจากจะช่วยให้งานบำรุงรักษาเร็วขึ้นแล้ว ยังช่วยให้ Autovacuum ทำงานได้มีประสิทธิภาพมากขึ้นด้วยครับ
• Temp Buffers (temp_buffers): เป็นพื้นที่หน่วยความจำสำหรับเก็บตารางชั่วคราว (temporary tables) ที่ถูกสร้างขึ้นระหว่างการประมวลผล Query ครับ

การจัดเก็บข้อมูล (Storage Structures)

การจัดเก็บข้อมูลบนดิสก์ก็มีผลต่อประสิทธิภาพเช่นกันครับ

• Tablespaces: เป็นการกำหนดตำแหน่งบนดิสก์สำหรับจัดเก็บไฟล์ข้อมูลของตารางและ Index เราสามารถสร้าง Tablespace ใหม่บนดิสก์ที่เร็วกว่า หรือแยก Workload ของตารางสำคัญๆ ไปยังดิสก์คนละชุดได้ครับ
• Heap Tables: คือตารางข้อมูลจริงๆ ที่เก็บแถวข้อมูล (tuples) ไว้บนดิสก์ การเปลี่ยนแปลงข้อมูล เช่น INSERT, UPDATE, DELETE จะสร้าง “dead tuples” ซึ่งต้องถูกกำจัดออกไปโดย VACUUM ครับ
• Indexes: โครงสร้างข้อมูลที่ช่วยให้การค้นหาข้อมูลในตารางทำได้รวดเร็วขึ้น โดยไม่ต้องสแกนทั้งตาราง เหมือนกับดัชนีในหนังสือครับ การออกแบบ Index ที่เหมาะสมเป็นหัวใจสำคัญของการปรับแต่ง Query
• WAL (Write-Ahead Log): ไฟล์ Log ที่บันทึกการเปลี่ยนแปลงทั้งหมดที่เกิดขึ้นกับฐานข้อมูล เพื่อใช้ในการกู้คืนข้อมูลเมื่อเกิดความผิดพลาด WAL เป็นส่วนที่สำคัญมากสำหรับความสมบูรณ์ของข้อมูลและประสิทธิภาพการเขียนครับ

การวิเคราะห์ปัญหาและตรวจสอบประสิทธิภาพ (Monitoring & Profiling)

ก่อนที่เราจะเริ่มปรับแต่งอะไรลงไป การรู้ว่าปัญหาอยู่ที่ไหนคือสิ่งแรกที่เราต้องทำครับ การตรวจสอบ (Monitoring) และการวิเคราะห์ (Profiling) จะช่วยให้เราเข้าใจพฤติกรรมของฐานข้อมูลและระบุจุดคอขวดได้อย่างแม่นยำครับ

เครื่องมือพื้นฐานในการตรวจสอบ

PostgreSQL มีวิว (views) และฟังก์ชันในตัวที่ทรงพลังสำหรับการตรวจสอบประสิทธิภาพครับ

• pg_stat_activity: เป็นวิวที่แสดงกิจกรรมทั้งหมดที่กำลังเกิดขึ้นในฐานข้อมูล ณ ปัจจุบัน ช่วยให้เราเห็นว่ามี Query อะไรบ้างที่กำลังรันอยู่ ใครเป็นผู้ใช้งาน Query นั้นใช้เวลานานเท่าไหร่ และอยู่ในสถานะใด (เช่น active, idle, waiting) ครับ

SELECT
    pid,
    datname,
    usename,
    client_addr,
    application_name,
    backend_start,
    state,
    state_change,
    query_start,
    xact_start,
    query,
    wait_event_type,
    wait_event
FROM pg_stat_activity
WHERE state != 'idle'
ORDER BY query_start DESC;

จากผลลัพธ์ เราจะสามารถหา Query ที่รันนานผิดปกติ หรือ Query ที่อยู่ในสถานะ waiting (กำลังรอทรัพยากรบางอย่าง) เพื่อนำไปวิเคราะห์ต่อได้ครับ

• pg_stat_statements: โมดูลนี้ (ต้องเปิดใช้งานใน postgresql.conf โดยเพิ่ม pg_stat_statements ใน shared_preload_libraries) จะเก็บสถิติการใช้งานของทุก Query ที่ถูกรัน เช่น จำนวนครั้งที่รัน เวลาเฉลี่ยที่ใช้ จำนวน Block ที่อ่าน/เขียน ช่วยให้เราสามารถระบุ Query ที่ทำงานช้าที่สุด (Top N Slowest Queries) ได้อย่างง่ายดายครับ

-- เปิดใช้งาน pg_stat_statements ใน postgresql.conf:
-- shared_preload_libraries = 'pg_stat_statements'
-- pg_stat_statements.track = all
-- รีสตาร์ท PostgreSQL หลังการเปลี่ยนแปลง

-- ดู Query ที่ใช้เวลารวมมากที่สุด
SELECT
    query,
    calls,
    total_time,
    mean_time,
    rows,
    100.0 * shared_blks_hit / (shared_blks_hit + shared_blks_read) AS hit_percent
FROM pg_stat_statements
ORDER BY total_time DESC
LIMIT 10;

การวิเคราะห์ pg_stat_statements จะช่วยให้คุณเห็นภาพรวมว่า Query ไหนคือตัวการที่ทำให้เกิดปัญหาคอขวดมากที่สุดครับ

• EXPLAIN และ EXPLAIN ANALYZE: นี่คือเครื่องมือที่ทรงพลังที่สุดในการทำความเข้าใจว่า PostgreSQL วางแผนที่จะรัน Query ของคุณอย่างไร EXPLAIN จะแสดง Query Plan หรือ “แผนที่” ที่ Optimizer ใช้ในการดำเนินการ Query ว่าจะมีการสแกนตารางแบบใด (Sequential Scan, Index Scan) มีการ Join แบบไหน (Nested Loop, Hash Join, Merge Join) และใช้ Index ใดบ้างครับ ส่วน EXPLAIN ANALYZE จะรัน Query จริงๆ แล้วแสดงผลลัพธ์ของ Query Plan พร้อมกับสถิติเวลาที่ใช้จริงในแต่ละขั้นตอน ซึ่งเป็นข้อมูลที่มีค่ามากในการระบุจุดคอขวดภายใน Query นั้นๆ ครับ

  EXPLAIN ANALYZE
  SELECT *
  FROM products
  WHERE price > 100
  ORDER BY created_at DESC
  LIMIT 10;
  

  การอ่านผลลัพธ์ของ EXPLAIN ANALYZE ต้องอาศัยความเข้าใจพอสมควร แต่เป็นทักษะที่จำเป็นอย่างยิ่งในการปรับแต่ง SQL Query ครับ หากพบว่ามีการทำ Sequential Scan บนตารางขนาดใหญ่ หรือการ Sorting ที่ใช้เวลานาน นั่นอาจเป็นสัญญาณว่าคุณต้องการ Index ใหม่ หรือต้องปรับแต่ง work_mem ครับ

• Log Files (postgresql.conf: log_min_duration_statement, log_statement): PostgreSQL สามารถตั้งค่าให้บันทึก Query ที่รันช้าเกินกว่าระยะเวลาที่กำหนดลงใน Log File ได้ การเปิดใช้งาน log_min_duration_statement = 100ms (หรือค่าอื่นๆ) จะช่วยให้คุณเห็น Query ที่ใช้เวลานานเกินไป ซึ่งเป็นประโยชน์อย่างยิ่งในการระบุปัญหา Query โดยไม่ต้องใช้ pg_stat_statements (แต่ pg_stat_statements ให้ข้อมูลที่ละเอียดกว่าครับ) นอกจากนี้ การตั้งค่า log_statement = 'all' สามารถใช้เพื่อดีบักในระยะสั้นได้ แต่ไม่ควรใช้ใน Production Environment เพราะจะทำให้ Log File มีขนาดใหญ่มากครับ

การตรวจสอบทรัพยากรระบบ (OS Level)

ประสิทธิภาพของ PostgreSQL ขึ้นอยู่กับทรัพยากรของระบบปฏิบัติการเป็นอย่างมาก การตรวจสอบ CPU, Memory, Disk I/O และ Network จึงเป็นสิ่งสำคัญครับ

• CPU: ใช้เครื่องมือเช่น top, htop, mpstat เพื่อดูการใช้งาน CPU หาก CPU ถูกใช้งานเต็ม 100% ตลอดเวลา แสดงว่าระบบอาจมีคอขวดที่ CPU ครับ
• Memory: ใช้ free -h หรือ htop เพื่อตรวจสอบปริมาณ RAM ที่ใช้งานและ RAM ที่เหลืออยู่ หากมีการใช้ Swap Memory มากผิดปกติ แสดงว่าระบบของคุณมี RAM ไม่เพียงพอครับ
• Disk I/O: iostat, vmstat เป็นเครื่องมือที่ยอดเยี่ยมในการตรวจสอบการอ่าน/เขียนดิสก์ หากพบว่าค่า %util (utilization) ของดิสก์สูงเป็นเวลานาน แสดงว่าดิสก์กำลังเป็นคอขวดครับ PostgreSQL เป็นฐานข้อมูลที่พึ่งพา I/O สูง การใช้ SSD หรือ NVMe ที่มีประสิทธิภาพสูงจึงเป็นสิ่งจำเป็นอย่างยิ่ง
• Network: netstat, iftop สามารถใช้ตรวจสอบการใช้งาน Network Traffic ได้ แม้จะไม่ค่อยเป็นปัญหาสำหรับฐานข้อมูลโดยตรง แต่ก็อาจเป็นปัจจัยหนึ่งหากแอปพลิเคชันและฐานข้อมูลอยู่คนละเซิร์ฟเวอร์ หรือมีปริมาณข้อมูลที่ต้องส่งผ่านเครือข่ายสูงมากๆ ครับ

การปรับแต่งไฟล์คอนฟิกูเรชัน (postgresql.conf) อย่างละเอียด

ไฟล์ postgresql.conf คือกุญแจสำคัญในการปรับแต่ง PostgreSQL ครับ การปรับค่าพารามิเตอร์ต่างๆ ในไฟล์นี้ให้เหมาะสมกับทรัพยากรของเซิร์ฟเวอร์และลักษณะการใช้งาน (Workload) จะส่งผลต่อประสิทธิภาพอย่างมหาศาลครับ นี่คือพารามิเตอร์ที่สำคัญที่คุณควรพิจารณาปรับแต่ง:

การจัดการหน่วยความจำ (Memory Management)

การใช้ RAM อย่างมีประสิทธิภาพคือหัวใจของการเพิ่มประสิทธิภาพ PostgreSQL ครับ

• shared_buffers:

  นี่คือพารามิเตอร์ที่สำคัญที่สุดตัวหนึ่งครับ กำหนดขนาดของ Shared Memory ที่ PostgreSQL ใช้สำหรับแคชข้อมูลและ Index ที่ถูกเข้าถึงบ่อยๆ หากมี RAM เพียงพอ การตั้งค่า shared_buffers ให้สูงขึ้นจะช่วยลดการเข้าถึงดิสก์ได้มาก โดยทั่วไปแล้วแนะนำให้ตั้งค่าเป็น 25% ของ RAM ทั้งหมดของเซิร์ฟเวอร์ แต่ไม่ควรเกิน 8GB – 16GB แม้ว่าคุณจะมี RAM มากกว่า 64GB ก็ตามครับ เพราะยิ่งมี Shared Buffers มากเท่าไหร่ การจัดการแคชก็ยิ่งซับซ้อนขึ้น และบางครั้งอาจไม่คุ้มค่ากับ Overheads ที่เพิ่มขึ้นมา

  shared_buffers = 4GB  # ตัวอย่างสำหรับเซิร์ฟเวอร์ที่มี RAM 16GB
  

  คำแนะนำ: เริ่มต้นที่ 25% ของ RAM, หากไม่เห็นผลลัพธ์ที่ดีขึ้นมาก อาจลองลดลงเล็กน้อย หรือไม่จำเป็นต้องเพิ่มเกิน 16GB บนระบบที่มี RAM มหาศาลครับ

• work_mem:

  เป็นหน่วยความจำส่วนตัวที่แต่ละ Backend Process สามารถใช้ได้สำหรับงาน Sorting และ Hashing หากมี Query ที่มีการ Sorting หรือ Hashing ขนาดใหญ่และพบว่ามีการใช้ Temp Files บนดิสก์ (ตรวจสอบได้จาก EXPLAIN ANALYZE) การเพิ่ม work_mem จะช่วยลดการใช้ดิสก์และทำให้ Query เหล่านั้นเร็วขึ้นครับ ข้อควรระวังคือ work_mem ถูกจัดสรรให้กับแต่ละ Backend Process ดังนั้น หากมี max_connections สูง และ work_mem สูงเกินไป อาจทำให้ RAM ถูกใช้จนหมดได้ครับ

  work_mem = 64MB   # ค่าเริ่มต้นมักจะต่ำเกินไป ลองปรับเพิ่มเป็น 32MB, 64MB, หรือ 128MB
  

  คำแนะนำ: ปรับเพิ่มทีละน้อยๆ และตรวจสอบการใช้งาน RAM โดยรวม หาก Query ส่วนใหญ่มีการ Sorting/Hashing ขนาดเล็ก ค่าเริ่มต้นอาจเพียงพอ แต่สำหรับ Query ที่ซับซ้อนและข้อมูลขนาดใหญ่ การเพิ่มค่านี้จะช่วยได้มากครับ

• maintenance_work_mem:

  หน่วยความจำที่ใช้สำหรับงานบำรุงรักษา เช่น VACUUM, ANALYZE, CREATE INDEX การเพิ่มค่านี้จะช่วยให้งานเหล่านี้เร็วขึ้นอย่างมาก โดยเฉพาะการสร้าง Index บนตารางขนาดใหญ่ หรือการ VACUUM FULL ครับ พารามิเตอร์นี้จะถูกใช้โดยกระบวนการ Autovacuum Worker ด้วยเช่นกัน แต่จะใช้เพียงแค่กระบวนการเดียวต่อครั้งเท่านั้น ดังนั้นจึงสามารถตั้งค่าได้สูงกว่า work_mem อย่างปลอดภัยครับ

  maintenance_work_mem = 256MB # หรือ 512MB, 1GB ขึ้นอยู่กับ RAM ที่มี
  

  คำแนะนำ: สามารถตั้งค่าได้สูงถึง 10% – 25% ของ RAM ทั้งหมด (สูงสุด 1GB – 2GB สำหรับเซิร์ฟเวอร์ที่มี RAM สูงมากๆ) เพื่อให้งานบำรุงรักษาทำได้เร็วขึ้นครับ

• wal_buffers:

  พื้นที่หน่วยความจำสำหรับแคช WAL (Write-Ahead Log) ก่อนที่จะเขียนลงดิสก์ ค่าเริ่มต้นคือ -1 (ซึ่งหมายถึง 1/32 ของ shared_buffers ไม่เกิน 16MB) การเพิ่มค่านี้เล็กน้อยอาจช่วยเพิ่มประสิทธิภาพการเขียนข้อมูล (Write Throughput) ได้บ้าง โดยเฉพาะในระบบที่มี Workload การเขียนสูงๆ แต่ไม่ควรตั้งค่าสูงเกินไปครับ

  wal_buffers = 16MB   # ค่าเริ่มต้นมักจะเพียงพอแล้ว หรืออาจเพิ่มเป็น 32MB
  

  คำแนะนำ: โดยทั่วไปค่าเริ่มต้นก็ดีพอแล้ว การปรับเพิ่มเพียงเล็กน้อย (เช่น 16MB หรือ 32MB) ก็เพียงพอครับ

การจัดการ WAL (Write-Ahead Log)

WAL มีความสำคัญต่อความสมบูรณ์ของข้อมูลและประสิทธิภาพการเขียนครับ

• wal_level:

  กำหนดปริมาณข้อมูลที่จะเขียนลงใน WAL มีผลต่อประสิทธิภาพและขนาดของ WAL ไฟล์ ค่าที่สูงขึ้นจะเพิ่มขนาด WAL และ Workload การเขียน แต่จำเป็นสำหรับการ Replicaton และ Point-in-Time Recovery (PITR) ครับ

  • replica (ค่าเริ่มต้นในเวอร์ชันใหม่ๆ): เพียงพอสำหรับการ Physical Replication และ PITR
  • logical: จำเป็นสำหรับการ Logical Replication และบาง Extension

  wal_level = replica
  

  คำแนะนำ: ใช้ replica เป็นค่าเริ่มต้น หากคุณไม่ได้ใช้ Logical Replication หรือ Extension ที่ต้องการ logical

• checkpoint_timeout, max_wal_size, min_wal_size:

  พารามิเตอร์เหล่านี้ควบคุมความถี่และขนาดของการทำ Checkpoint ซึ่งเป็นกระบวนการที่เขียนข้อมูลที่เปลี่ยนแปลงจาก RAM ลงสู่ดิสก์ การทำ Checkpoint บ่อยเกินไปจะทำให้เกิด I/O Spikes ในขณะที่การทำ Checkpoint ห่างเกินไปจะทำให้การกู้คืนระบบใช้เวลานานขึ้น

  • checkpoint_timeout: ระยะเวลาสูงสุดระหว่าง Checkpoint (เริ่มต้น 5 นาที)
  • max_wal_size: ขนาด WAL สูงสุดที่จะเก็บไว้ก่อนที่จะทำ Checkpoint (เริ่มต้น 1GB)
  • min_wal_size: ขนาด WAL ขั้นต่ำที่ PostgreSQL จะรักษาระหว่าง Checkpoint (เริ่มต้น 80MB)

  checkpoint_timeout = 10min  # หรือ 15min สำหรับ Workload สูง
  max_wal_size = 4GB          # หรือ 8GB, 16GB
  min_wal_size = 1GB          # ควรตั้งค่าให้สัมพันธ์กับ max_wal_size
  

  คำแนะนำ: ปรับเพิ่ม checkpoint_timeout และ max_wal_size เพื่อลดความถี่ของการ Checkpoint และลด I/O Spikes แต่ก็ต้องพิจารณาถึง Recovery Time Objective (RTO) ด้วยครับ หากคุณสังเกตเห็นข้อความ “checkpoint complete: wrote …” ใน Log บ่อยๆ แสดงว่าถึงเวลาที่ต้องเพิ่มค่าเหล่านี้แล้วครับ

• full_page_writes:

  เปิดใช้งานโดยค่าเริ่มต้น ช่วยป้องกันข้อมูลเสียหายบางส่วน (torn pages) ในกรณีที่ระบบล่มขณะเขียนข้อมูลลงดิสก์ มีผลกระทบต่อประสิทธิภาพการเขียนเล็กน้อย (เพิ่มปริมาณ WAL) แต่เป็นสิ่งสำคัญสำหรับความสมบูรณ์ของข้อมูลและควรเปิดใช้งานไว้ครับ

  full_page_writes = on
  

การจัดการการเขียน/อ่านข้อมูล (Disk I/O)

การสื่อสารกับดิสก์เป็นส่วนที่ช้าที่สุดในระบบคอมพิวเตอร์ครับ การปรับแต่งที่เกี่ยวข้องกับ I/O จึงสำคัญมาก

• effective_cache_size:

  พารามิเตอร์นี้ไม่ได้จัดสรรหน่วยความจำจริง แต่เป็นค่าประมาณที่ Query Planner ใช้เพื่อประเมินว่าระบบปฏิบัติการจะสามารถแคชข้อมูลได้มากน้อยเพียงใด ควรตั้งค่าเป็น RAM ทั้งหมดของเซิร์ฟเวอร์ ลบด้วย หน่วยความจำที่ PostgreSQL และแอปพลิเคชันอื่นๆ ใช้ไปครับ Query Planner จะใช้ค่านี้นำไปพิจารณาว่าจะใช้ Index Scan หรือ Sequential Scan หากตั้งค่าต่ำเกินไป Planner อาจเลือก Sequential Scan โดยไม่จำเป็น ทำให้ Query ช้าลงครับ

  effective_cache_size = 12GB # สำหรับเซิร์ฟเวอร์ที่มี RAM 16GB และ shared_buffers 4GB
  

  คำแนะนำ: ตั้งค่าประมาณ 50%-75% ของ RAM ทั้งหมดในเซิร์ฟเวอร์ครับ

• random_page_cost และ seq_page_cost:

  พารามิเตอร์เหล่านี้บอก Query Planner ถึงค่าใช้จ่ายในการอ่านหนึ่งหน้าข้อมูลแบบสุ่ม (random) เทียบกับการอ่านแบบต่อเนื่อง (sequential) ค่าเริ่มต้นคือ random_page_cost = 4.0 และ seq_page_cost = 1.0 หากคุณใช้ SSD ที่มีการเข้าถึงแบบสุ่มได้เร็วมาก คุณสามารถลด random_page_cost ลงได้ เช่น 1.1 หรือ 1.5 เพื่อให้ Planner เลือกใช้ Index Scan บ่อยขึ้นครับ

  random_page_cost = 1.1   # สำหรับ SSD/NVMe
  seq_page_cost = 1.0      # คงค่านี้ไว้
  

  คำแนะนำ: ลด random_page_cost ลงสำหรับ SSD/NVMe และตรวจสอบ Query Plan ด้วย EXPLAIN ANALYZE ว่า Planner เลือกใช้ Index ที่เหมาะสมหรือไม่

• synchronous_commit:

  ควบคุมว่าการ Commit Transaction จะรอให้ WAL ถูกเขียนลงดิสก์จริงหรือไม่

  • on (ค่าเริ่มต้น): รับประกันความคงทนของข้อมูลสูงสุด (ACID properties) แต่แลกมาด้วยประสิทธิภาพการเขียนที่ช้าลงเล็กน้อย
  • off: การ Commit จะไม่รอให้ WAL เขียนลงดิสก์ ช่วยเพิ่มประสิทธิภาพการเขียน แต่มีความเสี่ยงที่จะสูญเสียข้อมูลเล็กน้อยหากระบบล่มทันทีหลังจาก Commit (ข้อมูลที่อยู่ใน WAL Buffers อาจยังไม่ถูกเขียนลงดิสก์) เหมาะสำหรับ Workload ที่ยอมรับการสูญเสียข้อมูลเล็กน้อยได้ เช่น Log หรือระบบที่สร้างข้อมูลใหม่บ่อยๆ
  • local: รอให้ WAL ถูกเขียนไปยัง OS cache แต่ไม่รอลงดิสก์จริง

  synchronous_commit = off  # ใช้ด้วยความระมัดระวัง!
  

  คำแนะนำ: โดยทั่วไปควรใช้ on เพื่อความปลอดภัยของข้อมูล หากคุณมีความต้องการประสิทธิภาพการเขียนที่สูงมากและยอมรับความเสี่ยงได้ จึงค่อยพิจารณา off ครับ

การจัดการ Autovacuum

Autovacuum เป็นกระบวนการที่สำคัญมากในการรักษาประสิทธิภาพของ PostgreSQL โดยการกำจัด Dead Tuples และอัปเดตสถิติครับ

• autovacuum:

  ควรเปิดใช้งานไว้เสมอ (on) ไม่ควรปิดใน Production Environment ครับ

  autovacuum = on
  

• autovacuum_vacuum_scale_factor และ autovacuum_analyze_scale_factor:

  กำหนดสัดส่วนของ Dead Tuples หรือการเปลี่ยนแปลงข้อมูลที่ทำให้ Autovacuum เริ่มทำงาน ค่าเริ่มต้นคือ 0.2 (20%) ซึ่งอาจสูงไปสำหรับตารางขนาดใหญ่ ทำให้ Autovacuum ไม่ทำงานบ่อยพอและเกิด Bloat ได้ง่ายครับ

  autovacuum_vacuum_scale_factor = 0.05  # หรือ 0.1 สำหรับตารางขนาดใหญ่มาก
  autovacuum_analyze_scale_factor = 0.05 # เหมือนกัน
  

  คำแนะนำ: ลดค่าเหล่านี้ลงสำหรับตารางขนาดใหญ่ เพื่อให้ Autovacuum ทำงานบ่อยขึ้นและป้องกัน Bloat ครับ

• autovacuum_vacuum_cost_delay และ autovacuum_vacuum_cost_limit:

  ควบคุมความเร็วที่ Autovacuum ทำงาน เพื่อไม่ให้รบกวนการทำงานปกติของฐานข้อมูล autovacuum_vacuum_cost_delay คือระยะเวลาที่ Autovacuum จะรอหลังจากประมวลผลไปถึง autovacuum_vacuum_cost_limit หาก Autovacuum ทำงานช้าเกินไป ลองลด autovacuum_vacuum_cost_delay (ค่าเริ่มต้น 10ms) และ/หรือเพิ่ม autovacuum_vacuum_cost_limit (ค่าเริ่มต้น 200)

  autovacuum_vacuum_cost_delay = 2ms   # ลดค่านี้เพื่อเร่ง Autovacuum
  autovacuum_vacuum_cost_limit = 500   # เพิ่มค่านี้เพื่อเร่ง Autovacuum
  

  คำแนะนำ: หากพบว่าตารางมี Bloat บ่อยๆ หรือ Autovacuum ทำงานช้า ลองปรับค่าเหล่านี้ครับ แต่อย่าลืมว่าการเร่ง Autovacuum จะเพิ่ม I/O Workload ด้วยครับ

การจัดการ Connection

• max_connections:

  จำนวนการเชื่อมต่อสูงสุดที่ PostgreSQL ยอมรับได้ การตั้งค่าสูงเกินไปจะทำให้ PostgreSQL ใช้ RAM มากขึ้น (เพราะแต่ละ Connection ต้องการ RAM สำหรับ work_mem, temp_buffers ฯลฯ) และอาจทำให้ระบบ Overload ได้ครับ ควรตั้งค่าให้เหมาะสมกับจำนวนผู้ใช้งานพร้อมกันและ RAM ที่มี

  max_connections = 100 # ค่าที่เหมาะสมอาจอยู่ระหว่าง 100-500 ขึ้นอยู่กับ Workload
  

  คำแนะนำ: หากจำเป็นต้องรองรับ Connection จำนวนมาก ควรพิจารณาใช้ Connection Pooler เช่น PgBouncer เพื่อลดภาระของ PostgreSQL ครับ

การปรับแต่งอื่นๆ ที่สำคัญ

• default_statistics_target:

  กำหนดระดับความละเอียดของสถิติที่ ANALYZE เก็บไว้ ค่าที่สูงขึ้นจะช่วยให้ Query Planner ตัดสินใจได้ดีขึ้น แต่ก็ใช้เวลาในการ Analyze นานขึ้นและใช้พื้นที่เก็บสถิติมากขึ้น ค่าเริ่มต้นคือ 100 ครับ

  default_statistics_target = 500 # สำหรับคอลัมน์ที่มีข้อมูลหลากหลายมากๆ
  

  คำแนะนำ: หาก Query Planner ตัดสินใจผิดพลาดบ่อยๆ (เช่น เลือก Index ผิด) อาจลองเพิ่มค่านี้สำหรับคอลัมน์ที่มีข้อมูลไม่ซ้ำกันจำนวนมากครับ

• max_worker_processes, max_parallel_workers, max_parallel_workers_per_gather:

  สำหรับ PostgreSQL เวอร์ชัน 9.6 ขึ้นไป รองรับ Parallel Query Execution ซึ่งสามารถเร่งความเร็วของ Query บางประเภทได้โดยใช้ Worker Processes หลายตัวพร้อมกัน พารามิเตอร์เหล่านี้ควบคุมจำนวน Worker Processes ที่สามารถใช้งานได้

  • max_worker_processes: จำนวน Worker Processes สูงสุดที่ระบบสามารถสร้างได้
  • max_parallel_workers: จำนวน Parallel Worker Processes สูงสุดที่สามารถรันพร้อมกันได้ในระบบ
  • max_parallel_workers_per_gather: จำนวน Parallel Worker Processes สูงสุดที่แต่ละ Query สามารถใช้ได้

  max_worker_processes = 8   # เท่ากับจำนวน Core ของ CPU หรือมากกว่าเล็กน้อย
  max_parallel_workers = 8   # ควรน้อยกว่าหรือเท่ากับ max_worker_processes
  max_parallel_workers_per_gather = 4 # จำนวน Worker ต่อ Query
  

  คำแนะนำ: ลองปรับค่าเหล่านี้ตามจำนวน Core ของ CPU ที่มี เพื่อให้ Query ที่รองรับ Parallelism ทำงานได้เร็วขึ้นครับ

การปรับแต่ง SQL Query และ Indexing

แม้ว่าการปรับแต่งไฟล์คอนฟิกูเรชันจะสำคัญ แต่การปรับแต่ง SQL Query และการออกแบบ Index ที่ดีคือสิ่งที่ส่งผลต่อประสิทธิภาพโดยตรงมากที่สุดครับ เพราะไม่ว่าฐานข้อมูลของคุณจะถูกปรับแต่งมาดีแค่ไหน หาก Query ที่รันไม่มีประสิทธิภาพ ก็ยังคงทำงานช้าอยู่ดีครับ

การออกแบบ Index ที่มีประสิทธิภาพ

Index คือโครงสร้างข้อมูลที่ช่วยให้ PostgreSQL ค้นหาข้อมูลได้เร็วขึ้น แต่ Index ก็มีต้นทุนครับ ทั้งในด้านพื้นที่จัดเก็บและการบำรุงรักษา (เมื่อมีการ INSERT, UPDATE, DELETE ข้อมูลในตาราง Index ก็ต้องถูกอัปเดตด้วย) ดังนั้นจึงต้องออกแบบอย่างชาญฉลาด

• ประเภทของ Index:
  • B-Tree (Default): เหมาะสำหรับคอลัมน์ที่มีการเปรียบเทียบแบบเท่ากัน (=), น้อยกว่า (<), มากกว่า (>), BETWEEN, LIKE ที่ขึ้นต้นด้วยค่าคงที่ (e.g., ‘prefix%’) ใช้ได้ดีกับคอลัมน์ส่วนใหญ่
  • Hash: เหมาะสำหรับการเปรียบเทียบแบบเท่ากัน (=) เท่านั้น ไม่รองรับการเปรียบเทียบแบบช่วง (range queries) และไม่สามารถกู้คืนได้หลังจาก Crash (ใน PostgreSQL เวอร์ชันก่อน 10)
  • GIN (Generalized Inverted Index): เหมาะสำหรับข้อมูลประเภท array, JSONB, tsvector (full-text search) ที่มีหลายค่าในหนึ่งฟิลด์
  • GiST (Generalized Search Tree): เหมาะสำหรับข้อมูลเชิงพื้นที่ (spatial data), Full-Text Search, Range Types, IP Addresses
  • BRIN (Block Range Index): เหมาะสำหรับตารางขนาดใหญ่มากที่มีข้อมูลเรียงลำดับตามธรรมชาติ (เช่น timestamp) โดยเก็บข้อมูลสถิติของแต่ละ Block ของข้อมูล
• เมื่อไหร่ควรใช้ Index:
  • เมื่อคอลัมน์ถูกใช้ในเงื่อนไข WHERE clause บ่อยๆ
  • เมื่อคอลัมน์ถูกใช้ใน JOIN conditions
  • เมื่อคอลัมน์ถูกใช้ใน ORDER BY หรือ GROUP BY clause
  • เมื่อคอลัมน์มี Cardinality สูง (มีค่าไม่ซ้ำกันเยอะ)
  • หลีกเลี่ยง Index บนคอลัมน์ที่มี Cardinality ต่ำมากๆ (เช่น คอลัมน์เพศ) เพราะจะไม่ได้ประโยชน์มากนัก
• การสร้าง Index (Code Snippet):

  -- สร้าง B-Tree Index บนคอลัมน์ 'email' ของตาราง 'users'
  CREATE INDEX idx_users_email ON users (email);
  
  -- สร้าง Compound Index บนคอลัมน์ 'product_id' และ 'order_date' ของตาราง 'order_items'
  CREATE INDEX idx_order_items_product_date ON order_items (product_id, order_date DESC);
  
  -- สร้าง GIN Index บนคอลัมน์ 'tags' (ประเภท JSONB) ของตาราง 'articles'
  CREATE INDEX idx_articles_tags ON articles USING GIN (tags);
  

• Partial Indexes: Index ที่สร้างเฉพาะบน Sub-set ของข้อมูลในตาราง โดยมีเงื่อนไข WHERE clause ในการสร้าง ช่วยลดขนาด Index และทำให้การค้นหาเร็วขึ้นในกรณีที่ Query มักจะค้นหาข้อมูลที่มีเงื่อนไขเฉพาะเจาะจงครับ

  -- สร้าง Index เฉพาะสำหรับผู้ใช้งานที่ยัง Active
  CREATE INDEX idx_users_active_email ON users (email) WHERE status = 'active';
  

• Expression Indexes: Index ที่สร้างบนผลลัพธ์ของ Function หรือ Expression ช่วยให้ Query ที่ใช้ Function หรือ Expression นั้นๆ ทำงานได้เร็วขึ้นครับ

  -- สร้าง Index สำหรับการค้นหาแบบ case-insensitive
  CREATE INDEX idx_users_lower_email ON users (lower(email));
  

การเขียน Query ที่ดี

Query ที่เขียนขึ้นมาอย่างเหมาะสมสามารถสร้างความแตกต่างได้มากครับ

• หลีกเลี่ยง SELECT *: เลือกเฉพาะคอลัมน์ที่คุณต้องการจริงๆ เพื่อลดปริมาณข้อมูลที่ต้องดึงมาและลดการใช้งาน Bandwidth ครับ
• ใช้ JOIN ที่เหมาะสม: ทำความเข้าใจประเภทของ JOIN (INNER, LEFT, RIGHT, FULL) และใช้ให้ถูกต้อง การใช้ JOIN ที่ไม่จำเป็น หรือใช้ JOIN แบบที่ทำให้เกิด Cartesian Product จะทำให้ Query ช้าลงอย่างมาก
• ระวัง OR และ NOT: เงื่อนไข OR อาจทำให้ Query Planner ไม่สามารถใช้ Index ได้เต็มประสิทธิภาพในบางกรณี ลองพิจารณาใช้ UNION ALL แทน OR หากเงื่อนไขซับซ้อน ส่วน NOT อาจทำให้ Optimizer ไม่สามารถใช้ Index ได้เช่นกัน
• การใช้ EXISTS แทน IN ในบางกรณี: สำหรับ Subquery ที่ไม่มีการคืนค่าคอลัมน์อื่นนอกจากเงื่อนไข การใช้ EXISTS มักจะมีประสิทธิภาพดีกว่า IN ครับ

  -- อาจมีประสิทธิภาพดีกว่า
  SELECT u.name FROM users u WHERE EXISTS (SELECT 1 FROM orders o WHERE o.user_id = u.id);
  
  -- เทียบกับ
  SELECT u.name FROM users u WHERE u.id IN (SELECT o.user_id FROM orders o);
  

• การใช้ LIMIT และ OFFSET อย่างระมัดระวัง: การใช้ OFFSET ที่มีค่าสูงมากๆ อาจทำให้ Query ช้าลง เพราะ PostgreSQL ยังคงต้องสแกนและทิ้งข้อมูลจำนวนมากที่อยู่ก่อนหน้า Offset นั้นๆ หากเป็นไปได้ ให้ใช้ Index และเงื่อนไข WHERE เพื่อจำกัดผลลัพธ์ให้ได้มากที่สุดก่อนใช้ OFFSET ครับ
• การใช้ CTE (Common Table Expressions): CTEs (ใช้ WITH clause) ช่วยให้ Query อ่านง่ายขึ้นและสามารถนำผลลัพธ์กลับมาใช้ซ้ำได้ ซึ่งบางครั้งอาจช่วยให้ Optimizer สร้าง Query Plan ที่ดีขึ้นได้ครับ

การใช้ VACUUM และ ANALYZE อย่างถูกวิธี

VACUUM และ ANALYZE มีความสำคัญอย่างยิ่งต่อประสิทธิภาพของ PostgreSQL ครับ

• ความสำคัญของการกำจัด Dead Tuples: เมื่อมีการ UPDATE หรือ DELETE ข้อมูลใน PostgreSQL แถวข้อมูลเก่าจะไม่ถูกลบทันที แต่จะถูกทำเครื่องหมายว่าเป็น “dead tuple” ครับ ซึ่งยังคงใช้พื้นที่จัดเก็บและทำให้ตารางมีขนาดใหญ่ขึ้น (Bloat) การมี Dead Tuples มากเกินไปจะทำให้การสแกนตารางช้าลง และอาจทำให้ Index ไม่สามารถใช้งานได้อย่างเต็มประสิทธิภาพ VACUUM มีหน้าที่ในการกำจัด Dead Tuples และคืนพื้นที่ดิสก์ที่ใช้โดย Dead Tuples ให้กลับมาใช้ใหม่ได้ครับ
• VACUUM vs VACUUM FULL:
  • VACUUM: เป็นการทำความสะอาดแบบ “non-blocking” คือสามารถทำได้ในขณะที่ฐานข้อมูลยังทำงานอยู่ โดยจะทำเครื่องหมาย Dead Tuples ว่าสามารถนำพื้นที่กลับมาใช้ใหม่ได้ แต่จะไม่คืนพื้นที่ดิสก์กลับสู่ระบบปฏิบัติการทันที (ตารางยังคงใช้พื้นที่เดิมอยู่)
  • VACUUM FULL: เป็นการทำความสะอาดแบบ “blocking” คือจะล็อกตารางและสร้างตารางใหม่ขึ้นมาโดยไม่มี Dead Tuples แล้วค่อยลบตารางเก่าทิ้ง ซึ่งจะคืนพื้นที่ดิสก์กลับสู่ระบบปฏิบัติการได้อย่างสมบูรณ์ แต่จะใช้เวลานานและทำให้ตารางนั้นไม่สามารถใช้งานได้ชั่วคราว ไม่ควรใช้ VACUUM FULL บ่อยๆ ใน Production Environment ครับ

  VACUUM (VERBOSE, ANALYZE) my_table;
  VACUUM FULL my_table; -- ใช้ด้วยความระมัดระวัง!
  

• ANALYZE เพื่ออัปเดตสถิติ: ANALYZE มีหน้าที่ในการรวบรวมสถิติเกี่ยวกับข้อมูลในตารางและ Index เช่น จำนวนแถว ค่าสูงสุด/ต่ำสุด ความถี่ของค่าต่างๆ สถิติเหล่านี้จะถูกใช้โดย Query Planner ในการตัดสินใจสร้าง Query Plan ที่มีประสิทธิภาพ หากสถิติไม่เป็นปัจจุบัน Planner อาจตัดสินใจผิดพลาดได้ครับ Autovacuum จะทำการ ANALYZE ตารางโดยอัตโนมัติ แต่บางครั้งหากมีการเปลี่ยนแปลงข้อมูลจำนวนมากอย่างรวดเร็ว คุณอาจต้องการรัน ANALYZE ด้วยตนเองครับ

คำแนะนำ: โดยทั่วไปควรพึ่งพา Autovacuum เป็นหลักในการดูแลรักษาตาราง หากคุณพบว่าตารางมี Bloat รุนแรง (ตรวจสอบได้จาก pg_stat_all_tables) และ Autovacuum ไม่สามารถจัดการได้ทัน อาจต้องพิจารณาปรับแต่งพารามิเตอร์ของ Autovacuum หรือรัน VACUUM ด้วยตนเองเป็นครั้งคราวครับ

อ่านเพิ่มเติมเกี่ยวกับ Autovacuum

การปรับแต่งระดับ Database และ Schema

การออกแบบฐานข้อมูลที่ดีตั้งแต่แรกก็เป็นส่วนสำคัญในการสร้างฐานข้อมูลที่มีประสิทธิภาพครับ

การเลือกประเภทข้อมูลที่เหมาะสม

การเลือกใช้ Data Type ที่ถูกต้องและเหมาะสมกับข้อมูลจะช่วยประหยัดพื้นที่จัดเก็บและทำให้การทำงานของฐานข้อมูลเร็วขึ้นครับ

• ใช้ INTEGER แทน BIGINT หากข้อมูลไม่เกินขอบเขตของ INTEGER
• ใช้ SMALLINT แทน INTEGER หากเป็นไปได้
• ใช้ TEXT หรือ VARCHAR ที่ไม่มีการกำหนดความยาว หากคุณไม่ต้องการจำกัดความยาวของสตริงตายตัว เพราะ VARCHAR(n) ไม่ได้มีประสิทธิภาพดีกว่า TEXT ครับ
• พิจารณาใช้ NUMERIC สำหรับข้อมูลการเงินที่ต้องการความแม่นยำสูง และใช้ REAL หรือ DOUBLE PRECISION สำหรับค่าประมาณ
• ใช้ TIMESTAMP WITH TIME ZONE หากคุณต้องการเก็บเวลาพร้อมข้อมูล Time Zone
• ใช้ JSONB แทน JSON หากคุณต้องการค้นหาหรือ Index ข้อมูลภายใน JSON ได้อย่างมีประสิทธิภาพ

การ Normalization และ Denormalization

• Normalization: การออกแบบฐานข้อมูลให้เป็นไปตามหลัก Normal Forms (เช่น 3NF) ช่วยลดความซ้ำซ้อนของข้อมูล (Data Redundancy) และเพิ่มความสมบูรณ์ของข้อมูล (Data Integrity) เหมาะสำหรับระบบที่มี Workload การเขียน (Write-heavy) สูง เพราะลดความซับซ้อนในการอัปเดตข้อมูล แต่แลกมาด้วยการที่อาจต้อง Join ตารางจำนวนมากเพื่อดึงข้อมูล ซึ่งอาจทำให้ Query สำหรับการอ่านช้าลงครับ
• Denormalization: เป็นการเพิ่มความซ้ำซ้อนของข้อมูลโดยเจตนา เพื่อลดจำนวนการ Join ที่จำเป็นในการดึงข้อมูล เหมาะสำหรับระบบที่มี Workload การอ่าน (Read-heavy) สูง เช่น Data Warehouse หรือระบบ Report ครับ การ Denormalization สามารถเพิ่มประสิทธิภาพการอ่านได้มาก แต่ก็เพิ่มความซับซ้อนในการจัดการความสมบูรณ์ของข้อมูลเมื่อมีการเขียนครับ

คำแนะนำ: ควรเริ่มต้นด้วยการ Normalization ที่เหมาะสม และพิจารณา Denormalization เฉพาะในจุดที่พิสูจน์แล้วว่าเป็นคอขวดด้านประสิทธิภาพการอ่าน และคุณยอมรับความซับซ้อนในการจัดการข้อมูลที่เพิ่มขึ้นได้ครับ

การ Partitioning Table

การ Partitioning คือการแบ่งตารางขนาดใหญ่มากๆ ออกเป็นตารางย่อยๆ ที่เล็กลง โดยแต่ละ Partition จะเป็นอิสระต่อกัน การ Partitioning มีประโยชน์อย่างมากสำหรับตารางที่มีข้อมูลจำนวนมหาศาล และมี Query ที่มักจะเข้าถึงข้อมูลในช่วงเวลาหรือเงื่อนไขเฉพาะเจาะจง

• ประเภทของการ Partitioning:
  • Range Partitioning: แบ่งข้อมูลตามช่วงค่าของคอลัมน์ เช่น แบ่งตามวันที่, เดือน, ปี
  • List Partitioning: แบ่งข้อมูลตามค่าที่กำหนดไว้ในลิสต์ เช่น แบ่งตามภูมิภาค, ประเภทสินค้า
  • Hash Partitioning: แบ่งข้อมูลตามค่า Hash ของคอลัมน์ ทำให้ข้อมูลกระจายตัวอย่างสม่ำเสมอ เหมาะสำหรับกรณีที่ไม่สามารถกำหนดช่วงหรือลิสต์ที่ชัดเจนได้
• ข้อดีของการ Partitioning:
  • เพิ่มประสิทธิภาพ Query: Query Planner สามารถสแกนเฉพาะ Partition ที่เกี่ยวข้องได้ ทำให้ค้นหาข้อมูลเร็วขึ้น
  • จัดการข้อมูลได้ง่ายขึ้น: การลบข้อมูลเก่าทำได้ง่ายเพียงแค่ Drop Partition ทั้งหมด แทนที่จะ Delete ทีละแถว
  • ลดขนาด Index: แต่ละ Partition มี Index ของตัวเอง ทำให้ Index มีขนาดเล็กลงและจัดการได้ง่ายขึ้น
  • ปรับปรุง Autovacuum: Autovacuum ทำงานบน Partition เล็กๆ ได้เร็วขึ้น
• การสร้าง Partition (Code Snippet):

  -- สร้างตารางหลัก (Parent Table)
  CREATE TABLE sales (
      sale_id SERIAL,
      sale_date DATE NOT NULL,
      amount NUMERIC(10, 2)
  ) PARTITION BY RANGE (sale_date);
  
  -- สร้าง Partition ย่อยสำหรับแต่ละปี
  CREATE TABLE sales_2022 PARTITION OF sales
  FOR VALUES FROM ('2022-01-01') TO ('2023-01-01');
  
  CREATE TABLE sales_2023 PARTITION OF sales
  FOR VALUES FROM ('2023-01-01') TO ('2024-01-01');
  
  -- เพิ่ม Partition ใหม่สำหรับปี 2024
  CREATE TABLE sales_2024 PARTITION OF sales
  FOR VALUES FROM ('2024-01-01') TO ('2025-01-01');
  

การใช้ Materialized Views

Materialized View คือวิวที่เก็บผลลัพธ์ของ Query ไว้ในดิสก์จริงๆ เหมือนกับตารางทั่วไป ซึ่งแตกต่างจาก Standard View ที่จะประมวลผล Query ทุกครั้งที่ถูกเรียกใช้ครับ

• ข้อดีข้อเสีย:
  • ข้อดี: เหมาะสำหรับ Query ที่ซับซ้อนและใช้เวลานานในการประมวลผล หรือ Report ที่ไม่ต้องการข้อมูลแบบ Real-time เป๊ะๆ ช่วยลดภาระของฐานข้อมูลหลักและเพิ่มความเร็วในการอ่านได้อย่างมากครับ
  • ข้อเสีย: ข้อมูลใน Materialized View จะไม่เป็นปัจจุบันทันทีที่ข้อมูลต้นฉบับเปลี่ยนแปลง คุณต้องทำการ Refresh ด้วยคำสั่ง REFRESH MATERIALIZED VIEW เป็นระยะๆ ครับ
• การสร้าง Materialized View (Code Snippet):

  -- สร้าง Materialized View สำหรับสรุปยอดขายรายวัน
  CREATE MATERIALIZED VIEW daily_sales_summary AS
  SELECT
      sale_date,
      SUM(amount) AS total_sales,
      COUNT(sale_id) AS total_orders
  FROM sales
  GROUP BY sale_date
  ORDER BY sale_date;
  
  -- Refresh ข้อมูลใน Materialized View
  REFRESH MATERIALIZED VIEW daily_sales_summary;
  
  -- Refresh แบบไม่ Blocking
  REFRESH MATERIALIZED VIEW CONCURRENTLY daily_sales_summary;
  

การจัดการ Connection Pooling

การสร้าง Connection ใหม่ไปยังฐานข้อมูลนั้นใช้ทรัพยากรและเวลาครับ หากแอปพลิเคชันของคุณมีการสร้างและปิด Connection บ่อยๆ หรือมีผู้ใช้งานพร้อมกันจำนวนมาก PostgreSQL อาจต้องใช้ทรัพยากรมากในการจัดการ Connection เหล่านี้ ซึ่งอาจทำให้ประสิทธิภาพโดยรวมลดลงได้ครับ

• ทำไมถึงต้องใช้ Connection Pooler:

  Connection Pooler (เช่น PgBouncer, Odyssey) ทำหน้าที่เป็นตัวกลางระหว่างแอปพลิเคชันกับ PostgreSQL โดยจะสร้าง Pool ของ Connection ที่พร้อมใช้งานไว้ล่วงหน้า เมื่อแอปพลิเคชันต้องการ Connection มันจะได้รับ Connection จาก Pool ทันที แทนที่จะต้องสร้างใหม่ เมื่อแอปพลิเคชันเสร็จสิ้นการใช้งาน Connection นั้นก็จะถูกส่งกลับไปที่ Pool เพื่อให้ Connection Pooler สามารถนำกลับมาใช้ใหม่ได้ครับ

• ประโยชน์และหลักการทำงาน:
  • ลด Overheads การสร้าง Connection: ช่วยให้แอปพลิเคชันเชื่อมต่อกับฐานข้อมูลได้เร็วขึ้น
  • ลดจำนวน Connection บน PostgreSQL: จำกัดจำนวน Connection ที่ PostgreSQL ต้องจัดการ ซึ่งช่วยลดการใช้ RAM และ CPU ของ PostgreSQL ครับ
  • เพิ่มเสถียรภาพ: ช่วยให้ PostgreSQL ไม่เกิดภาวะ Overload จากจำนวน Connection ที่มากเกินไป
• การติดตั้งและคอนฟิกูเรชันเบื้องต้น (PgBouncer):

  PgBouncer เป็น Connection Pooler ที่ได้รับความนิยมอย่างมากสำหรับ PostgreSQL

  ; ตัวอย่างไฟล์ pgbouncer.ini
  [databases]
  mydb = host=localhost port=5432 dbname=mydb
  
  [pgbouncer]
  listen_addr = 0.0.0.0
  listen_port = 6432
  auth_type = md5
  auth_file = /etc/pgbouncer/userlist.txt
  pool_mode = session ; หรือ transaction, statement
  default_pool_size = 20
  max_client_conn = 1000
  

  คำแนะนำ: การใช้ Connection Pooler เป็น Best Practice สำหรับแอปพลิเคชันส่วนใหญ่ที่เชื่อมต่อกับ PostgreSQL โดยเฉพาะใน Production Environment ครับ

การปรับแต่งระดับระบบปฏิบัติการ (Operating System Tuning)

ประสิทธิภาพของ PostgreSQL ขึ้นอยู่กับประสิทธิภาพของระบบปฏิบัติการที่รันอยู่ด้วยครับ การปรับแต่ง OS ให้เหมาะสมจะช่วยให้ PostgreSQL ทำงานได้อย่างเต็มศักยภาพ

การจัดการ Disk I/O

• เลือกใช้ SSD/NVMe: นี่คือการอัปเกรดที่เห็นผลชัดเจนที่สุดสำหรับฐานข้อมูลใดๆ ครับ ความเร็วในการอ่าน/เขียนแบบสุ่มของ SSD/NVMe สูงกว่า HDD อย่างมหาศาล ซึ่งเป็นสิ่งจำเป็นสำหรับ Workload ของฐานข้อมูล
• RAID Configuration:
  • RAID 10 (1+0): มักเป็นทางเลือกที่ดีที่สุดสำหรับฐานข้อมูล ให้ทั้งประสิทธิภาพการอ่าน/เขียนที่ดีและการป้องกันข้อมูล
  • RAID 0: ให้ประสิทธิภาพสูงสุด แต่ไม่มีการป้องกันข้อมูล ไม่ควรใช้ใน Production
  • RAID 5/6: อาจไม่เหมาะสำหรับ Workload การเขียนที่หนักหน่วงของฐานข้อมูลเนื่องจากมี Write Penalty
• Filesystem: XFS/ext4: ทั้งสอง Filesystem นี้เป็นตัวเลือกที่ดีสำหรับ PostgreSQL โดย XFS มักจะให้ประสิทธิภาพที่ดีกว่าเล็กน้อยสำหรับ Workload ที่มีขนาดใหญ่และมีการเขียนข้อมูลเยอะๆ ครับ
• I/O Scheduler (Linux):
  • noop/none: เหมาะสำหรับ SSD/NVMe เพราะดิสก์เหล่านี้ไม่ต้องการการจัดเรียงคิว I/O
  • deadline/cfq: อาจเหมาะสำหรับ HDD แต่ประสิทธิภาพของ SSD จะดีที่สุดเมื่อใช้ noop หรือ none ครับ

การจัดการ Memory และ Swap

• ปิด Swap หรือจำกัดการใช้: การที่ PostgreSQL ต้องใช้ Swap Memory (ไฟล์บนดิสก์ที่ใช้จำลองเป็น RAM) จะทำให้ประสิทธิภาพลดลงอย่างมาก เพราะดิสก์ช้ากว่า RAM หลายเท่า หากมี RAM ไม่เพียงพอควรเพิ่ม RAM ไม่ใช่พึ่งพา Swap ครับ อย่างไรก็ตาม การปิด Swap ทั้งหมดอาจมีความเสี่ยงในบางกรณี (เช่น OOM Killer) การตั้งค่า vm.swappiness ใน sysctl.conf ให้มีค่าต่ำๆ (เช่น 1 หรือ 10) จะช่วยลดการใช้ Swap ได้ครับ
• Huge Pages: การเปิดใช้งาน Huge Pages (ใน Linux) สำหรับ Shared Buffers ของ PostgreSQL สามารถช่วยลด Overhead ในการจัดการ Memory และเพิ่มประสิทธิภาพได้เล็กน้อยสำหรับระบบที่มี RAM จำนวนมากครับ

การปรับแต่ง Kernel Parameters (sysctl.conf)

ไฟล์ /etc/sysctl.conf ใช้สำหรับปรับแต่งค่า Kernel Parameters ต่างๆ ครับ

• vm.swappiness: ควบคุมพฤติกรรมการใช้ Swap ของ Kernel ค่า 0 คือพยายามหลีกเลี่ยงการใช้ Swap ให้มากที่สุด (ยกเว้นกรณีจำเป็นจริงๆ) ค่า 100 คือ

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

  • Network Forensics: Packet Capture Analysis, Flow Data และ Incident Investigation
  • Network Access Control (NAC): 802.1X, MAB และ Posture Assessment
  • Network Documentation คู่มือทำเอกสาร Network Diagram สำหรับองค์กร
  iCafeForex.com — EA Forex และเครื่องมือเทรด · SiamCafe.net — ชุมชน IT ที่ใหญ่ที่สุด