ภูมิทัศน์ของ storage engine ของ PostgreSQL กำลังเผชิญกับการเปลี่ยนแปลงที่สำคัญ โดย OrioleDB beta12 ส่งมอบการปรับปรุงประสิทธิภาพที่น่าประทับใจ extension สำหรับ storage แบบกำหนดเองนี้ทดแทน Heap storage เริ่มต้นของ PostgreSQL ด้วยระบบที่ใช้ undo log แสดงให้เห็นการปรับปรุงที่น่าทึ่งในการทดสอบประสิทธิภาพการประมวลผลธุรกรรม อย่างไรก็ตาม เส้นทางสู่การยอมรับในกระแสหลักเผชิญกับความท้าทายที่น่าสนใจซึ่งได้จุดประกายการอภิปรายในชุมชน
การปรับปรุงประสิทธิภาพจุดประกายคำถามเรื่องการรวมเข้าด้วยกัน
ผลการทดสอบล่าสุดเผยให้เห็นการปรับปรุงประสิทธิภาพอย่างมาก โดย OrioleDB บรรลุ throughput ที่ดีกว่า PostgreSQL มาตรฐานถึง 2.6 เท่าในการทดสอบ TPC-C ใน instance ที่ใหญ่กว่า ความแตกต่างยิ่งมีความชัดเจนมากขึ้น โดยสามารถทำได้ 218,716 ธุรกรรมต่อนาทีเมื่อเปรียบเทียบกับ 83,653 ของ PostgreSQL ใน 16xl instances ผลลัพธ์เหล่านี้ทำให้สมาชิกชุมชนตั้งคำถามว่าทำไมการปรับปรุงดังกล่าวจึงไม่ได้ถูกรวมเข้าไปใน core ของ PostgreSQL
สถาปัตยกรรมที่อยู่เบื้องหลังการปรับปรุงเหล่านี้คล้ายคลึงกับแนวทางของ Oracle โดยใช้ระบบ undo log ที่หลีกเลี่ยงปัญหา bloat ที่พบบ่อยในการใช้งาน MVCC แบบดั้งเดิมของ PostgreSQL การออกแบบนี้ย้ายการจัดการ dead tuple ออกจากพื้นที่ storage หลักไปยัง undo logs แยกต่างหาก ซึ่งช่วยปรับปรุงประสิทธิภาพโดยรวม
ผลการทดสอบ TPC-C Benchmark (ธุรกรรมต่อนาที)
| ขนาด Instance | PostgreSQL Heap | OrioleDB | การเพิ่มประสิทธิภาพ |
|---|---|---|---|
| large | 6,155 | 7,539 | 1.22x |
| xl | 11,129 | 18,390 | 1.65x |
| 2xl | 12,812 | 25,786 | 2.01x |
| 4xl | 17,392 | 31,844 | 1.83x |
| 8xl | 37,577 | 84,770 | 2.26x |
| 12xl | 56,830 | 116,564 | 2.05x |
| 16xl | 83,653 | 218,716 | 2.61x |
 |
|---|
| การเปรียบเทียบประสิทธิภาพของ OrioleDB และ PostgreSQL ในระหว่างการทดสอบ TPC-C benchmark โดยเน้นที่ throughput ที่เหนือกว่าของ OrioleDB |
สถานะ Extension และความท้าทายในการรวม Core
แม้จะมีตัวเลขประสิทธิภาพที่น่าประทับใจ OrioleDB ยังคงเป็น extension ที่ต้องการ core PostgreSQL patches ทีมพัฒนาได้ส่ง patches ไปยัง Table Access Method API upstream แต่กระบวนการรวมเข้าด้วยกันยังคงดำเนินต่อไป การอภิปรายในชุมชนเผยให้เห็นความอยากรู้อยากเห็นเกี่ยวกับว่าทีม core ของ PostgreSQL ที่มีชื่อเสียงในเรื่องความระมัดระวังจะยอมรับการปรับปรุงเหล่านี้เป็นตัวทดแทน Heap storage system ที่มีมายาวนานหรือไม่
ระบบที่ใช้ undo log โดยพื้นฐานแล้วเป็นวิธีที่ Oracle จัดโครงสร้าง core row storage โดยแต่ละ row จะถูกเปลี่ยนแปลงในที่เดิมและมี header ที่แสดงรายการ chain ของธุรกรรมที่กำลัง hold เวอร์ชันต่างๆ ของมันอยู่
ลักษณะที่ระมัดระวังของกระบวนการพัฒนา PostgreSQL หมายความว่าการเปลี่ยนแปลงพื้นฐานดังกล่าวต้องการการตรวจสอบและทดสอบอย่างละเอียดก่อนการรวมเข้าด้วยกันที่เป็นไปได้
ความเข้ากันได้และการพัฒนาในอนาคต
คำถามเรื่องความเข้ากันได้ในปัจจุบันมุ่งเน้นไปที่ความสามารถของ OrioleDB ในการทำงานร่วมกับ extension และเครื่องมืออื่นๆ ของ PostgreSQL extension นี้ดูเหมือนจะเข้ากันได้กับเครื่องมือที่ใช้ logical replication เปิดความเป็นไปได้สำหรับการใช้งานกับโซลูชันการจัดการฐานข้อมูลต่างๆ อย่างไรก็ตาม ผู้ใช้ยังคงต้องใช้ patches เฉพาะเพื่อใช้ OrioleDB กับการติดตั้ง PostgreSQL มาตรฐาน
แผนงานการพัฒนารวมถึงฟีเจอร์ที่ทะเยอทะยานอย่าง multi-master capabilities แม้ว่าการมุ่งเน้นในทันทียังคงอยู่ที่การบรรลุสถานะ general availability แนวทางนี้แสดงให้เห็นการก้าวหน้าอย่างรอบคอบสู่ความพร้อมในการใช้งานจริงในขณะที่รักษาความเข้ากันได้กับระบบนิเวศของ PostgreSQL
ความกระตือรือร้นของชุมชนต่อการปรับปรุงประสิทธิภาพเหล่านี้สะท้อนถึงความปรารถนาที่กว้างขึ้นสำหรับโซลูชันฐานข้อมูลโอเพนซอร์สที่ทรงพลังมากขึ้นซึ่งไม่ต้องการการปรับแต่งอย่างกว้างขวาง ในขณะที่ OrioleDB ก้าวหน้าสู่ความเสถียร มันแสดงถึงก้าวสำคัญในวิวัฒนาการของ PostgreSQL แม้ว่าการรวมเข้ากับระบบ core จะยังคงไม่แน่นอน
อ้างอิง: OrioleDB beta12: features and benchmarks
 |
|---|
| การเปรียบเทียบเวลาแฝงระหว่าง OrioleDB และ PostgreSQL ในระหว่างการทดสอบ TPC-C แสดงให้เห็นข้อได้เปรียบด้านประสิทธิภาพที่สม่ำเสมอของ OrioleDB |