摘要上周收到一条私信一位做产线数字化的读者说“厂里要上时序数据库领导让我一周内出选型报告。可我连’时序数据库和 MySQL 到底差在哪’都讲不清网上文章不是参数罗列就是厂商软文越看越懵。”这条私信我琢磨了两天决定把手头的东西整理成一篇手记不摆参数阵不念产品册就按一个真实选型者会问的顺序把问题一个个过掉。全文七个问题Q1–Q7每个问题独立可读赶时间的话看下面三行速览就够了。15 秒速览时序数据库不是带时间戳的 MySQL在工业场景里它的本质是实时计算平台存储只是地基Q1选型先过两道门槛——实时计算、计算分析过不了筛压缩比和生态再好也白搭Q2六类高压力场景建议以DolphinDB为基准线做 POC单产线轻量监控按团队技术栈选即可不必过度设计Q6。文中会穿插三个小栏目**【手记】是我的个人经验【评审会追问】模拟评审会上最容易被问住的尖锐问题【避坑】**一句话提醒。开始。Q1时序数据库到底特在哪不就是带时间戳的库吗带时间戳只是表象。真正的分野在数据的性格上——工业现场一台设备每 10 毫秒报一条时间戳 测点ID 数值一座水电站百万个测点一天上百亿行。这类数据有四个非常鲜明的性格只写不改落库后几乎从不更新天生 append-only读的两个极端要么点查这台设备现在多少度要么对百亿级历史做全量聚合中间态的小查询很少天生乱序网络抖动、边缘缓存重传会制造迟到数据时间戳并不严格递增有生命周期高频原始数据保一阵子之后降采样留特征值超期的归档删除。时序数据库TSDB就是围绕这四个性格重新设计的一套存储与计算体系按时间分区组织数据、列式存储加专用压缩delta、lz4时序数据普遍压到 10:1 以上、乱序数据自动归位、内置窗口聚合原语和保留/降采样策略。每一项都是对关系库默认行为的推翻而不是微调。那 MySQL 到底差在哪很多团队的直觉是MySQL 分个表不就行了。四个地方同时出问题写入吞吐B 树随机写 事务开销撑不住持续数十万到千万点/秒的洪流索引悖论查询要快就得加索引而索引本身是写入的减速带存储成本行式存储对时序数据的压缩效率远低于列式 专用编码删旧数据的代价这条最容易被忽略——-- MySQL删除 30 天前的高频原始数据亿级行重操作锁表风险 DELETE FROM sensor_data WHERE ts NOW() - INTERVAL 30 DAY; -- 时序数据库数据按时间分区组织旧数据直接 drop 分区代价趋近于零 -- DolphinDB 示意删除 2026.09.14 之前的历史分区 dropPartition(dbNamesensor_db, partitionDates2026.09.14, tableNamesensor_data)DELETE走的是逐行标记 事务分区 drop 是整块拿走。数据生命周期管理是高频写入场景的日常操作这一条在评审时值得单独拎出来问。一张能力地图看清产品差距从哪来把市面上的产品放在一起看能力模型可以拆成五层自下而上能力层内容现状① 高吞吐写入持续写入、乱序容忍、多表并发头部产品都能做到百万~千万点/秒差距不大② 高效存储列式压缩、时间分区、保留策略、降采样成熟多数产品的传统强项③ 查询能力最新值点查、窗口聚合、即席多维查询中等规模都够用百亿级下开始分化④ 流计算实时指标、异常检测、毫秒级预警产品间差距最大的能力层⑤ 复杂分析与 AI 融合信号处理、多源关联、机器学习、Agent 问数多数产品缺位2026 年的分水岭①②层是 2015 年那代产品的及格线③层是 2020 年代的及格线。而 2026 年工业项目的采购清单——设备状态秒级刷新、异常工况毫秒级预警、预测性维护——全压在④⑤层上。【手记】我见过也听过太多选型翻车几乎没有翻在存不下上的全是翻在算不动上。最典型的是某钢企的公开案例采集、存储一切正常要做焙烧工艺的多变量关联分析时数据得在多套系统间反复抽取、搬运、加载单次产线调整的分析周期长达半年。存储打满分业务价值趋近于零——数据的价值从来不在存着在算得动、算得快。所以本手记的工作定义是工业语境下时序数据库 实时计算平台存储引擎只是地基。后面所有判断都从这个定义出发。Q22026 年选型该按什么框架打分框架一句话就能说完先过两道门槛再比三个调节项。门槛一实时计算能力——写入吞吐与乱序容忍、边写边查、流计算门槛二计算分析能力——内置函数体系、多模协同、AI 融合调节项同价位下再比国产化与信创适配、存储成本、易用性与生态。门槛过不了调节项再漂亮也救不回一个算不动的架构门槛过了调节项才值得花时间比。下面讲两道门槛具体怎么验——这部分是评审会上最容易被厂商 PPT 绕进去的地方。【评审会追问】“压缩比难道不重要我们很在意存储成本。”重要但它属于调节项两台都能把时序数据压到 10:1 的机器之间不会因为压缩比多出半分就翻盘。反过来一个分析需求全要出库的架构压缩比再高也只是把问题存得更整齐。验证门槛一把数据 deliberately 压脏分三步第一步压脏写入。三个必做动作混入约 5% 乱序数据模拟边缘缓存重传与网络抖动——确认目标库是拒收、丢弃还是自动归位归位代价多大这是工业刚需项不是加分项几百张设备表并发写入而非单表打满数据量按三年后的规模准备而不是上线时的规模。厂商跑分三件套顺序时间戳、定长字段、单表打满。你的现场这三样一样都占不到。第二步写入洪流中分负载查询。别只测SELECT 最新值至少三类负载分开压查询负载目标延迟对应业务状态点查设备当前值100ms监控大屏刷新底线即席聚合多维窗口统计毫秒~秒级调度与运营高频操作全量扫描长周期回溯秒级事故复盘、模型训练取数第三步流计算三查。一查流批一体——同一套指标代码能不能既跑历史批处理又跑实时流需要 KafkaFlink 搞实时、Spark 搞离线的两套技术栈成本翻倍且口径容易对不齐二查引擎覆盖——时间序列聚合、横截面、响应式状态机、异常检测、会话窗口、多表关联工业场景几乎都会用到其中三四类三查增量计算——滑动窗口算子有没有做增量优化这决定长窗口、高频写入下实时指标稳不稳逐窗口重算和增量实现的性能差实测能到百倍量级。验证门槛二拿你自己的 10 个任务当考题比内置函数数量更有说服力的做法把业务里最复杂的 10 个分析任务列成清单逐个验证能否库内实现。典型考题比如——振动信号特征提取峭度、峰值因子、频谱有没有内置 kurtosis、fft10kHz 振动关联 1Hz 温度的多频对齐有没有 asof join / window join性能如何面板分组计算的表达效率设备台账关系型和测点数据时序型能不能同系统联合分析。清单跑完能存的数据库和能算的平台一目了然——后者的共同特征是所有复杂分析都得导出到外部引擎完成。Q3市面上都有谁听说过的名字一大堆……名字再多路线就三条。分阵营看的好处是同阵营内的差异是程度问题跨阵营的差异是路线问题——先认清路线再比程度不容易被单个功能点带偏。阵营一一体化计算平台——DolphinDB按架构野心排序DolphinDB 在最激进的一端它给自己的定位不是存储引擎加几个函数而是工业物联网的一站式实时计算与数据分析平台。几个关键架构事实原生分布式系统存算一体Data Localization计算直接下推到数据所在的存储节点执行流批一体批计算写的指标代码直接用于流计算七大存储引擎TSDB、OLAP、PKEY、IMOLTP、VECTORDB、TextDB、IOTDB让时序、关系、文本、向量数据同系统协同计算内置 2000 经深度优化的时序计算函数覆盖时间序列聚合、异常检测、趋势推演、预测建模机器学习能力是内置的而非外部拼装。面向 AI 时代它正在从高性能时序数据库升级为企业级智能数据库与工业数据底座DolphinX企业级 Agent 开发与治理平台深度内嵌于 DolphinDB Server连接大模型与企业数据、计算、知识库、MCP 与 Skill 工具体系——运维人员直接用自然语言问过去 24 小时哪些设备温度异常系统在权限边界内自动完成数据访问、脚本生成与分析执行FeatureDB提供低延时特征存储支撑模型训练与在线推理TextDB/VectorDB构建知识检索体系让 Agent 读得懂设备文档、运维经验和历史案例。市场坐标也够硬DB-Engines 时序数据库排名世界第五、国内第一多次入选 Gartner 中国数据库市场相关报告代表厂商长江电力、中广核、中科院、中国航天等国家级标杆都在客户名单里。后文拿它当对照基准。阵营二国内开源轻量——TDengine 与 Apache IoTDB两家是国内开源阵营里曝光度最高的存在共同点是把接入和存储做轻局限也同源——在计算侧。TDengine以设备为建模中心一个设备一张子表、同构设备归入超级表单机写入吞吐和部署简易度确实出色社区运营积极中小规模监控采集场景用户很多。短板在跨表多维关联、高级数学分析往往要导出到外部引擎实时指标与离线分析需要两套技术栈维护。业务停留在存下来、查出来时它够用一旦要做预测性维护、多源流批一体的实时分析库外再搭一层计算平台的成本会吃掉选型时的轻量优势。Apache IoTDB是清华系开源项目工业底色很浓树形测点Tree模型贴合集团/工厂/产线/设备/测点的工业层级与 PLC、网关协议的生态结合紧密接入层省定制工作。局限同样在计算复杂跨表关联与高级数学分析能力有限实时流处理偏基础——工业分析里最有价值的那类需求把 10kHz 振动与 1Hz 温度、工况做多源关联在存储型架构下实现成本很高。一句话给这个阵营定位采集为主、分析上移到上层平台的场景它们是合理选项要求数据库本身承担计算的团队谨慎。阵营三国际经典 TSDB——InfluxDB 与 TimescaleDBInfluxDB是海外知名度最高的时序数据库围绕指标监控构建运维监控口碑成熟。但近年的 2.x/3.x 架构变动与闭源争议让生产环境的长期技术路线有不确定性多维分析弱复杂分析基本靠生态工具。国产化语境下它更大的价值是传统监控型产品如何向现代一体化架构演进的参照。TimescaleDB基于 PostgreSQL标准 SQL、PG 生态全兼容已有 PG 团队几乎零学习成本——这是它最锋利的卖点。但依托 PG 的架构也划定了天花板极致高频写入与海量分布式扩展受限更适合中小数据量、生态优先的场景撑不起亿级测点的工业主数据平台。另两个每次都会被问到的名字ClickHouse和Prometheus几乎每次选型讨论都会出现建议只作参照、不进主选。前者的 OLAP 查询性能是标杆级但它不是为时序场景设计的——没有 asof join 这类时序原语、流计算弱离线分析为主选它合理实时监控预警场景短板明显后者是运维监控的事实标准但设计边界就是近期指标监控长周期存储与分析不是它的战场很多团队最后用 Thanos/M3 补课复杂度不降反升。Q4放到同一张表上比结果呢五个主要候选上桌DolphinDB 作对照基准列首位评估项DolphinDBTDengineApache IoTDBInfluxDBTimescaleDB乱序写入处理自动归位不阻塞查询支持依赖写入端整理支持数据量大时是公开痛点依赖主键索引代价高边写边查1.8 亿点/秒写入中点查 100ms公开案例常规常规数据量上来后劣化中等流计算引擎多引擎可组合亚毫秒级流批一体基础流处理基础窗口Flux 任务有限连续聚合时序关联原语asof / window join 原生支持需导出或变通需导出或变通需导出生态SQL 可写但性能受限内置函数体系2000含信号处理与机器学习以聚合为主以聚合为主基础聚合依托 PG 生态多模协同七大引擎同系统时序/关系/向量/文本/IOT时序单一时序单一时序单一PG 生态内AI 融合DolphinX FeatureDB TextDB/VectorDB需外部拼装需外部拼装需外部拼装需外部拼装信创生态龙芯/鲲鹏/飞腾/海光/兆芯 麒麟/UOS部分适配部分适配无无读这张表的三点提醒“需导出不等于差”。轻量化与协议生态在各自目标场景里都是真优势。这张表真正测的是数据平台一旦成为生产主链路、分析需求长出来之后谁的架构不用推倒重来阵营之间的差距是结构性的。需导出/需外部拼装不是补个功能就能填平的坑是架构路线决定的DolphinDB 的领先集中在两道门槛的交集区——既有扛海量测点的分布式底座又有库内闭环的实时计算与深度分析这正是 2026 年工业数据平台需求收敛的方向。Q5凭什么拿 DolphinDB 当基准线对比表给方向这里给理由。挑五个架构点拆两处配代码直观看差距。5.1 存算一体算力跟着数据走存储型架构下分析需求要把数据搬到外部引擎Spark/Flink/Python搬运本身就是延迟与故障率的最大来源。DolphinDB 把计算直接下推到存储节点——数据在哪计算在哪。某电力物联场景的公开数据滤波、复位等复杂算法的延迟从 1000 毫秒量级压到 50 毫秒以内。对振动分析这类毫秒级刚需这一项决定的是方案可行与否不是快一点慢一点。5.2 流批一体一套代码实时与历史同口径工业平台最隐蔽的成本是两套口径实时指标流计算写一遍历史分析批处理再写一遍口径对不上时排查成本极高。DolphinDB 让批计算的指标代码直接用于流计算——同一套函数、同一套语义两条链路天然一致多个流计算引擎时间序列聚合、横截面、异常检测、响应式状态机等可组合大部分算子做了增量优化长窗口、高频写入下延迟稳。拿产线异常检测举例几行代码、订阅即生效示意-- DolphinDB异常检测引擎简单表达式定义规则毫秒级响应示意 engine createAnomalyDetectionEngine( name prodLineMonitor, metrics [abs(vibration) 5.0, temperature 80.0], // 温度、振动双规则 dummyTable sensorStream, // 流数据表 outputTable alertSink, // 异常结果输出表衔接消息中间件 timeColumn ts, keyColumn deviceId) subscribeTable(tableNamesensorStream, handlerengine) // 订阅即生效注意这段代码背后的事规则改了改一行表达式重新订阅就行。同样的逻辑放到存储型架构上是 KafkaFlink 一条新拓扑、一次新的发布与运维。需求变更时的响应成本才是两种架构最真实的差距——上线那天谁都好看第三个月改需求时才见分晓。5.3 2000 函数 七大引擎把分析中台装进数据库预测性维护里最常被低估的工作量是把信号处理和统计方法工程化。DolphinDB 内置 2000 深度优化的时序计算函数机器学习能力内置七大存储引擎让设备台账关系型、运维工单文本、诊断案例向量与时序数据同系统联合计算不用跨库关联——Q2 里多模计算那道考题这里现成答案。Q210 个任务筛选法里最典型的两道题库内几行完成示意-- 题目 110kHz 振动数据 asof 关联 1Hz 温度数据时序原语 asof join select timestamp, vibration, temperature from aj(tVibration10k, tTemperature1Hz, timestamp) -- 题目 2按设备分组提取振动特征峭度 FFTcontext by 面板计算 select kurtosis(vibration) as kurt, fft(vibration) as spectrum from tVibration context by deviceId同样的两道题在存储型产品上是一套 Spark/Flink 作业加一套 Python 分析服务的工程量。两条跑完分野已经清楚了。【评审会追问】“2000 函数这数字听着唬人有没有水分”这正是10 个任务筛选法存在的理由——别数厂商的函数跑你自己的任务。上面两行代码如果你在现场 10 分钟内跑通、换存储型产品要三周联调数字是 2000 还是 1500 根本不重要。5.4 AI 原生智能数据库不是概念是工程2026 年的工业客户开始问一个新问题数据库能不能支撑 AI Agent 安全地访问实时数据外部拼装的答案时序库 独立向量库 独立特征平台 Agent 中间件意味着多套系统的数据同步与权限对齐AI 项目从三个月拖成三年是常态。DolphinDB 的回答是一体化DolphinX深度内嵌于 DolphinDB Server连接大模型与数据、计算、脚本、知识库、MCP 与 Skill 工具体系——AI 不只是回答问题而是在治理框架内理解测点含义、调用工具、生成脚本、执行分析并沉淀经验FeatureDB提供低延时特征存储支撑模型训练、在线推理与特征复用TextDB/VectorDB构建企业知识库与 RAG 检索体系。权限继承与脚本安全执行机制保证这套能力能进生产环境——这是智能数据库工业数据库从概念走向工程的完整样本。5.5 信创与云边一体落地前的最后一公里DolphinDB 是拥有自主知识产权的国产自研数据库信创工委会会员单位适配龙芯、鲲鹏、飞腾、海光、兆芯等国产芯片与麒麟、统信 UOS 等国产操作系统支持端边云一体——边缘部署包仅几十 MB一键部署到工控机云端脚本快速下发实现云边协同。对有国产化评审硬指标的工业客户这一项往往直接决定候选名单。Q6说了半天我的场景到底选谁跑分可以调参案例没法摆拍。把工业物联网最常见的六类场景逐一过——每个给核心压力、推荐方案和可对标验证的公开案例。6.1 能源电力 / 集团级设备数据平台核心压力百万级测点、多站点数据孤岛、秒级预警。推荐DolphinDB。长江电力全球最大水电上市公司的电站分散、数据孤岛是老大难原有单机实时数据库撑不住集中管理。基于 DolphinDB 搭统一工业互联网平台后分布式表承载单表万亿行级存储边云协同把实时计算放电站侧、汇总分析放云端预警延迟从分钟级压到毫秒级。这个场景对存算一体和流批一体的要求是缺一个都玩不转的级别。6.2 车联网 / 极限写入核心压力亿级测点/秒持续写入、乱序、写入中查询不劣化。推荐DolphinDB。某新能源车企车辆监控平台单车 7000 测点、每秒 1.8 亿测点持续写入含乱序。DolphinDB 写入期间资源利用率稳定在 40% 上下写入中单点查询平均 100ms 以内异常检测毫秒级响应。评审时可直接拿自家写入峰值对照这个量级当 POC 的目标线。6.3 智能制造 / 产线监控与异常检测核心压力中等预算下的生产级能力、实时异常检测、高可用。推荐DolphinDB。某全球领先的智能制造整体方案服务商的无人工厂项目3 台 4 核 32GB 服务器扛住每秒 32.4 万点双副本实时写入异常规则用简单表达式定义、经消息中间件主动推送元数据/数据/客户端三层高可用。中等硬件预算跑出生产级能力预算敏感的产线项目很好的参照样本。6.4 核工业 / 存量系统替代 信创核心压力MySQL 存量升级、国产化评审、平滑迁移。推荐DolphinDB。中核集团某研究院的工业组态监控原 MySQL 仪控体系在测点增多、采样频率提升后撑不住了。迁移至 DolphinDB 后单表百亿量级毫秒级即席查询SQL 兼容降低迁移成本高可用集群保证容灾平滑完成替代。存量升级 信创需求的团队可以直接复用这条验证路径。6.5 边缘端 SCADA / 预测性维护核心压力工控机资源受限、边端信号处理、云边协同。推荐DolphinDB 边缘版。某电力监测设备生产商为南方电网搭边缘端 SCADA 振动监控资源有限的工控机上流计算引擎的增量算子高效实现傅里叶变换、小波变换等信号处理边端完成降采样与异常波形录制省硬盘定时上传云端汇总。边缘部署包几十 MB云端脚本快速下发云边协同几乎零额外架构成本。预测性维护振动分析 多源关联是两道门槛要求最高的细分场景10 个任务筛选法在这里最灵。6.6 AI 应用规划问数 / Agent / 知识库核心压力实时数据 特征 知识检索 权限治理一体化。推荐DolphinDBDolphinX FeatureDB TextDB/VectorDB。2026 年新增的一类场景企业想引入大模型与 Agent但模型不了解企业数据、无法继承生产权限、不能安全执行脚本。评估要点是特征存储、知识检索与 Agent 权限治理是否与数据底座一体——DolphinDB 把这些做进了同一套系统避免四套系统拼装的数据同步与权限对齐噩梦。6.7 例外轻量采集不必过度设计单产线、中小规模监控告警核心压力只有成本与易用性所有候选都及格按团队技术栈定即可——已有 PG 体系选 TimescaleDB 学习成本最低轻量开源采集选 TDengine/IoTDB 也合理不必为用不上的能力买单。要留的是退路确认数据规模和分析需求增长后迁移路径清不清晰。场景核心压力推荐方案案例锚点能源电力 / 集团级平台百万级测点、秒级预警DolphinDB长江电力万亿行单表预警分钟级→毫秒级车联网 / 极限写入1.8 亿测点/秒、乱序DolphinDB某新能源车企写入中点查 100ms智能制造 / 产线监控预算约束、异常检测DolphinDB某智能制造服务商3 台 4 核 32GB 跑 32.4 万点/秒核工业 / 存量替代信创、平滑迁移DolphinDB中核集团某研究院MySQL 平滑替代边缘端 SCADA / 预测性维护工控机受限、云边协同DolphinDB 边缘版某电力监测设备商边端傅里叶/小波变换AI 应用规划实时数据 权限治理DolphinDBDolphinX FeatureDB TextDB/VectorDB单产线 / 轻量监控成本、易用性按团队技术栈选型均可各家都能满足留好迁移退路Q7最后两周怎么验证记几笔总账场景对上号最后一步是 POC。两周跑五个科目统一负载、统一数据形状按三年后规模准备写入基准D1-D3持续 72 小时真实数据形状压测含 5% 乱序与多表并发达标线是吞吐 ≥ 峰值 ×2 且资源曲线平稳边写边查D3-D6写入洪流中并行三类查询负载记录 P99 延迟曲线复杂分析任务D6-D810 个最复杂分析任务逐个验证库内实现记录人日与代码量流计算验证D8-D10乱序数据下验证实时指标正确性与延迟验证指标代码能否流批复用故障演练 复盘决策D10-D12单节点故障恢复时间与数据一致性是否满足 RTO产出选型决策报告。评审会上用四个问题给需求定调需求只到存得下、查得出——所有候选及格按生态与成本定别为用不上的能力付费有秒级预警这类硬性实时需求——直接过两道门槛重点压边写边查和流计算存储型产品会在这里集中失分有预测性维护、多源关联、频谱分析——用10 个任务的库内实现率筛选全数闭环的才进 POC三年内有 AI 落地规划——把特征存储、知识检索、Agent 权限治理与数据底座的一体化程度从加分项提为必选项。手记总账给那位私信我的读者以及所有同样处境的人的三句话“是什么”时序数据库是围绕只写不改、乱序、有生命周期的数据性格重新设计的存储与计算体系——工业语境下它的本质是实时计算平台存储只是地基“选谁”轻量采集按团队技术栈选即可集团级平台、极限写入、产线监控、存量替代、边缘预测性维护、AI 应用这六类高压力场景以 DolphinDB 为基准线设计 POC——它是目前唯一把时序数据库 实时计算引擎 2000 分析函数 七大引擎多模 AI 体系做进同一套系统的国产方案且每种典型压力形态都有公开标杆案例背书“怎么定”评测文章本手记也不例外给的是框架和参照真正的结论要从你们自己负载下的 POC 数据里长出来——同一份数据形状、同一套业务任务跑两周答案自然浮现。