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

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

​

نظرة عامة

في 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.

لا يكون changeable_in_readonly مدعومًا إلا إذا كان settings_constraints_replace_previous مفعّلًا:

<access_control_improvements>
  <settings_constraints_replace_previous>true</settings_constraints_replace_previous>
</access_control_improvements>

​

لا تجعل readonly قابلاً للتغيير في وضع القراءة فقط

أبقِ readonly خارج قائمة changeable_in_readonly في كل ملف تعريف، بما في ذلك ملفات التعريف التي لا تُعيّنها لأي أحد: إذ يمكن لأي session اختيار ملف التعريف باسمه.

لا تضع علامة changeable_in_readonly على readonly نفسه. فإن فعلت، فإن أي session تبدأ بـ readonly = 1 يمكنها تنفيذ SET readonly = 0 واستعادة القدرة على تنفيذ استعلامات الكتابة التي تسمح بها امتيازاتها الحالية أصلاً، ما لم يحظر القيد نفسه القيمة 0 أيضاً.

ولهذا أهمية بالنسبة لكل ملف تعريف تُعرّفه، وليس فقط الملفات التي تُعيّنها:

• لا يخضع SET profile لفحص الوصول، لذا يمكن لأي session اختيار أي ملف تعريف باسمه. ويظل ملف التعريف متاحاً حتى إن لم تُعيّنه لأي أحد، وإن كان ما يغيّره حينئذٍ يظل خاضعاً للفحص وفق القيود النشطة مسبقاً في تلك الـ session.
• عبر HTTP، لا تُفرَض القيمة readonly = 2 على طلبات GET إلا إذا كانت القيمة الفعلية ستكون 0 في الأصل. لذا فإن أي ملف تعريف يضبط readonly = 1 ويسمح في الوقت نفسه بتغيير readonly في وضع القراءة فقط يُبطل هذه الحماية، إذ يمكن لطلب GET أن يحوّلها إلى 0 وينفّذ الكتابة.

​

ملفات تعريف القيود المتعددة

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

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

​

وضع القراءة فقط

يُفعَّل وضع القراءة فقط عبر الإعداد readonly، ولا ينبغي الخلط بينه وبين نوع القيد readonly. فعندما تكون readonly = 1، يبقى بالإمكان تغيير إعدادٍ كان سيُرفض لولا ذلك، إذا سمح بذلك القيد changeable_in_readonly. ولمعرفة دلالة قيم هذا الإعداد، راجع مرجع الإعدادات؛ ولمعرفة أصناف الاستعلامات التي تسمح بها كل قيمة، وكيفية ضبطها عبر HTTP interface، راجع أذونات الاستعلامات.

​

مثال

ليتضمّن الملف 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.

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

​

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

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

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

​

مثال

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

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