引言：制造业 IT 团队的选型困境

制造业数字化转型进入深水区，设备联网、产线实时监控、能耗统计、故障追溯等场景对时序数据库（TSDB）的需求持续上升。在项目方案设计阶段，研发与 IT 团队经常面临选型难题：市面上时序数据库产品繁多，InfluxDB、TimescaleDB、TDengine、Apache IoTDB、Prometheus 等各有技术路线；写入性能、集群能力、工业协议生态、开源许可证约束、国产化适配、长期运维成本，多个维度交织在一起，很难快速取舍。

本文立足于制造业真实落地场景，对八大主流时序相关存储引擎进行系统性横向梳理，厘清各自技术架构、优势、短板、适用边界，围绕写入性能、存储压缩、工业生态、许可证合规、集成难度等关键维度展开对比，帮助制造企业结合自身业务规模、技术栈、合规要求完成选型评估。

重要说明：本文区分「原生时序数据库」与「可承载时序数据的通用引擎」；ClickHouse 属于 OLAP 分析引擎，并非专为时序场景设计，但工业领域大量用来做时序数据离线分析，纳入对比方便读者完整评估。

一、八大主流时序数据库概览

InfluxDB —— 被广泛使用的时序数据库

由 InfluxData 公司研发，是工业物联网领域普及度很高的时序数据库。

• 技术演进：早期 InfluxDB V1 采用自研存储引擎；V2 重构架构，整合 API 与任务调度；InfluxDB 3.0 使用 Rust 重构底层，基于 Apache Arrow、Parquet 开放数据格式，彻底摆脱旧版本存储引擎瓶颈。
• 数据模型：Measurement（测量指标）+ Tag（维度标签）+ Field（数值指标）+ Timestamp，天然适配传感器多维度采集模型。
• 配套生态：官方提供 Telegraf 采集框架，内置 300 + 采集插件，原生支持 MQTT、Modbus、OPC UA、S7 等大量工业协议，可直接对接 PLC、边缘网关、SCADA 设备，无需从零开发采集程序；自带任务调度、告警、数据降采样、数据 TTL 能力。
• 许可证现状：InfluxDB 3.0 Core 采用 Apache 2.0 开源协议，商用约束低；企业版提供集群、高可用、技术支持等增值能力，需要商业授权。
• 优势：工业采集生态完整，学习资料丰富，上下游工具链成熟；时序查询语法简单，实施门槛低。
• 短板：V1/V2 旧版本存在集群能力弱、资源占用偏高历史问题；升级至 3.0 存在一定迁移成本；超大分布式集群场景落地案例少于部分国产时序数据库。
• 制造业适配场景：中小型 / 中型工厂设备采集、产线实时监控、能耗采集、边缘网关本地时序存储。

TimescaleDB —— PostgreSQL 时序扩展

作为 PostgreSQL 的时序扩展，完全兼容 SQL 和 PG 生态。通过超表（Hypertable）自动分区，压缩率高达 95%。适合已有 PostgreSQL 技术栈的制造企业，可复用现有驱动和工具链。

定位：基于 PostgreSQL 构建的时序扩展引擎，不是独立数据库进程，深度复用 PostgreSQL 内核。

• 核心机制：提出超表（Hypertable），底层自动按时间范围分区，对外依然呈现单表形态，开发者无需手动管理分区。支持时序数据后台压缩、连续聚合、TTL 生命周期管理。
• 兼容性：100% 兼容标准 SQL、PostgreSQL 生态驱动、连接池、监控工具、备份恢复方案。开发人员无需学习全新查询语法。
• 架构模式：支持单机与分布式集群部署。
• 许可证：社区版开源，商业版提供官方支持、高级高可用特性。
• 优势：学习成本极低，企业现有 PG 技术栈可以无缝承接；时序数据和 MES 业务结构化数据可以在同一数据库内关联查询；事务能力继承 PostgreSQL，适合需要时序数据与业务工单联合分析的场景。
• 短板：底层依托 B+Tree，极限高吞吐写入场景性能弱于原生 LSM 架构时序数据库；海量点位（百万级设备）场景资源开销相比专用 IoT 时序数据库更高。
• 制造业适配场景：企业已经大规模使用 PostgreSQL；需要联合查询时序采集数据与生产工单、设备档案等业务数据；中低速采集规模场景。

TDengine —— 国产工业 IoT 专用

涛思数据推出、面向工业物联网场景设计的国产时序数据库。

