الانتقال إلى المحتوى الرئيسي
أولًا، لنتحدث عن سبب طرح هذا السؤال أصلًا. هناك سببان رئيسيان:
  1. يجري تطوير ClickHouse بوتيرة سريعة جدًا، وعادةً ما تصدر أكثر من 10 إصدارات مستقرة سنويًا. وهذا يترك أمام المستخدمين نطاقًا واسعًا من الإصدارات للاختيار من بينها، ما يجعل الاختيار غير بسيط.
  2. يريد بعض المستخدمين تجنّب قضاء الوقت في تحديد الإصدار الأنسب لحالة الاستخدام الخاصة بهم، ويفضّلون ببساطة اتباع نصيحة شخص آخر.
السبب الثاني أكثر جوهرية، لذا سنبدأ به ثم نعود إلى كيفية التنقّل بين إصدارات ClickHouse المختلفة.

​
ما إصدار ClickHouse الذي توصي به؟

قد يكون من المغري الاستعانة بمستشارين أو الاعتماد على بعض الخبراء المعروفين للتنصل من مسؤولية بيئة الإنتاج لديك. فتثبّت إصدارًا معينًا من ClickHouse أوصى به شخص آخر؛ وإذا ظهرت فيه مشكلة ما، فليست هذه مسؤوليتك بل مسؤولية ذلك الشخص. لكن هذا التفكير فخ كبير. فلا أحد من خارج شركتك يعرف ما الذي يجري في بيئة الإنتاج لديك أفضل منك. إذًا، كيف تختار على نحو صحيح إصدار ClickHouse الذي سترقّي إليه؟ أو كيف تختار أول إصدار من ClickHouse؟ أولًا، عليك أن تستثمر في إعداد بيئة ما قبل الإنتاج واقعية. وفي عالم مثالي، قد تكون هذه البيئة نسخة ظل مطابقة تمامًا، لكن ذلك يكون مكلفًا في العادة. فيما يلي بعض النقاط الأساسية لتحقيق درجة معقولة من التطابق في بيئة ما قبل الإنتاج بتكلفة ليست مرتفعة جدًا:
  • يجب أن تشغّل بيئة ما قبل الإنتاج مجموعة استعلامات قريبة قدر الإمكان من تلك التي تنوي تشغيلها في الإنتاج:
    • لا تجعلها بيئة للقراءة فقط مع بعض البيانات الجامدة.
    • ولا تجعلها بيئة للكتابة فقط يقتصر دورها على نسخ البيانات من دون إنشاء التقارير المعتادة.
    • ولا تقم بمسحها بالكامل بدلًا من تطبيق تغييرات المخطط.
  • استخدم عينة من بيانات الإنتاج والاستعلامات الحقيقية. وحاول اختيار عينة تظل ممثلة وتجعل استعلامات SELECT تُرجع نتائج معقولة. واستخدم إخفاء الهوية إذا كانت بياناتك حساسة وكانت السياسات الداخلية لا تسمح بخروجها من بيئة الإنتاج.
  • تأكد من أن بيئة ما قبل الإنتاج مشمولة بأدوات المراقبة والتنبيه لديك بالطريقة نفسها المطبقة على بيئة الإنتاج.
  • إذا كانت بيئة الإنتاج لديك تمتد عبر عدة مراكز بيانات أو مناطق، فاجعل بيئة ما قبل الإنتاج كذلك.
  • إذا كانت بيئة الإنتاج لديك تستخدم ميزات معقدة مثل النسخ المتماثل، والجداول الموزعة، والعروض المادية المتتالية، فتأكد من تهيئتها بشكل مماثل في بيئة ما قبل الإنتاج.
  • هناك مفاضلة بين استخدام عدد مماثل تقريبًا من الخوادم أو الآلات الافتراضية في بيئة ما قبل الإنتاج كما في الإنتاج ولكن بأحجام أصغر، وبين استخدام عدد أقل بكثير منها ولكن بالأحجام نفسها. قد يلتقط الخيار الأول مشكلات إضافية متعلقة بالشبكة، بينما يكون الخيار الثاني أسهل في الإدارة.
