Hyperdrive הוא שירות מנוהל לניהול מאגר חיבורים (connection-pooling) המאפשר ל-Workers לתקשר ישירות עם מסדי נתונים מסוג PostgreSQL – כולל אלו המשתמשים בתוסף pgvector לחיפוש וקטורי. על ידי שמירה על סט חיבורים לשימוש חוזר בקרבת השרת, Hyperdrive מפחית את עומס ה-handshake שעיכב זמן רב עומסי עבודה של AI ב-edge.
מדוע Workers ו-PostgreSQL מתנגשים
Cloudflare Workers פועלים כפונקציות JavaScript קצרות מועד בעשרות מיקומי edge. כל בקשה נכנסת מתחילה תהליך חדש, והדפוס המקובל הוא לפתוח חיבור TCP חדש למסד הנתונים ב-backend. עם זאת, PostgreSQL מצפה לחיבור יציב לכל תהליך לקוח ומגביל את המספר הכולל של חיבורים בו-זמניים. התוצאה היא שתי בעיות:
- עלות חיבור גבוהה – יצירת חיבור דורשת מספר סבבי תקשורת (round trips) לצורך אימות וניהול פרוטוקול. סבבים אלו מוסיפים שיהוי (latency) לכל בקשה.
- מגבלות חיבור – Workers יכולים להתרחב לאלפי הרצות בו-זמניות, מה שעלול לרוקן במהירות את מאגר החיבורים של PostgreSQL ואף לגרום לקריסת מסד הנתונים.
כיצד Hyperdrive מגשר על הפער
Hyperdrive ממוקם בין ה-Worker לבין מסד הנתונים, ושומר על מאגר של חיבורים קבועים (persistent connections) בשרת הקרוב מבחינה רשתית למופע ה-PostgreSQL. מנקודת המבט של ה-Worker, השינוי היחיד הוא מחרוזת חיבור (connection string) חדשה. מבחינה פנימית, ה-proxy משתמש מחדש בחיבור קיים עבור כל שאילתה נכנסת, ובכך מבטל את עלות ה-handshake.
ההגדרה קלה במכוון:
- הרץ את ה-Wrangler CLI (כלי שורת הפקודה של Cloudflare) כדי ליצור מופע Hyperdrive, תוך אספקת ה-URL המקורי של מסד הנתונים.
- הוסף את ה-Hyperdrive binding שנוצר לקובץ ההגדרות
wrangler.toml. - השתמש בדרייבר תואם כמו
node-postgresבקוד ה-Worker; הדרייבר רואה בנקודת הקצה (endpoint) של Hyperdrive כשרת PostgreSQL רגיל.
מכיוון שסיסמת מסד הנתונים קיימת רק בהגדרות ה-Hyperdrive, היא לעולם לא מופיעה בקוד המקור של ה-Worker, מה שמצמצם את שטח התקיפה (attack surface).
טיפים מעשיים לחיפוש וקטורי
עומסי עבודה של חיפוש וקטורי המשתמשים ב-pgvector כוללים מערכים גדולים של נקודה צפה (floating-point) הנוטים להשתנות בכל שאילתה. ההתנהגות ברירת המחדל של Hyperdrive כוללת מטמון קריאה (read cache), שעלול להתנגש עם נתונים המשתנים ללא הרף. כדי לשמור על תוצאות מעודכנות, צור הגדרת Hyperdrive שנייה עם ביטול המטמון (caching disabled).
טרנזקציות ארוכות הן מלכודת נוספת. החזקת חיבור למסד הנתונים בזמן המתנה לתגובה של מודל AI חיצוני תופסת מקום במאגר ומבטלת את המטרה של ניהול מאגר חיבורים. הדפוס המומלץ הוא:
- פתיחת טרנזקציה.
- ביצוע השאילתה.
- ביצוע Commit באופן מיידי.
- קריאה למודל ה-AI מחוץ לטרנזקציה.
כוונון עדין (Fine-tuning) של פרמטרים ב-pgvector (למשל, הגדרת ה-hnsw.ef_search השולטת על דיוק החיפוש) יכול להתבצע באמצעות פקודת SET LOCAL בתוך טרנזקציה קצרה. זה מבטיח שהשינוי יחול רק על השאילתה הנוכחית ולא ישפיע על Workers אחרים החולקים את המאגר.
מגבלות שנותרו
Hyperdrive אינו מעביר את מסד הנתונים עצמו. אם שרת ה-PostgreSQL נמצא באזור ענן מרוחק, השיהוי עדיין יהיה מוגבל על ידי המרחק הפיזי הזה. תכונת ה-"Smart Placement" של Cloudflare יכולה לסייע על ידי ניתוב Workers לצומת ה-edge הקרוב ביותר שבו קיים גם מופע Hyperdrive, אך היא אינה יכולה לבטל את סבב התקשורת (round-trip) הבסיסי ברשת.
שכבת המטמון, למרות שהיא שימושית לקריאות סטטיות, תחמיץ לעיתים קרובות נתונים וקטוריים המשתנים בכל בקשה. מפתחים צריכים לשקול את האיזון (trade-off) בין פגיעות במטמון (cache hits) לבין רעננות תוצאות החיפוש.
מתי לבחור בחלופה
אם אפליקציה זקוקה רק לאחסון וקטורי טהור ללא הצטרפויות (joins) רלציוניות, Cloudflare מציעה שירות ייעודי בשם Vectorize. Vectorize מאחסן וקטורים ישירות ב-edge ומסיר את הצורך ב-backend מסוג PostgreSQL. Hyperdrive נותר הבחירה הטובה יותר כאשר יש לחבר וקטורים עם טבלאות רלציוניות קיימות, כגון פרופילי משתמשים או היסטוריית עסקאות.
שורה תחתונה
Hyperdrive מעניק למפתחי edge כלי מעשי להרצת חיפושים וקטוריים מבוססי AI מבלי לחרוג ממגבלות החיבור של PostgreSQL. הוא מפחית את שיהוי ה-handshake, מרכז את פרטי ההזדהות ומציע שליטה מדויקת על המטמון ועל אורך הטרנזקציה. השירות אינו מוחק את המרחק הבסיסי בין ה-edge לבין מסד הנתונים, ופגיעות במטמון (cache-misses) נותרת נושא לשיקול דעת, אך עבור עומסי עבודה הזקוקים גם להצטרפויות רלציוניות וגם לדמיון וקטורי, Hyperdrive הוא הנתיב הישיר ביותר למערך (stack) edge סקילבילי ובעל שיהוי נמוך.