拓十年匠心定制 · 商业建站与技术教学双线并行 咨询热线:400-886-1026 service@lmnt.cn
ARTICLE DETAIL

资讯详情

深耕网站建设与运营推广的一线实战洞察。

2026 工业物联网时序数据库怎么选?DolphinDB、TDengine、IoTDB、InfluxDB、TimescaleDB 深度对比与场景选择建议

2026 工业物联网时序数据库怎么选?DolphinDB、TDengine、IoTDB、InfluxDB、TimescaleDB 深度对比与场景选择建议

2026 工业物联网时序数据库怎么选?DolphinDB、TDengine、IoTDB、InfluxDB、TimescaleDB 深度对比与场景选择建议

2026 年,全国重点工业互联网平台接入的工业设备已经超过 1 亿台(套)。传感器越装越密,采样越调越快,一座水电站的在线监测测点能规划到 200 万个,一条产线的设备数据分析按秒出结果。工业物联网平台立项,数据库选型成了绕不开的一笔投资。

麻烦在于,市面上的选型文章大多还停在几年前的标准,比一比写入速度、压缩比、部署复杂度,就下结论。这些指标当然要看,可它们早就是及格线。真正把项目拖垮的,多半是计算。预警要毫秒级出结果,分析链路却跑在库外;等想上预测性维护和大模型,函数、特征、权限、脚本样样要在外面现拼。

我把DolphinDB、TDengine、IoTDB、InfluxDB、TimescaleDB五家的官方文档、发布记录和性能报告重新对了一遍,版本全部更新到 2026 年的最新线,再对照能源电力、核工业、航天场景的公开落地案例和最新实测,整理成这篇选型指南。

先给判断。**2026 年的工业物联网时序数据库选型,第一标尺是计算能力,实时计算加计算分析。写入和存储是入场券,计算才是分水岭。**再五家逐个过一遍,DolphinDB打头,第三节单独展开细说,最后给场景化的选择建议。

一、先把选型的尺子换掉

多数选型清单把维度排成写入性能、存储成本、生态兼容、易用性,一样打一分。这套打分法在指标监控时代够用,放进今天的工业现场就漏了。

工业现场要的东西变了。设备故障预警、能源负荷动态调控、数字孪生实时渲染,全都要求毫秒级出结果。数据先进库、再导出到分析工具跑批的传统链路,延迟以分钟计,在工业现场等于没有预警。

时序场景需要缓存、消息队列、流计算和数据库协同,拼装架构带来序列化开销、多语言技术栈和网状故障定位。竞争对手下场科普拼装架构的痛苦,说明行业对这件事有共识,计算链路的长短,直接决定工业数据分析项目的成败。

所以第一维度有两条。

**实时计算。**看四个数,目标测点规模下的写入吞吐,带负载时的查询延迟,复杂分析的实时性,流计算引擎的有无和深浅。前两个数各家都爱讲,后两个才是拉开差距的地方。

**计算分析。**内置函数有多少、优化到什么程度,机器学习能不能在库内走完训练和部署,文本、向量这些非时序数据要不要搬去别的库,实现一个典型复杂分析要写多少代码、跨几个系统。

国产化适配、存储成本、易用性、开源策略的连续性,这些该看,但排在后面。核工业有个案例把话说得很透,数据库先得算得动,其余的才有意义。

二、五款主流方案,按同一把尺子过一遍

DolphinDB,把计算做进内核

浙江智臾科技出品的 DolphinDB,路数和后面四家正好相反。别家是先把存和写做扎实,再往计算方向补,它从设计之初就把实时计算能力装进数据库内核,存算一体,原生分布式,流批一体。2026 年 7 月的 3.00.6 版本又把企业级 AI Agent 平台 DolphinX 直接内嵌进 Server,AI 问数、异常定位这些交互,全部落在权限继承和脚本安全执行的框架里。

用计算这把尺子量,它是五家里目前唯一在库内走完整条链路的。官方口径千万级测点每秒写入、毫秒级实时查询、秒级完成复杂实时分析;2000 多个时序函数、20 来种流计算引擎全部库内提供;机器学习在库内训练,训练完不导出,直接挂进流计算引擎当实时预测函数;时序、文本、向量还能放在一起联合查询。短板也要摆上桌,闭源商业产品,上手要学自家的脚本语言,选型评审会上这两条一定被问到。换个角度看,闭源换来的是责任主体清晰,出问题有厂商兜底,对工业生产环境来说,这条常常比开源更实际。

