六个价值百万的深夜事故：时序数据库是什么 + 2026 年主流产品选型指南和场景全解析

[图片]
文中六起事故取自工业和互联网行业里反复出现的典型故障模式，人物、企业与数字做了匿名与合成处理，但每一类都在真实世界里不止一次地发生过。产品对照部分只陈述公开资料可查的能力事实。
[图片]
所以我们换一种写法。六个事故，每个事故对应时序数据库的一门课：数据模型、精度与生命周期、架构、运维、AI 喂养、实时计算。先看出事经过，再看根子在哪，最后拿同一把尺子量 2026 年主流的五款产品：DolphinDB、TDengine、Apache IoTDB、InfluxDB、TimescaleDB。六门课上完，选型清单自己会浮出来，不用背。
开工之前：三分钟说清"时序数据库是什么"
先把名词解决了，不然后面的事故看不懂。
时序数据是带时间戳、按时间顺序到达、以追加为主、几乎不更新的数据。水轮机每秒一千次的振动波形、电表每十五分钟一个读数、服务器每十秒一组的 CPU 指标，都是。它和普通业务数据（订单、用户、库存）的行为模式几乎是反着的：业务数据改得多、量平稳；时序数据只写不改、量持续增长，而且热点永远在"最近一段时间"。
通用关系数据库处理这种数据不是不行，是贵得没道理：为几乎不发生的更新维护索引，为只增不减的历史一路堆存储。按时间窗口做聚合，还得全表扫描。时序数据库就是为这类负载专门做过取舍的数据库：按时间分区、列式压缩、面向时间窗口的查询和计算、数据生命周期管理（到期自动降精度或删除）。2026 年又多了一条：把计算搬到数据旁边，而不是把数据搬给计算。行业给这类正在演化的产品起了两个新名字：工业数据库、智能数据库。名字背后的事，事故五会拆开讲。
再啰嗦一个名词：测点/时间线（series）。一台设备的某个传感器持续上报的某一个物理量，就是一条时间线。"3 号机组轴承温度"是一条时间线，"3 号机组轴承振动"是另一条。一个中型工厂有几十万条时间线不稀奇。记住这个词，事故三整个故事都围着它转。
[图片]

事故一：设备改了个名，两个月的历史"消失"了（数据模型课）
华东一家汽车零部件厂，2025 年秋天做车间并线改造，87 台设备从老车间划入新产线，MES 系统里设备编码统一换成新规则。改造顺利，产线照跑，数据照传。
两周后，工艺工程师做季度报表，发现这批设备的曲线"断了"：十月以后有数，十月以前全空。同比、环比、工艺追溯全部报错。更诡异的是，数据一条没丢：按老编码查，历史曲线都在。
问题出在时序库的身份模型上。
[图片]
根因：谁决定"这条数据属于谁"
大多数时序库用"标签组合"来标识一条时间线：设备编码、产线、车间这些属性拼在一起，构成这条时间线的身份。身份内嵌在标签里的模型，标签一变，等于凭空造出一条全新的时间线：旧数据还挂在旧标签下，新数据流向新标签，两边老死不相往来。看板按"现在的设备名"去查，自然只能查到改造之后的数据。
这家厂最后的修复方式是：写脚本回填 80 万条时间线的元数据，跑了两个周末，其间报表口径仍然是错的。为一次"改个名"，代价是两个周末，外加两周口径错误的报表。
五款产品，两类答案
这件事上，五款产品的数据模型取向可以分成两类。
身份外挂型，设备信息不掺和数据本身，单独放在元数据表里，查询时再关联：

• DolphinDB：时序数据按分区表组织，设备、测点属性走维度表，与数据本体解耦。设备改名只改维度表一行，历史查询自动带上新名，不需要回填。
• TimescaleDB：建立在 PostgreSQL 之上的关系模型，设备信息本来就是独立维表，改名是标准的关系操作，历史数据天然不受影响。
  身份内嵌型，标签或路径就是身份，改动有代价，但各家代价不同：
• TDengine：超级表/子表模型，一台设备一张子表，标签挂在子表上。标签支持修改，历史跟着子表走，改名代价相对小。
• InfluxDB：经典 tag 组合决定 series 身份，v1/v2 时代这是高基数问题的源头之一；2025 年 4 月 GA 的 v3 用 Rust + Arrow 完全重写，转向表/SQL 模型，正在向身份外挂的方向靠。
• Apache IoTDB：树形存储路径（root.车间.产线.设备.测点），路径即身份。层级调整意味着路径变更，历史数据需要迁移才能挂到新路径下。
  这一课的选型问题
  你的测点身份在系统生命周期里会不会变？设备会不会改名、换产线、重新编组？
  会变，就把"元数据与数据是否解耦"当成硬指标查证，让厂商当场演示改名；不会变，这类问题可以往后放。
  [图片]

