إعدادات الجلسة join_*

هذه الإعدادات متوفرة في system.settings، وهي مُولَّدة تلقائيًا من الملف المصدر. يحدد خوارزمية JOIN المستخدمة. يمكن تحديد عدة خوارزميات، وتُختار الخوارزمية المناسبة لكل استعلام بحسب kind/strictness وtable engine. القيم الممكنة:

• grace_hash

تُستخدم Grace hash join. توفّر Grace hash خيار خوارزمية يتيح تنفيذ joins معقدة بكفاءة مع الحد من استهلاك الذاكرة. في المرحلة الأولى من grace join، يُقرأ الجدول الأيمن ويُقسَّم إلى N من الـ buckets وفقًا لقيمة hash الخاصة بـ key columns (في البداية تكون N هي grace_hash_join_initial_buckets). ويُنفَّذ ذلك بطريقة تضمن إمكانية معالجة كل bucket بشكل مستقل. تُضاف rows من الـ bucket الأولى إلى hash table داخل الذاكرة، بينما تُحفَظ البقية على disk. وإذا تجاوز نمو hash table مقدار memory limit (على سبيل المثال كما هو محدد بواسطة max_bytes_in_join)، فسيُزاد عدد الـ buckets ويُعاد تحديد الـ bucket المخصصة لكل row. وأي rows لا تنتمي إلى الـ bucket الحالية تُفرَّغ وتُعاد إعادة تخصيصها. يدعم INNER/LEFT/RIGHT/FULL ALL/ANY JOIN.

• hash

تُستخدم Hash join algorithm. وهي أكثر تطبيقات join عمومية، إذ تدعم جميع التركيبات من kind وstrictness، كما تدعم عدة join keys مدمجة باستخدام OR في قسم JOIN ON. عند استخدام خوارزمية hash، يُحمَّل الجزء الأيمن من JOIN إلى RAM.

• parallel_hash

نوع مختلف من join hash يقسّم البيانات إلى buckets ويبني عدة hash tables بدلًا من واحدة، بالتوازي، لتسريع هذه العملية. عند استخدام خوارزمية parallel_hash، يُحمَّل الجزء الأيمن من JOIN إلى RAM.

• partial_merge

نوع مختلف من sort-merge algorithm، حيث يُفرَز الجدول الأيمن بالكامل فقط. لا يُدعَم RIGHT JOIN وFULL JOIN إلا مع strictness من نوع ALL (SEMI وANTI وANY وASOF غير مدعومة). عند استخدام خوارزمية partial_merge، يقوم ClickHouse بفرز البيانات وتفريغها إلى disk. تختلف خوارزمية partial_merge في ClickHouse قليلًا عن التطبيق التقليدي. أولًا، يفرز ClickHouse الجدول الأيمن حسب join keys على هيئة blocks، ثم ينشئ min-max index للـ blocks المرتبة. بعد ذلك يفرز أجزاءً من الجدول الأيسر حسب join key ويجري join عليها مع الجدول الأيمن. ويُستخدم min-max index أيضًا لتخطي blocks غير اللازمة من الجدول الأيمن.

• direct

تجري خوارزمية direct (المعروفة أيضًا باسم nested loop) عملية lookup في الجدول الأيمن باستخدام rows من الجدول الأيسر كمفاتيح. وهي مدعومة في أنواع تخزين خاصة مثل Dictionary وEmbeddedRocksDB وtables من نوع MergeTree. بالنسبة إلى MergeTree tables، تدفع الخوارزمية مرشحات join key مباشرةً إلى storage layer. وقد يكون ذلك أكثر كفاءة عندما يتمكن المفتاح من استخدام primary key index الخاص بالجدول في عمليات lookup، وإلا فإنها تُجري فحصًا كاملًا للجدول الأيمن لكل block من الجدول الأيسر. يدعم INNER وLEFT joins، وjoin keys أحادية العمود للمساواة فقط، من دون شروط أخرى.

• auto

عند ضبطه على auto، تتم تجربة join hash أولًا، ثم يجري التبديل تلقائيًا أثناء التنفيذ إلى خوارزمية أخرى إذا تم تجاوز memory limit.

