ملفات التهيئة

ملفات التهيئة وملفات التعريف للإعدادات المستندة إلى XML غير مدعومة في ClickHouse Cloud. لذلك، في ClickHouse Cloud، لن تجد ملف config.xml. وبدلًا من ذلك، يجب استخدام أوامر SQL لإدارة الإعدادات من خلال ملفات تعريف الإعدادات.للمزيد من التفاصيل، راجع “تهيئة الإعدادات”

يمكن تهيئة ClickHouse server باستخدام ملفات تهيئة بصيغة XML أو YAML. في معظم أنواع التثبيت، يعمل ClickHouse server باستخدام /etc/clickhouse-server/config.xml بوصفه ملف التهيئة الافتراضي، ولكن يمكن أيضًا تحديد موقع ملف التهيئة يدويًا عند بدء تشغيل الخادم باستخدام خيار سطر الأوامر --config-file أو -C. وفي حال عدم تحديد أيٍّ من هذين الخيارين، يبحث الخادم في دليل العمل الحالي عن config.xml ثم config.yaml ثم config.yml بهذا الترتيب، ويستخدم أول ملف يعثر عليه. وإذا لم يُعثر على أيٍّ منها، يبدأ الخادم بالتهيئة المضمَّنة في الملف التنفيذي. أما الملف المحدد عبر --config-file فيُستخدم كما هو: فإذا لم يكن موجودًا، يُبلغ الخادم عن خطأ بدلًا من البحث عن ملف بامتداد مختلف. ويتبع clickhouse-keeper القواعد نفسها مع keeper_config.xml وkeeper_config.yaml وkeeper_config.yml. يمكن وضع ملفات تهيئة إضافية داخل الدليل config.d/ نسبةً إلى ملف التهيئة الرئيسي، على سبيل المثال داخل الدليل /etc/clickhouse-server/config.d/. تُدمج الملفات الموجودة في هذا الدليل مع التهيئة الرئيسية في خطوة معالجة مسبقة قبل تطبيق التهيئة في ClickHouse server. تُدمج أجزاء التهيئة بترتيب معجمي وفقًا لمساراتها الكاملة. بالنسبة إلى الملفات الموجودة في الدليل القياسي config.d/، يعادل هذا الترتيب حسب اسم الملف. يُدمج أيضًا الدليل القديم conf.d/؛ ولأن conf.d يسبق config.d في الترتيب، تُعالج جميع أجزائه أولًا عند وجود الدليلين. ولتسهيل التحديثات وتحسين التنظيم إلى وحدات، من أفضل الممارسات إبقاء ملف config.xml الافتراضي دون تعديل، ووضع أي تخصيصات إضافية في config.d/. توجد تهيئة ClickHouse Keeper في /etc/clickhouse-keeper/keeper_config.xml. وبالمثل، يجب وضع ملفات التهيئة الإضافية الخاصة بـ Keeper في /etc/clickhouse-keeper/keeper_config.d/. يمكن المزج بين ملفات تهيئة XML وYAML، فعلى سبيل المثال يمكن أن يكون لديك ملف تهيئة رئيسي config.xml وملفات تهيئة إضافية هي config.d/network.xml وconfig.d/timezone.yaml وconfig.d/keeper.yaml. لا يُدعم المزج بين XML وYAML داخل ملف تهيئة واحد. يجب أن تستخدم ملفات تهيئة XML الوسم الأعلى مستوى <clickhouse>...</clickhouse>. في ملفات تهيئة YAML، يكون clickhouse: اختياريًا، وإذا كان غير موجود، فإن المُحلِّل يدرجه تلقائيًا.

دمج ملفات الإعداد

يُدمَج ملفا إعداد (عادةً ملف الإعداد الرئيسي وملف إعداد آخر من config.d/) كما يلي:

إذا ظهرت عقدة (أي path يؤدي إلى عنصر) في كلا الملفين ولم تكن تحتوي على السمات replace أو remove، فتُضمَّن في ملف الإعداد المدمج، كما تُضمَّن العناصر الفرعية من كلتا العقدتين وتُدمَج تكراريًا.
إذا كانت إحدى العقدتين تحتوي على السمة replace، فتُضمَّن في ملف الإعداد المدمج، ولكن لا تُضمَّن إلا العناصر الفرعية من العقدة التي تحتوي على السمة replace.
إذا كانت إحدى العقدتين تحتوي على السمة remove، فلا تُضمَّن العقدة في ملف الإعداد المدمج (وإذا كانت موجودة بالفعل، فتُحذَف).