事故二：被均值抹平的尖峰，和迟到两个月的告警（精度与生命周期课）
北方一家风电场，32 台机组，齿轮箱高速轴温度由 SCADA 系统按秒采集。存储策略是行业常见做法：原始秒级数据保留 7 天，之后只留 1 分钟均值，长期曲线全部由均值绘制。
入冬前的一次例行数据分析里，第三方诊断服务发现 11 号机组主轴轴承温度存在持续 3 到 4 秒、幅度 12°C 的尖峰，出现一次、隔几天再出现，频率在两个月里慢慢变密。这是轴承早期损伤的典型征兆。但这些尖峰全被 1 分钟均值稀释了：单秒 12°C 的尖峰，摊进 60 个采样点的平均值里，只剩 0.2°C 的涟漪，趋势看板上什么异常都看不出来。
两个月后轴承报废。更换费用加上停机损失发电量，账单 80 多万。复盘会上最难受的一句话是：原始数据 7 天就删了，想回头验证都没得验。
根因：降采样不是压缩，是信息销毁
降采样的本意是控制存储成本，但用"均值"做降采样，等于默认了数据在窗口内是平的。对温度这类缓变量大致成立，对振动、冲击、瞬态工况完全不成立。尖峰是最值信息，均值第一个把它抹掉。再叠加"原始数据短期删除"的生命周期策略，信息就永远地没了。
正确做法是两条。一是多精度存储：原始数据、秒级、分钟级、小时级并存，原始数据到期落冷存储，不删。二是降采样保留极值：每个窗口除了均值，同时落 max 和 min，尖峰信息在每一级精度里都活着。
五款产品怎么处理这件事

• DolphinDB：多精度存储是产品级能力，原始库、秒级、分钟级库由流引擎级联降采样，窗口聚合同时保留 min/max 等极值统计；冷热分层按时间分区自动流转。
• TimescaleDB：连续聚合（continuous aggregate）自动维护多级聚合视图，原始数据保留策略（retention policy）与聚合独立配置，可做到原始数据到期删除、聚合长存；但聚合里是否保留极值，需要建表时自己设计好。
• TDengine：降采样查询和流计算内置，可按窗口聚合落盘；配合其数据压缩能力，保留更长周期原始数据的成本相对可控。
• InfluxDB：v1/v2 时代的任务（task/CQ）体系成熟，降采样+保留策略是文档里的经典配置；v3 重写后这部分能力在开源版有所收窄，需要按版本确认。
• Apache IoTDB：触发器与数据压缩配合，可做多粒度落盘；其列式文件 TsFile 本身压缩率高，延长原始数据在线周期是它的强项之一。
  这一课的选型问题
  你的业务里，"异常"藏在均值里还是藏在极值里？你的原始数据打算保留多久，以什么形态保留？
  振动、冲击、瞬态类信号，把"降采样保留极值、原始数据落冷不删"写进验收标准。
  [图片]
  图3　组态监控画面：看板上"一切正常"的均值曲线，和被它抹掉的尖峰（图源：DolphinDB 物联网宣传册）

事故三：一次 OTA 灰度，把时间线数量引爆了（架构课）
一家新势力车企的车联网平台，车辆上报数据进某开源时序库，标签设计很"顺手"：车型、批次、固件版本、城市，全塞进标签里。跑了一年，一切正常。120 万条时间线，集群很轻松。
2025 年一次 OTA 升级开始灰度。固件版本标签每放出一个新版本就多一个取值，叠加车型与城市，时间线数量两周内从 120 万涨到 2600 万。先是写入延迟从 30 毫秒爬到 800 毫秒，然后内存水位报警、OOM、集群接连重启三次。数据量每天的增量并没有明显变化。压垮集群的不是数据，是时间线的数量。
根因：时序库的第一压力源是基数，不是数据量
每一条时间线，时序库都要为它维护身份：索引项、元数据、缓存。这个成本乘上时间线总数，就是"基数（cardinality）"。120 万条时间线的索引是可控的，2600 万条的索引可能就比数据本体还大。高基数因此被叫作时序库的第一场大考：很多库在小规模下表现完美，规模翻十倍就变成另一个产品。
这件事的架构课有两层。第一层是建模：标签该怎么设计（哪些进标签、哪些放元数据表、哪些根本不该按标签存），是选型之后的第一道坎。第二层是产品：当基数真的涨上来，数据库的索引结构和扩容能力接不接得住。
五款产品怎么过这场考试

