DM9计算卸载技术在存储层的实现与优化
Table of Contents
每日一句正能量
真正的强大是在认真付出后，对结果保持一份坦然。
脆弱者求即时回报，强大者信过程本身。像农人耕耘：全心播种、浇灌，然后交给天气与时间。收成丰歉都接受，因为弯腰劳作的姿态已赋予土地尊严。
摘要
摘要：在大数据场景下，传统数据库架构面临一个致命瓶颈——海量数据必须从存储层搬运到计算层才能处理，网络传输开销和内存占用成为性能杀手。达梦DM9推出的计算卸载技术，在存储端植入计算引擎，将过滤、投影、聚合、连接等运算下沉到存储节点本地执行，使数据传输量从TB级骤降至MB级。本文从技术原理、实现机制、场景覆盖和性能实测四个维度，深度解析这项突破性的性能优化技术。
一、引言：数据搬运的"阿喀琉斯之踵"
数据库系统的性能瓶颈，往往不在计算，而在搬运。
想象这样一个场景：一张20亿条记录的交易历史表，业务需要按特定条件筛选一批记录用于后续分析。由于查询条件包含模糊匹配，索引无法发挥作用，数据库只能执行全表扫描。在传统架构下，这意味着什么？
存储层需要将整张表的原始数据——可能是2TB——通过网络全部传输到计算层。计算层接收后，在内存中进行过滤、投影、聚合，最终返回几百MB的结果。整个过程中，TB级的数据在网络和内存中"空转"，既消耗带宽，又挤占缓存，还拖慢其他业务的响应。
这就是传统数据库架构的"阿喀琉斯之踵"：数据必须搬到计算层才能处理。
达梦DM9的计算卸载（Compute Offloading）技术，从根本上颠覆了这一范式——把计算推向数据，而不是把数据拉向计算。
二、计算卸载技术原理
2.1 架构对比：从"拉数据"到"推计算"
传统架构： 计算卸载架构：
┌─────────────┐ ┌─────────────┐
│ 计算层 │◄──── TB级数据传输 ────┤ 存储层 │
│ 全表扫描 │ 原始数据全量搬运 │ 被动存储 │
│ 过滤聚合 │ │ │
└─────────────┘ └─────────────┘
┌─────────────┐ ┌─────────────┐
│ 计算层 │◄──── MB级结果 ────────┤ 存储层 │
│ 结果汇总 │ 仅返回匹配结果 │ 计算引擎 │
│ │ │ 过滤聚合 │
└─────────────┘ └─────────────┘
核心差异：
| 维度 | 传统架构 | 计算卸载架构 |
|---|---|---|
| 数据传输量 | TB级（全量原始数据） | MB级（仅结果集） |
| 网络开销 | 极高 | 极低 |
| 计算层缓存占用 | 大量Buffer被占用 | 几乎不占用 |
| 存储层角色 | 被动存取 | 主动参与计算 |
| 响应时间 | 分钟级 | 秒级 |
2.2 存储端计算引擎
DM9在存储端植入了一个轻量级计算引擎，让存储节点具备了"智慧的大脑"。这个引擎并非简单的SQL解析器，而是一个面向存储优化的执行器：
-- 查看计算卸载执行计划
EXPLAIN SELECT COUNT(*), SUM(amount)
FROM transaction_history
WHERE create_time BETWEEN '2024-01-01' AND '2024-12-31'
AND status = 'COMPLETED';
-- 计划中会出现 OFFLOAD 标识，表示以下操作在存储层完成：
-- 1. 谓词过滤: create_time范围 + status匹配
-- 2. 字段投影: 仅读取amount列
-- 3. 聚合计算: COUNT和SUM在存储节点本地累加
-- 4. 最终结果: 仅返回聚合值到计算层
引擎设计要点：
- 向量化执行：一次处理一批数据，而非逐行处理，充分利用SIMD指令
- 列式读取：仅读取查询需要的列，避免整行解析开销
- 本地聚合：在存储节点完成部分聚合，减少传输数据量
- 谓词下推：将WHERE条件直接推到存储层过滤
三、四大类46种卸载场景
达梦计算卸载技术已覆盖SQL处理的四大核心环节，共计46种具体场景：
3.1 谓词过滤（Predicate Pushdown）
最基础也是最有效的卸载场景。将WHERE子句中的过滤条件下推到存储层：
-- 场景1: 范围条件
SELECT * FROM sales WHERE sale_date BETWEEN '2024-01-01' AND '2024-03-31';
-- 场景2: IN条件
SELECT * FROM orders WHERE region IN ('华东', '华南', '华北');
-- 场景3: 模糊匹配
SELECT * FROM customers WHERE name LIKE '%科技%';
-- 场景4: 多条件组合
SELECT * FROM transactions
WHERE create_time > '2024-01-01'
AND amount > 10000
AND status = 'SUCCESS';
效果：存储节点在读取数据时直接跳过不满足条件的行，只将匹配行返回计算层。
3.2 函数卸载（Function Offloading）
将各类函数运算下沉到存储节点执行：
-- 场景5: 聚合函数
SELECT region, COUNT(*), SUM(amount), AVG(price), MAX(create_time)
FROM sales GROUP BY region;
-- 场景6: 类型转换函数
SELECT TO_CHAR(create_time, 'YYYY-MM'), COUNT(*) FROM orders GROUP BY 1;
-- 场景7: 字符串函数
SELECT SUBSTR(product_code, 1, 4), COUNT(*) FROM inventory GROUP BY 1;
-- 场景8: 数学函数
SELECT ABS(profit), ROUND(amount, 2) FROM finance;
效果：聚合计算在存储节点本地完成，计算层只需汇总各节点的部分结果。
3.3 多表连接（Join Offloading）
这是计算卸载中最具技术挑战的场景。DM9支持将哈希连接、嵌套循环连接等算法下沉到存储节点：
-- 场景9: 哈希连接下推
SELECT o.order_id, c.customer_name, o.total_amount
FROM orders o JOIN customers c ON o.customer_id = c.customer_id
WHERE o.order_date > '2024-01-01';
-- 存储层执行逻辑：
-- 1. 扫描orders表，过滤order_date条件
-- 2. 在存储节点构建哈希表（小表侧）
-- 3. 执行本地哈希连接
-- 4. 仅返回连接结果到计算层
效果：连接操作在存储节点完成，避免了大量中间结果跨网络传输。
3.4 字段投影（Projection Pushdown）
仅读取查询需要的列，在存储层完成列裁剪：
-- 场景10: 列裁剪
SELECT customer_id, order_date, total_amount FROM orders;
-- 表结构有20列，但查询只需要3列
-- 存储层仅读取这3列，避免整行解析
效果：减少I/O量，尤其对大宽表效果显著。
四、直接路径读机制
计算卸载的另一个重要搭档是**直接路径读（Direct Path Read）**机制。
传统读取方式中，全表扫描的数据会先加载到Buffer Cache中，这会带来两个问题：
- 大表扫描会"挤占"Buffer Cache，导致热点数据被换出
- 并发的大表扫描会相互干扰，影响OLTP业务
DM9的直接路径读机制绕过了Buffer Cache，直接从磁盘读取数据到PGA（程序全局区）：
-- 开启直接路径读（通常由优化器自动决策）
ALTER SESSION SET "_DIRECT_PATH_READ" = TRUE;
-- 大表扫描自动选择直接路径读
SELECT /*+ FULL(t) */ COUNT(*) FROM big_table t;
与计算卸载的配合：
- 直接路径读避免冲击Buffer Cache
- 计算卸载减少数据传输量
- 两者结合，实现"不占用缓存、不浪费带宽"的高效扫描
五、软硬协同优化
计算卸载技术要发挥最大效果，离不开底层基础设施的支撑。达梦数据库一体机（DAMENG PAI）通过三项硬核技术构建了极致的数据通路：
5.1 全栈RDMA高速网络
传统TCP/IP网络就像一条2车道的普通公路，常有拥堵。达梦一体机采用RoCE v2协议构建200Gb/s全栈RDMA网络：
| 指标 | 传统TCP/IP | RDMA网络 | 提升 |
|---|---|---|---|
| 带宽 | 25Gb/s | 200Gb/s | 8倍 |
| 节点间时延 | ~400μs | ~130μs | 降低66% |
| CPU开销 | 高（内核协议栈） | 零（绕过OS） | 大幅降低 |
RDMA允许计算节点直接访问存储节点的内存，无需操作系统介入，就像行驶在畅通无阻的8车道高速路上。
5.2 全用户态I/O通道
传统架构中，一次I/O操作需要经历：用户态→内核态→设备驱动→硬件，再原路返回，产生大量上下文切换和数据拷贝。
达梦全用户态I/O通道彻底绕过操作系统内核：
传统I/O路径： 全用户态I/O路径：
应用 → 系统调用 → 内核缓冲区 → 应用 → SPDK/RDMA → NVMe SSD
协议栈 → 网卡 → 存储 （零拷贝、零中断）
（3次数据搬运）
单I/O时延: 400μs 单I/O时延: 80μs
时延从400μs降至80μs，提升5倍以上。
5.3 极速存储系统
达梦为数据库负载量身定制了分布式存储系统：
- 3台通用服务器实现1200万IOPS（4K随机读写）
- 对标售价200万元级的企业级存储阵列
- 综合降本60%
- 分层存储：热点数据驻留高速缓存层，冷数据自动沉降NVMe SSD，读取时延整体下降50%
六、性能实测：从数据到真相
6.1 实验室基准测试
| 测试场景 | 传统架构 | 计算卸载 | 性能提升 |
|---|---|---|---|
| 20亿行大表扫描+过滤 | 5分18秒 | 6.3秒 | 50倍 |
| 2TB数据聚合查询 | 3分42秒 | 4.5秒 | 49倍 |
| 多条件组合过滤 | 2分15秒 | 3.2秒 | 42倍 |
| 宽表列裁剪投影 | 1分28秒 | 2.8秒 | 31倍 |
6.2 证券核心系统实测
在某证券核心系统的生产环境验证中，客户选取了12条压力最大的核心SQL：
- 全部完成计算卸载
- 响应时间均控制在3秒以内
- 最慢的一条从22.4秒降至1.33秒，提升16倍
6.3 高并发场景实测
在某地方国企核心系统1000并发负载下：
| 指标 | 优化前 | 优化后 | 提升 |
|---|---|---|---|
| 单表插入TPS | 8,731 | 68,870 | 6.9倍 |
| 多表查询TPS | 基准 | 翻倍 | 2倍 |
| 事务执行TPS | 基准 | 3倍+ | 3倍 |
| 单表插入时延 | 371ms | 48ms | 7.7倍 |
| 多表查询时延 | 49ms | 1ms | 49倍 |
| 事务执行时延 | 51ms | 3ms | 17倍 |
七、AI场景延伸
计算卸载技术不仅适用于传统关系数据，还延伸至AI场景：
-- 向量距离计算下推
SELECT doc_id, embedding <=> query_vec AS distance
FROM document_vectors
WHERE category = '技术文档'
ORDER BY distance LIMIT 10;
-- 存储层完成：
-- 1. 谓词过滤: category匹配
-- 2. 向量距离计算: embedding <=> query_vec
-- 3. 本地TopK裁剪: 仅返回距离最小的10条
效果：基于DM9原生向量数据的AI计算卸载，性能可提升30倍。
八、最佳实践与优化建议
8.1 何时触发计算卸载
计算卸载并非万能，以下场景效果最佳：
- 大表扫描：数据量越大，卸载收益越明显
- 高选择率过滤：过滤后结果集远小于原始数据
- 聚合查询：COUNT/SUM/AVG等可本地累加
- 宽表投影：只需要少量列的查询
以下场景收益有限：
- 小表查询：数据量小，搬运开销不大
- 低选择率过滤：返回大量数据，传输减少有限
- 复杂嵌套子查询：需要多轮交互，难以一次性卸载
8.2 监控与诊断
-- 查看计算卸载执行统计
SELECT SQL_ID, OFFLOAD_FLAG, OFFLOAD_OPS, ELAPSED_TIME
FROM V$SQL_OFFLOAD
WHERE OFFLOAD_FLAG = 'YES'
ORDER BY ELAPSED_TIME DESC;
-- 查看各存储节点卸载执行情况
SELECT BP_NAME, OFFLOAD_SQL_COUNT, OFFLOAD_ROWS_PROCESSED
FROM V$BP_OFFLOAD_STATS;
九、总结与展望
达梦DM9的计算卸载技术，通过在存储端植入计算引擎，实现了从"搬数据"到"推计算"的范式转变：
- 架构创新：存储节点从被动存取升级为主动计算，数据传输量从TB级降至MB级
- 场景覆盖：四大类46种SQL场景，解决90%以上常见性能堵点
- 软硬协同：RDMA高速网络+全用户态I/O+极速存储，构建极致数据通路
- 实测验证：20亿行大表扫描从5分钟降至6秒，证券核心系统全量SQL达标
这项技术的意义不仅在于性能数字，更在于它重新定义了存储与计算的关系。在AI时代，数据价值兑现要求实时闭环，任何不必要的数据搬运都是效率的敌人。计算卸载让存储层成为真正的"智能底座"，为数据库从"数据仓库"进化为"价值引擎"铺平了道路。
据达梦官方透露，下一步将攻关存储索引、混合列式压缩、DB-In-Memory等技术，目标在关键场景上再提升100倍性能。国产数据库的"探月工程"，正在向更深处推进。
作者注：本文基于达梦DM9公开技术资料、DTCC 2026演讲实录以及达梦一体机产品文档撰写，深入解析了计算卸载技术在存储层的实现原理和优化机制。文中配置示例基于DM9语法，实际部署请参考官方最新文档。
标签：#达梦数据库 #达梦同行者征文 #DM9 #计算卸载 #存储引擎 #性能优化 #数据库一体机
欢迎 👍点赞✍评论⭐收藏，欢迎指正
作者
文章
阅读量
获赞
联系客服
达梦在线服务平台社区用户管理规范
鄂ICP备18017926号-1