4、时序数据库选型：InfluxDB、TimescaleDB、ClickHouse压缩能力对比
行情数据，说白了就是带时间戳的数值流。每秒成千上万笔，一天下来几个TB，存储成本压得人喘不过气。我这些年跟这三款数据库都打过交道，今天聊聊它们的压缩能力，帮你选个趁手的家伙。
4.1 为什么压缩能力这么重要？
你想想看，行情数据有个特点：重复性高。同一只股票，连续几笔成交价可能一模一样。时间戳虽然一直在变，但间隔往往是固定的。这些规律，就是压缩的突破口。
我见过不少团队，上来就上全量数据，结果一个月后存储爆了。其实，选对时序数据库，压缩比能做到10:1甚至20:1。什么意思？原本100TB的数据，压缩完只剩5TB。这省下来的可都是真金白银。
核心观点：压缩能力直接决定了你的存储成本。选型时，压缩比、压缩速度、查询性能三者要平衡。
4.2 InfluxDB：专为时序而生，压缩有绝活
InfluxDB是我最早接触的时序数据库。它的压缩策略很有意思——按列存储，同一列的数据类型一致，压缩起来特别顺手。
具体来说，InfluxDB用了这些招数：
- 时间戳压缩：用delta-of-delta算法。相邻时间戳的差值再求差值，大部分情况下差值很小，甚至为0。这样一搞，时间戳的存储空间能省掉90%以上。
- 数值压缩：用Gorilla算法。这是Facebook开源的那套，专门针对浮点数。它记录数值的变化量，而不是完整数值。行情数据波动不大时，压缩效果特别好。
- 标签压缩：标签值用字典编码。重复的标签只存一次，后面用ID引用。
我记得有一次，帮一家券商做行情归档。原始数据每天大概500GB，用InfluxDB压完只剩30GB。压缩比超过16:1。不过要注意，InfluxDB的压缩是实时的，写入时就要计算，对CPU有一定消耗。
小技巧：InfluxDB的压缩效果跟数据规律性强相关。如果时间戳间隔均匀，数值变化小，压缩比会非常漂亮。反之，如果数据乱序严重，压缩效果会打折扣。
4.3 TimescaleDB：PostgreSQL的时序外挂
TimescaleDB本质上是个PostgreSQL扩展。它继承了PG的压缩能力，又针对时序数据做了优化。
它的压缩思路跟InfluxDB不太一样：
- 按块压缩：数据先按时间分块（chunk），每个块内部再压缩。块的大小可以配置，我一般设成1天或1周。
- 多种算法可选：支持ZSTD、LZ4、PGLZ等。ZSTD压缩比高，LZ4速度快。我个人的习惯是，归档数据用ZSTD，热数据用LZ4。
- 列式存储：TimescaleDB 2.0之后支持列式压缩。同一列的数据放在一起，压缩效率比行式存储高不少。
我曾经在一个项目中，用TimescaleDB存储期货行情。原始数据每天200GB，用ZSTD压缩后大概15GB。压缩比13:1左右。比InfluxDB略低一点，但胜在灵活——你可以随时调整压缩策略，甚至对不同的列用不同的算法。
注意：TimescaleDB的压缩是异步的。数据先写入，后台再压缩。查询时自动解压，对用户透明。但压缩期间会占用额外IO，建议在低峰期触发。
4.4 ClickHouse：列式存储的压缩之王
说到压缩，ClickHouse绝对是王者级别的存在。它本身就是列式存储，压缩是刻在骨子里的。
ClickHouse的压缩能力来自几个方面：
- 列式存储天然优势：同一列的数据类型一致，数值范围相近。压缩算法可以针对性地优化。
- 多种编码方式：除了通用的LZ4、ZSTD，还有专门针对时序数据的编码，比如DoubleDelta、Gorilla。这些编码能大幅提升压缩比。
- 数据排序：ClickHouse允许你指定排序键。把时间戳、股票代码作为排序键，数据物理上排好序，压缩效果会更好。
我做过一个对比测试：同样的行情数据，InfluxDB压缩后30GB，TimescaleDB压缩后15GB，ClickHouse压缩后只有8GB。压缩比超过60:1。当然，这是理想情况。实际项目中，压缩比一般在20:1到40:1之间。
为什么会这么强？说白了，ClickHouse把压缩做到了极致。它甚至允许你为每一列指定压缩算法和编码方式。比如时间戳列用DoubleDelta，价格列用Gorilla，成交量列用LZ4。这种精细化的控制，其他数据库很难做到。
经验之谈：ClickHouse的压缩虽然强，但写入时CPU开销也大。如果写入速度要求极高（比如每秒百万级），可能需要权衡一下。我一般建议，写入峰值不超过每秒50万行，否则CPU会扛不住。
4.5 三款数据库压缩能力对比
直接上表格，一目了然：
| 特性 | InfluxDB | TimescaleDB | ClickHouse |
|---|---|---|---|
| 压缩算法 | Gorilla、delta-of-delta | ZSTD、LZ4、PGLZ | LZ4、ZSTD、DoubleDelta、Gorilla |
| 典型压缩比 | 10:1 ~ 16:1 | 8:1 ~ 13:1 | 20:1 ~ 60:1 |
| 压缩时机 | 实时压缩 | 异步压缩 | 写入时压缩 |
| CPU消耗 | 中等 | 低（异步） | 高 |
| 灵活性 | 低（固定算法） | 中（可调算法） | 高（每列可配） |
| 查询性能 | 优秀 | 良好 | 极佳 |
4.6 怎么选？我的建议
没有银弹。三款数据库各有千秋，关键看你的场景：
- 如果数据量不大（每天几百GB以内），InfluxDB够用了。部署简单，查询方便，压缩比也还行。
- 如果已经用了PostgreSQL，TimescaleDB是自然选择。不用迁移数据，直接扩展就行。压缩能力中规中矩，但胜在生态兼容。
- 如果数据量巨大（每天TB级），ClickHouse是唯一选择。压缩比高得离谱，查询速度也快。但学习曲线陡，运维成本高。
我曾经帮一家量化基金做选型。他们每天产生2TB的行情数据，要求存储30天。用InfluxDB的话，需要60TB的存储。用ClickHouse，只需要10TB。一年下来，存储成本差了上百万。嗯，最后他们选了ClickHouse。
避坑指南：我曾经犯过一个错误——只关注压缩比，忽略了查询性能。结果数据是压得很小，但查一条记录要好几秒。后来我学乖了，选型时一定要做压测，压缩比和查询延迟都要看。
4.7 知识体系总览
下面这张图，帮你理清三款数据库的压缩逻辑：
这张图把三款数据库的压缩路径画清楚了。从行情数据流入，到各自压缩，最终都指向一个目标——降低存储成本。你选哪条路，取决于你的数据规模、团队能力和预算。
公众号:蓝海资料掘金营，微信deep3321