Ruby gem ใหม่ที่ชื่อ pg_hash_func สัญญาว่าจะเพิ่มความเร็วของ query สำหรับ hash partition ของ PostgreSQL ได้มากถึง 20 เท่า แต่ชุมชนนักพัฒนากำลังตั้งคำถามว่าการอ้างสิทธิ์ด้านประสิทธิภาพนี้จะยืนหยัดได้ในสถานการณ์จริงหรือไม่ gem นี้มีเป้าหมายที่จะข้าม catalog lookup overhead ของ PostgreSQL โดยการคำนวณตำแหน่ง partition โดยตรงในโค้ดแอปพลิเคชัน
ขาดหลักฐานประสิทธิภาพในโลกแห่งความจริง
ความกังวลที่ใหญ่ที่สุดที่นักพัฒนาหยิบยกขึ้นมาคือการขาด benchmark ประสิทธิภาพ query จริง ในขณะที่ผู้สร้าง gem อ้างว่ามีการปรับปรุงความเร็วอย่างมีนัยสำคัญ แต่ benchmark เหล่านั้นวัดเพียงเวลาการคำนวณ hash เท่านั้น ไม่ใช่การดำเนิน query ที่สมบูรณ์ นักวิจารณ์ชี้ให้เห็นว่าแนวทางนี้ล้มเหลวในการพิจารณาสิ่งที่เกิดขึ้นระหว่างการดำเนินการฐานข้อมูลจริง ซึ่ง catalog lookups เป็นเพียงส่วนหนึ่งของกระบวนการ query โดยรวม
ชุมชนมีความสงสัยเป็นพิเศษเพราะการเปรียบเทียบประสิทธิภาพแสดงเพียงการคำนวณ hash ของ Ruby เทียบกับการคำนวณ hash ของ SQL เท่านั้น โดยไม่แสดงให้เห็นถึงการปรับปรุงประสิทธิภาพ query แบบ end-to-end เมื่อ query partition เฉพาะเทียบกับการปล่อยให้ PostgreSQL จัดการการเลือก partition โดยอัตโนมัติ
การอ้างสิทธิ์ด้านประสิทธิภาพเทียบกับความเป็นจริง
- การปรับปรุงที่อ้างสิทธิ์: เร็วกว่า 20-40 เท่าในการคำนวณ hash
- ขอบเขตของ benchmark: เฉพาะเวลาการคำนวณ hash ไม่ใช่การดำเนินการ query ทั้งหมด
- ข้อมูลที่ขาดหายไป: การเปรียบเทียบประสิทธิภาพ query แบบ end-to-end
- ความกังวลของชุมชน: ไม่มีการให้ benchmark ของ query ในโลกแห่งความจริง
ความเสี่ยงด้านการบำรุงรักษาและความเข้ากันได้
นักพัฒนาหลายคนได้เน้นย้ำถึงฝันร้ายด้านการบำรุงรักษาที่อาจเกิดขึ้นจากการ implement hash functions ภายในของ PostgreSQL ใหม่ แนวทางนี้ต้องการการซิงโครไนซ์กับรายละเอียดการ implement ภายในของ PostgreSQL ซึ่งอาจเปลี่ยนแปลงระหว่างเวอร์ชัน สิ่งนี้สร้างการเชื่อมโยงที่แน่นหนาระหว่างโค้ดแอปพลิเคชันและ PostgreSQL เวอร์ชันเฉพาะที่หลายคนพบว่าน่ากังวล
สิ่งนี้ดูเหมือนฝันร้ายด้านการบำรุงรักษาในอนาคต แต่ฉันอาจผิดก็ได้ หากคุณติดอยู่กับ PostgreSQL เวอร์ชันเฉพาะเป็นเวลานาน บางทีมันอาจคุ้มค่า
gem ปัจจุบันรองรับเพียงการแบ่ง partition แบบ integer (bigint, integer, smallint) และขาดการรองรับ text, UUID หรือประเภทข้อมูลทั่วไปอื่นๆ ซึ่งจำกัดการใช้งานในทางปฏิบัติมากขึ้น
ข้อจำกัดปัจจุบันของ gem pg_hash_func
- ประเภทข้อมูลที่รองรับ: bigint (int8), integer (int4), smallint (int2)
- ประเภทข้อมูลที่ไม่รองรับ: text/string, UUID, ประเภทข้อมูลอื่นๆ
- แพลตฟอร์ม: Ruby เท่านั้น
- การพึ่งพาเวอร์ชัน PostgreSQL: ต้องการการซิงโครไนซ์กับการเปลี่ยนแปลงการใช้งานภายใน
กลยุทธ์การปรับปรุงที่น่าสงสัย
สมาชิกชุมชนยังตั้งคำถามเกี่ยวกับหลักฐานพื้นฐานของการปรับปรุง Hash partitioning มักถูกเลือกโดยเฉพาะเมื่อคุณไม่ทราบรูปแบบข้อมูลล่วงหน้า แต่แนวทางนี้ต้องการความรู้โดยละเอียดเกี่ยวกับ partition keys และโครงสร้าง สิ่งนี้ดูเหมือนจะขัดแย้งกับข้อได้เปรียบหลักอย่างหนึ่งของ hash partitioning - การกระจายข้อมูลโดยไม่ต้องการการวิเคราะห์รูปแบบล่วงหน้า
โซลูชันที่เสนอในการใช้ SQL queries แบบ static ด้วย hash functions ที่ hardcode แทนที่จะใช้ catalog routines ของ PostgreSQL ทำให้นักพัฒนาบางคนงงงวย เนื่องจากมันเพิ่มความซับซ้อนในขณะที่อาจเสียสละการปรับปรุงที่มีอยู่แล้วใน PostgreSQL
สรุป
แม้ว่าแนวคิดของการปรับปรุง PostgreSQL partition queries จะมีคุณค่า แต่การตอบสนองของชุมชนแสดงให้เห็นว่าจำเป็นต้องมี benchmark ที่ครอบคลุมมากขึ้นและการทดสอบในโลกจริงเพื่อตรวจสอบประโยชน์ที่อ้างไว้ แนวทางนี้อาจมีคุณค่าสำหรับสถานการณ์ high-throughput เฉพาะที่มี PostgreSQL เวอร์ชันที่เสถียร แต่ overhead ด้านการบำรุงรักษาและขอบเขตที่จำกัดทำให้เกิดคำถามเกี่ยวกับการใช้งานในวงกว้าง นักพัฒนาดูเหมือนจะสนใจที่จะเห็นการเปรียบเทียบประสิทธิภาพ query จริงมากกว่า benchmark การคำนวณ hash แยกต่างหากเพื่อประเมินเทคนิคการปรับปรุงนี้อย่างเหมาะสม
อ้างอิง: Bypass PostgreSQL catalog overhead with direct partition hash calculations