يوجد Cloudflare Hyperdrive بسبب مشكلة محددة وغير براقة: عامل Worker يعمل في 200 مدينة ويتحدث إلى قاعدة بيانات Postgres واحدة في مدينة واحدة يكون أبطأ من الاستعلام نفسه صادرًا من خادم يجلس بجوار تلك القاعدة مباشرة. ليس أبطأ قليلًا. غالبًا أبطأ بعدة أضعاف، ولأسباب لا علاقة لها بطريقة كتابة الاستعلام.
الغريزة الأولى عندما يبدو تطبيق بلا خادم ثقيلًا هي إلقاء اللوم على مخطط الاستعلامات أو إضافة فهرس جديد. في Workers التي تتحدث إلى قاعدة بيانات إقليمية، يكون الاستعلام سليمًا في الغالب. المشكلة هي الاتصال.
ما الذي يصلحه Hyperdrive فعليًا: تكلفة إنشاء اتصال بقاعدة البيانات، وهي تكلفة تُدفع مع كل طلب على حدة. يحتاج اتصال Postgres إلى مصافحة TCP وتفاوض TLS وتبادل مصادقة قبل أن يتحرك صف واحد، وكل خطوة من هذه الخطوات رحلة ذهاب وإياب من المكان الذي استيقظ فيه Worker إلى المكان الذي تعيش فيه قاعدة البيانات. يحتفظ Hyperdrive باتصالات دافئة قرب قاعدة بياناتك ويجمعها في مجمع واحد، فيستعير Worker اتصالًا مفتوحًا بدل أن يبني اتصالًا جديدًا من الصفر.
لماذا يكون Worker المتصل مباشرة بقاعدة Postgres بطيئًا
يفتح خادم التطبيقات التقليدي مجمع اتصالات مرة واحدة عند الإقلاع ثم يعيد استخدامه طوال عمر العملية. تُدفع تكلفة المصافحة عند بدء التشغيل ثم تتوزع على ملايين الطلبات إلى أن يعيد أحدهم تشغيل الخدمة.
Workers لا تعمل بهذه الطريقة. كل استدعاء قصير العمر وقد يعمل في أي موقع من مواقع Cloudflare. لا توجد عملية طويلة العمر تحتفظ بمجمع، لذا يدفع كل طلب تكلفة الإعداد كاملة من دون مساعدة، ويدفعها على المسافة الممتدة من الحافة إلى قاعدة بيانات الأصل لديك.
ثلاث رحلات ذهاب وإياب قبل أول بايت من البيانات ليست مشكلة ضبط. المستخدم في سيدني الذي يصل إلى Worker يتحدث إلى Postgres في لندن يدفع هذا الزمن أربع مرات: TCP ثم TLS ثم المصادقة ثم الاستعلام أخيرًا. أما الاستعلام نفسه فقد لا يستغرق أكثر من جزأين من الألف من الثانية.
وهناك عطل ثانٍ أهدأ صوتًا. يخصص Postgres عملية خلفية لكل اتصال، وحده الأقصى محدود، وهو بضع مئات في العادة. Worker الذي يتوسع إلى آلاف الاستدعاءات المتزامنة سيستنزف ذلك المجمع ويبدأ في جمع حالات رفض الاتصال في اللحظة نفسها التي تحدث فيها ذروة الحركة التي بنيت الحافة من أجلها.
ما الذي يفعله Hyperdrive حيال ذلك
يجلس Hyperdrive بين Worker وقاعدة البيانات بوصفه مجمّع اتصالات تشغّله Cloudflare نيابة عنك. يحافظ على اتصالات دافئة مع الأصل لديك، فيستعير الاستدعاء واحدًا منها بدلًا من التفاوض على اتصال جديد من الصفر.
كما يخزّن نتائج الاستعلامات مؤقتًا. الاستعلامات القرائية المتكررة يمكن تقديمها من دون لمس الأصل إطلاقًا، وهو ما يحول مسألة زمن الاستجابة إلى مسألة إصابة ذاكرة تخزين مؤقت في حصة معتبرة من الحركة. أما عمليات الكتابة وكل ما ليس حتميًا فتمر مباشرة.
الإعداد كله سلسلة اتصال واحدة. تسجل قاعدة البيانات لدى Cloudflare، وتحصل على ربط Hyperdrive، ثم توجه مشغل Postgres الحالي إلى ذلك الربط بدل قاعدة البيانات. لا يتغير المشغل ولا SQL ولا المخطط. هذا أهم مما يبدو، لأنه يعني أن التغيير قابل للتراجع وأنك تستطيع قياسه مقابل اتصال مباشر من دون إعادة كتابة أي شيء.
الأرقام التي تحدد ما إذا كان مناسبًا لك
جرى التحقق منها مقابل وثائق Cloudflare في أغسطس 2026، ويستحق الأمر مراجعة جديدة قبل الالتزام، لأن هذه القيم تتحرك.
| Workers Free | Workers Paid | |
|---|---|---|
| التكلفة | مشمولة | مشمولة |
| الاستعلامات | 100,000 يوميًا | بلا حد |
| قواعد البيانات المهيأة | 10 لكل حساب | 25 لكل حساب |
| اتصالات الأصل لكل تهيئة | نحو 20 | نحو 100 |
| الحد الأقصى لمدة الاستعلام | 60 ثانية | 60 ثانية |
| حجم الاستجابة المخزنة مؤقتًا | 50 ميجابايت | 50 ميجابايت |
لا يفرض Hyperdrive أي رسوم إضافية على أي من الخطتين ، ولا توجد رسوم خروج للبيانات. وتعريف ما يُحتسب استعلامًا واسع: عملية select أو insert أو update أو delete أو تغيير في المخطط، كلها تُحتسب، والاستعلامات المخدومة من الذاكرة المؤقتة تُحتسب مثل غيرها تمامًا. تتم إعادة ضبط الحصة اليومية المجانية عند منتصف الليل بتوقيت UTC.
تذكر وثائق الحدود مهلة اتصال أولية قدرها 15 ثانية ومهلة خمول قدرها 10 دقائق. وسقف الستين ثانية للاستعلام الواحد هو ما يوقع الفرق التي تنقل أحمال التقارير: الاستعلام التحليلي الذي يستغرق دقيقتين في مهمة مجدولة سيفشل هنا ببساطة.
ما قواعد البيانات التي تعمل فعلًا
يدعم Hyperdrive إصدارات PostgreSQL من 9.0 إلى 17.x وإصدارات MySQL من 5.7 إلى 8.x ، سواء استضفتها بنفسك أو كانت مُدارة. وتدخل MariaDB ضمن توافق MySQL.
من مزودي الخدمات المُدارة المذكورين بالاسم AWS Aurora بصيغتيها المتوافقة مع Postgres والمتوافقة مع MySQL، إضافة إلى Neon وSupabase وTimescale وMaterialize وCockroachDB وPlanetScale. كما تعمل النسخ المُدارة على Azure وGoogle Cloud.
القيد العملي ليس المحرك بل إمكانية الوصول. يجب أن تكون قاعدة بياناتك قابلة للعنونة من شبكة Cloudflare. أي نسخة Postgres مغلقة داخل شبكة VPC خاصة بلا نقطة نهاية عامة تحتاج إلى نفق أو ترتيب اقتران قبل أن يتمكن Hyperdrive من رؤيتها أصلًا، وهذا مشروع شبكي لا مجرد تعديل في الإعدادات.
متى يكون Cloudflare Hyperdrive الإجابة الخاطئة
عندما تنتمي البيانات إلى الحافة. إذا كان نمط الوصول لديك عمليات بحث بمفتاح وقيمة، فإن Workers KV أسرع وأبسط. وإذا أردت قاعدة بيانات علائقية صغيرة تعيش قرب Worker بدل أن تعيش في إقليم واحد، فإن D1 هو المنتج المصمم لذلك. أما Hyperdrive فهو لحالة أن يكون لديك بالفعل Postgres أو MySQL وتنوي الاحتفاظ به.
عندما يكون الحمل تحليليًا. سقف الستين ثانية والمحاسبة على أساس كل استعلام يناسبان الحركة المعاملاتية. أما عمليات التجميع الطويلة فمكانها منفذ مهام يتحدث إلى قاعدة البيانات مباشرة.
عندما لا تكون قد قِست. الإخفاق الأكثر شيوعًا الذي نراه هو فريق يضيف Hyperdrive إلى تطبيق لم يكن مقيدًا بالاتصالات أصلًا. إذا كان Worker بطيئًا لأنه يطلق ستة استعلامات متتابعة حيث يكفي استعلام واحد، فإن تجميع تلك الاتصالات الستة يجعله أقل بطئًا بهامش ضئيل ويترك المشكلة الحقيقية كما هي.
هذا القياس يستحق أن يُجرى كما ينبغي قبل أي خطوة أخرى. تشرح مقارنتنا بين Cloudflare Workers وAWS Lambda أين ينتصر التنفيذ على الحافة فعلًا، ويغطي مقال Cloudflare D1 الحالة التي يكون فيها نقل قاعدة البيانات أفضل من تسريع الطريق إليها.
كيف تتخذ القرار الصحيح
قِس زمن طلب واحد من طرف إلى طرف عبر اتصال مباشر، ثم أعد القياس عبر Hyperdrive، من موقع بعيد عن قاعدة بياناتك. إذا كان الفارق صغيرًا فإن زمن الاستجابة لديك يسكن في مكان آخر، وتكون قد وفرت على نفسك اعتمادية إضافية. وإذا كان الفارق كبيرًا فقد عثرت على مال حقيقي.
تبني Mecanik معماريات الحافة وتراجعها عبر فريق تطوير البرمجيات لدينا، بما في ذلك الجزء غير البراق الذي يقيس فيه أحدهم ما هو بطيء فعلًا قبل إعادة هندسة أي شيء. إذا كان تطبيقك بلا خادم أبطأ من الخادم الذي حل محله، فإن مسار الاتصال هو أول مكان ينبغي النظر فيه.
قراءات ذات صلة: بناء واجهة Cloudflare Workers API: دليل serverless 2026 وCloudflare Queues: مهام خلفية على الحافة وتقليل زمن استجابة نماذج LLM: التخزين المؤقت واستراتيجيات الحافة وكيفية بناء تطبيق ويب في 2026 .
الأسئلة الشائعة
ما المشكلة التي يحلها Cloudflare Hyperdrive؟ تكلفة فتح اتصال بقاعدة البيانات مع كل طلب. Worker قصير العمر ولا يحتفظ بمجمع اتصالات، لذا يدفع كل استدعاء من دون Hyperdrive مصافحة TCP وتفاوض TLS وتبادل مصادقة على المسافة الممتدة من الحافة إلى قاعدة بياناتك قبل أن تتحرك أي بيانات. يحتفظ Hyperdrive باتصالات دافئة مجمّعة قرب الأصل ليستعير Worker واحدًا منها بدلًا من ذلك.
كم تبلغ تكلفة Cloudflare Hyperdrive؟ لا شيء يتجاوز خطة Workers لديك. فهو مشمول في الخطة المجانية والخطة المدفوعة معًا بلا رسوم منفصلة وبلا رسوم خروج للبيانات. تسمح الخطة المجانية بـ 100,000 استعلام لقاعدة البيانات يوميًا مع إعادة الضبط عند منتصف الليل بتوقيت UTC، والخطة المدفوعة بلا حد. عمليات select وinsert وupdate وdelete وتغييرات المخطط تُحتسب كلها استعلامات، والاستعلامات المخدومة من الذاكرة المؤقتة تُحتسب مثل غيرها.
ما قواعد البيانات التي يدعمها Hyperdrive؟ إصدارات PostgreSQL من 9.0 إلى 17.x وإصدارات MySQL من 5.7 إلى 8.x، مستضافة ذاتيًا أو مُدارة، مع دخول MariaDB ضمن توافق MySQL. من المزودين المذكورين AWS Aurora وNeon وSupabase وTimescale وMaterialize وCockroachDB وPlanetScale، إضافة إلى النسخ المُدارة على Azure وGoogle Cloud. ويجب أن تكون قاعدة البيانات قابلة للوصول من شبكة Cloudflare.
ما أبرز حدود Hyperdrive؟ عشر قواعد بيانات مهيأة لكل حساب في الخطة المجانية و25 في الخطة المدفوعة، ونحو 20 اتصال أصل لكل تهيئة في المجانية و100 في المدفوعة، وحد أقصى لمدة الاستعلام قدره 60 ثانية، وحجم استجابة مخزنة مؤقتًا قدره 50 ميجابايت، ومهلة اتصال أولية قدرها 15 ثانية، ومهلة خمول قدرها 10 دقائق. وسقف الستين ثانية للاستعلام هو ما يعطل الأحمال التحليلية.
هل أستخدم Hyperdrive أم D1؟ Hyperdrive عندما تكون لديك بالفعل قاعدة Postgres أو MySQL تنوي الاحتفاظ بها وتكون المشكلة زمن الوصول إليها. وD1 عندما تريد قاعدة بيانات علائقية تعيش على شبكة Cloudflare منذ البداية. الاثنان يحلان مشكلتين مختلفتين: أحدهما يسرّع الطريق إلى قاعدة بيانات قائمة، والآخر يلغي المسافة بنقل البيانات نفسها.
التعليقات