达梦分布计算集群DMDPC
一. 概述
1.简介
DMDPC 是基于达梦数据库管理系统研发的一款同时支持在线分析处理和在线事务处理的新型分布式数据库系统。它既具备传统单机数据库的绝大部分功能,又提供了分布式计算集群才拥有的高可用、高扩展、高性能、高吞吐量和对用户透明等高级特性。
2.架构
一个完整的 DMDPC 架构由计划生成节点 SP、数据存储节点 BP 和元数据服务器节点 MP 三部分组成。SP 对外提供分布式数据库服务,用户可以登录到任意一个 SP 节点,获得完整的数据库服务;BP 负责存储数据,执行 SP 的调度指令并将执行结果返回给 SP;MP 负责存储元数据并向 SP、BP 提供元数据服务。
SP 节点不存储数据,配置成单机即可。MP 和 BP 节点既可以配置成单机,也可以配置成多副本系统。其中每一个多副本系统中只有一个作为主节点,其余节点均作为备份节点。
3.基本术语
3.1 SP
计划生成节点,英文全称为 SQL Processor,简称为 SP。SP 为 DMDPC 集群中对外提供数据库服务的节点,负责接收用户请求并生成计划、划分子计划、按照一定规则计算并行度并调度各个子计划,并最终将执行结果返回给用户。SP 具备以下特征:
-
全部的 SQL 标准支持:包括复杂关联查询、存储过程、视图、序列等某些分布式数据库难以支持的特性。
-
SP 节点自身无状态:每个 SP 节点上不存储任何数据字典信息和用户数据,一个 集群中可以存在多个 SP 节点。连接上任何一个 SP 节点都可以获得完整的数据库服务。
-
SP 具备子计划的执行能力:因为 SP 和 BP 是由同一套代码编译出来的,只是不同的启动参数决定了担任不同的角色,所以 SP 和 BP 一样具有操作符的执行能力。
-
支持动态增删节点。
3.2 BP
数据存储节点,英文全称为 Backend Processor,简称为 BP。BP为DMDPC集群中数据实际存储的节点,负责存储数据和接收SP的子任务调度指令, 执行子任务,并返回结果给 SP。
一个 DMDPC 集群可配置多个 BP 节点同时提供服务,且可以随着用户业务量变化动态 增删 BP 节点。为了保障 BP 节点能够持续提供服务,每一个 BP 节点又可以配置成一个 BP 多副本系统。
3.3 MP
元数据服务器节点,英文全称为 Metadata Processor,简称为 MP,MP 为 DMDPC 集群中提供元数据服务(即字典信息服务)的节点。所有 DDL 请求都会经过 SP 转发给 MP 执行,元数据信息全部存储在 MP。
一个 DMDPC 集群只能配置一个 MP 节点提供服务。为了保障 MP 节点能持续提供服务, MP 节点可以配置成一个 MP 多副本系统。
3.4 BS 模式
BP 节点有两种启动模式:BP 模式和 BS 模式。
通常 BP 节点是以 BP 模式启动并运行,仅作为后台数据存储节点。如果 BP 节点以 BS 模式启动运行,用户可直接登录 BP 进行操作,此时的 BP 同时具有前端 SP 节点的功能也具有 BP 的功能,生成分布式计划,并和 MP/其他 BP 甚至辅助 SP 进 行数据交互。如果查询或修改的数据都在直连的 BP 本地,则类似于单节点,执行时无网络交互的代价,这相对于先连接到 SP,再查询或修改 BP 的模式,可获得性能上的提升。
3.5 QC
查询调度总单元(Query Coordinator,QC),在 SP 上,执行计划生成后拆分得到了一组子计划,执行期间由 QC 对执行计划的执行进行调度控制。
3.6 SQC
查询调度子单元(Sub Query Coordinator,SQC),在 BP 上,为处理同一计划中的一个或者多个子计划,采用 SQC 来进行协调,为每一个子计划生成一组线程执行、协调。SQC 可以认为是 QC 在每个 BP 上的调度助手,由 SQC 向 QC 汇报某一个子任务的完成情况。
3.7 RAFT 组
拥有相同数据的一个或多个节点共同构成一个 RAFT 组,RAFT 组中的节点个数为奇数。多副本系统基于 RAFT 算法,管理组内的节点,并始终维护一个主节点,保持 RAFT 组内的数据一致性。当 RAFT 组中含有三个或三个以上节点时,RAFT 组中的所有节点(三个或三
个以上)共同构成一个多副本系统。当 RAFT 组中只有 1 个节点时,则该节点称为单副本系统。
4. 系统原理
在 DMDPC 中,数据根据用户指定的分布规则分布在不同的 BP 上,DMDPC 的核心在于对用户请求的并行执行。下面对 DML(查询、插入、删除、更新)和 DDL 操作流程分别进行详细说明。
4.1. DML 流程
DML 流程分为两种情况:一般流程和优化流程。优化流程是指在实际执行时,对符合优化的细节进行优化之后形成的流程。EXPLAIN 查看执行计划时,包含 mpp_opt_flag(1)的即为优化流程下的执行计划,包含 mpp_opt_flag(0)的即为一般流程下的执行计划。
4.2. DDL 流程
DMDPC 中处理 DDL 请求的流程如下:
- 客户端发送 DDL 请求给 SP;
- SP 在经过初步分析后,判断出是 DDL 请求,转发给 MP,等待 MP 响应;
- MP 接收到 SP 转发的 DDL 请求后,根据具体类型,更改系统表;如果有 B 树创建、 删除等用户数据操作,转发给相应 BP 完成;所有步骤完成后回复 SP;
- SP 根据 MP 的反馈结果向客户端报告成功或失败。
二. 系统规范
1.集群中 SP、BP、MP 都有自己的实例名,这些实例名要求全局唯一;
2.一个 DMDPC 集群可以有多个 SP 和多个 BP,但只能有一个 MP;
3.DMDPC 中数据的分布以分区为单位,同一分区必须位于同一 BP,同一表的不同分区可以位于不同 BP,一张分区表的所有分区可只落在部分 BP;非分区表只包含一个分区, 因此非分区表只落在一个 BP 上。分区表包含一个或多个分区,因此分区表可以落在一个或 多个 BP 上;DMDPC 下,分区列同时也是分布列;
4.实例在初始化时需指定 DPC_MODE 以决定其角色(SP、BP 或 MP),随后启动时需要附带上 DPC_MODE 参数。实例角色在初始化后不能更改。
三. 关键技术
1.元数据服务
在 DMDPC 中,为了简化 DDL 的处理,使用专门的元数据服务器 MP 负责管理所有的字典对象元数据信息。所有 SP 和 BP 都是通过网络请求从 MP 获取字典对象的。
2.DMDPC 的计划生成
DMDPC 的执行计划是在单机数据库执行计划的基础上插入了数据交换操作符 ESEND/ERECV 后形成的。数据交换操作符的插入只发生在特定的操作符中,例如:连接、分组、排序等。
在处理每一个单机操作符时,优化器会考虑各种可能的数据分发方式。优化器穷举各种可能的路径,根据代价模型依次计算代价值,最后挑选出最小代价。用户可以通过 EXPLAIN 命令查看执行计划,通过 10053 TRACE 信息(需设置 10053 trace event)观察到计划的优化过程。
3.子计划分割与调度
子计划分割以 ESEND/ERECV 操作符为界限分割原始计划得到一系列的子计划。每个子计划之间相互独立执行,有各自的并行度,采用不同的线程。子计划一般以 ESEND 操作符为根节点,以 ERECV 为叶子操作符节点。
相邻的一对 ESEND/ERECV 操作符所在的子计划被称为父子关系子计划,因为 ESEND 所在的子计划发送的数据是要依靠 ERECV 所在的父亲子计划来接收的,二者之间存在着依赖关系,可以称为 Parent SPLAN 和 Child SPLAN。一个 SPLAN 最多只有一个 Parent SPLAN,但是可以有零个、一个或多个 Child SPLAN。
4.生产者、消费者并行执行模型
DMDPC 使用的生产者、消费者并发执行模型。该模型将父子子任务分别视为消费者子任务、生产者子任务。
生产者子任务的角色是生产数据,只要有数据的存放空间,生产动作可以一直进行下去直至生产结束。 消费者子任务的角色是消费数据,只要有新的数据进来,消费动作可以一直进行下去。
5.分布式事务一致性
在分布式系统架构下,不同的服务器之间通过网络远程协作而完成的事务,称为分布式事务。
DMDPC 通过两阶段提交技术来保证多个 BP 之间的分布式事务一致性。两阶段提交的参 与者为 SP 和 BP。SP 作为全局事务的协调者,统一处理全局事务,BP 作为参与者,是被 SP 调度并执行事务的节点。SP 根据 BP 的响应来决定是否真正的执行并提交事务。所有参 与者 BP 要么一起提交要么一起回滚,始终保持事务一致性状态。两阶段分为预提交阶段和提交阶段。
5.1 预提交
- 客户端向 SP 发起事务提交请求。
- SP 向所有参与者 BP 广播预提交命令。询问是否可以进行事务 COMMIT,并等待 BP 的响应。
- BP 接收到预提交命令之后,将相关操作生成回滚日志写入回滚段并响应 SP。
- 如果 SP 收到所有参与者 BP 的预提交成功的消息,则进入第二阶段进行提交。否则,当存在 BP 没有响应导致 SP 无法确定该 BP 是否执行了预提交时,SP 先尝试通知存活 BP 执行回滚。若有 BP 回滚成功,SP 就可以直接响应“事务提交失败”给客户端;否则 SP 只能响应“未知的提交结果”给客户端。客户端不论是收到“事务提交失败”还是“未知的提交 结果”,都表示事务执行失败。
5.2提交
如果 SP 收到所有参与者 BP 的预提交成功的消息,那么说明可以进入提交阶段。
- SP 向所有参与者 BP 广播 COMMIT 命令。
- BP 接收到提交命令之后,执行二阶段的提交任务,释放事务资源,并将 COMMIT 成功结果反馈给 SP。
结果”,都表示事务执行失败。
5.2提交
如果 SP 收到所有参与者 BP 的预提交成功的消息,那么说明可以进入提交阶段。
- SP 向所有参与者 BP 广播 COMMIT 命令。
- BP 接收到提交命令之后,执行二阶段的提交任务,释放事务资源,并将 COMMIT 成功结果反馈给 SP。
- SP 收到所有参与者 BP 的 COMMIT 成功消息之后,直接响应客户端事务提交成功。 二阶段提交时若遇到 BP 与 SP 通信中断,SP 会将提交任务交由异步任务进行处理并立即响应客户端事务提交成功。待故障 BP 与 SP 重新建立连接后,异步任务会自动重新执行二阶 段提交,直到提交成功。客户端收到事务提交成功的消息,表示事务执行成功完成。