PgDog - เครื่องมือสำหรับชาร์ด Postgres ได้โดยไม่ต้องมีส่วนขยายเพิ่มเติม

 (github.com/pgdogdev)
4 คะแนน โดย GN⁺ 2025-05-29 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ตัวจัดการ transaction pooler และ logical replication สำหรับ PostgreSQL ที่พัฒนาด้วย Rust พร้อมความสามารถด้าน การขยายแนวนอน และการทำชาร์ดอัตโนมัติ
  • สามารถ ชาร์ดฐานข้อมูล PostgreSQL ได้อย่างง่ายดายโดยไม่ต้องใช้ extension และเหมาะกับการจัดการฐานข้อมูลหลายร้อยชุดกับการเชื่อมต่อหลายแสนรายการ
  • เป็น ตัวทำโหลดบาลานซ์ DB ที่ทำงานในชั้นแอปพลิเคชัน (OSI 7) โดยสามารถกำหนดเส้นทาง SELECT ไปยัง replica และส่งคำสั่งที่เหลือไปยัง primary โดยอัตโนมัติ
  • รองรับ transaction/session pooling แบบเดียวกับ PgBouncer พร้อมทั้ง แยกวิเคราะห์คิวรีเพื่อกำหนดเส้นทางไปยัง shard โดยอัตโนมัติ และ รวมผลลัพธ์ให้เสร็จได้ด้วย
  • ใช้ COPY และ logical replication เพื่อ กระจายข้อมูลไปยัง shard โดยอัตโนมัติ หรือชาร์ดฐานข้อมูลเดิมแบบไม่ต้องหยุดระบบ ได้
  • การตั้งค่าสามารถกำหนดได้อย่างง่ายดายด้วยไฟล์ TOML และ ปรับตั้งค่าใหม่ได้ระหว่างรันไทม์
  • ต่างจาก Citus ที่ใช้ Postgres extension ตรงที่เป็นพร็อกซีภายนอกฐานข้อมูล จึง ใช้งานได้บน RDS, Cloud SQL เป็นต้น

แนะนำโปรเจ็กต์และคุณค่าหลัก

  • PgDog เป็นโอเพนซอร์สโซลูชันที่รองรับการขยายแนวนอนของฐานข้อมูล PostgreSQL อย่างรอบด้าน ทั้ง การชาร์ดที่ทำได้ง่าย, logical replication, transaction pooling และ L7 load balancing
  • พัฒนาด้วยภาษา Rust จึงให้ทั้ง ประสิทธิภาพสูง และ ความปลอดภัย
  • PgDog ทำให้เกิด การชาร์ด, การกระจายข้อมูล, การกู้คืนความขัดข้อง และการทำโหลดบาลานซ์ที่ยืดหยุ่น ได้ด้วยการติดตั้งพร็อกซีเพียงตัวเดียวโดยไม่ต้องติดตั้ง extension
  • แตกต่างจากผลิตภัณฑ์คู่แข่ง (เช่น PgBouncer, PgCat) ตรงที่รองรับทั้ง automatic sharding และ logical replication ครบถ้วน และมีจุดเด่นที่ เปลี่ยนการตั้งค่าระหว่างใช้งานจริงและมอนิเตอร์แบบเรียลไทม์ได้

ความสามารถหลัก

โหลดบาลานซ์ (Load Balancer)

  • PgDog เป็น application-level proxy ใน OSI layer 7 ที่กระจายคิวรีไปยังโหนด PostgreSQL หลักและ replica หลายตัว เพื่อช่วยป้องกันปัญหาความขัดข้องและโหลดสูง
  • มีหลายกลยุทธ์การกระจาย เช่น round-robin, random และ least connections
  • ตรวจจับประเภทของคิวรีเพื่อแยกส่ง SELECT ไปยัง replica และคิวรีเขียนอื่น ๆ ไปยังโหนดหลักโดยอัตโนมัติ
  • รองรับ health check และทำ failover อัตโนมัติเมื่อเกิดปัญหา ช่วยคงความพร้อมใช้งานแม้เกิดข้อผิดพลาดเครือข่ายหรือฮาร์ดแวร์ขัดข้อง

