当人们看到 ClickHouse 的官方 T 恤时，通常会产生这个问题。T 恤正面印有醒目的字样 “ClickHouse не тормозит”。

在 ClickHouse 开源之前，它是由俄罗斯最大的 IT 公司 Yandex 作为内部存储系统开发的。因此，它最初的口号是用俄语写的，即“не тормозит”（发音为“ne tormozit”）。在开源发布后，我们首先为俄罗斯的活动制作了一些这样的 T 恤，并且使用这个口号是很自然的事情。

其中一批 T 恤原本打算在俄罗斯以外的活动中赠送，我们尝试制作了这个口号的英文版本。不幸的是，俄语在表达方面非常优雅，而 T 恤上的空间有限，因此我们无法找到足够好的翻译（大多数选项要么太长，要么不准确），因此决定即使在为国际活动制作的 T 恤上也保留俄语口号。事实证明这是一个很好的决定，因为全世界的人们在看到它时都会感到惊喜和好奇。

那么，它是什么意思呢？以下是翻译 “не тормозит” 的一些方法。

• 如果逐字翻译，它类似于 “ClickHouse 没有踩刹车”。
• 如果你想尽量接近俄语 IT 背景人士的理解，它类似于 “如果你的大型系统出现延迟，那不是因为使用了 ClickHouse”。
• 更简洁但不太精确的版本可以是 “ClickHouse 不慢”、“ClickHouse 没有延迟” 或 “ClickHouse 很快”。

如果你还没有亲眼见过这些 T 恤，你可以在许多与 ClickHouse 相关的视频中在线查看它们。例如，这个视频

附注：这些 T 恤不公开出售，它们通常在大多数 ClickHouse 聚会 上免费赠送，通常是奖励最佳问题或其他形式的积极参与。

OLAP 代表联机分析处理。这是一个广泛的术语，可以从技术和业务两个角度来看待。但在最高层次上，你可以简单地反过来读这些词。

处理：一些源数据被处理……

分析：……以生成一些分析报告和见解……

联机：……实时进行。

从业务角度看 OLAP​

近年来，商业人士开始意识到数据的重要性。盲目决策的公司往往无法跟上竞争对手的步伐。成功的公司的数据驱动方法迫使他们收集所有可能对商业决策有远程用处的

从商业角度来看，OLAP 允许公司持续规划、分析和报告运营活动，从而最大限度地提高效率，降低成本，并最终赢得市场份额。这可以通过内部系统实现，也可以外包给 SaaS 提供商，例如 Web/移动分析服务、CRM 服务等。OLAP 是许多 BI 应用（商业智能）背后的技术。

ClickHouse 是一种 OLAP 数据库管理系统，经常被用作这些 SaaS 解决方案的后端，用于分析特定领域的的数据。但是，一些企业仍然不愿将其数据与第三方提供商共享，因此内部数据仓库方案也是可行的。

从技术角度看 OLAP​

所有数据库管理系统都可以分为两类：OLAP（联机**分析**处理）和 OLTP（联机**事务**处理）。前者专注于构建报告，每个报告都基于大量历史数据，但执行频率并不高。而后者通常处理连续的事务流，不断修改数据的当前状态。

在实践中，OLAP 和 OLTP 不是类别，更像是一个频谱。大多数实际系统通常专注于其中之一，但如果也需要相反类型的负载，则会提供一些解决方案或变通方法。这种情况经常迫使企业运行多个集成的存储系统，这可能不是什么大问题，但拥有更多系统会增加维护成本。因此，近年来发展趋势是 HTAP（**混合事务/分析处理**），其中两种类型的负载都可以由单个数据库管理系统很好地处理。

即使 DBMS 最初是纯 OLAP 或纯 OLTP，它们也被迫朝着 HTAP 方向发展以保持竞争力。ClickHouse 也不例外，最初它被设计为尽可能快的 OLAP 系统，并且它仍然没有完整的事务支持，但必须添加一些功能，例如一致的读/写和用于更新/删除数据的变异。

OLAP 和 OLTP 系统之间的根本权衡仍然存在

