التجربة MariaDB: ذاكرة التخزين المؤقت للاستعلام

مفهوم ذاكرة التخزين المؤقت للاستعلام

ذاكرة التخزين المؤقت للاستعلام MariaDB / MySQL هي آلية مضمنة في الخادم تقوم بتخزين نتيجة استعلامات SELECT في الذاكرة. عند إعادة إرسال استعلام مماثل، يقوم الخادم بإرجاع النتيجة المخزنة مؤقتًا مباشرة دون تنفيذ الاستعلام. إنها بسيطة وأنيقة ومن المحتمل أن تكون فعالة للغاية.

الكلمة الأساسية هنا هي "محتمل". تعد ذاكرة التخزين المؤقت للاستعلام واحدة من أكثر الميزات التي يتم إساءة فهمها وتكوينها بشكل خاطئ في MariaDB / MySQL. إذا تم استخدامه بشكل صحيح، فيمكن أن يقلل أوقات الاستجابة بمقدار 10 مرات. وإذا تم تكوينه بشكل خاطئ، فقد يؤدي إلى تدمير الأداء.

الأوضاع الثلاثة

يمكن أن تعمل ذاكرة التخزين المؤقت للاستعلام في ثلاثة أوضاع، يتم التحكم فيها بواسطة المتغير query_cache_type:

إيقاف (0)

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

تشغيل (1)

يتم تخزين كافة استعلامات SELECT مؤقتًا بشكل افتراضي، باستثناء تلك التي تم وضع علامة عليها بالتلميح SQL_NO_CACHE. هذا هو الوضع الأكثر عدوانية.

-- Cette requête sera mise en cache
SELECT * FROM products WHERE category_id = 5;

-- Cette requête ne sera PAS mise en cache
SELECT SQL_NO_CACHE * FROM products WHERE category_id = 5;

نحن نسأل (2)

لا يتم تخزين أية استعلامات مؤقتًا بشكل افتراضي. يتم تخزين الطلبات التي تم وضع علامة صراحة عليها بـ SQL_CACHE فقط في ذاكرة التخزين المؤقت. هذا هو الوضع الأكثر تحكمًا والأكثر فعالية في كثير من الأحيان.

-- Cette requête ne sera PAS mise en cache (mode par défaut)
SELECT * FROM products WHERE category_id = 5;

-- Cette requête SERA mise en cache
SELECT SQL_CACHE * FROM products WHERE category_id = 5;

الوضع ON DEMAND هو الوضع الذي أوصي به في معظم الحالات. إنه يجبرك على التفكير في الاستعلامات التي تستحق إخفاءها، بدلاً من تخزين كل شيء بشكل أعمى.

البطلان: كعب أخيل

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

-- Suppose que 1000 SELECT sur la table 'products' sont en cache
UPDATE products SET price = 19.99 WHERE product_id = 42;
-- → Les 1000 entrées de cache pour 'products' sont invalidées

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

حجم ذاكرة التخزين المؤقت

يتم التحكم في حجم ذاكرة التخزين المؤقت للاستعلام بواسطة query_cache_size:

[mysqld]
query_cache_type = 2
query_cache_size = 64M
query_cache_limit = 2M
query_cache_min_res_unit = 2048

• query_cache_size: إجمالي حجم ذاكرة التخزين المؤقت. لا تتجاوز 256 ميجابايت — وبعد ذلك، يصبح كائن المزامنة لذاكرة التخزين المؤقت العالمية بمثابة عنق الزجاجة.
• query_cache_limit: الحد الأقصى لحجم النتيجة الفردية. لا يتم تخزين النتائج الأكبر حجمًا مؤقتًا.
• query_cache_min_res_unit: حجم كتلة التخصيص. يؤدي تقليل هذه القيمة للحصول على نتائج صغيرة إلى تقليل التجزئة.

مراقبة ذاكرة التخزين المؤقت

تعد متغيرات الحالة Qcache_* ضرورية لتقييم الفعالية:

SHOW GLOBAL STATUS LIKE 'Qcache%';

المقاييس الرئيسية:

نسبة الكفاءة

النسبة الأكثر أهمية هي نسبة الإصابة:

Hit ratio = Qcache_hits / (Qcache_hits + Com_select) × 100

التفسير:

• > 40%: ذاكرة التخزين المؤقت فعالة، وتستحق التمكين
• 20-40%: منطقة رمادية، يتم تقييمها على أساس كل حالة على حدة
• < 20%: ذاكرة التخزين المؤقت غير فعالة، فكر في إلغاء تنشيطها

النسبة المهمة الثانية هي نسبة الإخلاء:

Eviction ratio = Qcache_lowmem_prunes / Qcache_inserts × 100

إذا تجاوزت هذه النسبة 10%، فإن ذاكرة التخزين المؤقت صغيرة جدًا — قم بزيادة query_cache_size أو قلل ما قمت بتخزينه مؤقتًا.

فخ المنافسة

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

ولهذا السبب قام MySQL 8.0 بإزالة ذاكرة التخزين المؤقت للاستعلام. قدر فريق Oracle أن تكلفة كائن المزامنة (mutex) تتجاوز فوائد التخزين المؤقت في أحمال العمل الحديثة (التزامن العالي، والكتابة المتكررة).

اختار MariaDB الاحتفاظ به، مع الأخذ في الاعتبار أنه يظل مفيدًا لبعض حالات الاستخدام المحددة (أحمال القراءة، والتزامن المنخفض، ونادرًا ما يتم تعديل الجداول).

ذاكرة التخزين المؤقت للاستعلام وGalera: التركيبة الصعبة

يعد استخدام ذاكرة التخزين المؤقت للاستعلام في مجموعة Galera مشكلة. Galera ينسخ عمليات الكتابة إلى كافة العقد، لكن ذاكرة التخزين المؤقت للاستعلام تكون محلية لكل عقدة. النتيجة:

1. تتلقى العقدة A التحديد وتخزن النتيجة مؤقتًا
2. تتلقى العقدة B تحديثًا عبر النسخ المتماثل Galera
3. لم يتم إبطال ذاكرة التخزين المؤقت للعقدة أ — فهي لا تعرف أن البيانات قد تغيرت
4. يقوم التحديد التالي على العقدة A بإرجاع البيانات القديمة

الطريقة الآمنة الوحيدة لاستخدام ذاكرة التخزين المؤقت للاستعلام مع Galera هي باستخدام wsrep_causal_reads = ON، الذي يفرض التحقق من التناسق قبل كل قراءة. لكن هذا ينفي إلى حد كبير فائدة ذاكرة التخزين المؤقت.

البديل: مرشح ذاكرة التخزين المؤقت MaxScale

بالنسبة للبنيات التي تحتاج إلى ذاكرة تخزين مؤقت للاستعلام الموزع، يعد مرشح ذاكرة التخزين المؤقت MaxScale طريقة أفضل:

[query-cache]
type = filter
module = cache
storage = storage_inmemory
ttl = 10s
max_size = 256Mi

ذاكرة التخزين المؤقت MaxScale مركزية (على مستوى الوكيل)، مما يزيل مشكلة عدم الاتساق بين عقد Galera. بالإضافة إلى ذلك، يمكن لـ MaxScale إبطال ذاكرة التخزين المؤقت بذكاء بناءً على نوع الاستعلام، وليس فقط الجدول المعدل.

متى يتم تمكين ذاكرة التخزين المؤقت للاستعلام

تكون ذاكرة التخزين المؤقت للاستعلام ذات صلة عندما:

• التحميل للقراءة بشكل أساسي (> 80% من التحديد)
• الجداول نادرا ما يتم تعديلها (جداول التكوين، المستودعات)
• التزامن معتدل (<50 اتصالاً متزامنًا)
• تتكرر الطلبات نفسها بشكل متكرر (تطبيقات الويب التي تحتوي على ذاكرة تخزين مؤقت مفقودة)
• أنت على خادم مستقل، وليس مجموعة Galera

لا تكون ذاكرة التخزين المؤقت للاستعلام ذات صلة عندما:

• الحمل مختلط القراءة / الكتابة
• الجداول يتم تعديلها بشكل متكرر (جداول المعاملات)
• التزامن مرتفع (كائن المزامنة العالمي)
• أنت في مجموعة Galera (عدم تناسق ذاكرة التخزين المؤقت)

الخلاصة

تعد ذاكرة التخزين المؤقت للاستعلام MariaDB أداة قوية ولكنها حساسة. يوفر الوضع ON DEMAND مع التلميح SQL_CACHE أفضل تحكم. تعد المراقبة عبر متغيرات Qcache_* ضرورية لتقييم الفعالية. وبالنسبة للبنى الموزعة، غالبًا ما يكون مرشح ذاكرة التخزين المؤقت MaxScale خيارًا أفضل.

مثل أي أداة للأداء، المفتاح هو القياس. تفعيل ومراقبة وضبط. إذا ظلت نسبة الإصابة أقل من 20%، فقم بتعطيلها والمضي قدمًا.

تم نشر هذه المقالة في الأصل على متوسط.