إذا كنت تستخدم ClickHouse Cloud على Google Cloud، فلا تنطبق عليك هذه الصفحة لأن خدماتك تستخدم بالفعل Google Cloud Storage. وإذا كنت تبحث عن كيفية تنفيذ SELECT أو INSERT على بيانات GCS، فيُرجى مراجعة دالة الجدول gcs.
يدرك ClickHouse أن GCS توفّر حلّ تخزين جذابًا إذا كنت تسعى إلى فصل التخزين عن الحوسبة. ولدعم ذلك، تتوفر إمكانية استخدام GCS كطبقة تخزين لمحرك MergeTree. ويتيح لك هذا الاستفادة من قابلية التوسع والمزايا من حيث التكلفة التي توفّرها GCS، إلى جانب أداء عمليات insert وquery في محرك MergeTree.
لاستخدام حاوية GCS كقرص، يجب أولاً التصريح بها ضمن إعدادات ClickHouse في ملف داخل conf.d. يوضّح المثال أدناه تعريف قرص GCS. يتضمن هذا الإعداد عدة أقسام لإعداد “القرص” في GCS، وذاكرة التخزين المؤقت، والسياسة التي تُحدَّد في استعلامات DDL عند إنشاء الجداول على قرص GCS. ويرد شرح كل منها أدناه.
تتيح سياسات إعدادات التخزين اختيار مكان تخزين البيانات. وتسمح السياسة المبرزة أدناه بتخزين البيانات على القرص gcs عبر تحديد السياسة gcs_main. على سبيل المثال، CREATE TABLE ... SETTINGS storage_policy='gcs_main'.
بافتراض أنك قمت بتهيئة القرص لاستخدام حاوية تخزين مع صلاحية الكتابة، ينبغي أن تتمكن من إنشاء جدول كما في المثال أدناه. وللاختصار، نستخدم مجموعة فرعية من أعمدة بيانات سيارات الأجرة في مدينة نيويورك ونرسل البيانات مباشرةً إلى الجدول المدعوم من GCS:
اعتمادًا على العتاد، قد تستغرق عملية الإدراج الأخيرة لمليون صف بضع دقائق حتى تكتمل. يمكنك التحقق من التقدم عبر جدول system.processes. لا تتردد في تعديل عدد الصفوف حتى حد 10 ملايين واستكشاف بعض الاستعلامات النموذجية.
SELECT passenger_count, avg(tip_amount) AS avg_tip, avg(total_amount) AS avg_amount FROM trips_gcs GROUP BY passenger_count;
تتوافق واجهة XML لـ Cloud Storage مع بعض الأدوات والمكتبات التي تعمل مع خدمات مثل Amazon Simple Storage Service (Amazon S3).لمزيد من المعلومات حول ضبط سلاسل التنفيذ، راجع تحسين الأداء.
كُتب هذا الدليل العملي لشرح عملية نشر ClickHouse مكرّر يعمل على Google Cloud ويستخدم Google Cloud Storage (GCS) بوصفه «type» لقرص التخزين في ClickHouse.في هذا الدليل العملي، ستنشر عقد ClickHouse server على أجهزة VM في Google Cloud Engine، مع حاوية GCS مخصّص للتخزين لكل عقدة. ويجري تنسيق النسخ المتماثل بواسطة مجموعة من عقد ClickHouse Keeper، والتي تُنشر أيضًا كأجهزة VM.متطلبات نموذجية للتوافر العالي:
عقدتا ClickHouse server في منطقتين من GCP
حاوية GCS عدد 2، منشوران في المنطقتين نفسيهما اللتين توجد فيهما عقدتا ClickHouse server
ثلاث عقد ClickHouse Keeper، اثنتان منها منشورتان في المنطقتين نفسيهما اللتين توجد فيهما عقدتا ClickHouse server. ويمكن أن تكون العقدة الثالثة في المنطقة نفسها لإحدى أول عقدتَي Keeper، ولكن ضمن نطاق توافر مختلف.
يتطلب ClickHouse Keeper عقدتين ليعمل، لذا يلزم وجود ثلاث عقد لتحقيق التوافر العالي.
قم بنشر ClickHouse على مضيفين؛ وفي إعدادات المثال يُسمَّيان chnode1 وchnode2.ضع chnode1 في إحدى مناطق GCP، وchnode2 في منطقة أخرى. في هذا الدليل، تُستخدم us-east1 وus-east4 لكلٍّ من الأجهزة الافتراضية في Compute Engine وحاويات GCS.
لا تبدأ clickhouse server إلا بعد إعداده. اكتفِ بتثبيته فقط.
ارجع إلى تعليمات التثبيت عند تنفيذ خطوات النشر على عُقد خادم ClickHouse.
انشر ClickHouse Keeper على ثلاثة مضيفين. وفي نماذج الإعداد هذه، تُسمّى keepernode1 وkeepernode2 وkeepernode3. يمكن نشر keepernode1 في المنطقة نفسها التي يوجد فيها chnode1، وkeepernode2 مع chnode2، وkeepernode3 في أيٍّ من المنطقتين، ولكن في منطقة توافر مختلفة عن عقدة ClickHouse في تلك المنطقة.راجع تعليمات التثبيت عند تنفيذ خطوات النشر على عقد ClickHouse Keeper.
سيُوضَع خادما ClickHouse في منطقتين مختلفتين لتحقيق التوفّر العالي. وستكون لكلٍّ منهما حاوية GCS في المنطقة نفسها.في Cloud Storage > Buckets، اختر CREATE BUCKET. في هذا الدليل العملي، ستُنشأ حاويتان: واحدة في us-east1 وأخرى في us-east4. يجب أن تكون الحاويتان ضمن منطقة واحدة، وبفئة التخزين القياسية، وغير عامّتَين. وعندما يُطلب منك ذلك، فعِّل منع الوصول العام. لا تُنشئ مجلدات، إذ سيُنشئها ClickHouse عند الكتابة إلى وحدة التخزين.إذا كنت بحاجة إلى إرشادات خطوة بخطوة لإنشاء حاويات GCS ومفتاح HMAC، فوسِّع إنشاء حاويات GCS ومفتاح HMAC وتابع:
افتح Cloud Storage > Settings > Interoperability ثم اختر إما Access key موجودًا أو CREATE A KEY FOR A SERVICE ACCOUNT. يشرح هذا الدليل مسار إنشاء مفتاح جديد لحساب خدمة جديد.
إذا كان هذا مشروعًا لا يحتوي على أي حساب خدمة موجود، فاختر CREATE NEW ACCOUNT.هناك ثلاث خطوات لإنشاء حساب الخدمة. في الخطوة الأولى، امنح الحساب اسمًا مناسبًا ومعرّفًا ووصفًا.في مربع حوار إعدادات Interoperability، يُوصى بدور IAM Storage Object Admin؛ حدّد هذا الدور في الخطوة الثانية.الخطوة الثالثة اختيارية ولا تُستخدم في هذا الدليل. يمكنك منح المستخدمين هذه الامتيازات وفقًا لسياساتك.سيُعرض مفتاح HMAC الخاص بحساب الخدمة. احفظ هذه المعلومات، إذ ستُستخدم في إعداد ClickHouse.
تستخدم جميع عقد ClickHouse Keeper ملف التهيئة نفسه، باستثناء السطر server_id (أول سطر مميز أدناه). عدّل الملف بإدراج أسماء المضيفين الخاصة بخوادم ClickHouse Keeper لديك، وعلى كل خادم اضبط server_id بحيث يطابق إدخال server المناسب في raft_configuration. ونظرًا لأن server_id في هذا المثال مضبوط على 3، فقد ميّزنا الأسطر المطابقة في raft_configuration.
عدّل الملف باستخدام أسماء المضيفين لديك، وتأكد من إمكانية حلّها من عُقد ClickHouse server وعُقد Keeper
انسخ الملف إلى موقعه (/etc/clickhouse-keeper/keeper_config.xml على كل خوادم Keeper)
عدّل server_id على كل جهاز، استنادًا إلى رقم الإدخال الخاص به في raft_configuration
أفضل الممارساتستطلب منك بعض الخطوات في هذا الدليل وضع ملف تهيئة في /etc/clickhouse-server/config.d/. هذا هو الموقع الافتراضي في أنظمة Linux لملفات تجاوز التهيئة. عند وضع هذه الملفات في ذلك الدليل، يدمج ClickHouse محتواها مع التهيئة الافتراضية. ومن خلال وضع هذه الملفات في الدليل config.d، ستتجنب فقدان تهيئتك أثناء الترقية.
بشكل افتراضي، يستمع ClickHouse على واجهة loopback، وفي إعداد يستخدم النسخ المتماثل تكون الحاجة إلى الاتصال الشبكي بين الأجهزة ضرورية. اجعله يستمع على جميع الواجهات:
يحدّد هذا الملف اسم المضيف والمنفذ لكل خادم ClickHouse في العنقود. يحتوي ملف التكوين الافتراضي على تعريفات نموذجية للعناقيد، ولعرض العناقيد المكتمل تكوينها فقط، أُضيف الوسم replace="true" إلى الإدخال remote_servers بحيث إنه عند دمج هذا التكوين مع التكوين الافتراضي، يستبدل قسم remote_servers بدلًا من الإضافة إليه.
حرّر الملف بإدخال أسماء المضيفين الخاصة بك، وتأكد من إمكانية حلّها من عُقد خادم ClickHouse
يحدّد هذا الملف الإعدادات المرتبطة بمسار ClickHouse Keeper. وتحديدًا، وحدات الماكرو المستخدمة لتحديد النسخة المتماثلة التي تنتمي إليها البيانات. على أحد الخوادم، يجب تحديد النسخة المتماثلة على أنها replica_1، وعلى الخادم الآخر replica_2. يمكن تغيير الأسماء؛ فاستنادًا إلى مثالنا حيث تُخزَّن إحدى النسختين المتماثلتين في ساوث كارولاينا والأخرى في شمال فرجينيا، يمكن أن تكون القيم carolina وvirginia؛ فقط تأكد من أنها مختلفة على كل جهاز.
يتضمن إعداد التخزين في ClickHouse كلاً من disks وpolicies. يحمل الـ disk الذي يجري إعداده أدناه الاسم gcs، وهو من types3. ويكون النوع s3 لأن ClickHouse يتعامل مع حاوية GCS كما لو أنه حاوية AWS S3. ستحتاج إلى نسختين من هذا الإعداد، واحدة لكل عقدة من عقد ClickHouse server.يجب إجراء عمليات الاستبدال التالية في الإعداد أدناه.تختلف عمليات الاستبدال هذه بين عقدتي ClickHouse server:
يجب ضبط REPLICA 1 BUCKET على اسم الـ حاوية الموجود في نفس الـ Region الخاصة بالخادم
يجب تغيير REPLICA 1 FOLDER إلى replica_1 على أحد الخادمين، وإلى replica_2 على الخادم الآخر
عمليات الاستبدال التالية مشتركة بين العقدتين:
يجب ضبط access_key_id على HMAC Key الذي تم إنشاؤه سابقًا
يجب ضبط secret_access_key على HMAC Secret الذي تم إنشاؤه سابقًا
أرسل الأوامر إلى ClickHouse Keeper باستخدام netcat. على سبيل المثال، يُرجع mntr حالة عنقود ClickHouse Keeper. وإذا شغّلت الأمر على كل عقدة من عقد Keeper، فسترى أن إحداها هي القائد، وأن العقدتين الأخريين تابعتان:
عند النظر إلى حاويات التخزين، سترى أنه تم إنشاء مجلد في كل حاوية بالاسم المستخدم في ملف التكوين storage.xml. وسِّع المجلدات وسترى العديد من الملفات التي تمثل أقسام البيانات.