• 为了高效地构建分析报告，能够单独读取列至关重要，因此大多数 OLAP 数据库都是列存储的，
• 虽然单独存储列会增加行操作（如追加或就地修改）的成本，成本与列数成正比（如果系统试图收集事件的所有详细信息以备不时之需，列数可能很大）。因此，大多数 OLTP 系统按行存储数据。

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

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

第二个原因更基本，所以我们将从这个原因开始，然后回到浏览各种 ClickHouse 版本。

您推荐哪个 ClickHouse 版本？​

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

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

以下是一些关键要点，可以在预生产环境中获得合理的保真度，而无需花费太高的成本

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

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

更进一步的一步可能是将这些自动化测试贡献给ClickHouse 的开源测试基础设施，这些测试基础设施在其日常开发中持续使用。当然，学习如何运行它以及如何将您的测试适配到此框架会花费一些额外的时间和精力，但这将通过确保 ClickHouse 版本在宣布稳定时已经针对这些测试进行了测试而得到回报，而不是在事后反复浪费时间报告问题，然后等待错误修复被实施、回退并发布。一些公司甚至将其使用作为内部政策，将这种对基础设施的测试贡献作为一项内部政策（在 Google 被称为碧昂丝规则）。

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

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

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

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

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

1. 稳定版
2. lts（长期支持）

以下是如何在它们之间进行选择的一些指导

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

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

注意：有关在 ClickHouse 中使用时间序列分析的其他示例，请参阅博客在 ClickHouse 中使用时间序列数据。

ClickHouse 是一种通用的数据存储解决方案，适用于OLAP 工作负载，而有很多专门的时间序列数据库管理系统。但是，ClickHouse专注于查询执行速度 使其在许多情况下都能胜过专业系统。有很多关于此主题的独立基准测试，因此我们不会在这里进行测试。相反，让我们专注于 ClickHouse 功能，如果这是您的用例，这些功能非常重要。

首先，有**专门的编解码器**，可以生成典型的时间序列。无论是 DoubleDelta 和 Gorilla 等常用算法，还是 ClickHouse 特定的算法，如 T64。

其次，时间序列查询通常只命中最近的数据，例如一天或一周前的旧数据。使用同时具有快速 nVME/SSD 驱动器和高容量 HDD 驱动器的服务器是有意义的。ClickHouseTTL 功能允许配置将新鲜的热数据保留在快速驱动器上，并随着数据年龄的增长逐渐将其移动到较慢的驱动器上。如果您的需求需要，还可以对更旧的数据进行汇总或删除。

尽管这违背了 ClickHouse 存储和处理原始数据的理念，但您可以使用物化视图来满足更严格的延迟或成本要求。

相关内容​

• 博客：在 ClickHouse 中使用时间序列数据

作为开源产品，这个问题的答案并不那么简单。如果您想开始使用 ClickHouse，您不必告诉任何人，只需获取源代码或预编译的包即可。无需签署任何合同，并且Apache 2.0 许可证允许不受限制地分发软件。

此外，技术栈通常处于保密协议 (NDA) 覆盖范围的灰色地带。一些公司认为他们使用的技术是竞争优势，即使是开源的，也不允许员工公开分享任何细节。有些公司则认为存在一些公关风险，只允许员工在获得公关部门批准后分享实施细节。

那么如何了解谁在使用 ClickHouse 呢？

一种方法是**四处打听**。如果不在书面上，人们更愿意分享他们在公司中使用的技术、用例、使用的硬件、数据量等信息。我们在世界各地的 ClickHouse 线下交流会 上定期与用户交流，并听取了关于 1000 多家使用 ClickHouse 的公司的故事。不幸的是，这些信息无法复现，我们试图将这些故事视为在保密协议下讲述的，以避免任何潜在的麻烦。但您可以参加我们未来的任何线下交流会，并自行与其他用户交流。线下交流会有多种发布方式，例如，您可以订阅 我们的 Twitter。

第二种方法是寻找公司**公开声明**他们使用 ClickHouse。这种方法更有说服力，因为通常会有一些确凿的证据，例如博客文章、演讲视频录制、幻灯片等。我们在我们的**用户案例** 页面上收集了此类证据的链接。欢迎您贡献您雇主的故事或您偶然发现的一些链接（但在过程中请勿违反您的保密协议）。

