.................................................................................... - 270 - GP 安装条件 .................................................................................................. gpbackup 与 gprestore .......................................................................... - 329 - 条件与限制 ............................................................................................... ....................................................................................... - 364 - 升级条件 ..................................................................................................

gp_autostats_mode = on_change – gp_autostats_on_change_threshold = 5000000（资料依据项目而定）  Truncate操作不会丢失字段级统计信息，在适当条件下可仅针对系统字段执行Analyze 垃圾空间回收 • GPDB采用MVCC机制，UPDATE 或 DELETE并非物理删除，而只是对无效记 录做标记； • Update/dele 级压缩 • 数据压缩对于高并发查询分析系统可以大幅降低IO消耗，提升并行处理、混合负载的性能 分布键使用： • 尽量采用一个常用关联字段作为分布键，例如账号、客户号，这个可以提高关联条件的命中率，减少关联时数据重分布 （主要对大表） • 选用分布键同时考虑数据平均分布（一个例子，日志号不是最好的分布键，大量的空值导致资料倾斜） 物理模型经验分享（续） 分区表使用： • 以并发查询为主要功能，特别OLTP查询（根据KEY，Attribute等作为筛选条件）的系统按照常用字段建索引。 • 建索引的方法：对于区别度高的字段，如账号、手机号码等使用B-Tree索引，对于区别度低的字段（<10000),采用 Bitmap索引； • 表关联时，一般不需要建索引，如果where条件的筛选性很强，建立索引可以让系统性能提升 • 对于大数据类系统，应避免使用PK,UI

断的创新能力和资源，让产品保持持续旺盛的生命力。 这也是我们在用户选型时，通常建议用户考察一下底层的技术支撑 是不是有好的组织和社区支持的原因，如果缺乏这方面的有力支持 或独自闭门造轮，那就有理由为那个车的前途感到担忧，一个简单 判断的标准就是看看底下那个轮子有多少人使用，有多少人为它贡 献力量。 2) 为什么是 Postgresql 而不是其它的？ 我想大家可能主要想问为什么是 Postgresql Greenplum 中不到一个小时就加载完成了，而在用户传 统数据仓库平台上耗时半天以上。 在该用户的生产环境中，1 个数百亿表和 2 个 10 多亿条记录表的全表 关联中（只有 on 关联条件，不带 where 过滤条件，其中一个 10 亿 条的表计算中需要重分布），Greenplum 仅耗时数分钟就完成了， 当其它传统数据平台还在为千万级或亿级规模的表关联性能发愁时， Greenplum 已经一骑绝 再者，执行计划为什么会选择不够高效的方法，由于执行计划是基于 统计信息生成的，而统计信息不可能涵盖所有细节。通常，以下几中 情况会导致评估失真： 1) 过多的 WHERE 条件但并没有过滤很多数据。 2) 过多的 JOIN 条件但并没有真正降低匹配数据量。 3) 用重复率极底的字段做汇总。 因此，你需要很了解你的数据，这样才能达到优化的最高境界。 Big Date2.indd 44 16-11-22

No-force ● redo log，没有undo log，事务回滚不需要做undo操作 • PG采用的是MVCC，更新操作不是in-place update，而是重新创建tuple， 可见性判断 • Robert Haas 2018, “DO or UNDO - there is no VACUUM”: zheap, in-place update PostgreSQL和Greenplum采用的策略 QD向QE发起两阶段提交 • 分布式快照 • QD向QE发送全局快照信息 • Writer QE和Reader QE共享本地快照信息 • distributed log：分布式事务提交日志 • 用于判断分布式事务是否提交，作用和PG 的commit log类似，基于simple LRU实现 • 分布式死锁检测 • 本地事务的管理：创建、提交、状态迁移 等 • 加锁和MVCC • 本地事务的死锁检测

'2017-01-01') EXCLUSIVE EVERY (INTERVAL '1 day')， DEFAULT PARTITION error ); 如果输⼊的数据不满⾜分区的 CHECK 约束条件，并且没有创建默认分区，数据将被拒绝插⼊。 默认分区能够保证在输⼊数据不满⾜分区时，能够将数据插⼊到默认分区。 场景五：为每个分区指定独⽴的名： CREATE TABLE p_store_sales( 增加默认分区（⼀般不建议使⽤默认分区）： ALTER TABLE p_store_sales ADD DEFAULT PARTITION other; 如果输⼊的数据不满⾜分区的 CHECK 约束条件，并且没有创建默认分区，数据将被拒绝插⼊。默认分区能够保证在输⼊数据不满⾜分区时，能够将数据插⼊到默认分区。 如果分区表中包含默认分区，您必须通过分裂默认分区的⽅式来增加新的分区。在使⽤ INTO ] 命令: CREATE RULE 描述: 定义⼀个新的重写规则 语法: CREATE [ OR REPLACE ] RULE 名字 AS ON 事件 TO 表 [ WHERE 条件 ] DO [ ALSO | INSTEAD ] { NOTHING | 命令 | ( 命令 ; 命令 ... ) } 命令: CREATE SCHEMA 描述: 定义⼀个新的模式

也可以单独使用 • 可以被定义为任务，定时调度执行 异构平台环境下初始化同步 8 • 非侵入式技术对生产没有影响 • 基于日志捕获技术的实时性非常高 • 支持从过去的某一指定时间开始捕获 • 条件过滤 • 支持触发器捕获技术作为补充 基于数据库事务日志的变化数据捕获 9 • 避免人为错误 • 在迁移结束前校验数据 • 支持异构 异构平台间数据校验域修复 10 内置监控与报警

对于Greenplum上的架构和设计不断优化 Ø 继续建设多样化的postgresql数据集市，满足不同需求 • 优化现有业务的调度实现 Ø 时间周期的考量 Ø 并发与功能实现的权衡 Ø 增强任务可控性和可度量性 • 支持符合条件的新业务 Ø 抽象业务模型，整合使用分类 Ø 简化上线模型，优化上线方式 40 Greenplum扩展规划 新业务上线流程 • 把握三个方面，解决三个问题 Ø 确认数据来源与传输，解决原始数据从那里来的问题

后发送至 Coordinator 节点并返回给客户端用户。 分布式查询优化器 l 对于普通查询，只需要将 Segment 上的数据汇总即可，如果有 filter， 则在 segment 上执行条件过滤 l 对于 JOIN，我们需要考虑两张表的分布键以及分 布策略。若分布键和分布策略不同，就需要对数据 进行节点间移动 Confidential │ ©2021 VMware, Inc. 17

性能可达到传统方案（Oracle、Teradata）的 10到100倍， 而成本只是其一小部分 – 可伸缩性：从较低的万亿字节扩展到千万亿字节 – 开放式系统：在通用系统和开放源软件的基础上创建 前提条件 – 硬件：基于开放式标准硬件 – 软件：Postgres和Greenplum – 体系架构：海量并行处理体系，针对商务智能/数据仓库 进行了优化，解决了所有数据流瓶颈问题 Greenplum数据引擎

现代数据分析和商业智能 (BI) 生成的 SQL 查询往往带有相关子查询，内部子查询需要外部查询的相关知识。GPORCA 可 以生成不相关的计划，这种计划只需查询一次。随后，系统将中间结果与主表结合，生成符合用户条件的结果集。借助上 述及其他优化方法，经过 GPORCA 优化的 SQL 查询可实现 10 倍甚至更大幅度的速度提升。但是，也有其他一些查询（尽 管数量不多）尚且无法通过 GPORCA 实现性能提升。随着