• full_sorting_merge

Sort-merge algorithm مع فرز كامل للجداول الموصولة قبل تنفيذ join.

• prefer_partial_merge

يحاول ClickHouse دائمًا استخدام join partial_merge إن أمكن، وإلا يستخدم hash. Deprecated، وهو مماثل لـ partial_merge,hash.

• default (مهمل)

قيمة قديمة، يُرجى عدم استخدامها بعد الآن. تماثل direct,hash، أي جرّب استخدام direct join وhash join (بهذا الترتيب). يغيّر سلوك عمليات JOIN ذات الصرامة ANY عندما يحتوي الجدول الأيمن على أكثر من صف مطابق واحد للمفتاح. القيم الممكنة:

• 0 — إذا كان الجدول الأيمن يحتوي على أكثر من صف مطابق واحد، فلن يُضم إلا أول صف يتم العثور عليه.
• 1 — إذا كان الجدول الأيمن يحتوي على أكثر من صف مطابق واحد، فلن يُضم إلا آخر صف يتم العثور عليه.

انظر أيضًا:

• عبارة JOIN
• محرك الجدول Join
• join_default_strictness

يضبط درجة الصرامة الافتراضية لعبارات JOIN. القيم الممكنة:

• ALL — إذا كان الجدول الأيمن يحتوي على عدة صفوف متطابقة، ينشئ ClickHouse حاصلًا كارتيسيًا من الصفوف المتطابقة. وهذا هو سلوك JOIN المعتاد في standard SQL.
• ANY — إذا كان الجدول الأيمن يحتوي على عدة صفوف متطابقة، فلا يُضم سوى أول صف يُعثر عليه. وإذا كان الجدول الأيمن يحتوي على صف متطابق واحد فقط، فستكون نتائج ANY وALL متطابقة.
• ASOF — لربط التسلسلات ذات المطابقة غير المؤكدة.
• Empty string — إذا لم يتم تحديد ALL أو ANY في الاستعلام، يطرح ClickHouse استثناء.

يحدّ من عدد الملفات المسموح به للفرز المتوازي في عمليات MergeJoin عند تنفيذها على القرص. كلما زادت قيمة الإعداد، زاد استخدام RAM وقلّت الحاجة إلى عمليات الإدخال/الإخراج على القرص. القيم الممكنة:

• أي عدد صحيح موجب يبدأ من 2.

الحد الأدنى لمتوسط عدد الصفوف لكل مفتاح في الجدول الأيمن، لتحديد ما إذا كان سيتم إخراج النتائج وفق قائمة الصفوف في hash join. يحدّد هذا الإعداد الإجراء الذي ينفّذه ClickHouse عندما تصل عملية join إلى أيٍّ من الحدود التالية:

• max_bytes_in_join
• max_rows_in_join

لا يُراعى هذا الإعداد إلا مع قيم join_algorithm hash وparallel_hash. أما الخوارزميات الأخرى (مثل partial_merge وgrace_hash وauto) فتتعامل مع هذه الحدود بطريقة مختلفة — مثل تفريغ البيانات إلى القرص، أو إعادة التقسيم، أو تبديل الاستراتيجية — راجع join_algorithm. القيم الممكنة:

• THROW — يطرح ClickHouse استثناءً ويوقف الاستعلام.
• BREAK — يوقف ClickHouse الاستعلام ولا يطرح استثناءً.

القيمة الافتراضية: THROW. انظر أيضًا

• عبارة JOIN
• محرك الجدول Join

يحدّد هذا الإعداد سلوك JOIN. عند دمج الجداول، قد تظهر خلايا فارغة. ويملؤها ClickHouse بطرق مختلفة وفقًا لهذا الإعداد. Possible values:

• 0 — تُملأ الخلايا الفارغة بالقيمة الافتراضية لنوع الحقل المقابل.
• 1 — يتصرف JOIN بالطريقة نفسها كما في standard SQL. ويُحوَّل نوع الحقل المقابل إلى Nullable، وتُملأ الخلايا الفارغة بـ NULL.