المجال الثاني الذي ينبغي الاستثمار فيه هو بنية تحتية للاختبارات المؤتمتة. لا تفترض أن مجرد تنفيذ نوع معين من الاستعلامات بنجاح مرة واحدة يعني أنه سيستمر في العمل إلى الأبد. لا بأس بوجود بعض unit tests التي يُجرى فيها محاكاة ClickHouse، لكن تأكد من أن منتجك يحتوي على مجموعة معقولة من الاختبارات المؤتمتة التي تُشغَّل على ClickHouse حقيقي وتتحقق من أن جميع حالات الاستخدام المهمة ما تزال تعمل كما هو متوقع. ويمكن أن تكون خطوة إضافية إلى الأمام هي المساهمة بهذه الاختبارات المؤتمتة في البنية التحتية للاختبارات مفتوحة المصدر الخاصة بـ ClickHouse، والتي تُستخدم باستمرار في تطويره اليومي. ومن المؤكد أن ذلك سيتطلب وقتًا وجهدًا إضافيين لتعلّم كيفية تشغيلها، ثم كيفية تكييف اختباراتك مع هذا الإطار، لكنه سيؤتي ثماره لأنه يضمن اختبار إصدارات ClickHouse عليها بالفعل عند الإعلان عنها على أنها مستقرة، بدلًا من إضاعة الوقت مرارًا في الإبلاغ عن المشكلة بعد وقوعها ثم انتظار تنفيذ إصلاح للخلل، وترحيله إلى الإصدارات الأقدم، ثم إصداره. بل إن بعض الشركات تتبع مثل هذه المساهمات الاختبارية في البنية التحتية بوصفها سياسة داخلية (وتُسمى Beyonce’s Rule في Google). عندما تكون بيئة ما قبل الإنتاج والبنية التحتية للاختبارات لديك جاهزتين، يصبح اختيار أفضل إصدار أمرًا مباشرًا:
  1. شغّل اختباراتك المؤتمتة بانتظام على إصدارات ClickHouse الجديدة. يمكنك فعل ذلك حتى مع إصدارات ClickHouse الموسومة بأنها testing، لكن لا يُنصح بالانتقال بها إلى الخطوات التالية.
  2. انشر إصدار ClickHouse الذي اجتاز الاختبارات إلى بيئة ما قبل الإنتاج، وتحقق من أن جميع العمليات تعمل كما هو متوقع.
  3. أبلغ عن أي مشكلات اكتشفتها في ClickHouse GitHub Issues.
  4. إذا لم تكن هناك مشكلات كبيرة، فمن المفترض أن يكون من الآمن البدء في نشر إصدار ClickHouse في بيئة الإنتاج لديك. كما أن الاستثمار في أتمتة الإصدارات التدريجية التي تطبق نهجًا مشابهًا لـ canary releases أو green-blue deployments قد يقلل أيضًا من مخاطر المشكلات في الإنتاج.
كما قد تكون لاحظت، لا يوجد شيء خاص بـ ClickHouse في النهج الموصوف أعلاه — فالناس يفعلون ذلك مع أي جزء من البنية التحتية يعتمدون عليه إذا كانوا يتعاملون مع بيئة الإنتاج لديهم بجدية.

​
كيف تختار بين إصدارات ClickHouse؟

إذا ألقيت نظرة على محتويات مستودع حزم ClickHouse، فسترى نوعين من الحزم:
  1. stable
  2. lts (دعم طويل الأمد)
فيما يلي بعض الإرشادات لمساعدتك على الاختيار بينهما:
  • stable هو نوع الحزم الذي نوصي به افتراضيًا. تُصدر هذه الحزم شهريًا تقريبًا (وبالتالي توفّر ميزات جديدة بتأخير معقول)، كما أن أحدث ثلاثة إصدارات مستقرة تحظى بالدعم من حيث التشخيصات وترحيل إصلاحات الأخطاء إلى الإصدارات الأقدم.
  • تُصدر حزم lts مرتين سنويًا، وتبقى مدعومة لمدة عام بعد إصدارها الأولي. وقد تفضّلها على stable في الحالات التالية:
    • لدى شركتك سياسات داخلية لا تسمح بالترقيات المتكررة أو باستخدام برمجيات غير LTS.
    • تستخدم ClickHouse ضمن بعض المنتجات الثانوية التي لا تتطلب ميزات ClickHouse معقدة، أو لا تتوفر لها موارد كافية للحفاظ على تحديثها.
كثير من الفرق التي تعتقد في البداية أن lts هو الخيار الأنسب تنتهي غالبًا إلى الانتقال إلى stable على أي حال بسبب ميزة حديثة مهمة لمنتجها.
هناك نقطة أخرى ينبغي وضعها في الاعتبار عند ترقية ClickHouse: نحن نحرص دائمًا على التوافق بين الإصدارات، لكن أحيانًا لا يكون من العملي الحفاظ على كل شيء كما هو، وقد تتغير بعض التفاصيل البسيطة. لذا احرص على مراجعة سجل التغييرات قبل الترقية لمعرفة ما إذا كانت هناك أي ملاحظات بشأن تغييرات غير متوافقة مع الإصدارات السابقة.
آخر تعديل في ٢٩ يونيو ٢٠٢٦