跳至主要内容

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

首先,让我们讨论为什么人们会问这个问题。主要有两个原因

  1. ClickHouse 的开发速度非常快,通常每年会有 10 多个稳定版本发布。这使得可供选择的版本范围很广,选择起来并不容易。
  2. 一些用户不想花时间去确定哪个版本最适合他们的用例,而是直接遵循别人的建议。

第二个原因更根本,所以我们先从这个原因开始,然后再讨论如何选择不同的 ClickHouse 版本。

您推荐哪个 ClickHouse 版本?

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

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

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

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

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

更进一步的步骤可能是将这些自动化测试贡献到 ClickHouse 的开源测试基础设施,这些测试在 ClickHouse 的日常开发中被持续使用。这肯定需要一些额外的学习时间和精力,例如学习 如何运行它,然后如何将您的测试适应此框架,但它会带来回报,因为它可以确保 ClickHouse 版本在发布为稳定版本时就已经针对这些测试进行了测试,而不是在发布后重复浪费时间去报告问题,然后等待错误修复被实现、回溯并发布。有些公司甚至将对基础设施的此类测试贡献作为其内部策略,(在谷歌被称为 碧昂斯的法则)。

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

  1. 定期针对新的 ClickHouse 版本运行您的自动化测试。您甚至可以针对标记为 testing 的 ClickHouse 版本进行测试,但建议不要继续进行下一步操作。
  2. 将通过测试的 ClickHouse 版本部署到预生产环境,并检查所有进程是否按预期运行。
  3. 将您发现的任何问题报告到 ClickHouse GitHub 问题
  4. 如果没有重大问题,您应该可以开始将 ClickHouse 版本部署到生产环境。投资于逐步发布自动化,以实现类似于 金丝雀发布蓝绿部署 的方法,可以进一步降低生产环境中出现问题的风险。

您可能已经注意到,上述方法中并没有什么特别针对 ClickHouse 的内容——人们在使用任何他们依赖的基础设施时,如果他们认真对待生产环境,都会这样做。

如何在 ClickHouse 版本之间进行选择?

如果您查看 ClickHouse 包仓库的内容,您会看到两种类型的包

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

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

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

许多最初认为 lts 是最佳选择的小组,最终还是切换到了 stable,因为他们需要某些对他们的产品很重要的最新功能。

提示

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