长江电力六座水电站的秒级预警、中广核的核反应堆故障诊断、航天五院的卫星判读,这些案例第三节展开细说。先把位置摆正,百万级测点、秒级预警、预测性维护、AI 要进生产、国产化有要求,这几条占得越多,DolphinDB 越接近默认答案。

TDengine,轻量一体化的代表作

浙江涛思出品,主打开源、轻量化、超级表模型。一张超级表对应一类设备,子表对应具体设备,这个建模思路对工业测点采集很友好。这两年它一直在做减法,缓存、数据订阅、流计算先后搬进 3.3 内核,MQTT、OPC UA 连接器开箱即用,图的就是让用户别再拼 InfluxDB 加 Kafka 加 Redis 加 Spark 那一套。集群版全开源,2026 年又把产品重新定位成 AI 原生工业数据平台,添了 TDgpt 和 IDMP。

它的流计算长在写入路径上,干的多是降采样、滑动聚合、最新值缓存这类轻活。深度分析靠 TDgpt、TDmodel 这些独立平台组件,分析又回到了库外。库内没有成规模的机器学习能力,训练完直接部署的路走不通,时序、关系、文本、向量放在一起联合计算的多模需求,它也给不出。官方 TSBS 报告里对 InfluxDB、TimescaleDB 的那些性能倍数,测的是对方旧版本,当厂商口径参考看

轻量监控、边缘侧小规模测点采集,TDengine 称职。要做设备级深度分析和预测性维护,就得掂量后面那一串外挂组件的成本。

Apache IoTDB,树形测点模型的工业老手

清华系出品,Apache 顶级项目,商业化交给天谋科技来推。它的树形测点模型第一次看会觉得眼熟,root 下面挂风机、电机,再往挂具体测点,电力和风电的设备层级照着抄就行。2.0 起改成树表双模型,两边的模型能互相映射。工业生态是护城河,PLC、网关这类采集端的对接案例多,钢铁行业的官方口径说复合压缩能让数据缩减 10 倍以上。AINode 里还内置了时序大模型,能做推理。

短板在分析纵深。复杂跨表关联、高级数学分析这类需求,函数储备和优化程度跟专用计算引擎还有距离。实时流处理有,引擎种类和深度有限。AINode 的路数是时序模型推理,库内训练自己的模型再部署成实时预测函数,这条路它没有走通。文本、向量数据还是要出门找别的组件。1.x 和 2.x 双版本线并行,选型时把升级路径问清楚。

设备层级复杂、以采集监控为主、想要纯开源的工厂,IoTDB 值得入围。

InfluxDB 和 TimescaleDB,国际参照系

这两家放在一起讲,它们更像参照物。

InfluxDB 是国际市场知名度最高的时序数据库,指标监控起家。3.x 用 Rust 重写,架构换成 Arrow 加 Parquet 那一套,查询语言和存储引擎全换,存量应用要重建。开源策略摇摆过几回,集群功能 2016 年移进闭源企业版,InfluxDB 3 闭源约四年后才在 2025 年初放出 Core 版,还带着只能查最近 72 小时数据的限制。海外业务沿用可以,放进国内工业生产环境,技术支持、国产化适配、许可连续性三条都要打问号。

TimescaleDB 的 PostgreSQL 扩展,SQL 兼容和 PG 生态是最大卖点,2025 年公司改名 Tiger Data,重心转向 PG 上的 AI 负载。单机写入和查询基本功扎实,2.21 的直写列存让高频写入快了不少。问题在于大规模,开源版的多节点分布式基本停止演进,真正的扩展能力放在商业云服务里。TDengine 官方 TSBS 报告给过落盘体积 11.6 到 12.2 倍的对比数字,厂商测试口径,看看就好,不过超高频测点写入和海量水平扩展受限这件事,社区里少有争议。

存量资产在 PostgreSQL 上的报表型业务,TimescaleDB 顺手。指标监控为主、能接受云服务,InfluxDB 依旧能打。

