การปรับปรุง PostgreSQL Optimizer ตลอด 10 ปี

 (rmarcus.info)
2 คะแนน โดย GN⁺ 2024-04-19 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

สิ่งที่ได้รับการปรับปรุงของ PostgreSQL Optimizer ตลอด 10 ปี

  • ในฐานะนักวิจัยด้านการปรับแต่งคิวรี ได้ใช้ประโยชน์จากโอเพนซอร์สคิวรีออปติไมเซอร์อันซับซ้อนของ PostgreSQL ในงานวิจัยตลอด 10 ปีที่ผ่านมา
  • หลังจากเริ่มทำงานด้านฐานข้อมูล ก็เริ่มสงสัยว่า PostgreSQL ได้รับการปรับปรุงไปมากเพียงใดในช่วง 10 ปีนี้
  • แม้จะมีบันทึกการเปลี่ยนแปลงและความคิดเห็นมากมาย แต่ไม่พบการเปรียบเทียบเชิงประจักษ์ที่หนักแน่น จึงตัดสินใจรัน Join Order Benchmark (JOB) ด้วยตนเองตั้งแต่ PostgreSQL 8 ถึง 16
  • สำหรับฐานข้อมูลแต่ละเวอร์ชัน ได้บันทึกเวลาแฝงของคิวรีที่เปอร์เซ็นไทล์ที่ 90

การตั้งค่าสภาพแวดล้อมทดสอบ

  • คอมไพล์ PostgreSQL แต่ละเวอร์ชันภายใน Docker container ของ Arch Linux โดยใช้ GCC 13.2
  • เพื่อวัดคุณภาพของคิวรีออปติไมเซอร์ ได้ตั้งค่า shared_buffers เป็น 8GB (มากพอที่จะเก็บฐานข้อมูลทั้งหมดไว้ได้)
  • ตั้งค่า work_mem เป็น 8MB สำหรับทุกเวอร์ชัน
  • แต่ละคิวรีจะถูกรันหนึ่งครั้งเพื่อวอร์มแคช จากนั้นรันเพิ่มอีก 5 ครั้งและบันทึกค่าเวลาแฝงมัธยฐาน

การปรับปรุงประสิทธิภาพโดยรวม

  • ประสิทธิภาพส่วนหางของ PostgreSQL ดีขึ้นอย่างมาก แต่เวอร์ชัน 13~16 โดยรวมค่อนข้างคงที่
  • เมื่อเปรียบเทียบเวอร์ชัน 8 กับ 16 พบว่า PostgreSQL optimizer ลด tail latency ลงได้เกือบครึ่งในช่วง 10 ปีที่ผ่านมา
  • สามารถตรวจสอบการกระจายของคิวรีทั้งหมดได้ (ดูสเกลแบบลอการิทึม)

การหาปริมาณการปรับปรุงด้วยการวิเคราะห์รีเกรสชัน

  • สามารถใช้การวิเคราะห์รีเกรสชันเพื่อตรวจสอบว่าความชันของเวลาแฝงที่ลดลงมีนัยสำคัญหรือไม่ และหาปริมาณได้ว่า PostgreSQL แต่ละเวอร์ชันนำมาซึ่งการปรับปรุงมากเพียงใด
  • เมื่อนำหมายเลข major version ของ PostgreSQL ไปทำรีเกรสชันกับเวลาแฝงของคิวรี พบว่า major version ใหม่แต่ละรุ่นของ PostgreSQL ให้การปรับปรุงประสิทธิภาพเฉลี่ย 15% บน Join Order Benchmark
  • อย่างไรก็ตาม โมเดลเชิงเส้นอาจเป็นตัวชี้วัดที่ไม่ค่อยเหมาะนักสำหรับการวัดการเปลี่ยนแปลง

ประเด็นที่ควรพิจารณาเพิ่มเติม

  • แน่นอนว่า การปรับปรุงทั้งหมดนี้ไม่ได้มาจากคิวรีออปติไมเซอร์เพียงอย่างเดียว การปรับปรุงด้าน execution engine ตั้งแต่ parallel worker ไปจนถึง just-in-time (JIT) compilation ก็มีบทบาทเช่นกัน
  • การตรวจสอบด้วยว่า query plan ของแต่ละคิวรีใน JOB เปลี่ยนไปอย่างไรในแต่ละปี ก็น่าจะน่าสนใจเช่นกัน

