شرح البداية الباردة Postgres بدون خادم

تحدث البداية الباردة عندما يتم وضع الحوسبة التي تقوم بتشغيل قاعدة البيانات الخاصة بك في وضع السكون بسبب عدم النشاط، ويجب أن يقوم الاستعلام الجديد بإعادة تشغيلها أولاً قبل التشغيل. هذا ليس زمن الوصول المعتاد للشبكة لاتصال TCP/TLS النموذجي: هذا هو الوقت المناسب لتشغيل عملية Postgres جديدة واستعادة حالتها، حتى قبل بدء تنفيذ الطلب الأول.

يأتي المصطلح من الحوسبة بدون خادم على نطاق واسع، حيث يجب إعادة تشغيل بيئة التنفيذ الصفرية قبل معالجة الطلب، سواء كانت وظيفة خادم أو وقت تشغيل WebAssembly على الحافة. قمنا بتفصيل هذه الآلية على جانب وظائف الحافة في مقالتنا حول البدء البارد WebAssembly الذي يواجه حاويات. بالنسبة لقاعدة البيانات، تختلف الآليات: فهي ليست ملفًا ثنائيًا مُجمَّعًا هو الذي يبدأ، بل خادم Postgres كامل والذي يجب أن يعيد فتح ملفاته، والتحقق من حالته، ثم قبول الاتصالات الجديدة.

1. تسجيل دخول العميل

يصل طلب إلى المشروع الذي تم تعليق حسابه.

2. كشف النوم

تلاحظ المنصة أن الحساب لم يعد نشطًا.

3. إعادة تشغيل الحساب

يتم إعادة تشغيل عملية Postgres، ويتم استعادة الحالة الضرورية.

4. تمت معالجة الطلب

تم الاتصال بنجاح، ويتم تنفيذ الطلب بشكل طبيعي.

رسم توضيحي لآلية البداية الباردة، تسلسل مبسط، بدون قيمة زمنية مقاسة.

يفصل Neon بنية قاعدة البيانات الخاصة به إلى طبقتين متميزتين: التخزين المستمر الذي يحتفظ بالبيانات، وحساب عملية Postgres نفسها، والتي يمكن إيقافها وإعادة تشغيلها بشكل مستقل. يسمح هذا الفصل لـ Neon بتعليق حساب مشروع غير نشط دون لمس البيانات، ثم إعادة تشغيله عند الطلب، وفقًا لوثائقه الرسمية.

في الخطة المجانية، يقوم Neon بتوثيق مهلة عدم النشاط الافتراضية لمدة 5 دقائق قبل وضع الحساب في وضع السكون. تسمح لك الخطط المدفوعة بتكوين هذا الحد، أو حتى زيادته بشكل كبير للاستخدام مع حركة المرور الثابتة. يتغير هذا النوع من التغييرات الافتراضية مع تحديثات المنتج: تحقق من تحديث وثائق النيون في وقت القراءة بدلاً من هذا الشكل المعزول.

يخدم هذا التصميم غرضًا محددًا، وهو بيئات سريعة الزوال. قاعدة بيانات لكل فرع من فروع Git، وبيئة معاينة عن طريق طلب السحب، وقاعدة بيانات اختبارية تُستخدم لبضع دقائق فقط في اليوم: يعد تشغيل الحوسبة بشكل مستمر لهذه الاستخدامات أمرًا مكلفًا دون أي فائدة حقيقية. يؤدي تعليق الحساب بين استخدامين إلى تقليل الفاتورة دون حذف البيانات، وهذه هي الحجة المركزية لنموذج نيون بدون خادم.

يشير نيون في وثائقه إلى إعادة تشغيل الحساب عادةً في حدود بضع مئات من المللي ثانية إلى بضع ثوانٍ، اعتمادًا على حجم المشروع وحجم سجلات المعاملات التي سيتم إعادة تشغيلها قبل أن يصبح الحساب جاهزًا. هذا رقم نشره الناشر نفسه، وليس تدقيقًا مستقلاً: تعامل معه كأمر موثق من حيث الحجم، وليس كضمان تعاقدي.

بالنسبة للقياس في العالم الحقيقي، قامت أداة المجتمع العامة، neon-latency-benchmarks.vercel.app، بتعليق مشاريع النيون على فترات منتظمة وتعرض زمن انتقال الاستيقاظ المرصود. هذا هو نوع المنهجية الذي يهم أكثر من مجرد رقم توثيقي: تظل شروط الاختبار مرئية، وليست مخفية خلف متوسط ​​التسويق. نحن نطبق نفس المبدأ في منهجية قياس الواجهة الخلفية الخاصة بنا: نشر البروتوكول قبل نشر الشكل.

قامت Vercel ببناء عرض قاعدة بيانات Postgres الخاص بها استنادًا إلى بنية Neon الأساسية، وهي شراكة تم الإعلان عنها في عام 2024. وفي وقت كتابة هذا التقرير، يتم تقديم تكامل Postgres هذا في Vercel Marketplace كخيار تخزين إلى جانب مقدمي الخدمات الآخرين. تحقق من صفحة منتج Vercel المحدثة: يتطور هذا النوع من الشراكة بسرعة في سوق يتغير كل ثلاثة أشهر.

بشكل ملموس، يتبع سلوك النوم والاستيقاظ لقاعدة بيانات Postgres المقدمة عبر Vercel نفس الآليات الموضحة أعلاه لـ Neon مباشرة. إنه ليس محركًا منفصلاً بنموذج التشغيل البارد الخاص به، بل هو نفس البنية التحتية التي تم الكشف عنها خلف تكامل Vercel.