على سبيل المثال، إذا كان لديك ملفا الإعداد التاليان:

config.xml

<clickhouse>
    <config_a>
        <setting_1>1</setting_1>
    </config_a>
    <config_b>
        <setting_2>2</setting_2>
    </config_b>
    <config_c>
        <setting_3>3</setting_3>
    </config_c>
</clickhouse>

config.d/other_config.xml

<clickhouse>
    <config_a>
        <setting_4>4</setting_4>
    </config_a>
    <config_b replace="replace">
        <setting_5>5</setting_5>
    </config_b>
    <config_c remove="remove">
        <setting_6>6</setting_6>
    </config_c>
</clickhouse>

سيكون ملف التهيئة الناتج بعد الدمج كما يلي:

<clickhouse>
    <config_a>
        <setting_1>1</setting_1>
        <setting_4>4</setting_4>
    </config_a>
    <config_b>
        <setting_5>5</setting_5>
    </config_b>
</clickhouse>

الاستبدال باستخدام متغيرات البيئة وعُقد ZooKeeper

لتحديد أن قيمة أحد العناصر يجب أن تُستبدل بقيمة متغير بيئة، يمكنك استخدام السمة from_env. على سبيل المثال، مع متغير البيئة $MAX_QUERY_SIZE = 150000:

<clickhouse>
    <profiles>
        <default>
            <max_query_size from_env="MAX_QUERY_SIZE"/>
        </default>
    </profiles>
</clickhouse>

سيكون التكوين الناتج كما يلي:

<clickhouse>
    <profiles>
        <default>
            <max_query_size>150000</max_query_size>
        </default>
    </profiles>
</clickhouse>

يمكن فعل الأمر نفسه باستخدام from_zk (عقدة ZooKeeper):

<clickhouse>
    <postgresql_port from_zk="/zk_configs/postgresql_port"/>
</clickhouse>

# clickhouse-keeper-client
/ :) touch /zk_configs
/ :) create /zk_configs/postgresql_port "9005"
/ :) get /zk_configs/postgresql_port
9005

لينتج عن ذلك الإعداد التالي:

<clickhouse>
    <postgresql_port>9005</postgresql_port>
</clickhouse>

كيفية تفسير القيم

يختلف from_env وfrom_zk في طريقة تفسير القيمة المستبدلة:

تُعامل القيمة المستبدلة مباشرةً عبر from_env كنص حرفي. ويُجرى إفلات محارف XML الخاصة، مثل & و< و>، تلقائيًا؛ لذا يمكن لمتغير البيئة أن يحتوي على أي قيمة قابلة للتمثيل في XML، مثل a&b<c>d، دون إفساد التهيئة (انظر الملاحظة أدناه بشأن محارف التحكم غير المسموح بها في XML). ولا تُفسَّر القيمة المباشرة على أنها XML مطلقًا، حتى لو بدت كمقطع XML: فالقيمة <a>1</a> تُدرج بوصفها النص الحرفي <a>1</a>. وينطبق ذلك أيضًا عند وضع السمة المباشرة على عنصر حاوٍ عادي مثل <profiles from_env="…"/>: إذ يجب نقل أي استبدال قائم لشجرة XML فرعية إلى <profiles><include from_env="…"/></profiles>. أما <include from_env="…"/> فيختلف حفاظًا على التوافق مع الإصدارات السابقة: فهو يحلّل متغير البيئة بوصفه مقطع XML ويُدرج عناصره الفرعية في العنصر الأصل.
يتوقف تفسير القيمة المستبدلة عبر from_zk على ما إذا كانت تبدأ بـ<. فالقيمة التي تبدأ بـ< تُحلَّل دائمًا بوصفها مقطع XML؛ وبهذه الطريقة تُدرج شجرة فرعية في أي عنصر، سواء أكان <include from_zk="…"/> البنيوي أم عنصرًا حاويًا عاديًا مثل <profiles from_zk="…"/>. وقد أُبقي على هذا السلوك حفاظًا على التوافق مع الإصدارات السابقة، إذ كانت الإصدارات الأقدم تفسّر قيم from_zk دائمًا على أنها XML. أما القيمة التي لا تبدأ بـ< فلا تُحلَّل بوصفها شجرة YAML فرعية إلا باستخدام الصيغة الصريحة <include from_zk="…" yaml="true"/>؛ وعندئذٍ تُرفض التهيئة إذا كان YAML غير صالح. وتتيح السمة yaml="true" تحليل YAML أينما استُخدمت صيغة <include> العامة، بما في ذلك داخل عنصر طرفي؛ لذا لا تستخدمها لقيمة إعداد حرفية أو لـSecret. وفي غياب yaml="true"، تُعامل القيمة التي لا تبدأ بـ< كنص حرفي، حتى عند استخدامها بصيغة الاستبدال العامة للعنصر الطرفي <password><include from_zk="/secret"/></password>. وبذلك تُحفَظ القيم التي تحتوي عرضًا على صيغة YAML أو على YAML غير صالح، مثل abc # rotated أو [1. وفي هذه الصيغة، لا تُحفَظ البايتات كما هي إلا إذا جاء <include> ضمن السطر نفسه دون عقد نصية تتضمن مسافات بيضاء حوله؛ لذا يُفضَّل استخدام الصيغة المباشرة <password from_zk="…"/> مع قيم Secret وإعدادات العناصر الطرفية التي تتطلب الحفاظ على البايتات كما هي. وعلى أي عنصر آخر — سواء أكان عنصرًا طرفيًا يُستبدل مثل <some_setting from_zk="…"/> أو <password from_zk="…"/>، أم عنصرًا حاويًا عاديًا مثل <profiles from_zk="…"/> — تُحفَظ القيمة التي لا تبدأ بـ< كنص حرفي ببايتاتها الأصلية كما هي (مع إفلات محارف XML الخاصة تلقائيًا، كما في from_env). لذا تبقى قيمة مثل abc: def نصًا حرفيًا abc: def بدلًا من أن تصبح عنصرًا فرعيًا <abc>def</abc>. ولإدراج شجرة فرعية في عنصر عادي (بدلًا من <include> بنيوي)، قدّمها بوصفها مقطع XML (أي قيمة تبدأ بـ<).

يجب أن تكون القيم الحرفية نصًا صالحًا وفق XML 1.0يحافظ الاستبدال الحرفي (from_env، أو قيمة from_zk لعنصر طرفي لا تبدأ بـ<) على بايتات القيمة كما هي لكل محرف يمكن تمثيله كنص في XML 1.0. أما محارف التحكم غير المسموح بها في XML 1.0 — وهي 0x00–0x08 و0x0B و0x0C و0x0E–0x1F — فلا يمكن تمريرها عبر تهيئة XML إطلاقًا (إذ تحظرها مواصفة XML حتى في مراجع المحارف الرقمية مثل )، وتُرفض أي قيمة تحتوي على أحدها عند معالجة الاستبدال. ومحارف الجدولة (\t) وتغذية السطر (\n) وإرجاع العربة (\r) مسموح بها، وتبقى بايتاتها كما هي بعد كتابتها وقراءتها مجددًا.