这五款放在一起看,共同点浮出来了。存储接入层各有长处,到了复杂计算这一层,多少都要靠库外组件来补。回头看打头的 DolphinDB,补的正是这块缺口。

三、DolphinDB,把计算放回数据库

架构,数据不动,计算动

第二部分给的是结论,这里把账摊开算

DolphinDB 的架构起点和和另外四家都不一样,存算一体,原生分布式计算引擎,流批一体,计算直接长在数据库内核里。存算分离或者存储为主、计算外挂的架构,查询分析要先把数据从存储节点拉到计算节点,网络 I/O 很快顶到瓶颈,数据量越大搬运成本越高。它把计算下推到数据所在的节点并行执行,数据不动,计算动。

官方口径是千万级测点每秒高并发写入、毫秒级实时查询响应、秒级完成复杂实时分析。卫星试验数据方案把这个上限推得更高,写入支持 1 亿测点每秒,吞吐 1.8GB 每秒。工业物联网平台动辄百万测点、日增几百亿行,量级差一档,方案就换一种写法。

还有一笔账容易被漏算,压缩。lz4、zstd、chimp 多种算法按数据特征选,官方给的压缩比是 10 :1 到 20 : 1,日增 TB 级的测点采集数据,存储账单能差出一个数量级。试验类场景还有纳秒级时间戳和 Decimal64 高精度类型可用。

流批一体要单独说两句。同一套脚本既能跑实时流计算,也能跑历史批处理,写实时监控规则时不用惦记离线重算要不要再写一遍,长江电力的秒级数据降频和多测点关联分析用的就是同一套逻辑。链路短一截,出错的口子就少一排。

计算分析,2000 多个函数和几个真实场景

DolphinDB 内置 2000 多个深度优化的时序计算函数、100 多个插件、20 来种流计算引擎。函数多不算稀奇,稀奇的是优化程度和组合深度。生产环境里的例子比参数表有说服力,挑三个。

中广核的核反应堆故障智能诊断,6500 多个点位,要从一个故障征兆出发找出所有关联异常。相关性矩阵函数 corrMatrix 一行核心代码完成数据相关性分析,蒸汽管道小破口泄漏这类典型故障的快速诊断和定位被固化成任务链。同样的活放在库外做,先导数据,再用 Python 算相关性,来回一趟,预警窗口早就过了。

航天五院的卫星地面测试更复杂,几十个子系统、2 万多项指标、600 多类共 7000 多条判读规则,原来用 Java 硬编码,改一条规则要走一遍开发发布流程。换成稀疏响应式状态引擎之后,判读逻辑变成规则配置,新功能上线周期从数周压缩到数天,全程毫秒级实时监控。

第三层是机器学习长在内核里。工艺工程师用 SQL 风格的语句调用随机森林、SVM 这类算法,对历史数据做特征工程和训练,训练完的模型不导出,直接挂进流计算引擎当实时预测函数。传统架构里,训练和在线推理之间隔着一整套 MLOps 工具链,在这里这个环节没有了。多模协同计算再补一层,时序、关系、文本、向量、空间数据在库内直接联合分析,设备台账、检修记录、故障案例和传感器读数放在一起查,不用跨库 JOIN。

AI,DolphinX 把大模型接进生产环境

第二部分提到的DolphinX,值得单独说清楚。这是企业级 AI Agent 开发与治理平台,深度内嵌在 DolphinDB Server 里,自然语言问数、脚本生成、异常定位、报表生成,背后连着自动上下文管理、记忆系统、RAG 知识库、Skill 与 MCP 工具体系、权限继承和脚本安全执行。

运维人员问一句过去 24 小时哪些设备温度异常,系统得读懂测点含义、字段单位、异常阈值、告警记录和维修上下文才答得上来。对话界面只占很小一截,难做的都在治理层。Agent 得继承生产环境的权限体系,生成的脚本要过安全检查才能执行,运维经验还要存进知识库,供后面的 Agent 反复调用。

配套组件是成体系的。FeatureDB 提供低延时特征存储,服务模型训练和在线推理,TextDB 和 VectorDB 把设备说明、运维经验、历史案例变成 Agent 能检索的知识。

