يناقش هذا الدليل توصياتنا العامة بشأن الأجهزة، وقدرات المعالجة، والذاكرة، وإعدادات الأقراص لمستخدمي الإصدار مفتوح المصدر. إذا كنت ترغب في تبسيط إعدادك، فنوصي باستخدام ClickHouse Cloud، إذ إنها تتوسع تلقائيًا وتتكيف مع أحمال العمل لديك مع تقليل التكاليف المرتبطة بإدارة البنية التحتية.
يعتمد تكوين مجموعة ClickHouse لديك بدرجة كبيرة على حالة الاستخدام الخاصة بتطبيقك وأنماط أحمال العمل. عند تخطيط معمارية نظامك، يجب أن تأخذ العوامل التالية في الاعتبار:
- التزامن (الطلبات في الثانية)
- معدل النقل (الصفوف المعالجة في الثانية)
- حجم البيانات
- سياسة الاحتفاظ بالبيانات
- تكاليف الأجهزة
- تكاليف الصيانة
تعتمد أنواع الأقراص التي ينبغي استخدامها مع ClickHouse على حجم البيانات ومتطلبات زمن الاستجابة أو معدل النقل.
لزيادة الأداء إلى أقصى حد، نوصي بإرفاق وحدات تخزين SSD ذات IOPS مخصّصة مسبقًا من AWS مباشرةً، أو الخيار المكافئ من موفّر السحابة الذي تستخدمه، لما يوفّره ذلك من تحسين لعمليات IO.
لخفض التكاليف، يمكنك استخدام وحدات تخزين EBS ذات أغراض عامة من نوع SSD.
يمكنك أيضًا اعتماد تخزين متدرج باستخدام أقراص SSD وHDD ضمن معمارية hot/warm/cold. أو يمكنك استخدام AWS S3 للتخزين بهدف فصل الحوسبة عن التخزين. يُرجى الاطلاع على دليلنا لاستخدام ClickHouse مفتوح المصدر مع فصل الحوسبة عن التخزين هنا. ويكون فصل الحوسبة عن التخزين متاحًا افتراضيًا في ClickHouse Cloud.
ما نوع CPU الذي ينبغي أن أستخدمه؟
يعتمد نوع CPU المناسب على نمط استخدامك. وبوجه عام، فإن التطبيقات التي تتضمن عددًا كبيرًا من الاستعلامات المتزامنة والمتكررة، أو التي تعالج كميات أكبر من البيانات، أو التي تستخدم UDFs كثيفة الحوسبة، ستحتاج إلى عدد أكبر من أنوية CPU.
التطبيقات ذات زمن الاستجابة المنخفض أو الموجّهة للعملاء
بالنسبة إلى متطلبات زمن الاستجابة في حدود عشرات المللي ثانية، مثل أعباء العمل الموجّهة للعملاء، نوصي باستخدام فئة i3 أو فئة i4i من AWS، أو العروض المكافئة من موفر السحابة لديك، لأنها مُحسّنة لعمليات IO.
التطبيقات عالية التزامن
بالنسبة إلى أعباء العمل التي تحتاج إلى تحسين التزامن (أكثر من 100 استعلام في الثانية)، نوصي باستخدام سلسلة C المحسّنة للحوسبة من AWS أو العرض المكافئ من موفر السحابة لديك.
حالة استخدام مستودعات البيانات
بالنسبة إلى أعباء عمل مستودعات البيانات والاستعلامات التحليلية المخصصة، نوصي باستخدام سلسلة R من AWS أو العرض المكافئ من موفر السحابة لديك، لأنها مُحسّنة للذاكرة.
ما النسبة المناسبة لاستخدام CPU؟
لا توجد نسبة قياسية مستهدفة لاستخدام CPU في ClickHouse. استخدم أداة مثل iostat لقياس متوسط استخدام CPU، ثم اضبط حجم خوادمك وفقًا لذلك للتعامل مع الارتفاعات المفاجئة في حركة المرور. ومع ذلك، في حالات استخدام التحليلات أو مستودعات البيانات التي تتضمن استعلامات آنية، ينبغي أن تستهدف استخدام CPU بين 10% و20%.
كم عدد أنوية CPU التي ينبغي أن أستخدمها؟
يعتمد عدد أنوية CPU التي ينبغي أن تستخدمها على عبء العمل لديك. ومع ذلك، نوصي عمومًا بنسب الذاكرة إلى نواة CPU التالية استنادًا إلى نوع CPU لديك:
- M-type (حالات الاستخدام العامة): نسبة ذاكرة إلى نواة CPU تبلغ 4 GB:1
- R-type (حالات استخدام مستودعات البيانات): نسبة ذاكرة إلى نواة CPU تبلغ 8 GB:1
- C-type (حالات الاستخدام المحسّنة للحوسبة): نسبة ذاكرة إلى نواة CPU تبلغ 2 GB:1
على سبيل المثال، عند استخدام وحدات CPU من النوع M، نوصي بتخصيص 100GB من الذاكرة لكل 25 نواة CPU. ولتحديد مقدار الذاكرة المناسب لتطبيقك، من الضروري إجراء profiling لاستخدام الذاكرة. يمكنك قراءة هذا الدليل حول استكشاف مشكلات الذاكرة وإصلاحها أو استخدام لوحة observability المدمجة لمراقبة ClickHouse.
كما هو الحال مع اختيارك لـ CPU، فإن اختيارك لنسبة الذاكرة إلى التخزين ونسبة الذاكرة إلى CPU يعتمد على حالة الاستخدام لديك.
يعتمد الحجم المطلوب من RAM عمومًا على:
- مدى تعقيد الاستعلامات.
- مقدار البيانات التي تُعالَج في الاستعلامات.
ومع ذلك، وبوجه عام، كلما زادت الذاكرة المتاحة لديك، زادت سرعة تنفيذ استعلاماتك.
إذا كانت حالة الاستخدام لديك حساسة من ناحية التكلفة، فقد تكفي كميات أقل من الذاكرة، إذ يمكن تمكين الإعدادات (max_bytes_before_external_group_by وmax_bytes_before_external_sort) للسماح بترحيل البيانات إلى القرص، لكن تجدر الإشارة إلى أن ذلك قد يؤثر بشكل كبير في أداء الاستعلامات.
ما نسبة الذاكرة إلى التخزين التي ينبغي اعتمادها؟
بالنسبة إلى أحجام البيانات الصغيرة، تكون نسبة الذاكرة إلى التخزين 1:1 مقبولة، لكن يجب ألا تقل الذاكرة الإجمالية عن 8GB.
بالنسبة إلى حالات الاستخدام التي تتطلب فترات احتفاظ طويلة بالبيانات أو تتعامل مع أحجام بيانات كبيرة، نوصي بنسبة ذاكرة إلى تخزين تتراوح بين 1:100 و1:130. على سبيل المثال، 100GB من RAM لكل نسخة متماثلة إذا كنت تخزّن 10TB من البيانات.
بالنسبة إلى حالات الاستخدام التي تتطلب وصولًا متكررًا، مثل أعباء العمل الموجّهة للعملاء، نوصي باستخدام ذاكرة أكبر، بنسبة ذاكرة إلى تخزين تتراوح بين 1:30 و1:50.
نوصي بوجود ثلاث نسخ متماثلة على الأقل لكل شارد (أو نسختين متماثلتين مع Amazon EBS). بالإضافة إلى ذلك، نوصي بالتحجيم الرأسي لجميع النسخ المتماثلة قبل إضافة نسخ متماثلة أخرى (التحجيم الأفقي).
لا يطبّق ClickHouse التجزئة تلقائيًا، كما أن إعادة تجزئة مجموعة بياناتك ستتطلب موارد حوسبة كبيرة. لذلك، نوصي عمومًا باستخدام أكبر خادم متاح لتجنّب الاضطرار إلى إعادة تجزئة بياناتك مستقبلًا.
ننصح باستخدام ClickHouse Cloud، إذ يتوسّع تلقائيًا ويتيح لك التحكّم بسهولة في عدد النسخ المتماثلة بما يناسب حالة الاستخدام لديك.
تهيئات نموذجية لأعباء العمل الكبيرة
تعتمد تهيئات ClickHouse بدرجة كبيرة على المتطلبات المحددة لتطبيقك. يُرجى التواصل مع فريق المبيعات إذا كنت ترغب في أن نساعدك على تحسين معمارية نظامك من حيث التكلفة والأداء.
ولتقديم إرشادات (لا توصيات)، فيما يلي أمثلة على تهيئات يستخدمها مستخدمو ClickHouse في بيئات الإنتاج:
شركة SaaS للأعمال من Fortune 500
| التخزين |
| حجم البيانات الجديدة شهريًا | 30TB |
| إجمالي التخزين (مضغوط) | 540TB |
| الاحتفاظ بالبيانات | 18 شهرًا |
| سعة القرص لكل عقدة | 25TB |
| CPU |
| التزامن | أكثر من 200 استعلام متزامن |
| عدد النسخ المتماثلة (بما في ذلك زوج التوافر العالي) | 44 |
| vCPU لكل عقدة | 62 |
| إجمالي vCPU | 2700 |
| الذاكرة |
| إجمالي RAM | 11TB |
| RAM لكل نسخة متماثلة | 256GB |
| نسبة RAM إلى vCPU | 4 GB:1 |
| نسبة RAM إلى القرص | 1:50 |
| التخزين |
| حجم بيانات السجلات الشهري | 4860TB |
| إجمالي التخزين (مضغوط) | 608TB |
| الاحتفاظ بالبيانات | 30 يومًا |
| سعة القرص لكل عقدة | 13TB |
| CPU |
| عدد النسخ المتماثلة (بما في ذلك زوج التوافر العالي) | 38 |
| vCPU لكل عقدة | 42 |
| إجمالي vCPU | 1600 |
| الذاكرة |
| إجمالي RAM | 10TB |
| RAM لكل نسخة متماثلة | 256GB |
| نسبة RAM إلى vCPU | 6 GB:1 |
| نسبة RAM إلى القرص | 1:60 |
فيما يلي مقالات مدوّنة منشورة حول معماريات من شركات تستخدم ClickHouse مفتوح المصدر:
آخر تعديل في ٢٥ يونيو ٢٠٢٦