CPU 超线程有很好的支持，提供更好的请求响应速度。在 PoC 中接触 到其它一些国内外基于开放平台的 MPP 软件，大都是建立在节点级的 并行，单个或少量的任务时无法充分利用资源，导致系统加载和 SQL 执行性能不高。 记忆较深的一次 PoC 公开测试中，有厂商要求在测试中关闭 CPU 超 线程，估计和这个原因有关（因为没有办法利用到多个 CPU core 的 计算能力，还不如关掉超线程以提高单 与其他所有关系型数据库一样，拥有一套管理数据库内 部对象及关联关系的元数据表，我们称之为 Greenplum 系统表。 Greenplum 的产品内核是基于 postgresql 数据库基础上开发完成的， 因此，Greenplum 系统表很多继承于 postgresql 数据库。 Greenplum 的系统表大致可分为这几类： 1) 数据库内部对象的元数据 如：pg_database、pg_na 如：pg_database、pg_namespace、pg_class、pg_attribute、pg_ type、pg_exttable 等。 这类系统表既涵盖了全局的对象定义，也涵盖了每个数据库内的各 种对象定义。这类系统表的元数据不是分布式的存储，而是每一个 数据库实例（不论是 master 实例还是 segment 实例）中都各有一 份完整的元数据。但也有例外，如：gp_distribution_policy（分布 键定义）表则只在

........................................................................................ - 27 - 管理对象权限 ................................................................................................ ................................................................................. - 79 - 第七章：定义数据库对象 .................................................................................................. ............................................................................... - 89 - 使用表空间存储 DB 对象 ......................................................................................... - 90 - 查看现有的表空间和文件空间

Workbench/J是⼀个独⽴于DBMS，跨平台的SQL查询分析⼯具。具有通⽤性好、⼩巧、免安装等优点， 并且功能强⼤，查询编辑器⽀持⾃动补全，Database Explorer可以查看和编辑各种数据库对象（表、视图、存储过程等）。 详情可⻅：SQL Workbench/J 访问 udw 访问UDW数据仓库 Greenplum数据仓库 UDW Copyright © 2012-2021 UCloud DATABASE product; 3、模式管理 、模式管理 数据库模式(schema)是包含了⼀系列数据库对象（表，数据类型，⾃定义函数）集合的命名容器。⼀个数据库可以有多个模式。不同模式不共享命名空间。public 模式是在创建数据库之后就 会默认创建的，每个⽤⼾都有权限在这个 schema 创建对象，如果不指定 schema 那么就会默认创建到这⾥。 创建⼀个模式: CREATE SCHEMA 做哈希分布。 为了尽可能的并⾏处理数据，需要选择能够最⼤化地将数据均匀分布到所有计算节点的策略，⽐如选择 primary key；分布式处理中将会存在本地和分布式协作的操作，当不同的表使⽤相 同的分布键的时候，⼤部分的排序、连接关联操作⼯作将会在本地完成，本地操作往往⽐分布式操作快很多，采⽤随机分布的策略⽆法享受到这个优势。 开发指南 Greenplum数据仓库 UDW Copyright © 2012-2021

随机分布的方式。 随机分布与复制分布 复制分布则表示整张表在每个节点上都有一份完整的拷贝，假设我们有 100 个节点，复制表则会将 数据保存 100 份。复制表可避免生成分布式查询计划，而是生成本地计划，从而避免数据在集群的 不同节点间移动。 Confidential │ ©2021 VMware, Inc. 12 除了支持数据在不同的 segment 节点上水平分布以外，还支持在单个节点按照不同的标准进行分 │ ©2021 VMware, Inc. 13 Greenplum 支持多态存储，即单张用户表，可以根据访问模式的不同而使用不同的存储方式存储 不同的分区。例如根据数据的新、旧程度决定将数据存储至本地硬盘还是以外部表的方式存储在 HDFS 或者是 S3 中。Greenplum 提供以下存储方式: l 堆表 (Heap Table)：默认存储方式，同时也是 PostgreSQL 的默认存储方式。支持高效的更新 QD/QE/火山模型/Gang Confidential │ ©2021 VMware, Inc. 25 Greenplum，或者说 PostgreSQL 是进程模型，而不是类似于 MySQL 的线程模型。 主进程 postmaster 是整个数据库实例的总控进程，负责启动和关闭数据库实例。当客户端和 Coordinator 建立连接时，postmaster 会 fork 出一个子进程来为该连接提供服务。

