Hyperdrive คือบริการจัดการ connection-pooling ที่ช่วยให้ Workers สามารถสื่อสารกับฐานข้อมูล PostgreSQL ได้โดยตรง รวมถึงฐานข้อมูลที่ใช้ส่วนขยาย pgvector สำหรับการค้นหาแบบเวกเตอร์ (vector search) ด้วย การเก็บชุดการเชื่อมต่อฐานข้อมูลที่นำกลับมาใช้ใหม่ได้ไว้ใกล้กับเซิร์ฟเวอร์ ช่วยให้ Hyperdrive ลดภาระงาน (overhead) จากการทำ handshake ที่เป็นอุปสรรคต่อเวิร์กโหลด edge AI มาอย่างยาวนาน

ทำไม Workers และ PostgreSQL ถึงทำงานร่วมกันได้ยาก

Cloudflare Workers ทำงานในรูปแบบฟังก์ชัน JavaScript ที่มีอายุการใช้งานสั้น ณ ตำแหน่ง edge หลายแห่ง แต่ละคำขอ (request) ที่เข้ามาจะเริ่มกระบวนการใหม่ และรูปแบบปกติคือการเปิดการเชื่อมต่อ TCP ใหม่ไปยังฐานข้อมูลหลังบ้าน อย่างไรก็ตาม PostgreSQL คาดหวังการเชื่อมต่อที่เสถียรต่อหนึ่งกระบวนการของไคลเอนต์ และมีการจำกัดจำนวนการเชื่อมต่อพร้อมกันทั้งหมด ผลลัพธ์ที่ได้คือปัญหาสองประการ:

  • ต้นทุนการเชื่อมต่อสูง – การสร้างการเชื่อมต่อต้องมีการรับส่งข้อมูลหลายรอบ (round trips) เพื่อการยืนยันตัวตนและการเจรจาโปรโตคอล ซึ่งการรับส่งข้อมูลเหล่านั้นจะเพิ่มความหน่วง (latency) ให้กับทุกคำขอ
  • ข้อจำกัดด้านการเชื่อมต่อ – Workers สามารถขยายตัวได้ถึงหลายพันการทำงานพร้อมกัน ซึ่งอาจทำให้ connection pool ของ PostgreSQL เต็มอย่างรวดเร็ว และอาจทำให้ฐานข้อมูลล่มได้

Hyperdrive ช่วยเชื่อมช่องว่างนี้ได้อย่างไร

Hyperdrive ทำหน้าที่อยู่ระหว่าง Worker และฐานข้อมูล โดยรักษา pool ของการเชื่อมต่อที่คงอยู่ (persistent connections) ไว้บนเซิร์ฟเวอร์ที่มีเครือข่ายใกล้กับอินสแตนซ์ของ PostgreSQL ในมุมมองของ Worker สิ่งเดียวที่เปลี่ยนไปคือ connection string ใหม่ ภายในระบบ proxy จะนำการเชื่อมต่อที่มีอยู่แล้วมาใช้ซ้ำสำหรับแต่ละคิวรี (query) ที่เข้ามา ซึ่งช่วยกำจัดต้นทุนจากการทำ handshake

การตั้งค่าถูกออกแบบมาให้เบาและง่าย:

  1. รัน Wrangler CLI (เครื่องมือ command-line ของ Cloudflare) เพื่อสร้างอินสแตนซ์ Hyperdrive โดยระบุ URL ของฐานข้อมูลต้นฉบับ
  2. เพิ่ม Hyperdrive binding ที่สร้างขึ้นลงในไฟล์กำหนดค่า wrangler.toml
  3. ใช้ driver ที่รองรับ เช่น node-postgres ในโค้ดของ Worker โดย driver จะมองเห็น endpoint ของ Hyperdrive เป็นเซิร์ฟเวอร์ PostgreSQL ปกติ

เนื่องจากรหัสผ่านของฐานข้อมูลถูกเก็บไว้ในคอนฟิกูเรชันของ Hyperdrive เท่านั้น จึงไม่ปรากฏในซอร์สโค้ดของ Worker ซึ่งช่วยลดช่องทางการโจมตี (attack surface)

เคล็ดลับในการใช้งานสำหรับการค้นหาแบบเวกเตอร์

เวิร์กโหลดการค้นหาแบบเวกเตอร์ที่ใช้ pgvector จะเกี่ยวข้องกับอาร์เรย์เลขทศนิยม (floating-point arrays) ขนาดใหญ่ที่มีแนวโน้มจะเปลี่ยนแปลงในทุกๆ คิวรี พฤติกรรมเริ่มต้นของ Hyperdrive จะรวมถึงการทำ read cache ซึ่งอาจขัดแย้งกับข้อมูลที่มีการเปลี่ยนแปลงตลอดเวลา เพื่อให้ได้ผลลัพธ์ที่สดใหม่เสมอ ให้สร้างคอนฟิกูเรชัน Hyperdrive ตัวที่สองโดยปิดการใช้งานการทำแคช (caching)