سلوك الترقية بالنسبة لقيم العُقد الطرفية المُرمَّزة بالكياناتكانت الإصدارات السابقة تعيد تحليل كل قيمة from_env مباشرة بوصفها XML، ولذلك كان أي محرف & أو < أو > خام يُرفض لأنه يجعل البنية غير سليمة، ولم يكن من سبيل لتضمينه إلا بترميزه بكيانات XML: فمتغير البيئة المضبوط على a&b كان يُفك ترميزه إلى a&b، و<a>1</a> إلى <a>1</a>، و إلى محرف الإرجاع (carriage return). أما الآن فقيمة from_env المباشرة تُعامَل نصًا حرفيًا، ومن ثَمّ تُحَل قيم البيئة ذاتها إلى القيم الحرفية a&b و<a>1</a> و. وبعبارة أخرى، لا تحتفظ بمعناها السابق دون تغيير إلا القيم النصية العادية: أما قيمة البيئة التي رُمِّزت بالكيانات لتلائم مسار XML القديم فيجب ضبطها الآن بصيغتها الخام (على سبيل المثال، اضبط a&b، وهي قيمة كان المسار القديم يرفضها، بينما يقبلها المسار الجديد بوصفها النص الحرفي a&b).كانت الإصدارات السابقة تعيد تحليل كل قيمة from_zk طرفية بوصفها XML، ولذلك كان أي محرف & أو < أو > خام يُرفض لأنه يجعل البنية غير سليمة، ولم يكن من سبيل لتضمينه إلا بترميزه بكيانات XML: فالقيمة المخزنة بصيغة a&b كان يُفك ترميزها إلى a&b، و<a>1</a> إلى <a>1</a>، و إلى محرف الإرجاع. أما الآن فتُحفظ القيمة الطرفية التي لا تبدأ بـ < كما هي ببايتاتها الأصلية تمامًا، ومن ثَمّ تُحَل العُقد ذاتها إلى القيم الحرفية a&b و<a>1</a> و. وبعبارة أخرى، لا تحتفظ بمعناها السابق دون تغيير إلا القيم المفردة النصية العادية: أما القيمة الطرفية التي رُمِّزت بالكيانات لتلائم مسار XML القديم فيجب تخزينها الآن بصيغتها الخام (على سبيل المثال، خزّن a&b، وهي قيمة كان المسار القديم يرفضها، بينما يقبلها المسار الجديد بوصفها النص الحرفي a&b).ينطبق التغيير نفسه على القيمة المفردة العادية التي تُستبدل عبر <include from_zk="…"/> مضمَّن داخل إعداد طرفي أو داخل Secret، مثل <password><include from_zk="/secret"/></password>: إذ تُحفظ القيمة المفردة هنا أيضًا كما هي ببايتاتها الأصلية تمامًا، ولذا فإن /secret = a&b (التي كان يُفك ترميزها سابقًا إلى a&b) تُحَل الآن إلى القيمة الحرفية a&b، ويجب بدلًا من ذلك تخزينها بصيغتها الخام a&b. تجنّب إحاطة هذه الصيغة بمسافات بيضاء، لأن تلك المسافات تصبح جزءًا من قيمة الإعداد الناتجة؛ ويُفضَّل استخدام الصيغة المباشرة <password from_zk="…"/> عندما تكون مطابقة البايتات بدقة أمرًا مهمًا. (لا يسري هذا التغيير على قيمة from_zk التي تبدأ بـ <، ولا على الشجرة الفرعية بصيغة YAML المُشار إليها عبر <include from_zk="…" yaml="true"/> — فالقيم التي تُحفظ حرفيًا هي فقط القيم غير المُعلَّمة التي لا تبدأ بـ <.)

القيم الافتراضية

قد يحتوي عنصر يحمل السمة from_env أو from_zk أيضًا على السمة replace="1" (ويجب أن تظهر الأخيرة قبل from_env/from_zk). في هذه الحالة، يمكن للعنصر أيضًا تحديد قيمة افتراضية. تكون قيمة العنصر هي قيمة متغير البيئة أو عقدة ZooKeeper إذا كانت معيّنة، وإلا فتكون القيمة الافتراضية. يتكرر المثال السابق، ولكن بافتراض أن MAX_QUERY_SIZE غير معيّن:

<clickhouse>
    <profiles>
        <default>
            <max_query_size replace="1" from_env="MAX_QUERY_SIZE">150000</max_query_size>
        </default>
    </profiles>
</clickhouse>

لينتج عن ذلك الإعداد التالي:

<clickhouse>
    <profiles>
        <default>
            <max_query_size>150000</max_query_size>
        </default>
    </profiles>
</clickhouse>

الاستبدال بمحتوى الملف

يمكن أيضًا استبدال أجزاء من الإعداد بمحتويات الملفات. ويمكن تنفيذ ذلك بطريقتين:

استبدال القيم: إذا كان العنصر يحتوي على السمة incl، فستُستبدل قيمته بمحتوى الملف المشار إليه. يُحدَّد المسار إلى الملف الذي يحتوي على قيم الاستبدال بواسطة العنصر include_from ضمن إعداد الخادم؛ ولا يوجد مسار افتراضي، لذا لا تُقرأ قيم الاستبدال إلا عند تحديده. وتُحدَّد قيم الاستبدال في عناصر /clickhouse/substitution_name داخل هذا الملف. وإذا لم تكن قيمة الاستبدال المحددة في incl موجودة، فسيُسجَّل ذلك في السجل. ولمنع ClickHouse من تسجيل قيم الاستبدال المفقودة، حدِّد السمة optional="true" (على سبيل المثال، إعدادات الماكرو).
استبدال العناصر: إذا كنت تريد استبدال العنصر بالكامل بقيمة استبدال، فاستخدم include اسمًا للعنصر. ويمكن الجمع بين اسم العنصر include والسمة from_zk = "/path/to/node". في هذه الحالة، تُستبدل قيمة العنصر بمحتويات عقدة ZooKeeper الموجودة في /path/to/node. وينجح ذلك أيضًا إذا خزّنت شجرة XML فرعية كاملة بوصفها عقدة ZooKeeper، إذ ستُدرج بالكامل في العنصر المصدر.

تم التغيير في الإصدار 26.8: قبل هذا الإصدار، كان الملف /etc/metrika.xml يُستخدم ضمنيًا كلما كان موجودًا، حتى عند عدم تحديد include_from. إذا كنت تعتمد على هذا الملف، فحدِّد مساره صراحةً في include_from. لاحظ أن include_from يُقرأ من كل ملف إعداد على حدة: فالملفات التي تُحمَّل بشكل منفصل عن إعداد الخادم الرئيسي — إعداد المستخدمين (مثلًا، users.xml عندما لا يكون مضمنًا في الملف الرئيسي) وإعدادات قاموس XML — يحتاج كل منها إلى عنصر include_from خاص به؛ ولا يكفي تحديده في إعداد الخادم الرئيسي.

يظهر مثال على ذلك أدناه:

<clickhouse>
    <!-- Appends XML subtree found at `/profiles-in-zookeeper` ZK path to `<profiles>` element. -->
    <profiles from_zk="/profiles-in-zookeeper" />

    <users>
        <!-- Replaces `include` element with the subtree found at `/users-in-zookeeper` ZK path. -->
        <include from_zk="/users-in-zookeeper" />
        <include from_zk="/other-users-in-zookeeper" />
    </users>
</clickhouse>

إذا كنت تريد دمج محتوى الاستبدال مع الإعداد الحالية بدلًا من إلحاقه بها، فيمكنك استخدام السمة merge="true". على سبيل المثال: <include from_zk="/some_path" merge="true">. في هذه الحالة، ستُدمج الإعداد الحالية مع المحتوى القادم من الاستبدال، وستُستبدل إعدادات الإعداد الحالية بالقيم القادمة من الاستبدال.

تشفير الإعدادات وإخفاؤها

يمكنك استخدام التشفير المتماثل لتشفير عنصر من عناصر الإعدادات، مثل كلمة مرور بنص واضح أو مفتاح خاص. للقيام بذلك، اضبط أولًا ترميز التشفير، ثم أضف السمة encrypted_by إلى العنصر المراد تشفيره، على أن تكون قيمتها اسم ترميز التشفير. وعلى خلاف السمات from_zk وfrom_env وincl أو العنصر include، لا يُجرى أي استبدال (أي فك تشفير القيمة المشفرة) في الملف المُعالَج مسبقًا. ولا يحدث فك التشفير إلا وقت التشغيل داخل عملية الخادم. على سبيل المثال:

<clickhouse>

    <encryption_codecs>
        <aes_128_gcm_siv>
            <key_hex>00112233445566778899aabbccddeeff</key_hex>
        </aes_128_gcm_siv>
    </encryption_codecs>

    <interserver_http_credentials>
        <user>admin</user>
        <password encrypted_by="AES_128_GCM_SIV">961F000000040000000000EEDDEF4F453CFE6457C4234BD7C09258BD651D85</password>
    </interserver_http_credentials>

