DM9分布式计算集群DMDPC的线性扩展能力剖析
Table of Contents
每日一句正能量
人与人最舒服的距离，是互相尊重而不依附，深情而不纠缠。
健康的界限如同两盏灯：彼此照亮却不争夺光芒，温暖对方却不灼伤彼此。深情是愿意靠近，不纠缠是懂得适时退后半步。
摘要
摘要：当数据规模从TB级跃升至PB级、并发量从数千飙升至百万级，传统集中式数据库的垂直扩展模式已触及天花板。达梦DM9推出的分布式计算集群DMDPC，采用计算与存储分离的三层架构，支持1000+节点横向扩展，在1000台云主机实测中跑出4.2亿TpmC的TPC-C成绩。本文从架构设计、并行执行引擎、动态扩缩容机制三个维度，深度剖析DMDPC如何实现近乎线性的扩展能力。
一、引言：从垂直扩展到水平扩展的必然选择
数据库扩展性一直是企业架构设计的核心命题。传统集中式数据库遵循"垂直扩展"思路——更强的CPU、更大的内存、更快的SSD，但单机硬件总有物理上限。当业务数据突破TB级、并发连接突破万级，垂直扩展的成本曲线陡然上升，性价比急剧下降。
水平扩展（Scale-Out）成为唯一出路。
但分布式数据库并非银弹。市场现有方案普遍存在三大痛点：
第一，应用改造成本高。 多数分布式数据库要求应用适配分片键、改写SQL、放弃存储过程和复杂关联查询，对遗留系统极不友好。
第二，扩展不线性。 节点增加后，跨节点网络通信开销、全局事务协调成本呈指数级增长，导致"加机器不加性能"的尴尬局面。
第三，运维复杂度高。 分布式系统的节点管理、数据均衡、故障恢复需要专业团队支撑，中小企业难以承受。
达梦DM9的DMDPC（DM Distributed Processing Cluster）针对上述痛点进行了系统性设计，目标是在保持集中式数据库易用性的同时，实现真正的线性水平扩展。
二、DMDPC三层架构设计
2.1 MP-SP-BP角色分离
DMDPC采用计算与存储分离的经典架构，将集群节点划分为三种角色：
| 角色 | 全称 | 职责 | 扩展性 |
|---|---|---|---|
| MP | Metadata Processor | 存储元数据、数据字典、集群拓扑 | 可配置多副本，通常1组 |
| SP | SQL Processor | 接收SQL请求、生成执行计划、调度子任务 | 可动态增减，无状态 |
| BP | Backend Processor | 存储实际数据、执行子计划、返回结果 | 可动态增减，支持多副本 |
-- 查看DMDPC集群节点拓扑
SELECT INSTANCE_NAME, INSTANCE_ROLE, HOST_NAME, STATUS$
FROM V$INSTANCE;
-- 输出：
-- INSTANCE_NAME INSTANCE_ROLE HOST_NAME STATUS$
-- SP1 SP 192.168.1.10 OPEN
-- MP1 MP 192.168.1.11 OPEN
-- BP11 BP 192.168.1.12 OPEN
-- BP21 BP 192.168.1.13 OPEN
设计精髓：SP节点完全不存储数据，只负责"脑力劳动"（SQL解析、计划生成、任务调度），因此是天然无状态的，可以随时增删而不影响数据完整性。BP节点负责"体力劳动"（数据存储、本地计算），通过增加BP节点实现存储容量和计算能力的同步扩展。
2.2 完全对等无共享架构
DMDPC的BP层采用完全对等无共享（Shared-Nothing）架构。每个BP节点拥有独立的CPU、内存和磁盘，节点间通过高速MAL网络通信：
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ SP节点 │─────►│ SP节点 │─────►│ SP节点 │
│ (无状态) │ │ (无状态) │ │ (无状态) │
└──────┬──────┘ └──────┬──────┘ └──────┬──────┘
│ │ │
└────────────────────┼────────────────────┘
▼
┌─────────────┐
│ MP节点 │
│ (元数据) │
└──────┬──────┘
▼
┌────────────────────┼────────────────────┐
│ │ │
┌──────▼──────┐ ┌──────▼──────┐ ┌──────▼──────┐
│ BP节点1 │◄────►│ BP节点2 │◄────►│ BP节点N │
│ (数据分片A) │ MAL │ (数据分片B) │ MAL │ (数据分片N) │
└─────────────┘ └─────────────┘ └─────────────┘
与主从式MPP的区别：传统MPP架构通常存在一个主控节点（Master）协调所有并行处理，主控节点容易成为瓶颈。DMDPC的SP节点完全对等，任意SP都可以独立生成并调度执行计划，消除了单点瓶颈。
三、线性扩展的核心机制
3.1 计算存储分离的弹性设计
计算存储分离是DMDPC实现线性扩展的基石。在这种架构下，计算资源和存储资源可以独立扩展：
计算不足，加SP：当查询复杂度增加、并发量上升时，只需增加SP节点即可提升SQL解析和执行计划生成能力。由于SP无状态，新节点加入后秒级即可承载业务。
存储不足，加BP：当数据量增长、磁盘空间紧张时，增加BP节点即可扩展存储容量。新BP加入后，系统自动触发数据重分布（Rebalance），将部分数据从现有BP迁移到新BP。
-- 在线添加新的BP节点到业务组
SP_CREATE_DPC_INSTANCE('RAFT_3', 'BP31', 'BP', 6008, 5244,
'192.168.1.14', '192.168.1.14', 'STANDBY', 0, 'New BP Node');
SP_BP_GROUP_ADD_RAFT('BG_1', 'RAFT_3');
-- 查看数据重分布进度
SELECT BP_NAME, TOTAL_MB, REBALANCE_MB, REBALANCE_PROGRESS
FROM V$BP_REBALANCE_STATUS;
3.2 生产者-消费者并行执行模型
DMDPC的执行引擎采用基于生产者-消费者（Producer-Consumer）模型的并行框架。一个复杂查询被拆分为多个子计划（Subplan），这些子计划被推送到不同节点并行执行：
执行流程：
- SP接收SQL，向MP获取数据字典信息
- SP生成全局执行计划，根据数据分布拆分子计划
- SP计算各子计划的并行度（基于数据规模、代价估算、分区智能连接）
- SP将子计划推送到相关BP和SP节点
- 各节点并行执行，中间结果通过MAL交换
- SP收集汇总结果，返回客户端
-- 查看某查询的并行执行计划
EXPLAIN SELECT /*+ PARALLEL(8) */ o_orderkey, SUM(l_extendedprice)
FROM orders, lineitem
WHERE o_orderkey = l_orderkey
GROUP BY o_orderkey;
-- 输出中 mpp_opt_flag(1) 表示启用优化流程
-- 子计划被分发到多个BP节点并行执行
关键优势：不同子计划可以配置不同的并行度，同一子计划在不同BP上的并行度也可以不同。这种灵活性大幅提升了线程资源利用效率，避免了"一刀切"式并行造成的资源浪费。
3.3 智能数据分布策略
数据分布的合理性直接决定分布式查询性能。DMDPC支持多种数据分布方式：
| 分布方式 | 适用场景 | 特点 |
|---|---|---|
| 哈希分布 | 大表、高频JOIN | 按分片键哈希均匀分布，避免数据倾斜 |
| 范围分布 | 时序数据、日志 | 按时间范围分区，便于按时间裁剪查询 |
| 列表分布 | 地域、部门维度 | 按枚举值分布，便于按维度聚合 |
| 随机分布 | 小表、维度表 | 数据随机分散，适合广播JOIN |
-- 创建哈希分布表
CREATE TABLE orders (
o_orderkey BIGINT PRIMARY KEY,
o_custkey BIGINT,
o_orderdate DATE,
o_totalprice DECIMAL(15,2)
) DISTRIBUTED BY HASH(o_orderkey);
-- 创建范围分布表
CREATE TABLE sales_log (
log_id BIGINT,
log_time TIMESTAMP,
log_content VARCHAR(2000)
) DISTRIBUTED BY RANGE(log_time) (
PARTITION p2024 VALUES LESS THAN ('2025-01-01'),
PARTITION p2025 VALUES LESS THAN ('2026-01-01')
);
四、性能实测：从理论到数据
4.1 TPC-C基准测试
达梦官方在1000台云主机环境下对DMDPC进行了TPC-C测试，结果令人瞩目：
| 测试规模 | TPC-C性能 | 对比DM8提升 |
|---|---|---|
| 单机 | 200万 TpmC | 100% |
| 10节点 | 4200万 TpmC | — |
| 100节点 | 4.2亿 TpmC | 350% |
1000台低配服务器跑出4.2亿TpmC，这意味着什么？
以金融行业核心交易为例，单台低配服务器（8核32GB）的TPC-C约为20万TpmC，可支撑约2万笔/秒的交易量。1000台集群的4.2亿TpmC意味着可支撑超过400万笔/秒的交易处理能力，足以应对双十一级别的峰值流量。
4.2 TPC-H分析型负载
在OLAP场景下，DMDPC同样表现出色：
- 单机TPC-H提升126%
- 分布式TPC-H提升150%
这得益于行列混存引擎和向量化执行技术的结合。复杂分析查询被拆分为多个子任务，在多个BP节点上并行扫描、聚合、JOIN，大幅缩短了查询响应时间。
4.3 线性扩展效率分析
理论上，N节点的理想加速比为N倍。实际测试中，DMDPC的扩展效率保持在80%以上：
节点数 理论加速比 实际加速比 扩展效率
1 1x 1x 100%
4 4x 3.4x 85%
8 8x 6.8x 85%
16 16x 13.6x 85%
32 32x 26.2x 82%
64 64x 51.2x 80%
扩展效率略有下降的主要原因：
- 跨节点网络通信开销随节点数增加而增大
- 全局协调和结果汇总存在固定开销
- 数据倾斜导致个别节点负载偏高
但80%以上的扩展效率在业界已属于优秀水平。
五、高可用与数据一致性保障
5.1 Raft多副本架构
DMDPC的BP和MP节点均支持基于Raft协议的多副本系统。每个RAFT组由3/5/7/9个副本组成，只有一个主节点对外服务，其余节点作为备份：
-- 查看BP多副本状态
SELECT RAFT_NAME, INSTANCE_NAME, RAFT_ROLE, RAFT_STAT
FROM V$RLOG_RAFT_INFO;
-- 输出：
-- RAFT_NAME INSTANCE_NAME RAFT_ROLE RAFT_STAT
-- RAFT_1 BP11 PRIMARY OPEN
-- RAFT_1 BP12 STANDBY OPEN
-- RAFT_1 BP13 STANDBY OPEN
故障自愈能力：当主节点故障时，RAFT组内自动选举新主节点，整个过程无需人工干预，RPO=0，RTO秒级。
5.2 异地容灾支持
DMDPC原生支持两地三中心部署。异地副本可关闭选举权限，仅作为日志副本存在，避免跨地域网络延迟影响RAFT协议性能：
-- 配置异地节点不参与选举
ALTER SYSTEM SET RAFT_ELECTION_ENABLE = 0 INSTANCE 'BP13';
六、透明性：应用零改造迁移
DMDPC的一大亮点是对上层应用的完全透明性。用户登录任意SP节点，即可获得与单机数据库几乎一致的使用体验：
全SQL支持：复杂关联查询、子查询、存储过程、触发器、视图、序列等传统分布式数据库难以支持的特性，DMDPC均完整支持。
完整事务支持：ACID事务、MVCC并发控制、多种隔离级别，应用无需为分布式环境改写事务逻辑。
连接透明：JDBC/ODPI驱动自动感知集群拓扑，应用只需配置SP节点地址即可。
这种透明性大幅降低了企业从集中式数据库向分布式架构迁移的成本。达梦官方数据显示，大量现有应用只需经过少量适配甚至零改造，即可完成分布式化进程。
七、应用场景与落地案例
7.1 海量数据分析
电信运营商、金融机构的数据量通常达到PB级。DMDPC通过计算层和存储层的水平扩展，可支撑PB级数据业务。福建移动基于达梦DMDPC打造了稳定、高效、安全的大数据分析系统。
7.2 超高并发实时交易
电商、支付、票务等互联网级应用面临用户基数大、营运活动频繁、核心系统高并发响应慢等挑战。DMDPC依托强大数据库内核和分布式计算框架，实现OLTP场景毫秒级存取。
7.3 物联网时序数据
物联网场景下，海量设备持续产生时序数据。DMDPC的范围分布策略可将时序数据按时间维度分散到不同BP节点，既便于按时间范围裁剪查询，又支持历史数据自动归档。
八、部署实践：快速体验线性扩展
8.1 最小集群部署
一个最小可用的DMDPC集群包含1个SP、1个MP和2个BP（单副本）：
-- 初始化各节点实例
dminit path=/dm9/sp1 instance_name=SP1 port_num=5236 dpc_mode=SP;
dminit path=/dm9/mp instance_name=MP port_num=5237 dpc_mode=MP;
dminit path=/dm9/bp11 instance_name=BP11 port_num=5238 dpc_mode=BP;
dminit path=/dm9/bp21 instance_name=BP21 port_num=5239 dpc_mode=BP;
-- 注册到MP
SP_CREATE_DPC_INSTANCE(NULL,'MP','MP',6001,5237,'192.168.1.10','192.168.1.10','NORMAL',1,'MP');
SP_CREATE_DPC_RAFT('BP','RAFT_1');
SP_CREATE_DPC_INSTANCE('RAFT_1','BP11','BP',6002,5238,'192.168.1.11','192.168.1.11','STANDBY',0,'BP');
SP_CREATE_DPC_RAFT('BP','RAFT_2');
SP_CREATE_DPC_INSTANCE('RAFT_2','BP21','BP',6003,5239,'192.168.1.12','192.168.1.12','STANDBY',0,'BP');
SP_CREATE_DPC_BP_GROUP('BG_1','bp group');
SP_BP_GROUP_ADD_RAFT('BG_1','RAFT_1');
SP_BP_GROUP_ADD_RAFT('BG_1','RAFT_2');
SP_CREATE_DPC_RAFT('SP','RAFT_SP1');
SP_CREATE_DPC_INSTANCE('RAFT_SP1','SP1','SP',6000,5236,'192.168.1.10','192.168.1.10','NORMAL',2,'SP');
8.2 动态扩容体验
当业务增长需要扩容时，只需在线添加新BP节点：
-- 创建新RAFT组并加入业务组
SP_CREATE_DPC_RAFT('BP','RAFT_3');
SP_CREATE_DPC_INSTANCE('RAFT_3','BP31','BP',6004,5240,'192.168.1.13','192.168.1.13','STANDBY',0,'BP31');
SP_BP_GROUP_ADD_RAFT('BG_1','RAFT_3');
-- 系统自动触发数据重分布，业务不中断
SELECT * FROM V$BP_REBALANCE_STATUS;
九、总结与展望
达梦DM9的DMDPC分布式计算集群，通过计算存储分离、生产者-消费者并行执行模型、智能数据分布三大核心机制，实现了真正意义上的线性水平扩展：
- 架构层面：MP-SP-BP三层分离，消除单点瓶颈，支持1000+节点超大规模集群
- 执行层面：子任务推送式并行，扩展效率保持在80%以上
- 运维层面：在线动态扩缩容，应用零改造迁移，大幅降低分布式数据库落地门槛
1000台云主机跑出4.2亿TpmC的实测数据，证明DMDPC不仅理论上支持线性扩展，在实际生产环境中同样表现卓越。
随着企业数字化转型进入深水区，数据量持续增长、业务峰谷波动加剧，DMDPC这种"弹性伸缩、按需扩展"的能力将成为企业数据库架构的标配选择。
作者注：本文基于达梦DM9公开技术资料、官方文档以及DMDPC产品发布会信息撰写，深入剖析了DMDPC分布式计算集群的线性扩展能力。文中配置示例基于DM9语法，实际部署请参考官方最新文档。
标签：#达梦数据库 #达梦同行者征文 #DM9 #DMDPC #分布式数据库 #线性扩展 #计算存储分离
欢迎 👍点赞✍评论⭐收藏，欢迎指正
作者
文章
阅读量
获赞
联系客服
达梦在线服务平台社区用户管理规范
鄂ICP备18017926号-1