您可以在用户案例列表中找到一些非常大型公司的名称，例如彭博社、思科、中国电信、腾讯或 Uber，但通过第一种方法，我们发现还有很多其他公司。例如，如果您查看 2020 年福布斯发布的全球最大科技公司名单，其中超过一半的公司以某种方式使用 ClickHouse。此外，我们也不得不提及 Yandex，该公司于 2016 年最初开源了 ClickHouse，并且恰好是欧洲最大的 IT 公司之一。

ClickHouse 的设计初衷就是为了速度。在开发过程中，查询执行性能始终是重中之重，但同时也考虑了其他重要特性，例如用户友好性、可扩展性和安全性，以便 ClickHouse 能够成为一个真正的生产系统。

"构建速度"，Alexey Milovidov（ClickHouse CTO）​

"构建速度" 演讲来自 2022 年 6 月在阿姆斯特丹举行的 ClickHouse 线下交流会。

"ClickHouse 性能优化的秘密" 演讲来自 2019 年 12 月的大数据技术大会，从更技术的角度探讨了相同主题。

是什么让 ClickHouse 如此快速？​

架构选择​

ClickHouse 最初被构建为一个原型，旨在很好地完成一项单一任务：尽可能快地过滤和聚合数据。构建典型的分析报告需要执行此操作，而典型的 GROUP BY 查询就是这么做的。ClickHouse 团队做出了一些高级决策，这些决策结合在一起，使得完成此任务成为可能。

**列式存储：**源数据通常包含数百甚至数千列，而报告可能只需要使用其中的几列。系统需要避免读取不必要的列，以避免代价高昂的磁盘读取操作。

**索引：**内存驻留的 ClickHouse 数据结构允许仅读取必要的列，以及这些列中仅必要的行范围。

**数据压缩：**将同一列的不同值存储在一起通常会导致更好的压缩率（与行式系统相比），因为在实际数据中，同一列在相邻行中通常具有相同的值，或者值变化不多。除了通用压缩之外，ClickHouse 还支持 专用编解码器，可以使数据更加紧凑。

**向量化查询执行：**ClickHouse 不仅以列的形式存储数据，还以列的形式处理数据。这可以提高 CPU 缓存利用率，并允许使用 SIMD CPU 指令。

**可扩展性：**ClickHouse 可以利用所有可用的 CPU 内核和磁盘来执行单个查询。不仅限于单个服务器，还可以利用集群中所有 CPU 内核和磁盘。

关注底层细节​

但许多其他数据库管理系统也使用了类似的技术。真正使 ClickHouse 脱颖而出的是**关注底层细节**。大多数编程语言都提供了大多数常用算法和数据结构的实现，但它们往往过于通用，效率不高。每个任务都可以被视为具有各种特征的场景，而不是仅仅使用随机实现。例如，如果您需要一个哈希表，以下是一些需要考虑的关键问题

• 选择哪个哈希函数？
• 冲突解决算法：开放寻址法 与 链地址法？
• 内存布局：键和值使用一个数组还是使用单独的数组？它将存储小值还是大值？
• 填充因子：何时以及如何调整大小？如何在调整大小时移动值？
• 是否会删除值，如果会删除，哪个算法效果更好？
• 是否需要使用位图进行快速探测、字符串键的内联放置、对不可移动值的支持、预取和批处理？

哈希表是 GROUP BY 实现的关键数据结构，ClickHouse 会自动为每个特定查询选择 30 多种变体 之一。

算法也是如此，例如，在排序时，您可能会考虑

• 要排序什么：数字、元组、字符串或结构的数组？
• 所有数据是否完全在 RAM 中可用？
• 是否需要稳定排序？
• 是否需要完全排序？也许部分排序或第 n 个元素就足够了？
• 如何实现比较？
• 是否正在对已经部分排序的数据进行排序？

依赖于其所处理数据的特征的算法通常比其通用对应算法表现更好。如果事先并不知道，系统可以尝试各种实现，并在运行时选择效果最佳的实现。例如，请参阅 一篇关于 ClickHouse 中如何实现 LZ4 解压缩的文章。

最后但并非最不重要的是，ClickHouse 团队始终关注互联网上人们声称他们想出了最佳实现、算法或数据结构来完成某些任务，并尝试这些方法。这些说法大多被证明是错误的，但偶尔您确实会发现一些珍宝。