ประเด็นสำคัญ

  • อัปเกรดฐานข้อมูลของคุณ! การย้ายจาก PostgreSQL 8 ไป 16 สามารถปรับปรุง tail latency ของเวิร์กโหลดได้อย่างมาก
  • นักวิจัยควรตระหนักว่า PostgreSQL เป็นเป้าหมายที่เปลี่ยนแปลงตลอดเวลา
    • งานวิจัยด้าน learned query optimization ได้เปรียบเทียบกับ PostgreSQL คนละเวอร์ชันมาตลอดตามกาลเวลา
    • แม้เทคนิคเก่าจะปรับปรุง PostgreSQL ได้ 30% และเทคนิคล่าสุดปรับปรุงได้ 25% ก็อาจเป็นไปได้ว่าเทคนิคล่าสุดกำลังถูกเปรียบเทียบกับ PostgreSQL ที่แข็งแกร่งกว่าอยู่แล้ว

ความเห็นของ GN⁺

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

  • ไม่ใช่แค่คิวรีออปติไมเซอร์เท่านั้นที่มีส่วนช่วยเพิ่มประสิทธิภาพ แต่การปรับปรุง execution engine ก็มีส่วนสำคัญด้วย มีการเพิ่มประสิทธิภาพในหลายด้าน เช่น การประมวลผลแบบขนานและ JIT compilation

  • การทดลองนี้จำกัดอยู่ที่ Join Order Benchmark เท่านั้น ดังนั้นผลของการปรับปรุงประสิทธิภาพในงานจริงอาจแตกต่างกันไปตามเวิร์กโหลด ควรทำ benchmark ที่เหมาะกับลักษณะงานของตนเองด้วย

  • นักวิจัยควรคำนึงถึงการเปลี่ยนแปลงของเวอร์ชัน PostgreSQL เพราะแม้จะใช้อัลกอริทึมเดียวกัน ระดับการปรับปรุงประสิทธิภาพเชิงสัมพัทธ์ก็อาจต่างกันตามเวอร์ชันของ PostgreSQL ที่ใช้เป็นตัวเปรียบเทียบ

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

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

1 ความคิดเห็น

 
GN⁺ 2024-04-19
ความคิดเห็นบน Hacker News

สรุป:

  • หากต้องการแก้ปัญหาการเพิ่มประสิทธิภาพให้ดี ข้อมูลเกี่ยวกับต้นทุนเป็นสิ่งสำคัญ PostgreSQL ยังมีช่องให้ปรับปรุงได้อีกมาก โดยเฉพาะยังขาดข้อมูลอย่าง syscall latency และสถิติของ foreign key
  • สำหรับคิวรีขนาดใหญ่ จำเป็นต้องนำเทคนิคอย่าง deferred planning ที่สามารถปรับแผนระหว่างการรันมาใช้
  • ควรใช้แมชชีนเลิร์นนิงเพื่อปรับปรุงโมเดลคาดการณ์ต้นทุน การใช้แมชชีนเลิร์นนิงเพื่อวางแผนคิวรีโดยตรงไม่ค่อยเหมาะสม
  • การตั้ง shared buffer ให้ใหญ่จนยกข้อมูลทั้งหมดขึ้นมาไว้ในหน่วยความจำเพื่อทำเบนช์มาร์ก ทำให้ประเมินประสิทธิภาพจริงของ optimizer ได้ยาก
  • JIT compiler ในตอนนี้ยังมีหลายกรณีที่ก่อให้เกิดแต่การลดประสิทธิภาพ
  • เนื่องจากการกำหนดเลขเวอร์ชันของ PostgreSQL เปลี่ยนไปตั้งแต่เวอร์ชัน 10 การมองเวอร์ชัน 8.x และ 9.x เป็น major version แล้ววิเคราะห์แนวโน้มด้านประสิทธิภาพก็น่าจะน่าสนใจ
  • จากกราฟที่นำเสนอเพียงอย่างเดียว ยังยืนยันแนวโน้มการปรับปรุงประสิทธิภาพได้ไม่ชัดเจน แม้ tail latency จะดูเหมือนดีขึ้น แต่ส่วนอื่นอาจแตกต่างกันไปในแต่ละกรณี
  • การสร้าง optimizer ที่ยอดเยี่ยมเป็นงานที่ท้าทายอย่างมาก
  • สงสัยว่าการเพิ่มประสิทธิภาพคิวรีอยู่ในระดับ SQL หรือระดับอัลกอริทึม