Skip to main content
يوفّر ClickHouse Managed Postgres خيارات مرنة للتحجيم بما يتوافق مع متطلبات أعباء العمل لديك. ومع توفّر أكثر من 50 نوعًا من المثيلات المعتمدة على NVMe للاختيار من بينها، يمكنك تحجيم CPU والذاكرة والتخزين بشكل مستقل لتحسين الأداء والتكلفة بما يناسب حالة الاستخدام الخاصة بك.

أنواع المثيلات والمرونة

يوفّر ClickHouse Managed Postgres مجموعة واسعة من أنواع المثيلات، وقد صُمّم كلٌّ منها ليلائم خصائص مختلفة لأعباء العمل:
  • أكثر من 50 نوعًا من المثيلات متاحة ضمن تكوينات محسّنة للحوسبة والذاكرة والتخزين
  • تخزين مدعوم بـ NVMe في جميع أنواع المثيلات لضمان عمليات إدخال/إخراج على القرص متسقة وعالية الأداء
  • التحجيم المستقل للموارد: اختر التوازن المناسب بين CPU والذاكرة والتخزين وفقًا لعبء العمل لديك

اختيار نوع المثيل المناسب

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

كيف تعمل عملية التحجيم

عند تغيير أنواع المثيلات، يُجري ClickHouse Managed Postgres عملية التحجيم الرأسي توفّر بنية تحتية جديدة وتنقل قاعدة بياناتك بأقل قدر ممكن من التعطل.

عملية التوسعة

يُنشئ سير عمل التوسعة مثيلًا احتياطيًا جديدًا من النسخ الاحتياطية ويُجري عملية failover محكومة:
  1. تجهيز المثيل الاحتياطي: يُنشأ مثيل احتياطي جديد بنوع المثيل المستهدف (CPU والذاكرة وإعدادات التخزين)
  2. الاستعادة من النسخ الاحتياطية في S3: يُهيَّأ المثيل الاحتياطي من خلال الاستعادة من أحدث نسخة احتياطية مخزنة في S3
  3. إعادة تطبيق WAL بالتوازي: يطبّق المثيل الاحتياطي جميع تغييرات Write-Ahead Log (WAL) منذ النسخة الاحتياطية باستخدام آليات restore متوازية مدعومة من WAL-G
    • يتيح WAL-G عمليات restore سريعة ومتوازية
    • منشئ WAL-G عضو في فريق Ubicloud الذي عقدنا معه شراكة، ما يضمن خبرة عميقة ومستوى عاليًا من التحسين
  4. اللحاق بالنسخ المتماثل: يلحق المثيل الاحتياطي بالمثيل الأساسي من خلال بث تغييرات WAL المستمرة وتطبيقها
  5. Failover: بمجرد أن يصبح المثيل الاحتياطي متزامنًا بالكامل، تؤدي عملية failover محكومة إلى ترقية المثيل الاحتياطي ليصبح المثيل الأساسي الجديد
    • هذه هي الخطوة الوحيدة التي تسبب فترة توقف (~30 ثانية)
    • تنقطع جميع الاتصالات النشطة أثناء failover
    • يجب على العملاء إعادة الاتصال بعد اكتمال failover
  6. إخراج المثيل القديم من الخدمة: يُخرج المثيل الأصلي من الخدمة بعد اكتمال failover

مدة التوسيع

يعتمد إجمالي الوقت المطلوب للتوسيع بشكل أساسي على حجم قاعدة البيانات لديك ومقدار بيانات WAL التي يجب إعادة تطبيقها من النسخ الاحتياطية:
  • استعادة النسخة الاحتياطية: الوقت اللازم لاستعادة أحدث نسخة احتياطية كاملة من S3 إلى المثيل الجديد
  • إعادة تطبيق WAL: الوقت اللازم لإعادة تطبيق تغييرات WAL التزايدية منذ آخر نسخة احتياطية كاملة
  • الاستعادة المتوازية: تُسرّع آليات الاستعادة المتوازية في WAL-G هذه العملية بشكل كبير
