Skip to main content
هذه الإعدادات متاحة في system.settings، وهي مُولَّدة تلقائيًا من ملف المصدر.

​
load_balancing

يحدّد خوارزمية اختيار النسخ المتماثلة المستخدمة في معالجة الاستعلامات الموزعة. يدعم ClickHouse خوارزميات اختيار النسخ المتماثلة التالية: انظر أيضًا:

​
عشوائي (الخيار الافتراضي)

يُحصى عدد الأخطاء لكل نسخة متماثلة. ويُرسَل الاستعلام إلى النسخة المتماثلة الأقل أخطاءً، وإذا وُجدت عدة نسخ من هذا النوع، فيُرسَل إلى أيٍّ منها. العيوب: لا يُراعى قرب الخادم؛ وإذا كانت النسخ المتماثلة تحتوي على بيانات مختلفة، فستحصل أيضًا على بيانات مختلفة.

​
أقرب اسم مضيف

يُحصى عدد الأخطاء لكل نسخة متماثلة. وكل 5 دقائق، يُقسَم عدد الأخطاء قسمةً صحيحة على 2. وبذلك، يُحسَب عدد الأخطاء للفترة الأخيرة باستخدام التنعيم الأسي. إذا كانت هناك نسخة متماثلة واحدة لديها أقل عدد من الأخطاء (أي إن الأخطاء حدثت مؤخرًا على النسخ المتماثلة الأخرى)، فيُرسَل الاستعلام إليها. وإذا كانت هناك عدة نسخ متماثلة لها أقل عدد من الأخطاء، فيُرسَل الاستعلام إلى النسخة المتماثلة التي يكون اسم مضيفها الأكثر تشابهًا مع اسم مضيف الخادم في ملف الإعدادات (أي وفقًا لعدد الأحرف المختلفة في المواضع نفسها، حتى الحد الأدنى لطول اسمي المضيفين). على سبيل المثال، يختلف example01-01-1 و example01-01-2 في موضع واحد، بينما يختلف example01-01-1 و example01-02-2 في موضعين. قد تبدو هذه الطريقة بدائية، لكنها لا تتطلب بيانات خارجية عن طوبولوجيا الشبكة، كما أنها لا تقارن عناوين IP، وهو ما سيكون معقدًا في حالة عناوين IPv6 لدينا. وهكذا، إذا كانت هناك نسخ متماثلة متكافئة، فتُفضَّل الأقرب اسمًا. ويمكننا أيضًا افتراض أنه عند إرسال استعلام إلى الخادم نفسه، وفي غياب حالات الفشل، فإن الاستعلام الموزع سيتجه أيضًا إلى الخوادم نفسها. لذلك، حتى إذا وُضعت بيانات مختلفة على النسخ المتماثلة، فسيُرجِع الاستعلام في الغالب النتائج نفسها.

​
مسافة ليفنشتاين لاسم المضيف

تمامًا مثل nearest_hostname، لكنه يُجري المقارنة بين أسماء المضيفين باستخدام مسافة ليفنشتاين. على سبيل المثال:

​
أطول بادئة مشتركة لاسم المضيف

تمامًا مثل nearest_hostname، لكن تُفضَّل النسخة المتماثلة التي يشترك اسم المضيف الخاص بها مع اسم المضيف المحلي في أطول بادئة مشتركة (وكلما كانت البادئة المشتركة أطول، ارتفعت الأولوية). وعلى خلاف nearest_hostname، الذي يحسب الأحرف المختلفة موضعًا بموضع، لا تلتبس هذه الاستراتيجية بأسماء المضيفين التي تختلف أطوال مقاطعها الرقمية. على سبيل المثال، بالنسبة إلى اسم المضيف المحلي sfe301:
هنا يُفضَّل sfe10101 لأنه يملك أطول بادئة مشتركة مع sfe301 (sfe، بطول 3). تُختار النسخ المتماثلة ذات أطوال البادئات المشتركة المتساوية عشوائيًا. وعلى وجه الخصوص، عندما لا تشترك أي نسخة متماثلة في أي بادئة مع اسم المضيف المحلي (أي عندما تكون جميع أطوال البادئات المشتركة صفرًا)، تعمل هذه الاستراتيجية تمامًا مثل random.

​
أطول لاحقة مشتركة لاسم المضيف

تمامًا مثل hostname_longest_common_prefix، ولكن تُقارَن أطول لاحقة مشتركة بدلًا من البادئة. ويكون هذا مفيدًا عندما تكون هوية مركز البيانات مُرمَّزة في لاحقة اسم المضيف. على سبيل المثال، بالنسبة إلى اسم المضيف المحلي et46gtghn.qc.localdomain:
هنا يُفضَّل ab999.qc.localdomain لأنه يشارك et46gtghn.qc.localdomain أطول لاحقة مشتركة (.qc.localdomain، بطول 15). تُختار النسخ المتماثلة ذات أطوال اللواحق المشتركة المتساوية عشوائيًا. وعلى وجه الخصوص، عندما لا تشترك أي نسخة متماثلة مع اسم المضيف المحلي في أي لاحقة (أي تكون جميع أطوال اللواحق المشتركة صفرًا)، فإن هذه الاستراتيجية تعمل تمامًا مثل random.

​
بالترتيب

يُجرى الوصول إلى النُسخ المتماثلة التي لديها العدد نفسه من الأخطاء بالترتيب نفسه الذي حُدِّدت به في التهيئة. تكون هذه الطريقة مناسبة عندما تعرف بدقة أي نسخة متماثلة هي المفضلة.

​
الأول أو عشوائي

تختار هذه الخوارزمية النسخة المتماثلة الأولى في المجموعة، أو نسخة متماثلة عشوائية إذا كانت الأولى غير متاحة. وهي فعّالة في إعدادات البنية ذات النسخ المتماثلة المتقاطعة، لكنها غير مفيدة في التكوينات الأخرى. تحل خوارزمية first_or_random مشكلة خوارزمية in_order. فمع in_order، إذا تعطلت إحدى النسخ المتماثلة، تتحمل النسخة التالية عبئًا مضاعفًا، بينما تتعامل النسخ المتماثلة المتبقية مع المقدار المعتاد من الحركة. وعند استخدام خوارزمية first_or_random، يُوزَّع الحمل بالتساوي بين النسخ المتماثلة التي لا تزال متاحة. يمكن تحديد النسخة المتماثلة الأولى صراحةً باستخدام الإعداد load_balancing_first_offset. ويمنح ذلك تحكمًا أكبر في إعادة موازنة أعباء عمل الاستعلامات بين النسخ المتماثلة.

​
التناوب الدوري

تستخدم هذه الخوارزمية سياسة التناوب الدوري بين النسخ المتماثلة التي لها العدد نفسه من الأخطاء (ولا تُحتسب إلا الاستعلامات التي تتبع سياسة round_robin).

​
load_balancing_first_offset

أي نسخة متماثلة يُفضَّل إرسال query إليها عند استخدام استراتيجية load balancing ‏FIRST_OR_RANDOM.
آخر تعديل في ٢٣ يوليو ٢٠٢٦