GP 的计算实例，很多时候也叫 Segment Primary ： GP 的主计算实例 Mirror ： GP 的镜像计算实例 MPP ： 大规模并行处理 算子 ： 执行计划中的运算操作 背景简介 多年前，编者翻译了 GP4.2.2 的 AdminGuide，如今，GP 已经历经了无数个版 本更新和迭代，编者也有了更多的感悟，放眼 GP 的中文资料，为之动容，就想着再为 文件 ....................................................................................... - 35 - 限制并发连接数量 .............................................................................................. .................................................................................. - 168 - 关于 GP 的并发控制 ................................................................................................

这个核心软件组件。最终实现了对同一个集群中多 个 Postgresql 实例的高效协同和并行计算，Interconnect 承载了并行 查询计划生产和 Dispatch 分发（QD）、协调节点上 QE 执行器的并 行工作、负责数据分布、Pipeline 计算、镜像复制、健康探测等等诸 多任务。 在 Greenplum 开源以前，据说一些厂商也有开发 MPP 数据库的打算， 其中最难的部分就是在 Interconnect 每个节点上所有 Postgresql 实 例 都 是 并 行 工 作 的， 这 种 并 行 的 Style 贯 穿 了 Greenplum 功能设计的方方 面面： 外部表数据加载是并行的、 查询计划执行是并行的、索 引的建立和使用是并行的， 统计信息收集是并行的、表 关联（包括其中的重分布或 广播及关联计算）是并行的，排序和分组聚合都是并行的，备份恢复 也是并行的，甚而数据库启停和元数据检查等维护工具也按照并行方 超线程有很好的支持，提供更好的请求响应速度。在 PoC 中接触 到其它一些国内外基于开放平台的 MPP 软件，大都是建立在节点级的 并行，单个或少量的任务时无法充分利用资源，导致系统加载和 SQL 执行性能不高。 记忆较深的一次 PoC 公开测试中，有厂商要求在测试中关闭 CPU 超 线程，估计和这个原因有关（因为没有办法利用到多个 CPU core 的 计算能力，还不如关掉超线程以提高单 core

节点一般配置4~8个Instance，初始化完成后很 难修改，需要提前规划； • 每个Instance都是一套独立的进程，当客户端 发起一个请求时，每个Instance都将FORK子进 程并行工作； • 对于并发请求高、面向于复杂的灵活查询的系 统，建议每个Segment配置4个或以下Instance， 这样来保证每个Instance所需资源，保证系统 系统运行稳定性，例如，减少OOM发生的概率； • 询计划是cost base的，统计信息的准确性对查询 计划的优劣有很大影响；  对于字段数较多的表，可关闭gp_autostate_mode (on_no_stats=>none)，仅对必要列执行Analyze， 只在结果中返回的列无需收集统计信息；  对于频繁创建表删表的系统，可关闭gp_autostate_mode(on_no_stats=> on_change) ，数据变化量达 到一定阀值才收集统计信息； on_change – gp_autostats_on_change_threshold = 5000000（资料依据项目而定）  Truncate操作不会丢失字段级统计信息，在适当条件下可仅针对系统字段执行Analyze 垃圾空间回收 • GPDB采用MVCC机制，UPDATE 或 DELETE并非物理删除，而只是对无效记 录做标记； • Update/delete操作后，数据库不会自动释放这些空间，这些垃圾空间的回收方

事务中的操作要么全部正确执行，要么完全不 执行。 Write Ahead Logging，分布式事务：两阶段提交协议 Consistency 一致性 数据库系统必须保证事务的执行使得数据库 从一个一致性状态转移到另一个一致性状态。 （满足完整性约束） 实现对A、I、D三个属性的支持 Isolation 隔离性 多个事务并发地执行，对每个事务来说，它并 不会感知系统中有其他事务在同时执行。 多版本并发控制Multi-Version 多版本并发控制Multi-Version Concurrency Control、 两阶段加锁（Two Phase Locking, 2PL）、乐观并发控制 （OCC） Durability 持久性 一个事务在提交之后，该事务对数据库的改变 是持久的。 Write Ahead Logging + 存储管理 Jim Gray于1981年VLDB描述了事务的原子性、一致性和持久性，在此基础上，Hae 数据库管理系统组成图 Hector Garcia-Molina /Jeffrey D.Ullman/Jennifer Widom《数据库系统实现》 查询编译器/ 优化器 事务管理器 DDL编译器 执行引擎 日志和恢复 并发控制 索引/文件/ 记录管理器 缓冲区管理器 缓冲区 锁表 存储管理器 存储 查询计划 对索引、文件和 记录的请求 页命令 事务命令 查询、更新 用户/ 应用 DDL命令

