Skip to main content
في هذا المثال، ستتعلّم كيفية إعداد عنقود ClickHouse بسيط يوفّر نسخًا متماثلًا للبيانات. هناك خمسة خوادم مُعدّة. يُستخدم اثنان منها لاستضافة نُسخ من البيانات. وتُستخدم الخوادم الثلاثة الأخرى لتنسيق عملية النسخ المتماثل للبيانات.
تظهر أدناه معمارية العنقود الذي ستقوم بإعداده:
على الرغم من إمكانية تشغيل ClickHouse Server وClickHouse Keeper معًا على الخادم نفسه، فإننا نوصي بشدة باستخدام مضيفات مخصصة لـ ClickHouse Keeper في بيئات production، وهذا هو النهج الذي سنوضحه في هذا المثال.يمكن أن تكون خوادم Keeper أصغر حجمًا، وعادةً ما تكون 4GB RAM كافية لكل خادم Keeper إلى أن تكبر ClickHouse Servers.

المتطلبات المسبقة

1

إعداد بنية الدليل وبيئة الاختبار

ملفات المثالتوضح لك الخطوات التالية كيفية إعداد العنقود من الصفر. إذا كنت تفضل تخطي هذه الخطوات والانتقال مباشرةً إلى تشغيل العنقود، فيمكنك الحصول على ملفات المثال من مستودع الأمثلة مجلد ‘docker-compose-recipes’.
في هذا الدليل العملي، ستستخدم Docker compose لإعداد مجموعة ClickHouse. يمكن تعديل هذا الإعداد ليناسب أجهزة محلية منفصلة، أو أجهزة افتراضية، أو نسخ سحابية أيضًا.نفّذ الأوامر التالية لإعداد بنية الدليل لهذا المثال:
أضف ملف docker-compose.yml التالي إلى مجلد cluster_1S_2R:
docker-compose.yml
أنشئ المجلدات الفرعية والملفات التالية:
  • يحتوي الدليل config.d على ملف إعدادات خادم ClickHouse ‏config.xml، حيث تُحدَّد الإعدادات المخصصة لكل عقدة ClickHouse. وتُدمَج هذه الإعدادات مع ملف إعدادات ClickHouse الافتراضي config.xml الذي يأتي مع كل عملية تثبيت لـ ClickHouse.
  • يحتوي الدليل users.d على ملف إعدادات المستخدم users.xml، حيث تُحدَّد الإعدادات المخصصة للمستخدمين. وتُدمَج هذه الإعدادات مع ملف إعدادات ClickHouse الافتراضي users.xml الذي يأتي مع كل عملية تثبيت لـ ClickHouse.
أدلة الإعدادات المخصصةمن أفضل الممارسات استخدام الدليلين config.d وusers.d عند كتابة إعداداتك الخاصة، بدلًا من تعديل الإعدادات الافتراضية مباشرةً في /etc/clickhouse-server/config.xml وetc/clickhouse-server/users.xml.السطر
يضمن أن أقسام الإعدادات المحددة في الدليلين config.d وusers.d تحلّ محل أقسام الإعدادات الافتراضية المحددة في الملفين الافتراضيين config.xml وusers.xml.
2

تهيئة عقد ClickHouse

إعداد الخادم

قم الآن بتعديل كل ملف تهيئة فارغ config.xml الموجود في fs/volumes/clickhouse-{}/etc/clickhouse-server/config.d. يجب تغيير الأسطر المُميَّزة أدناه بحيث تكون مخصصة لكل عقدة:
يُشرح كل قسم من أقسام ملف الإعداد أعلاه بمزيد من التفاصيل في ما يلي.

الشبكة والتسجيل

يُفعَّل الاتصال الخارجي عبر واجهة الشبكة من خلال تفعيل إعداد listen host. ويضمن ذلك أن يكون خادم ClickHouse قابلاً للوصول من قِبل المضيفات الأخرى:
تم ضبط منفذ واجهة برمجة تطبيقات HTTP على 8123:
يُضبط منفذ TCP المستخدم للتواصل عبر البروتوكول الأصلي لـ ClickHouse بين clickhouse-client وأدوات ClickHouse الأصلية الأخرى، وبين clickhouse-server وخوادم clickhouse-server الأخرى على 9000:
يُعرَّف التسجيل في كتلة <logger>. توفر لك هذه التهيئة النموذجية سجل تصحيح يُدوَّر عند 1000M ثلاث مرات:
لمزيد من المعلومات حول تهيئة التسجيل، راجع التعليقات المضمّنة في ملف التهيئة الافتراضي لـ ClickHouse.

