Skip to main content

​
الأسئلة الشائعة

​
الإعداد الأولي وتوفير البنية التحتية

تواصل مع ClickHouse عبر نموذج الاتصال، وسيقوم الفريق بتمكين BYOC لمؤسستك. بعد ذلك، جهّز حسابًا سحابيًا مخصصًا (حساب AWS أو مشروع GCP أو اشتراك Azure) واتبع دليل الإعداد الأولي القياسي. نوصي بشدة باستخدام حساب أو مشروع أو اشتراك مخصص حصريًا لـ BYOC.
توقّع أن تستغرق العملية نحو 45–90 دقيقة من البداية إلى النهاية. ويرجع اتساع هذا النطاق إلى أن معظم الوقت يُستهلك في توفير موفر الخدمة السحابية للموارد (عنقود Kubernetes وموازنات التحميل ومكونات الشبكة)، وهي عملية تختلف مدتها من تشغيل لآخر وتقع خارج سيطرة ClickHouse. وعندما يتعطل التوفير، تكون الأسباب الأكثر شيوعًا مرتبطة بالحساب:
  • تعديل قالب CloudFormation أو وحدة Terraform قبل تطبيقهما — مثلًا بإضافة PermissionsBoundary أو بإعادة تسمية دور IAM لتلبية اصطلاح تسمية معين (في AWS، احتفظ بالاسم الافتراضي ClickHouseManagementRole ما لم توافق ClickHouse صراحةً على اسم مختلف). طبّق المخرجات كما تم توفيرها — إذ تتوفر التخصيصات المدعومة كمعلمات، وأي تغيير آخر يتطلب موافقة ClickHouse مسبقًا.
  • سياسات على مستوى المؤسسة (AWS SCPs أو سياسات مؤسسة GCP مثل iam.allowedPolicyMemberDomains أو سياسات Azure التي تقيّد تعيينات الأدوار) تمنع افتراض الدور أو ربط IAM.
  • عدم تطابق المعرّف الخارجي في دور الإعداد الأولي (راجع سؤال المعرّف الخارجي أدناه).
  • حدود حصة الحساب (مثل Elastic IPs أو VPCs في AWS).
