3. 主流产品对比：InfluxDB、TimescaleDB、TDengine、ClickHouse、Prometheus

好，咱们直接切入正题。市面上号称时序数据库的产品不少，但真正经得起生产环境考验的，我个人觉得就这五位：InfluxDB、TimescaleDB、TDengine、ClickHouse 和 Prometheus。每个我都深度用过，踩过坑，也真香过。

这章我不打算罗列枯燥的参数表。咱们换个思路——从「场景」出发，看看它们各自擅长什么，又有什么短板。你想想看，选型选错了，后面重构的代价可不是闹着玩的。

3.1 InfluxDB：老牌劲旅，但有点「重」

InfluxDB 是我最早接触的时序数据库。2015 年那会儿，它几乎是时序数据库的代名词。说实话，它的生态确实成熟，文档齐全，社区活跃。

优点：

• 查询语法友好： 类 SQL 的 InfluxQL，上手快。我团队里刚毕业的小朋友，半天就能写复杂查询。
• 数据压缩率高： 默认的 TSM 引擎，压缩比能做到 10:1 甚至更高。我在一个 IoT 项目中，每天 5TB 的原始数据，压缩后只剩 400GB。
• 持续查询和保留策略： 自动降采样和过期删除，省心。我曾经用它做 7 天热数据 + 90 天冷数据的自动管理，非常稳。

缺点：

• 集群版是付费的： 开源版只能单机。一旦数据量超过单机瓶颈，你就得考虑商业版或者自己折腾。嗯，这里要注意，自己搭集群的坑很深。
• 高基数问题严重： 如果你的 tag 组合特别多（比如设备 ID 有 1000 万种），InfluxDB 的写入性能会断崖式下跌。我曾在智能电表项目中吃过这个亏，后来不得不迁移。
• JOIN 能力弱： 它本质上不是关系型数据库，跨 measurement 的关联查询基本别想。

3.2 TimescaleDB：披着 SQL 外衣的时序库

TimescaleDB 很有意思。它不是一个独立的数据库，而是 PostgreSQL 的一个扩展。说白了，你装个 PG，再装个 TimescaleDB 插件，就能拥有时序能力。

优点：

• 全 SQL 支持： 这是它最大的杀手锏。你不需要学任何新语法，PostgreSQL 能做的，它都能做。JOIN、子查询、窗口函数，随便用。
• 与 PG 生态无缝集成： 可以直接用 PG 的备份、恢复、高可用方案。我习惯用 Patroni 做 TimescaleDB 的集群，非常成熟。
• 自动分区（Hypertable）： 按时间和空间自动分块，对开发者透明。你只管 insert，它自动管理。

缺点：

• 写入性能不如专用库： 毕竟底层还是 PG 的行存储，写入吞吐量比 InfluxDB 和 TDengine 差一个量级。我测过，单机大概 50 万 points/s，而 TDengine 能到 200 万+。
• 压缩率一般： 默认没有列式压缩，需要手动开启。而且压缩后的查询性能会受影响。
• 内存消耗大： PG 的 shared_buffers 和 work_mem 配置不好，很容易 OOM。我见过不少新手把服务器搞崩。

3.3 TDengine：国产之光，但生态尚浅

TDengine 是涛思数据的产品。我第一次用是 2019 年，当时被它的写入性能震撼到了。说实话，在 IoT 和车联网领域，它的性能确实能打。

优点：

• 极致的写入性能： 单机轻松百万 points/s。它的设计哲学就是「一个设备一张表」，避免了高基数问题。我在风电项目中，用 3 台服务器扛住了 10 万台风机、每秒 100 万条数据的写入。
• 超级表（Super Table）： 自动聚合同类设备，查询时按标签过滤。这个设计很巧妙，既保留了关系查询的灵活性，又保持了时序写入的高效。
• 计算与存储一体化： 支持 SQL 和 RESTful 接口，内置降采样、插值、预测等时序函数。很多场景不需要额外写代码。

缺点：