تهيئة العنقود

يتم ضبط إعدادات العنقود في القسم <remote_servers>. وهنا يُعرَّف اسم العنقود cluster_1S_2R.يُعرِّف الكتلة <cluster_1S_2R></cluster_1S_2R> تخطيط الـ cluster، باستخدام إعدادَي <shard></shard> و<replica></replica>، ويعمل بوصفه Template لاستعلامات distributed DDL، وهي الاستعلامات التي تُنفَّذ عبر الـ cluster باستخدام جملة ON CLUSTER. بشكل افتراضي، تكون استعلامات distributed DDL مسموحاً بها، غير أنه يمكن تعطيلها عبر الإعداد allow_distributed_ddl_queries.يُضبط internal_replication على true بحيث تُكتب البيانات إلى نسخة متماثلة واحدة فقط.
لكل خادم، تُحدَّد المعلمات التالية:

تهيئة Keeper

يُخبر القسم <ZooKeeper> ClickHouse بمكان تشغيل ClickHouse Keeper (أو ZooKeeper). نظرًا لاستخدامنا Keeper cluster، يجب تحديد كل <node> من عقد الـ cluster، مع اسم الـ hostname ورقم المنفذ الخاص به باستخدام الوسمَين <host> و<port> على التوالي.سيُشرح إعداد ClickHouse Keeper في الخطوة التالية من الدليل العملي.
على الرغم من إمكانية تشغيل ClickHouse Keeper على الخادم نفسه الذي يعمل عليه ClickHouse Server، فإننا نوصي بشدة، في بيئات الإنتاج، بتشغيل ClickHouse Keeper على مضيفات مخصصة.

تهيئة الماكرو

بالإضافة إلى ذلك، يُستخدم قسم <macros> لتعريف استبدالات المعاملات للجداول المُتماثلة. وتُدرج هذه الاستبدالات في system.macros، مما يتيح استخدام استبدالات مثل {shard} و{replica} في الاستعلامات.
سيُحدَّد كلٌّ منها بشكلٍ خاص وفقًا لبنية العنقود.

تهيئة المستخدم

عدِّل الآن كل ملف تهيئة فارغ users.xml الموجود في fs/volumes/clickhouse-{}/etc/clickhouse-server/users.d بالمحتوى التالي:
/users.d/users.xml
في هذا المثال، تم تهيئة المستخدم default بدون كلمة مرور لأغراض التبسيط. في الممارسة الفعلية، لا يُنصح بهذا الأسلوب.
في هذا المثال، يكون ملف users.xml نفسه على جميع العُقد في العنقود.
3

إعداد ClickHouse Keeper

إعداد Keeper

لكي يعمل النسخ المتماثل، يجب إعداد عنقود ClickHouse Keeper وتهيئته. يوفّر ClickHouse Keeper نظام التنسيق لنسخ البيانات المتماثل، إذ يعمل كبديل مباشر لـ ZooKeeper، الذي يمكن استخدامه أيضًا. ومع ذلك، يُوصى باستخدام ClickHouse Keeper لأنه يوفّر ضمانات أفضل وموثوقية أعلى ويستخدم موارد أقل من ZooKeeper. ولتحقيق التوافر العالي والحفاظ على quorum، يُوصى بتشغيل ثلاث عقد ClickHouse Keeper على الأقل.
يمكن تشغيل ClickHouse Keeper على أي عقدة في العنقود إلى جانب ClickHouse، رغم أنه يُوصى بتشغيله على عقدة مخصصة، مما يتيح التوسّع وإدارة عنقود ClickHouse Keeper بشكل مستقل عن عنقود قاعدة البيانات.
أنشئ ملفات keeper_config.xml لكل عقدة ClickHouse Keeper باستخدام الأمر التالي من جذر مجلد المثال:
عدِّل ملفات التكوين الفارغة التي أُنشئت في دليل كل عقدة fs/volumes/clickhouse-keeper-{}/etc/clickhouse-keeper. يجب تعديل الأسطر المظللة أدناه بحيث تكون خاصة بكل عقدة:
/clickhouse-keeper/keeper_config.xml
سيحتوي كل ملف تهيئة على التكوين الفريد التالي (كما هو موضح أدناه). يجب أن يكون server_id المستخدم فريدًا لتلك العقدة المحددة من ClickHouse Keeper ضمن العنقود، وأن يطابق <id> الخاص بالخادم المعرّف في قسم <raft_configuration>. يمثل tcp_port المنفذ الذي يستخدمه عملاء ClickHouse Keeper.
يُستخدم القسم التالي لتكوين الخوادم المشاركة في النصاب ضمن خوارزمية إجماع Raft:
ClickHouse Cloud يسهّل الإدارةClickHouse Cloud يخفف العبء التشغيلي المرتبط بإدارة الأجزاء والنُسخ المتماثلة. تتولى المنصة تلقائيًا الإتاحة العالية والنسخ المتماثل وقرارات التوسّع. وتكون موارد الحوسبة والتخزين منفصلة، وتتوسع بحسب الطلب من دون الحاجة إلى إعداد يدوي أو صيانة مستمرة.اقرأ المزيد
4