تُعاد محاولة التوفير تلقائيًا، وتتعافى العملية ذاتيًا بمجرد حل المشكلة الأساسية. إذا ظلت بنيتك التحتية عالقة لأكثر من بضع ساعات، فاتصل بالدعم.
ينشئ ClickHouse Cloud console معرّفًا خارجيًا لحساب AWS الخاص بك عند بدء الإعداد الأولي، ويملؤه مسبقًا في رابط CloudFormation (المعلمة ExternalID)؛ وإذا كنت تستخدم Terraform، فمرّر القيمة نفسها باعتبارها external_id. تشترك جميع البنى التحتية لـ BYOC ضمن حساب AWS نفسه في المعرّف الخارجي نفسه. لا تختر قيمة بنفسك: يجب أن تتطابق مع ما تتوقعه أتمتة ClickHouse، وإلا فلن يمكن تولّي الدور عبر الحسابات وسيفشل التوفير. راجع المعرّف الخارجي لـ AWS للتفاصيل.
تستخدم البنى التحتية لـ BYOC التي تم إعدادها قبل إدخال المعرّفات الخارجية القيمة النائبة emptyid للتوافق مع الإصدارات السابقة. عند إضافة بنية تحتية جديدة إلى حساب AWS يتضمن نشرًا قديمًا قائمًا، يعيد Console استخدام هذه القيمة النائبة كي تحافظ جميع البنى التحتية في الحساب على تكوين ثقة متسق. إذا كنت ترغب في التبديل إلى معرّف خارجي فريد، فاتصل بـ ClickHouse Support.
في AWS وGCP، يمكنك النشر في شبكة VPC الحالية الموجودة في الحساب أو المشروع نفسه الذي توجد فيه البنية التحتية لـ BYOC. راجع أدلة التخصيص لـ AWS وGCP. في GCP، تُدعم أيضًا Shared VPC من مشروع مضيف منفصل — راجع Shared VPC من مشروع مضيف للتعرف على المتطلبات الأساسية، والحقل الذي يجب تعبئته في Console، والامتيازات التي تضيفها وحدة الإعداد الأولي إلى مشروعك المضيف. ستتوفر قريبًا إمكانية إحضار VNet الخاصة بك في Azure.في AWS، تُدعم أيضًا الشبكات الفرعية المشتركة من حساب آخر عبر AWS Resource Access Manager ‏(RAM)، بحيث يمكنك إبقاء إدارة الشبكات مركزية في حساب محوري وتشغيل البنية التحتية لـ BYOC في حساب فرعي. وثمة متطلب أساسي خاص بهذا الإعداد: للموارد المشتركة عبر RAM عرضٌ للعلامات خاص بكل حساب، لذا يجب على الحساب الفرعي تطبيق علامات VPC والشبكة الفرعية المطلوبة بنفسه — إذ لا تكون العلامات المطبقة من الحساب المحوري مرئية للحساب الفرعي، ويفشل التوفير بدونها. وتظل جداول التوجيه مملوكة للحساب المحوري، الذي يبقى مسؤولًا عن NAT وتوجيه حركة الخروج على الشبكات الفرعية المشتركة. راجع دليل التخصيص لـ AWS للاطلاع على العلامات والمتطلبات الأخرى.لاحظ أنه عند استخدام VPC يديرها العميل، لا يتم تمكين سوى موازن التحميل الخاص افتراضيًا (راجع تهيئة).
لا. يُنشأ عنقود Kubernetes (EKS أو GKE أو AKS) ويُدار بالكامل من قِبل ClickHouse. وهذا أمر ضروري كي يتمكن ClickHouse من تشغيل المنصة بشكل موثوق والحفاظ على ترقيتها.
في حساب سحابي: هذا ممكن، لكن الموارد الموجودة في الموقع نفسه تقع دائمًا، بدرجة ما، ضمن نطاق أذونات ClickHouse — ففي AWS تكون معظم أذونات الكتابة مقيّدة بالعلامات والبادئات (تحمل الموارد التي يوفّرها ClickHouse العلامة clickhouse-byoc=true)، لكن مجموعة صغيرة من إجراءات EC2 لا يمكن تقييدها بالعلامات. أما في GCP وAzure، فلدى هويات الإعداد الأولي أذونات على مستوى المشروع أو الاشتراك. أبقِ مواردك بعيدة عن الموارد التي يوفّرها ClickHouse، ويفضّل استخدام حساب أو مشروع أو اشتراك مخصص في كل Cloud — إذ تظل هذه توصيتنا الأساسية.في عنقود Kubernetes: هذا ممكن ضمن قيود — استخدم مجموعات العقد الخاصة بك مع التلويثات ووسائل التحمّل، وابقَ خارج مساحات الأسماء التي يديرها ClickHouse، ولا تثبّت وحدات تحكم قبول أو محركات سياسات على مستوى العنقود، إذ قد تعيق مطابقة مكونات ClickHouse. اشرح خطتك لفريق الدعم كي نتمكن من التأكد من عدم وجود أي تعارضات.

​
الحوسبة والتحجيم

