เครื่องมือจัดการ PostgreSQL ใหม่ที่ชื่อ PgDog ได้เปิดตัวขึ้นมา โดยสัญญาว่าจะแก้ไขปัญหาที่ท้าทายที่สุดอย่างหนึ่งในโลกของฐานข้อมูล นั่นคือการทำ sharding อัตโนมัติพร้อมการจัดการ query แบบโปร่งใส สร้างด้วย Rust และใช้ใบอนุญาต AGPL v3 โปรเจกต์โอเพนซอร์สนี้มีเป้าหมายที่จะทำให้การขยายขนาด PostgreSQL เป็นไปอย่างราบรื่นที่สุดสำหรับนักพัฒนา
คุณสมบัติหลัก:
- การรวมกลุ่มธุรกรรมที่รองรับการเชื่อมต่อหลายแสนครั้ง
- การกระจายโหลดในชั้นแอปพลิเคชัน (OSI Level 7) ด้วยกลยุทธ์หลากหลาย
- การแยกวิเคราะห์คิวรีอัตโนมัติและการกำหนดเส้นทาง shard โดยใช้ parser ดั้งเดิมของ PostgreSQL
- การประกอบผลลัพธ์คิวรีข้าม shard ในหน่วยความจำ
- CSV parser ในตัวสำหรับแบ่งคำสั่ง COPY ข้าม shard
- การรองรับโปรโตคอล logical replication สำหรับการ resharding แบบสด
Transparent Sharding พร้อมความฉลาดในการทำงานข้าม Shard
สิ่งที่น่าสนใจที่สุดของ PgDog อยู่ที่แนวทางการจัดการ distributed queries ไม่เหมือนกับโซลูชัน sharding แบบดั้งเดิมที่ต้องการให้แอปพลิเคชันรู้เรื่องการกระจายข้อมูล PgDog ทำงานที่ชั้น network layer ในขณะที่ยังคงความเข้ากันได้กับ PostgreSQL เครื่องมือนี้ใช้ parser ดั้งเดิมของ PostgreSQL เพื่อทำความเข้าใจ queries สกัด sharding keys และเส้นทาง requests ไปยัง shards ที่เหมาะสมโดยอัตโนมัติ
เมื่อ queries ครอบคลุมหลาย shards PgDog จะรวบรวมผลลัพธ์ในหน่วยความจำก่อนส่งไปยังไคลเอนต์ ความโปร่งใสนี้หมายความว่าแอปพลิเคชันที่มีอยู่สามารถได้รับประโยชน์จาก sharding โดยไม่ต้องเปลี่ยนแปลงโค้ด อย่างไรก็ตาม แนวทางนี้ทำให้เกิดคำถามสำคัญเกี่ยวกับประสิทธิภาพและการใช้ทรัพยากรที่ชุมชนกระตือรือร้นที่จะสำรวจ
คำถามเรื่องประสิทธิภาพและข้อกังวลในโลกจริง
ข้อเสนอแนะจากชุมชนในช่วงแรกเน้นช่องว่างที่สำคัญใน benchmarks ปัจจุบัน ในขณะที่ PgDog แสดงประสิทธิภาพที่น่าประทับใจสำหรับ connection pooling มาตรฐาน การทดสอบที่แท้จริงจะมาพร้อมกับ query parsing และการดำเนินการข้าม shard
หนึ่งในโปรเจกต์ Postgres ที่น่าสนใจที่สุดที่ฉันเคยเห็นมาหลายปี benchmarks ที่นำเสนอดูเหมือนจะจัดการเฉพาะ pooling มาตรฐาน ฉันอยากเห็นว่ามันจะเป็นอย่างไรเมื่อ query parsing และ cross-shard join เข้ามาเกี่ยวข้อง
ข้อกังวลนี้สะท้อนความสงสัยที่กว้างขึ้นในอุตสาหกรรมเกี่ยวกับโซลูชัน transparent sharding ภาระการคำนวณของการ parse ทุก query รวมกับความต้องการหน่วยความจำสำหรับการรวบรวมผลลัพธ์ข้าม shard อาจส่งผลกระทบต่อประสิทธิภาพอย่างมีนัยสำคัญภายใต้โหลดหนัก
 |
