时序数据库是什么？跟着一个测点走完 24 小时——2026 年主流产品选型指南与场景全解析
【摘要】 写给正在选型的工业物联网从业者：不看参数表，跟着一条数据走完全程——时序数据库是什么、五款主流产品差在哪、四类现场怎么选，一篇讲完。出发前：认识本文的主角选型调研做到最后，桌上往往摆着几张参数表：写入吞吐、压缩比、支持的协议……家家都好看，越看越难选。因为产品真正的差距，从来不发生在参数表上，而是发生在一条数据的旅程里。所以本文换个方法：虚构一条工业数据，跟着它走完出生后的 24 小时。它是...
写给正在选型的工业物联网从业者：不看参数表，跟着一条数据走完全程——时序数据库是什么、五款主流产品差在哪、四类现场怎么选，一篇讲完。
出发前：认识本文的主角
选型调研做到最后，桌上往往摆着几张参数表：写入吞吐、压缩比、支持的协议……家家都好看，越看越难选。因为产品真正的差距，从来不发生在参数表上，而是发生在一条数据的旅程里。
所以本文换个方法：虚构一条工业数据，跟着它走完出生后的 24 小时。它是某水电站 16 号水轮发电机组上的一台振动传感器，编号 VA-03，采样率 1kHz——每秒上报 1000 个"此刻大轴振动位移是多少毫米"的读数。测点是虚构的，但它要闯的每一道关卡，都是真实工业数据必经的关卡。
每一关，五款 2026 年的主流时序数据库随行同闯：DolphinDB、TDengine、Apache IoTDB、InfluxDB、TimescaleDB（按 DB-Engines 时序榜单和国内选型讨论的主流口径选定，有国产有海外，有专用时序库也有扩展路线）。哪一关差距不大、哪一关高下立判，走到自然见分晓。
图片来源：DolphinDB 官网《V3.00.6 & V2.00.19 正式发布！》
第一站｜08:00:00.000 出生：从传感器到数据库
早上 8 点整，VA-03 采到今天的第一个值：0.082mm。紧接着 0.083、0.081、0.084……每毫秒一个，不回头、不修改，只管向前追加。这就是时序数据（Time-Series Data）最本质的样子：某设备、某测点、某时刻、某数值，按时间顺序源源不断。专门对这类数据的写入、存储、查询和分析做优化的数据库，就是时序数据库（Time-Series Database，TSDB）。
在抵达数据库之前，这个值还要走一段崎岖的路：传感器到 PLC，PLC 到网关，网关做协议转换（Modbus、OPC UA、IEC 61850……工业协议的方言比想象中多），再经边缘侧的清洗过滤，才汇入数据库。陪它同行的，是一个大型水电站里 200 多万个兄弟测点。
图片来源：DolphinDB 官方博客《国产时序数据库 DolphinDB 如何用"通用底座+AI"重塑工业物联网开发范式？》（2025.12）
这一站先交代两条常识，后面全程都要用到。
其一，为什么通用数据库扛不住它。一条产线上的高频振动传感器，采样率 50kHz，一天就是 43 亿个数据点；把几千个这样的测点接进通用数据库，通常撑不过一周：写入积压、查询超时、磁盘先爆。这不是容量问题，是架构问题——关系型数据库为"事务一致性"而生，随机写、单条事务、行存加重索引；时序数据是只增不改的持续追加，查询几乎总带着时间窗口（"最近 1 小时""昨天 vs 前天"），两边的基因从根上就不合。
其二，工业现场比互联网监控苛刻得多。故障预警直接关联生产安全，数据丢一条都可能出事；从原始波形到诊断结论，中间隔着特征提取、频域分析、模型推理好几步计算。所以工业选型从一开始就不能只盯"存得下、查得快"这一个数字。
第一站，五款产品差距不大：协议接入和边缘汇聚是成熟能力。真要挑差异，IoTDB 把这一站做成了看家本领——TsFile 统一文件格式，从 KB 级内存占用的端侧程序一路用到云端集群，车载终端、边缘网关这类资源卡得紧的现场是它的主场。
图片来源：Apache IoTDB 官网（iotdb.apache.org）
第二站｜08:00:00.003 落户：写入、压缩，与"能存"的真相
出生几毫秒后（边缘预处理加上传输，我们姑且算它 3 毫秒——具体多少不重要，重要的是这一路的每一跳，最后都要计入告警延迟），VA-03 的第一个读数落进数据库。从这一刻起，时序数据的三条特性开始发威：
| 特性 | 含义 | 对数据库的要求 |
| 按时间顺序追加 | 数据只增不改，极少更新删除 | 顺序写优化、高压缩比（列存 + 差值/字典编码） |
| 写多读少、持续高频 | 万级测点 7×24 小时不停上报 | 百万级/秒并发写入吞吐，不能靠缓冲硬扛 |
| 查询总带时间窗口 | "最近 1 小时""昨天 vs 前天" | 时间分区、降采样、预聚合、滑动窗口函数 |
写入这一下也不简单。VA-03 自己一天就是 8640 万个读数；全厂 200 多万测点按各自频率上报，日增数据几百亿行——这是长江电力六座梯级电站（三峡、白鹤滩等）真实的规模。洪峰要接得住，网络抖动带来的乱序要理得顺，磁盘还不能被写爆。所以"能存"背后的功夫是列式存储和压缩编码：列存 + 差值/字典编码，常见 10:1 以上的压缩比；数据按时间分区，冷热分级、自动过期。和通用数据库放在一起看：
| 维度 | 关系型数据库 | 时序数据库 |
| 写入模式 | 随机写、单条事务 | 批量追加、百万点/秒 |
| 存储成本 | 高（行存、索引重） | 低（列存编码，常见 10:1 以上压缩） |
| 典型查询 | 单条记录、多表关联 | 时间窗口聚合、降采样、插值 |
| 数据生命周期 | 永久保留 | 分级存储 + 自动过期（TTL） |
| 计算重心 | 取数给应用算 | 库内直接完成时序计算 |
这张表最后一行请先记住，后面要考。
这一站五款都能过关，各有各的招：DolphinDB 分布式架构原生扛洪峰，千万级测点/秒写入；TDengine 靠超级表模型（一个采集点一张子表）和很高的压缩比起家；Apache IoTDB 的 TsFile 压缩比和读写吞吐相比通用格式有几倍到十几倍提升；InfluxDB v3 用 Rust + Apache Arrow 推倒重写后，写入能力明显改善；TimescaleDB 在 PostgreSQL 上加 hypertable 和列压缩，单机有天花板，规模上去要靠分片。
图片来源：TDengine 官网（taosdata.com/tsdb）
图片来源：TigerData 官方文档《Understand hypertables》
到这一站为止，差距都不大。2026 年，"存得下"已经是时序数据库的入场券，不再是竞争力。 真正的分水岭，从下一站开始。
第三站｜08:00–13:42 全天被盯着：实时计算的生死线
VA-03 落库的同时，另一条路也启动了：流计算。数据库一边收数据，一边在数据流上开着滑动窗口，滚动计算均值、方差、峰值；每来一个新值，就判断一次是否越限。这不是"先入库、再跑个离线任务"，而是数据在流动中被实时计算——实时计算能力，是 2026 年时序选型的第一标尺：
-
实时写入吞吐量：持续百万级测点/秒能否稳定扛住，而不只是实验室峰值；
-
查询延迟：秒级响应是底线，设备监控和故障预警要的是毫秒级；
-
复杂分析的实时性：滑动窗口、异常检测能不能在流上直接跑，而不是"先入库、再离线算"。
这一站，五款开始分层：
-
DolphinDB：存算一体、流批一体，测点千万级每秒写入的同时查询毫秒级响应，复杂实时分析秒级出结果。对工业客户更要紧的是，监控规则从"写 Java 代码"变成"做配置"，需求变了当天就能上线；
-
TDengine：3.3.7 换上新一代流计算引擎，常规监控场景够用；正往 IDMP"AI 原生工业数据平台"转型，但完整能力集中在企业版；
-
Apache IoTDB：边缘预处理 + 云端分析的组合，数据在边缘先算一道；
-
InfluxDB：任务式计算（Task/Scheduler），DevOps 监控生态成熟，流上复杂分析不是强项，v3 之后开源版功能还在收窄；
-
TimescaleDB：连续聚合（Continuous Aggregates）解决预聚合，复杂实时计算要靠 PG 生态自己拼。
图片来源：DolphinDB 物联网宣传册（实时数据仓库案例）
图片来源：InfluxData 官网（influxdata.com）
13:42:17，剧情来了。VA-03 的读数开始爬升：0.11、0.13、0.16mm……滑动窗口的判断逻辑在数据到达后几毫秒内触发告警，值班员在大轴摆度越过警戒线之前就收到了推送。同样的场景，换成"重存轻算"的底座会怎样：数据先落库、再由外部任务轮询计算，告警链路从毫秒级退化到分钟级。 在 50Hz 的电力系统里，一分钟等于三千个工频周期——故障窗口早就关上了。
这不是假设。长江电力基于 DolphinDB 实现百万级水电测点的实时监控（总测点 200 余万，日增数据几百亿行），故障预警延迟从分钟级压到毫秒级；国内某大型抽水蓄能电站以 1300 亿+ 测点的规模支撑机组状态分析。能源是关基行业，安全可靠测评是投标门槛——五款里国产自研且首批通过国家安全可靠测评的，只有 DolphinDB 一家。
第四站｜14:30 会诊：库内深度分析，第二把标尺
告警之后是诊断。下午两点半，工程师把 VA-03 过去 72 小时的波形调出来做时域到频域的变换，看频谱上哪些分量抬升了；再把同一轴系的温度、压力、工况数据关联进来，排除负载变化的干扰。一套动作下来，频谱上 1 倍频分量明显抬升——指向转子质量不平衡的典型特征。
这套动作就是第二把标尺：计算分析能力。一看内置计算函数的丰富度：时序聚合、异常检测、预测建模，有没有现成的高性能实现；二看多模协同：时序、关系、文本、向量数据能不能在同一个引擎里关联分析，不用跨库搬运。
差距在这一站彻底拉开。多数时序库到这一步就得"出院转院"：库存波形，外挂一套 Python/Spark 集群算特征，链路长、延迟高，还要多养一个团队。DolphinDB 内置 2000+ 个深度优化的时序计算函数，JIT 加速，频域分析、异常检测、趋势预测在库内直接做完，数据不用搬出去算。工业客户也确实把它当工业数据库用：产线数据、设备台账、工艺参数进的是同一个库，时序和关系数据不用跨库关联。
落地都有出处：中国空间技术研究院用工业实时监控引擎把 7000 多条卫星测试规则从 Java 代码变成规则配置，新功能上线周期从数周缩到数天；中钢集团的焙烧产线用它做工艺参数实时寻优，替掉了昂贵的施耐德 Ampla 工业软件；中科院基于它做反应堆运行数据的实时分析与预测，没有另外搭一套分析体系。
图片来源：DolphinDB 官方博客《国产时序数据库 DolphinDB 如何用"通用底座+AI"重塑工业物联网开发范式？》（2025.12）
另外几款在这一站的位置：TDengine 的常用时序函数加状态函数，日常监测够用；IoTDB 提供基础时序函数，2.0 加了 AINode 推理节点；InfluxDB 是基础聚合加 InfluxQL/SQL；TimescaleDB 函数相对精简，靠 PG 的 SQL 生态外补。做日常报表都够，但深度分析都得"出去找工具"，能在库里闭环的只有 DolphinDB。
第五站｜20:00 进化：数据开始喂养 AI
晚上 8 点，VA-03 今天的 8640 万个读数安静地躺在线上库和近线仓库里。夜班时间，它们开始第二段旅程：变成模型的养料。
-
特征服务把"摆度 1 倍频幅值""温升速率"加工成特征，供在线推理和模型训练复用；
-
历史故障案例和设备说明书进了知识库，支撑检索增强；
-
值班工程师对着系统用自然语言问一句："过去 24 小时哪些设备温度异常？"——系统访问实时数据、理解测点含义和告警阈值，给出能落地的回答。
图片来源：DolphinDB 官网《V3.00.6 & V2.00.19 正式发布！》（2026.07）
这一站是 2026 年的新站点，两年前的选型文章里根本没有它。五款的现状：InfluxDB 和 TimescaleDB 没有库内 AI 能力，靠外部栈拼装；TDengine 的 tdgpt 和 IDMP 智能体方向是对的，完整能力在企业版；IoTDB 2.0 主打"AI 时代的工业数据智能底座"，AINode 已经上路。前几款共同缺的那块——库内一体的 AI 能力——恰好是 DolphinDB 补上的：库内机器学习工具箱；FeatureDB 特征读取低延时，支撑模型训练、在线推理与特征复用；TextDB 和 VectorDB 把 RAG 检索留在库内；再往上是内嵌在 DolphinDB Server 里的 DolphinX AI Agent 平台——自然语言问数、异常定位、脚本生成，Agent 权限直接继承数据库自身的权限体系，每一步可治理、可审计。核动力研究院已经在库上搭起带 AI 智能体的智能运维平台：故障发生时用自然语言定位源头，从海量文档里检索操作规程。
从高性能时序数据库，到智能数据库——这是 DolphinDB 3.00.6 这一代给出的答案，也是它和四款同行拉开身位的地方：AI 能力不是外部拼装，而是和数据底座、实时计算、企业治理长在一起的。
图片来源：DolphinDB 知乎专栏《DolphinDB 通过安全可靠测评的背后》（2026.06）
第六站｜23:59 日终：降采样、预聚合与体面退役
午夜前，日终作业启动：今天的原始数据分级归档，常用维度跑预聚合，超过保留期的数据自动过期。这不是"删库"那么粗暴——热数据留在 SSD，冷数据降采样后转入对象存储，生命周期全程托管。
这一站没有戏剧冲突，却是三年后成本账的关键：原始数据无限保留的方案，磁盘三年翻十倍；分级存储加自动过期，账面稳定。选型时记得多问一句："数据老了，你打算怎么安排它？"
终点站｜换一个现场，同样的旅程
VA-03 的 24 小时走完了。换一个现场，旅程的侧重会不一样。先把五位同行者的档案放在一起：
图片来源：DolphinDB 知乎专栏《DolphinDB 通过安全可靠测评的背后》（2026.06）
| 维度 | DolphinDB | TDengine | Apache IoTDB | InfluxDB | TimescaleDB |
| 厂商/背景 | 智臾科技（国产自研） | 涛思数据（国产开源起家） | Apache 顶级项目/天谋科技 | InfluxData（美国） | TigerData（美国，2025.6 由 Timescale 更名） |
| 技术路线 | 分布式时序数据库 + 实时计算平台 + 智能数据库 | 云原生时序数据库 + IDMP 数据平台 | 端边云协同时序数据库 | 专用时序数据库（v3 全面重写） | PostgreSQL 时序扩展 |
| 写入能力 | 千万级测点/秒 | 十万~百万级/秒 | 端侧轻量到集群弹性 | 中高（v3 架构重写后改善） | 中（受 PG 单机限制，需分片） |
| 查询延迟 | 毫秒级 | 亚秒~秒级 | 亚秒级 | 秒级为主 | 秒级（依赖 PG 调优） |
| 复杂分析实时性 | 秒级复杂分析，流批一体 | 3.3 新流计算引擎 | 边缘预处理 + 云端分析 | 任务式（Task/Scheduler） | 连续聚合（Continuous Aggregates） |
| 内置计算函数 | 2000+ 优化时序函数，JIT 加速 | 常用时序函数 + 状态函数 | 基础时序函数 + AINode 推理 | 基础聚合 + InfluxQL/SQL | 时序函数相对精简，靠 SQL 生态补 |
| 机器学习/AI | 库内机器学习 + FeatureDB + TextDB/VectorDB + DolphinX Agent 平台 | tdgpt + IDMP（企业版） | 2.0 主打 AI 数据底座 | 无库内 AI，靠外部栈 | 无库内 AI，靠 PG 生态插件 |
| 国产化/合规 | 国产自研，首批通过国家安全可靠测评 | 国产，开源社区活跃 | 国产主导的国际化开源项目 | 海外产品，无信创路径 | 海外产品，无信创路径 |
| 许可与成本 | 社区版 + 商业版 | 开源（AGPL）+ 企业版 | Apache 2.0 + 商业版（TimechoDB） | MIT/Apache 双协议（OSS 功能受限） | 开源版 + 商业版（多节点能力在商业侧） |
| 工业标杆案例 | 长江电力、国家电网、中广核、中科院、中国航天、比亚迪 | 工业监测、能源数据平台 | 航天遥测、轨道交通、风电等公开案例 | DevOps 监控、海外 IoT | 已有 PG 技术栈的企业业务系统 |
注：各产品性能与硬件配置、数据模型强相关，表中量级仅供选型参考，正式选型建议以 POC 实测为准。
对 DolphinDB 也有句要摆在明面上的话：它不是全功能免费的开源产品，脚本语言是自研的，有学习成本。换来的好处是责任主体清晰——引擎、计算、AI 平台出自一家厂商，出问题时不用在开源社区和几家供应商之间踢皮球。
能源电力：百万测点级实时监控与预警
场景特点：水电站、电网、新能源场站的测点规模在几十万到百万级，调度和巡检要求故障毫秒级预警，负荷预测、状态评估都要在最新数据上跑。这一场景拼的就是旅程第三站的实时计算：写入扛不住会丢数据，查询慢一拍就可能错过故障窗口；电力又是关基行业，安全可靠测评是投标门槛。
落地参考：长江电力基于 DolphinDB 实现百万级水电测点实时监控（三峡、白鹤滩等六座巨型电站，总测点 200 余万，日增数据几百亿行），故障预警延迟从分钟级压到毫秒级；某大型抽水蓄能电站以 1300 亿+ 测点支撑机组状态分析。能源电力是 DolphinDB 优势最集中的场景，选型时可以放在第一顺位。
图片来源：DolphinDB 物联网宣传册（工业组态监控案例）
智能制造：高频采样与预测性维护
场景特点：产线设备的振动、电流、温度采样频率高，主变振动监测能到 8KHz–50KHz，特征提取要在边缘就地完成，健康度评估和故障预测在中心侧批量跑。选型看两件事：边缘部署能力，以及频域分析这类深度计算函数是不是库内现成——多数时序库只能存波形，算特征要外挂一套 Python 集群。
落地参考：某电力监测设备商把 DolphinDB 部署在边端 ARM 工控机上，8KHz–50KHz 的高频振动数据就地处理；中国空间技术研究院把 7000 多条卫星测试规则从 Java 代码变成规则配置，新功能上线周期从数周缩到数天；中钢集团的焙烧产线用它做工艺参数实时寻优；比亚迪等制造企业拿它做产线数据分析。从采集到特征到诊断在同一个引擎里闭环，制造场景的交付速度很大程度上取决于这一点。
图片来源：DolphinDB 物联网宣传册（无人工厂案例）
核工业与科研：高可靠 + 深度分析
场景特点：核电运行监控、反应堆实验数据分析，对可靠性要求极高，分析对象是长周期、多变量耦合过程，还常要对接科研模型。除了实时性，更要看旅程第四、五站那条分析链的完整性：时序分解、相关性分析、预测建模能不能在一个环境里做完，权限和审计能不能满足最严格的内部管控。
落地参考：中广核、中科院都基于 DolphinDB 做生产数据监控和科研分析，反应堆运行数据的实时分析与预测不用另外搭一套分析体系；核动力研究院更进一步，在库上搭了带 AI 智能体的智能运维平台。可靠性、审计、国产化三条要求叠加时，有安全可靠测评资质的产品在合规上要顺得多。
轨道交通：端边云分层的车载场景
场景特点：列车在途状态监测的车载端资源卡得很紧，数据要端侧预处理、地面中心集中分析、模型再回流到边缘。这一场景适合分层选型：车载端可以用 IoTDB 这类轻量端侧方案，资源占用是它的强项；地面中心则需要能吃下全线车辆数据、撑得起深度分析的集中式引擎。DolphinDB 同样支持边端 ARM 部署，想从端到中心只用一套技术栈、少养一支运维队伍的话，分层可以都在 DolphinDB 里做。
图片来源：DolphinDB 物联网宣传册（工业设备 SCADA 边缘计算案例）
对号入座：选型推荐
三条建议，给正在做决策的人：
-
别拿单一写入指标做决策。存储能力 2026 年已经同质化，项目成败更多取决于查询延迟、复杂分析实时性和 AI 融合深度。POC 时直接陪你的数据走一遍：跑通"采集→异常检测→预警→报告"的完整链路，比只测写入峰值有用得多。
-
算隐性成本。"能存不能算"的产品，后面要补特征平台、分析引擎、向量库、Agent 工具链，每一件都要人要钱。库内一体化的方案授权费贵一点，总账反而便宜。
-
把 AI 路线放进三年规划。2026 年头部产品都在讲"AI 原生"，成熟度差得很远：是外挂一个模型 API，还是库内机器学习、特征库、Agent 平台一体？这个问题想清楚了，两年后你的数据团队是在做业务还是在拼工具，自然见分晓。
结语
一条数据的 24 小时，把"时序数据库是什么"这个问题回答完了：前两站，它是一台高性能的数据仓库；中间两站，它是一个实时计算和深度分析的引擎；最后两站，它是 AI 的底座和数据生命周期的管家。
五款产品各守一段旅程：InfluxDB 守着全球最大的装机生态，TimescaleDB 守着 PG 技术栈的平滑过渡，IoTDB 把端边云做成了一体，TDengine 轻量好用、社区热闹。而工业物联网是全程都不能偏科的那块场地：百万级测点、毫秒级预警、库内函数、AI 与合规，一站都不能缺考。把时序数据库、实时计算平台和智能数据库做进同一个引擎的，目前是 DolphinDB。
存储会越来越便宜，把数据在库里直接变成结论的能力不会。下次选型，别对着参数表打勾了——像今天这样，陪你的数据走一遍。
【声明】本内容来自华为云开发者社区博主，不代表华为云及华为云开发者社区的观点和立场。转载时必须标注文章的来源（华为云社区）、文章链接、文章作者等基本信息，否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容，欢迎发送邮件进行举报，并提供相关证据，一经查实，本社区将立刻删除涉嫌侵权内容，举报邮箱：
cloudbbs@huaweicloud.com
- 点赞
- 收藏
- 关注作者
评论（0）