نعم. لا يلزم توفير البنية الأساسية، بما في ذلك عنقود Kubernetes، إلا مرة واحدة لكل مجموعة من حساب/مشروع/اشتراك سحابي ومنطقة، وتشترك فيها جميع الخدمات التي تنشئها في تلك المنطقة.
تتوفر جميع المناطق العامة المدرجة في وثائق المناطق المدعومة لعمليات نشر BYOC. يوفّر BYOC الموارد عبر ثلاث مناطق توافر، لذا لا تُدعم المناطق التي تحتوي على أقل من ثلاث مناطق توافر، ولا AWS Local Zones. إذا لم تكن المنطقة التي تحتاج إليها مدرجة، فاتصل بممثل ClickHouse لمناقشة مدى توفرها.
إلى جانب مثيلات ClickHouse نفسها، بما في ذلك خوادم ClickHouse وClickHouse Keeper، نشغّل أيضًا خدمات داعمة مثل clickhouse-operator وcluster autoscaler وIstio وحزمة المراقبة.استهلاك الموارد لهذه المكونات المشتركة مستقر نسبيًا ولا يزداد خطيًا مع عدد خدمات ClickHouse أو حجمها. كإرشاد تقريبي، يبلغ إجمالي مجموعة عقد النظام المخصصة لهذه أعباء العمل نحو 48 وحدة vCPU و192 غيغابايت من الذاكرة — أي ما يعادل على AWS، مثلًا، نحو ست مثيلات من نوع 2xlarge. بالإضافة إلى ذلك، يشغّل كل مستودع مجموعة ClickHouse Keeper مخصصة تتألف من ثلاث عقد، وتشترك فيها جميع الخدمات ضمن ذلك المستودع. راجع نموذج التكلفة للتفاصيل.
التحجيم التلقائي الرأسي على مستوى الخدمة مدرج في خارطة الطريق. المتاح حاليًا: التحجيم الرأسي والأفقي اليدوي عبر Console، والتحجيم المجدول لأنماط الحمل المتوقعة، والتعطيل وإعادة التشغيل تلقائيًا لأعباء العمل المتقطعة، والتحجيم التلقائي لمجموعات العقد على مستوى البنية الأساسية — ولن تحتاج إلى إدارة العقد بنفسك مطلقًا. تراقب ClickHouse خدمة ClickHouse Keeper وتُحجّمها.
يعمل BYOC على مجموعة منتقاة من مجموعات العقد بدلًا من أنواع المثيلات العشوائية. تعمل مجموعات عقد أعباء العمل، وهي خوادم ClickHouse وKeeper، افتراضيًا على مثيلات محسّنة للذاكرة ومعتمدة على ARM، مثل Graviton على AWS، بينما تستخدم مجموعة عقد النظام عادةً مثيلات x86. يمكن توفير عائلات مثيلات أو نسب CPU إلى الذاكرة أو بُنى مختلفة عند الطلب عبر الدعم؛ ولا تُدعم مثيلات Spot. راجع configuration.
تعمل كل نسخة متماثلة كـ pod واحد على عقدة خاصة بها — إذ يُطابق حجم العقدة حجم النسخة المتماثلة، وتُوفَّر العقد عند الطلب، ولا تُوضَع نسخ متماثلة متعددة على عقدة واحدة مطلقًا. لذلك، تكون النسخ المتماثلة الصغيرة جدًا غير فعّالة: إذ يستهلك الحمل الإضافي حصة أكبر من العتاد، كما يزداد عرض نطاق الشبكة والقرص مع حجم المثيل. أما الأحجام الأصغر مما توفره Console فتتطلب طلبات مخصصة عبر الدعم.
نعم. يدعم BYOC المستودعات (فصل الحوسبة عن الحوسبة): تشترك خدمات متعددة في البيانات نفسها، لذا يمكنك تخصيص خدمات للاستيعاب وأخرى للاستعلام.

​
الشبكة والأمان