............................................................................................. 10 并发控制优化 .............................................................................................. m 6 及未来发布的 Greenplum 7 丰富的 HTAP 特性，具备良好性能、可靠性和稳定性，使得 Greenplum 不仅可以作为全能的分析化平台，也能满足交易型业 务场景，能够处理多种并发混合工作负载，专为满足在多结构数据环境中进行实时分析的需求而设计。 欧拉开源操作系统是一款面向数字基础设施的操作系统，支持服务器、云计算、边缘计算、嵌入式等应用场景，支持多 样性计算，致力于提供安全、稳定、易用的操作系统。 15%-17%，值得一提的是此论文主要由中国研发团队完成，也说明了中国研发团队实力处于世界一流水平。在论文 中 Greenplum 团队提出一种全新的全局死锁检测器来减少独占锁的使用，减少独占锁的使用可以极大的提高数据库 在高并发状态下的性能，这项技术已经在 Greenplum6 实现。 在 Greenplum6 和即将发布的 Greenplum 7, 带来了多项产品改进和新增功能，这些功能提升了性能，增加了系统可

Ø实时，在线系统，客户使用 Ø事务小，频率高，并发高 • 过去的数据 —— OLAP Ø非实时（T+1，或小时级），离线系统，分析决策 Ø事务大，频率相对小，并发低 • 未来的数据 —— 趋势分析 Ø非实时，离线+在线流系统，趋势分析 Ø算法分析，持续计算 5 数据仓库体系架构 OLAP场景举例 • 业务相关场景 Ø用户状态 （注册数，活跃数，并发量，峰值） Ø金币状态 Ø道具/物品状态 10 greenplum体系架构 postgresql体系结构 11 greenplum体系架构 postgresql体系结构 • pg结构组成 Ø 连接关系系统 Ø 编译执行系统 Ø 存储执行系统 Ø 事务系统 Ø 系统表 • pg逻辑和物理结构 Ø instance实例 - user - tablesapce Ø database - schema - table,view Greenplum开发规范 五 Greenplum运维体系 四 Greenplum扩展规划 六 34 Greenplum开发规范 不规范容易出现的问题 • GP架构易出现问题 Ø 资源不足 Ø 连接、语句执行失败 Ø 多任务冲突 • 库表使用易出现问题 Ø 表定义过大 Ø 表类型单一 Ø 表的散列键不恰当 Ø 分区表的分区键性能不佳 • 加载易出现问题 Ø 文件加载出现特殊字符 Ø 数据校验标准问题

有云和私有云）中，也适用不同的本地配置。其大规模并行处理 (MPP) SQL 的设计核心是一个称为 GPORCA 的新一代查 询优化器。GPORCA 专为满足在多结构数据环境中进行高级分析的需求而设计，能够处理多种并发混合工作负载的复杂查 询。与旧式 MPP 数据库中常用的传统 RDBMS 查询优化器相比，GPORCA 大幅度地提高了查询性能。 Pivotal Greenplum 5：新一代数据平台 作为重要的新版本，Pivotal GREENPLUM 5：新一代数据平台 集成分析：改进后的全新分析接口 一直以来，客户都能在 Pivotal Greenplum 中做高级分析，无论是提供将应用逻辑向下推送至数据所在位置的方法，执行 分析功能，还是以大规模并行方式构建数据模型，都可以实现。Greenplum 5 支持适用于数据挖掘和数据科学工作的最全面、 最先进的分析程序包和扩展。 Greenplum 5 还针对最受欢迎的 Python 起，GPORCA 将成为默认查询优化器。它能够通过并发的混合工作负载处理多种复杂查询， 并可提高查询性能。2 这样一来，大型团队就可以利用高级分析和多元化工作负载并行处理多个分析用例，针对大型数据卷实现较高的分析查询 性能。GPORCA 的强大之处在于 能够以并行方式针对提交的 SQL 语句计算大量可能的查询计划。为了生成最快的计划，GPORCA 会计算数千种备选查询 执行计划，并根据成本做出决策。它还能免去