قد تتراوح مدة الاستعادة من بضع دقائق إلى بضع ساعات، لكن الصيانة/فترة التوقف تكون محدودة جدًا (حوالي 30 ثانية فقط).
الحد الأدنى من فترة التوقفسيتعرض تطبيقك لفترة توقف تبلغ نحو 30 ثانية أثناء التحويل عند الفشل، بغض النظر عن المدة التي تستغرقها عملية التوسيع بالكامل. تتم جميع أعمال الاستعادة واللحاق بالبيانات في الخلفية على المثيل الاحتياطي.

الاستعادة المتوازية باستخدام WAL-G

يستخدم ClickHouse Managed Postgres أداة WAL-G لتسريع استعادة النسخ الاحتياطية أثناء عمليات التحجيم. واللافت أن مطوّر WAL-G عضو في فريق Ubicloud الذي أقمنا معه شراكة، ما يضيف خبرة عميقة إلى عملية الاستعادة. يوفّر WAL-G ما يلي:
  • التنزيل وفك الضغط بالتوازي: تُجلَب عدة مقاطع من النسخ الاحتياطية من S3 ويُفك ضغطها في الوقت نفسه
  • إعادة تطبيق WAL بكفاءة: تُطبَّق تغييرات WAL التزايدية بالتوازي حيثما أمكن
  • بث مُحسَّن: بث مباشر من تخزين S3 من دون نُسخ وسيطة
  • استعادة سريعة: مع أن الوقت الإجمالي يعتمد على حجم البيانات، فإن النهج المتوازي يجعل العملية سريعة جدًا
تُقلِّل هذه التحسينات بشكل كبير الوقت اللازم لتشغيل مثيل الاحتياطي الجديد. والأهم من ذلك أن الاستعادة تتم بالكامل في الخلفية، ولن يواجه تطبيقك فترة تعطل إلا خلال نافذة failover القصيرة التي تبلغ نحو 30 ثانية.

بدء عملية توسيع السعة

لتوسيع سعة مثيل ClickHouse Managed Postgres لديك:
  1. انتقل إلى علامة تبويب الإعدادات في مثيلك
  2. في قسم التحجيم، مرّر إلى حجم الخدمة
  3. حدّد نوع المثيل المستهدف
  4. راجع التغييرات وانقر على “تطبيق التغييرات”

استراتيجيات التوسع

التحجيم الرأسي

تُعدّ التحجيم الرأسي (تغيير أنواع المثيلات) الطريقة الأساسية لضبط الموارد في ClickHouse Managed Postgres. ويتيح هذا النهج ما يلي:
  • تحكم دقيق: اختر من بين أكثر من 50 نوعًا من المثيلات لضبط CPU والذاكرة والتخزين بدقة
  • تحسين أعباء العمل: اختر إعدادات مُحسَّنة لعبء العمل لديك (سواء كان كثيف الحوسبة أو الذاكرة أو التخزين)
  • كفاءة من حيث التكلفة: ادفع فقط مقابل الموارد التي تحتاج إليها، من دون تخصيص موارد زائدة

النسخ المتماثلة للقراءة للتوسع الأفقي

بالنسبة إلى أعباء العمل كثيفة القراءة، فكّر في استخدام النسخ المتماثلة للقراءة لتوسيع سعة القراءة أفقيًا:
  • نقل استعلامات القراءة إلى مثيلات النسخ المتماثلة المخصّصة للقراءة
  • كل نسخة متماثلة للقراءة هي مثيل Postgres مستقل تمامًا، وله موارده الحاسوبية وذاكرته الخاصة
  • تبث النسخ المتماثلة للقراءة تغييرات WAL من تخزين الكائنات لتحقيق نسخ متماثل فعّال
يُعد هذا النهج مثاليًا للتطبيقات ذات النسبة المرتفعة من عمليات القراءة إلى الكتابة، مثل لوحات معلومات إعداد التقارير، أو استعلامات التحليلات، أو نقاط نهاية واجهة برمجة التطبيقات كثيفة القراءة.

تحجيم CDC لتكامل ClickHouse

