跳至主要内容

生产环境中使用哪个 ClickHouse 版本？

·阅读时间：6 分钟

首先，让我们讨论一下为什么人们会问这个问题。有两个关键原因

  1. ClickHouse 的开发速度非常快，通常每年都会发布 10 多个稳定版本。这使得可供选择的版本范围很广，这并非一个简单的选择。
  2. 一些用户希望避免花时间找出哪个版本最适合他们的用例，只是遵循其他人的建议。

第二个原因更加根本，所以我们先从它开始，然后回到浏览各种 ClickHouse 版本。

您推荐使用哪个 ClickHouse 版本？​

雇佣顾问或信任一些知名专家来摆脱对生产环境的责任，这很诱人。您安装其他人推荐的特定 ClickHouse 版本；如果出现问题，就不是您的错，而是其他人的错。这种推理方式是一个很大的陷阱。没有外部人员比您更了解贵公司生产环境中发生的事情。

那么，您如何正确选择要升级到的 ClickHouse 版本？或者，您如何选择第一个 ClickHouse 版本？首先，您需要投资建立一个 **现实的预生产环境**。在理想情况下，它可以是完全相同的影子副本，但这通常很昂贵。

以下是一些在预生产环境中获得合理保真度的关键要点，而成本并不高

  • 预生产环境需要运行与您打算在生产环境中运行的查询尽可能接近的查询集
    • 不要将其设为只读，使用一些冻结数据。
    • 不要将其设为只写，只是复制数据而没有构建一些典型的报告。
    • 不要将其完全清除，而应该应用模式迁移。
  • 使用真实生产数据的样本和查询。尝试选择一个仍然具有代表性的样本，并使 `SELECT` 查询返回合理的结果。如果您的数据是敏感的，并且内部策略不允许其离开生产环境，请使用混淆。
  • 确保您的预生产环境与生产环境一样，受到监控和警报软件的覆盖。
  • 如果您的生产环境跨越多个数据中心或区域，请让您的预生产环境也这样做。
  • 如果您的生产环境使用复杂的功能（如复制、分布式表和级联物化视图），请确保它们在预生产环境中也进行了类似的配置。
  • 在预生产环境中使用大致相同数量的服务器或 VM，但规模更小，或者使用更少但规模更大的服务器，这之间存在权衡。第一个选项可能会捕获额外的网络相关问题，而第二个选项更易于管理。

第二个需要投资的领域是 **自动化测试基础设施**。不要假设如果某种类型的查询已成功执行一次，它就会永远继续执行。可以进行一些 ClickHouse 被模拟的单元测试，但请确保您的产品有一套合理的自动化测试，这些测试针对真实的 ClickHouse 运行，并检查所有重要的用例是否按预期工作。

更进一步的步骤是将这些自动化测试贡献给ClickHouse 的开源测试基础设施，该基础设施在 ClickHouse 的日常开发中持续使用。学习如何运行它，然后如何将你的测试适应此框架，肯定会花费额外的时间和精力，但这将带来回报，确保 ClickHouse 发布时，已经针对这些测试进行了测试，从而避免了在发布稳定后，重复浪费时间报告问题，然后等待错误修复的实现、回退和发布。一些公司甚至将这种对基础设施的测试贡献作为其内部政策，（在 Google 被称为Beyonce’s Rule）。

当您拥有预生产环境和测试基础设施后，选择最佳版本就很简单了

  1. 定期针对新的 ClickHouse 版本运行您的自动化测试。即使对于标记为testing的 ClickHouse 版本，您也可以执行此操作，但不建议将它们用于下一步操作。
  2. 将通过测试的 ClickHouse 版本部署到预生产环境，并检查所有进程是否按预期运行。
  3. 向ClickHouse GitHub Issues报告您发现的任何问题。
  4. 如果没有重大问题，则可以安全地开始将 ClickHouse 版本部署到生产环境。投资于实施类似于金丝雀发布或蓝绿部署方法的渐进式发布自动化，可以进一步降低生产环境中出现问题的风险。

正如您可能已经注意到，上述方法中没有特定于 ClickHouse 的内容 - 任何认真对待生产环境的人都会对他们依赖的任何基础设施执行此操作。

如何选择 ClickHouse 版本？​

如果您查看 ClickHouse 包存储库的内容，您会看到两种类型的包

  1. stable
  2. lts (长期支持)

以下是关于如何在这两者之间进行选择的指南

  • stable 是我们默认推荐的包类型。它们大约每月发布一次（因此以合理的速度提供新功能），并且在诊断和错误修复的回退方面，支持三个最新的稳定版本。
  • lts 每半年发布一次，并且在最初发布后的 1 年内提供支持。在以下情况下，您可能更喜欢它们而不是 stable
    • 您的公司有一些内部政策，不允许您频繁升级或使用非 LTS 软件。
    • 您在一些辅助产品中使用 ClickHouse，这些产品要么不需要任何复杂的 ClickHouse 功能，要么没有足够的资源来保持更新。

许多最初认为 lts 是最佳选择团队，最终还是会切换到 stable，因为他们产品中需要一些最新的功能。

注意

升级 ClickHouse 时，还需要记住的一件事是：我们始终关注跨版本的兼容性，但有时保持兼容性并不合理，一些细微的细节可能会发生变化。因此，请确保您在升级之前查看变更日志，查看是否有任何有关向后不兼容更改的说明。