متى تستخدم القواميس بدلًا من عمليات JOIN
تكون القواميس الأنسب عندما يكون أحد طرفَي عملية JOIN جدولًا مرجعيًا يمكن احتواؤه في الذاكرة. في عملية JOIN القياسية، ينشئ ClickHouse جدول تجزئة من الجانب الأيمن قبل فحصه باستخدام الجانب الأيسر — حتى لو جرى لاحقًا استبعاد معظم الصفوف بواسطة عوامل تصفيةWHERE. وعلى الرغم من أن الإصدارات الحديثة (24.12+) تدفع عوامل التصفية قبل عمليات JOIN في كثير من الحالات، فإن ذلك لا يلغي دائمًا هذا الحمل الإضافي. أما عند استخدام قاموس، فتستدعي dictGet مباشرةً، لذلك لا تحدث عمليات بحث إلا للصفوف التي اجتازت التصفية بالفعل.
ومع ذلك، لا تكون dictGet الخيار المناسب دائمًا. فإذا كنت بحاجة إلى استدعاء dictGet على نسبة كبيرة من صفوف جدول — على سبيل المثال، ضمن شرط WHERE مثل dictGet('dict', 'elevation', id) > 1800 — فقد يكون من الأفضل استخدام عمود عادي مع فهارس أصلية. يستطيع ClickHouse استخدام PREWHERE لتخطي granules لعمود عادي، لكن dictGet تُقيَّم صفًا بصف من دون دعم للفهرسة.
وكقاعدة عامة:
- استخدم القواميس لاستبدال عمليات JOIN مع جداول الأبعاد الصغيرة عندما يكون مفتاح بحث متاحًا بالفعل.
- استخدم الأعمدة العادية والفهارس عند التصفية بناءً على القيمة المسترجعة عبر عدد كبير من الصفوف.
اختيار تخطيط
يتحكم البندLAYOUT في بنية البيانات الداخلية للقاموس. جميع التخطيطات المتاحة موثقة في مرجع التخطيطات.
عند اختيار تخطيط، استخدم الإرشادات التالية:
flat— أسرع تخطيط (بحث بسيط عبر إزاحة المصفوفة)، لكن يجب أن تكون المفاتيح من النوعUInt64، وهي محدودة افتراضيًا بـ 500,000 (max_array_size). وهو الأنسب للمفاتيح الصحيحة المتزايدة اطرادًا في الجداول الصغيرة إلى المتوسطة. تؤدي توزيعات المفاتيح المتفرقة (مثل قيم المفاتيح 1 و500,000) إلى هدر الذاكرة، لأن حجم المصفوفة يُحدَّد وفقًا لأكبر مفتاح. إذا كنت تصطدم بحد 500 ألف، فهذه إشارة إلى التبديل إلىhashed_array.hashed_array— الخيار الافتراضي الموصى به لمعظم حالات الاستخدام. يخزّن السمات في مصفوفات مع جدول تجزئة يربط المفاتيح بفهارس المصفوفة. وهو قريب جدًا منhashedفي السرعة، لكنه أكفأ في استخدام الذاكرة، خاصةً عند وجود عدد كبير من السمات.hashed— يخزّن القاموس بالكامل في جدول تجزئة. قد يكون أسرع منhashed_arrayعندما يكون لديك عدد قليل جدًا من السمات، لكنه يستهلك ذاكرة أكبر كلما ازداد عدد السمات.complex_key_hashed/complex_key_hashed_array— استخدم هذين عندما لا تكون المفاتيح قابلة للتحويل إلىUInt64(على سبيل المثال، مفاتيحString). ويتبعان نفس المفاضلات في الأداء مثل نظيريهما غير المركبين.sparse_hashed— يبادل انخفاض استخدام الذاكرة بزيادة استهلاك CPU مقارنةً بـhashed. نادرًا ما يكون الخيار الأفضل — ولا يكون فعالًا إلا عندما تكون لديك سمة واحدة. في معظم الحالات، يكونhashed_arrayأنسب.cache/ssd_cache— لا يخزّن في ذاكرة التخزين المؤقت إلا المفاتيح كثيرة الاستخدام. وهو مفيد عندما لا تتسع الذاكرة لمجموعة البيانات الكاملة، لكن قد تعود عمليات البحث إلى المصدر عند عدم العثور على المفتاح في ذاكرة التخزين المؤقت. لا يُنصح به لأعباء العمل الحساسة لزمن الاستجابة، ولا عندما يلزم إثراء موثوق للبيانات وقت الإدراج؛ راجع قواميس ذاكرة التخزين المؤقت في مسارات الإدخال.direct— يستعلم المصدر عند كل عملية بحث من دون أي تخزين داخل الذاكرة. استخدمه عندما تتغير البيانات بوتيرة عالية جدًا بحيث لا يناسبها التخزين في ذاكرة التخزين المؤقت، أو عندما يكون القاموس كبيرًا جدًا بحيث لا يتسع في الذاكرة.
قواميس ذاكرة التخزين المؤقت في مسارات الإدخال
تحتفظ التخطيطات القائمة على ذاكرة التخزين المؤقت —cache وcomplex_key_cache وssd_cache وcomplex_key_ssd_cache — بالعناصر المُحمَّاة مسبقاً على الخادم المحلي فقط. فكل خادم يُحمّي ذاكرة التخزين المؤقت الخاصة به بشكل مستقل، وعند إعادة تشغيل الخادم أو استبداله يبدأ بذاكرة تخزين مؤقت فارغة. أما عمليات البحث في ذاكرة تخزين مؤقت باردة فتعتمد على مصدر القاموس، مما يزيد زمن الاستجابة وقد يؤدي إلى تعطّل عمليات الإدراج أو فشلها إذا تعذّر على المصدر تلبية عملية البحث. وفي ClickHouse Cloud، يزيد التوسع التلقائي والاستبدال المُدار للعُقد من احتمال حدوث ذلك.
تجنّب استخدام هذه التخطيطات لإثراء البيانات وقت الإدراج في العروض المُجسَّدة التزايدية أو في أعمدة MATERIALIZED وDEFAULT حين يكون ثبات زمن الاستجابة وتوافر المصدر أمرين مهمين. واستخدم بدلاً من ذلك تخطيطاً يحمّل القاموس كاملاً على كل خادم: عادةً hashed أو hashed_array للمفاتيح من نوع UInt64، وcomplex_key_hashed أو complex_key_hashed_array للمفاتيح النصية أو المركّبة. كما قد يكون flat وغيره من التخطيطات المحمَّلة بالكامل مناسباً أيضاً. وإذا تعذّر استيعاب القاموس كاملاً، فأثرِ البيانات قبل الإدراج أو وقت الاستعلام بدلاً من الاعتماد على ذاكرة تخزين مؤقت مُحمّاة في مسار الإدخال.
مراقبة استخدام القواميس
تتبّع استهلاك الذاكرة وسلامة القواميس عبر جدولsystem.dictionaries:
bytes_allocated— مقدار الذاكرة التي يستهلكها القاموس. تخزّن القواميس البيانات بصيغة غير مضغوطة، لذا قد تكون هذه القيمة أكبر بكثير من حجم الجدول المضغوط.hit_rateوfound_rate— مفيدان لتقييم مدى فعالية تخطيطcache.last_exception— راجِع هذا الحقل عندما يفشل القاموس في التحميل أو التحديث.