الحوسبة السحابية ومراكز البيانات

Cloudflare تختبر ضغط محتوى التخزين المؤقت لتوسيع السعة الفعلية باستخدام Zstandard وPingora

اختبرت Cloudflare نموذجاً أولياً يضغط ملفات النصوص القابلة للضغط داخل التخزين المؤقت باستخدام Zstandard، ما خفّض حجم الأصول المؤهلة إلى نحو الثلث في الاختبارات. المقابل هو استهلاك إضافي محدود للمعالج، مع وعود بتوفير سعة تخزين على مستوى البيتابايت وتقليل نقل البيانات بين مراكز البيانات.

01 سبتمبر 2026
4 دقائق قراءة
1 قراءة
فريق تحرير certi.news
Cloudflare تختبر ضغط محتوى التخزين المؤقت لتوسيع السعة الفعلية باستخدام Zstandard وPingora

تختبر Cloudflare طريقة لزيادة السعة الفعلية لشبكة التخزين المؤقت لديها من دون إضافة عتاد جديد، عبر ضغط بعض الأصول النصية باستخدام خوارزمية Zstandard داخل البنية المعتمدة على Pingora. ويهدف النموذج الأولي، الذي أطلقت عليه الشركة اسم Cache Transcoding، إلى تقليل المساحة التي تشغلها البيانات على الأقراص وحجم البيانات المنقولة بين طبقات التخزين المؤقت ومراكز البيانات.

عند دخول استجابة مؤهلة إلى الذاكرة المؤقتة، تُحوَّل بياناتها إلى تمثيل مضغوط باستخدام zstd قبل كتابتها على القرص. وتظل الأصول بهذا الشكل أثناء وجودها في التخزين المؤقت وأثناء انتقالها عبر Tiered Cache، ثم تُفك قبل إرسالها إلى العميل. وبذلك لا يتغير محتوى الملف نفسه؛ إذ إن Zstandard خوارزمية ضغط غير فقدية تعيد بعد فك الضغط كل بايت إلى حالته الأصلية.

نتيجة كبيرة مقابل كلفة معالجة محدودة

في الاختبارات الأولية، انخفض حجم الأصول المؤهلة على القرص إلى نحو ثلث حجمها الأصلي في المتوسط. وبلغت نسبة الضغط في مجموعة الاختبار المضبوطة 2.834 مرة. أما كلفة الترميز فكانت 4.31 نانوثانية لكل بايت، أو نحو 232 ميغابايت في الثانية، وتُدفع مرة واحدة عند ملء الذاكرة المؤقتة. في المقابل، بلغت كلفة فك الضغط 1.56 نانوثانية لكل بايت، أو نحو 641 ميغابايت في الثانية، وتُدفع عند كل عملية تقديم.

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

لماذا لا تضغط Cloudflare كل شيء؟

لا تستهدف الآلية جميع أنواع المحتوى. فالصور والفيديوهات والخطوط تكون مضغوطة عادةً، وقد شكّلت في عينة الحركة 21.4% من الطلبات لكنها مثّلت 63.3% من إجمالي البايتات. إعادة ضغط هذه البيانات قد تستهلك المعالج من دون توفير ملموس.

في المقابل، شكّلت HTML وJSON وCSS وJavaScript نحو 67.3% من الطلبات و22.3% من البايتات. وكان نحو 71% من هذه الاستجابات النصية يصل من المصدر من دون Content-Encoding، ما جعلها مرشحة للضغط. ويقتصر النموذج الأولي على استجابات 200 OK التي لا تحدد Content-Encoding، وتملك نوع محتوى نصياً قابلاً للضغط، وطولاً معروفاً لا يقل عن 4 KiB.

تُترك من دون تغيير طلبات الشرائح الجزئية، والاستجابات التي ضغطها المصدر مسبقاً، وطلبات النطاق، والأجسام ذات الطول غير المعروف، والمحتوى الثنائي. ووجدت Cloudflare أن حد 4 KiB يستبعد عدداً كبيراً من الطلبات الصغيرة، لكنه لا يحذف سوى نحو 1% من البايتات التي كانت مؤهلة بخلاف ذلك.

كيف تعمل الآلية عبر طبقات التخزين؟

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

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

قراءة certi.news: ما الذي تثبته التجربة فعلاً؟

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

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

تخطط Cloudflare لاختبار مستويات أعلى من zstd، وتوسيع نطاق المحتوى والأحجام، وضبط شروط الأهلية، ودراسة طلبات النطاق والاستجابات المضغوطة مسبقاً. لذلك تبقى Cache Transcoding في المادة الحالية نموذجاً أولياً ناجحاً ضمن شروط محددة، لا إعلاناً عن تعميم نهائي على جميع حركة Cloudflare.

مصدر الخبر
كيف أعددنا هذا الخبر؟

اعتمد الخبر على المصدر الأصلي الموضح أعلاه. قد نستخدم أدوات آلية للمساعدة في الاستخراج والتصنيف والصياغة، لكن النشر يخضع لقواعد تمنع المحتوى المكرر والقصير أو الروتيني منخفض القيمة. اقرأ سياستنا التحريرية.

ف
كاتب المقال

فريق تحرير certi.news

فريق التحرير

فريق تحرير certi.news يتابع المصادر التقنية ويعيد بناء الأخبار بالعربية مع مراجعة الحقائق والسياق قبل النشر.

من نفس التصنيف

مقالات قد تهمك

عرض جميع المقالات