لماذا نستخدم التخزين المؤقت؟

لماذا نستخدم التخزين المؤقت؟

كل نظام ضخم يصطدم في نهاية المطاف بعقبتين: زمن الاستجابة والحِمل. استعلام قاعدة البيانات الذي يستغرق 80 مللي ثانية مقبول تماماً لعشرة مستخدمين، لكنه يكفي لشلّ بنيتك التحتية بأكملها مع عشرة ملايين مستخدم. التخزين المؤقت (Caching) هو التقنية الأكثر تأثيراً لاختراق هاتين العقبتين في آنٍ واحد.

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

مشكلة زمن الاستجابة

تتفاوت سرعات الوصول تفاوتاً هائلاً بين طبقات مختلفة في الحاسوب. هذه الأرقام تقريبية لكنها معايير صناعية راسخة:

• قراءة L1 cache للمعالج: ~0.5 نانو ثانية
• قراءة الذاكرة العشوائية RAM: ~100 نانو ثانية
• قراءة عشوائية من SSD: ~100 ميكرو ثانية (100,000 نانو ثانية)
• استعلام قاعدة البيانات (شبكة + قرص): 1 – 100 مللي ثانية
• رحلة شبكة بين مناطق: 150 – 300 مللي ثانية

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

مشكلة الحِمل

زمن الاستجابة ليس سوى نصف القصة. النصف الآخر هو معدل النقل: كم طلباً تستطيع قاعدة بياناتك معالجته في الثانية. نموذج PostgreSQL نموذجي على جهاز سحابي يتحمّل نحو 5,000–15,000 استعلام قراءة بسيط في الثانية قبل أن يصبح المعالج أو الإدخال-الإخراج عنق الزجاجة. نقطة API مشهورة تتلقى 100,000 طلب في الدقيقة (نحو 1,667 طلب/ث) تبدو مُدارَة — حتى تتضاعف بثلاثة أضعاف خلال ذروة المرور، أو يُسقط استعلام بطيء (ربط ثلاثة جداول كبيرة) معدل التحمّل المستدام إلى 500 طلب/ث.

تمتص طبقة الكاش الغالبية العظمى من حركة القراءة قبل أن تصل إلى قاعدة البيانات. إذا أصابت 90% من الطلبات الكاش (نسبة إصابة الكاش = 90%)، لا ترى قاعدة البيانات إلا 10% من الحِمل الأصلي — تقليص بمعامل 10. عند نسبة إصابة 99%، يبلغ التقليص 100 ضعف. لهذا تصف شركات مثل Twitter وFacebook وNetflix طبقات التخزين المؤقت لديها بأنها بنية تحتية أساسية لا تحسيناً ثانوياً.

قبل التخزين المؤقت: كل طلب يضرب قاعدة البيانات

تخيّل صفحة منتج في موقع تجارة إلكترونية. كل تحميل للصفحة يُطلق عدة استعلامات: جلب تفاصيل المنتج، وجلب المراجعات، وجلب العناصر المرتبطة، وجلب عدد المخزون. بدون كاش:

مع ثلاثة عملاء يُطلق كلٌّ منهم ثلاثة استعلامات، تعالج قاعدة البيانات تسعة استعلامات. مع 1,000 مستخدم متزامن تعالج 3,000 استعلام في الثانية — لصفحة واحدة فحسب. مع ذروة مرور، يُثبَّت معالج قاعدة البيانات عند 100%، تتضخم أوقات الاستعلامات، تنفد مجمّعات الاتصال، وتبدأ الصفحات في إرجاع أخطاء.

بعد التخزين المؤقت: تُخدَّم القراءات من الذاكرة

أضف الآن طبقة كاش — عادةً مخزن في الذاكرة مثل Redis — بين التطبيق وقاعدة البيانات. الطلب الأول لصفحة المنتج لا يزال يضرب قاعدة البيانات، لكن النتيجة تُخزَّن في الكاش. كل طلب لاحق على نفس البيانات يُخدَّم مباشرة من الذاكرة في أقل من 1 مللي ثانية، دون لمس قاعدة البيانات إطلاقاً.

التحول مذهل. نفس الصفحة التي استغرقت 120–200 مللي ثانية تُعاد الآن في 1–5 مللي ثانية لغالبية المستخدمين. قاعدة البيانات التي كانت تعالج 3,000 استعلام في الثانية تعالج الآن 300 فقط، ولديها هامش للاستعلامات التحليلية المعقدة والكتابات وذروات المرور.

مثال واقعي ملموس

جدول زمني Twitter هو أحد أكثر هياكل البيانات قراءةً على الإنترنت. في أوائل Twitter، كان الجدول الزمني يُجلَب بالاستعلام عن قاعدة البيانات في الوقت الحقيقي — بربط متابعات المستخدم بتغريداتهم الأخيرة. على النطاق الكبير كان هذا غير مستدام. الحل كان حساب جدول زمني كل مستخدم مسبقاً وتخزينه في Redis. قراءة جدول زمني مخزَّن تستغرق أقل من 1 مللي ثانية. بدون كاش، تستلزم نفس القراءة ربطاً متعدد الجداول يستغرق 200–500 مللي ثانية تحت الحِمل — تحسين بمعامل 200–500.

مجموعة Memcached في Facebook (تُدعى Tao) تخدم أكثر من مليار قراءة في الثانية في الذروة، وتمتص عبئاً لا تستطيع أي أسطول من قواعد البيانات العلائقية تحمّله مباشرةً.

ما الذي لا يحلّه التخزين المؤقت

التخزين المؤقت قوي لكنه ليس حلاً سحرياً. من المهم فهم حدوده منذ البداية:

• أعباء الكتابة الثقيلة: يساعد التخزين المؤقت أساساً في القراءات. إذا كانت عنق الزجاجة لديك في إنتاجية الكتابة، فأنت بحاجة إلى تقنيات مختلفة (سجلات الكتابة المسبقة، التجزئة، الكتابة غير المتزامنة).
• الاستعلامات الفريدة غير المتكررة: لا يوفّر الكاش وقتاً إلا إذا طُلبت نفس البيانات أكثر من مرة. التقارير لمرة واحدة أو الاستعلامات الشخصية عديمة إعادة الاستخدام معدل إصابتها 0%.
• خطر البيانات القديمة: يحمل الكاش نسخة من البيانات. إذا تغير المصدر ولم يُحدَّث الكاش، يقرأ العملاء معلومات قديمة. إدارة هذا — إبطال الكاش — أمر صعب بشهرة واسعة وموضوع محوري في هذا البرنامج التعليمي.
• تكلفة الذاكرة: تعيش الكاشات في RAM المكلفة. يجب أن تتخذ قرارات مدروسة بشأن ما تخزّنه ولكم من الوقت.

الخلاصة

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