ส่วนที่เราเกลียดที่สุดของ PostgreSQL (2023)

 (cs.cmu.edu)
4 คะแนน โดย GN⁺ 2024-10-21 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

ส่วนที่เกลียดที่สุดใน PostgreSQL

  • ตลอด 5 ปีที่ผ่านมา PostgreSQL ได้กลายเป็น DBMS ที่ได้รับความนิยมสูงสุดบนอินเทอร์เน็ต เนื่องจากมีความน่าเชื่อถือ ความสามารถ ฟังก์ชันการทำงาน และเหมาะกับเวิร์กโหลดในการใช้งานจริงส่วนใหญ่
  • อย่างไรก็ตาม วิธีที่ PostgreSQL ใช้ในการทำ multi-version concurrency control (MVCC) ถูกมองว่าแย่ที่สุดเมื่อเทียบกับ DBMS เชิงสัมพันธ์ตัวอื่น

Multi-version concurrency control คืออะไร?

  • เป้าหมายของ MVCC คือทำให้หลายคิวรีสามารถอ่านและเขียนฐานข้อมูลพร้อมกันได้โดยไม่รบกวนกัน
  • DBMS จะไม่เขียนทับแถวเดิม แต่เก็บหลายเวอร์ชันไว้ เพื่อให้คิวรีเลือกเวอร์ชันที่เหมาะสมมาสนองคำขอได้
  • วิธีนี้ทำให้ไม่จำเป็นต้องใช้การล็อกเรคอร์ดแบบชัดเจน และช่วยให้คิวรีมองเห็นสแนปช็อตของฐานข้อมูลได้

Multi-version concurrency control ของ PostgreSQL

  • เมื่ออัปเดตแถวเดิม PostgreSQL จะสร้างเวอร์ชันใหม่ขึ้นมาเพื่อบันทึกการเปลี่ยนแปลง โดยใช้วิธีจัดเก็บเวอร์ชันแบบ append-only
  • วิธีนี้ก่อให้เกิดปัญหาซับซ้อนหลายอย่าง

การจัดเก็บหลายเวอร์ชัน

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

การทำ vacuum ของเวอร์ชัน

  • PostgreSQL ใช้กระบวนการ vacuum เพื่อลบเวอร์ชันเก่าที่หมดอายุแล้ว
  • autovacuum จะทำงานเป็นระยะเพื่อลบเวอร์ชันที่หมดอายุและนำพื้นที่กลับมาใช้ซ้ำ

ทำไม MVCC ของ PostgreSQL ถึงแย่ที่สุด

  • การติดตั้งใช้งาน MVCC ของ PostgreSQL เป็นดีไซน์จากยุค 1980 ซึ่งไม่สอดคล้องกับรูปแบบระบบแบบ log-structured สมัยใหม่
  • บทความนี้อธิบายปัญหาหลัก 4 ข้อที่เกิดจาก MVCC ของ PostgreSQL

ปัญหาที่ 1: การคัดลอกเวอร์ชัน

  • PostgreSQL คัดลอกทุกคอลัมน์ไปยังเวอร์ชันใหม่ ทำให้เกิดข้อมูลซ้ำซ้อนและเพิ่มความต้องการด้านพื้นที่จัดเก็บ
  • MySQL และ Oracle หลีกเลี่ยงปัญหานี้ด้วยการเก็บ delta แทน

ปัญหาที่ 2: ตารางบวม

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

ปัญหาที่ 3: การบำรุงรักษา secondary index

  • PostgreSQL ต้องอัปเดตทุกอินเด็กซ์ทุกครั้งที่มีการอัปเดตข้อมูล
  • สิ่งนี้ทำให้ประสิทธิภาพของคิวรีลดลง

ปัญหาที่ 4: การจัดการ vacuum

  • ประสิทธิภาพของ PostgreSQL พึ่งพาความมีประสิทธิผลของ autovacuum อย่างมาก
  • หาก autovacuum ทำงานได้ไม่ดี ก็จะเกิดปัญหาด้านประสิทธิภาพ

