Michael Johnsonمنذ 4 نوفمبر 2026، يفشل استعلام Cloudflare D1 إذا تجاوز حجم نتيجته 50 ميغابايت. ومن المهم للمطورين فهم نطاق هذا التغيير: فالحد يتعلق بحجم نتيجة استعلام منفرد، لا بالحد الأقصى لحجم قاعدة البيانات. ولا يشمل هذا الحد استيراد البيانات وتصديرها عبر REST API، لذا فإن طريقة قراءة البيانات هي ما يحدد الحاجة إلى تغيير سير العمل.
ما الذي يخضع للحد تحديداً؟
وصفت Cloudflare هذا التغيير في تدوينة بتاريخ 30 أكتوبر: إذ يعيد أي استعلام تتجاوز نتيجته 50 ميغابايت الخطأ D1 query result exceeded the maximum response size limit of 50 MB. ويبدأ تطبيق الحد في 4 نوفمبر 2026. وتذكر وثائق D1 أيضاً أن الحد يتعلق بحجم نتيجة الاستعلام؛ بينما يمكن أن تصل سعة قاعدة البيانات إلى 10 غيغابايت في الخطة المدفوعة أو 500 ميغابايت في الخطة المجانية.
هذان مستويان مختلفان: فالتخزين يحدد حجم البيانات الموجودة في قاعدة البيانات، أما حد النتيجة فيحدد مقدار البيانات التي يمكن لاستعلام واحد إرجاعها. لذلك يمكن أن تحتوي قاعدة البيانات على بيانات يتجاوز حجمها 50 ميغابايت بكثير، مع بقائها قابلة للقراءة على دفعات. وفي المقابل، قد يتجاوز استعلام موجّه إلى قاعدة بيانات صغيرة الحد إذا اختار عدداً كبيراً من الصفوف العريضة أو حقولاً نصية أو ثنائية كبيرة.
في إعلان Cloudflare عن الحد، تشير الشركة إلى أن العتبة تغطي المئين 99.999 من استعلامات D1. وهذا تقدير لتوزيع الاستعلامات أورده مزود الخدمة؛ أما التحقق على مستوى التطبيق، فالأهم فيه قياس الاستجابات الفعلية للتطبيق وتحديد الاستعلامات التي تعيد كميات كبيرة من البيانات.
لماذا يُعد التصدير عبر REST API حالة منفصلة؟
يحصل التطبيق عادةً على نتيجة تنفيذ SQL ثم يمررها إلى الشيفرة المستدعية. أما استيراد قاعدة البيانات وتصديرها عبر REST API فهما عمليتان مختلفتان: وتوضح Cloudflare على نحو منفصل أنهما غير خاضعتين للحد الجديد، وتستمران كما كانتا. لذا، فإن فشل استعلام يعيد مجموعة كبيرة لا يعني تعذر تصدير كمية كبيرة من البيانات من قاعدة البيانات.
عملياً، يساعد هذا التمييز على اختيار المسار المناسب. فإذا كان التطبيق يحتاج إلى جميع السجلات لعرضها أو معالجتها أو إعداد تقرير، فقسّم القراءة إلى دفعات. أما إذا كان الهدف نقل البيانات أو تصديرها، فتحقق من استخدام مسار التصدير عبر REST API بدلاً من محاولة الحصول على قاعدة البيانات كلها في استجابة SQL واحدة.
كيف تقلّص الاستجابة من دون فقدان البيانات المطلوبة؟
الخطوة الأولى هي استبعاد الأعمدة غير الضرورية. فبدلاً من SELECT *، حدّد الحقول التي تحتاج إليها العملية الحالية فقط. وهذا يقلص حجم الاستجابة، ولا سيما إذا كان الجدول يتضمن أوصافاً طويلة أو بيانات JSON أو قيم BLOB.
الخطوة الثانية هي قراءة الصفوف على دفعات باستخدام LIMIT وOFFSET، كما توصي Cloudflare. فمثلاً، يمكن للواجهة جلب الصفحة التالية أثناء التمرير، ويمكن للمهمة المجمّعة معالجة الدفعات كلّاً على حدة. وأضف ترتيباً ثابتاً، كاستخدام معرّف فريد؛ فمن دونه قد تتغير حدود الصفحات إذا تبدلت البيانات بين الاستعلامات.
ومن المفيد أيضاً حفظ نقطة تحقق لآخر سجل جرت معالجته عند تنفيذ عمليات تصدير طويلة. وبذلك يمكن استئناف المهمة بعد تعطلها من دون إعادة معالجة المجموعة بأكملها. ويعتمد التصميم المحدد على التطبيق؛ لكن المبدأ الأساسي هو تقييد حجم كل استجابة، بدلاً من الاعتماد على استعلام واحد يعيد المجموعة كلها دفعة واحدة.
ما الذي ينبغي التحقق منه في التطبيق؟
ابدأ بالاستعلامات التي تعيد قوائم كبيرة: عمليات التصدير الخاصة بالتقارير، والشاشات الإدارية، والمهام الخلفية، ومسارات API التي ترسل مصفوفات من الصفوف. سجّل مؤقتاً حجم الاستجابة بعد تسلسلها، أو عدد الحقول المختارة وأحجامها. ثم تحقق من أكبر حجم متوقع، لا من مجموعة الاختبار الصغيرة المعتادة فحسب.
إذا بدأ التطبيق بإظهار خطأ بعد تطبيق التغيير، فوثائق D1 تربطه بنتيجة تتجاوز 50 ميغابايت، وتوصي باختيار الأعمدة اللازمة أو تقسيم النتيجة إلى صفحات. ويساعد ذلك على تمييز مشكلة حجم الاستجابة من قيود وقت التنفيذ أو الذاكرة أو إتاحة قاعدة البيانات؛ فلكل منها أخطاء وأسباب مختلفة.
والخلاصة للفريق بسيطة: من المرجح ألا تحتاج الاستعلامات القصيرة المعتادة إلى تغيير، أما عمليات القراءة الكبيرة فينبغي تحويلها إلى معالجة على دفعات. ولا يمنع وجود الحد تخزين قاعدة بيانات أكبر حجماً، ولا يلغي التصدير عبر REST API؛ بل يقتضي تصميم الاستعلامات بحيث تظل كل استجابة دون 50 ميغابايت.