• 核心创新模型：超级表（STable）+ 子表，推荐 “一台设备一张子表” 的划分方式，贴合工厂「设备独立采集」的数据特征，减少不同设备数据之间的索引竞争。
• 架构特点：内置消息队列、缓存、计算引擎一体化能力，官方宣称可以简化平台组件，理论上可省去额外部署 Kafka；支持时序聚合、流式计算、数据 TTL。
• 许可证重点说明：不同版本协议存在差异，早期社区版采用 AGPLv3 许可证，该协议具备较强传染性；企业进行商用部署、二次嵌入前，务必组织法务团队完成知识产权合规评估。商业版本提供宽松商业协议、集群、技术支持。
• 优势：国产自主可控路线；针对海量物联网设备场景深度优化；国内工业项目落地案例丰富，本地化技术支持渠道完善。
• 短板：自定义 SQL 扩展语法，开发者需要学习特有概念；生态工具相比 InfluxDB 更少，采集端需要自行对接工业网关或者基于 SDK 开发。
• 制造业适配场景：海量设备、大规模多厂区集团型物联网项目；有国产化替代要求的制造企业。

Prometheus —— 云原生监控标配

CNCF（Cloud Native Computing Foundation，云原生计算基金会） 毕业项目，云原生监控领域事实标准。

• 采集模型：采用 Pull（拉取）模式，服务主动周期性抓取指标数据，区别于工业 IoT 普遍使用的设备主动上报 Push 模式。
• 存储与定位：原生设计面向 IT 基础设施短期监控，默认配置较短的数据保留周期。单节点不适合长期持久存储 TB 级原始传感器采集数据。
• 查询语言：PromQL，擅长瞬时指标、区间指标计算。配套 Alertmanager 实现告警管理。
• 许可证：Apache 2.0。
• 优势：云原生生态完善，K8s 环境标配；运维工具、监控面板资源丰富。
• 短板：原生不适合工业 IoT 典型的 Push 上报模型；缺少完善的数据降采样、冷热分层能力；不适合长期保存高频传感器原始采集数据。
• 制造业适配场景：工厂服务器、虚拟化平台、容器等 IT 基础设施监控；不建议直接用于产线 PLC、传感器海量采集存储。

QuestDB —— 极致写入性能

主打极致单机写入性能的开源时序数据库。

• 底层架构：自研列式存储，针对时序追加写入场景优化；TSBS 公开基准测试中单节点写入性能表现突出。
• 接口兼容：支持标准 SQL，同时兼容 PostgreSQL 有线协议，可以复用大量 PG 客户端工具。
• 许可证：开源版本 Apache 2.0，商用无强制开源风险。
• 优势：单机吞吐能力强；部署简单，依赖少；SQL 友好，上手快。
• 短板：官方原生集群高可用方案成熟度相对有限；国内社区规模、落地案例偏少；大规模分布式场景可供参考实践案例不多。
• 制造业适配场景：边缘工控机单机采集、中小型产线本地实时数据存储；不需要跨节点集群的边缘站点。

VictoriaMetrics —— Prometheus 高效替代

可以理解为 Prometheus 生态的高性能替代存储。

• 核心定位：完全兼容 Prometheus API 与 PromQL，旨在解决原生 Prometheus 压缩差、难以水平扩容、长期存储成本高的痛点。支持单节点、集群模式。
• 存储特性：高压缩算法，相同指标数据存储空间相比原生 Prometheus 大幅下降。
• 许可证：Apache 2.0。
• 优势：无缝迁移 Prometheus 现有采集规则与 Grafana 面板；扩容灵活；长期指标存储成本更低。
• 短板：生态完全围绕云原生监控指标构建，缺少面向工业 IoT 设备采集的配套组件；不擅长处理带复杂文本属性、大量不同设备异构采集报文场景。
• 制造业适配场景：工厂 IT 运维监控集群扩容；原有 Prometheus 体系需要延长数据保存周期；不适用于产线设备原始采集。

Apache IoTDB —— 工业物联网原生 TSDB

清华大学发起孵化、Apache 顶级开源项目，面向工业物联网原生设计。

