تتناول هذه الصفحة إرشادات عملية لاختيار نمط تخطيط القاموس المناسب، وفهم الحالات التي تتفوق فيها القواميس على عمليات JOIN (ومتى لا يحدث ذلك)، ومراقبة استخدام القواميس.
للحصول على مقدمة عن القواميس مع أمثلة عملية، راجع الدليل الرئيسي للقواميس.
متى تستخدم القواميس بدلًا من عمليات JOIN
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 — لا يخزّن إلا المفاتيح كثيرة الاستخدام. وهو مفيد عندما لا تتسع الذاكرة لمجموعة البيانات الكاملة، لكن قد تعود عمليات البحث إلى المصدر عند عدم العثور على المفتاح في cache. لا يُنصح به للأحمال الحساسة لزمن الاستجابة.direct — يستعلم المصدر عند كل عملية بحث من دون أي تخزين داخل الذاكرة. استخدمه عندما تتغير البيانات بوتيرة عالية جدًا بحيث لا يناسبها التخزين في cache، أو عندما يكون القاموس كبيرًا جدًا بحيث لا يتسع في الذاكرة.
تتبّع استهلاك الذاكرة وسلامة القواميس عبر جدول system.dictionaries:
الأعمدة الرئيسية:
bytes_allocated — مقدار الذاكرة التي يستهلكها القاموس. تخزّن القواميس البيانات بصيغة غير مضغوطة، لذا قد تكون هذه القيمة أكبر بكثير من حجم الجدول المضغوط.hit_rate وfound_rate — مفيدان لتقييم مدى فعالية تخطيط cache.last_exception — راجِع هذا الحقل عندما يفشل القاموس في التحميل أو التحديث.
آخر تعديل في ٢ يوليو ٢٠٢٦
