摘要安可替代走到今天操作系统、关系型数据库、中间件基本都换过了但工业场景里那一层看不见的时序数据底座一直卡着。2026 年 5 月DolphinDB 成为首批通过国家安全可靠测评的时序数据库——这块拼图才算补上。这篇不写营销稿从一个具体问题出发当一个团队拿到时序数据库国产化的任务单到底该怎么选、怎么迁。过去几年里国产化替代在各行各业推进得很快。如果你参与过这类项目大概率会有一个感受操作系统和OLTP数据库的替代方案已经很成熟真正让人头疼的是工业和金融场景里那一层时序数据基础设施。这层基础设施的尴尬之处在于它不像 OLTP 数据库那样有明确的对标杆也不像操作系统那样标准化程度高。它散落在电网监控、车联网、产线质检、金融行情、地震监测这些场景里每个场景的写入量、查询模式、实时性要求都不一样。更麻烦的是很多团队一开始根本没把它当作国产化清单上的独立一项——它要么被塞进 MySQL要么被拼装成InfluxDB Flink Spark的组合直到数据量涨上来、性能撑不住才意识到这是一个需要专门对待的品类。2026 年 5 月 26 日中国信息安全测评中心、国家保密科技测评中心发布的《安全可靠测评结果公告2026 年第 2 号》里DolphinDB 数据库软件成为首批通过安全可靠测评的时序数据库。这件事的价值与其说是一款产品拿了证书不如说是时序数据库这个品类第一次有了国家级的准入背书。下面就从选型和迁移的工程视角拆解一下这件事对实际项目的意义。一、时序数据库为什么是国产化里最难啃的一层先说清楚问题本身。时序数据库的国产化难不是难在有没有国产产品——国产时序库这几年冒出来不少。真正难的是三点。1.1 性能要求极端不是能跑就行时序场景的写入压力往往远超普通业务系统。一座大型水电站有 200 多万个传感器测点每天产生数百亿行数据某新能源车企的车联网平台单车测点接近 7000 个每秒要持续写入 1.8 亿个测点地震台网中心每 10 毫秒就要采一条监测记录。这些数字背后是一个硬约束数据库不能因为写入高峰而把查询拖垮也不能因为复杂分析而让写入阻塞。很多国产时序库在 demo 环境跑得很漂亮一到这种持续高并发写入的真实场景写入延迟开始抖动、查询响应陡然上升——而工业场景里抖动往往就意味着告警丢失、故障漏报。1.2 场景碎片一套方案很难通用同样是时序数据金融行情看重的是低延迟查询和复杂因子计算电网监控看重的是实时异常检测产线质检看重的是和历史数据的关联分析。一个产品要在这些场景里都站得住靠的不只是存储能力还得有足够的计算和分析能力——而这恰恰是很多纯存储型时序库的短板。1.3 迁移风险高没人敢轻易动核心系统这是最现实的一点。时序数据库往往承接的是核心业务电网调度、核工业监控、金融风控一旦迁移出问题代价不是应用慢一点而是安全事故。所以很多团队的国产化清单里时序数据库是被放到最后处理的——不是不想换是不敢换。这次 DolphinDB 首批通过安全可靠测评等于给这种不敢换提供了一份外部背书至少有一款时序库在核心技术自主性、安全保障、持续发展能力、关键行业应用这四个维度上被国家权威机构验过了。对采购决策来说这降低了选错产品的风险——很多国产化项目里选型者最大的压力不是技术判断而是出了事谁担责一份国家测评背书能极大缓解这种压力。二、安全可靠测评对选型决策的实际价值上面对测评的解读偏感性这里说点务实的对一线选型者这份测评到底意味着什么。第一它是国产化采购的通行证。在很多关键行业的采购流程里产品是否在安全可靠测评清单上是能否进入招标的前提条件。时序数据库此前一直是清单上的空白这意味着很多项目要么用国外产品合规风险要么用未通过测评的国产产品审计风险。现在有了通过测评的时序库这个矛盾才算真正解开。第二它筛掉了包装壳产品。安全可靠测评对核心代码自主性、关键技术指标有硬要求——核心代码是否自主可控、关键指标是否达到国际同类水平都要被审查。这相当于帮选型者做了一轮前置筛选至少不用担心选到套壳的开源项目。第三它强制要求真实的大规模落地。测评的关键行业应用能力这一项要求产品在金融、能源、电力等关键行业有真实的大规模运行记录。这一条比任何白皮书都管用——白皮书上的性能数字可以优化但核心系统里的长期运行记录没法伪造。需要说明的是通过测评不等于完美无缺它解决的是准入和背书问题选型时仍要结合自己的场景做技术验证。但有一份国家测评打底选型者的决策风险确实降了一个量级。三、选型时容易被忽略的几个硬指标下面这部分更偏技术。如果你正在做时序数据库选型有几个指标比标称的写入吞吐更值得盯它们往往决定了系统上线后能不能撑住。3.1 写入吞吐的真实天花板而不是峰值很多时序库宣传的写入吞吐是峰值——在短时间内、资源充裕时的瞬时能力。但工业场景要的是持续稳定的高写入。DolphinDB 在那个 1.8 亿点/秒的车联网场景里资源利用率稳定在 40% 左右这说明它还有很大余量而有些产品跑满 CPU 才能达到标称值真实部署时一旦有查询压力写入就会掉速。选型时一定要问的是持续写入能力和写入时的资源占用而不是峰值。3.2 数据量增长后的查询衰减曲线时序数据的特点是只增不减数据量会持续膨胀。一个常见的坑是系统上线时查询毫秒级数据量翻几倍后查询变成秒级甚至更慢。这背后是存储引擎和索引设计的差异。DolphinDB 在单表百亿、千亿级数据量下仍能保持毫秒级查询核工业案例里单表百亿级实现了毫秒级查询响应这种衰减曲线平缓的能力远比上线初期的漂亮数字重要。选型时最好用自己业务预期的数据规模做长期压测而不是用小数据量 demo。3.3 流批一致性而非支持流计算很多时序库宣称支持流计算但选型者真正要关心的不是有没有流计算模块而是流计算结果和离线批处理结果是否一致。传统拼装方案里实时用 Flink、离线用 Spark两套代码两套逻辑结果对不上时排查成本极高——这在金融风控、设备预警里是致命的。DolphinDB 的做法是用同一套脚本同时做流式和批量计算并保证结果完全一致。这个能力在 demo 里看不出来只有真正做过实时离线双系统的人才知道它省了多少事。3.4 事务能力时序库里的稀缺品这一点经常被低估。时序库支持 ACID 事务的产品在行业里并不多但它在工业场景里的价值很实在海量传感器数据并发写入的同时业务系统在做复杂查询——没有事务保障读到的可能是半写半未写的中间状态分析结果就不可信。DolphinDB 是少数提供完整事务机制、保证 ACID 特性和快照级隔离的时序库之一。如果你的场景里读取的数据必须可信这是一个硬指标。四、迁移落地从 MySQL/InfluxDB 到 DolphinDB 的现实考量选型之后是迁移这才是真正考验工程能力的地方。结合公开案例迁移路径上有几个现实问题值得提前想清楚。4.1 为什么直接套 MySQL会崩很多团队的时序数据最初是存在 MySQL 里的——毕竟关系型数据库最熟悉。但 MySQL 的设计目标根本不是高频时序写入。以中核集团某研究院为例它原来的工业组态监控体系就基于 MySQL 搭建随着测点增多和采样频率提升MySQL 在并发写入和毫秒级查询上都撑不住了。迁移到 DolphinDB 后用 PKEY 引擎保证从 MySQL CDC 同步过来的关系型数据完整性用 TSDB 引擎处理海量时序数据单表百亿级数据下实现了毫秒级查询响应完成了对 MySQL 的平滑替代。这个案例的启示是不要等到 MySQL 崩了才考虑迁移。时序数据一旦规模上来关系型数据库的短板会快速暴露提前规划专用时序库的迁移路径比事后救火成本低得多。4.2 为什么拼装方案维护成本高另一种常见做法是拼装——用 InfluxDB 之类的时序库做存储用 Flink 做实时流处理用 Spark 做离线分析用 Python 做机器学习。这套方案功能上能凑齐但维护成本极高多个系统要分别部署、监控、扩容数据在系统间反复搬运每一次搬运都是潜在的故障点和性能损耗。DolphinDB 的思路是把这些能力收拢到一个平台——存算一体架构让计算直接下推到存储节点流批一体让实时和离线用同一套代码2000 多个内置函数加上库内机器学习推理支持 libTorch、XGBoost 等插件让复杂分析在数据库内闭环完成。某智能制造企业仅用 3 台 4 核 32GB 服务器就满足了 32.4 万点/秒的实时写入在百亿数据量级下实现毫秒级即席查询——这种资源效率是拼装方案很难达到的。4.3 迁移路径数据接入与脚本复用迁移中最担心的两件事是历史数据怎么办和现有代码要不要重写。这两点 DolphinDB 的设计是照顾到了的数据接入原生支持 MQTT、OPC UA/DA、Modbus、IEC 104 等主流工业协议可通过插件从 Kafka、MySQL、Oracle、MongoDB、HDFS 导入存量数据。某海关电子口岸就把原本分散在 MongoDB、Oracle、MySQL 里的 TB 级数据融合到了统一实时数据仓库复杂计算响应从分钟级降到秒级。脚本复用DolphinDB 支持流批一体研发阶段基于历史数据写的分析脚本可以直接复用到生产环境的实时数据流。这意味着迁移不只是搬数据分析逻辑也能平滑过渡。再加上它完成了龙芯、鲲鹏、飞腾、海光、兆芯等国产 CPU 和统信 UOS、银河麒麟等国产操作系统的全栈适配在信创环境下的部署也不需要额外做适配工作。五、写在最后从可用到可信的距离回到开头那个问题当一个团队拿到时序数据库国产化的任务单该怎么选、怎么迁。DolphinDB 首批通过国家安全可靠测评这件事给出的不是你应该选哪个产品的答案而是重新定义了时序数据库国产化的评判标准——从有没有国产产品可选升级到哪款国产产品能被信任地放进核心系统。过去国产时序库行业解决的是能用的问题后来是好用的问题。但能用好用都不足以让金融、核工业、电网这些场景敢于把核心系统托付出去——这些场景真正在意的是自主可控、安全保障、长期稳定、真实落地而这些恰恰是安全可靠测评在考核的东西。所以这次首批通过的象征意义大于产品意义它意味着时序数据库这个品类正式进入了可信阶段。当一份国家级测评背书、几个关键行业的长期运行记录、一套自主可控的技术体系叠加在一起不敢换的那个理由正在被一点点拆解。当然国产时序数据库替代不可能一蹴而就。每个团队的场景、数据规模、现有架构都不同选型和迁移都需要结合自身情况做扎实的技术验证。但至少从今天起做这件事的人手里多了一份可以参考的坐标系——而不是只能在国外产品和不踏实的国产产品之间二选一。这或许才是这次测评通过最实在的价值。参考与延伸阅读中国信息安全测评中心《安全可靠测评结果公告2026 年第 2 号》中国信通院分布式时序数据库稳定性专项评测、性能专项评测、基础能力专项评测