生产环境中使用哪个 ClickHouse 版本？
首先，我们来讨论一下为什么人们会提出这个问题。主要有两个原因
- ClickHouse 的开发速度非常快，通常一年会有 10 多个稳定版本发布。这使得可供选择的版本范围很广，选择起来并不简单。
- 有些用户不想花时间弄清楚哪个版本最适合他们的用例，只想遵循别人的建议。
第二个原因更根本，所以我们先从它开始，然后再回到如何浏览各种 ClickHouse 版本。
您推荐使用哪个 ClickHouse 版本？
聘请顾问或信任一些知名专家以摆脱对生产环境的责任是很诱人的。您安装了别人推荐的某个特定 ClickHouse 版本；如果出现问题，那不是您的错，是别人的错。这种推理方式是一个大陷阱。任何外部人员都不比您更了解您公司生产环境中的情况。
那么，如何正确选择要升级的 ClickHouse 版本？或者如何选择您的第一个 ClickHouse 版本？首先，您需要投入精力建立一个真实的预生产环境。在理想情况下，它可以是完全相同的影子副本，但这通常很昂贵。
以下是一些关键点，可以在不花费太多成本的情况下，在预生产环境中获得合理的保真度
- 预生产环境需要运行与您打算在生产环境中运行尽可能接近的一组查询
- 不要使其只读并使用冻结的数据。
- 不要使其只写并仅复制数据而不构建一些典型的报告。
- 不要擦除它而是应用模式迁移。
- 使用真实的生产数据和查询样本。尝试选择仍然具有代表性且使
SELECT查询返回合理结果的样本。如果您的数据敏感且内部策略不允许其离开生产环境，请使用混淆处理。 - 确保预生产环境受到您的监控和告警软件的覆盖，就像您的生产环境一样。
- 如果您的生产环境跨多个数据中心或区域，请确保您的预生产环境也这样做。
- 如果您的生产环境使用复杂的特性，如复制、分布式表和级联物化视图，请确保它们在预生产环境中配置相似。
- 在预生产环境中，使用与生产环境相同数量但尺寸较小的服务器或虚拟机，或者使用更少的服务器但尺寸相同，这之间存在权衡。第一种选择可能捕获额外的网络相关问题，而后者更易于管理。
您需要投入的第二个领域是自动化测试基础设施。不要假设某个查询成功执行一次后，它将永远如此。拥有一些 ClickHouse 被模拟的单元测试是可以的，但请确保您的产品具有合理的自动化测试集，这些测试集针对真实的 ClickHouse 运行，并检查所有重要的用例是否仍然按预期工作。
更进一步，您可以将这些自动化测试贡献给 ClickHouse 的开源测试基础设施，该基础设施在其日常开发中持续使用。学习 如何运行它 以及如何将您的测试适应到这个框架中，肯定需要额外的时间和精力，但它将通过确保在宣布稳定版本时，ClickHouse 发布已经通过这些测试，而不是在事后才报告问题并等待修复程序实施、回溯和发布来获得回报。一些公司甚至将这种测试贡献作为内部政策，（在 Google 被称为 碧昂丝法则）。
当您拥有预生产环境和测试基础设施后，选择最佳版本就变得很简单
- 定期对新的 ClickHouse 版本运行您的自动化测试。您甚至可以对标记为
testing的 ClickHouse 版本执行此操作，但不建议继续使用它们进行后续步骤。 - 将通过测试的 ClickHouse 版本部署到预生产环境，并检查所有进程是否按预期运行。
- 将您发现的任何问题报告到 ClickHouse GitHub Issues。
- 如果没有重大问题，应该可以安全地开始将 ClickHouse 版本部署到您的生产环境。投资于渐进式发布自动化，实施类似于 金丝雀发布 或 蓝绿部署 的方法，可以进一步降低生产环境中的问题风险。
正如您可能注意到的，上述方法中没有什么特别适用于 ClickHouse——如果他们认真对待生产环境，人们会这样做任何他们依赖的基础设施。
如何选择 ClickHouse 版本？
如果您查看 ClickHouse 包存储库的内容，您会看到两种类型的包
稳定版lts（长期支持）
以下是一些关于如何选择它们之间的指导
stable是我们默认推荐的包类型。它们大约每月发布一次（从而以合理的速度提供新功能），并且最新的三个稳定版本在诊断和回溯错误修复方面都受到支持。lts每半年发布一次，并在首次发布后支持一年。您可能更喜欢它们而不是stable，在以下情况下：- 您的公司有一些内部策略不允许频繁升级或使用非 LTS 软件。
- 您在一些辅助产品中使用 ClickHouse，这些产品要么不需要任何复杂的 ClickHouse 功能，要么没有足够的资源来保持其更新。
许多最初认为 lts 是正确选择的团队最终还是切换到 stable，因为某个最近的功能对他们的产品很重要。