Transaction Pooling

  • PgDog รองรับ transaction/session pooling แบบ PgBouncer เพื่อจัดการทรัพยากร connection อย่างมีประสิทธิภาพ ทำให้รองรับไคลเอนต์หลายแสนรายได้ด้วย backend connection เพียงจำนวนน้อย

การชาร์ด

  • แยกวิเคราะห์ไวยากรณ์คิวรีโดยตรงเพื่อ ดึง sharding key และใช้การกำหนดเส้นทางที่เหมาะสมที่สุด
  • รองรับ cross-shard query ระหว่างฐานข้อมูลหลาย shard และรวมผลลัพธ์ในหน่วยความจำก่อนส่งกลับให้ไคลเอนต์แบบโปร่งใส
  • เมื่อรันคำสั่ง COPY จะรองรับ การกระจายข้อมูลหลาย shard ผ่านการแยกวิเคราะห์ CSV ซึ่งสะดวกต่อการโหลดข้อมูลปริมาณมาก
  • อิงตาม PostgreSQL logical replication protocol เพื่อซิงก์เบื้องหลังแบบไม่ต้องหยุดระบบ และเพิ่ม shard หรือขยายระบบได้แบบเรียลไทม์ระหว่างใช้งาน

การมอนิเตอร์

  • รองรับทั้ง ฐานข้อมูลสำหรับการจัดการ สไตล์ PgBouncer และ OpenMetrics endpoint
  • มีตัวอย่างสำหรับมอนิเตอร์และแดชบอร์ดภายนอก เช่น Datadog

การตั้งค่าและรันไทม์

  • สภาพแวดล้อมหลัก: Kubernetes (มี Helm chart), Docker และสภาพแวดล้อมโลคัล (build ด้วย Rust) ซึ่งทำให้ deploy และทดสอบได้ง่าย
  • โดยทั่วไปเพียงเขียน ไฟล์ตั้งค่า 2 ไฟล์ (pgdog.toml, users.toml) ก็สามารถตั้งค่าสภาพแวดล้อมขั้นต่ำสำหรับการชาร์ดและการใช้งานตามผู้ใช้ได้ครบ
  • ค่าการตั้งค่าส่วนใหญ่แก้ไขได้แบบเรียลไทม์ และมีผลแบบไดนามิกโดยไม่ต้องรีสตาร์ตโปรเซส

ประสิทธิภาพและไลเซนส์

  • PgDog เป็น network proxy แบบ asynchronous ประสิทธิภาพสูง ที่สร้างบน Rust และ Tokio โดยมุ่งลดการเคลื่อนย้ายข้อมูลให้น้อยที่สุดและจำกัดผลกระทบด้านประสิทธิภาพ
  • มีผล benchmark ให้ดูในเอกสารทางการเพื่อนำไปใช้ตั้งเกณฑ์ประสิทธิภาพได้
  • ใช้โอเพนซอร์สไลเซนส์ AGPL v3 เปิดกว้างเต็มที่ต่อการใช้งานภายในองค์กรและการปรับแต่งแบบส่วนตัว
  • อย่างไรก็ตาม บริษัทที่ให้บริการบน public cloud จะมีเงื่อนไขว่า หากมีการแก้ไขโค้ด ต้องเปิดเผยรายละเอียดการแก้ไขนั้น

สถานะโครงการและการมีส่วนร่วม

  • ปัจจุบันยังอยู่ในระยะเริ่มต้น จึงแนะนำให้ กลุ่ม early adopter ทดลองนำไปใช้ก่อน โดยความเสถียรของแต่ละฟีเจอร์ยังคงได้รับการอัปเดตอย่างต่อเนื่อง
  • มีการทดสอบและ benchmark แยกตามความสามารถอย่างต่อเนื่อง
  • ยินดีต้อนรับการมีส่วนร่วมจากชุมชนโอเพนซอร์ส รายละเอียดเพิ่มเติมดูได้ใน Contribution Guidelines

