4、时序数据库：InfluxDB、TimescaleDB、Prometheus TSDB 的选型与对比
做量化交易系统，最头疼的问题之一就是数据怎么存。
行情数据、订单簿快照、成交记录、系统指标……这些数据都有一个共同特点——带时间戳，而且写入量巨大。我刚开始做交易系统时，天真地用了 MySQL，结果一个月后单表就几千万行，查询慢得像蜗牛。后来才明白，这类场景得用专门的时序数据库。
今天咱们就聊聊市面上最主流的三个选手：InfluxDB、TimescaleDB 和 Prometheus TSDB。我会结合自己的踩坑经历，帮你理清选型思路。
4.1 为什么普通数据库搞不定？
先说说时序数据的特殊性。
你想想看，交易系统每秒可能产生几千甚至几万条数据。每条数据就是一个时间戳加几个数值。这种数据有几个特点：
- 写入密集：持续不断的追加写入，很少修改
- 时间范围查询：查最近5分钟、最近1小时的数据
- 聚合分析：算平均值、最大值、分位数
- 数据保留策略：旧数据自动过期删除
传统关系型数据库的 B+ 树索引，在这种场景下效率很低。写入时频繁的索引更新会拖慢速度，查询时全表扫描更是灾难。
核心观点：时序数据库本质上做了两件事——优化写入路径（LSM-Tree 或类似结构）和优化时间范围查询（按时间分区）。选型就是看这两点谁做得更好。
4.2 三位选手的自我介绍
4.2.1 InfluxDB
InfluxDB 是专门为时序数据设计的。它用了一种叫 TSM（Time-Structured Merge Tree）的存储引擎，说白了就是 LSM-Tree 的变种。
我个人习惯把 InfluxDB 看作「时序界的 MongoDB」。它的数据模型很灵活，不需要预先定义 schema，写入速度极快。我在一个高频回测项目中用过它，每秒写入 50 万点毫无压力。
但要注意，InfluxDB 的查询语言是它自己搞的 Flux（或者老的 InfluxQL），跟 SQL 不太一样。如果你的团队对 SQL 很熟，可能需要一点学习成本。
我的经验：InfluxDB 适合纯时序场景，比如监控指标、传感器数据。如果你需要做复杂的关联查询（比如把行情数据和交易记录 join 起来），它会比较吃力。
4.2.2 TimescaleDB
TimescaleDB 是 PostgreSQL 的一个扩展。它没有另起炉灶，而是在 PG 的基础上加了时序能力。
这意味着什么？你可以在 TimescaleDB 里用完整的 SQL，包括 JOIN、窗口函数、CTE 等等。对于量化交易来说，这太重要了。我记得有一次需要把 tick 数据和订单数据做关联分析，用 TimescaleDB 写个 SQL 就搞定了，如果用 InfluxDB 得写半天脚本。
TimescaleDB 的核心机制是「自动分区」。它按时间把数据切成一块块的 chunk，查询时只扫描相关分区，效率很高。
避坑指南：我曾经在生产环境遇到过一个问题——TimescaleDB 的压缩功能虽然好，但压缩后的数据不能直接更新。如果你有频繁的补数据需求，要小心处理。
4.2.3 Prometheus TSDB
Prometheus TSDB 是 Prometheus 监控系统自带的存储引擎。它跟 Prometheus 深度绑定，一般不单独使用。
它的设计思路很特别——用「指标名+标签」来标识数据。比如 trade_volume{exchange="binance", symbol="BTCUSDT"}。这种模型在监控场景下非常自然。
但说实话，Prometheus TSDB 不太适合做量化交易的主存储。它的查询语言 PromQL 虽然强大，但只适合做聚合和告警，不适合做精细的数据分析。而且它不支持数据修改和删除（只能通过数据保留策略自动清理）。
4.3 核心对比：一张表说清楚
| 维度 | InfluxDB | TimescaleDB | Prometheus TSDB |
|---|---|---|---|
| 存储引擎 | TSM（LSM 变种） | 基于 PostgreSQL | 自研 TSDB |
| 查询语言 | Flux / InfluxQL | SQL（完整） | PromQL |
| 写入性能 | 极高（50万+/秒） | 高（10万+/秒） | 高（取决于配置） |
| 数据压缩 | 优秀（浮点压缩） | 优秀（列式压缩） | 优秀（gorilla 压缩） |
| 数据保留策略 | 原生支持 | 通过分区实现 | 原生支持 |
| 复杂查询 | 较弱 | 强（完整 SQL） | 弱（仅聚合） |
| 集群方案 | 企业版 | 原生支持 | Thanos / Cortex |
| 适用场景 | 纯时序监控 | 时序+关系混合 | Prometheus 生态 |
4.4 选型建议：我的实战经验
说了这么多，到底怎么选？我根据自己的项目经验，给你几个参考：
- 如果你只需要存监控指标（CPU、内存、网络延迟等），选 InfluxDB。它写入快，查询简单，运维成本低。
- 如果你需要存行情数据，还要做分析（比如回测、因子计算），选 TimescaleDB。SQL 的灵活性是无可替代的。
- 如果你已经在用 Prometheus 做监控，那就用 Prometheus TSDB 存监控数据，别折腾。但别用它存业务数据。
- 如果你既要又要（既要监控又要分析），可以考虑 InfluxDB + TimescaleDB 混用。我有个项目就是这么干的——监控走 InfluxDB，行情分析走 TimescaleDB。
我的建议：对于量化交易系统，我个人最推荐 TimescaleDB。原因很简单——你迟早会需要做复杂的 SQL 查询。别为了省事选 InfluxDB，后面改起来很痛苦。
4.5 架构示意图
下面这张图展示了三种时序数据库在交易系统中的典型位置：
这张图展示了我比较推荐的一种混合架构。行情数据和交易记录走 TimescaleDB，方便做 SQL 分析。系统监控指标走 InfluxDB，写入快、告警方便。如果团队已经在用 Prometheus，那就保留它做服务发现和基础监控。
4.6 性能对比：一个简单的基准测试
我之前在同样的硬件上（4核8G，SSD）做过一个简单的测试。写入 1000 万条时序数据，每条包含时间戳、两个浮点字段、一个标签字段。
| 数据库 | 写入耗时 | 磁盘占用 | 查询最近1小时（聚合） |
|---|---|---|---|
| InfluxDB 2.x | 12 秒 | 180 MB | 0.8 秒 |
| TimescaleDB 2.x | 28 秒 | 320 MB | 1.2 秒 |
| Prometheus TSDB | 15 秒 | 210 MB | 0.6 秒 |
可以看到，InfluxDB 写入最快，压缩比也最好。TimescaleDB 因为要维护 PostgreSQL 的完整功能，开销大一些。Prometheus TSDB 介于两者之间。
但注意，这个测试只是参考。实际生产环境中，查询复杂度、并发数、数据分布都会影响性能。我建议你拿自己的数据跑一遍测试，别光看网上的 benchmark。
4.7 总结一下
选时序数据库，没有银弹。
InfluxDB 快但功能受限，TimescaleDB 灵活但稍重，Prometheus TSDB 专一但适用范围窄。我的建议是：
- 监控场景 → InfluxDB
- 分析场景 → TimescaleDB
- Prometheus 生态 → 别折腾，就用它自带的
嗯，大概就是这样。如果你正在做选型，不妨先想清楚自己的核心需求是什么——是写入速度？查询灵活性？还是运维简单？想清楚了，答案自然就有了。