اختبر الإعداد

تأكد من أن Docker يعمل على جهازك. ابدأ العنقود باستخدام الأمر docker-compose up من الدليل الجذر cluster_1S_2R:
ينبغي أن ترى Docker يبدأ بسحب صور ClickHouse وKeeper، ثم يبدأ تشغيل الحاويات:
للتحقق من أن التجمّع يعمل، اتصل بـ clickhouse-01 أو clickhouse-02 ونفّذ الاستعلام التالي. وفيما يلي أمر الاتصال بالعقدة الأولى:
إذا نجح ذلك، فسترى موجّه ClickHouse client:
شغّل الاستعلام التالي للتحقق من طوبولوجيات العناقيد المعرّفة وعلى أي مضيفات:
Query
Response
شغّل الاستعلام التالي للتحقق من حالة تجمّع ClickHouse Keeper:
Query
Response
يُستخدم الأمر mntr أيضًا على نطاق واسع للتحقق من أن ClickHouse Keeper قيد التشغيل، وللحصول على معلومات عن حالة العلاقة بين عقد Keeper الثلاث. في الإعداد المستخدم في هذا المثال، هناك ثلاث عقد تعمل معًا. ستنتخب هذه العقد قائدًا، وستكون العقد المتبقية عقدًا تابعة.يوفّر الأمر mntr معلومات متعلقة بالأداء، ويُبيّن أيضًا ما إذا كانت عقدة معيّنة تابعة أم قائدًا.
قد تحتاج إلى تثبيت netcat حتى تتمكن من إرسال الأمر mntr إلى Keeper. يُرجى مراجعة صفحة nmap.org للحصول على معلومات التنزيل.
شغّل الأمر أدناه من سطر الأوامر على clickhouse-keeper-01 وclickhouse-keeper-02 و clickhouse-keeper-03 للتحقق من حالة كل عقدة Keeper. الأمر الخاص بـ clickhouse-keeper-01 موضح أدناه:
تعرض الاستجابة أدناه مثالًا على استجابة من عقدة follower:
Response
يوضح الرد أدناه مثالًا لرد صادر من العقدة القائدة:
Response
بهذا، تكون قد أعددت بنجاح عنقود ClickHouse بشظية واحدة ونسختين متماثلتين. في الخطوة التالية، ستنشئ جدولًا في العنقود.
5

أنشئ قاعدة بيانات

الآن بعد أن تحققت من أن العنقود مُهيّأ بشكل صحيح ويعمل، ستعيد إنشاء الجدول نفسه المستخدم في الدليل العملي لمجموعة البيانات النموذجية UK property prices. وتتألف هذه المجموعة من نحو 30 مليون صف لأسعار بيع العقارات في إنجلترا وويلز منذ عام 1995.اتصل بعميل كل مضيف عبر تشغيل كل واحد من الأوامر التالية من علامات تبويب أو نوافذ طرفية منفصلة:
يمكنك تشغيل الاستعلام أدناه باستخدام clickhouse-client على كل مضيف للتأكد من عدم إنشاء أي قواعد بيانات بعد، باستثناء القواعد الافتراضية:
Query
Response
من خلال عميل clickhouse-01، شغّل استعلام DDL الموزّع التالي باستخدام بند ON CLUSTER لإنشاء قاعدة بيانات جديدة باسم uk:
يمكنك مرة أخرى تشغيل الاستعلام نفسه كما في السابق من عميل كل خادم للتأكد من أنه تم إنشاء قاعدة البيانات على مستوى العنقود، على الرغم من تشغيل الاستعلام على clickhouse-01 فقط:
6