บทสรุป

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

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

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

 
GN⁺ 2025-05-29
ความคิดเห็นบน Hacker News

  • ทักทาย Lev พร้อมอธิบายว่ากำลังเปรียบเทียบ PgDog กับการสร้างระบบเองสำหรับการทำ sharding ให้ฐานข้อมูล Postgres ขนาด 40TB ในตอนนี้ โดยบอกว่าต้องการโซลูชันที่ทำงานคล้าย Vitess for PostgreSQL และย้ำว่านอกจากความสามารถแบบ scatter gather แล้ว ยังต้องมีการจัดการคอนฟิกที่อิงกับสิ่งอย่าง etcd การแบ่ง shard และธุรกรรมแบบ best-effort สำหรับการปรับ schema กับทุก shard ด้วย อีกทั้งยังถามถึงประสบการณ์การ rewrite query ด้วย pg_query.rs พร้อมแชร์ว่ารู้สึกว่าการ rewrite ทำได้ยากเพราะ AST type เป็น immutable และขาด deep clone สุดท้ายเลยกำลังใช้ sqlparser crate ที่รองรับ Visitor pattern และกำลังพัฒนา side project สำหรับ online schema change ของ PG โดยอิงกับ shadow tables และ logical replication

    • ยินดีมากกับข้อเสนอให้ร่วมงานและแชร์ช่องทางติดต่อ พร้อมอธิบายว่าการจัดการคอนฟิกสามารถแก้ได้อยู่แล้วด้วย K8s หรือเครื่องมือ CD หลายแบบ และสามารถซิงก์การ reload config ของ PgDog ได้, การเปลี่ยน schema ทุก shard ด้วยธุรกรรมแบบ best-effort ใช้งานได้แล้ว โดยแม้ schema change แบบ idempotent จะดีที่สุด แต่ถ้าล้มเหลวก็อาจพิจารณา two-phase commit, ส่วนการแบ่ง shard สามารถทำได้ด้วย logical replication พร้อมยกประสบการณ์ที่ Instacart กับข้อมูล 10TB+ เป็นตัวอย่าง โดยแชร์ขั้นตอนเปิด replication slot แล้วกู้คืนด้วย N instances ลบข้อมูลที่หมายเลข shard ไม่ตรงกัน และทำ resync ผ่าน logical replication, ยังพูดถึงไอเดียใช้ logical replication ของ Pg 17 บน streaming replica เพื่อทำการ split แบบขนาน และกำลังคิดวิธี COPY ข้อมูลโดยตรงด้วย foreign tables ด้วย, สำหรับ pg_query.rs ดูเหมือนตอนนี้จะทำงานแบบ mutable ได้แล้ว จึงช่วงหลังนำมาใช้จริงอย่างหนักในการ rewrite และสร้าง query โดยย้ำว่าจุดเด่นสำคัญคืออิงกับ parser ของ Postgres 100% และมีความสามารถ "deparse" กระจายอยู่หลายจุด ทำให้งานซับซ้อนมีความเป็นไปได้สูง

  • ถ้ามี Vitess for Postgres แล้ว Yugabyte ไม่ได้ทำหน้าที่นั้นอยู่หรือ เป็นคำถามที่มีคนตั้งขึ้น

  • เมื่อดูเฉพาะความสามารถหลักอาจเหมือนเล็ก แต่คิดว่าประโยชน์มหาศาลของ PgDog คือช่วยตัดโค้ดออกไปและแยกการอ่านไปที่ read replica การเขียนไปที่ primary ได้ หลายแอปไม่ได้รองรับการแยก R/W โดยตรง ดังนั้นการทำที่ระดับ proxy เคยช่วยให้ประสิทธิภาพดีขึ้นมากในอดีต จึงขอชื่นชมโครงการนี้

    • มีการแนะนำว่าฟีเจอร์นี้ใช้ได้อยู่แล้วใน pgcat และแชร์ ลิงก์ pgcat

    • มีคนแชร์ว่าที่ Instacart เคยใช้ Makara เพื่อแยก R/W แต่ประสบการณ์คือการต้องทำแบบเดียวกันซ้ำ ๆ ในหลายภาษาอย่าง Python หรือ Go ค่อนข้างยุ่งยาก

  • มีความเห็นว่าโครงการนี้น่าประทับใจ แต่ยังรู้สึกห่าง ๆ กับ sharding แบบอัตโนมัติเต็มรูปแบบ โดยปกติ sharding มักทำที่ขอบเขตของ tenancy และอยากให้การข้ามขอบเขตนี้มี friction อยู่บ้าง เพราะ cross-shard join นั้นต่างจาก in-shard join ทั้งด้านประสิทธิภาพ หน่วยความจำ และ CPU จึงอยากให้จุดนี้ถูกแสดงออกอย่างชัดเจน อย่างไรก็ตามไม่ได้สงสัยในตัวโครงการ และเชื่อว่าจะมี use case มากมาย

    • มีคนถามกลับว่าทำไมถึงอยากให้มี friction โดยเสริมว่าปัญหาด้านประสิทธิภาพของ cross-shard join นั้นส่วนใหญ่เข้าใจกันดีและติดตามได้ด้วย real-time metrics สุดท้ายแล้วต้องมีทั้งสองแนวทาง และทางเลือกที่ให้แอปโค้ดเป็นคน join เองก็ไม่ค่อยน่าพึงประสงค์นัก

  • กำลังจับตาดู PgDog อยู่และมองว่าน่าประทับใจมาก พร้อมแสดงความยินดีกับการเปิดตัวและหวังว่าจะพัฒนาต่อไป

    • มีการบอกว่าเส้นทาง 15 ปีเพิ่งเริ่มต้นเท่านั้น

  • มีความเห็นว่าเสน่ห์หลักคือการจัดการ distributed query พร้อมรักษาความโปร่งใสและความเข้ากันได้ไว้ที่ชั้น network โดยข้อจำกัดในเอกสารตอนนี้ถือว่าเป็นเรื่องปกติและคาดว่าจำเป็นต้องมี trade-off อยากรู้ว่าจะจัดการอย่างไร และถ้ามีการพูดคุยเพิ่มเติมก็อยากเข้าร่วมด้วย

  • มีคนบอกว่าในโซลูชันอย่าง PgDog ความยากที่สุดคือการจัดการ complex query บนระบบ sharded ให้ถูกต้องจนถึง 1% สุดท้ายจริง ๆ (หรือไม่ก็ตรวจจับ query ที่ผิดปกติ) รวมถึงการรับประกัน isolation และ consistency อย่างสมบูรณ์

  • มีคนบอกว่าทันทีที่เปิดเอกสารก็เช็กก่อนเลยว่ารองรับ Unique Index หรือไม่ แต่ก็น่าเสียดายที่ตอนนี้ยังไม่รองรับเพราะต้องมีทั้งการ rewrite query และ execution engine แยกต่างหาก ถึงอย่างนั้นก็ยังมองเห็นศักยภาพและคาดหวังไว้

    • มีการตอบว่าตอนนี้รองรับการสร้าง primary key ที่ไม่ซ้ำกันในทุก shard แล้วเป็นรางวัลเล็ก ๆ พร้อมแชร์ ลิงก์เอกสารที่เกี่ยวข้อง, ส่วนการทำ cross-shard unique index ต้องตรวจสอบกับทุก query จึงมีต้นทุนสูง และยังเปิดกว้างเรื่องไอเดีย

  • มีความเห็นว่านี่คือโครงการ Postgres ที่น่าสนใจที่สุดในรอบหลายปี โดยมองว่า benchmark ที่ให้มาน่าจะครอบคลุมแค่ connection pooling พื้นฐาน เลยสงสัยว่าผลจะเป็นอย่างไรเมื่อมี query parsing หรือ cross-shard join ทำงานจริง

    • มีการอธิบายว่า query parser ถูก cache ไว้แล้ว ดังนั้นถ้าใช้ prepared query หรือ placeholder จะเพิ่มเพียง lock กับ hash lookup เท่านั้น จึงแทบไม่มีต้นทุน, ส่วน cross-shard join นั้นถ้า filter ไม่เหมาะสม ต้นทุนประมวลผล query อาจสูงขึ้น และเมื่อ result set ใหญ่อาจต้อง page ลงดิสก์ด้วย คาดว่าตอนนี้ยังโฟกัส OLTP ก่อนและพยายาม push down การ join ให้มากที่สุด พร้อมคาดว่าความต้องการ cross-shard join จะเพิ่มขึ้นในไม่ช้า

  • มีคนประเมินว่านี่คือความก้าวหน้าที่จำเป็นอย่างมากต่อความสามารถในการขยายระบบของ Postgres พร้อมแสดงความยินดีกับการเปิดตัว

  • มีความเห็นว่าโครงการนี้ดูยอดเยี่ยมมากและขอแสดงความยินดีกับการเปิดตัว

    • มีการย้ำว่านี่คือผลลัพธ์จากความพยายามหลายปี