跳到主要内容
跳到主要内容

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

首先，来看一下大家为什么会问这个问题。主要有两个原因：

  1. ClickHouse 的开发迭代速度非常快，通常每年会发布 10 个以上的稳定版本。可供选择的版本非常多，选起来并不那么简单。
  2. 有些用户不想花时间去摸索哪个版本最适合自己的使用场景，而是希望直接采纳他人的建议。

第二个原因更为根本，所以我们先从这一点说起，然后再回到如何在各个 ClickHouse 版本之间做出选择。

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

人们往往倾向于雇佣顾问，或者依赖一些知名专家，以此来摆脱对生产环境的责任。你安装了某个别人推荐的 ClickHouse 版本；如果这个版本出了问题——那不是你的错，而是别人的错。这种思路是一个大陷阱。没有任何外部人员比你更了解你们公司生产环境中实际发生的情况。

那么，应该如何正确地选择要升级到哪个 ClickHouse 版本？或者，如何选择你的第一个 ClickHouse 版本？首先，你需要投入精力搭建一个真实的预生产环境。在理想情况下，它可以是一个完全相同的影子环境，但这通常成本较高。

下面是一些要点，可以在预生产环境中以不算太高的成本获得合理的真实性：

  • 预生产环境需要运行与你计划在生产中运行的尽可能接近的一组查询：
    • 不要让它只是对一些冻结数据的只读环境。
    • 不要让它只是写入环境，只是复制数据却不构建一些典型报表。
    • 不要在需要执行模式迁移时直接清空它。
  • 使用真实生产数据和查询的样本。尽量选择仍然具有代表性、并且能让 SELECT 查询返回合理结果的样本。如果你的数据很敏感且内部策略不允许数据离开生产环境，则使用脱敏/混淆。
  • 确保预生产环境和生产环境一样，被你的监控和告警软件所覆盖。
  • 如果你的生产环境跨多个数据中心或地区部署，请让预生产环境也做到这一点。
  • 如果你的生产环境使用了诸如复制、分布式表以及级联物化视图等复杂特性，请确保它们在预生产环境中的配置也类似。
  • 在预生产环境中使用与生产大致相同数量但规格更小的服务器或虚拟机，还是使用数量少得多但规格相同的服务器或虚拟机，这是一个权衡。前一种方案可能会暴露更多与网络相关的问题，而后一种方案更易于管理。

第二个值得投入的领域是自动化测试基础设施。不要认为某类查询只要成功执行过一次，它就会永远继续成功执行。使用一些对 ClickHouse 做 mock 的单元测试是可以的，但要确保你的产品有一套合理的自动化测试集，是针对真实的 ClickHouse 运行的，并检查所有重要用例是否依然按预期工作。

更进一步的一步，是把这些自动化测试贡献给 ClickHouse 的开源测试基础设施，这些测试在 ClickHouse 的日常开发中被持续使用。要学习如何运行它，以及之后如何将你的测试适配到这个框架，确实需要一些额外的时间和精力，但这会带来回报：当 ClickHouse 版本被宣布为稳定版时，已经在这些测试上跑过了，而不是一遍又一遍地在事后花时间报告问题，然后再等待 bug 修复的实现、回溯移植和发布。有些公司甚至将对基础设施的此类测试贡献，作为内部政策的一部分（在 Google 被称为 Beyonce's Rule）。

当你已经搭建好了预生产环境和测试基础设施后，选择最佳版本就很直观了：

  1. 定期在新的 ClickHouse 发行版上运行你的自动化测试。即使是标记为 testing 的 ClickHouse 发行版你也可以这样做，但不推荐在后续步骤中继续使用这些版本。
  2. 将通过测试的 ClickHouse 发行版部署到预生产环境，并检查所有流程是否按预期运行。
  3. 将你发现的任何问题报告到 ClickHouse GitHub Issues。
  4. 如果没有发现重大问题，就可以认为开始将该 ClickHouse 发行版部署到生产环境是安全的。投入精力实现渐进发布自动化，采用类似 金丝雀发布 或 蓝绿部署 的方法，可以进一步降低生产环境中出现问题的风险。

如你所见，上述方法中没有任何内容是 ClickHouse 特有的——只要认真对待生产环境，人们对任何他们所依赖的基础设施组件都会这样做。

如何在不同 ClickHouse 发行版之间进行选择？​

如果你查看 ClickHouse 软件包仓库的内容，会看到两类软件包：

  1. stable
  2. lts（长期支持版，long-term support）

下面是关于如何在它们之间进行选择的一些指导：

  • stable 是我们默认推荐的软件包类型。它们大约每月发布一次（因此能在合理的时间内提供新功能），并且最近的三个 stable 版本在诊断和错误修复回溯（backport）方面都提供支持。
  • lts 每年发布两次，并在初始发布后提供一年的支持。在以下情况下，你可能会更倾向于选择 lts 而不是 stable：
    • 你的公司有内部策略，不允许频繁升级或使用非 LTS 软件。
    • 你在一些次要产品中使用 ClickHouse，这些产品要么不需要任何复杂的 ClickHouse 特性，要么没有足够的资源保持其持续更新。

许多团队最初认为 lts 是最佳选择，但往往会因为某个对其产品非常重要的新功能而最终还是转用 stable。

提示

升级 ClickHouse 时还有一点需要注意：我们始终致力于在不同发行版之间保持兼容性，但有时保持完全兼容并不合理，一些次要细节可能会发生变化。因此，在升级之前，请务必查看 changelog，确认是否有任何关于向后不兼容变更的说明。