قواعد البيانات تنتقل إلى الحافة — Turso وNeon وCloudflare D1 يعيدون كتابة مكان تخزين بياناتك

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

المشكلة في هذا النموذج هي أنه لا يأخذ في الاعتبار مكان وجود مستخدميك. إذا كانت خوادم تطبيقك في us-east-1 وأرسل مستخدم في سنغافورة طلبًا، فإن هذا الطلب ينتقل من سنغافورة إلى فرجينيا ويعود — حوالي 200 ميلي ثانية من زمن الوصول ذهابًا وإيابًا قبل حتى التفكير في استعلامات قاعدة البيانات. منصات Serverless الحديثة وبيئات Edge Runtimes دفعت كود التطبيق أقرب إلى المستخدمين: Cloudflare Workers يعمل في أكثر من 300 موقع، Vercel Edge Functions تنتشر في عشرات المناطق. لكن معظم التطبيقات لا تزال تستعلم عن مثيل Postgres أو MySQL واحد يجلس في منطقة واحدة، مما يلغي ميزة زمن الوصول لتنفيذ Edge بمجرد إجراء استدعاء قاعدة بيانات.

تحاول قواعد البيانات الحافة (Edge) حل هذه المشكلة عن طريق نقل البيانات نفسها — أو على الأقل البيانات التي يتم الوصول إليها بشكل متكرر — بالقرب من المستخدمين.

المنافسون الرئيسيون

Turso مبني على libSQL، وهو Fork من SQLite مع إضافة التكرار (Replication). الهندسة واضحة: قاعدة بيانات رئيسية تخزن النسخة الموثوقة من بياناتك، ويقوم Turso تلقائيًا بتكرارها إلى مواقع الحافة القريبة من مستخدميك. استعلامات القراءة تضرب أقرب نسخة مكررة (Replica)؛ عمليات الكتابة تذهب إلى الرئيسية. نشر Turso نسخًا مكررة حافة في عشرات المناطق ويجعل كل شيء يبدو كاتصال SQLite قياسي من منظور المطور. نموذج التسعير عدواني — طبقة مجانية سخية، ثم تسعير لكل قاعدة بيانات. للتطبيقات التي تحتوي على مستأجرين معزولين كثيرين (منتجات SaaS حيث يحصل كل عميل على قاعدة بياناته الخاصة)، نموذج Turso مقنع: يمكنك الحصول على آلاف قواعد البيانات مقابل القليل جدًا من المال، كل منها موضوع بالقرب من مستخدمه الأساسي.

Neon يتخذ نهجًا مختلفًا: هو Postgres بدون خادم، مع فصل التخزين والحوسبة. تنخفض الحوسبة إلى الصفر عند عدم الاستخدام (القضاء على تكاليف الخمول) وتصعد في غضون ثوانٍ عند وصول حركة المرور. طبقة التخزين متينة ومتعددة المستأجرين ومكررة عالميًا على مستوى الكتلة. يمكن نشر نسخ مكررة للقراءة في أي منطقة. تجربة المطور قريبة جدًا من Postgres القياسي — سلاسل الاتصال، psql، جميع الأدوات المعتادة تعمل — مما يقلل احتكاك الترحيل بشكل كبير. ميزة التفرع (Branching) في Neon، التي تنشئ لقطات فورية للنسخ عند الكتابة من قاعدة بياناتك للتطوير أو الاختبار، حظيت بإشادة واسعة.

Cloudflare D1 أيضًا مبني على SQLite ومتكامل بعمق مع Cloudflare Workers. الفكرة بسيطة: كود Worker الخاص بك يعمل على الحافة، وD1 موجودة معه تمامًا. للاستعلامات التي لا تتطلب اتساقًا عالميًا، تلغي D1 الرحلة ذهابًا وإيابًا إلى قاعدة بيانات مركزية تمامًا. D1 حاليًا محدودة في الميزات مقارنة بـ Postgres كامل — لا دعم للمفاتيح الخارجية خارج الصندوق، محدودة بنظام أنواع SQLite — لكنها سريعة حقيقيًا للقراءة عند مشاركة الموقع مع Worker الحافة الذي يعالج الطلب.

PlanetScale تستحق الذكر لسبب مختلف: أعلنت في 2024 أنها تنهي طبقتها المجانية وتعيد التركيز على العملاء المؤسسيين. العديد من المطورين الذين بنوا مشاريع على خدمة PlanetScale المتوافقة مع MySQL سارعوا إلى الترحيل، وانتهى الأمر بالعديد منهم في Neon أو Turso. كانت بنية PlanetScale القائمة على Vitess تقدم قابلية توسع أفقي بسعر تبين أنه غير مستدام. كانت الحلقة تذكيرًا مفيدًا بأن خدمات قواعد البيانات المجانية ليست أساسًا مضمونًا.

مشكلة الاتساق

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

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

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

نموذج الاتساق لـ Cloudflare D1 محدد بنطاق منطقة واحدة: الكتابات إلى D1 تكون مرئية فورًا للقراءات في نفس المنطقة، لكن الاتساق العالمي غير مضمون. توفر Durable Objects من Cloudflare primitive مختلفة لحالة متسقة عالميًا، لكن Durable Objects ليست قاعدة بيانات علائقية.

التقارب نحو SQLite

نمط لافت في مشهد قواعد البيانات الحافة هو كم من هذه المنتجات تتقارب على SQLite كمحرك تخزين أساسي. libSQL من Turso، وCloudflare D1، وقاعدة البيانات المدمجة في Bun، والعديد غيرها كلها تستخدم SQLite أو مشتقًا. الأسباب عملية: SQLite سريعة جدًا لأحمال العمل أحادية الكاتب، وهي مدمجة في عملية التطبيق (لا خادم منفصل)، ومختبرة بشكل استثنائي. التحدي دائمًا كان التكرار، الذي لا تدعمه SQLite القياسية — libSQL وLiteFS ومشاريع مماثلة تعمل لسد هذه الفجوة.

ظهور SQLite كمحرك قاعدة بيانات إنتاجي جاد — يتجاوز دورها التقليدي كمخزن محلي مدمج — هو أحد أكثر اتجاهات البنية التحتية إثارة للاهتمام في السنوات القليلة الماضية. تعمل على كل شيء من أجهزة IoT إلى وظائف Serverless Edge، وبساطتها أصبحت بشكل متزايد ميزة بدلاً من قيد.

متى تستخدمها

قواعد البيانات الحافة مناسبة للتطبيقات حيث المستخدمون موزعون عالميًا، وأحمال العمل كثيفة القراءة هي القاعدة، والاتساق النهائي مقبول لمعظم الاستعلامات. منتجات SaaS مع قواعد بيانات لكل مستأجر، ومنصات المحتوى مع جماهير عالمية، وواجهات Backend API التي تخدم تطبيقات الهاتف المحمول في العديد من المناطق الجغرافية كلها مرشحة معقولة.

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

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