ClickHouse Cloud واجهة برمجة تطبيقات

تُعد ClickHouse Cloud API واجهة برمجة تطبيقات REST صُممت للمطورين لتسهيل إدارة المؤسسات والخدمات على ClickHouse Cloud. وباستخدام Cloud API الخاصة بنا، يمكنك إنشاء الخدمات وإدارتها، وإنشاء مفاتيح API، وإضافة أعضاء إلى مؤسستك أو إزالتهم، وغير ذلك الكثير.

تعرّف على كيفية إنشاء أول مفتاح API والبدء في استخدام ClickHouse Cloud API.

تم إنشاء واجهة برمجة تطبيقات ClickHouse Cloud استنادًا إلى مواصفة OpenAPI المفتوحة المصدر لضمان إمكانية استهلاكها من جانب العميل بشكل متوقَّع. إذا كنت بحاجة إلى استهلاك وثائق واجهة برمجة تطبيقات ClickHouse Cloud برمجيًا، فنحن نوفر نقطة نهاية Swagger بصيغة JSON عبر https://api.clickhouse.cloud/v1. ويمكنك أيضًا العثور على وثائق واجهة برمجة تطبيقات عبر واجهة مستخدم Swagger.

يُسمح للمطورين بما يصل إلى 100 مفتاح API لكل مؤسسة. ولكل مفتاح API حد أقصى يبلغ 10 طلبات خلال نافذة مدتها 10 ثوانٍ. إذا كنت ترغب في زيادة عدد مفاتيح API أو عدد الطلبات لكل نافذة مدتها 10 ثوانٍ في مؤسستك، فيرجى التواصل مع support@clickhouse.com

يتيح لك موفّر Terraform الرسمي من ClickHouse استخدام البنية التحتية بوصفها شيفرة لإنشاء تهيئات قابلة للتنبؤ وخاضعة للتحكم في الإصدارات، مما يجعل عمليات النشر أقل عرضةً للأخطاء بكثير.

يمكنك الاطلاع على وثائق موفّر Terraform في سجل Terraform.

إذا كنت ترغب في المساهمة في موفّر Terraform الخاص بـ ClickHouse، فيمكنك الاطلاع على المصدر في مستودع GitHub.

توفّر ClickHouse موفّرَين رسميَّين لـ Terraform - موفّر ClickHouse Cloud للبنية التحتية السحابية وموفّر DBops للكائنات على مستوى قاعدة البيانات. وكلاهما يتّبع نموذج الإصدار نفسه.

كل إصدار هو build واحد يضم جميع الموارد. وتُشحن موارد الميزات التي لم تصل بعد إلى مرحلة التوافر العام إلى جانب موارد GA، مع تمييزها بأنها beta — فلا يوجد build منفصل ولا يلزم تثبيت أي شيء لاستخدامها.

يُشار إلى مورد beta في موضعين:

• عند plan وapply، على شكل تحذير Beta Resource. لا يتعطل Terraform بسبب التحذيرات، لذا يستمر التنفيذ بشكل طبيعي.
• في وثائقه، عبر تنبيه ينص على "هذا المورد في beta".

تعني Beta أن المخطط والسلوك قد يتغيران في إصدار موفّر مستقبلي. أما كل ما لا يحمل هذا الوسم فهو GA ومشمول بضمانات التوافق المعتادة.

يستخدم كلا الموفّرين نظام الإصدارات الدلالية (MAJOR.MINOR.PATCH). ويُزاد رقم الإصدار الرئيسي عند حدوث تغييرات غير متوافقة، ورقم الإصدار الثانوي عند إضافة ميزات أو موارد جديدة، ورقم إصدار التصحيحات عند إصلاح العيوب. وتُطرح الإصدارات عند الحاجة بدلًا من اتباع جدول زمني ثابت.

تسبق الإصدارات ذات اللاحقة -alphaN (مثل 3.15.0-alpha3) نموذج الإصدار ذي البنية الواحدة. وتظل متاحة، لكنها لم تعد تُنتج.

عندما تصل ميزة إلى التوافر العام، يُزال وسم Beta من موردها في الإصدار التالي من الموفّر: يتوقف ظهور التحذير عند إنشاء plan، وتُزال الملاحظة من الوثائق. ولا يتغير أي شيء آخر — لا تعديلات على الإعدادات، ولا ترحيل للحالة، ولا تبديل بين الإصدارات المجمّعة.

يكون العدد الافتراضي للنسخ المتماثلة التي تُنشأ لكل خدمة هو 3 في مستويَي Scale وEnterprise، بينما يكون 1 في مستوى Basic. وفي مستويَي Scale وEnterprise، يمكن تعديل هذا العدد بتمرير الحقل numReplicas في طلب إنشاء الخدمة. يجب أن تكون قيمة الحقل numReplicas بين 2 و20 بالنسبة إلى الخدمة الأولى في مستودع. أما الخدمات التي تُنشأ في مستودع حالي، فيمكن أن يكون عدد النسخ المتماثلة فيها منخفضًا حتى 1.

نوصي بزيارة قناة Slack الخاصة بنا أولًا للحصول على دعم سريع. وإذا كنت ترغب في الحصول على مساعدة إضافية أو مزيد من المعلومات حول واجهة برمجة التطبيقات وإمكاناتها، فيرجى التواصل مع ClickHouse Support عبر https://console.clickhouse.cloud/support