- بما أن السعة تُضاف إلى العنقود قبل إزالة السعة القديمة، فإن السعة الإجمالية للعنقود لا تنخفض بخلاف نهج الإزالة أولًا. وبالطبع، قد تظل الأحداث غير المخطط لها، مثل أعطال العُقد أو الأقراص وما إلى ذلك، تحدث في البيئة السحابية.
- يكون هذا النهج مفيدًا بشكل خاص عندما يكون العنقود تحت حمل كثيف، لأنه يمنع تحميل النسخ المتماثلة الحالية فوق طاقتها كما قد يحدث مع نهج الإزالة أولًا.
- ولأن النسخ المتماثلة يمكن إضافتها بسرعة من دون الحاجة إلى انتظار إزالة النسخ أولًا، فإن هذا النهج يوفّر تجربة توسعة أسرع وأكثر استجابة.
- تنتظر عمليات MBB حتى تنتهي أعباء العمل الحالية على النسخ المتماثلة الحالية قبل إنهائها. وهذه المدة مضبوطة حاليًا على ساعة واحدة، ما يعني أن عمليات التوسعة أو الترقية قد تنتظر مدة تصل إلى ساعة بسبب استعلام طويل التشغيل على نسخة متماثلة قبل إزالة تلك النسخة. بالإضافة إلى ذلك، إذا كانت هناك عملية نسخ احتياطي قيد التشغيل على نسخة متماثلة، فستُترك حتى تكتمل قبل إنهاء تلك النسخة.
- نظرًا إلى وجود وقت انتظار قبل إنهاء النسخة المتماثلة، فقد تنشأ حالات يكون فيها لدى العنقود عدد من النسخ المتماثلة يتجاوز الحد الأقصى المحدد له. على سبيل المثال، قد تكون لديك خدمة تضم 6 نسخ متماثلة إجمالًا، ولكن مع وجود عملية MBB قيد التنفيذ، قد تُضاف 3 نسخ متماثلة إضافية إلى العنقود ليصبح المجموع 9 نسخ متماثلة، بينما تظل النسخ الأقدم لا تزال تخدم الاستعلامات. وهذا يعني أنه لفترة من الوقت، سيكون لدى العنقود عدد نسخ متماثلة أكبر من العدد المطلوب. بالإضافة إلى ذلك، قد تتداخل عدة عمليات MBB معًا، مما يؤدي إلى تراكم النسخ المتماثلة. ويمكن أن يحدث هذا، على سبيل المثال، في السيناريوهات التي تُرسل فيها عدة طلبات توسعة رأسية إلى العنقود عبر واجهة API. لدى ClickHouse Cloud آليات تحقّق للحد من عدد النسخ المتماثلة التي قد تتراكم في العنقود.
- مع عمليات MBB، يُحتفَظ ببيانات جدول النظام لمدة 30 يومًا. وهذا يعني أنه في كل مرة تحدث فيها عملية MBB على عنقود، تُنسخ بيانات جدول النظام الخاصة بآخر 30 يومًا من النسخ المتماثلة القديمة إلى الجديدة.