يمكنك تقليص الامتيازات منذ البداية على AWS وGCP: إذ إن مكوّنات الإعداد الأولي قابلة للتهيئة عبر المعلمات، لذا يمكنك حجب أذونات إدارة طوبولوجيا شبكة VPC الخاصة بك عند استخدام VPC خاصة بك (IncludeVPCWritePermissions في CloudFormation، وinclude_vpc_write_permissions في وحدات Terraform). على GCP، يقتصر ذلك على إدارة الطوبولوجيا فقط — إذ يحتفظ ClickHouse بإذن الكتابة إلى موارد الشبكة التي يملكها داخل VPC، مثل مرفق خدمة Private Service Connect وعناوين الإدخال. أما الشبكة الفرعية NAT لـ Private Service Connect فليست من بينها: ففي حالة VPC الخاصة بك تنشئها بنفسك قبل تفعيل الرابط الخاص. على AWS، يمكنك أيضًا — ضمن معاينة خاصة تُفعَّل عبر الدعم — إدارة أدوار IAM بنفسك (IncludeIAMWritePermissions=false، راجع أدوار IAM التي يديرها العميل)، كما تُحمى الأدوار المشتركة بين الحسابات بمعرّف خارجي لمنع هجمات النائب الملتبس. على Azure، تمنح وحدة الإعداد الأولي دورًا ثابتًا على مستوى الاشتراك، من دون معلمات لتحديد النطاق حاليًا. في جميع السحب، لا تُطلب بعض الأذونات إلا لميزات محددة، ويمكن إزالتها إذا كنت لن تستخدم تلك الميزات مطلقًا — تواصل مع الدعم إذا احتجت إلى تقييد الأذونات بما يتجاوز ما تتيحه هذه المكوّنات.بعد التوفير، لا تزل الأذونات من هوية الإدارة من جانب واحد: إذ يطابق ClickHouse البنية التحتية باستمرار مع الحالة المطلوبة، وقد تؤدي الأذونات المفقودة إلى تعطل التوفير والترقيات والدعم. لتغيير الأذونات الممنوحة أو إلغاء الإعداد بالكامل، نسّق مع الدعم (راجع سؤال إيقاف الخدمة أدناه).
يوفر مرجع الامتيازات نظرة عامة على كل دور وهوية والغرض منهما على AWS وGCP وAzure. بالنسبة إلى هوية الإعداد الأولي (التمهيد)، تحدد المكوّنات المنشورة نطاق السياسات الدقيق — قالب CloudFormation ووحدات Terraform — ويمكن لفريق الأمان لديك تدقيقها مباشرةً. تُوضَّح الهويات الإضافية التي ينشئها ClickHouse بعد الإعداد الأولي (أدوار وحدة التحكم وحسابات الخدمة والهويات المُدارة) لكل مزود في مرجع الامتيازات، وبما أنها موجودة في حسابك، يمكنك فحص سياساتها الفعلية في وحدة التحكم السحابية لديك ومراجعة إنشائها واستخدامها في CloudTrail أو ما يعادله في GCP/Azure. على AWS، يُحدَّد نطاق معظم أذونات الكتابة لدور الإدارة بواسطة علامات الموارد وبادئات الأسماء مثل clickhouse-cloud-*، لذلك لا يمكنه عمومًا تعديل الموارد التي لم ينشئها (إذ لا يمكن تحديد نطاق عدد قليل من إجراءات EC2 بالعلامات)، وليس لديه أي وصول على مستوى الكائنات إلى حاويات بياناتك — إذ يقتصر الوصول إلى الكائنات على الهويات داخل العنقود والمحددة النطاق لأحمال عمل ClickHouse. على GCP وAzure، تمتلك هويات الإعداد الأولي أذونات على مستوى المشروع أو الاشتراك بدلًا من ذلك — وهو أحد أسباب التوصية بشدة بمشروع أو اشتراك مخصص. أذونات القراءة أوسع نطاقًا لأنها مطلوبة للمطابقة المستمرة.
افتراضيًا، لا يملكون أي وصول إلى بياناتك. لاستكشاف الأخطاء وإصلاحها، يجب على المهندسين المرور بعملية escalation داخلية تمنح وصولًا فوريًا عند الحاجة؛ ويكون هذا الوصول مقيّدًا زمنيًا، ومعتمدًا على الشهادات، ومحدودًا بجداول system.* (من دون جداول بيانات العملاء)، ويُسجَّل ويُدقَّق من قبل فريق الأمان لدينا. يظهر لك أي query ينفذه مهندس ClickHouse في system.query_log الخاص بك. ولتشخيص البنية التحتية، يمكن لعملية escalation نفسها، بعد الموافقة، أن تمنح وصولًا مقيّدًا زمنيًا إلى خادم واجهة برمجة تطبيقات Kubernetes وحزمة المراقبة داخل العنقود عبر Tailscale. راجع ClickHouse data access للاطلاع على نموذج الوصول إلى البيانات، وأمان الشبكة للاطلاع على نموذج الاتصال.
نعم. إن تنفيذ آلية يتحكم بها العميل، تتيح له الموافقة على وصول المهندسين إلى العنقود، مدرج في خارطة طريقنا. في الوقت الحالي، يجب على المهندسين المرور بعملية escalation الداخلية لدينا للحصول على وصول فوري إلى العنقود. يُسجَّل ذلك ويُدقَّق من قبل فريق الأمان لدينا.
البيانات الوصفية التشغيلية فقط: أحداث حالة الخدمة والنسخ الاحتياطي، ومقاييس الاستخدام لأغراض الفوترة، وإشعارات التنبيهات. تبقى بياناتك ونسخك الاحتياطية وسجلاتك وبيانات Monitoring في حسابك. راجع أمان الشبكة للاطلاع على القائمة الكاملة للتدفقات الصادرة.
افتراضيًا، تكون نقطة نهاية واجهة برمجة تطبيقات Kubernetes عامة، ويختلف ما يقيّد الوصول إليها بحسب السحابة: على AWS تُقيَّد بقائمة سماح IP تحتوي فقط على عناوين IP الخاصة ببوابة NAT لدى ClickHouse — وما دام هذا الإعداد الافتراضي قيد الاستخدام، فلا تحذف إدخالات قائمة السماح الخاصة بـ ClickHouse، إذ يحتاجها مستوى التحكم لإدارة العنقود — أما على GCP وAzure فتُقيَّد بواسطة IAM السحابي بدلًا من قائمة سماح IP (راجع كشف خادم واجهة برمجة تطبيقات Kubernetes). يمكن بدلًا من ذلك تحويل نقطة النهاية إلى وصول خاص فقط، بالتنسيق مع فريق ClickHouse: عبر Tailscale (للخروج فقط، ويُستخدم أيضًا للوصول لأغراض استكشاف الأخطاء وإصلاحها) أو، على AWS، عبر VPC Lattice (معاينة خاصة) — راجع configuration. لاحظ أن هذا ينطبق على واجهة برمجة تطبيقات Kubernetes فقط: إذ تنطلق استدعاءات واجهة برمجة تطبيقات موفر الخدمة السحابية (مثل EKS وEC2 على AWS) من شبكة ClickHouse Cloud عبر افتراض دور عبر الحسابات، ولا يمكن مطلقًا توجيهها عبر Tailscale — راجع واجهات برمجة تطبيقات موفر الخدمة السحابية مقابل واجهة برمجة تطبيقات Kubernetes.
على AWS، تستخدم حركة البيانات بين Customer BYOC VPC الخاص بك وS3 بروتوكول HTTPS (المنفذ 443) عبر واجهة برمجة تطبيقات AWS S3 لبيانات جدول والنسخ الاحتياطية، وكذلك لأرشيفات المقاييس والسجلات طويلة الأمد في حال تمكينها. تُكتب السجلات الحية على وحدات التخزين المرفقة بعُقد ClickHouse الخاصة بك بدلًا من تخزين الكائنات — راجع حدود الشبكة. تمر هذه الحركة عبر نقطة نهاية VPC من نوع بوابة لـ S3، لذا تبقى داخل شبكة AWS ولا تعبر الإنترنت العام ولا تترتب عليها رسوم بوابة NAT. وبالمثل، على GCP، يستخدم الوصول إلى واجهات برمجة تطبيقات Google خدمة Private Google Access. وعلى Azure، تُخزَّن البيانات في حسابات Azure Blob Storage ضمن اشتراكك.
لا. تُخزَّن كائنات blob لبيانات جدول ضمن تخطيط مشترك من دون مسارات مخصصة لكل جدول، لذلك لا يمكن إسناد objects إلى الجداول، وأي تعديل مباشر قد يؤدي إلى تلف خدماتك. لا تعدّل محتويات حاوية مباشرةً مطلقًا؛ وإذا اشتبهت في وجود مشكلة، فافتح طلب دعم.
تنتهي اتصالات client عند موازن التحميل على منافذ TLS: 8443 (واجهة HTTPS) و9440 (native protocol عبر TLS)؛ كما يوجّه المنفذ 443 إلى واجهة HTTPS. لا تكون MySQL interface (المنفذ 3306) مكشوفة حاليًا في BYOC — وهي مدرجة في خارطة الطريق (راجع overview).داخل الشبكة، تستخدم الاتصالات الداخلية للعنقود native protocol على المنفذ 9000، وHTTP على المنفذ 8123، واتصالات interserver على المنفذ 9009 للنسخ المتماثل وdistributed queries. لا تُكشف هذه المنافذ الداخلية ومنافذ ClickHouse Keeper مطلقًا على أي موازن التحميل.
مع VPC مُدار من ClickHouse، تحصل كل خدمة افتراضيًا على موازن التحميل عام محمي بقائمة وصول IP؛ ويمكن أيضًا تمكين موازن التحميل خاص، الذي يمكن الوصول إليه من شبكتك والشبكات المقترنة بها، في ClickHouse Cloud console (راجع Load Balancers). مع VPC مُدار من العميل، تنعكس الإعدادات الافتراضية ولا يتم تمكين سوى موازن التحميل خاص. يُفرض ترشيح IP على طبقة ingress proxy، لذا قد تبدو منافذ موازن التحميل مفتوحة في عمليات الفحص، بينما تُرفض الاتصالات من المصادر غير المدرجة. يمكن تعطيل public endpoint بالكامل بمجرد ألا يعتمد عليه أي شيء. يعرض محدد Connection via في Console نقاط النهاية لكل مسار connection مُمكّن لخدمتك. راجع connectivity.
ليس حاليًا. تُوفَّر نقاط نهاية خدمة ضمن clickhouse-byoc.com مع certificates مُدارة بواسطة ClickHouse.
لا توجد قائمة موحدة منشورة بالنقاط الطرفية. تتطلب المجموعة اتصالًا فعالًا بالإنترنت للخروج (مباشرةً أو عبر NAT)، بالإضافة إلى وصول خاص إلى واجهات برمجة تطبيقات موفر السحابة — راجع متطلبات اتصال الشبكة. إذا كانت سياسة الشبكة لديك تتطلب قائمة صريحة، فاتصل بالدعم لمراجعة إعدادك.
تتطلب بعض مكونات المنصة، بصورة مشروعة، امتيازات مرتفعة أو وصولًا إلى نظام ملفات المضيف، مثل برنامج تشغيل EBS CSI ووظائف تهيئة العقد ومُصدّر عقد Prometheus (الذي يقرأ /proc و/sys). إذا أظهرت أداة الفحص لديك نتائج، فشاركها مع الدعم — وسنؤكد ما إذا كانت كل منها مقصودة بحكم التصميم أو تتطلب إجراءً.
ليس حاليًا لـ BYOC. تُشفّر البيانات أثناء التخزين باستخدام مفاتيح يديرها موفر السحابة. راجع النظرة العامة للاطلاع على القائمة الحالية للميزات المخطط لها.