أنشئ جدولًا على العنقود

الآن بعد إنشاء قاعدة البيانات، أنشئ جدولًا على العنقود. نفّذ الاستعلام التالي من أي عميل على أحد المضيفات:
لاحظ أنه مطابق تمامًا للاستعلام المستخدم في جملة CREATE الأصلية ضمن الدليل العملي لمجموعة البيانات النموذجية أسعار العقارات في المملكة المتحدة، باستثناء عبارة ON CLUSTER واستخدام المحرك ReplicatedMergeTree.صُمِّمت عبارة ON CLUSTER للتنفيذ الموزّع لاستعلامات DDL ‏(لغة تعريف البيانات) مثل CREATE وDROP وALTER وRENAME، بما يضمن تطبيق تغييرات المخطط هذه على جميع العقد في العنقود.يعمل المحرك ReplicatedMergeTree بالطريقة نفسها التي يعمل بها محرك الجداول العادي MergeTree، لكنه ينسخ البيانات أيضًا.يمكنك تشغيل الاستعلام أدناه من عميل clickhouse-01 أو clickhouse-02 للتأكد من أن الجدول قد أُنشئ على مستوى العنقود:
Query
Response
7

إدراج البيانات

نظرًا لأن مجموعة البيانات كبيرة وتستغرق بضع دقائق لاستيعابها بالكامل، سنبدأ بإدراج جزء صغير منها فحسب.أدرج مجموعة فرعية أصغر من البيانات باستخدام الاستعلام أدناه من clickhouse-01:
لاحظ أن البيانات مُنسوخة بالكامل على كل عقدة:
لتوضيح ما يحدث عند تعطّل أحد المضيفين، أنشئ قاعدة بيانات اختبارية بسيطة وجدول اختبار من أيٍّ من المضيفين:
كما هو الحال مع جدول uk_price_paid، يمكننا إدراج البيانات من أيٍّ من المضيفَين:
لكن ماذا سيحدث إذا تعطّل أحد المضيفين؟ لمحاكاة ذلك، أوقف clickhouse-01 بتنفيذ الأمر التالي:
تحقق من أن المضيف متوقف عن طريق تشغيل:
Response
بعد إيقاف clickhouse-01، أدرج صفًا آخر من البيانات في جدول الاختبار واستعلم عن الجدول:
Response
أعد تشغيل clickhouse-01 الآن باستخدام الأمر التالي (يمكنك تشغيل docker-compose ps مجدداً للتحقق من ذلك):
استعلم عن جدول الاختبار مجدداً من clickhouse-01 بعد تشغيل docker exec -it clickhouse-01 clickhouse-client:
Query
Response
إذا كنت في هذه المرحلة ترغب في استيراد مجموعة بيانات أسعار العقارات في المملكة المتحدة بالكامل للتجربة والاستكشاف، يمكنك تشغيل الاستعلامات التالية:
استعلم عن الجدول من clickhouse-02 أو clickhouse-01:
Query
Response

الخلاصة

تتمثل ميزة بنية هذا العنقود في أنه مع وجود نسختين متماثلتين، تكون بياناتك موجودة على خادمين منفصلين. وإذا تعطل أحد الخادمين، تواصل النسخة المتماثلة الأخرى خدمة البيانات من دون أي فقدان. وهذا يلغي نقاط الإخفاق المفردة على مستوى التخزين. عندما يتوقف أحد الخادمين عن العمل، تظل النسخة المتماثلة المتبقية قادرة على:
  • معالجة استعلامات القراءة دون انقطاع
  • قبول عمليات كتابة جديدة (بحسب إعدادات الاتساق لديك)
  • الحفاظ على إتاحة الخدمة للتطبيقات
عندما يعود الخادم المتعطل إلى العمل، يصبح قادرًا على:
  • مزامنة البيانات المفقودة تلقائيًا من النسخة المتماثلة السليمة
  • استئناف التشغيل الطبيعي دون تدخل يدوي
  • استعادة التكرار الكامل بسرعة
في المثال التالي، سنستعرض كيفية إعداد عنقود يضم شاردتين لكن بنسخة متماثلة واحدة فقط.
آخر تعديل في ٢٣ يوليو ٢٠٢٦