传统的关系型数据库存在单机规模限制, 无法满足扩容持续扩展和性能扩展的需求, 而现有的大部分 NoSQL 数据库对于关系型 SQL 语句支持有待提升, 从目前的需求和项目应用中存在一些当前技术无法满足的场合来看, 期望能够探索和预研利用通用服务器, 能够支持集群扩展, 且良好支持关系型 SQL 应用的技术及组件. 正因为这个原因, MPP 数据库应运而生.
MPP 的全称是 Massively Parallel Processing, 代表大规模并行计算数据库.
MPP 数据库技术介绍
MPP 数据库架构
MPP(Massively Parallel Processing)大规模并行处理系统是由许多松耦合处理单元组成, 每个单元内的 CPU 多有自己的资源, 如总线, 内存, 硬盘等. 在每个单元内都有操作系统和管理数据库的实例副本. 这种结构最大的特点在于不共享资源. 如图 1 所示, 完全不共享和完全对等不共享都属于 MPP 架构.
图 1 四种 MPP 架构
点击查看大图
MPP 架构的新型数据库在核心技术上和传统数据库相比有巨大差别, 是为了面向结构化数据分析设计开发的, 能够有效处理 PB 级别的数据量. 在技术上为很多行业用户解决了处理性能问题.
MPP 架构根据有无 Master 可以分为三类中心架构, 扁平架构以及联邦架构. 中心架构表示的是只有一个主 Master, 扁平架构是没有主 Master 节点, 所有的节点都是平等. 联邦架构表示的是有 2 个或者 2 个以上的 Master 节点. 注意, MPP 架构的数据库将逐步与 Hadoop 生态系统混搭使用, 用 MPP 处理 PB 级别的, 高质量的结构化数据, 同时为应用提供丰富的 SQL 和事务支持. 用 Hadoop 实现半结构化, 非结构化数据处理. 这样同时满足结构化, 半结构化以及非结构化数据的处理需求.
主流 MPP 厂商介绍
Teradata
Teradata 没有主节点的概念, 因此稳定性方面, 只要还有一个节点生存, 数据就不丢失, 只不过系统运行会变慢. Clique 是一个具有失效保护功能的节点的集合, Clique 里所有的节点必须能够存取 Clique 里所有 AMP 的虚拟磁盘. 如果一个节点失效, 所有的虚拟处理器将移动到 Clique 里其他的节点中, 每个节点能支持 128 个虚拟处理器, 每个 Clique 所能支持的最大虚拟处理器个数也不能超过 128 个.
对于数据分布策略, Teradata 只采用 HASH 算法, 分配过程完全自动进行, 不需要 DBA 干预, 这一点和其他的 OLTP DBMS 有很大的区别. 当重新配置 AMP 数时, 只需要变动 HASH MAP, 相应的数据会自动重新分配到新的 AMP 中去.
Povital Greenplum
GreenPlum 数据库是最先进的分布式开源数据库技术, 主要用来处理大规模的数据分析任务. GreenPlum 有一个 Master 节点, 所有查询, 修改操作都是通过 Master, 然后由 Master 转发给各个子节点.
阿里 HybridDB
阿里的云数据库 HybridDB for PostgreSQL 是一种在线分布式云数据库, 由多个计算组组成, 可提供大规模并行处理 (MPP) 数据仓库服务. HybridDB for PostgreSQL 基于 GreenPlum Database 开源数据库项目开发, 目前仅提供云商服务, 不支持线下部署, 闭源.
阿里在 2009 年左右开始使用 GreenPlum, 搭建了国内甚至全亚洲最大的 GPDB 集群. 2015 年 10 月 GreenPlum Database 由 Pivotal 开源后, 阿里云 PostgreSQL 内核团队便开始进行深度的调研, 于 2016 年开始进行产品的研发工作, 到 2016 年 7 月对用户开放公测邀请并准备正式商业化的工作, 目前产品已经正式上线.
HybridDB 融合了阿里的早期对于 GreenPlum 的使用运维经验, 增加了自动化运维及故障预警等多种监控项, 也对源码特别是在网络调度上进行了针对性优化, 提供跨网扩数据节点的吞吐能力, 优先支持 json 并且大幅提升检索性能.
HybridDB 在功能上的特色在于:
基于成熟的 GreenPlum 开源, 保证在 GreenPlum 上使用的数据, 迁移至 HybridDB 完全兼容, 并且提供了开源迁移工具.
支持多种混合数据类型, 特别是优化 json 支持, 提供 GIS 地理信息数据类型, HyperLogLog 预估分析数据类型.
支持混合的数据存储, 除了原有的行寸, 列寸, SSD/HDD 本地存储, 还增加了 OSS 云存储, 实现廉价的数据存储方案.
南大通用 GBase
南大通用提供 GBase 8a/8t/8m/8s/8d/UP 等多款自主可控数据库, 大数据产品. GBase8a 是分析型 MPP 数据库, 以大规模并行处理, 列存储, 高压缩和智能索引技术为基础, 具有满足各个数据密集型行业日益增大的数据分析, 数据挖掘, 数据备份和实时查询等需求的能力, 内核前期采用 MySQL 实现.
GBase8t 是支撑高端业务的事务型数据库; GBase8m 是 MPP 架构的全内存数据库, 采用多核, 多进程, 大内存, SSD 等硬件技术, 比同类内存数据库的性能有大幅度的提升; GBase eb 是一款软硬件一体化的企业级嵌入式产品.
多种数据库对比
我们对 MPP 数据库 (以 GreenPlum 为例) 与主流的关系型分布式数据库 (以 MariaDB 为例),NoSQL 数据库(以 HBase,Cassandra 为例) 进行对比, 如表 1 所示:
表 1 多种数据库对比
项目 | GreenPlum | MariaDB | HBase | Cassandra |
---|---|---|---|---|
开源协议 | Apache | GPLV2 | Apache | Apache |
分布式设计架构 | MPP 架构,中心化设计,有主节点,有单点备份 | 提供多主方式,互相之间通过日志备份数据 | 中心化设计,有主节点,横向扩展能力强 | 无中心化设计,支持横向扩展 |
分布式数据一致性 | 强一致性 | 强一致性,选择 CAP 原则中的 CP | 强一致性,0 数据丢失;可用性低;扩容方便,CAP 原则中的 CP | 一致性可配,当一致性级别为 ALL 时存在数据丢失肯恩;可用性高;扩容方便,选择 CAP 原则中的 AP
|
是否支持事务 | 支持分布式事务处理 | 支持原子化事务处理 | 不支持 | 支持轻量级事务性,当在同一个节点上时支持事务性 |
列定义 | 表结构固定,每一列代表一个字段 | 表结构固定,每一列代表一个字段 | 可随时添加字段,且不需要每一列赋值,可存储费结构化数据 | 可随时添加字段,且不需要每一列赋值,可存储费结构化数据 |
存储内容 | 关系型数据存储方式,也支持列存储 | 关系型数据存储方式 | 基于列存储 | 面向列存储,支持 key-value 存储 |
查询方式 | 支持各种复杂查询方式,可以通过建索引(无限制个数)扩展检索方式 | 支持各种复杂查询方式(弱于 Postgresql),可以通过建索引扩展检索方式 | 不支持条件查询,仅支持通过单个 row key 访问、row key 的 range 和全表扫描方式 | 支持有限度的复杂查询,例如支持集合查找、范围查找,支持 limit、order by(有限度),支持通过索引查找
|
备份复制方式 | 支持同步、异步、半同步复制,支持主备 | 基于行级数据同步复制,不会有数据丢失,而且在每个节点上都有完整的副本 | 基于 HDFS 方式 | 复制因子可配,当一致性级别为 ALL 时,不会丢失数据,否则可能存在丢数据风险 |
更新数据方式 | 更新原始行数据 | 更新原始行数据 | 通过时间戳(可自定义)起到版本控制作用,追加添加新的版本记录方式实现更新 | 通过时间戳起到版本控制作用,追加添加新的版本记录方式实现更新 |
主要用途 | 适用于中规模数据存储 | 不适合社交网络业务场景的数据库 | 适用于大量数据存储 | 适用于对象文件存储 |
GPDB 数据库
原理分析研究
GreenPlum 数据库 (后面简称 GPDB) 是一种基于 PostgreSQL 的分布式数据库, 可以通过标准 SQL 语句对 GPDB 中的数据进行读写访问.
GPDB 采用 Shared Nothing 架构, 主机, 操作系统, 内存, 存储都是自我控制, 不存在共享. 由 Master Host,Segment Host,InterConnect 三大部分组成.
Matser Host 不存储业务数据, 只存储数据字典. 它可以一主一备, 分布在两台机器上, 当主 Master 挂掉时, 由备 Master 接替主 Master.
Master 的主要职责有如下几点:
建立与客户端的会话链接和管理.
SQL 的解析并形成分布式的执行计划.
将生成好的执行计划分发到每个 Segment 上执行.
收集 Segment 的执行结果, 并将结果返回给客户端.
Segment Host 用于存储和读取业务数据, 每一台机器上可以配置多个 Segment, 而每一个 Segment 都是对等的. Segment 分为 Primary 和 Mirror 两种, 一般交错地存放在子节点上. 一旦 Primary 挂起后, 由 Mirror 接替 Primary.
Segment 的主要职责有如下几点:
执行由 Master 分发的 SQL 语句.
负责数据的存储和计算.
将读取和计算结果发给 Master.
InerConnect 模块承载了并行查询计划生产和 Dispatch 分发(QD), 协调节点上 QE 执行器的并行工作, 负责数据分布, Pipeline 计算, 镜像复制, 健康探测等诸多任务. 它是链接 Master Host 和 Segment Host 的唯一桥梁, 是整个架构中不可缺少的.
GPDB 采用 MPP 架构, 因此对大规模数据处理有着明显的优势, 具体体现如下:
支持海量数据的存储和处理. GPDB 同时使用多台机器并行计算, 极大地提高了对海量数据的处理能力, 理论上可以处理 PB 级规模.
支持线性扩展. GPDB 在扩展节点时操作简单, 在很短时间内就能完成数据的重新发布.
较好的并发支持以及高可用性支持.
支持数据库内压缩. GPDB 支持 3 种数据压缩方式, 在提高性能的同时, 显著地减少了存储数据所需要的空间.
支持多种索引功能. GPDB 目前支持 5 种索引, 分别为二叉搜索树, 哈希, 位图, GIST 和 GIN.
由于在 GPDB 的架构中, 有一个 Master 节点, 应用层的访问都需要通过 Master 进行分发, 因此 Master 节点是一个瓶颈. 具体如下:
不适合大并发, 实时性高的应用.
数据备份只有一份, 如果两份数据都丢失, 这个系统将不能再运行.
主节点挂起后, 由主备运行, 但是恢复主节点需要手动操作.
GPDB 为新一代数据仓库和大规模分析处理而建立的软件解决方案, 其最大的特点是不需要高端的硬件支持就可以支撑大规模的高性能数据仓库和商业智能查询, 在数据仓库, 商业智能的应用上, 尤其是在海量数据的处理方面 GPDB 表现出极其优异的性能.
GPDB 属于关系型数据库产品, 它的特点主要就是查询速度快, 数据转载速度快, 批量 DML 处理快. 性能可以随着硬件的增加呈线性增加. 因此, 它主要适用于面向分析的应用, 比如构建企业级 ODS/EDW, 或者数据集市等.
关键流程及原理
数据库的高可靠性是数据库产品核心要素之一.
主备节点机制
GreenPlum 主备流复制的核心部分由 WalSender,WalReceiver 和 StartUp 三个进程组成. WalSender 进程是用来发送 WAL 日志记录, WalReceiver 用来接收 WAL 日志记录, StartUp 进程是用来 Apply 日志的.
1. Primary 和 Mirror 同步机制
Primary 和 Mirror 同步的内容主要有两部分: 文件和数据. 之所以 Primary 和 Mirror 需要同步文件, 是因为 Primary 和 Mirror 之间可以自动 failover, 只有两者保持同步才能相互替代, 如果只把数据同步过去, pg_control,pg_clog,pg_subtrans 没有同步, 那么从 Primary 切换到 Mirror 会出现问题. GP Master 和 GP Slave 不用担心这些问题, Append Only 表的数据只会存在 Segment, 所以 WAL 日志足够保持 GP Master 和 GP Slave 同步(只要是流复制, pg_control,pg_clog,pg_subtrans 这些文件 Slave 会自动更新, 无需从 Master 同步).
2. 数据同步
当 GP Master 向 Primary 下发执行计划后, Primary 开始执行, 如果是 DML 操作, 那么 Primary 会产生 XLOG 及更新 page, 会在 SlruPhysicalWritePage 函数中 (写数据页) 产生 FileRepOperationOpen,FileRepOperationWrite,FileRepOperationFlush,FileRepOperationClose 等指令消息, 通过 Primary Sender 进程向 Mirror 发送 Message, 然后 Mirror 的 mirror consumer 等进程解析消息, 执行变更. XLOG 通过 XLogWrite 函数 (写 XLOG) 执行同样的操作, 把 XLOG 更新同步过去.
3. 文件同步
Primary 会有 Recovery 进程循环地把 Primary 的 pg_control,pg_clog,pg_subtrans 等文件覆盖到 Mirror. 同时检查 XLOG 是否一致, 如果不一致以 Primary 为主, 对 Mirror 进行覆盖. 除了把 Primary 部分文件同步到 Mirror 之外, Recovery 进程还会将 Mirror 上面的临时文件删除.
数据备份
每一个 Segment 都由 Primary Segment 和 Mirror Segment 两部分构成. 当一份数据插入时, 会分别在 Primary Segment 和 Mirror Segment 上各插入一份数据, 但是两份数据所处的位置需要满足两个条件:
两份相同的数据不能存放在同一台物理主机上.
两份相同的数据不能存放在同一个 Segment 上.
在数据库操作过程中, 只有 Primary Segement 是活跃的, Mirror 仅做复制处理. 当 Primary Segment 挂掉, 文件复制进程停止, Mirror Segment 自动成为活跃的 Segment Instance, 所有数据库操作则继续使用 Mirror. 此时记录事务的模式发生改变, 系统状态改为 Change Tracking 模式. 当管理员把失败 Segment 重新启动后, 恢复进程将两个至今的差异数据同步. 此时, 系统状态为 Resychronizing 模式. 一旦所有的 Mirror 和 Primary 都再次同步完成, 系统状态将变更为 Synchronized 模式. 注意, Primary Segment 挂掉会自动切换到 Mirror Segment, 但是 Primary Segment 恢复正常后不能自动切换到 Primary Segement, 需要手动切换.
故障检测及恢复
FTS(Fault Tolerance Serve)是 GreenPlum 中的故障检测服务, 是保证 GP 高可用的核心功能. GreenPlum 的 Segment 的健康监测及 HA 是由 GP Master 实现的, GP Master 上面有个专门的进程 - FTS 进程, 它可以快速检测到 Primary 或者 Mirror 是否挂掉, 并及时作出 Primary/Mirror 故障切换. 如果 FTS 挂掉了, Master 将会重新 fork 出来一个 FTS 进程.
GP Master 上面的 FTS 进程每隔 60s(时间可以配置)向 Primary 或者 Mirror 发送心跳包, Primary 和 Mirror 收到心跳后返回它们的当前状态, FTS 进程心跳包的发送状态和 Segement 返回状态更新元信息和作出故障切换. 因为 Segment 可能很多, 为了加快检测速度, FTS 是多线程的, 默认 16 个线程.
GPDB 的每个 Segement 都有一个镜像节点, 当主节点不可用时会自动切换到镜像节点, 以保持集群仍然可用状态. 当主节点恢复并启动之后, 主节点会自动恢复期间的变更. 只要 Master 不能连接 Segemen 实例时, 就会在系统表中将此实例表示为不可用, 并用镜像节点代替. 镜像节点一般需要和主节点位于不同的服务器上.
数据查询
查询数据的过程, 具体如下所示:
Client 端用户查询请求.
Master 解析和优化 SQL 语句, 把任务下发到每一个 Segment 上面.
每一个 Segment 并行独立地查询自己节点上的数据(包括 Table scan,join,aggregations,sort).
Segment 将查询的结果返回给 Master.
Master 将结果发送给用户.
GPDB 集群规模瓶颈分析
Master 中心瓶颈
GPDB 采用多节点并行计算方式来降低输出查询等操作的耗时, 而所有的操作任务的分发以及收集都是通过 Master 节点完成, 因此在大并发的应用下, Master 节点会成为整个集群的瓶颈. 随着集群规模变得太大, 业务数据太多时, MPP 的元数据巨大无比, 所以 MPP 数据库要在扩展性上实现质的提升, 就要对元数据, 以及数据存储等架构上有突破, 降低对一致性的要求, 这样扩展性才能提升.
节点之间大量数据通信网路带宽瓶颈
对于单次的数据操作, 随着 Segment 的增加理论上耗时应该呈线性下降, 但是 Segment 的增加直接增加了网络的负担. 对于一些数据操作, Segment 之间需要相互通信, 节点数越多, 通信的数据量越大, 因此在横向扩展方面, 网络带宽直接影响了集群的数量. 目前的官方文档配置都是推荐要求 10Gbps 及更高带宽配置.
节点内部磁盘 I/O 瓶颈
当 Segment 集群数量较小时, 同时存储的数据量较大, 对于单次查询操作, 观察磁盘 I/O, 发现磁盘 I/O 直线上升, 其效率直接影响了查询效率. 因此, 理论上磁盘性能越好, 对于整个集群的性能的提升越有利.
Postgres 集群与 GPDB 差异
一般的通用数据库都会提供集群的方法, 毕竟单机方式始终存在无法满足性能和存储空间扩展的需求弊端.
不同的集群扩展架构, 可能大致的设计目标都会相同, 架构需要满足可扩展且高可用的要求, 也就是能够通过增加节点机器方式提升数据库系统的对外服务能力, 同时在数据可靠性方面有一定的措施. Postgres 集群和 GPDB 架构对此两点均有涉及, 但是在实现原理上和特性表现存在不同. 接下来我们先从架构上进行探讨.
Postgres 架构原理
Pgpool-II 和 Postgres-XL 是 PG 集群开源实现中比较成功的两个项目, 尚不确定二者在企业生产环境中是否被广泛使用. 其中 Pgpool-II 的前身是 Pgpool-I,Postgres-XL 的前身是 Postgres-XC.
1. Pgpool-II
Pgpool-II 相当于中间件, 它位于应用程序和 PG 服务端之间. Pgpool-II 可以搭建在已经存在的任意版本的 PG 主从结构上, 主从结构的实现与 Pgpool-II 无关, 可以通过 slony 等工具或者 PG 自身的流复制机制实现.
除了主从结构的集群, Pgpool-II 也支持多主结构, 称为复制模式, 该模式下 PG 节点之间是对等的, 没有主从关系, 写操作同时在所有节点上执行, 这种模式下写操作的代价很大, 性能上不及主从模式. PG9.3 之后支持的流复制机制可以方便的搭建主从结构的集群(包括同步复制与异步复制), 因此 Pgpool-II 中比较常用的模式是流复制主从模式.
既然 PG 可以通过自身的流复制机制方便的搭建主从结构集群, 为什么还要在它上面搭建 Pgpool-II 呢? 因为简单的主从结构集群并不能提供连接池, 负载均衡, 自动故障切换等功能, Pgpool-II 正好可以做到这些, 当然负载均衡只针对读操作, 写操作只发生在主节点上. 为了避免单点故障, Pgpool-II 自身也可以配置为主从结构, 对外提供虚拟 IP 地址, 当主节点故障后, 从节点提升为新的主节点并接管虚拟 IP.
2. Postgres-XL
Postgres-XL 将 PG 的 SQL 解析层的工作和数据存取层的工作分离到不同的两种节点上, 分别称为 Coordinator 节点和 Datanode 节点, 而且每种节点可以配置多个, 共同协调完成原本单个 PG 实例完成的工作. 此外, 为了保证分布模式下事务能够正确执行, 增加了一个 GTM 节点. 为了避免单点故障, 可以为所有节点配置对应的 slave 节点. Postgres-XL 的 Coordiator 节点是整个集群的数据访问入口, 可以配置多个, 然后在它们之上通过 Nginx 等工具实现负载均衡. Coordinator 节点维护着数据的存储信息, 但不存储数据本身. 接收到一条 SQL 语句后, Coordinator 解析 SQL, 制定执行计划, 然后分发任务到相关的 Datanode 上, Datanode 返回执行结果到 Coordinator,Coordinator 整合各个 Datanode 返回的结果, 最后返回给客户端.
Postgres-XL 的 Datanode 节点负责实际存取数据, 数据在多个 Datanode 上的分布有两种方式: 复制模式和分片模式, 复制模式下, 一个表的数据在指定的节点上存在多个副本; 分片模式下, 一个表的数据按照指定的规则分布在多个数据节点上, 这些节点共同保存一份完整的数据. 这两种模式的选择是在创建表的时候执行 CREATE TABLE 语句指定的, 也可以通过 ALTER TABLE 语句改变数据的分布方式.
3. GPDB 集群
采用无共享存储架构, 由 master,segment 和 interconnect 三个基本组件组成. 其中 master 负责 sql 语句解析及优化, 事务执行, 以及数据均衡, 异常节点诊断等. Segment 内核就是独立的 PG 数据库内核, 负责数据的存储和监所执行. Interconnect 模块为虚拟的模块, 分散在各个 Segment 和 Master 协议机制中, 实现任意点对点之间互联, 配置并行执行语句的协同交互, 数据的实时备份, 数据快速导入导出等.
两种不同技术集群的差异对比如下表 2 所示:
表 2 不同技术集群的差异对比
项目 | Pgpool-II | Postgres-XL | MPP |
---|---|---|---|
实现机制 | 独立与 PG 的中间件。使用数据库读写分离方式 | 在 PG 的特定版本上改进实现;对 PG 的系统层次进行拆分进行扩展 | 底层 Segment 使用 PG 内核作为服务,可以兼容 PG 历史版本;采用无共享架构 |
适用场景 | 适合主从结构的小型集群;读写分离,扩展可提升读取的性能 | 适合较大规模集群 | 使用较大规模,线性扩展,可满足单机读写扩容的要求 |
功能 | 提供连接池、虚拟 IP 配置、负载均衡、自动完成故障切换的功能 | 多个 Coordinator 节点的需要使用其他的工具实现负载均衡故障切换,需要手动触发 | 数据均衡、请求不均衡,每个请求下发所有节点;并且一条 SQL 语句可以多节点并行;物理节点及逻辑数据偏备份高可用
|
数据分布 | 每一个节点一份数据,数据冗余分布 | 支持数据冗余分布,也支持分片式分布 | 数据切片分布,具有多种分配策略,Hash、随机等。数据片在另外的物理节点存在一个同步副本 |
存在的问题 | 写操作性能受限,没有单机 PG 的好 | 1. 无法使用任意版本 PG 需要版本匹配使用(Postgres-XL 9.5 R1.3 是基于 PG9.5 的) | 1. 对 PG 各个版本均支持; 2. 读写性能都能均衡提升,一定规模下是线性扩展的; 3. 节点扩展上执行 gpexpand 命令即可完成,所有表数据自动完成均衡 |
结束语
本文是针对 MPP(Massively Parallel Processing)数据库技术的初步技术, 产品介绍, 包括 MPP 数据库的发展及趋势, 多种数据库比对, 厂商分析等多方面概述知识介绍, 接着对主流的 GPDB 数据库进行原理分析, 关键流程解读, 特性分析, 并针对关系型数据库 PostgresSQL 与 GPDB 的差异进行了对比. 通过本文的阅读, 应该可以建立起对于 MPP 数据库的基本认识, 后续文章会针对 MPP 数据库进行深入技术解读.
参考资源
参考 developerWorks 上的 MPP 文章, 了解更多 MPP 知识.
评论
来源: http://www.ibm.com/developerworks/cn/opensource/os-lo-mpp-database-overview/index.html