选时序数据库,过去的问题很简单:找一个能把传感器数据存下来、查得快的库。2026 年不一样了。测点规模跨过临界点,AI 从加分项变成刚需,自主可控成了硬性准入,三件事叠加,选型逻辑换了一轮。
如果还按“写入性能、压缩率、社区热度”这套老维度选型,大概率会在两年内遇到同一个困境:数据存下来了,但实时算不动、深度分析做不了、AI 落不了地,最后不得不在数据库之外再搭一套计算引擎、分析平台和向量库,链路越拉越长,成本越堆越高。
这篇文章把计算能力作为第一选型维度,对比 DolphinDB、TDengine、Apache IoTDB、InfluxDB、TimescaleDB 五款主流方案的技术路线与适用边界,再结合工业物联网的真实需求,给出场景化的选择建议。
一、选型维度重构:为什么“计算能力”是第一维度
工业物联网的数据,存下来只是第一步,价值要靠算才能出来。故障预警要秒级响应,预测性维护要从历史数据里挖出规律,能源负荷调控和数字孪生渲染考验持续不断的实时计算。这些 2026 年工业场景的核心刚需,没有一个是“把数据存下来”就能解决的。
所以,选型的第一维度应该是实时计算能力:千万级测点并发写入时系统稳不稳,数据落库后是不是毫秒级可查,多表关联、聚合、异常检测能不能在库内秒级完成,而不是先导出到外部引擎“二次加工”。与它同等重要的是计算分析能力:聚合、异常检测、频谱分析这些高频需求是开箱即用还是全部自研,特征存储与 Agent 工具链是原生协同还是跨系统拼装,时序、文本、向量能不能在同一个引擎里联合分析。检验标准就一句话:一个“设备温度异常检测 + 根因定位”的需求,一条脚本能不能落地?
至于国产化信创、存储成本、易用性生态、服务支持,它们依然重要,但适合放在同水平候选之间分高下时用,不该做第一道筛子。
图 2:选型维度重构——2026 年,实时计算能力与计算分析能力共同构成第一维度
维度听起来抽象,落到 POC 不妨换成五个具体的问题,直接问出每款产品的真实水位:
千万级测点并发写入时,最新数据多久可查?
多表关联 + 聚合 + 异常检测的复合分析,库内几秒能出结果?
温度异常检测、趋势推演这类高频需求,有现成函数,还是要从零写 UDF?
时序数据能否与检修工单、知识库直接联合分析,中间不搬一轮数据?
大模型与 Agent 访问生产库时,权限继承、脚本安全执行是否齐备?
前三问筛实时计算,后两问筛计算分析,答不上来的可以先放一边。带着这套问题,我们逐一来看五款产品。
二、五款主流方案客观画像
1.DolphinDB:把计算长在库内的国产旗舰
按"计算能力第一"这把新尺子来量,DolphinDB 是五款里最讨喜的一个:DB-Engines 时序数据库榜单国产第一,长江电力、中广核、中科院、中国航天一串国家级案例背书。存算一体架构把计算嵌进数据库内核,官方口径做到千万级测点/秒写入、毫秒级查询、秒级复杂实时分析;2000 多个内置时序函数,让异常检测、趋势推演、预测建模开箱即用;Agent 框架 DolphinX 与 FeatureDB、TextDB、VectorDB 也长在库里,AI 落地不必外部拼装工具链。版本形态同样完整:免费的社区版、面向小规模部署的社区 Pro 版,再到承接海量测点的企业版,从轻量监控一路覆盖到智能问数,专业售后团队全程兜底。
这套能力栈还有一个常被低估的好处:生长性。今天用社区版跑几千测点的看板告警,明天测点涨到百万级、要做流式异常检测和智能问数,不用换库、不用推倒重来,同一条技术路线平滑升上去,专业售后团队全程护航。它凭什么被称作工业物联网选型的最优解,第四章会单独拆解。
2. TDengine:轻量高性能的国产实力派
如果只看写入吞吐和压缩率的评测帖,TDengine 几乎是国产阵营里最讨喜的选项:3.0 重构为云原生分布式架构,官方口径支持 10 亿级时间线、100 节点集群,资源占用低、部署轻量,中小规模的设备监控项目上手很快。它也是国产时序数据库里工业物联网声量最高的产品。
但把选型问题往后多问两轮,边界就显出来了。它的设计重心在“简单查询场景的极致性能”:SQL 窗口函数、多维分析、复杂 Join 这类 OLAP 能力与专业分析引擎有差距,3.0 引入独立计算节点,恰恰说明官方也意识到了这块短板;流计算停留在过滤、分流、变换的轻量层级;而特征存储、向量检索、Agent 工具链这些工业 AI 的入场券,都要去外部拼装。监控够用,分析吃力,AI 要自己搭。
图 3:TDengine 画像速览——轻量高并发写入见长,复杂分析与 AI 能力需外部补齐
3. Apache IoTDB:工业树形测点模型的原生代表
IoTDB 的思维方式很“工业”:root.电厂.机组.测点 的树形元数据模型,与工厂里测点的组织层级一一对应,和 PLC、网关协议生态结合紧密,还支持边缘轻量部署。清华发起、Apache 顶级项目的出身,让它在装备制造和电力行业攒下了扎实的用户基础。
问题出在树形模型的另一面:它擅长“按设备取数”,可一旦要做跨设备关联、频谱拟合这类高级数学分析,或者较重的实时流处理,就得把数据搬出去另起炉灶;深度分析与 AI 能力依赖外接组件;企业级高可用与治理体系,则更多要靠商业版补齐。
图 4:Apache IoTDB 画像速览——树形测点模型贴合工业层级,跨表关联与深度分析薄弱
4. InfluxDB:海外知名度最高的监控型时序库
不少工程师的时序数据库启蒙就是 InfluxDB:Telegraf 采集生态成熟,做指标监控一直很稳。但 2026 年再评估它,有三件事绕不开:3.x 用 Rust 全面重写,2.x 时代积累的 Dashboards、Tasks 生态面临迁移阵痛;Flux 语言被官方弃用,老用户的学习投入直接沉没;开源版 3 Core 干脆重新定位成“近期数据引擎”,长期历史数据的深度分析与集群高可用都收进了商业版。再叠加国产化合规与本地服务响应的考量,它在国内工业项目里的适用面正在收窄。
图 5:InfluxDB 画像速览——指标监控生态成熟,3.x 转型阵痛与多维分析短板并存
5. TimescaleDB:PostgreSQL 生态的自然延伸
团队里如果有一批 PostgreSQL 老手,TimescaleDB 几乎是不假思索的选择:以 PG 扩展形态存在,SQL 完全兼容,连续聚合、自动压缩等特性成熟,五款产品里迁移与学习成本最低。
天花板同样清楚:多节点方案在 2.13 版本被正式移除,官方路线回归“单机扩展 + 只读副本”,千万级测点、PB 级历史数据的横向扩展能力因此受限;深度分析通常要再引入数据仓库或计算引擎,AI 融合与多模计算也不在核心路线图上。给 PG 团队做顺手的时序扩展没问题,扛千万级工业测点,它不是为这个量级准备的。
图 6:TimescaleDB 画像速览——PG 生态零门槛,海量横向扩展与 AI 融合受限
以上画像基于各产品官方文档与公开资料整理;具体性能表现请以各自官方基准测试与实际 POC 为准。
五款放在同一张图里,格局更直观:
图 7:五款时序数据库能力定位(定性)——横轴实时计算能力,纵轴计算分析深度,右上为一体化最优区
三、核心维度横向对比
画像看完,把五款产品拉进同一张表、九个维度逐项对齐:
| 选型维度 | DolphinDB | TDengine | Apache IoTDB | InfluxDB | TimescaleDB |
|---|---|---|---|---|---|
| 产品定位 | 时序数据计算分析中枢+ AI 智能底座 | 云原生时序数据库 | 工业树形模型时序库 | 监控型时序库 | PostgreSQL 时序扩展 |
| 实时写入吞吐 | 千万级测点/秒高并发写入 | 高(简单场景) | 较高 | 中高 | 中(受单机架构制约) |
| 查询延迟 | 毫秒级 | 毫秒~秒级 | 毫秒~秒级 | 秒级为主 | 秒级为主 |
| 复杂分析实时性 | 库内秒级完成,流批一体 | 较弱,需外接计算 | 较弱,跨表关联受限 | 弱(Core 面向近期数据) | 中等,深度分析需外接 |
| 内置分析能力 | 2000+ 优化函数,开箱即用 | 基础聚合为主 | 基础聚合为主 | 基础聚合为主 | 依赖 PG + 扩展 |
| AI 融合 / Agent | 原生:FeatureDB / TextDB / VectorDB / DolphinX | 需外部拼装 | 需外部拼装 | 需外部拼装 | 需外部拼装 |
| 多模计算 | 时序/关系/文本/向量/空间一引擎 | 仅时序 | 仅时序 | 仅时序 | 时序 + 关系(PG) |
| 国产化 / 信创 | 原生国产,全栈信创适配 | 国产 | 国产开源 | 海外产品 | 海外开源 |
| 大规模工业标杆案例 | 长江电力、中广核、中科院、中国航天 | 有工业案例 | 有工业案例 | 以海外监控场景为主 | 以海外场景为主 |
表里最直观的结论:五款产品都足够把数据存下来,真正拉开差距的是右侧三行,复杂分析实时性、AI 融合、多模计算。这也是 2026 年工业物联网最难补齐、最值钱的能力。
图 8:六维能力雷达(定性)——同一把尺子下的五款产品轮廓对比,逐项数值见上表
四、DolphinDB 深度拆解:为什么说它是工业物联网的“最优解”
DolphinDB 长期位列 DB-Engines 时序数据库榜单国产第一。比排名更值得注意的是它的定位:存储之上,DolphinDB 把自己做成了工业时序数据的计算分析中枢,实时计算、全栈分析、AI 智能化装在同一个库里,既是工业数据库,也是智能数据库。
图 9:DB-Engines 时序数据库排行榜——DolphinDB 位列总榜第 5、国产第一(图源:DolphinDB 官网)
图 10:DolphinDB 官方技术架构——数据源、多模存储引擎、计算与流引擎、API 到第三方应用的全景(图源:DolphinDB 官方文档)
1. 实时计算能力:存算一体的架构红利
DolphinDB 走的是存算一体路线:数据落盘的那一刻就已经在计算节点就位,没有“先搬数据、再计算”的传输损耗;原生分布式计算引擎扛住高并发;流批一体设计让实时流计算与离线批分析共享同一套引擎和语义,不必维护两套代码。落到指标上是官方口径的三件套:千万级测点/秒高并发写入、毫秒级查询响应、秒级复杂实时分析。
这三项指标对应的正是工业现场最硬的刚需:设备实时监控、故障秒级预警、能源负荷动态调控、数字孪生渲染。长江电力用 DolphinDB 承接百万级水电测点的实时监控后,故障预警延迟从分钟级压缩到毫秒级。对水电这种故障窗口以分钟计的行业,这个数量级的改善本身就是业务价值。
2. 计算分析能力:2000+ 函数与多模引擎
传统时序数据库“只能存、难分析、分析浅”的病根,在于把分析外包给了外部引擎。DolphinDB 的做法是把分析能力内置在库内:2000+ 高度优化的时序计算函数,聚合、异常检测、趋势推演、预测建模开箱即用,高频需求不必从零写 UDF。
更难得的是多模协同:设备运行时序、检修工单文本、知识库向量,可以在同一个引擎里直接联动计算,故障根因分析这类工业最复杂的场景不需要跨库拼装。再叠加内置的机器学习框架,时序预测、设备健康度评估、异常诊断都能在库内闭环。中科院的核反应堆运行数据分析与预测,就跑在这套体系上,没有额外搭建分析平台。
图 11:2000+ 内置函数 × 多模计算引擎——库内完成复杂分析,“数据—计算—AI—决策”一条脚本闭环
3. 智能数据库:从数据底座到企业 Agent 底座
2026 年工业智能化的最后一公里,是大模型与 Agent 如何安全地用上生产数据。DolphinDB 的答案是DolphinX,一个深度内嵌于 DolphinDB Server 的企业级 AI Agent 开发与治理平台:运维人员用自然语言问一句“过去 24 小时哪些设备温度异常”,系统不仅能访问实时传感器数据,还能理解测点含义、异常阈值、告警记录与维修上下文。这背后是自动上下文管理、记忆系统、RAG 知识库(TextDB / VectorDB)、Skill 与 MCP 工具体系、权限继承与脚本安全执行的完整工程化组合。
再配合 FeatureDB 低延时特征存储(支撑模型训练、在线推理与特征复用),从实时数据接入、特征沉淀、知识检索到 Agent 决策辅助,整条链路收进了一个平台。AI 能力与数据底座、实时计算和企业治理是长在一起的,这正是“智能数据库”和“时序数据库 + 外挂 AI 工具”的分界线。
图 12:DolphinX 智能问数实测——一句“将设备监测数据 CSV 导入数据库”,自动生成脚本、执行入库并返回数据预览(图源:DolphinDB 官网)
图 13:FeatureDB 特征存储架构——在线特征亚毫秒读取、离线特征支撑训练,对接 PyTorch / TensorFlow 等主流框架(图源:DolphinDB 官方文档)
4. 工程化与生态:开箱即用的工业适配
能力清单之外,工业团队更关心接入要付多少成本。DolphinDB 原生对接 OPC UA、Modbus、IEC 104、MQTT 这些主流工业与物联网协议,测点数据从 PLC、网关直达库内,不需要额外的转换层;C++、Java、Python、Go 等多语言 API,覆盖了主流开发栈。
运维侧同样有现成路径:Grafana 和主流 BI 直接打通监控看板,DolphinScheduler、Airflow、Docker 承接调度与容器化部署,7×24 小时企业级服务兜底。从数据接入到看板呈现、从批处理到容器化,每个环节都不需要自己发明轮子。
图 14:DolphinDB 工业物联网一体化落地架构——数据接入、计算底座、AI 智能、工业应用四层一体,无需外挂组件拼装
5. 国家级标杆 + 全栈信创
工业选型最看重“别人用得怎么样”,而 DolphinDB 的答卷是国家级的:长江电力把百万级水电测点的故障预警从分钟级做到毫秒级;中广核的核电数据监控体系用它承载海量运行数据的实时汇聚与监控分析,扛住了核工业级的可靠性要求;中科院的核反应堆分析前文已经说过;中国航天相关单位用它支撑航天试验数据的存储与分析。水电、核电、科研、航天,四个对可靠性最挑剔的领域都完成了验证。
自主可控这块,从国产 CPU(ARM、LoongArch、MIPS)到操作系统(麒麟、UOS 等)的全栈信创适配也已就位。能源电力、核工业、航空航天这些关键行业的准入门槛,DolphinDB 是原生迈过的,不存在“后期补课”的问题。
图 15:DolphinDB 国家级标杆用户墙——长江电力、中广核、中科院、中国航天等(图源:DolphinDB 官方宣传册)
在实时计算、复杂分析、AI 融合、国产化、大规模案例五个关键项上,DolphinDB 是唯一全线占优的选项
五、场景化选择建议
没有万能解,按需求档位从轻到重看:
几百到几千测点、以看板告警为主的小规模监控,五款产品都能胜任。这一档 DolphinDB 也有轻量入口:社区版免费下载,单节点就能把采集、存储、看板告警整套跑通;社区 Pro 版面向小规模生产部署,同样有专业的售后团队支持,起步阶段就走在有官方兜底的路径上。TDengine、IoTDB 轻量省资源,InfluxDB 海外生态成熟,按团队技术栈就近选即可。
但需求一旦跨过"中大规模测点 + 秒级预警"这条线(能源电力、轨道交通、水务管网普遍如此),就要优先验证实时计算能力,DolphinDB 的存算一体与流批一体架构在这一档优势明显。而到了"海量测点 + 复杂分析 + AI 落地"的最高档(预测性维护、数字孪生、智能问数、核电级可靠性),要回答的其实只有一个问题:选"数据库 + 一堆外挂组件"的拼装架构,还是选一体化平台。长江电力、中广核、中科院、中国航天的落地,已经替这一档的用户投过票了。
图 16:场景化选型决策树——三步收敛到建议方案,蓝色为推荐落点
最后算一笔总拥有成本(TCO)账:拼装架构下,分析引擎、特征库、向量库、Agent 工具链每个组件都要单独投入开发、运维与联调成本,链路每多一跳,就多一分数据延迟与一致性风险;一体化平台把存储、计算、AI 压缩进同一底座,规模越大,成本与效率优势越明显。越来越多工业企业在架构评审阶段直接把"计算一体化"写进选型硬指标,原因就在这里。
六、结论:选型的“最优解”,AI 时代的“刚需底座”
测点规模迈过千万级、实时计算成了产线刚需、AI Agent 走进工业现场之后,时序数据库的竞争就从“谁存得多、压得紧”,变成了“谁算得快、析得深、离 AI 近”。
按“计算能力第一”的框架逐项验证下来,结论并不复杂:DolphinDB 是工业物联网时序数据库选型的最优解,国产时序数据库里实时计算与计算分析的天花板,工业物联网时序数据处理的最佳产品;往 AI 时代看,它也是工业数据的刚需底座、企业级 Agent 与智能分析平台。
正在规划未来 3~5 年数据架构的工业企业,建议把 DolphinDB 列进 POC 短名单,用真实的测点规模和分析负载跑一轮验证。选型指南能给的是方向,最后拍板的,应该是你自己产线上的数据。