</clickhouse>

يمكن أيضًا تطبيق السمتين from_env وfrom_zk على encryption_codecs:

<clickhouse>

    <encryption_codecs>
        <aes_128_gcm_siv>
            <key_hex from_env="CLICKHOUSE_KEY_HEX"/>
        </aes_128_gcm_siv>
    </encryption_codecs>

    <interserver_http_credentials>
        <user>admin</user>
        <password encrypted_by="AES_128_GCM_SIV">961F000000040000000000EEDDEF4F453CFE6457C4234BD7C09258BD651D85</password>
    </interserver_http_credentials>

</clickhouse>

<clickhouse>

    <encryption_codecs>
        <aes_128_gcm_siv>
            <key_hex from_zk="/clickhouse/aes128_key_hex"/>
        </aes_128_gcm_siv>
    </encryption_codecs>

    <interserver_http_credentials>
        <user>admin</user>
        <password encrypted_by="AES_128_GCM_SIV">961F000000040000000000EEDDEF4F453CFE6457C4234BD7C09258BD651D85</password>
    </interserver_http_credentials>

</clickhouse>

يمكن تعريف مفاتيح التشفير والقيم المشفّرة في أيٍّ من ملفَي الإعداد. فيما يلي مثال على config.xml:

<clickhouse>

    <encryption_codecs>
        <aes_128_gcm_siv>
            <key_hex from_zk="/clickhouse/aes128_key_hex"/>
        </aes_128_gcm_siv>
    </encryption_codecs>

</clickhouse>

فيما يلي مثال على users.xml:

<clickhouse>

    <users>
        <test_user>
            <password encrypted_by="AES_128_GCM_SIV">96280000000D000000000030D4632962295D46C6FA4ABF007CCEC9C1D0E19DA5AF719C1D9A46C446</password>
            <profile>default</profile>
        </test_user>
    </users>

</clickhouse>

لتشفير قيمة، يمكنك استخدام البرنامج (كمثال) encrypt_decrypt:

./encrypt_decrypt /etc/clickhouse-server/config.xml -e AES_128_GCM_SIV abcd

961F000000040000000000EEDDEF4F453CFE6457C4234BD7C09258BD651D85

حتى مع عناصر التهيئة المشفَّرة، تظل العناصر المشفَّرة ظاهرة في الملف المُعالَج مسبقًا. إذا كانت هذه مشكلة في عملية نشر ClickHouse لديك، فهناك بديلان: إما ضبط أذونات الملف المُعالَج مسبقًا على 600، أو استخدام السمة hide_in_preprocessed. على سبيل المثال:

<clickhouse>

    <interserver_http_credentials hide_in_preprocessed="true">
        <user>admin</user>
        <password>secret</password>
    </interserver_http_credentials>

</clickhouse>

إعدادات المستخدم

يمكن لملف config.xml تحديد إعداد منفصل يتضمن إعدادات المستخدم وملفات التعريف والحصص. ويُحدَّد المسار النسبي لهذا الإعداد في العنصر users_config. وتكون قيمته افتراضيًا users.xml. وإذا لم يتم تحديد users_config، فستُحدَّد إعدادات المستخدم وملفات التعريف والحصص مباشرةً في config.xml. يمكن تقسيم إعدادات المستخدم إلى ملفات منفصلة، على غرار config.xml وconfig.d/. ويُحدَّد اسم الدليل على أنه قيمة الإعداد users_config بعد حذف اللاحقة .xml وإضافة .d. ويُستخدَم الدليل users.d افتراضيًا، لأن القيمة الافتراضية لـ users_config هي users.xml. تُدمَج أجزاء إعدادات المستخدم بترتيب معجمي وفقًا لمساراتها الكاملة. وبالنسبة إلى الملفات في الدليل القياسي users.d/، يعادل ذلك ترتيبها حسب اسم الملف. ويُدمَج أيضًا الدليل القديم conf.d/؛ ولأن conf.d يسبق users.d في الترتيب، تُعالَج جميع أجزائه أولًا عند وجود الدليلين معًا. لاحظ أن ملفات الإعداد تُدمَج أولًا مع مراعاة الإعدادات، ثم تُعالَج التضمينات بعد ذلك. راجع أيضًا الدمج.