إذا كنت تُكرّر البيانات إلى ClickHouse باستخدام ClickPipes، يمكنك تحجيم مسار CDC (التقاط تغييرات البيانات) بشكل مستقل:
  • تحجيم workers الخاصة بـ CDC من 1 إلى 24 من أنوية CPU
  • تتوسع الذاكرة تلقائيًا إلى 4x عدد أنوية CPU
  • اضبط التحجيم عبر ClickPipes OpenAPI
يتيح لك ذلك تحسين معدل نقل التكرار بشكل منفصل عن موارد مثيل Postgres.

التحجيم التلقائي

يراقب ClickHouse Managed Postgres استخدام القرص ويزيد سعة التخزين تلقائيًا كي لا تنفد المساحة في مثيلك:
  • استخدام القرص بنسبة 85%: تتلقى إشعارًا عبر Cloud Console والبريد الإلكتروني.
  • استخدام القرص بنسبة 90%: يبدأ التحجيم التلقائي. تُزاد سعة التخزين إلى الحجم الأكبر التالي المتاح لعائلة مثيلك. تبقى وحدة المعالجة المركزية والذاكرة كما هما، ما لم يكن حجم المثيل الحالي لا يدعم قرصًا أكبر، وفي هذه الحالة يُزاد حجم المثيل أيضًا. تُحجَّم النسخ المتماثلة للقراءة بالتوازي مع المثيل الأساسي.
  • استخدام القرص بنسبة 95%: يتجاوز التحويل أي نافذة صيانة مُهيأة ويُنفَّذ فور جاهزية الخادم الجديد.
إذا كان مثيلك يستخدم بالفعل أكبر تهيئة متاحة، فلن يتمكن التحجيم التلقائي من التوسع أكثر. حرر مساحة على القرص أو تواصل مع الدعم.

التحويل والاتصالات

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

وضع القراءة فقط

إذا ملأت عمليات الكتابة القرص بوتيرة أسرع من قدرة التحجيم التلقائي على الاكتمال، تنتقل المثيلة إلى وضع القراءة فقط لمنع امتلاء القرص بالكامل. ويُفعَّل هذا الوضع بناءً على المساحة الحرة المتبقية: تستمر عمليات القراءة في العمل، بينما تفشل عمليات الكتابة بخطأ Postgres القياسي cannot execute INSERT in a read-only transaction. وإذا استمرت المساحة الحرة في التناقص، تُنهى الاتصالات القائمة لضمان تطبيق إعداد القراءة فقط على كل جلسة؛ وتعمل عمليات القراءة مجددًا بمجرد إعادة اتصال العملاء. يُلغى وضع القراءة فقط تلقائيًا عند تعافي المساحة الحرة، وعادةً ما يحدث ذلك مباشرةً بعد اكتمال التحويل إلى التحجيم للأعلى.

مثال

يتعامل مثيل بسعة تخزين قدرها 1024 غيغابايت مع عبء عمل كثيف الكتابة:
  1. عند استخدام 870 غيغابايت (85%)، تتلقى إشعارًا بشأن التخزين.
  2. عند استخدام 922 غيغابايت (90%)، يبدأ التحجيم التلقائي. يُوفَّر خادم بديل بسعة تخزين قدرها 2048 غيغابايت ويُستعاد من أحدث نسخة احتياطية، بينما يواصل مثيلك معالجة حركة المرور.
  3. بعد أن يلحق البديل بالوضع الحالي، يُنفَّذ التحويل، ضمن نافذة الصيانة إذا كانت مهيأة. تنقطع الاتصالات لأقل من دقيقة، ويعيد تطبيقك الاتصال باسم المضيف نفسه، ويعود الاستخدام إلى نحو 45%.
  4. إذا انخفضت المساحة الحرة إلى أقل من 2% (نحو 20 غيغابايت) قبل اكتمال التحويل، ينتقل المثيل إلى وضع القراءة فقط. تُستأنف عمليات الكتابة تلقائيًا بمجرد اكتمال التحويل إلى القرص الأكبر.

موارد إضافية

آخر تعديل في ١٤ أغسطس ٢٠٢٦