的核心特征，及多年来围绕该平台发展出的生态系统。 摘要 Pivotal Greenplum 不受限于基础架构，这意味着它是一种可完全移植的分析数据库软件解决方案，可部署在多云环境（公 有云和私有云）中，也适用不同的本地配置。其大规模并行处理 (MPP) SQL 的设计核心是一个称为 GPORCA 的新一代查 询优化器。GPORCA 专为满足在多结构数据环境中进行高级分析的需求而设计，能够处理多种并发混合工作负载的复杂查 PostgreSQL 新增功能。 新一代 数据平台 IT 人员 开发 人员 业务 分析师 数据 科学家 灵活 部署 数据源和数据管道 Spring Cloud Data Flow ETL 本地存储 HDFSS 云对象 存储 GemFire Spark 其他 RDBMSes 多结构数据 PIVOTAL GREENPLUM 平台 原生接口 分析应用 用户 JDBC、OBBC Teradata Python. R、 Java、Perl、C Apache SOLR PostGIS ANSI SQL 其他数据库 SQL ML/统计数据/图形 程序化 文本 地理空间 公有云 私有云 完全 托管云 本地 BI / 报告 自定义应用 机器学习 AI SQL 大规模 并行处理 (MPP) PB 级数据 加载 查询 优化器 (GPORCA) Workload Manager 多态存储 Command

简称“欧拉”）编译测试了高级分 析数据平台 Greenplum，用实践证明了 Greenplum 与支持多样性计算的欧拉开源操作系统完全兼容，是 Greenplum 与中国本地 IT 厂商的深入合作的典型模板，大大丰富了中国本地国产化应用生态。本白皮书着眼介绍了欧拉开源操作系 统平台架构、创新性及核心特点， 同时介绍了 Greenplum 作为一款深受技术爱好者喜爱的、中立的纯开源软件，践行 “Run 成功测试运行所做努力贡献的人员表示感谢！ 摘要 Greenplum 不受限于基础架构，这意味着它是一种可完全移植的分析数据库软件解决方案，可部署在不同操作系统、 不同芯片的环境，适合本地部署、多云环境（公有云和私有云）中。Greenplum 6 及未来发布的 Greenplum 7 丰富的 HTAP 特性，具备良好性能、可靠性和稳定性，使得 Greenplum 不仅可以作为全能的分析化平台，也能满足交易型业 式等应用场景，支持多 样性计算，致力于提供安全、稳定、易用的操作系统。 Greenplum 与欧拉开源社区强强联手，不仅是双方业务用户所期盼的，同时也是 Greenplum 社区与对中国本地开源社 区的深入合作尝试。本次合作对双方打造丰富应用生态注入了鲜活动力！ 完全兼容欧拉开源操作系统的 HTAP 数据平台 Greenplum

事务提交时，数据页不需要刷回持久存储，为了保证持久性，先把Redo Log写 入日志文件。Redo log记录修改数据对象的新值(After Image, AFIM) ■ Steal → Undo Log 允许Buffer Pool未提交事务所修改的脏页刷回到持久存储，为了保证原子性， 先把Undo Log写入日志文件。Undo Log记录修改数据对象的旧值(Before Image, BFIM) Solution: Logging QD向QE发送全局快照信息 • Writer QE和Reader QE共享本地快照信息 • distributed log：分布式事务提交日志 • 用于判断分布式事务是否提交，作用和PG 的commit log类似，基于simple LRU实现 • 分布式死锁检测 • 本地事务的管理：创建、提交、状态迁移 等 • 加锁和MVCC • 本地事务的死锁检测 • xlog、commit log(CLOG)