مثال XML

على سبيل المثال، يمكنك إنشاء ملف إعدادات منفصل لكل مستخدم كما يلي:

$ cat /etc/clickhouse-server/users.d/alice.xml

<clickhouse>
    <users>
      <alice>
          <profile>analytics</profile>
            <networks>
                  <ip>::/0</ip>
            </networks>
          <password_sha256_hex>...</password_sha256_hex>
          <quota>analytics</quota>
      </alice>
    </users>
</clickhouse>

أمثلة YAML

هنا يمكنك الاطلاع على ملف التهيئة الافتراضي المكتوب بصيغة YAML: config.yaml.example. توجد بعض الاختلافات بين تنسيقي YAML وXML من حيث تهيئة ClickHouse. فيما يلي نصائح لكتابة التهيئة بصيغة YAML. يُمثَّل وسم XML ذو القيمة النصية بزوج مفتاح-قيمة في YAML

key: value

XML المقابل:

<key>value</key>

تُمثَّل عقدة XML المتداخلة بخريطة YAML:

map_key:
  key1: val1
  key2: val2
  key3: val3

XML المقابل:

<map_key>
    <key1>val1</key1>
    <key2>val2</key2>
    <key3>val3</key3>
</map_key>

لإنشاء وسم XML نفسه عدة مرات، استخدم تسلسلاً في YAML:

seq_key:
  - val1
  - val2
  - key1: val3
  - map:
      key2: val4
      key3: val5

XML المقابل:

<seq_key>val1</seq_key>
<seq_key>val2</seq_key>
<seq_key>
    <key1>val3</key1>
</seq_key>
<seq_key>
    <map>
        <key2>val4</key2>
        <key3>val5</key3>
    </map>
</seq_key>

لتحديد سمة XML، يمكنك استخدام مفتاح السمة مع البادئة @. لاحظ أن الرمز @ محجوز وفقًا لمعيار YAML، لذا يجب وضعه بين علامتَي اقتباس مزدوجتين:

map:
  "@attr1": value1
  "@attr2": value2
  key: 123

XML المقابل:

<map attr1="value1" attr2="value2">
    <key>123</key>
</map>

كما يمكن أيضًا استخدام السمات ضمن تسلسل YAML:

seq:
  - "@attr1": value1
  - "@attr2": value2
  - 123
  - abc

XML المقابل:

<seq attr1="value1" attr2="value2">123</seq>
<seq attr1="value1" attr2="value2">abc</seq>

لا تتيح الصيغة المذكورة أعلاه تمثيل عقد النص في XML التي تتضمن سمات XML بصيغة YAML. ويمكن التعامل مع هذه الحالة الخاصة باستخدام مفتاح السمة #text:

map_key:
  "@attr1": value1
  "#text": value2

XML المقابل:

<map_key attr1="value1">value2</map_key>

تفاصيل التنفيذ

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

الأساسيات

مفاهيم ClickHouse

أفضل الممارسات

دمج ملفات الإعداد

الاستبدال باستخدام متغيرات البيئة وعُقد ZooKeeper

كيفية تفسير القيم

القيم الافتراضية

الاستبدال بمحتوى الملف

تشفير الإعدادات وإخفاؤها

إعدادات المستخدم

مثال XML

أمثلة YAML

تفاصيل التنفيذ

​دمج ملفات الإعداد

​الاستبدال باستخدام متغيرات البيئة وعُقد ZooKeeper

​كيفية تفسير القيم

​القيم الافتراضية

​الاستبدال بمحتوى الملف

​تشفير الإعدادات وإخفاؤها

​إعدادات المستخدم

​مثال XML

​أمثلة YAML

​تفاصيل التنفيذ

دمج ملفات الإعداد

الاستبدال باستخدام متغيرات البيئة وعُقد ZooKeeper

كيفية تفسير القيم

القيم الافتراضية

الاستبدال بمحتوى الملف

تشفير الإعدادات وإخفاؤها

إعدادات المستخدم

مثال XML

أمثلة YAML

تفاصيل التنفيذ