[译]一个数据类型的引入让你的 Clickhouse 大幅度提速降费

原文:Reducing Clickhouse Storage Cost with the LowCardinality Type – Lessons from an Instana Engineer^[1]

问题

在 Instana，我们正在m5.12xlarge
AWS EC2
实例和类似大小的自定义构建Google Cloud
实例上运行 Clickhouse 集群。但是，最大的成本驱动因素不是实例的大小，而是实例所连接的 EBS 卷（持久性 SSD），每一个 12TB 卷每月在 AWS 上的费用为 $$2,040。

不幸的是，由于写入 IOPS 达到每秒数千次，我们无法像以前在其他实例上那样^[2]使用便宜的 ST1 卷。

Clickhouse 是一个惊人的快速分析数据库，可以处理大量插入内容，并结合复杂的分析查询，Instana 可以使用这些查询来回答有关跟踪的各种问题，例如“向我显示所有在其中一种特定服务上执行的有错误的跟踪并向我显示基于特定参数的每个组的延迟分布百分位数”。

通常，这些查询的性能与处理的数据量成正比。因此，减少存储数据量，不仅可以降低成本，而且可以提高性能。

压缩

当然，我们已经在压缩数据。Clickhouse 支持 lz4 和 zstd 压缩，尽管 zstd 速度较慢且占用大量资源，但 Clickhouse 需要扫描较少数据的事实弥补了这一缺陷。另外，我们使用 gzip 压缩将数据发送到 Clickhouse，以减少跨 AZ 流量，就像我们之前文章Kafka 跨 AZ 流量优化一样^[3]介绍的那样，通过配置减少了跨 AZ 流量。对于我们发送的数据类型，我们计算出 2-3 级压缩已经足够，不值得进行更高级别的压缩。

引入低基数（LowCardinality）

我们已经在同一个架构上运行了一年，并收集了一些我们想做的更改。但是，对数十亿条记录进行模式迁移并不是您一直想要做的。当我们第一次遇到LowCardinality^[4]数据类型时，似乎无法使用任何东西。我们假设我们的数据不够均匀，无法使用它。但是，当最近再次查看它时，事实证明我们是非常错误的。LowCardinality 这个名称有点误导人。它实际上可以理解为字典。并且根据我们的测试，即使该列包含数百万个不同的值，它的性能仍然更好，更快。

因此，我们创建了一个新模式，并附带了一个迁移实用程序。对于如何进行迁移，我们有一些想法，其中一些想法具有较高的操作复杂性，但没有停机时间，其他想法则更快，更轻松，但确实需要停机。最终，Clickhouse 是我们最大的数据库，并且每秒的更新率非常高。幸运的是，我们从不更新旧数据！

我们最终实现了一个迁移工具，该工具可以执行所有操作：在线实时迁移，停止、批量迁移，轻松停止和重新启动等等。这也使我们的自托管本地客户可以选择最适合他们的方法。

结果

迁移花费了数周的时间才能完成。现在，要评估整体结果时，我们很高兴看到我们所做的所有负载测试和计算都适用于整个生产数据集。

磁盘上的大小减少了近 50％：

SELECT   table,   formatReadableSize(SUM(bytes_on_disk))FROM system.partsWHERE (active = 1) AND ((table = 'calls_v2') OR (table = 'calls_v3'))GROUP BY table┌─table────┬─formatReadableSize(SUM(bytes_on_disk))─┐│ calls_v3 │ 1.85 TiB                               ││ calls_v2 │ 3.90 TiB                               │└──────────┴────────────────────────────────────────┘

性能几乎提高了 2 倍！

这里是我们 Instana 自我监控的两个屏幕截图。具有讽刺意味的是，他们显示了跟踪分析屏幕，该屏幕可以查询针对特定客户的 Clickhouse 服务的呼叫性能。该客户正在我们的美国数据中心中运行，并使用我们的 REST API 进行夜间报告，因此会导致大量处理密集型 Clickhouse 呼叫。我们在早上 9:14 进行了欧洲团队对新模式的阅读的上线测试。

立即通话数量增加了一倍以上。这是为什么？好吧，如果我们不考虑计数，而是平均等待时间，则很清楚发生了什么：

现在，所有这些蓝色的GetCallGroups
查询的速度都快一倍。显然，我们的客户使用某种并发限制，现在它可以同时进行两次呼叫。

我们在自己的最终用户监控中也看到了相同的改进。由于最终用户通过 UI 进行的呼叫比通过 API 进行的复杂性要低，因此平均值没有显示出易于在屏幕截图上识别的改进，但是较高的百分位数（如 95th 百分点）确实得到了显着改善：

因此，我们不仅将存储成本削减了大约一半，而且使产品的生产速度提高了两倍。真正的双赢。

参考资料