لا، ليس بنفس الطريقة. توفر Supabase مثيل Postgres مخصصًا لكل مشروع بدلاً من حساب بدون خادم معلق لكل اتصال. وبالتالي، لا تتم إضافة أي تأخير للاستيقاظ إلى كل جلسة جديدة بعد بضع دقائق من عدم النشاط، على عكس نموذج النيون.

ومع ذلك، توجد آلية مختلفة في الخطة المجانية: تقوم Supabase بتوثيق الإيقاف المؤقت التلقائي للمشاريع غير النشطة بعد فترة ممتدة، لمدة أسبوع وفقًا لتوثيقها، مع استعادة يدوية من لوحة المعلومات بدلاً من التنبيه التلقائي عند الطلب الأول. إنها عتبة تقاس بالأيام، وليس بالدقائق، وهي إجراء واضح وليس انتعاشًا شفافًا: هناك اختلافان هيكليان مع بداية النيون الباردة، وليس اختلافًا بسيطًا في نفس الآلية. للحصول على مقارنة كاملة للهندسة المعمارية، توثق المقارنة التفصيلية Aurabase و Supabase التناقضات الأخرى.

لا تقدم Aurabase نموذجًا بدون خادم مثل Neon. تم التحقق منه في كود الموفر (aura-provisioner، مفتوح المصدر على github.com/daylami555/aurabase): يتلقى كل مشروع إما مجموعة Postgres مخصصة تتم إدارتها بواسطة CloudNativePG، أو مشغل Kubernetes CNPG، أو قاعدة مخصصة على مجموعة CNPG مشتركة بين عدة مشاريع لنفس المؤسسة، اعتمادًا على الخطة المختارة. في كلتا الحالتين، ليست حوسبة واحدة هي التي يتم تعليقها وتنشيطها عند كل اتصال: إنها مجموعة Postgres كاملة، مع النسخ المتماثلة الأساسية والمحتملة.

توجد آلية السبات على جانب Aurabase، ولكنها تخدم غرضًا مختلفًا. في حالة عدم النشاط لفترة طويلة، 7 أيام افتراضيًا وقابلة للتكوين عبر متغير بيئة، ويتم التحقق من الحد في التعليمات البرمجية، يقوم المزود بوضع المثيلات غير النشطة في وضع السكون لتحرير الموارد، وليس لتحسين زمن الوصول للاستخدام المتقطع. يؤدي تنشيط مجموعة CNPG النائمة إلى إعادة إنشاء حجراتها من وحدات التخزين المستمرة، وهي آلية أثقل من الناحية الهيكلية من إعادة تشغيل عملية بسيطة بدون خادم.

تتمتع هذه البنية المخصصة بنظير مباشر من حيث العزلة وإمكانية التنبؤ بالأداء: لا يشارك المشروع حوسبةه مع مشروع آخر، على عكس المجموعة المشتركة ذات الحجم السيئ. نحن نفصل هذا التحكيم في مقال مخصص: قاعدة مخصصة مقابل قاعدة مشتركة، تأثير حقيقي على الأداء والعزلة.

يخدم نموذج Neon بدون خادم حالة استخدام محددة: العديد من البيئات سريعة الزوال أو البيئات ذات حركة المرور المتقطعة للغاية، حيث لا يكون الدفع مقابل حساب يعمل بشكل مستمر أمرًا منطقيًا من الناحية الاقتصادية. قاعدة بيانات لكل فرع من فروع Git، وبيئة معاينة عن طريق طلب السحب، ونموذج أولي يتم اختباره عدة مرات في الأسبوع: تصبح البداية الباردة العرضية بمثابة حل وسط مقبول مقابل فاتورة تتناسب مع الاستخدام الفعلي.

على العكس من ذلك، تصبح بنية Postgres المخصصة والمفعلة دائمًا مفضلة عندما يحتاج زمن استجابة الاتصال الأول إلى أن يظل قابلاً للتنبؤ به: واجهة برمجة تطبيقات إنتاج مع حركة مرور منتظمة، أو واجهة خلفية لا يمكنها تحمل ارتفاع زمن الوصول العرضي بناءً على طلب المستخدم، أو نظام حيث يكون p99 أكثر أهمية من تكلفة فرع اختبار معزول.

منبه النيون: تم توثيقه من قبل الناشر، ولم يتم تدقيقه بشكل مستقل. عتبة إسبات Aurabase: تم تحديدها في aura-provisioner، المتغير HIBERNATE_INACTIVITY_DAYS، الافتراضي 7 أيام.

إن البداية الباردة بدون خادم لـ Postgres ليست مفهومًا عالميًا: إنها نتيجة مباشرة لبنية النيون، التي تفصل بين التخزين والحساب لتعليق الأخير بين استخدامين. ترثها Vercel Postgres مباشرة من خلال شراكتها مع Neon. Supabase وAurabase، اللذان يوفران مثيلات Postgres مخصصة، يكشفان عن آلية مختلفة، يتم قياسها بالأيام بدلاً من الدقائق، وليست مصممة لنفس الغرض.

قبل اختيار موفر خدمة وفقًا لهذا المعيار وحده، تحقق من ثلاثة أشياء: حد عدم النشاط الفعلي الموثق من قبل الموفر، وما إذا كان قابلاً للتكوين في خطتك، وما إذا كانت حركة مرور التطبيق لديك تبرر الحوسبة المعلقة. للاستخدام مع حركة المرور المتقطعة الحقيقية أو فروع الاختبار أو المعاينات، فإن النموذج بدون خادم له فائدة اقتصادية واضحة. بالنسبة للإنتاج مع حركة مرور منتظمة، فإن البنية المخصصة ببساطة تزيل هذا السؤال.