• InfluxDB：v1/v2 时代高基数是公认痛点；v3 用 Rust + Arrow 重写后，官方口径对基数的支持能力大幅提升，这次重写很大程度上就是冲着这个问题去的。
• TimescaleDB：靠 hypertable 自动分块与 PostgreSQL 索引体系应对，单机容量有上限，适合基数规模可控、又想要 PostgreSQL 全套生态的场景。
• TDengine：一个设备一张子表、超级表统一挂标签的模型，把"设备数量"与"标签基数"解耦，是对高基数的原生防御。
• Apache IoTDB：用 schema 模板约束元数据结构，乱建的标签在建模阶段就被拦住，从源头控制基数。
• DolphinDB：分区表 + 分区列的水平扩展模型，时间线规模上去后靠扩节点摊薄索引与写入压力，工业现场几十万到百万级测点是它的常规工况。
  这一课的选型问题
  算一遍你的时间线总数：设备数 × 每台设备的测点数 × 标签取值组合。再问一句：三年后这个数字是多少？
  拿三年后的数字去问候选产品要实测，而不是拿今天的数字看各家演示。
  [图片]
  图4　边缘-中心分层架构：测点从边缘一路汇聚到中心，基数也随之累积（图源：DolphinDB 物联网宣传册）

事故四：一次大版本升级，停机了一夜（运维与责任课）
一家物流公司的监控平台用了某开源时序库的 2.x 版本。2025 年该产品发布新一代大版本：架构完全重写，存储引擎、查询语言、API 全换了。开源社区里的升级指南写着：没有平滑升级路径，需要迁移工具整体搬运数据，查询语法按新文档重写。
运维团队评估后硬着头皮上：迁移工具跑了一夜，300 多条监控面板查询重写了大半，周一早上例会没看板可用。更大的麻烦在后面：新大版本把原开源版的集群等核心能力收进了企业版，开源版功能收窄。继续用开源版，能力缩水；买企业版，预算没这项；换产品，一年前的选型推倒重来。
根因：免费的产品，账单在别处
这不是某一家的问题，是整个时序数据库市场 2025 到 2026 年的集体动作：Timescale 公司 2025 年 6 月更名为 TigerData，产品线向企业级数据平台演进；InfluxDB v3 完全重写并调整开源版边界；TDengine 的 IDMP 定位"AI 原生工业数据平台"但仅随企业版发布。行业从"开源跑马圈地"进入"商业化收网"阶段，开源版用户首当其冲感受到的是升级路径与功能边界的动荡。
事故四的课不在技术，在责任：升级的时候，出问题的时候，谁对你负责？
五款产品的"责任结构"

• DolphinDB：闭源商业产品。客观说这是短板：代码不开源，用自有脚本语言（DolphinDB 语言）而非标准 SQL，都意味着绑定。换来的另一面是责任主体清晰：升级、迁移、故障，厂商兜底，工单有归属。首批通过安全可靠测评，对国产化有硬要求的场景是一条现成的合规路径。
• TDengine / Apache IoTDB：开源核心 + 企业版双轨。开源版可自主掌控，重大故障与生产支持需要企业版或商业支持合同，责任边界取决于买不买服务。
• InfluxDB：开源版功能在 v3 后收窄，商业版（Cloud/Enterprise）能力完整，开源用户需要正视这条边界。
• TimescaleDB（TigerData）：开源扩展 + 云/企业服务，PostgreSQL 生态的通用运维能力可以复用，团队有 PostgreSQL 功底时责任最可控。
  这一课的选型问题
  画出你的责任矩阵：半夜集群挂了找谁？大版本升级谁做担保？三年后这家公司/这个社区还在不在？
  开源不等于免费，闭源不等于绑架。把"谁负责"和"多少钱"放在同一张表里算。
  [图片]

