简介

我们需要存储结构化时序数据，时间间隔为5分钟或1分钟，计算95峰值、995峰值、最值等指标，并且在网页中展示。

MySQL存储

项目开发初期，为了快速开发原型，验证产品，我们使用MySQL作为整个项目的存储。带来的问题是时序数据库范围分析查询耗时很长，计算30天的数据需要30s+，到了无法容忍的地步，即便是创建索引、使用BitInt存储时间戳，几乎没有性能提升。

后来我们组其他同事说换ClickHouse来存储时序数据，于是我们就开始了替换之旅。

ClickHouse

ClickHouse是面向OLAP（在线分析处理）、兼容SQL标准的列式数据库，主要的不足是不支持事务。因此我们目前没有把整个存储都迁移到ClickHouse上，而是只把时序数据存过来。

本以为替换过程会很麻烦，可能修改大量的代码和逻辑，实际上很快，因为之前接口的逻辑设计很合理，所以只替换了数据库ORM库，从gorm换成了sqlx，花了1天时间(前期重构逻辑花了1个星期我是不会会说^_^)。

更重要的是，ClickHouse提供了很多聚合函数，之前计算95值需要2次查询，而现在只需要一次查询就够了，对应的SQL如下：

select d.en_name, max(d.in_value) as peak_in,
    max(d.out_value) as peak_out, max(d.max_value) as peak_max,
    quantileExact(0.95)(d.out_value) as peak_95,
    quantileExact(0.995)(d.out_value) as peak_995,
    quantileExact(0.999)(d.out_value) as peak_999
from table_value d where d.record_time >= '2020-01-01 00:00:00' and d.record_time <= '2020-01-31 23:59:59'
group by d.en_name

经验证，ClickHouse是真的牛逼，30天内的查询耗时从30s降到2s内，提升了15倍！！！

下图是ClickHouse的测试结果，x轴表示查询的时间范围，最大12个月，最小1个月，共测试12次。可以看到大部分耗时在3s内。

下图是MySQL存储中的测试结果（忽略标题），分别计算1、2、3个月范围的数据，共查询1次，耗时都在100s以上。

总结

ClickHouse之所以快主要是采用列式存储和数据压缩，减少了数据扫描范围和数据传输大小；其次，利用CPU的SIMD(Single Instruction Multiple Data)技术实现向量化执行引擎，可以通过一条CPU指令对一组数据执行相同的操作，实现空间上的并行。

需要说明的是，MySQL和ClickHouse各有优劣，要针对自己的业务需求、场景选择合适的数据库。本文涉及的业务比较适用于ClickHouse的强项，才会比MySQL快15倍。