|---|
| ภาพหน้าจอนี้แสดงที่เก็บข้อมูล GitHub สำหรับโครงการ PgDog ซึ่งสะท้อนการอภิปรายที่กำลังดำเนินอยู่เกี่ยวกับประสิทธิภาพและการประเมินผลของโครงการ |
High Availability และความท้าทายในการดำเนินงาน
แนวทางของโปรเจกต์ต่อ high availability เผยให้เห็นทั้งจุดแข็งและข้อจำกัด PgDog จัดการ frontend proxies หลายตัวผ่านการซิงโครไนซ์การกำหนดค่าแทนที่จะใช้กลไก consensus การเลือกออกแบบนี้หลีกเลี่ยงสถานการณ์ split-brain ที่ซับซ้อน แต่ต้องการการประสานงานการปรับใช้อย่างระมัดระวัง
สำหรับการปรับใช้แบบไม่มีดาวน์ไทม์ แนวทางที่แนะนำเกี่ยวข้องกับการหยุดการรับส่งข้อมูลชั่วคราว โหลดการกำหนดค่าใหม่ และกลับมาดำเนินการภายในไม่กี่วินาที แม้ว่าจะใช้ได้กับการบำรุงรักษาตามแผน แต่ไม่ได้จัดการกับความล้มเหลวที่ไม่คาดคิดซึ่ง blue-green deployments กับ TCP load balancers กลายเป็นสิ่งจำเป็น
ข้อกำหนดการกำหนดค่า:
- การกำหนดค่าหลัก: pgdog.toml (การตั้งค่าทั่วไปและข้อมูลเซิร์ฟเวอร์)
- การกำหนดค่าผู้ใช้: users.toml (รายละเอียดการยืนยันตัวตน)
- การตรวจสอบ: จุดปลาย OpenMetrics และฐานข้อมูลผู้ดูแลระบบแบบ PgBouncer
- การปรับใช้: ขับเคลื่อนด้วยการกำหนดค่าพร้อมการโหลดซ้ำแบบซิงโครไนซ์สำหรับพร็อกซีหลายตัว
โมเดลธุรกิจและข้อพิจารณาเรื่องใบอนุญาต
ใบอนุญาต AGPL v3 ของ PgDog ได้จุดประกายการอภิปรายเกี่ยวกับการนำไปใช้ในองค์กร ใบอนุญาตอนุญาตให้ใช้งานภายในและการปรับเปลี่ยนส่วนตัวโดยไม่ต้องแบ่งปันซอร์สโค้ด แต่ต้องการให้องค์กรที่เสนอ PgDog เป็นบริการสาธารณะแบ่งปันการปรับเปลี่ยนของพวกเขา
ทีมพัฒนาวางแผนที่จะสร้างรายได้ผ่านการปรับใช้แบบจัดการและบริการสนับสนุน ตามรูปแบบที่ได้รับการยอมรับในซอฟต์แวร์โครงสร้างพื้นฐาน อย่างไรก็ตาม องค์กรบางแห่งยังคงระมัดระวังเกี่ยวกับใบอนุญาต AGPL แม้จะมีการชี้แจงจากนักพัฒนา
มองไปข้างหน้า
PgDog เป็นตัวแทนของความพยายามที่ทะเยอทะยานในการแก้ไขความท้าทายการขยายขนาดแนวนอนของ PostgreSQL ผ่าน intelligent proxying ความสำเร็จของโปรเจกต์จะขึ้นอยู่กับว่ามันจัดการกับผลกระทบด้านประสิทธิภาพของ transparent sharding ได้ดีเพียงใด และสามารถส่งมอบตามสัญญาของการขยายขนาดที่ราบรื่นได้หรือไม่
เนื่องจากโปรเจกต์ยังอยู่ในช่วงเริ่มต้น ผู้ที่อาจนำไปใช้ควรทดสอบกรณีการใช้งานเฉพาะของพวกเขาอย่างละเอียด โดยเฉพาะอย่างยิ่งที่เกี่ยวข้องกับ cross-shard queries ที่ซับซ้อน เดือนที่จะมาถึงจะเผยให้เห็นว่า PgDog สามารถเชื่อมช่องว่างระหว่างความน่าเชื่อถือของ PostgreSQL และความต้องการการขยายขนาดของแอปพลิเคชันสมัยใหม่ได้หรือไม่
อ้างอิง: PgDog