容器化MPP数据库 AGENDA 云数据库背景 云数据库实现方案 Greenplum on Kubernetes Greenplum Operator 总结 云数据库背景 云数据库背景 ● 资源变化 ○ 本地资源 → 云 ○ 静态资源 → 弹性需求 ● 数据变化 ○ 内部数据 → 多数据源 ○ 数据规模 → 不易预测 ○ 数据格式 → 半结构化/无模式 ○ 数据隔离 → 数据共享 ● 云数据库市场巨大 Mode ● 容器化数据库+Kubernetes ○ Apache Spark ○ CockroachDB ○ Apache HAWQ 云数据库存储方案 ● 块存储 ○ 文件系统接口 ● 对象存储 ○ 成本低 ○ 扩展性强 ○ 访问延迟高 Greenplum on Kubernetes Network Interconnect Standby Host Master Host Primary Segment部署策略 ○ Mirror Segment部署策略 ● 容器化Greenplum运维管理 ○ 故障检测及恢复 ○ 升级扩容 ● 容器化Greenplum存储管理 ○ 容器本地存储易失性 容器化Greenplum ● 容器粒度 ○ Segment主机 VS. Segment实例 ● 容器资源分配 ○ CPU ○ 内存 ○ 磁盘 ● 容器间网络互联 ○ 本机网络

优化器 本地存储 主节点Segment 系统表 分布式事务 Interconnect 调度器 执行器 解析器 优化器 处理解析树，生成 查询计划 查询计划描述了如 何执行查询 主节点 Segment 实例 本地事务 执行器 系统表 本地存储 Segment 主机 Segment 实例 Local TM 执行器Executor Catalog 本地存储Storage Segment 实例 本地事务 执行器 系统表 本地存储 Segment 实例 本地事务 执行器 系统表 本地存储 Segment 主机 Segment 实例 Local TM 执行器 Catalog 本地存储 Segment 实例 本地事务 执行器 系统表 本地存储 Segment 实例 本地事务 执行器 系统表 本地存储 Segment 主机 主机 Segment 实例 Local TM 执行器 Catalog 本地存储 Segment 实例 本地事务 执行器 系统表 本地存储 18 Pivotal Confidential–Inter nal Use Only 调度器 本地存储 主节点Segment 系统表 分布式事务 Interconnect 执行器 解析器 发送查询计划给各 个Segments

AGE大于10亿停止工作，等待vacuum执行 数据库对象数上限的最佳实践  GPDB内部的对象：所有的表（包括分区表）、索引、视图等都称为对象  GPDB最佳实践所推荐的对象管理要求是：一个数据库内对象不要超过10 0000个  最佳实践是出于对系统性能和稳定性因素建议对pg_class 所维护的对象数进行约束  减少对象数的方法： – 提高分区粒度 – 避免大范围使用列存储 pg_class对象数如果不进行约束，可能会产生以下问题： – gprecoverseg –F效率低，数据库实例修复如果增量同步失败，我们一般会建议使用gprecoverseg –F进行全量同 步，全量同步是在两个节点之间全量拷贝文件，超过10 0000个对象，在数据目录下地文件数会可能达到上百万 个档，这些文件的拷贝需要花费很长时间 – 使用gpexpand扩容节点时，对象数多，对应到每 在GPDB中，对象权限不能从Schema继承，新增的对象需要Grant授权给相应用户。  用户可以属于多个角色组role，用户可以从role继承权限  建议在系统建设时，按照功能、权限划分为较为固定的数个角色组，新增对象时只要把权限Grant到 相应角色组 即可，不需要再按照使用者单独授权，这种方式对于查询用户较多的系统能简化权限管理。  同一个对象内的数据，如果