事故五：想训一个模型，数导了四天没导出来（AI 喂养课）
一家钢厂启动板材表面缺陷预测项目。数据团队的需求听上去很简单：从时序库里取 6 个月、1400 个测点、10Hz 的历史数据，给训练平台用。
第一步就卡死了。用 CSV 导出，跑了三天没跑完；换成查询接口分页拉取，拉到第四天内存溢出；好不容易拉出来的数据，时间戳精度被接口截断到秒，和缺陷记录标签对不上，全部返工。数据团队最后的解法是绕开数据库：让产线侧重新落了一份原始文件直接拷过来。数据库里存了三年的数据，在训练这件事上等于不存在。
根因：为仪表盘设计的读取接口，喂不饱训练管线
BI 查询取的是"最近一小时、聚合后的几千个点"；训练读取要的是"六个月、原始精度、上亿行、按列组织"。前者是细水长流，后者是开闸放水。用前者的接口做后者的活，就是这家钢厂的遭遇。2026 年这件事不再是数据团队的私事。每个工厂都在上 AI，预测性维护、质量预测、能耗优化，每个模型背后都是同一种批量读取需求。能不能把库里的历史数据顺畅地"喂"给训练管线（批量导出、Parquet/Arrow 列式格式、Python 生态直连、特征可复用管理），正在成为时序数据库的新硬指标。这也是"工业数据底座""智能数据库"这些 2026 年高频词的实际含义。
五款产品的 AI 接口现状

• DolphinDB：提供批量取数与 Python 生态接口，配套 FeatureDB 做特征入库与复用，训练、回测、在线推理共用一套特征口径；DolphinX 将数据平台与 AI 流程串成整体。这是它 3.00.6 之后的主打方向。
• Apache IoTDB：2.0（2025 年 7 月发布）明确以 AI 工业数据底座为定位，TsFile 列式文件可直接对接大数据与 AI 工具链。
• TDengine：IDMP 定位 AI 原生工业数据平台，面向工业数据的 AI 消费链路，随企业版提供。
• InfluxDB：v3 架构原生采用 Arrow/Parquet 数据格式，与列式分析工具链天然亲和，这是重写带来的真实红利。
• TimescaleDB（TigerData）：直接用 PostgreSQL 生态的 COPY、外部表、FDW 与 Python 生态打通，训练读取有成熟的 SQL 工具箱可用。
  这一课的选型问题
  你买时序库只是为了看板和历史查询，还是两年内就会用它喂 AI 模型？
  如果是后者，把"百万行级批量读取的实测耗时"和"特征管理能力"写进 POC 清单，现在就测。

事故六：算一个特征值，四个系统接力（实时计算课，2026 年的第一标尺）
压轴事故发生在一座水电站。八台机组，每台三千多个振动测点，1kHz 采样，保护逻辑要求特征值的计算延迟在秒级。
系统架构是标准的大数据栈：时序库负责存，Kafka 负责搬运，Flink 负责计算，Redis 负责暂存结果，看板再从 Redis 取。数据从测点到屏幕，六跳。平稳运行时端到端延迟五秒上下，勉强踩在达标线上。
某个凌晨 02:17，一批历史数据补录进库，Kafka 瞬间积压，Flink 反压，振动特征值延迟冲到 8 分钟。值班工程师在电话里问了一句：
“我们买的时序库，自己不会算吗？”
根因：计算在库外，每一跳都是风险
为什么要把计算搬到库外？因为传统定位里时序库"只会存和查"，一做复杂计算就力不从心，于是补 Kafka、补 Flink、补 Redis。但数据搬动的每一跳都是成本和故障点：格式转换、时序对齐、Exactly-Once 语义、反压、积压。事故六的 8 分钟延迟里，没有任何一环"坏了"，每一环都在正常工作，延迟是架构本身给的。
2026 年回看这条链路：工业场景里最有价值的计算（实时特征值、异常判据、控制指令依据）恰恰要求数据一落库就算完。实时计算与库内分析能力，是今年选型的第一标尺。存储压缩比、写入吞吐这些当年分高下的指标，五款主流产品如今都过关了，差距拉开的地方在"算"。
五款产品在第一标尺上的位置

• DolphinDB：流数据引擎内置在数据库中，数据写入的同时在引擎内完成实时计算与复杂分析（窗口聚合、因子计算、实时告警判定），无需外挂计算栈；流批一体的口径让"看板上的数"和"复盘用的数"天然一致。第一标尺上是五款中最完整的答案。
• TDengine：3.3.7 版本引入新的流计算引擎，库内窗口计算能力明显加强，向"计算靠近数据"的方向跟进。
• TimescaleDB（TigerData）：连续聚合加 Hyperfunctions 函数库，在 PostgreSQL 框架内做增量物化，适合分钟级以上的实时性要求。
• Apache IoTDB：提供库内流处理与触发器能力，配合 2.0 的数据底座定位，覆盖中低频实时场景。
• InfluxDB：v3 开源版的分析任务能力较 v1/v2 收窄，重计算场景仍依赖外部链路。
  六个事故，一条主线
  回头看，前面五个事故里各款留下的缺口：事故一的身份模型、事故二的极值丢失、事故三的基数天花板、事故四的责任真空、事故五的喂养断层，到事故六汇成同一句话：数据与计算分离，是六起事故共同的结构性根源。把计算搬进数据库引擎，正是 DolphinDB 补上的那块板。
  [图片]
  图7　写入、流计算、分析、告警在同一引擎内完成的实时数仓架构，与事故六的"六跳"形成对照（图源：DolphinDB 物联网宣传册）

