行，不管其所 在的资源队列如何限制。 内存限制如何工作 在资源队列上设置的内存限制使得每个Instance上该资源队列能够使用的内存 总和不能超过设定的最大值。每个查询语句分配的内存大小是资源队列的内存限制除以 最大活动语句数量(建议与活动语句数限制结合使用，而不是与cost限制结合使用，如 果是与cost限制结合使用，将按照cost的权重进行分配)。例如，资源队列的内存限 制为2 ZSTD 为 1~19 级可选 ZLIB 为 1~9 级可选 QUICKLZ 仅 1 个级别可选(缺省不需指定) RLE_TYPE 为 1~4 级可选 BLOCKSIZE 表的存储块大小 8192 ~ 209715(8K ~ 2M)该值必须是 8192 的 倍数 对列存表单独的字段使用存储参数的格式如下： [ ENCODING ( storage_options Database 管理员指南 V6.2.1 版权所有：Esena(陈淼 +86 18616691889) 编写：陈淼 - 109 - ENCODING的情况下，该字段将不会使用压缩存储，而块大小使用系统配置参数 block_size指定的值，此时，该字段的存储属性，与普通AO表一致。 列级压缩设置的优先级 COLUMN的压缩设置通过TABLE向分区再向子分区传递。在越低级别的设置具有越

QD 从QE归集结果，返回给客户端 Confidential │ ©2022 VMware, Inc. 14 分布式执行和事务 Ø MVCC q Xmin, Xmax 是节点本地的 Ø 分布式快照 q QD生成，下发给QE q segment本地事务异步两阶段提交，保持一致性 Ø HTAP 优化 q 全局死锁检测 q 只读事务、只涉及到某个节点的操作、vacuum Ø SIGMOD int, sdate date, amt numeric) DISTRIBUTED BY (id) PARTITION BY RANGE(sdate) ... Ø Heap: 源自PG，固定页面 大小, 适合OLTP Ø Append Optimized: 没有 页面的概念，变长，行存、 列存、压缩，适合OLAP Ø 外部表: HDFS，S3，文件， 网络，命令，流式数据… Confidential

32 Greenplum实现分布式事务与并发控制 • 分布式事务管理 • 分布式事务的创建、状态迁移等 • QD向QE发起两阶段提交 • 分布式快照 • QD向QE发送全局快照信息 • Writer QE和Reader QE共享本地快照信息 • distributed log：分布式事务提交日志 • 用于判断分布式事务是否提交，作用和PG 的commit log类似，基于simple 33 分布式事务信息在QD和QE之间的同步 MyTmGxact: TMGXACT 分布式事务结构体 • 分布式事务id • 分布式事务管理器启动的时间戳 • 活跃分布式事务中最小的事务id，分布式快照 • session id 34 Greenplum的两阶段提交函数调用关系 35 ● 事务的实现原理和Write Ahead Log（WAL） ● 分布式事务和两阶段提交的原理 ● Greenplum两阶段提交协议的实现

载到内存，当内存用满时，执行快速排序等内排序算法，生成一个顺串。之后清 空内存，继续读取外存数据，如此反复，直到所有外存数据处理完毕。该算法生 成的每一个顺串的大小都不会超过内存的大小，而顺串越小，合并阶段的代价 就越高，需要读取外存的次数也越多，有没有办法在分割阶段就生成大于内存 大小的顺串呢？ 归并排序的三个问题 23 替换选择算法 24 Knuth 5.4.1R替换选择算法： ● 1. 初始化阶段，读取输入元组至内存，并建立最小堆。 读取新元组，如果元组排序键大于等于lastkey，插入堆顶，并调整堆，使其有 序。 ● 4. 如果新元组排序键小于lastkey，将该元组放入堆尾，并将堆的大小减1。 ● 5. 重复第2步，直至堆大小变为0。 ● 6. 顺串生成完毕。将堆大小重置为N，并重新建堆。重复第2步，开始生成下一 个顺串。 替换选择算法 25 ● 问题二：合并阶段假设存在N个输入缓冲区，如何高效的比较N个输入缓冲区的

Greenplum 6里引入了numsegments ▪ Numsegments描述了该表连续分布的segment数量，默认与集群大小一致。对每个 表执行操作时也会按照numsegment值分配Gang ▪ 增加新节点后，对每个表做EXPAND后该值会随着改成新集群的大小 改进与实现 改进与实现 • EXPAND每个表 – 对表加最高级别锁（其他读写均被阻塞） – 移动数据到新节点 – 修改numsegments 改进与实现 • 减少重分布数据移动量 – Jump Consistent Hash ▪ 均匀性：通过概率做到均匀分布 ▪ 稳定性：在相同集群大小下，同一个Tuple每次计算结果相同 ▪ 单调性：扩容过程中，旧节点之间没有数据迁移 ▪ 高效性：对于集群大小为N的时候，时间复杂度为Log(N) – 更多算法细节请参考链接。https://arxiv.org/pdf/1406.2294.pdf – 通过GUC

白皮书 8 白皮书 | 8 • 嵌入式：发布面向嵌入式领域的版本 openEuler 21.09 Embedded，镜像大小<5M，启动时间<5S。 4. 繁荣社区生态 友好卓面环境：UKUDDEXfce 卓面环境，丰富社区卓面环境生态。 • 欧拉 DevKit：支持操作系统迁移、兼容性评估、简化安全配置 Amazon Web Services、Microsoft Azure 和 Google 云平台上运行，也可以运行在国内云平台上，如阿里云、 腾讯云等，只需选择要在群集中调配的数据节点数量（不超过预定义的最大大小），然后选择一系列部署选项，群集 便会立即启动运行，可供客户使用，国内外有相当数量的客户已选择云上 Greenplum。 图 2：Greenplum 不受限于基础架构的软件架构 三中心数据中心来说，保证完全同步的开销是很难接受 的，针对这种情况，Greenplum 7 版本采用了多个集群间异步的方式来处理，来确保数据同步。这样备份集群和主 集群之间可能会存在延迟，延迟的大小是由传输管道的带宽决定的，但在大部分使用场景下，这样的延迟是可以接受 的。 图 3：Greenplum 多站点复制 Master 节点自动 Failover Greenplum

RPMSAS 盘，采用 RAID5 或者 RAID10，需要预留单独 的 hotspare 盘），CPU 2 路 8 核及以上（主频 2.5G HZ 以上），1 块 RAID 卡（要求 cache 大小 1GB 以上，并带有掉电保护功能） 3. 计算节点服务器 由于计算节点真正的负责计算， 计算节点的硬件性能直接影响到整体 集群的性能，Greenplum 建议单个集群最开始搭建的时候最好选用相 盘，采用 RAID5 或者 RAID10，需要预留单 独的 hotspare 盘），CPU 2 路 8 核及以上（主频 2.5GHZ 以上），1-2 块 RAID 卡（单块 RAID 卡的 cache 大小 1GB 以上，并带有掉电保护 功能，RAID 卡应为多通道，目前接触的硬件厂商中，单通道支持的最 大磁盘数为 16 块） ·硬盘尽量选 用 SAS 盘，从实践经验看，硬盘故障是 Greenplum 900GB 10K RPM SAS 盘，采用 RAID5 ，预留 hotspare 盘），CPU2 路 6 核以上（主频 2G HZ 以上），1 块 RAID 卡（单块 RAID 卡的 cache 大小 1GB 以上，并带有掉电保护功能 ）。 ·ETL 服务器最好和 Greenplum 接入相同的二层交换机，如果跨交 换机，确保网络不存在性能瓶颈。 ·ETL 服务器网卡尽量选用万兆网卡，某香港航空公司曾抱怨

master segment 虚拟机类型 n1-standard-16 n1-standard-8 CPU核数 16 8 内存大小（GB） 60 30 CPU平台 Intel Haswell 存储类型 SSD persistent disk 存储大小（GB） 512 Linux发行版 Ubuntu Linux 18.04 Linux内核版本 4.15.0 GCC版本 7.3.0

Vacuum：标记垃圾空间为可再利用 Vacuum用于将数据表垃圾空间标记到FSM（自由空间映射），一般也不回收空间，当往该表插入新数据时，数据库会重 新这些空间。 FSM驻留在内存中，FSM的大小必须足够标记数据库中的所有过期记录。如果尺寸不够大,超出自由映像空间的过期记录 占用的空间将无法被VACUUM命令标记。可通过修改max_fsm_pages、max_fsm_relations放大这些参数 本参数为4.2.8以上版本增加，防止临时空间SPILL档数过多导致空间急剧增长 视图gp_workfile_usage_per_query可以实时监控每个query正在使用的临时空间大小 注：在GP4.3中内置了这个view，在GP4.2中需要执行./share/postgresql/contrib/gp_workfile_mgr.sql 临时空间的监控和管理 

Confidential │ ©2021 VMware, Inc. Brin on AO Storage Upper Level：定长数据段，约为3.2MB RevMap：变长数据段，大小随数据表数据 量变化，向后增长 BrinTuples：存放Min Max的数据段，Page 结构和Heap Page相同 22 Confidential │ ©2021 VMware, Inc