工业时序数据库对比：InfluxDB、TDengine、IoTDB、OpenTSDB 到底怎么选

工业数据采集的数据量级和写入频率跟互联网监控数据完全不是一个数量级。一个中型工厂上万个采集点、每秒几十万条数据、动辄几年的存储保留期，让通用数据库不堪重负。时序数据库因此成为工业软件栈里不可或缺的一层。这两年可选的产品越来越多，InfluxDB、TDengine、IoTDB、OpenTSDB 是四个主流选项，但它们的架构差异、性能特点、生态成熟度差别不小。今天从技术架构、写入性能、查询能力、生态五个维度做一次冷静盘点。

一、四款产品的技术出身

InfluxDB

InfluxDB 是 InfluxData 公司 2013 年开源的时序数据库，是最早把"时序数据库"这个概念做成产品的团队之一。InfluxDB 1.x 用 TSM 存储引擎、Go 语言实现，简单易用。2.x 引入 Flux 查询语言、任务系统。3.x 用 Rust 重写，底层切换到 Apache Arrow 和 Parquet 列存，同时支持 SQL。InfluxDB 3.0 之后，云原生特性显著增强。

TDengine

TDengine 是涛思数据 2017 年发布的国产时序数据库，2020 年开源。核心特点是"一个设备一张表、超级表逻辑抽象"，把物联网场景里普遍存在的高基数标签问题优雅地解决。TDengine 用 C 语言实现，从写入、查询到集群管理都自研，不依赖 Kafka、Redis 等外部组件。3.x 版本进一步引入云边端一体化架构，支持流式计算和缓存一体化。

IoTDB

IoTDB 是清华大学软件学院孵化的开源项目，2020 年进入 Apache 孵化器，2022 年毕业成为 Apache 顶级项目。IoTDB 提出"树状元数据模型"，用类似文件系统的路径表达设备与测点关系，非常契合工业设备的层级结构。存储引擎 TsFile 针对时序场景做了大量优化。IoTDB 目前是国内工业互联网项目中标率最高的时序数据库之一。

OpenTSDB

OpenTSDB 是最早出现的时序数据库之一，2010 年开源，架构上是 HBase 的一层封装。写入通过 HTTP 或 Telnet 接口，数据以 tag 组织，查询通过 HTTP API 返回 JSON。优点是继承 HBase 的水平扩展能力，缺点是运维复杂、依赖组件多、生态迭代缓慢。现在 OpenTSDB 更多以"历史存量系统"的角色存在，新项目采用率下降。

二、四款产品核心特性横向对比

表格
特性 InfluxDB 3.x TDengine 3.x IoTDB 1.x OpenTSDB 2.x
开发语言 Rust C Java Java
存储引擎 Parquet+Arrow TSDB 自研 TsFile 自研 HBase
数据模型 表+标签 超级表 树状路径 指标+标签
查询语言 SQL+Flux SQL SQL+MQTT HTTP API
集群模式 云原生 无依赖集群 分布式副本 依赖 HBase
单机写入吞吐 百万点/秒 千万点/秒 百万点/秒 十万点/秒
压缩比 5-10倍 10-20倍 10-15倍 3-5倍

[数据来源：各产品**发布的性能白皮书 2025 版、Apache IoTDB 社区基准测试报告]

三、写入性能的现实差异

单机写入吞吐

TDengine 由于"一个设备一张表"的架构设计，避免了写入时的索引维护开销，在物联网高吞吐场景下拥有明显优势。基准测试显示 TDengine 单机在四十万测点场景下可以稳定跑到 1000 万条每秒的写入吞吐；InfluxDB 3.x 通过 Arrow 内存格式优化后在类似场景下达到 100 到 200 万条每秒；IoTDB 单机测试稳定在 150 万条每秒；OpenTSDB 依赖 HBase 的写入路径较长，同等硬件下大致在 5 到 15 万条每秒。

[数据来源：涛思数据《TDengine 性能测试白皮书 2025》、Apache IoTDB TPC-x-IoT 基准测试报告]

高基数场景

工业场景一个常见挑战是"高基数"——同一测点在不同设备、不同工位、不同批次上都有独立时序。TDengine 的超级表设计对高基数天生友好，可以支持千万级子表。InfluxDB 3.x 之前在高基数场景性能会明显下降，切换到 Parquet 之后有较大改善。IoTDB 的树状模型也能支持高基数，但需要合理规划路径深度。OpenTSDB 在标签基数超过百万时性能显著衰减。

压缩比

工业时序数据具有大量重复模式（周期性、平稳段），压缩空间很大。TDengine 采用 Delta-Delta + LZ4/Zstd 混合压缩，在压力测试中可以达到 15 到 20 倍压缩比；IoTDB TsFile 用 SDT 和 RLE 结合，压缩比 10 到 15 倍；InfluxDB Parquet 存储压缩比 5 到 10 倍；OpenTSDB 依赖 HBase 底层压缩，3 到 5 倍。工业客户对存储成本敏感，压缩比直接影响硬件采购。

数据保留策略

工业客户通常需要按不同精度分层保留数据：原始高频数据保留一到三个月，秒级降采样保留一年，分钟级降采样保留三到五年。TDengine 的"数据保留策略 + 流式计算"可以在写入端自动生成不同精度的副本；IoTDB 通过时间分区表实现类似效果；InfluxDB 3.x 通过 Task 系统调度降采样；OpenTSDB 需要外置调度器，配置复杂。做长期存储规划时，这一点直接影响运维工作量。

