مقدمة عن ClickHouse Operator

يقدّم هذا المستند نظرة عامة على المفاهيم الأساسية وأنماط استخدام ClickHouse Operator.

يقدّم هذا المستند نظرة عامة على المفاهيم الأساسية وأنماط استخدام ClickHouse Operator.

​

ما هو ClickHouse Operator

ClickHouse Operator هو مُشغِّل لـ Kubernetes يعمل على أتمتة نشر عناقيد ClickHouse وإدارتها على Kubernetes. وقد بُني وفق نمط المشغّل، ويُوسِّع واجهة برمجة تطبيقات Kubernetes من خلال الموارد المخصّصة التي تمثّل عناقيد ClickHouse وتبعياتها.

يتولى المشغّل ما يلي:

• إدارة دورة حياة العنقود (الإنشاء، والتحديثات، والتوسّع، والحذف)
• تنسيق عنقود ClickHouse Keeper
• التوليد التلقائي للإعدادات
• مزامنة مخطط قاعدة البيانات
• التحديثات المتدرجة والترقيات
• توفير التخزين

​

الموارد المخصّصة

يوفّر المشغّل تعريفين رئيسيين للموارد المخصّصة (CRDs):

​

ClickHouseCluster

يمثل عنقودًا لقاعدة بيانات ClickHouse يمكن تهيئة النسخ المتماثلة والشظايا فيه.

apiVersion: clickhouse.com/v1alpha1
kind: ClickHouseCluster
metadata:
  name: sample-cluster
spec:
  replicas: 3
  shards: 2
  keeperClusterRef:
    name: sample-keeper
  dataVolumeClaimSpec:
    resources:
      requests:
        storage: 100Gi

​

KeeperCluster

يمثل عنقود ClickHouse Keeper للتنسيق الموزع (كبديل لـ ZooKeeper).

apiVersion: clickhouse.com/v1alpha1
kind: KeeperCluster
metadata:
  name: sample-keeper
spec:
  replicas: 3
  dataVolumeClaimSpec:
    resources:
      requests:
        storage: 10Gi

​

التنسيق

​

ClickHouse Keeper مطلوب

يتطلب كل ClickHouseCluster عنقود ClickHouse Keeper للتنسيق الموزع. يجب الإشارة إلى عنقود Keeper في مواصفة ClickHouseCluster باستخدام keeperClusterRef. افتراضيًا، يبحث المشغّل في مساحة الاسم الخاصة بـ ClickHouseCluster، ولكن يمكنك أيضًا تعيين keeperClusterRef.namespace للإشارة إلى KeeperCluster في مساحة اسم أخرى خاضعة للمراقبة.

​

علاقة Keeper واحد إلى واحد

يجب أن يكون لكل ClickHouseCluster عنصر KeeperCluster مخصص له. ولا يمكن مشاركة KeeperCluster واحد بين عدة ClickHouseClusters.

لماذا؟ ينشئ المشغّل تلقائيًا مفتاح مصادقة فريدًا لكل ClickHouseCluster للوصول إلى Keeper الخاص به. ويُخزَّن هذا المفتاح في Secret ولا يمكن مشاركته.

النتائج المترتبة:

• لا يمكن لعدة ClickHouseClusters الإشارة إلى KeeperCluster نفسه
• تستلزم إعادة إنشاء ClickHouseCluster إعادة إنشاء KeeperCluster الخاص به

لا تُحذف وحدات التخزين الدائمة تلقائيًا عند حذف موارد ClickHouseCluster أو KeeperCluster.

عند إعادة إنشاء عنقود:

1. احذف مورد ClickHouseCluster
2. احذف مورد KeeperCluster
3. انتظر حتى تتوقف جميع الكبسولات
4. احذف PersistentVolumeClaims اختياريًا إذا كنت تريد البدء من جديد
5. أعد إنشاء كلٍّ من KeeperCluster وClickHouseCluster معًا

لتجنّب أخطاء المصادقة، احذف وحدات التخزين الدائمة يدويًا أو أعد إنشاء كلا العنقودين معًا باستخدام تخزين جديد.

