الانتقال إلى المحتوى الرئيسي
لا تعمل ذاكرة التخزين المؤقت لشروط الاستعلام إلا عندما تكون enable_analyzer مضبوطة على true، وهي القيمة الافتراضية.
تتضمن كثير من أعباء العمل في الواقع استعلامات متكررة على البيانات نفسها أو على بيانات تكاد تكون نفسها (على سبيل المثال، بيانات موجودة مسبقًا بالإضافة إلى بيانات جديدة). يوفر ClickHouse تقنيات تحسين متنوعة لهذه الأنماط من الاستعلامات. أحد الخيارات هو ضبط البنية المادية للبيانات باستخدام بُنى الفهارس (مثل فهارس المفتاح الأساسي، وفهارس التخطي، والإسقاطات، والعروض المادية). وخيار آخر هو استخدام ذاكرة التخزين المؤقت للاستعلام في ClickHouse لتجنب التقييم المتكرر للاستعلامات. ومن عيوب النهج الأول أنه يتطلب تدخلاً يدويًا ومتابعة من مسؤول قاعدة بيانات. أما النهج الثاني فقد يعيد نتائج غير محدّثة (لأن ذاكرة التخزين المؤقت للاستعلام ليست متسقة على مستوى المعاملات)، وقد يكون ذلك مقبولاً أو غير مقبول بحسب حالة الاستخدام. توفر ذاكرة التخزين المؤقت لشروط الاستعلام حلاً أنيقًا للمشكلتين كلتيهما. وهي تستند إلى فكرة أن تقييم شرط تصفية (مثل WHERE col = 'xyz') على البيانات نفسها سيُرجع دائمًا النتائج نفسها. وبشكل أكثر تحديدًا، تتذكر ذاكرة التخزين المؤقت لشروط الاستعلام، لكل عامل تصفية جرى تقييمه ولكل granule (= كتلة من 8192 صفًا افتراضيًا)، ما إذا كان لا يوجد أي صف في هذه الكتلة يطابق شرط التصفية. وتُسجَّل هذه المعلومة على شكل بت واحد: إذ تمثل القيمة 0 عدم وجود أي صف يطابق عامل التصفية، بينما تعني القيمة 1 وجود صف مطابق واحد على الأقل. في الحالة الأولى، يمكن لـ ClickHouse تخطي الـ granule المقابل أثناء تقييم عامل التصفية، أما في الحالة الثانية فيجب تحميل الـ granule وتقييمه. تكون ذاكرة التخزين المؤقت لشروط الاستعلام فعّالة إذا استوفت ثلاثة متطلبات مسبقة:
  • أولاً، يجب أن يقيّم عبء العمل شروط التصفية نفسها بشكل متكرر. يحدث هذا طبيعيًا إذا تكرر الاستعلام عدة مرات، لكنه قد يحدث أيضًا إذا اشترك استعلامان في عوامل التصفية نفسها، مثل SELECT product FROM products WHERE quality > 3 و SELECT vendor, count() FROM products WHERE quality > 3.
  • ثانيًا، يجب أن تكون غالبية البيانات غير قابلة للتغيير، أي إنها لا تتغير بين الاستعلامات. وهذا هو الحال عمومًا في ClickHouse لأن الأجزاء غير قابلة للتغيير ولا تُنشأ إلا بواسطة عمليات INSERT.
  • ثالثًا، يجب أن تكون عوامل التصفية انتقائية، أي إن عددًا قليلاً نسبيًا فقط من الصفوف يطابق شرط التصفية. وكلما قلّ عدد الصفوف المطابقة لشرط التصفية، سُجِّل عدد أكبر من وحدات granule بالقيمة 0 (من دون صفوف مطابقة)، وأمكن “استبعاد” مزيد من البيانات من تقييمات التصفية اللاحقة.

​
استهلاك الذاكرة

نظرًا لأن ذاكرة التخزين المؤقت لشروط الاستعلام لا تخزّن سوى بت واحد لكل شرط تصفية ولكل granule، فهي لا تستهلك إلا قدرًا قليلًا من الذاكرة. يمكن ضبط الحد الأقصى لحجم ذاكرة التخزين المؤقت لشروط الاستعلام باستخدام إعدادات الخادم query_condition_cache_size (الافتراضي: 100 MB). يعادل حجم ذاكرة تخزين مؤقت قدره 100 MB عدد 100 * 1024 * 1024 * 8 = 838,860,800 إدخال. وبما أن كل إدخال يمثّل mark واحدة (8192 صفًا افتراضيًا)، يمكن لذاكرة التخزين المؤقت أن تغطي ما يصل إلى 6,871,947,673,600 (6.8 تريليون) صف من عمود واحد. عمليًا، تُقيَّم المرشحات على أكثر من عمود واحد، لذلك يجب قسمة هذا العدد على عدد الأعمدة المُرشَّحة.

​
إعدادات التهيئة والاستخدام

يتحكم الإعداد use_query_condition_cache في ما إذا كان ينبغي لاستعلام معيّن أو لجميع استعلامات الجلسة الحالية استخدام ذاكرة التخزين المؤقت لشروط الاستعلام. على سبيل المثال، أول تنفيذ للاستعلام 
SELECT col1, col2
FROM table
WHERE col1 = 'x'
SETTINGS use_query_condition_cache = true;
سيُخزِّن نطاقات من الجدول لا تستوفي شرط التصفية. وفي عمليات التنفيذ اللاحقة للاستعلام نفسه، مع استخدام المعامل use_query_condition_cache = true أيضًا، ستُستخدَم ذاكرة التخزين المؤقت لشروط الاستعلام لفحص بيانات أقل.

​
الإدارة

لا يستمر الاحتفاظ بذاكرة التخزين المؤقت لشروط الاستعلام بين عمليات إعادة تشغيل ClickHouse. لمسح ذاكرة التخزين المؤقت لشروط الاستعلام، شغّل SYSTEM CLEAR QUERY CONDITION CACHE. يُعرض محتوى ذاكرة التخزين المؤقت في جدول النظام system.query_condition_cache. ولحساب الحجم الحالي لذاكرة التخزين المؤقت لشروط الاستعلام بالميغابايت، شغّل SELECT formatReadableSize(sum(entry_size)) FROM system.query_condition_cache. إذا كنت ترغب في فحص شروط التصفية الفردية، يمكنك التحقق من الحقل condition في system.query_condition_cache. لاحظ أن هذا الحقل متاح فقط في إصدارات Debug. يُعرض عدد مرات الإصابة والإخفاق لذاكرة التخزين المؤقت لشروط الاستعلام منذ بدء تشغيل قاعدة البيانات كحدثين “QueryConditionCacheHits” و”QueryConditionCacheMisses” في جدول النظام system.events. ولا يُحدَّث هذان العدادان إلا لاستعلامات SELECT التي تعمل مع الإعداد use_query_condition_cache = true، أما الاستعلامات الأخرى فلا تؤثر في “QueryCacheMisses”.

​
محتوى مرتبط

آخر تعديل في ٢٩ يونيو ٢٠٢٦