• 生态不够丰富： 相比 InfluxDB 和 Prometheus，它的周边工具少。比如 Grafana 的插件更新慢，有些高级图表需要自己写。
• SQL 方言： 虽然支持 SQL，但语法和标准 SQL 有差异。比如 JOIN 支持有限，子查询嵌套层数多了会报错。我团队的新人经常在这里卡住。
• 集群运维复杂： 它的集群是强一致的，节点间通信开销大。我曾经在跨机房部署时，因为网络延迟导致写入抖动。

3.4 ClickHouse：OLAP 王者，但时序不是主业

ClickHouse 是 Yandex 开源的列式数据库。很多人把它当时序库用，其实它更擅长 OLAP 分析。不过，它的时序能力确实被低估了。

优点：

• 极致的查询性能： 列式存储 + 向量化执行，聚合查询快到离谱。我做过对比，同样的 10 亿行数据，ClickHouse 的 GROUP BY 比 InfluxDB 快 10 倍以上。
• 数据压缩率极高： 列式存储天然适合压缩。我见过一个案例，原始数据 100TB，用 ClickHouse 压缩后只剩 8TB。
• 丰富的聚合函数： 除了常见的 SUM、AVG，还有 quantile、uniq、topK 等高级函数。做实时报表和分析非常爽。

缺点：

• 写入不是强项： 它是批量写入的，单条插入性能很差。虽然支持实时写入，但需要做缓冲。我习惯用 Kafka + ClickHouse 的组合，批量 flush。
• 不支持单行更新和删除： 它是 append-only 的。如果你需要修改历史数据，得用 ALTER TABLE DELETE 或者重建分区，很麻烦。
• 运维门槛高： 配置参数多，MergeTree 引擎的合并策略、分区键选择、排序键设计，都需要经验。我见过不少团队因为分区键选错，查询越跑越慢。

3.5 Prometheus：监控界的标准，但不是通用库

Prometheus 严格来说不是时序数据库，而是监控系统。但它的 TSDB 模块确实很优秀，而且已经成为云原生监控的事实标准。

优点：

• Pull 模型： 主动拉取指标，不需要在被监控端安装 Agent。这在 Kubernetes 环境中简直是神器。我部署过上千个 Pod，Prometheus 自动发现，零配置。
• PromQL 强大： 它的查询语言 PromQL 虽然和 SQL 不同，但非常灵活。比如 rate、increase、histogram_quantile 等函数，做监控告警非常方便。
• 与 Grafana 深度集成： 几乎所有的 Grafana 面板都原生支持 Prometheus。你不需要写任何适配代码。

缺点：

• 不适合做长期存储： 它的设计目标是存储几周到几个月的数据。如果你要存几年，要么用 Thanos 或 VictoriaMetrics 做扩展，要么定期导出到其他存储。
• 单机瓶颈明显： 单机 Prometheus 能处理的时序数有限（大概 1000 万条）。超过这个量，要么分片，要么用联邦集群。
• 不支持复杂分析： 你不能用它做 JOIN、子查询、窗口函数。它只适合做监控指标的聚合和告警。

3.6 横向对比：一张表说清楚

维度	InfluxDB	TimescaleDB	TDengine	ClickHouse	Prometheus
写入性能	高	中	极高	中（需批量）	高
查询性能	中	中	高	极高	高（限 PromQL）
SQL 支持	类 SQL	全 SQL	类 SQL	全 SQL	PromQL
高基数处理	差	中	好	好	中
集群能力	付费	强（基于 PG）	强	强	弱（需扩展）
生态成熟度	高	高	中	高	极高
运维复杂度	低	中	中	高	低
典型场景	中小规模 IoT	业务+时序混合	超大规模 IoT	日志/OLAP 分析	基础设施监控

3.7 选型建议：我的一点心得

说了这么多，到底怎么选？我个人习惯用「三问法」：

1. 你的数据量有多大？ 单机 < 1TB，InfluxDB 或 Prometheus 够用。超过 10TB，考虑 TDengine 或 ClickHouse。
2. 你需要复杂查询吗？ 需要 JOIN、子查询、窗口函数？选 TimescaleDB 或 ClickHouse。只需要简单的时序聚合？InfluxDB 或 TDengine 更合适。
3. 你的团队擅长什么？ 团队熟悉 SQL？选 TimescaleDB 或 ClickHouse。团队熟悉监控？选 Prometheus。团队愿意学新东西？TDengine 值得一试。