สรุปโดย GN⁺

  • PostgreSQL ยังคงเป็น DBMS ที่ได้รับความนิยมมาก แต่แนวทางการทำ MVCC ของมันไม่ทันสมัย
  • การแก้ปัญหา MVCC ของ PostgreSQL ต้องใช้เวลาและความพยายามอย่างมาก
  • สามารถปรับแต่งการตั้งค่า autovacuum ให้เหมาะสมเพื่อปรับปรุงประสิทธิภาพได้
  • อาจพิจารณา MySQL และ Oracle เป็นทางเลือกสำหรับการแก้ปัญหา MVCC ของ PostgreSQL

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

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

 
GN⁺ 2024-10-21
ความคิดเห็นใน Hacker News

  • OrioleDB พยายามแก้ปัญหาด้วย storage engine แบบใหม่

    • หากงานส่วนใหญ่เป็นการทำ INSERT ก็ไม่จำเป็นต้องใช้พื้นที่เพิ่ม
    • มีข้อจำกัดเรื่องจำนวนคำสั่งภายในทรานแซกชัน แต่สามารถเลี่ยงได้ด้วยการใช้ COPY FROM
    • ในมุมมองของ DBA ไม่จำเป็นต้องจัดการพื้นที่ rollback/undo แยกต่างหาก

  • การออกแบบของ PostgreSQL ไม่ได้แย่ไปทุกด้าน

    • MySQL และ Oracle เก็บ delta ที่ถูกบีบอัดระหว่างเวอร์ชันใหม่กับเวอร์ชันปัจจุบัน
    • git ไม่ได้เก็บ diff แต่เก็บอ็อบเจ็กต์ทั้งก้อนคล้ายกับ PostgreSQL

  • การทำ MVCC ของ Oracle และ MySQL ไม่ได้เก็บที่อยู่ทางกายภาพของเวอร์ชันใหม่

    • แต่จะเก็บตัวระบุเชิงตรรกะเพื่อให้ DBMS หา physical address ของเวอร์ชันปัจจุบันได้
    • สิ่งนี้อาจทำให้การอ่าน secondary index ช้าลง แต่ก็ลด overhead ได้ด้วยข้อดีด้านอื่น

  • เวลาอัปเดตแถวเดียวใน MySQL การทำ SELECT id WHERE something; UPDATE what WHERE id=id เร็วกว่ามาก

    • ในงานทั่วไปไม่ได้ใช้วิธีนี้กันเป็นปกติ และนั่นทำให้ DML แบบครั้งเดียวช้าลง

  • ในช่วงทศวรรษ 2010 MongoDB ถูกมองว่าเป็น "webscale" เพราะการเขียนแบบไม่รับประกันความทนทาน

    • นี่เป็นผลจากการตลาด

  • ไม่เห็นด้วยกับคำอธิบายเกี่ยวกับ pg_repack

    • VACUUM FULL หนักก็จริง แต่ repack เป็นทางเลือกที่เร็วกว่าและเบากว่า

  • เหตุผลที่ PostgreSQL ได้รับความนิยมมีดังนี้

    • ความปลอดภัยของข้อมูล, ACID, ความคล้ายกับ Oracle, MVCC, การรองรับมาตรฐาน SQL, ทีม Postgres, ชุมชน, ชนิดข้อมูล, ประสิทธิภาพสูง, ความยืดหยุ่นแบบ BSD
    • PostgreSQL ยังคงพัฒนาอย่างต่อเนื่อง และชุมชนมีบทบาทสำคัญมาก

  • มีคำถามว่าการเก็บ row-tuple เวอร์ชันใหม่ทั้งก้อนของ PostgreSQL เป็นคุณสมบัติของ storage engine พื้นฐานหรือไม่

  • บทความเขียนได้ดี อ่านง่าย และเข้าใจง่าย

    • ช่วยให้เข้าใจปัญหาที่เกี่ยวกับ vacuum มากขึ้น และไดอะแกรมก็ดีด้วย