​
الترقيات والصيانة

تعمل الترقيات بالطريقة نفسها المتبعة في ClickHouse Cloud: تُدرَج الخدمات ضمن قنوات الإصدار (السريعة والمنتظمة والبطيئة) وتلتزم بنوافذ الصيانة المجدولة — تواصل مع الدعم لإعدادها. توقّع جدول تحديث أسبوعي على الأقل. تُنفَّذ الترقيات تدريجيًا، نسخة متماثلة تلو الأخرى (الإنشاء قبل الإزالة)، لذا لا يحدث توقف كامل للخدمة. راجع العمليات.
يتولى ClickHouse ترقيات Kubernetes وينفذها استباقيًا قبل تواريخ انتهاء الدعم لدى المزوّد، وينسّق نافذة الصيانة معك عبر الدعم. تكون ترقيات مستوى التحكم شفافة، أما ترقيات مجموعات العُقد فتتم بعقدة تلو الأخرى وفق نهج الإنشاء قبل الإزالة، لذا قد تلاحظ إعادة تعيين وجيزة للاتصالات عند إعادة تشغيل القرون، ولكن دون فقدان البيانات. راجع العمليات.

​
النسخ الاحتياطية والتعافي من الكوارث

في تخزين الكائنات ضمن حسابك السحابي الخاص — لا تغادر النسخ الاحتياطية بيئتك مطلقًا. يمكن تهيئة جدول النسخ الاحتياطي ومدة الاحتفاظ؛ اتصل بالدعم لتعديلهما.
جميع قواعد البيانات والجداول والكائنات التي أنشأها المستخدم، بالإضافة إلى كيانات الوصول (المستخدمون والأدوار وملفات تعريف الإعدادات وسياسات الصفوف والحصص) والدوال المعرّفة من قبل المستخدم. لا تُضمَّن جداول سجلات النظام، مثل system.query_log.
تشكّل النسخ الاحتياطية سلاسل: نسخة احتياطية كاملة تتبعها نسخ تزايدية تعتمد عليها. النسخة الاحتياطية الكاملة الأساسية مطلوبة لاستعادة أي نسخة تزايدية ضمن سلسلتها، لذا يُحتفَظ بها (وتُخزَّن) إلى أن تنتهي مدة الاحتفاظ بجميع النسخ التزايدية التابعة لها.
بطريقتين: نقاط نهاية النسخ الاحتياطية في ClickHouse Cloud API، ومقاييس النسخ الاحتياطية (عدادات البدء والإكمال والفشل) التي تعرضها حزمة المراقبة داخل الكتلة — نوصي بإعداد تنبيهات لحالات الفشل في نظام المراقبة الخاص بك. راجع قابلية الرصد.
يُنشر BYOC عبر ثلاث مناطق توافر، ولا يُقَرّ بعمليات الكتابة إلا بعد أن يؤكد تخزين الكائنات استلامها. لا يتوفر النسخ المتماثل عبر المناطق حاليًا، لذا يعتمد التعافي من الكوارث على مستوى المنطقة على النسخ الاحتياطية، وتقتصر قيمة RPO القابلة للتحقيق على تكرار النسخ الاحتياطي. يمكن تهيئة تكرار النسخ الاحتياطي ووجهته لتتوافق مع أهدافك، بما في ذلك إجراء نسخ احتياطي إلى حاوية في منطقة أخرى — اتصل بالدعم لإعداد ذلك.

