القيود على الإعدادات

في ClickHouse، تشير "القيود" المفروضة على الإعدادات إلى الحدود والقواعد التي يمكنك تعيينها للإعدادات. ويمكن تطبيق هذه القيود للحفاظ على الاستقرار والأمان وسهولة التنبؤ بسلوك قاعدة البيانات.

يمكن تعريف القيود على الإعدادات في قسم ملف التعريف ضمن ملف الإعداد user.xml. وهي تمنع المستخدمين من تغيير بعض الإعدادات باستخدام تعليمة SET.

تُعرَّف القيود على النحو التالي:

<profiles>
  <user_name>
    <constraints>
      <setting_name_1>
        <min>lower_boundary</min>
      </setting_name_1>
      <setting_name_2>
        <max>upper_boundary</max>
      </setting_name_2>
      <setting_name_3>
        <min>lower_boundary</min>
        <max>upper_boundary</max>
      </setting_name_3>
      <setting_name_4>
        <readonly/>
      </setting_name_4>
      <setting_name_5>
        <min>lower_boundary</min>
        <max>upper_boundary</max>
        <changeable_in_readonly/>
      </setting_name_5>
      <setting_name_6>
        <min>lower_boundary</min>
        <max>upper_boundary</max>
        <disallowed>value1</disallowed>
        <disallowed>value2</disallowed>
        <disallowed>value3</disallowed>
        <changeable_in_readonly/>
      </setting_name_6>
    </constraints>
  </user_name>
</profiles>

إذا حاول المستخدم انتهاك القيود، فسيُطلَق استثناء ويظل الإعداد دون تغيير.

هناك عدة أنواع من القيود التي يدعمها ClickHouse:

• min
• max
• disallowed
• readonly (بالاسم المستعار const)
• changeable_in_readonly

يحدّد القيدان min وmax الحدين الأدنى والأقصى لإعداد رقمي، ويمكن استخدامهما معًا.

يمكن استخدام القيد disallowed لتحديد قيمة أو قيم معيّنة لا ينبغي السماح بها لإعداد محدد.

ينصّ القيد readonly أو const على أن المستخدم لا يمكنه تغيير الإعداد المقابل مطلقًا.

يتيح نوع القيد changeable_in_readonly للمستخدمين تغيير الإعداد ضمن نطاق min/max حتى إذا كان الإعداد readonly مضبوطًا على 1، وإلا فلن يُسمح بتغيير الإعدادات في وضع readonly=1.

إذا كان هناك عدة ملفات تعريف نشطة لمستخدم، فستُدمَج القيود. تعتمد عملية الدمج على settings_constraints_replace_previous:

• true (موصى به): تُستبدَل القيود الخاصة بالإعداد نفسه أثناء الدمج، بحيث يُستخدَم القيد الأخير وتُتجاهَل جميع القيود السابقة. ويشمل ذلك الحقول غير المعيّنة في القيد الجديد.
• false (افتراضي): تُدمَج القيود الخاصة بالإعداد نفسه بطريقة يُؤخَذ فيها كل نوع من القيود غير المعيّنة من ملف التعريف السابق، ويُستبدَل كل نوع من القيود المعيّنة بالقيمة من ملف التعريف الجديد.

يتم تفعيل وضع القراءة فقط بواسطة الإعداد readonly، ويجب عدم الخلط بينه وبين نوع القيد readonly:

• readonly=0: لا توجد أي قيود على وضع القراءة فقط.
• readonly=1: يُسمح فقط باستعلامات القراءة، ولا يمكن تغيير الإعدادات إلا إذا كان changeable_in_readonly مُعيَّنًا.
• readonly=2: يُسمح فقط باستعلامات القراءة، لكن يمكن تغيير الإعدادات، باستثناء الإعداد readonly نفسه.

ليتضمّن الملف users.xml الأسطر التالية:

<profiles>
  <default>
    <max_memory_usage>10000000000</max_memory_usage>
    <force_index_by_date>0</force_index_by_date>
    ...
    <constraints>
      <max_memory_usage>
        <min>5000000000</min>
        <max>20000000000</max>
      </max_memory_usage>
      <force_index_by_date>
        <readonly/>
      </force_index_by_date>
    </constraints>
  </default>
</profiles>

ستُرجِع جميع الاستعلامات التالية استثناءات:

SET max_memory_usage=20000000001;
SET max_memory_usage=4999999999;
SET force_index_by_date=1;

Code: 452, e.displayText() = DB::Exception: Setting max_memory_usage should not be greater than 20000000000.
Code: 452, e.displayText() = DB::Exception: Setting max_memory_usage should not be less than 5000000000.
Code: 452, e.displayText() = DB::Exception: Setting force_index_by_date should not be changed.

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

يجب أن يُسبق اسم إعداد MergeTree بالبادئة merge_tree_ عند الإشارة إليه في قسم <constraints>.

يمكنك منع إنشاء جداول جديدة مع تحديد storage_policy صراحةً

<profiles>
  <default>
    <constraints>
      <merge_tree_storage_policy>
        <const/>
      </merge_tree_storage_policy>
    </constraints>
  </default>
</profiles>