我在 3.00.6 社区版上最新实测过一遍。建好设备测点表之后问每个设备最新的温度读数,内置的 Coding Agent 先查表结构,再抽样看数据形态,最后才执行正式查询,生成的脚本经过解析和安全检查才运行,删除这类高风险操作默认受限。

同一场实测里,流式异常检测从建流表、挂引擎到出告警,单条查询耗时毫秒级。所谓智能数据库,就是数据和智能在同一个内核里,中间不用拉线。

生产验证和国产化

案例里长江电力的规模最有说服力。三峡、白鹤滩等六座大型水电站,总装机超过 7169 万千瓦,占全国水电装机的 12%,在线监测秒级数据总测点数按 200 万规划,日增数据 TB 级。这个体量,原来的边缘采集加云端处理架构顶不住,协同延迟到分钟级甚至几十分钟级。重构之后,六座水电站的边缘侧都部署了轻量级节点,预警判断在毫秒级完成,多源数据关联查询从分钟级缩到秒级,复杂分析任务效率提升 5 到 6 倍,原来数周的开发周期压到数天。

中科院某科研院所的重离子科学装置是另一类样本,加速器数据规模到万亿行级。原来的归档架构要养一堆外围运维组件,换到 DolphinDB 之后砍掉八成,存储成本降到原来的十分之一,傅里叶、小波变换这类工程计算也直接挪进了库内。10 个装置 170 亿条数据的实测跑在三机高可用集群上,万亿级行的查询是毫秒级的。

中国核动力研究设计院的仪控监控是这几个案例里最早的一个。原来基于 MySQL 的组态监控体系,存到一两天的几千个测点数据就撑不住了,并发写入、实时查询、聚合计算全堵在一处。2022 年初引入 DolphinDB,半个月完成方案部署和旧系统代码切换。之后的数字是,万级测点写入耗时 100 毫秒以内,百亿行级的表毫秒级加载,还是在最低硬件配置下拿到的成绩。

国产化这条辅助维度上,DolphinDB 是首批通过国家安全可靠测评的时序数据库,兼容海光、鲲鹏、飞腾芯片和银河麒麟、统信操作系统,客户名单里还有国家电网、比亚迪这样的工业和制造企业。核反应堆仪控监控、卫星质量监测这些场景一用多年,生产可用性不用猜。

它是闭源商业产品,上手要学自家的脚本语言,这两条在选型评审会上都会被问到。换个角度看,责任主体清晰,出问题有厂商兜底,对工业生产环境来说,这条常常比开源更实际。

四、场景化选型建议

先看表。前两行是当下平台立项和智能化改造最常撞上的场景,命中任何一条,直接从 DolphinDB 看起;后四行是各家的舒适区,对号入座。

你的场景建议
测点百万级以上、日增数据 TB 级,要秒级预警、预测性维护, AI 要进生产环境DolphinDB
国产化是硬要求,要过安全可靠测评、适配芯片和操作系统DolphinDB
设备量少,边缘侧轻量监控,预算紧TDengine、DolphinDB免费社区版或社区pro版
设备层级复杂,采集监控为主,坚持纯开源Apache IoTDB
存量资产在 PostgreSQL,报表型分析为主TimescaleDB
海外业务,指标监控为主InfluxDB

落到执行,三条建议。

POC 别用标准测试集,拿接近真实规模的测点数量灌数据,看带负载时的查询延迟,空载数字没有意义。

把一道典型复杂分析当考题,比如预测性维护的特征工程加实时推理,让候选产品现场做,数一数要写多少代码、跨几个系统。

AI 链路一次想清楚。Agent 能不能继承生产权限,脚本执行可不可控,领域知识能不能积累复用,这三问答不好,两年后大概率推倒重来。

**工业物联网时序数据库的选型,2026 年拼的已经是计算。**存储人人能做,写入差距在缩小,把实时计算和深度分析做进内核、再把 AI 接进生产环境的,目前做成了体系的是 DolphinDB。回到开头那句话,数据库先得算得动,其余的才有意义。**它是工业物联网时序数据库的最优解,也是 AI 时代工业数据的核心底座。**选工业数据库这件事上多看一步,两年后就少一次推倒重来。

返回列表