أعلنت Cloudflare نتائج سلسلة من التحسينات منخفضة المستوى على مخزن DNS في منصة Big Pineapple، وهي المنصة التي تشغّل 1.1.1.1 وGateway DNS وDNS Firewall وAS112 وعدداً من خدمات DNS الأخرى. وتخزن المنصة أكثر من 250 مليار إدخال DNS في أي وقت، لذلك فإن التخلص من بايت واحد لكل إدخال يوفر أكثر من 250 غيغابايت من الذاكرة على مستوى الأسطول.
أدت خمسة تغييرات متتالية في بنية البيانات المكتوبة بلغة Rust إلى خفض حجم الإدخال الواحد من 953 بايتاً إلى 420 بايتاً، أي بنسبة 56%. وبعد تعميم التغييرات، انخفضت ذاكرة مجموعة العمل المستخدمة عبر أسطول Cloudflare بنحو 100 تيرابايت، مع تحسن الأداء بدلاً من التنازل عنه: زادت سرعة إدراج الإدخالات 43%، وانخفض زمن البحث في المخزن 19%.
لماذا كان حجم إدخال DNS مهماً؟
يبدأ Big Pineapple بمخزن فارغ عند التشغيل، ثم يمتلئ مع وصول الاستعلامات إلى أن يبلغ الحد الأقصى، فتُزال الإدخالات الأقدم أو الأقل استخداماً. ويختلف حجم المخزن بين مراكز البيانات، كما يمكن أن يؤدي استخدام EDNS Client Subnet إلى تخزين إجابات متعددة للاستعلام نفسه، لأن الخوادم authoritative قد تقدم إجابات مختلفة تبعاً لشبكة العميل.
يتكون كل إدخال من مفتاح يحدد اسم النطاق ونوع السجل وبعض السمات، وقيمة تحتوي على إجابة DNS وأقسام authority وadditional وبيانات وصفية مثل وقت الإنشاء وعداد مرات الاستخدام ومدة TTL. وعند هذا الحجم، لا تبقى الحقول الزائدة أو المساحة المحجوزة تفاصيل داخلية صغيرة، بل تتحول إلى تكلفة تشغيلية ضخمة.
أين جاءت الوفورات؟
استبدلت Cloudflare هياكل Vec وString القابلة للنمو بهياكل ثابتة هي Box<[T]> وBox<str> بعد تخزين الاستجابة، لأن البيانات لا تُعدّل لاحقاً. هذا التغيير أزال حقل السعة الذي تحتفظ به الهياكل القابلة للنمو، كما حد من المساحة المحجوزة غير المستخدمة. وبما أن كل إدخال يحتوي على ثمانية حقول من هذا النوع، بلغ الوفر 64 بايتاً لكل إدخال، وأكثر من 15 تيرابايت عبر المخزن بأكمله.
كما جُمعت قوائم أقسام الإجابة والسلطة والإضافات في قائمة واحدة، مع استخدام إزاحات من نوع u16 بدلاً من مؤشرات وأطوال أكبر. وسمح ذلك بتوفير 28 بايتاً لكل إدخال. واستفادت البنية أيضاً من ضغط عدة حقول منطقية في bitflag واحد، ما قلل المساحة المهدرة بسبب محاذاة الذاكرة التي يفرضها Rust داخل الهياكل.
وفي معظم سجلات DNS، يكون مالك السجل مطابقاً للنطاق الذي جرى الاستعلام عنه. لذلك لم تعد Cloudflare تخزن اسم المالك كاملاً في هذه الحالات، بل تستعيده من مفتاح التخزين عند بناء الإجابة. أما عندما يختلف الاسم، كما يحدث مع سجلات CNAME، فيُخزن الاسم الكامل. وبذلك أزيلت عمليات تخصيص الذاكرة لمعظم أسماء المالكين، مع الإبقاء على الحالات التي تحتاج الاسم فعلياً.
تقليل كلفة أنواع السجلات الكبيرة
كانت بنية RecordData تستخدم enum بحجم يساوي حجم أكبر نوع من السجلات، وهو NAPTR بحجم 144 بايتاً بعد احتساب الوسم والمحاذاة. ونتيجة لذلك، كانت سجلات A التي تحتاج 4 بايتات فقط وسجلات AAAA التي تحتاج 16 بايتاً تشغل مساحة أكبر بكثير من حاجتها، رغم أن A وAAAA يمثلان أكثر من 80% من حركة الاختبار.
جُرّب وضع الأنواع الكبيرة داخل Box منفصل، ما خفض الهدر في سجلات A وAAAA، لكنه أضاف تخصيصات منفصلة ومشكلات في locality الذاكرة. أما الحل النهائي فكان تخزين بيانات السجلات نفسها كبايتات خام متجاورة داخل Box<[u8]>، مع بادئة طول من بايتين لكل سجل. أزال ذلك كلفة enum والتخصيصات المتعددة، وحسّن استفادة المعالج من ذاكرة التخزين المؤقت.
هذا الاختيار يعني أن السجلات لم تعد قابلة للفهرسة العشوائية، بل يجب المرور عليها تسلسلياً. وترى Cloudflare أن الكلفة محدودة لأن عدد السجلات في الإدخال الواحد صغير. كما يمكن نسخ معظم الأنواع، ومنها A وAAAA وTXT وسجلات DNSSEC، مباشرة إلى رسالة DNS الخارجة، بينما لا تزال الأنواع التي تحتوي أسماء نطاقات، مثل CNAME وNS وMX وSOA، تحتاج إلى تحليل لتطبيق ضغط أسماء DNS.
ما الذي تغير عملياً؟
أظهرت القياسات الإنتاجية انخفاض الذاكرة المقيمة عند النسبة المئوية 99 من 9.3 إلى 5.3 غيغابايت، أي 43%، ومن 6.5 إلى 3.8 غيغابايت عند النسبة المئوية 90، أي 42%. وانخفضت التخصيصات لكل إدخال من 1.1 كيلوبايت إلى 461 بايتاً، بينما ارتفعت سرعة الإدراج من 625 ألف إدخال في الثانية إلى 893 ألفاً، وتراجع زمن البحث من 828 نانوثانية إلى 670 نانوثانية.
بدأ طرح التغييرات في 18 مايو 2026 واكتمل عبر جميع الخدمات في 6 يوليو 2026. وتوضح Cloudflare أن الذاكرة المقيمة في الإنتاج تشمل بيانات أخرى إلى جانب المخزن، لذلك جاءت نسبة الانخفاض الفعلية على مستوى العملية أقل من نتيجة القياس المعزول لكل إدخال. كما تخطط الشركة لإعادة استثمار الذاكرة المحررة في زيادة سعة المخزن من دون رفع استهلاك الذاكرة، بهدف تحسين معدلات إصابة الذاكرة المؤقتة وتقليل الاستعلامات المرسلة إلى الخوادم الأعلى.
تكمن أهمية هذه الحالة في أنها توضح أن تحسينات بنية البيانات، مثل إزالة السعة غير اللازمة وتجميع التخصيصات وتحسين locality، يمكن أن تحقق أثراً أكبر من إضافة موارد عتادية مباشرة عندما تعمل الخدمة على مئات المليارات من العناصر. لكن بعض المقايضات باقية: التخزين الخام يزيد تعقيد التعامل مع السجلات، والاسترجاع من مفتاح التخزين يصبح ضرورياً لإعادة بناء أسماء المالكين، كما أن نتائج الاختبارات تعتمد على مزيج حركة محدد لا يطابق الإنتاج بالكامل. لذلك تظل القياسات الإنتاجية، لا الأرقام النظرية وحدها، المرجع الأهم عند تقييم مثل هذه التحسينات.
كيف أعددنا هذا الخبر؟
اعتمد الخبر على المصدر الأصلي الموضح أعلاه. قد نستخدم أدوات آلية للمساعدة في الاستخراج والتصنيف والصياغة،
لكن النشر يخضع لقواعد تمنع المحتوى المكرر والقصير أو الروتيني منخفض القيمة.
اقرأ سياستنا التحريرية.