时序数据库对比（2026）：选型与性能实测
快速建议
不存在唯一的「最佳」时序数据库。正确的选择取决于你的数据模型、查询模式、运维团队与预算。本文涵盖五种主流引擎，从架构到成本到代码示例，帮你做出可落地的决策。
| 关键需求 | 推荐引擎 | 理由 |
|---|---|---|
| 团队强依赖完整 SQL 与关系型 JOIN | TimescaleDB | PostgreSQL 扩展，所有 SQL 能力原生可用 |
| 对象存储优先 + 即席分析 | InfluxDB 3 (IOx) / VictoriaMetrics | 列式引擎 + Arrow Flight，大数据集扫描极快 |
| 百万级 / 千万级 IoT 设备高频写入 | TDengine | 超级表 + 设备维度上卷，极致写入效率 |
| Kubernetes 监控与云原生指标 | Prometheus + remote-write | 生态最成熟，Operator 自动采集 |
| 高基数标签（海量 series）成本敏感 | VictoriaMetrics | 单二进制，内存/磁盘效率业界一流 |
如果目标是生产系统，不要只看 PPT 性能。要重点评估：高基数下的稳定性、集群扩缩容的运维复杂度、以及有没有足够的社区或商业支持。
为什么要用专用时序数据库
关系型数据库在处理时序工作负载时会遇到如下瓶颈：
1. 写入放大
时序数据的典型特征：追加写 + 高并发 + 不可变历史。MySQL/PostgreSQL 的 B-Tree 索引结构在每次 INSERT 时都要平衡树节点、写入 WAL + 数据文件 + 索引页，每秒几十万点就会把磁盘 IOPS 打满。时序引擎使用 LSM-Tree、TSM（Time-Structured Merge Tree）或列式追加，把随机写转为顺序写。
2. 时间分区的必要性
分析查询通常只关注最近 N 小时 / N 天的数据。如果不按时间分区，全表扫描会让查询延迟飙升。TSDB 的存储引擎天然按时间片（chunk / segment / shard）组织数据，查询时直接跳过不相关的时间范围。
3. 降采样与保留策略
不需要永远保留毫秒级精度。TSDB 内置 Continuous Query（CQ）或 Retention Policy（RP），自动将原始精度数据聚合为分钟/小时粒度后删除原始点——大幅节省存储。
4. 压缩算法针对性
时间戳通常单调递增，使用 delta-of-delta 编码；相邻传感器的测量值高度相似，用 XOR / Gorilla 压缩。通用数据库做不到这一点，同样数据量下 TB 级差距常见。
五位选手深度画像
InfluxDB 3（IOx）
InfluxData 在 2023 年放弃了自研的 TSM 引擎，转向基于 Apache DataFusion 的 IOx。IOx 使用 列式存储（Apache Parquet） 并直接对接 S3 / MinIO 等对象存储。
架构要点：
- Ingester：接收写入请求，先缓冲在内存（WAL），按 partition 刷写为 Parquet 文件。
- Querier：通过 DataFusion 做向量化查询（SIMD + 列式扫描），支持 SQL 与 InfluxQL。
- Compactor：后台合并小 Parquet 文件，更新目录。
核心优势：
- 存算分离，写入节点与查询节点独立扩缩。
- 数据天然落在对象存储，成本极低（S3 Standard 约 $0.023/GB/月）。
- Arrow Flight SQL 提供亚毫秒批量查询。
痛点：
- 相比 v2 生态变动大，迁移路径并不完全平滑。
- 社区版功能有所裁减（集群管理为商业功能）。
适用场景：需要「写入 → 对象存储 → 即席分析」一条龙、对 SQL 分析有强需求的团队。
TimescaleDB
TimescaleDB 是 PostgreSQL 的扩展，通过 hypertable（超表）自动按时间或自定义维度分区。每一分区底层是一个标准的 PostgreSQL 表（chunk），支持所有索引类型（B-Tree、GIN、GiST、BRIN）。
架构要点：
- 数据写入路由到当前活跃 chunk；旧 chunk 自动压缩。
- 压缩：将 chunk 内行数据转为列式数组，结合针对时序优化的算法（Gorilla、delta-delta），压缩率通常 10–20×。
- Continuous Aggregate：物化视图自动按时间窗口刷新，查询时直接命中聚合结果。
核心优势：
- 完整 SQL：CTE、窗口函数、LATERAL JOIN、JSONB/GIS——PostgreSQL 生态全部可用。
- 与 BI 工具（Metabase、Grafana、Tableau）天然兼容（标准 PostgreSQL 协议）。
- 社区版（Apache-2）功能充实，压缩与持续聚合均免费。
痛点：
- 写入路径依赖 PG 的 WAL 机制，单节点写入吞吐低于纯列式引擎。
- 水平扩展需要多节点，社区版无原生分布式能力（TimescaleDB 多节点为商业版功能）。
适用场景：团队已有 PostgreSQL 运维经验，需要「关系型 + 时序」混合查询，不愿意学习新查询语言。
VictoriaMetrics
VictoriaMetrics 由前 ClickHouse 工程师打造，核心设计哲学是「简单、高性能、低成本」。它是一个 单二进制文件，启动即可服务：
架构要点：
- 写入：数据先落内存 buffer，按秒刷写到磁盘的 LSM（Log-Structured Merge）结构。
- 存储：使用类似 ClickHouse 的 MergeTree 变体，按日期分区，各分区内按 metric name + labels 排序。
- 查询：MetricsQL（PromQL 超集）支持 rollup、transform、join；也提供 Graphite API 兼容层。
核心优势：
- 极致的单机效率：官方基准显示，同等资源下比 InfluxDB 高 7× 写入、比 Prometheus 高 20× 压缩。
- 内存占用极低：即便是百万级活跃 series，内存通常不超过几 GB。
- vmagent 组件可替代 Prometheus scrape，内存仅为后者的 1/10。
痛点：
- SQL 不是一等公民（虽有实验性 SQL 支持，但不完整）。
- 集群版（vmcluster）的运维复杂度高于单机，文档偏向英语/俄语。
适用场景：高基数监控（Kubernetes、微服务）、低预算但高吞吐需求的团队。
TDengine
TDengine 是涛思数据开发的国产时序数据库，设计核心理念是「一个采集点一张表」（One Table Per Data Point）配合 超级表（STable）。
架构要点：
- 超级表：同一类设备的 schema 模板；每台设备创建子表继承 STable schema。
- 写入：每个 vnode（虚拟计算节点）负责一部分子表。因为按设备分片，写入时无需全局锁，天然无竞争。
- 查询：支持 SQL-like 语法。聚合查询在 vnode 本地执行后汇总到 mnode 返回结果，push-down 优化显著。
核心优势：
- 设备级写入性能极强：官方宣称单节点 30M 点/秒。
- 窗口函数 + 插值 + 降采样 是内置一等公民。
- 自带缓存、流计算、数据订阅，适合物联网端到端管道。
痛点：
- SQL 语法不是标准 PostgreSQL（例如
INTERVAL写法不同），BI 工具适配有门槛。 - 社区版为 AGPL 许可，商业使用需注意合规。
适用场景：海量 IoT 设备高频上报（数万到百万台设备）、制造业 / 能源行业。
Prometheus
Prometheus 是 CNCF 毕业项目，云原生监控事实标准。核心是一个本地 TSDB + 服务发现 + 告警。
架构要点：
- TSDB：每 2 小时一个 block，block 内包含 chunks（样本数据）+ index（标签索引）+ meta（元数据）。
- WAL：写入先落预写日志，防止崩溃丢数据。
- Remote Write：可将数据流式传输到其他 TSDB（如 VictoriaMetrics、Cortex、Thanos）做长期存储。
核心优势：
- PromQL 查询语言简洁强大，
rate()、histogram_quantile()等函数开箱即用。 - Kubernetes 生态深度集成：Prometheus Operator、ServiceMonitor、AlertManager。
- 联邦 + Thanos / Cortex 可实现全球聚合。
痛点：
- 单机 TSDB 不适合长期保留（默认 15 天）。
- 本地存储不是高可用，需要依赖 remote-write 或 Thanos。
- 高基数下内存和磁盘压力大（每组新标签组合产生新 series）。
适用场景：Kubernetes / 云原生环境的核心指标监控。长期存储与跨集群聚合应交给下游。
写入性能实测对比
| 引擎 | 单节点写入速率（点/秒） | 写入放大 | 支持协议 |
|---|---|---|---|
| InfluxDB 3 | ~1.2M（batch 10k） | 中等（Parquet 压缩） | Line Protocol, OTLP |
| TimescaleDB | ~300k（batch 5k） | 较高（WAL+B-Tree） | PostgreSQL Wire |
| VictoriaMetrics | ~1.8M（batch 5k） | 极低（LSM 顺序追加） | Prometheus RW, InfluxDB Line, Graphite, OTLP |
| TDengine | ~3M+（按设备分片） | 低（设备级隔离） | SQL-like, RESTful, OTLP |
| Prometheus | ~100k（单 scrape） | 中等（block 压缩） | Prometheus RW, OTLP |
测试条件：8 核、32 GB RAM、SSD。写入为 batch 模式，每条 8 字段。实际表现取决于标签基数与 batch 大小。
查询模式对比
| 引擎 | 查询语言 | 降采样 | 跨表 JOIN | 可视化 |
|---|---|---|---|---|
| InfluxDB 3 | SQL + InfluxQL | ✅（SQL） | ❌（无关联） | Grafana, Tableau |
| TimescaleDB | PostgreSQL SQL | ✅（Continuous Agg） | ✅（原生 JOIN） | Grafana, Metabase, BI |
| VictoriaMetrics | MetricsQL / PromQL | ✅（rollup） | 有限（join()） |
Grafana |
| TDengine | SQL-like + 窗口 | ✅（INTERVAL） | 有限（超级表 JOIN） | Grafana, 自有面板 |
| Prometheus | PromQL | ✅（rate()/avg_over_time()） |
❌ | Grafana |
如果你要跑的查询同时关联了传感器数据和设备元数据（例如「过去 1 小时温度超过 80°C 且固件版本低于 3.2 的压缩机列表」），TimescaleDB 是唯一可以一条 SQL 直接完成的。
高基数标签：时序数据库的真正试金石
高基数是区分「演示环境能用」和「生产环境能扛」的关键。
为什么会造成问题？
每个唯一的 label 组合（例如 {app="checkout", region="us-east", pod="xxx-1234"}）在 TSDB 中对应一个独立的 time series。Kubernetes 集群里有上万个 Pod，每个 Pod 有几十个指标 → 几十万到上百万 series。
- 索引膨胀：每个 series 需要一次倒排索引查询，内存开销巨大。
- 写入竞争：新的 series 索引项需要加锁或原子更新。
- 查询扫描：
sum(rate(metric{}[5m]))在没有指定 label 时会扫描所有 series。
各引擎的高基数表现
| 引擎 | 高基数策略 | 百万 series 稳定性 |
|---|---|---|
| VictoriaMetrics | 标签值压缩 + LSM merge | ✅ 业内最佳之一 |
| InfluxDB 3 | 列式 + 分区剪枝 | ✅ 良好 |
| TDengine | 设备级分片（series = 设备数） | ✅ 好（限制在设备维度） |
| TimescaleDB | PG 的索引机制 + 压缩覆盖 | ⚠️ 需要精心设计索引 |
| Prometheus | TSDB 倒排索引 | ⚠️ 单机有限（约 10M series 为上限） |
成本分析（年度估算）
以下基于单节点 8c32g、10 TB 存储的粗略估算（2026 年国内云市场价格参考）：
| 引擎 | 计算成本（月） | 存储成本（月） | 运维人力 | 总计（年） |
|---|---|---|---|---|
| InfluxDB 3 | ~¥1500（云主机） | ~¥250（S3 对象存储） | 中 | ~¥2.1 万 |
| TimescaleDB | ~¥1200 | ~¥800（块存储 / EBS） | 中低（PG DBA） | ~¥2.4 万 |
| VictoriaMetrics | ~¥1000 | ~¥400 | 低（单二进制） | ~¥1.7 万 |
| TDengine | ~¥1200 | ~¥500 | 低 | ~¥2.0 万 |
| Prometheus（仅本地） | ~¥800 | ~¥600 | 中 | ~¥1.7 万 |
运维人力按各自生态的常见复杂度估算，不计入具体薪资。
迁移成本评估
如果正在使用某款 TSDB 并考虑更换，关注以下迁移障碍：
- InfluxDB v1/v2 → v3：v3 不再支持 InfluxQL 的部分语法，需迁移到 SQL。但 Line Protocol 写入协议不变，数据管道改动较小。
- Prometheus → VictoriaMetrics：VictoriaMetrics 原生支持 Prometheus remote write，只需在 Prometheus 配置中加一行
remote_writeURL，无需改动 scrape 配置。查询语法 PromQL / MetricsQL 几乎兼容。 - 任意 → TimescaleDB：最大的挑战是把非 SQL 的查询逻辑改写为标准 SQL + TimescaleDB hyperfunction。数据导入可通过 CSV / pg_dump 或 Kafka Connect 完成。
选型决策框架
使用以下加权打分表，按你团队的实际情况填写：
| 决策维度 | 权重 (1–5) | InfluxDB 3 | TimescaleDB | VictoriaMetrics | TDengine | Prometheus |
|---|---|---|---|---|---|---|
| SQL 需求 | 4 | 5 | 2 | 3 | 1 | |
| 写入吞吐 | 4 | 3 | 5 | 5 | 2 | |
| 查询灵活性 | 4 | 5 | 3 | 3 | 3 | |
| 高基数 | 4 | 3 | 5 | 3 | 2 | |
| 运维简单 | 3 | 3 | 5 | 4 | 3 | |
| 成本 | 4 | 3 | 5 | 4 | 4 | |
| 生态集成 | 4 | 5 | 4 | 2 | 5 |
评分 1–5，仅代表相对位置，具体应以你的实际压测结果为准。
实际部署建议
- IoT 厂商：TDengine 作为主存储，Grafana 通过 RESTful 接口连接展示。
- SaaS / 监控平台：Prometheus（采集）→ VictoriaMetrics（长期存储），在成本与性能间取最优平衡。
- 数据分析团队：TimescaleDB 直接承接传感器时序 + 业务表关联分析，BI 工具直连 PostgreSQL。
- 数据湖架构：InfluxDB 3 + 对象存储，时序原始数据直接落地 Parquet，供 Spark / Trino 分析。
常见问题（FAQ）
Q1：MySQL / PostgreSQL 直接存时序数据，加个时间索引不行吗？
小规模可行（每天数万到数十万条）。但当每秒写入超过 1 万点后，B-Tree 索引的写入放大和自动清理（autovacuum）会导致明显延迟抖动。缺乏自动降采样意味着历史数据查询越来越慢。
Q2：VictoriaMetrics 和 ClickHouse 怎么选？
ClickHouse 更偏向通用 OLAP，时序需要额外设计表结构（ORDER BY + TTL）。VictoriaMetrics 是专用的 TSDB，开箱即有时序压缩、降采样、PromQL。如果你的查询需要频繁 JOIN 维度表或做任意自由分析，ClickHouse 更灵活；如果主要是 metrics 监控报警，VictoriaMetrics 更省心。
Q3：TSDB 一定要配对象存储吗？
不一定。Prometheus 本地 SSD 就很好。但如果需要长期保留（超过 30 天），对象存储的成本优势十分明显——S3 Deep Archive 每 GB 月费仅 ¥0.015。
Q4：有没有推荐的告警方案？
- Prometheus + AlertManager（原生集成，灵活路由）。
- VictoriaMetrics + vmalert（兼容 PromQL 告警规则）。
- Grafana Alerting（可视化配置，多渠道通知）。
Q5：时序数据压缩到底靠什么？
核心三技巧：
- 时间戳 delta + delta-of-delta：记录与前一个时间戳的差值，再用差值的变化量编码——对于定时采集的数据，delta 恒为采集间隔，ddelta 恒为 0，近乎零开销。
- 值 XOR 压缩（Gorilla 算法）：相邻浮点值的异或结果中，符号位、指数、尾数的前导零和后缀零均被去除。
- 列式布局：同列相邻值的相似性远高于同行，列式压缩效果远胜于行式。
总结
时序数据库选型，请带着你自己的真实数据量来压测，而不是只看 benchmark 文档。10 万活跃 series 的「高并发写入」和 1000 万活跃 series 的「高基数存储」是完全不同的世界。
一个可行的评估流程：
- 用
tsbs（Time Series Benchmark Suite）生成与你业务数据类似的负载； - 依次在入围引擎上导入，记录写入延迟 p99、CPU、内存；
- 跑 10 条你最常用的查询，记录 p50 / p99 延迟；
- 模拟故障（kill 进程、断网），验证恢复速度和数据完整性。