• 数据模型：树形层级路径模型 工厂.产线.设备.指标，天然匹配工业资产层级管理架构。
• 核心能力：支持海量测点管理、时序聚合、降采样、数据 TTL；适配边缘 - 云端协同架构，支持边缘端轻量化部署。
• 许可证：Apache 2.0，开源协议友好。
• 现状客观描述：核心时序存储能力成熟；对外标准化生态偏弱，早期版本对外以私有交互接口为主，标准化 REST、通用生态工具相比 InfluxDB 偏少；部分第三方 JDBC 连接器社区维护，选型前需要验证版本稳定性。
• 优势：开源友好、国产技术路线；数据模型高度契合工业层级资产管理；边缘部署版本资源占用低。
• 短板：采集层缺少一体化官方采集组件，Modbus、OPC UA、MQTT 对接需要自行开发或者依赖第三方网关转发。
• 制造业适配场景：集团多级工业物联网平台、有层级资产管理诉求、具备自主开发采集程序能力的团队。

ClickHouse —— OLAP 分析型列式数据库

重要界定：ClickHouse 不属于专用时序数据库，是面向 OLAP 场景的列式分析引擎，但是工业领域被广泛用来做时序数据离线统计分析，因此纳入对比，方便大家厘清边界。

• 技术特点：极致的批量查询、多维聚合性能；极高的数据压缩比；支持自定义分区策略。
• 工作模式：更适合批量导入数据后进行大规模统计分析。
• 优势：多维报表、能耗汇总、长周期批量数据分析能力极强；社区庞大，人才储备充足。
• 短板：持续高频、小批量实时点写入不是最优场景；缺少时序数据库原生的连续聚合、自动降采样、时序专用函数；缺少告警、流处理一体化配套。一般不建议单独作为实时采集主存储。
• 制造业适配场景：作为第二层分析存储；接收 TSDB 转发的时序数据，用于日 / 月 / 年度产能、能耗、OEE 离线统计分析；常采用「实时 TSDB ​+ ClickHouse 离线分析」分层架构。

二、制造业核心维度横向对比

三、制造业典型场景适配度评级

四、制造业选型决策框架

制造企业选型不能只看网上基准测试性能，必须结合工业现场真实约束，建议采用三步决策法逐层收敛：

第一步：评估采集规模、写入模型

先厘清基础业务指标：设备总数、单设备指标数量、上报频率、采用 Push 上报（设备 / 网关主动上报，工业主流）还是 Pull 拉取。

• 写入吞吐 5 万行 / 秒以内：绝大多数时序数据库单机均可承载；
• 持续稳定写入超过 50 万行 / 秒、上万台海量设备场景：重点考察 TDengine、InfluxDB 3.0、Apache IoTDB 这类面向 IoT 优化的产品；

重要提醒：所有公开基准测试均基于特定硬件、特定数据集，项目落地必须开展 POC，使用真实工厂报文压力测试验证。

第二步：评估采集链路与生态集成成本

工业场景最大隐性成本往往不是数据库本身，而是数据采集开发工作量。

• 如果希望直接对接 Modbus、OPC UA、MQTT 网关，尽量优先评估自带成熟采集组件的方案，减少二次开发；
• 如果团队具备较强开发能力，可以自主编写采集转发程序，则可以把重心放在许可证、国产化、集群能力上。

第三步：开源许可证合规、国产化政策评估

• Apache 2.0：商用风险最低，自由度高；
• AGPLv3：具备传染性，只要对外提供服务、嵌入系统，存在开源义务，务必法务评审；
• 有国产化政策要求：优先评估 TDengine、Apache IoTDB 等国内主导发展的开源项目；

通用决策原则

性能、生态、许可证、运维成熟度四者需要综合平衡，不要单一追逐纸面最高写入性能。很多项目后期故障，根源是忽略长期运维复杂度与生态工具缺失。

结语

八大时序相关存储引擎诞生背景、设计目标差异巨大，不存在一款可以覆盖全部制造业场景的 “万能方案”。

• 如果企业现有技术栈以 PostgreSQL 为主，同时需要时序数据和业务工单联合查询，优先评估 TimescaleDB；
• 项目存在国产化诉求、厂区设备规模庞大，可深入调研 TDengine、Apache IoTDB；
• 项目以 IT 服务器、容器监控为主，可选用 Prometheus、VictoriaMetrics；
• 希望最大限度降低工业网关、PLC 采集对接的开发成本，可以评估 InfluxDB；
• 若系统同时存在实时采集 + 长周期多维统计分析需求，推荐分层架构：采用专用时序数据库承载实时读写，搭配 ClickHouse 承担离线汇总报表。

任何选型结论都不能仅依靠文档对比，建议企业整理真实采集报文、预估峰值流量，搭建 POC 环境模拟现场压力，结合稳定性、运维难度、长期成本综合敲定最终方案。