Instance 文件有损毁， 将需要全量恢复或者需要选择全量恢复。在 6 之前的版本，GP 的 Primary 和 Mirror 之间采用的是 filerep 的方式进行 block 级别的变化同步的机制，从 6 版本开始， 使用 WAL 复制，这将可以从根本上解决以往的 block 损毁被复制到 Mirror 上的问题， 也不再需要 persistent 系统表了(这个的确是一个让人很头疼的设计)。 生变化，就会自动同步到 Standby 从而保证与 Master 的一致性，所以，Standby 与 Master 可以保持实时同步。在 6 之前的版本，Master 与 Standby 的同步机制就 一直是 WAL 同步，而在 6 版本开始，Primary 和 Mirror 也采用了 WAL 同步，但由 于 Mirror 需要同步的 WAL 日志的量很大，所以，对性能的影响比 Standby 为 2395 的查询： =# SELECT pg_cancel_backend(2395); 还可以为 pg_cancel_backend()函数提供一个可选的消息参数，用于通知该查 询的 ROLE，告知为何终止了其执行的事务。例如： =# SELECT pg_cancel_backend(2395,'因系统维护暂停使用'); 该事务的 ROLE 会收到如下信息：

数 据库实例同时开展并行计算。而且，这些 Postgresql 之间采用 share- nothing 无共享架构，从而更将这种并行计算能力发挥到极致，除此之 外，MPP 采用两阶段提交和全局事务管理机制来保证集群上分布式事 务的一致性，Greenplum 像 Postgresql 一样满足关系型数据库的包括 ACID 在内的所有特征。 从上图可以看到，Greenplum 的最小并行单元不是节点层级，而是在 ·行、列混合存储 ·数据表多级分区 ·Bitmap 索引 ·Hadoop 外部表 ·Gptext 全文检索 ·并行查询计划优化器和 Orca 优化器 ·Primary/Mirror 镜像保护机制 ·资源队列管理 ·WEB/Brower 监控 Big Date2.indd 7 16-11-22 下午3:38 8 3. Greenplum 的艺术 -- Parallel Everything 按照我们在用户现场观察到的，Master 上的资源消耗很少有超过 20% 情况发生，因为 Segment 才是计算和加载发生的场所（当然， 在 HA 方面，Greenplum 提供 Standby Master 机制进行保证）。 再进一步看，Master-Slave 架构在业界的大数据分布式计算和云计 算体系中被广泛应用，大家可以看到，现在主流分布式系统都是采 用 Master-Slave 架 构， 包 括：Hadoop

Confidential–Inter nal Use Only 平台概况 产品特性 客户端访问和工具 多级容错机制 无共享大规模并行处理 先进的查询优化器 多态存储系统 客户端访问 ODBC, JDBC, OLEDB, etc. 核心MPP 架构 并行数据流引擎 高速软数据交换机制 MPP Scatter/Gather 流处理 在线系统扩展 任务管理 服务 加载 & 数据联邦 高速数据加载 本地存储 主节点Segment 系统表 分布式事务 Interconnect 执行器 解析器 主节点上的分布式 事务管理器协调 Segment上的提交和 回滚操作 Segments 有自己的 事务日志，确定合 适提交或回滚自己 的事务 主节点 Segment 实例 本地事务 执行器 系统表 本地存储 Segment 主机 Segment 实例 执行器Executor

shold = 5000000（资料依据项目而定）  Truncate操作不会丢失字段级统计信息，在适当条件下可仅针对系统字段执行Analyze 垃圾空间回收 • GPDB采用MVCC机制，UPDATE 或 DELETE并非物理删除，而只是对无效记 录做标记； • Update/delete操作后，数据库不会自动释放这些空间，这些垃圾空间的回收方 式： 1）Vacuum 常用可选参数：-a：直接停止，不提示终端使用者输入确认 -m：只停止master实例，与gpstart –m对应使用 -M fast | -f：停止数据库，中断所有数据库连接，回滚正在运行的事务  -u：不停止数据库，只加载pg_hba.conf 和postgresql.conf 中运行时参数，当改动参数配置时候使用。  -r： 重启数据库 Admin常用命令