六起事故之后：一份反着推出来的选型清单
把六门课收进一张清单，每条对应一起事故：

1. 测点身份会变吗？ 元数据与数据解耦的模型，改名不回填（事故一）。
2. 异常藏在极值里吗？ 降采样保留 min/max，原始数据落冷不删（事故二）。
3. 三年后时间线总数是多少？ 按这个数要实测，不按今天的数看演示（事故三）。
4. 半夜出事找谁？ 责任矩阵和成本放一张表里算（事故四）。
5. 两年内要用它喂 AI 吗？ 批量读取耗时和特征管理现在就测（事故五）。
6. 计算要不要在库内发生？ 实时性与链路复杂度，第一标尺（事故六）。
   五款产品档案总表（2026 年 10 月口径）
   暂时无法在飞书文档外展示此内容
   客观说，闭源和自有脚本语言是 DolphinDB 真实的绑定成本；换来的是升级、故障都有明确的责任主体。两面放在一起权衡，工业核心场景通常倾向后者。
   [图片]
   关于 DolphinDB 的展开：为什么它站在推荐位第一位
   对比表之后，把主推的这款单独展开说说。
   上面六门课里 DolphinDB 每一门都有交代：解耦的身份模型（事故一）、多精度存储与极值保留（事故二）、分区扩展扛基数（事故三）、厂商兜底的责任结构（事故四）、FeatureDB 的特征链路（事故五）、引擎内实时计算（事故六）。这不是巧合。它的产品哲学从第一天就是"数据库要能算"：存储、计算、分析在同一个引擎里完成。其余四款多数从"存储优先"起步，正在向计算能力演进，方向一致，完成度有别。
   落地案例是这个完成度的注脚：长江电力在巨型水电站用高频振动监测支撑机组状态评估与预测性维护；中广核在核电安全监测场景以实时计算与可靠存储保障核级数据要求；中科院在大科学装置的海量科研数据场景实现高频采集与库内分析；中国航天在航天测控任务中支撑高频数据处理。四个案例正好对应工业时序最苛刻的四类工况：高频、高可靠、大规模、强实时。

场景全解析：四类工况对号入座
场景一：能源电力，状态监测与预测性维护。 水电、风电、光伏的机组振动、温度、油液监测，典型特征是高频采样（百 Hz 到 kHz）、尖峰即故障前兆、告警要求秒级。对应事故二与事故六，第一标尺权重最高。首选 DolphinDB（长江电力案例），次选 TDengine。
场景二：流程工业与核电，安全监测与合规审计。 数据不可丢不可改、留存周期以年计、国产化与安全测评是硬门槛。对应事故一与事故四，身份模型稳定性和责任主体是关键。首选 DolphinDB（中广核案例、首批安全可靠测评），次选 Apache IoTDB。
场景三：车联网与离散制造，海量设备接入。 十万级设备、标签维度多变、写入洪峰明显。对应事故三，基数应对是生死线。首选 TDengine，次选 DolphinDB（既有海量接入又有后续分析需求时）。
场景四：科研试验与智能工厂，高频采集喂 AI。 风洞、大科学装置、产线质检模型，原始数据精度不能丢，训练读取要开闸放水。对应事故二与事故五。首选 DolphinDB（中科院案例、FeatureDB），次选 Apache IoTDB（2.0 数据底座）、InfluxDB（v3 的 Arrow/Parquet 亲和）。
[图片]
图9　无人工厂产线：数据、计算、智能在同一座工厂里闭环（图源：DolphinDB 物联网宣传册）

推荐表
暂时无法在飞书文档外展示此内容
结语：选型这门课，考场在凌晨
六个事故讲完，回头看没有一起是"产品不行"：身份模型、降采样策略、标签设计、升级窗口、导出接口、计算链路，单拿出来都是可以绕开的坑。真正的教训是，选型时没问出口的问题不会消失，它们会挑一个凌晨找上门。2026 年的时序数据库已经越过"存得下、查得动"的阶段，分出高下的是库内实时计算、AI 喂养、责任兜底这些新标尺。拿这份清单去问、去测、去验收。六起事故的学费，别人已经替你交了。