​

تكرار المخطط

يُكرِّر ClickHouse Operator تلقائيًا تعريفات قاعدة البيانات على جميع النسخ المتماثلة في العنقود.

​

ما الذي تجري مزامنته

يقوم المشغّل بمزامنة:

• تعريفات قواعد البيانات Replicated
• محركات قواعد بيانات التكامل (PostgreSQL وMySQL وغيرها)

المشغّل لا يزامن:

• قواعد البيانات غير المُكرّرة (Atomic وOrdinary وغيرها)
• الجداول المحلية في قواعد البيانات غير المُكرّرة
• بيانات الجداول (يتولى ClickHouse replication مزامنتها)

​

يُوصى به: استخدم محرك قاعدة البيانات Replicated

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

استخدم دائمًا محرك قاعدة البيانات Replicated لعمليات النشر في بيئة الإنتاج.

الفوائد:

• تكرار المخطط تلقائيًا عبر جميع العقد
• تبسيط إدارة الجداول
• يمكن للمشغّل المزامنة مع النسخ المتماثلة الجديدة
• مخطط متسق عبر العنقود

أنشئ قواعد البيانات باستخدام DDL الموزّع:

CREATE DATABASE my_database ON CLUSTER 'default' ENGINE = Replicated;

​

تجنب المحركات غير Replicated

تتطلب محركات قواعد البيانات غير المكررة (Atomic وLazy وSQLite وOrdinary) إدارة المخطط يدويًا:

• يجب إنشاء الجداول بشكل منفصل على كل نسخة متماثلة
• قد يحدث انجراف في المخطط بين العُقد
• لا يمكن للمشغّل مزامنة النسخ المتماثلة الجديدة تلقائيًا

​

تعطيل تكرار المخطط

لتعطيل تكرار المخطط تلقائيًا، اضبط spec.settings.enableDatabaseSync على false في مورد ClickHouseCluster.

​

إدارة التخزين

يتولى المشغّل إدارة التخزين عبر Kubernetes PersistentVolumeClaims ‏(PVCs).

​

إعداد حجم تخزين البيانات

حدّد متطلبات التخزين في dataVolumeClaimSpec:

spec:
  dataVolumeClaimSpec:
    storageClassName: fast-ssd
    resources:
      requests:
        storage: 500Gi

​

دورة حياة التخزين

• الإنشاء: يتم إنشاء PVCs تلقائيًا مع العنقود
• التوسعة: تكون مدعومة إذا كانت StorageClass تسمح بتوسعة وحدة التخزين
• الاحتفاظ: لا يتم حذف PVCs تلقائيًا عند حذف العنقود
• إعادة الاستخدام: يمكن إعادة استخدام PVCs الحالية إذا أُعيد إنشاء العنقود بالاسم نفسه

لإزالة التخزين بالكامل:

# Delete cluster
kubectl delete clickhousecluster my-cluster

# Wait for pods to terminate
kubectl wait --for=delete pod -l app.kubernetes.io/instance=my-cluster-clickhouse

# Delete PVCs
kubectl delete pvc -l app.kubernetes.io/instance=my-cluster-clickhouse

​

أبرز إعدادات التكوين الافتراضية

• عنقود مُعدّ مسبقًا: عنقود باسم ‘default’ يضم جميع عُقد ClickHouse.
• وحدات الماكرو الافتراضية: بعض وحدات الماكرو المفيدة مُعرّفة مسبقًا:
  • {cluster}: اسم العنقود (default)
  • {shard}: رقم الجزء
  • {replica}: رقم النسخة المتماثلة
• تخزين مُكرَّر لكيانات التحكم بالوصول المستند إلى الأدوار (RBAC)
• تخزين مُكرَّر للدوال المعرّفة من قبل المستخدم (UDF)

​

الخطوات التالية

• دليل الإعداد - خيارات إعداد مفصلة
• مرجع واجهة برمجة التطبيقات - الوثائق الكاملة لواجهة برمجة التطبيقات