​
قابلية الرصد

تعمل حزمة المراقبة (Prometheus وGrafana وAlertManager) ضمن حسابك، ويمكنك استخدامها مباشرةً عبر الاتصال الخاص: الاستعلام عنها من خلال واجهة برمجة تطبيقات PromQL، أو ربطها اتحاديًا مع Prometheus الخاص بك، أو سحب المقاييس من نقطة النهاية /metrics_all في ClickHouse لكل خدمة. لا يتوفر حاليًا تكامل جاهز مع منصات خارجية مثل Datadog — بل يمكنك التكامل عبر آلية الاستيعاب المتوافقة مع Prometheus. راجع قابلية الرصد للاطلاع على نقاط النهاية والإعداد.

​
التكلفة

فاتورتان منفصلتان: تفرض ClickHouse Cloud رسوماً استناداً إلى الذاكرة المخصصة لخدماتك، بينما يُصدر موفّر الخدمة السحابية فاتورةً مباشرةً عن البنية التحتية الأساسية بسعر التكلفة، من دون أي هامش ربح. تغطي صفحات مرجع التكلفة التفصيلية حالياً AWS: راجع نموذج التكلفة، وخدمات AWS الخاضعة للفوترة، وحدود خدمات AWS.

​
التوافر ودورة الحياة

