cached القاموس في cache يحتوي على عدد ثابت من الخلايا.
وتتضمن هذه الخلايا العناصر الأكثر استخدامًا.
يكون مفتاح القاموس من النوع UInt64.
عند البحث عن قيمة في القاموس، يُبحث أولًا في cache. ولكل block من البيانات، تُطلب جميع المفاتيح التي لا توجد في cache أو التي انتهت صلاحيتها من المصدر باستخدام SELECT attrs... FROM db.table WHERE id IN (k1, k2, ...). ثم تُكتب البيانات المستلمة إلى cache.
محتويات cache محلية لكل خادم، وتُفقد عند إعادة تشغيل الخادم أو استبداله. لا تستخدم cache أو complex_key_cache لإثراء البيانات وقت الإدراج بشكل موثوق: إذ يجعل cache الفارغ عمليات الإدراج معتمدة على عمليات البحث في مصدر القاموس. وفي ClickHouse Cloud، يزيد التوسع التلقائي والاستبدال المُدار للعُقد من احتمال حدوث هذا الوضع. استخدم بدلًا من ذلك تخطيطًا يُحمِّل القاموس كاملًا على كل خادم؛ راجع أفضل ممارسات القواميس.
ينطبق ذلك عند البحث عن مفتاح — باستخدام dictGet ودوال القاموس الأخرى. أما قراءة القاموس كجدول باستخدام SELECT ... FROM <dictionary> فتختلف: فلأن cache لا يحتفظ بسجل بالمفاتيح الموجودة، تُعدِّد القراءة فقط الخلايا الموجودة في cache في تلك اللحظة والتي تحمل قيمة، ويكون WHERE على المفتاح عامل تصفية عاديًا لتلك الخلايا، وليس قائمة مفاتيح لجلبها. ولا يمكن اكتشاف مفتاح غير موجود في cache بهذه الطريقة، مهما كان ما ينص عليه WHERE. كما أن المفتاح الذي جرى البحث عنه ولم يُعثر عليه في المصدر لا يكون مرئيًا أيضًا: إذ يتذكر cache هذا الإخفاق كخلية افتراضية، وتتخطى قراءة الجدول الخلايا الافتراضية. كما أن الخلايا الموجودة ليست بمنأى عن المصدر: فالخلية منتهية الصلاحية تُقرأ عبر المسار نفسه الذي يسلكه dictGet، ولذلك يُعاد طلبها من المصدر — بشكل متزامن، أو بشكل غير متزامن إذا كان allow_read_expired_keys مفعّلًا.
dictGet مع تخطيط direct، الذي يستعلم من المصدر عند كل عملية بحث ولا يخزّن شيئًا في cache. لاحظ أن قراءة قاموس direct كجدول ليست جلبًا بالمفتاح أيضًا: إذ يُحمِّل SELECT ... FROM <dictionary> WHERE key IN (...) المصدر بأكمله ثم يُجري التصفية بعد ذلك، لأن ClickHouse لا يدفع عامل تصفية المفتاح إلى داخل القاموس. ولقراءة قاموس كجدول، استخدم تخطيطًا يحتفظ به كاملًا، مثل flat أو hashed.
إذا لم يُعثر على المفاتيح في القاموس، فستُنشأ مهمة لتحديث cache وتُضاف إلى قائمة انتظار التحديث. ويمكن التحكم في خصائص قائمة انتظار التحديث باستخدام الإعدادات max_update_queue_size, update_queue_push_timeout_milliseconds, query_wait_timeout_milliseconds, max_threads_for_updates.
بالنسبة إلى قواميس cache، يمكن ضبط lifetime لانتهاء صلاحية البيانات في cache. وإذا مرّ وقت أطول من lifetime منذ تحميل البيانات في خلية معيّنة، فلن تُستخدم قيمة الخلية ويصبح المفتاح منتهي الصلاحية. ويُعاد طلب المفتاح في المرة التالية التي يلزم فيها استخدامه. ويمكن تهيئة هذا السلوك باستخدام الإعداد allow_read_expired_keys.
تُعد هذه أقل طرق تخزين القواميس كفاءةً بين جميع الطرق. وتعتمد سرعة cache بدرجة كبيرة على صحة الإعدادات وسيناريو الاستخدام. ولا يحقق القاموس من النوع cache أداءً جيدًا إلا عندما تكون معدلات النجاح مرتفعة بما يكفي (الموصى به 99% فأكثر). ويمكنك عرض متوسط معدل النجاح في جدول system.dictionaries.
إذا ضُبط الإعداد allow_read_expired_keys على 1 (القيمة الافتراضية 0)، يصبح بإمكان القاموس دعم التحديثات غير المتزامنة. فإذا طلب عميل مفاتيح وكانت جميعها موجودة في cache، لكن بعضها منتهي الصلاحية، فسيُعيد القاموس المفاتيح منتهية الصلاحية إلى العميل ويطلبها من المصدر بشكل غير متزامن.
لتحسين أداء cache، استخدم استعلامًا فرعيًا مع LIMIT، واستدعِ الدالة التي تستخدم القاموس من خارج الاستعلام الفرعي.
جميع أنواع المصادر مدعومة.
مثال على الإعدادات:
- DDL
- ملف الإعدادات
اضبط حجم cache بحيث يكون كبيرًا بما يكفي. ستحتاج إلى التجربة لاختيار عدد الخلايا:
- اضبط قيمة مبدئية.
- شغّل الاستعلامات حتى يمتلئ cache بالكامل.
- قيّم استهلاك الذاكرة باستخدام جدول
system.dictionaries. - زِد عدد الخلايا أو قلّله حتى تصل إلى استهلاك الذاكرة المطلوب.
لا يُنصح باستخدام ClickHouse كمصدر لهذا التخطيط. تتطلب عمليات البحث في القاموس قراءات نقطية عشوائية، وهذا ليس نمط الوصول الذي جرى تحسين ClickHouse من أجله.