> ## Documentation Index
> Fetch the complete documentation index at: https://clickhouse.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# أفضل ممارسات القواميس

> إرشادات لاختيار أنماط تخطيط القواميس، ومتى تستخدم القواميس بدلًا من عمليات JOIN، وكيفية مراقبة استخدام القواميس.

تتناول هذه الصفحة إرشادات عملية لاختيار نمط تخطيط القاموس المناسب، وفهم الحالات التي تتفوق فيها القواميس على عمليات JOIN (ومتى لا يحدث ذلك)، ومراقبة استخدام القواميس.

للحصول على مقدمة عن القواميس مع أمثلة عملية، راجع [الدليل الرئيسي للقواميس](/docs/ar/concepts/features/dictionaries/index).

<div id="when-to-use-dictionaries-vs-joins">
  ## متى تستخدم القواميس بدلًا من عمليات JOIN
</div>

تكون القواميس الأنسب عندما يكون أحد طرفَي عملية JOIN جدولًا مرجعيًا يمكن احتواؤه في الذاكرة. في عملية JOIN القياسية، ينشئ ClickHouse جدول تجزئة من الجانب الأيمن قبل فحصه باستخدام الجانب الأيسر — حتى لو جرى لاحقًا استبعاد معظم الصفوف بواسطة عوامل تصفية `WHERE`. وعلى الرغم من أن الإصدارات الحديثة (24.12+) تدفع عوامل التصفية قبل عمليات JOIN في كثير من الحالات، فإن ذلك لا يلغي دائمًا هذا الحمل الإضافي. أما عند استخدام قاموس، فتستدعي `dictGet` مباشرةً، لذلك لا تحدث عمليات بحث إلا للصفوف التي اجتازت التصفية بالفعل.

ومع ذلك، لا تكون `dictGet` الخيار المناسب دائمًا. فإذا كنت بحاجة إلى استدعاء `dictGet` على نسبة كبيرة من صفوف جدول — على سبيل المثال، ضمن شرط `WHERE` مثل `dictGet('dict', 'elevation', id) > 1800` — فقد يكون من الأفضل استخدام عمود عادي مع فهارس أصلية. يستطيع ClickHouse استخدام `PREWHERE` لتخطي granules لعمود عادي، لكن `dictGet` تُقيَّم صفًا بصف من دون دعم للفهرسة.

وكقاعدة عامة:

* استخدم القواميس لاستبدال عمليات JOIN مع جداول الأبعاد الصغيرة عندما يكون مفتاح بحث متاحًا بالفعل.
* استخدم الأعمدة العادية والفهارس عند التصفية بناءً على القيمة المسترجعة عبر عدد كبير من الصفوف.

<div id="choosing-a-layout">
  ## اختيار تخطيط
</div>

يتحكم البند `LAYOUT` في بنية البيانات الداخلية للقاموس. جميع التخطيطات المتاحة موثقة في [مرجع التخطيطات](/docs/ar/reference/statements/create/dictionary/layouts/overview#storing-dictionaries-in-memory).

عند اختيار تخطيط، استخدم الإرشادات التالية:

* **`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، أو عندما يكون القاموس كبيرًا جدًا بحيث لا يتسع في الذاكرة.

<div id="monitoring-dictionary-usage">
  ## مراقبة استخدام القواميس
</div>

تتبّع استهلاك الذاكرة وسلامة القواميس عبر جدول [`system.dictionaries`](/docs/ar/reference/system-tables/dictionaries):

```sql theme={null}
SELECT
    name,
    status,
    element_count,
    formatReadableSize(bytes_allocated) AS size,
    query_count,
    hit_rate,
    found_rate,
    last_exception
FROM system.dictionaries
```

الأعمدة الرئيسية:

* `bytes_allocated` — مقدار الذاكرة التي يستهلكها القاموس. تخزّن القواميس البيانات بصيغة غير مضغوطة، لذا قد تكون هذه القيمة أكبر بكثير من حجم الجدول المضغوط.
* `hit_rate` و`found_rate` — مفيدان لتقييم مدى فعالية تخطيط `cache`.
* `last_exception` — راجِع هذا الحقل عندما يفشل القاموس في التحميل أو التحديث.