当"安全可靠"成为必选项：DolphinDB 在关键行业时序数据底座上的架构抉择
2026 年 5 月，时序数据库首次出现在国家安全可靠测评结果公告中。DolphinDB 成为首批通过该测评的产品之一。消息在圈内引发讨论，但一个更实际的问题随之浮出水面：对于正在建设或改造数据基础设施的关键行业用户来说，这张"通行证"意味着什么？
本文将聚焦于一个具体的决策场景：当一家电力企业、金融机构或工业集团面临时序数据平台的选型或迁移时，"安全可靠"这个维度的加入，会如何改变评估框架？DolphinDB 的架构设计，又为这种评估提供了哪些差异化的答案？
一、选型框架的"新变量"：为什么时序数据库的安可认证很重要
过去几年，时序数据库的选型评估主要集中在三个维度：写入吞吐、查询延迟、生态兼容。这些维度至今仍然重要——但2026年的新变化是，"合规准入"正在从加分项变为一票否决项。
这个变化不是突然发生的。它有三个清晰的驱动因素：
驱动一：关键信息基础设施的"白名单化"。 随着《关键信息基础设施安全保护条例》和"安全可靠测评"制度的逐步落地，越来越多的关键行业在采购基础软件时，将"是否通过安可测评"列为招标前置条件。对于时序数据库这样一个刚刚被纳入名录的新品类，首批通过测评意味着进入了采购"白名单"的第一梯队。
驱动二：国产化替代从"可用"迈向"好用"。 信创战略推进到深水区后，企业关心的核心问题已经从"能不能替"转变为"替了之后性能是否达标"。单纯通过合规审查、但实际运行时性能折损严重的产品，反而会让甲方陷入"通不过业务验收"的困境。
驱动三：数据安全法规的执行颗粒度变细。 《数据安全法》《个人信息保护法》实施以来，监管对核心数据"不出境、不出库、可审计"的要求越来越具体。时序数据库作为数据存储与计算的底层载体，其自身的安全机制（权限控制、审计能力、事务保障）直接决定了上层应用能否合规。
这三重驱动叠加，意味着2026年之后的时序数据库选型不能再沿用"先看性能、再看安可"的线性评估方式——安全可靠与性能表现，需要放在同一张评估表里并行审视。
二、"两个自信"：DolphinDB 的架构层回答
在并行审视安全与性能的框架下，DolphinDB 的回答可以概括为"两个自信"——架构自信和工程自信。这两者共同构成了它通过安可测评的技术基础。
2.1 架构自信：存算一体不是噱头
首先要回答一个关键问题：为什么时序数据库要通过安可测评，比关系型数据库更难？
原因在于时序数据库的负载特征。关系型数据库的安可适配，主要集中在 SQL 引擎和事务机制的国产化移植上——这些模块相对标准化，有成熟的参考路径。但时序数据库的核心差异在于写入和计算的紧耦合：动辄每秒百万级的数据点持续写入，同时还要在写入路径上完成实时聚合、异常检测等计算任务。
这就带来了一个架构层面的矛盾——如果存储和计算是分离的两套系统（如"TSDB + 外部流计算引擎"的拼凑模式），那么在国产化适配时就需要同时适配两套系统的芯片和操作系统，而且两套系统之间的数据传输路径会引入额外的安全风险和性能损耗。
DolphinDB 的存算一体架构，在这个问题上给出了一个更简洁的答案：计算直接下推到存储节点，数据存储的位置就是计算发生的位置。
这个设计的效果是双重的——
从安全视角看：数据不需要在存储层和计算层之间来回搬运。一次数据搬运，就意味着一次网络传输，一次序列化/反序列化，一次权限边界的跨越。存算一体将这些都消除了，核心数据可以做到"不出节点"即可完成全部计算。
从性能视角看：数据搬运恰恰也是传统拼凑架构中最大的延迟来源。某水电企业的实际压测数据显示，DolphinDB 在百万级测点写入的同时能够保持毫秒级的复杂查询响应——这在数据必须跨系统搬运的传统架构中是很难实现的。
2.2 工程自信：在国产芯片上"跑得快"而非"能跑"
安可测评的"自主可控"要求，天然意味着对国产 CPU 和操作系统的适配。但行业内存在一种心照不宣的"潜规则"：许多产品的国产化适配停留在"能编译、能运行"的层面，一旦迁移到国产 ARM 芯片上，性能就出现 30%-50% 的折损。
DolphinDB 在国产化适配上的工程投入指向一个不同目标：在国产芯片上跑出接近 x86 的性能。
这背后的技术细节值得展开。DolphinDB 的核心计算引擎大量使用了向量化技术和 SIMD（单指令多数据）指令集优化。在 x86 平台上，这意味着利用 AVX-512 等指令集；在飞腾（ARM v8）平台上，则需要针对 NEON 指令集进行重新适配；在龙芯（LoongArch）平台上，则需要利用其自有的向量扩展指令。这三者在指令集层面互不兼容，无法"一次优化、到处通用"。
DolphinDB 的做法是在底层抽象出一层向量化原语，然后为每个指令集架构编写独立的优化实现。这意味着——当内置函数（超过 2000 个）在国产芯片上被调用时，它们调用的是经过该芯片指令集深度优化的机器码，而非通用的标量实现。
这种工程投入是"隐性"的——用户不会在功能列表里看到"SIMD 适配"这个条目，但在实际业务中，它直接体现为：同一套查询在飞腾服务器上从原来需要 3 秒变为 200 毫秒。
三、两个"不必取舍"：关键场景中的验证
架构设计最终要回到实际场景中接受检验。以下两个维度，是我们在与多家关键行业用户交流后发现的最具共性的关注点。
3.1 ACID 事务与高写入吞吐：不必取舍
时序数据库领域存在一个广为接受的"折中"：要事务保障，就得牺牲写入性能。因此，绝大多数时序产品根本不提供事务机制。
这个折中在普通监控场景下或许可以接受，但在电力调度、金融交易、核工业监控等场景中，数据的一致性和持久性不是可选项，而是合规底线——电网调度数据如果因为节点故障而部分丢失，可能导致调度决策失误；金融行情数据如果出现"部分写入成功、部分失败"的残缺状态，可能引发风控漏洞。
DolphinDB 是时序数据库领域中少数完整支持 ACID 事务的产品。但更重要的是，它的实现方式没有走"全局锁"或"串行化写入"的老路——而是采用分区级事务并行提交的机制：数据按分区组织，每个分区内的事务独立提交，不同分区之间并行执行。
从实际效果看：某新能源车企在 DolphinDB 上实现了每秒 1.8 亿测点的不间断写入，同时事务 ACID 机制全程在线——写入吞吐没有因为事务保障而出现明显折损。分区级事务使得"一致性与高吞吐"这对传统认知中的矛盾，在实际工程中得到了调和。
3.2 数据不出库与复杂分析：不必取舍
关键行业数据安全的另一条铁律是"核心数据不出库"——数据一旦被导出到外部平台进行分析，就面临泄露、残留、权限失控等风险。
但工业物联网的核心价值恰恰在于复杂分析：预测性维护需要跑机器学习模型，工艺优化需要多维关联分析，实时预警需要流式计算。传统时序数据库不具备这些计算能力，必须将数据导出到外部平台（Python、Spark、Flink 等），这就让安全团队和业务团队陷入了"数据不出库"与"数据要出库"的矛盾。
DolphinDB 的解法不在安全管理层面，"打补丁"式的权限控制，而在架构层面——库内计算。它内置了超过 2000 个函数（覆盖时序处理、信号处理、统计分析、机器学习等），原生支持 Tensor 数据格式，支持通过 libTorch、XGBoost、TensorFlow 等插件在数据库内部完成模型推理。
这意味着一条数据从写入到完成复杂分析再到输出结果，全链路在数据库进程内闭环。数据清洗、特征提取、模型预测——每一步都不需要离开 DolphinDB 的权限管控边界。
在国家地震台网中心的实际部署中，MiniSeed 波形数据写入后，FilterPicker 异常检测和 TensorFlow 模型推理全都在 DolphinDB 内部完成，从数据采集到预警输出，端到端延迟控制在毫秒级。数据没有离开数据库一步，但复杂分析和 AI 推理照常运行。
四、"双栈"适配：从芯片到 OS 的落地路径
对于正在规划国产化替代路线的企业而言，DolphinDB 在信创环境下的适配覆盖是一个务实的考量因素。
DolphinDB 已完成的兼容性认证覆盖了主流国产 CPU 和操作系统两条"栈"：
芯片栈： 龙芯（LoongArch）、鲲鹏（ARM v8）、飞腾（ARM v8）、海光（x86 兼容）、兆芯（x86 兼容）。
操作系统栈： 统信 UOS、银河麒麟、以及 openEuler 等主流国产服务器操作系统。
两栈组合后，覆盖了当前国内信创市场的主要配置方案。这意味着——无论甲方企业选择了哪种国产芯片 + 国产操作系统的组合，DolphinDB 都有现成的适配版本，不需要额外的"二次适配"周期。
此外，DolphinDB 已与麒麟信安等信创厂商完成了双栈安全可靠认证——在产品的信创履历上，这算是相当完整的配置。
五、从"能过审"到"能上线"
安可测评的意义，最根本的还是要回到业务场景里去检验——一个通过了安可认证的产品，在实际的关键业务中能不能真正跑起来。
以下四个案例涵盖了四种不同类型的"国计民生"场景，它们共同的特点是：既要满足最严苛的安全合规要求，又要承载最极端的性能和实时性要求。
案例一：大型水电企业——200 万测点 + 毫秒级预警
该企业是中国最大的水电上市公司，超过 200 万测点日增数百亿行数据，各电站地理位置分散。传统架构在跨测点关联查询时存在严重性能瓶颈。
使用 DolphinDB 云边协同架构部署后，各电站边缘侧进行数据预处理，云端做全量汇聚与深度分析。多副本高可用机制保障了 7×24 小时的数据安全和服务连续性。效果：故障预警从分钟级压缩至毫秒级，多源数据关联查询从分钟级降至秒级，复杂分析效率提升 5-6 倍。
案例二：中核集团某研究院——信创环境下的核工业组态监控
核工业监控对数据安全、系统可靠性、自主可控有着极为严苛的要求。该研究院仪控团队基于 DolphinDB 替换原有 MySQL 架构。
采用 PKEY 引擎保证 MySQL CDC 同步的数据一致性，TSDB 引擎处理海量时序数据，细粒度权限控制和审计日志满足核工业安全标准。效果：单表百亿数据毫秒级查询，上层应用无需重写，事务 ACID 保障了监控数据的完整可靠。
案例三：国家级地震台网中心——毫秒级波形预警全链路库内闭环
地震波形数据采集频率达到每 10 毫秒一条，传统方案需要将数据导出到外部系统进行分析，延迟无法满足预警需求。
DolphinDB 方案中，MiniSeed 文件直接写入数据库，FilterPicker 异常检测和 TensorFlow 模型推理在库内完成，无需数据导出。效果：端到端延迟控制在毫秒级，数据全程未离开权限管控边界。
案例四：某海关电子口岸——TB 级多源数据融合
海关业务涉及多个政府部门的数据系统，原架构为 MongoDB + Oracle + MySQL + Java 的拼凑方案，TB 级数据复杂查询延迟以分钟计。
利用 DolphinDB 的外部数据源生态实现多系统数据融合入仓，细粒度权限控制实现了不同部门间的数据访问隔离。效果：复杂查询从分钟级降至秒级，大幅简化和缩短了数据处理链路。
六、选型建议：在时序数据库评估中纳入"安可维度"
基于以上分析，当企业将"安全可靠"作为时序数据库的评估维度时，可以采用以下四个细化指标：
指标一：安全机制是内生的还是外加的？ 如果一个产品的安全能力（权限、审计、事务）是后期通过插件或外部工具"打补丁"实现的，那么这些安全机制往往与核心计算引擎存在性能冲突。DolphinDB 的存算一体和库内计算架构，让安全机制与计算引擎共享同一套底层设计。
指标二：国产化适配的深度是否经过验证？ 评估时不仅要看"支持哪些国产硬件"，更要在实际业务负载下测试"在这些硬件上的性能表现"。DolphinDB 对 LoongArch、ARM v8 等指令集的向量化优化，在性能敏感场景下会产生可测量的差距。
指标三：事务保障是否以写入性能为代价？ 对于需要事务 ACID 的关键场景，应关注产品的并行事务提交能力，而非简单地因为"支持事务"或"不支持事务"做二选一。DolphinDB 的分区级并行提交机制是一个可供参考的实现路径。
指标四：安全闭环是否同时是性能闭环？ "数据不出库"是最佳的安全实践，但如果不出库意味着放弃复杂分析，则并不实用。评估时应关注产品的库内计算能力是否足够支撑业务所需的全部分析链路。
七、结语
2026 年 5 月的这份公告，将时序数据库正式推到了关键信息基础设施建设的聚光灯下。对于 DolphinDB 来说，首批通过安全可靠测评意味着它拿到了进入关键行业的"入场券"——但真正的考验才刚刚开始。
关键行业需要的不只是一张"证书"，而是一个在实际业务中经得起验证的答案：在国产芯片上能跑多快？在每秒亿级写入的同时能否保持一致性？在数据不出库的前提下能不能完成 AI 推理？
这些问题没有标准答案，只有架构设计得好不好。DolphinDB 用存算一体解决了数据搬运带来的安全与性能矛盾，用分区级事务并行提交调和了 ACID 与写入吞吐的对立，用库内计算打破了"数据不出库"与"复杂分析"的二选一困境。这些架构层面的选择，构成了它回答上述问题的底气。
当"安全可靠"从可选项变为必选项，时序数据库的选型逻辑正在被重塑。而 DolphinDB 给出的答案体系——虽然不见得适合所有场景——至少证明了一件事：国产时序数据库可以在安全合规的框架内，跑出让人信服的性能。
了解更多： 访问 DolphinDB 官网（dolphindb.cn）或查阅官方技术文档（docs.dolphindb.cn）获取详细产品信息和技术白皮书。
免责声明： 本文基于中国信息安全测评中心 2026 年第 2 号公告、DolphinDB 官方产品文档及公开技术资料撰写。文中涉及的性能数据和案例信息以 DolphinDB 官方最新发布为准。
浙公网安备 33010602011771号