Report 结算 系统 呼叫 中心 航线 分析 结算 系统 呼叫 中心 其他 航线 分析 结算 系统 呼叫 中心 BO报表响应速度 BO报表响应速度测试： 报表名 Oracle查 询时长 Greenplu m查询时 长 GP提升倍数 备注 报表一： 查询09年1月份数据 无法响应 查询 30秒 N 基于查询 语句 SQL1 报表一： 查询09年5月份数据 49秒 N 本项测试的目的是通过SQL查询检验Greenplum数据库引擎处理Query计算的响应 速度。 测试方法：针对数据加载测试中的三张大表，模拟生产业务需求进行复杂SQL语句查 询(参看附录)。 测试结果如下面两表： 语句名 Oracle查 询时长 Greenplu m查询时 长 GP提升倍数 备注 SQL1 1800秒+ 33.16秒 54X+ SQL2 A 1800秒+ 17.49秒 105X+

部署在多云环境（公 有云和私有云）中，也适用不同的本地配置。其大规模并行处理 (MPP) SQL 的设计核心是一个称为 GPORCA 的新一代查 询优化器。GPORCA 专为满足在多结构数据环境中进行高级分析的需求而设计，能够处理多种并发混合工作负载的复杂查 询。与旧式 MPP 数据库中常用的传统 RDBMS 查询优化器相比，GPORCA 大幅度地提高了查询性能。 Pivotal Greenplum ETL 和报告处理）都能不间断运行。 架构化查询语言性能提升 Pivotal Greenplum 5 对 SQL 查询处理进行了多项改进。广受欢迎的 SQL 结构——相关子查询（即嵌套在另一查询内的查 询）可使用来自外部查询的值。鉴于业界各大 BI/ 报告工具对子查询的广泛使用，这可以说是 GPORCA 中最重要的一项改 进了。在一些大型数据集中，对于外部查询所处理的每一行，系统都要对子查询进行一次计算，因此执行过程可能极为漫长。

有更好的性能，但是怎么保证事务的原子性和持久 性？ ❏ No-Force: 事务提交，所修改的数据页没有刷回至持久存储，如果发生断电 或者系统崩溃。 ❏ Steal: Buffer Pool中未提交的事务所修改的脏页刷回到持久存储，如果发生 断电或者系统崩溃。 缓冲区管理策略 14 ■ No-Force → Redo Log 事务提交时，数据页不需要刷回持久存储，为了保证持久性，先把Redo Log写 入日志文件。Redo and Isolation Exploiting Semantics, 1993, IBM DB2 19 ● Steal + No-force ● redo log，没有undo log，事务回滚不需要做undo操作 • PG采用的是MVCC，更新操作不是in-place update，而是重新创建tuple， 可见性判断 • Robert Haas 2018, “DO or

Segment 3D UPDATE orders SET cust_id = 2 WHERE id = 2； 29 Pivotal Confidential–Internal Use Only 完整的增删改查 表‘SALES’ 表‘SALES’ ■ 读和写不阻塞 ■ 支持更改删除、删除 ■ 支持更改分布键、主键（将数据从一个节点移到另一个节点） 30 Pivotal Confidential–Internal

portal – SQL结束不一定释放slot – 一个事务用光所有slot 2017 年象行中国（杭州 站）第一期 Resource Queue • System PANIC – 需要睡眠/唤醒机制 – Count + LWLock + Lock • Count：记录并发数 • LWLock：保护count • Lock：睡眠/唤醒，死锁检测，状态报告 – 维护Lock在共享内存的状态 –

存储计算分离 ○ PV持久化存储资源 ○ StatefulSet/Pod弹性扩展计算资源 ● 数据库服务层 ○ Service统一Master & Standby Master地址 ● 服务发现机制 ○ 所有节点地址名不变 ● 跨云能力 ○ 容器应用对基础设施透明 Greenplum Operator Kubernetes Operator ● 自定义资源类型 ○ Custom Resource