customer USING (cust_id) WHERE date=2008; 生成并行查询计划 8 Pivotal Confidential–Internal Use Only 执行并行计划 Standby Master … Master Host Interconnect Segment Host Node1 Segment Host Node2 Segment transaction processing - 联机事务处理 出色的OLTP特性 天生的优势 ● 行式存储 ● 索引 ● 直接分发 ● 完整的增删改 Greenplum 6 增强 ● 并发修改、删除 ● 系统性的优化事务和锁 26 Pivotal Confidential–Internal Use Only 行式存储 表‘SALES’ 表‘SALES’ ■ 更适合OLTP负载 ■ 支持更改删除、删除 ■ 支持更改分布键、主键（将数据从一个节点移到另一个节点） 30 Pivotal Confidential–Internal Use Only Greenplum 6：并发改删和分布式死锁检测 全局死 锁检测 gpconfig -c ‘gp_enable_global_deadlock_detector’ -v on 31 Pivotal Confidential–Internal

ve-schema-file灵活指定需要全量备份的某 个table或者某个schema，其中-s和-t选项不能同时使用 gpcrondump命令使用选项--incremental和--prefix执行增量备份，但是这里 的增量备份实际上只对有如下操作的表进行备份； ALTER TABLE DELETE INSERT TRUNCATE UPDATE DROP and then re-create the 年象行中国（杭州 站）第一期 gpcrondump具体实现(2/2) gpcrondump实际是对gp_dump的封装，具体步骤如下： 1. 读取参数，检测合理性 2. master执行对pg_class加锁操作 3. 封装并执行gp_dump命令 4. 检测每个segment备份状态 5. 其他操作，例如备份全局对象（角色和表空间）、 备份config文件、清理旧备份集以及VACCUM等 2017 gp_dump具体实现 2017 年象行中国（杭州 站）第一期 非并行数据恢复 如果恢复前后的数据库节点个数不同，则推荐使用非并行数据恢复，不过需要 保证备份集完整，而且都位于master所在的机器上，具体执行步骤如下 1.createdb database_name 2.psql database_name -f /gpdb/backups/gp_dump_1_1_20120714 3.$ psql database_name

（处理和存储） SQL 查询和 MapReduce程序 MPP （海量并行处理） “完全不共享”体系 Greenplum体系：并行数据流 21 • 通用并行数据流引擎可以通过本地方 式执行 SQL和MapReduce • 采用了针对商用硬件优化的MPP“完 全不共享”体系 • 可以在很多100s服务器上扩展到 1000s商用处理内核 • 将所有处理操作尽量移动到数据附近 计算内核 Greenplu m并行数 据流引擎 对本地磁盘进行直 接的高性能访问 gNet 互连 • 第一个支持互联网级分析技术（由Google普及）的产品 • 采用新的编程模型，在商用硬件上并行处理和执行 • 可以使客户洞察力和数据货币化程度达到前所未有的高度 MapReduce Greenplum MapReduce的优势 • 处理在任何地点存储的任何类型的数 据 • 将SQL的普遍性与MapReduce的灵 可以通过控制支持快速膨胀的数据集 “Greenplum将成为我们不可或缺的合作伙伴，因为我们需要不断更新数据操作方式，使用户和广告商 通过我们的工作网络中获得更好的印象。” - FIM受众网络技术和运营部门的产品执行副总裁 Arnie Gullov-Singh 24 净数据规模 (TB) 2008年9月 2008年12月 客户实例：Reliance Communications • 业务问题 • CDR安全合规性和分析