Hyperdrive یک سرویس مدیریتشدهی اتصالدهی (connection-pooling) است که به Workers اجازه میدهد مستقیماً با پایگاههای داده PostgreSQL ارتباط برقرار کنند – از جمله پایگاههایی که از افزونه pgvector برای جستجوی برداری (vector search) استفاده میکنند. Hyperdrive با نگه داشتن مجموعهای از اتصالات قابل استفاده مجدد در نزدیکی سرور، هزینهی اضافی فرآیند دستدادن (handshake) را که مدتهاست مانعی برای بارهای کاری هوش مصنوعی در لبه (edge AI workloads) بوده است، کاهش میدهد.
چرا Workers و PostgreSQL با هم تداخل دارند
Cloudflare Workers به عنوان توابع جاوااسکریپت با طول عمر کوتاه در دهها مکان لبه (edge locations) اجرا میشوند. هر درخواست ورودی یک فرآیند تازه را شروع میکند و الگوی معمول، باز کردن یک اتصال TCP جدید به پایگاه داده بکاند است. با این حال، PostgreSQL انتظار یک اتصال پایدار برای هر فرآیند کلاینت را دارد و تعداد کل اتصالات همزمان را محدود میکند. نتیجه، دو مشکل است:
- هزینه بالای اتصال – برقراری یک اتصال نیازمند چندین رفت و برگشت (round trips) برای احراز هویت و مذاکره پروتکل است. این رفت و برگشتها به هر درخواست تأخیر (latency) اضافه میکنند.
- محدودیتهای اتصال – Workers میتوانند تا هزاران اجرای همزمان مقیاسپذیر شوند، که این امر به سرعت مخزن اتصال (connection pool) PostgreSQL را تخلیه کرده و پتانسیل از کار انداختن پایگاه داده را دارد.
چگونه Hyperdrive این شکاف را پر میکند
Hyperdrive بین یک Worker و پایگاه داده قرار میگیرد و مجموعهای از اتصالات پایدار را روی سروری که از نظر شبکه به نمونهی PostgreSQL نزدیک است، حفظ میکند. از دیدگاه Worker، تنها تغییر، یک رشتهی اتصال (connection string) جدید است. در داخل، این پروکسی برای هر کوئری ورودی از یک اتصال موجود دوباره استفاده میکند و هزینهی handshake را از بین میبرد.
راهاندازی بهطور عمدی سبک طراحی شده است:
- ابزار Wrangler CLI (ابزار خط فرمان Cloudflare) را برای ایجاد یک نمونهی Hyperdrive اجرا کنید و URL اصلی پایگاه داده را ارائه دهید.
- اتصال (binding) تولید شدهی Hyperdrive را به فایل پیکربندی
wrangler.tomlاضافه کنید. - از یک درایور سازگار مانند
node-postgresدر کد Worker استفاده کنید؛ درایور، نقطه پایانی (endpoint) Hyperdrive را به عنوان یک سرور معمولی PostgreSQL میبیند.
از آنجایی که رمز عبور پایگاه داده فقط در پیکربندی Hyperdrive قرار دارد، هرگز در کد منبع Worker ظاهر نمیشود و این امر سطح حمله (attack surface) را کاهش میدهد.
نکات کاربردی برای جستجوی برداری
بارهای کاری جستجوی برداری که از pgvector استفاده میکنند، شامل آرایههای بزرگ اعداد ممیز شناور هستند که تمایل دارند در هر کوئری تغییر کنند. رفتار پیشفرض Hyperdrive شامل یک حافظه پنهان خواندنی (read cache) است که میتواند با دادههایی که مدام در حال تغییر هستند، تداخل داشته باشد. برای تازه نگه داشتن نتایج، یک پیکربندی دوم از Hyperdrive را با غیرفعال کردن قابلیت کشینگ (caching) راهاندازی کنید.
تراکنشهای طولانیمدت یکی دیگر از دامها هستند. نگه داشتن یک اتصال پایگاه داده در حین انتظار برای پاسخ یک مدل هوش مصنوعی خارجی، یک جایگاه (slot) از مخزن را اشغال کرده و هدف از pooling را از بین میبرد. الگوی توصیه شده این است:
- یک تراکنش باز کنید.
- کوئری را اجرا کنید.
- بلافاصله commit کنید.
- مدل هوش مصنوعی را خارج از تراکنش فراخوانی کنید.
تنظیم دقیق پارامترهای pgvector (به عنوان مثال، تنظیم hnsw.ef_search که دقت جستجو را کنترل میکند) میتواند با یک دستور SET LOCAL در داخل یک تراکنش کوتاه انجام شود. این کار تضمین میکند که تغییر فقط برای کوئری فعلی اعمال شود و بر سایر Workerهایی که از این مخزن استفاده میکنند تأثیر نگذارد.
محدودیتهای باقیمانده
Hyperdrive خودِ پایگاه داده را جابهجا نمیکند. اگر سرور PostgreSQL در یک ناحیه ابری دوردست قرار داشته باشد، تأخیر همچنان توسط آن فاصله فیزیکی محدود خواهد شد. ویژگی “Smart Placement” کلودفلر میتواند با هدایت Workers به نزدیکترین گره لبه (edge node) که دارای یک نمونهی Hyperdrive نیز هست، کمک کند، اما نمیتواند رفت و برگشتهای شبکهای زیرساختی را حذف کند.
لایهی کشینگ، اگرچه برای خواندنهای استاتیک مفید است، اما در مورد دادههای برداری که در هر درخواست تغییر میکنند، اغلب با خطا (miss) مواجه میشود. توسعهدهندگان باید بین نرخ برخورد با کش (cache hits) و تازگی نتایج جستجو، تعادل برقرار کنند.
چه زمانی یک جایگزین را انتخاب کنیم
اگر یک اپلیکیشن فقط به ذخیرهسازی برداری خالص بدون joinهای رابطهای نیاز دارد، Cloudflare سرویس اختصاصی به نام Vectorize را ارائه میدهد. Vectorize بردارها را مستقیماً در لبه ذخیره میکند و نیاز به یک بکاند PostgreSQL را از بین میبرد. زمانی که بردارها باید با جداول رابطهای موجود، مانند پروفایلهای کاربری یا تاریخچهی تراکنشها، join شوند، Hyperdrive همچنان انتخاب بهتری است.
جمعبندی
Hyperdrive به توسعهدهندگان لبه ابزاری کاربردی برای اجرای جستجوهای برداری مبتنی بر هوش مصنوعی، بدون از کار انداختن محدودیتهای اتصال PostgreSQL، میدهد. این سرویس تأخیر handshake را کاهش میدهد، اعتبارنامهها را متمرکز میکند و کنترل دقیقی بر کشینگ و طول تراکنش ارائه میدهد. این سرویس فاصله بنیادی بین لبه و پایگاه داده را از بین نمیبرد و خطاهای کش (cache-misses) همچنان یک دغدغه هستند، اما برای بارهای کاری که هم به joinهای رابطهای و هم به شباهت برداری نیاز دارند، Hyperdrive مستقیمترین مسیر به سمت یک استک لبهی مقیاسپذیر و کمتأخیر است.