تتوفر AWS وGCP وAzure بشكل عام للاستخدام الإنتاجي. راجع النظرة العامة للتعرّف على الميزات والمناطق المدعومة في كل سحابة.
أنه خدماتك وبنية BYOC التحتية من ClickHouse console — لا تبدأ بحذف الموارد أو سحب الأذونات من وحدة تحكم موفر الخدمة السحابية، لأن ذلك يقطع اتصال مستوى التحكم أثناء العملية ويفرض إجراء تنظيف يدوي. بعد اكتمال الإنهاء عبر وحدة التحكم، أزل حزمة الإعداد الأولي (CloudFormation stack أو وحدة Terraform) وأي موارد متبقية. في AWS، تُوسم جميع الموارد التي أنشأها ClickHouse بالوسم clickhouse-byoc=true، لذا يمكنك حصرها لاحقًا للتحقق من عدم بقاء أي منها؛ أما في GCP وAzure، فيحدّد المشروع أو الاشتراك المخصص الذي أعددته نطاق ما ينبغي مراجعته.

​
اتفاقيات مستوى الخدمة لوقت التشغيل

لا، نظرًا لأن طبقة البيانات مستضافة في البيئة السحابية الخاصة بالعميل، فإن توفّر الخدمة يعتمد على موارد لا تقع ضمن سيطرة ClickHouse. لذلك، لا يوفّر ClickHouse اتفاقية مستوى خدمة رسمية لوقت التشغيل لعمليات نشر BYOC. لاحظ أن الخدمات قيد التشغيل تعمل بشكل مستقل عن مستوى التحكم في ClickHouse: إذ لا يؤدي انقطاع مستوى التحكم إلى إيقاف الخدمات التي تعمل في حسابك. إذا كانت لديك أسئلة إضافية، فيُرجى التواصل مع support@clickhouse.com.
آخر تعديل في ٢٦ سبتمبر ٢٠٢٦