ธุรกรรม (transaction) ที่ทำงานนานเกินไปก็เป็นอีกหนึ่งข้อควรระวัง การถือการเชื่อมต่อฐานข้อมูลค้างไว้ในขณะที่รอการตอบกลับจากโมเดล AI ภายนอก จะเป็นการจองช่องใน pool และทำให้จุดประสงค์ของการทำ pooling เสียไป รูปแบบที่แนะนำคือ:

  • เปิด transaction
  • รันคิวรี
  • Commit ทันที
  • เรียกใช้โมเดล AI นอก transaction

การปรับจูนพารามิเตอร์ของ pgvector (เช่น การตั้งค่า hnsw.ef_search ที่ควบคุมความแม่นยำในการค้นหา) สามารถทำได้ด้วยคำสั่ง SET LOCAL ภายใน transaction สั้นๆ วิธีนี้จะช่วยให้แน่ใจว่าการเปลี่ยนแปลงจะมีผลเฉพาะกับคิวรีปัจจุบันเท่านั้น และไม่ส่งผลกระทบต่อ Workers ตัวอื่นๆ ที่ใช้ pool ร่วมกัน

ข้อจำกัดที่ยังคงมีอยู่

Hyperdrive ไม่ได้ย้ายตำแหน่งของฐานข้อมูล หากเซิร์ฟเวอร์ PostgreSQL ตั้งอยู่ในภูมิภาคคลาวด์ที่ห่างไกล ความหน่วงจะยังคงถูกจำกัดด้วยระยะทางทางกายภาพนั้น ฟีเจอร์ “Smart Placement” ของ Cloudflare สามารถช่วยได้โดยการส่ง Workers ไปยัง edge node ที่ใกล้ที่สุดที่มีอินสแตนซ์ Hyperdrive อยู่ด้วย แต่ก็ไม่สามารถกำจัดระยะการรับส่งข้อมูลทางเครือข่าย (network round-trip) พื้นฐานได้

เลเยอร์การทำแคช แม้จะมีประโยชน์สำหรับการอ่านข้อมูลแบบคงที่ (static reads) แต่จะเกิด cache miss บ่อยครั้งกับข้อมูลเวกเตอร์ที่มีการเปลี่ยนแปลงตามคำขอ นักพัฒนาจำเป็นต้องชั่งน้ำหนักระหว่างอัตราการเกิด cache hits กับความสดใหม่ของผลลัพธ์การค้นหา

เมื่อไหร่ควรเลือกทางเลือกอื่น

หากแอปพลิเคชันต้องการเพียงการจัดเก็บเวกเตอร์แบบบริสุทธิ์โดยไม่มีการ join ข้อมูลเชิงสัมพันธ์ (relational joins) Cloudflare มีบริการเฉพาะที่เรียกว่า Vectorize ซึ่ง Vectorize จะจัดเก็บเวกเตอร์ไว้ที่ edge โดยตรงและไม่จำเป็นต้องมี PostgreSQL เป็นหลังบ้าน Hyperdrive ยังคงเป็นตัวเลือกที่ดีกว่าเมื่อเวกเตอร์ต้องถูกนำไป join กับตารางเชิงสัมพันธ์ที่มีอยู่ เช่น โปรไฟล์ผู้ใช้หรือประวัติการทำธุรกรรม

บทสรุป

Hyperdrive มอบเครื่องมือที่ใช้งานได้จริงให้แก่นักพัฒนา edge เพื่อรันการค้นหาแบบเวกเตอร์ที่ขับเคลื่อนด้วย AI โดยไม่ทำให้ขีดจำกัดการเชื่อมต่อ PostgreSQL พุ่งสูงขึ้น มันช่วยลดความหน่วงจากการทำ handshake, รวมศูนย์ข้อมูลประจำตัว (credentials), และให้การควบคุมการทำแคชและความยาวของ transaction อย่างละเอียด แม้บริการนี้จะไม่สามารถลบระยะห่างพื้นฐานระหว่าง edge และฐานข้อมูลได้ และปัญหา cache-miss ยังคงเป็นสิ่งที่ต้องคำนึงถึง แต่สำหรับเวิร์กโหลดที่ต้องการทั้งการ join ข้อมูลเชิงสัมพันธ์และความคล้ายคลึงของเวกเตอร์ Hyperdrive คือเส้นทางที่ตรงที่สุดไปสู่ edge stack ที่ขยายตัวได้และมีความหน่วงต่ำ