JRY's digital garden

时序数据库选型

10 min read

时序数据库选型

引言

在数据采集层架构中，设备数据以高频、持续的方式产生，传统关系型数据库在写入性能和存储效率上难以满足需求。时序数据库（Time Series Database, TSDB）专为时序数据场景设计，是工厂数据平台的核心存储引擎之一。本文从工厂场景的实际需求出发，对比分析主流时序数据库产品的选型策略。

为什么需要时序数据库

时序数据的特征

工厂设备产生的数据具有鲜明的时序特征：

  • 有序性：数据按时间顺序产生，时间戳是最重要的维度
  • 高频写入：单设备可产生100Hz-10kHz的采样数据
  • 极少更新：历史数据写入后几乎不修改
  • 批量读取：分析时需要读取一段时间范围内的数据
  • 降采样需求：长期存储需要从秒级聚合到分钟/小时级

关系型数据库的局限

对比维度关系型数据库时序数据库
写入性能万级TPS百万级TPS
存储压缩无专门压缩列式存储+专用压缩算法
时间查询通过索引，效率一般原生支持，极致优化
聚合查询需要SQL聚合内置降采样和聚合函数
数据保留手动清理自动数据保留策略

以一个100台设备、每台1000个采集点、1秒采集频率的工厂为例，每日新增数据量约86亿条记录。关系型数据库在这个量级下，写入性能和存储成本都会成为瓶颈。

主流产品对比

InfluxDB

InfluxDB是目前最流行的开源时序数据库之一：

优势：

  • 生态成熟，文档丰富，社区活跃
  • Flux查询语言功能强大
  • Telegraf采集Agent支持200+输入插件
  • 云原生设计，支持Kubernetes部署

劣势：

  • 集群版（InfluxDB Enterprise）商业收费，社区版不支持集群
  • 2.x版本重构后性能有波动
  • 内存消耗较高

适用场景：中小规模工厂（<100台设备），或已使用Telegraf生态的项目。

TDengine

TDengine是涛思数据开源的时序数据库，在国内工业IoT领域应用广泛：

优势：

  • 极致的写入性能（单机千万点/秒）
  • 超高压缩比（通常10:1以上）
  • SQL语法，学习成本低
  • 内置消息队列、缓存功能，减少技术栈复杂度
  • 集群版开源（AGPL-3.0协议）

劣势：

  • 生态相对InfluxDB较窄
  • 复杂查询能力有待加强
  • 社区以国内为主，国际化程度不高

适用场景：大规模设备数据采集，追求极致性能和低存储成本，优先选择国产化方案。

Apache IoTDB

IoTDB是清华大学主导、Apache基金会孵化的时序数据库：

优势：

  • 专为IoT场景设计，对设备数据模型有原生支持
  • 端-边-云协同架构，支持边缘部署
  • 内置文件格式TsFile，支持离线数据分析
  • 对齐时序（aligned timeseries）特性，适合多传感器同步数据

劣势：

  • 社区规模较小
  • 运维工具不够成熟
  • 与大数据生态集成需要额外开发

适用场景：边缘-云协同场景，需要在网关侧部署轻量级时序数据库。

MatrixDB

MatrixDB是基于PostgreSQL（Greenplum）的分布式时序数据库：

优势：

  • 基于PostgreSQL生态，SQL兼容性好
  • 分布式架构，水平扩展能力强
  • 支持时序+GIS+关系型混合查询
  • 与Greenplum大数据平台无缝集成

劣势：

  • 社区较小，商业支持为主
  • 部署和运维复杂度较高
  • 小规模场景下资源开销偏大

适用场景：已有Greenplum/PostgreSQL生态的大型企业，需要时序与关系数据联合查询。

TimescaleDB

TimescaleDB是基于PostgreSQL扩展的时序数据库：

优势：

  • 完全兼容PostgreSQL生态，可复用PG丰富的扩展和工具
  • 自动分区（Hypertable），对应用透明
  • 持续聚合（Continuous Aggregate）功能强大
  • 开源版本功能完整（Apache 2.0协议）

劣势：

  • 写入性能相比专用TSDB有一定差距
  • 大规模集群部署需要依赖Citus等扩展
  • 压缩比不如TDengine

适用场景：需要与PostgreSQL深度集成的场景，或时序数据量适中（亿级/天以下）的项目。

综合对比

维度InfluxDBTDengineIoTDBMatrixDBTimescaleDB
写入性能★★★★★★★★★★★★★★★★★★★
压缩比★★★★★★★★★★★★★★★★★★★
查询能力★★★★★★★★★★★★★★★★★★★
集群能力★★★★★★★★★★★★★★★★★★★
生态丰富度★★★★★★★★★★★★★★★★★★★
运维复杂度低低中高中
开源协议MITAGPL-3.0Apache-2.0Apache-2.0Apache-2.0(社区版)
国产化否是是是否

选型决策树

数据量级？
├── < 1000万点/天
│   ├── 已有PostgreSQL生态？ → TimescaleDB
│   └── 否 → InfluxDB 或 TDengine
├── 1000万-10亿点/天
│   ├── 需要国产化？ → TDengine
│   └── 否 → TDengine 或 InfluxDB(付费集群)
└── > 10亿点/天
    ├── 需要混合查询？ → MatrixDB
    └── 否 → TDengine 集群版

关键选型考量

  1. 数据量级：决定了单机还是集群部署，直接影响技术选型
  2. 查询模式：实时查询为主（选TDengine）还是复杂分析为主（选TimescaleDB/MatrixDB）
  3. 运维能力：团队技术栈和运维能力决定了对复杂系统的承受度
  4. 国产化要求：部分行业（军工、能源）有国产化硬性要求
  5. 生态集成：与现有技术栈的兼容性和集成成本

与数据湖的协同

时序数据库主要处理热数据（最近7天-30天的高频数据），而数据湖负责冷数据（历史归档数据的批量分析）：

设备数据 → [热数据]时序数据库(TDengine) → 实时查询、看板
         → [温数据]OLAP(Doris) → 交互式分析
         → [冷数据]数据湖(Iceberg) → 长期归档、离线分析

数据生命周期管理策略：

  • 0-7天：全量高频数据存储在时序数据库，支持秒级查询
  • 7-90天：降采样至分钟级，存储在OLAP引擎或时序库
  • 90天以上：降采样至小时级，归档至数据湖

这种分层存储策略在工厂数据平台总体架构中是成本与性能平衡的关键设计。

实践建议

  1. PoC先行：在正式选型前，用实际工厂数据进行性能和功能验证
  2. 关注运维：时序数据库的长期稳定运行比峰值性能更重要
  3. 预留扩展空间：工厂设备会持续增加，选型时按3倍预期规模评估
  4. 统一数据接入：通过数据采集层架构的标准化设计，降低时序数据库更换的成本
  5. 监控先行：时序数据库本身的运行状态（写入延迟、存储使用率）需要完善监控

总结

时序数据库是工厂数据平台的核心组件，选型需要综合考量数据量级、查询模式、运维能力和生态兼容性。TDengine在纯时序场景表现卓越，TimescaleDB在混合场景中灵活度高，InfluxDB在生态和易用性上领先。无论选择哪款产品，都需要与实时数据流水线和数据湖形成完整的数据生命周期管理体系。

Graph View

Backlinks