断点续传与边缘容灾

工业现场经常出现网络抖动，采集器与数据库之间的写入通道必须支持断点续传。TDengine 的 taosAdapter、IoTDB 的 IoTDB Edge、InfluxDB 的 Telegraf 都提供了本地缓存机制，可以在网络中断时把数据缓存在边缘节点，恢复后自动回补。OpenTSDB 本身不提供这一能力，需要在采集侧独立实现，工厂运维经常在这里踩坑。

四、查询能力与工业场景适配

查询语言

SQL 兼容性是这两年工业时序数据库比拼的重点。TDengine 完全兼容标准 SQL，还扩展了时序特有的窗口函数、插值函数、状态窗口。IoTDB SQL 语法接近标准 SQL，同时兼容 MQTT 协议直连采集端。InfluxDB 从 3.x 开始默认支持 SQL，同时保留 Flux 兼容旧客户端。OpenTSDB 只支持 HTTP API 查询，不支持标准 SQL，与 BI 工具集成困难。

常见工业查询模式

工业场景高频的查询模式包括：任意窗口内的最大最小平均值、滑动窗口预警、多测点关联分析、跨设备聚合、状态变化捕捉。TDengine 和 IoTDB 针对这些模式做了专门优化，查询延迟通常在毫秒级；InfluxDB 3.x 通过预聚合任务实现类似能力；OpenTSDB 在复杂聚合场景下经常出现秒级延迟。

流式计算与实时预警

新一代工业时序数据库开始把流式计算作为内建能力。TDengine 3.x 内置了流式计算引擎，可以直接在数据库里定义连续查询和触发式预警。IoTDB 也在近期版本中增加了触发器机制。InfluxDB 提供 Task 定时任务但不是真正的流式引擎，仍需要外接 Flink 或 Kafka Streams。OpenTSDB 完全不支持流式计算。产线级预警场景选型时这一点值得重点关注，因为把预警逻辑放到数据库内部可以大幅降低端到端延迟。

与 AI 分析的对接

工业时序数据下游经常要接机器学习模型做异常检测、寿命预测。TDengine 提供了 Python 直连驱动和 pandas 数据帧接口，方便数据科学家在 Jupyter 里操作。IoTDB 通过 Session 接口支持批量拉取。InfluxDB 3.x 依赖 Arrow 内存格式与 Python pyarrow 无缝对接。OpenTSDB 需要通过 HTTP API 拉取 JSON，效率较低。

五、生态与合规

与工业协议集成

工业时序数据库需要跟 OPC UA、Modbus、MQTT、Kafka 等协议对接。TDengine 内置 OPC UA、MQTT、Modbus、HTTP 等直连接入模块，几乎不需要额外开发。IoTDB 深度支持 MQTT，OPC UA 需要通过独立采集组件。InfluxDB 生态里 Telegraf 采集器支持两百多种输入，覆盖面广但增加运维复杂度。OpenTSDB 需要用户自行搭建采集管道，工作量最大。

与可视化工具的对接

Grafana 是工业监控可视化的事实标准。四款数据库都提供了 Grafana 数据源插件。InfluxDB 由于历史深厚，Grafana **支持最完善；TDengine、IoTDB 的插件在社区中也很活跃；OpenTSDB 插件维护相对滞后。工业大屏还常用 Superset、DataEase、帆软等 BI 工具，SQL 兼容性直接影响接入难度，这也是 OpenTSDB 逐渐被替换的重要原因。

国产化与合规

工业互联网平台、能源、装备制造行业的国产化替代压力较大。TDengine 和 IoTDB 是国产阵营的两个代表，都通过了国内主流服务器和操作系统的兼容性认证，符合信创目录要求。InfluxDB 与 OpenTSDB 属于境外开源软件，用于关键信息基础设施行业时需要经过网络安全审查。GB/T 40218-2021《工业通信网络 网络和系统安全 工业自动化和控制系统信息安全评估》里对数据存储组件的安全要求也需要一并落实。

[数据来源：工业和信息化部《工业互联网创新发展行动计划 2024-2026》、GB/T 40218-2021 国家标准]

六、选型建议

如果工厂主要场景是设备台账多、单点采集频率高，TDengine 和 IoTDB 都能提供领先的写入性能，TDengine 在运维简单度上略胜，IoTDB 在树状建模上更契合行业。如果企业已有 Grafana、Kafka、Telegraf 一整套云原生工具链，InfluxDB 3.x 的生态一致性最好，学习曲线也最平滑。如果只是新项目起步，OpenTSDB 已经不建议作为首选，除非公司内部有大量存量 HBase 集群可以复用。选型最终不是"哪家最强"，而是"哪家跟你现有的采集架构、运维能力、合规要求最匹配"。做技术验证时，一定要用真实业务数据跑压力测试，不要相信厂商 PPT 上的漂亮数字。压缩比、写入延迟、并发查询这三个指标必须自己动手压出来才靠谱。此外还需要评估长期演进的风险：数据库软件生命周期通常比工厂设备短，选型时应把版本兼容性和数据迁移工具的成熟度也纳入考量。

[数据来源：中国电子技术标准化研究院《数据库发展研究报告 2025》、Gartner《Magic Quadrant for Cloud Database Management Systems 2025》]