81PB存储（增长 中） 4. 2.5PB 或 25PB 原始数据 按10x压缩率 1 2 3 4 Greenplum在摩根士丹利 OLTP - Online transaction processing - 联机事务处理 出色的OLTP特性 天生的优势 ● 行式存储 ● 索引 ● 直接分发 ● 完整的增删改 Greenplum 6 增强 ● 并发修改、删除 ● 系统性的优化事务和锁 系统性的优化事务和锁 26 Pivotal Confidential–Internal Use Only 行式存储 表‘SALES’ 表‘SALES’ ■ 更适合OLTP负载 ■ 高效更改和删除 ■ 适合需要全部或者多数列的查询 表 orders 索引 Greenplum支持以下索引: • Btree • Bitmap • Gist • GIN • BRIN (开发中) - 混合事务/分析处理 Gartner技术成熟度曲线 OLTP-OLAP独立部署 OLTP数据库 OLAP数据仓库 ■ 实时性 ■ 数据同步复杂性 ■ 应用复杂性 HTAP HTAP = ? ■ 卓越的OLAP特性 ■ 出色的OLTP特性 ■ 多态存储 ■ 有效的并发和资源管理 OLTP-OLAP独立部署 OLTP数据库 OLAP数据仓库 ■ 实时性 ■ 数据同步复杂性

数据仓库体系架构 业务数据与数据使用归类 时间维度：过去 - 现在 - 未来 （数据的生命周期） • “现在”的数据 —— OLTP • “过去”的数据 —— OLAP • “未来”的数据 —— 趋势分析 4 数据仓库体系架构 业务数据与数据特点 • 现在的数据 —— OLTP Ø实时，在线系统，客户使用 Ø事务小，频率高，并发高 • 过去的数据 —— OLAP Ø非实时（T+1，或小时级），离线系统，分析决策 数据仓库体系架构 数据流转过程 • 1 业务数据的产生 —— OLTP • 2 业务数据的中转 —— ETL服务器 • 3 数据的存储和计算 —— OLAP集群 • 4 结果数据的展现 —— 数据集市 • 5 访问接口的封装 —— API接口服务器 • 6 最终数据的显示 —— 前端界面 • 7 结果数据的交互 —— OLTP，趋势分析 • 8 OLAP数据流转 —— dbsync平台 7 系 Ø 公司第一套Greenplum集群，网络环境为千兆网 Ø 数据来源为OLTP库，针对小数据量传输和计算，部分实时交互操作 Ø 以对账业务为主，统计计算为辅 • 公司IDC_02机房Greenplum体系 Ø 针对数据来源主要是kfk产生csv文件的业务，不直接从数据库传数 Ø 以重点业务线、活动数据、非OLTP业务数据的任务计算为主 • 公司IDC_03机房Greenplum体系 Ø

join），而多个大表关联分析时 hash join 是必备的利器，缺少这些关键功能非常致命，将难于在 OLAP 领域充当大任。我们最近对基于 MYSQL 的某内存分布式数据库做 对比测试时，发现其优点是 OLTP 非常快，TPS 非常高（轻松搞定 几十万），但一到复杂多表关联性能就立马下降，即使其具有内存 计算的功能也无能为力，就其因估计还是受到 mysql 在这方面限制。 3) 扩展性方面，Postgresql Big Date2.indd 5 16-11-22 下午3:38 6 相信这些特点已经足够了，据说很多互联网公司采用 Mysql 来做 OLTP 的同时，却采用 Postgresql 来做内部的 OLAP 分析数据库，甚 至对新的 OLTP 系统也直接采用 Postgresql。 相比之下，Greenplum 更强悍，把 Postgresql 作为实例（该实例非 Oracle实例概念 最大的特点总结就一句话：基于低成本的开放平台基础上 提供强大的并行数据计算性能和海量数据管理能力。这个能力主要指 的是并行计算能力，是对大任务、复杂任务的快速高效计算，但如果 你指望 MPP 并行数据库能够像 OLTP 数据库一样，在极短的时间处 理大量的并发小任务，这个并非 MPP 数据库所长。请牢记，并行和 并发是两个完全不同的概念，MPP 数据库是为了解决大问题而设计的 并行计算技术，而不是大量的小问题的高并发请求。

replication) Ø 自动灾难恢复 (FTS，主备切换) Confidential │ ©2022 VMware, Inc. 9 分布式优化器：OLAP Ø OLTP系统的SQL语句相对简单（CURD） Ø OLAP系统的SQL语句就复杂得多（OLTP则尽量避免） q Join 很复杂(多表, outer join, lateral…) q 子查询、子链接 q 聚集 (grouping sets sdate date, amt numeric) DISTRIBUTED BY (id) PARTITION BY RANGE(sdate) ... Ø Heap: 源自PG，固定页面 大小, 适合OLTP Ø Append Optimized: 没有 页面的概念，变长，行存、 列存、压缩，适合OLAP Ø 外部表: HDFS，S3，文件， 网络，命令，流式数据… Confidential

Greenplum6 实现。 在 Greenplum6 和即将发布的 Greenplum 7, 带来了多项产品改进和新增功能，这些功能提升了性能，增加了系统可 用性，提高了系统可维护性，而这些对于传统 OLTP 类型应用提供了强有力的支撑。 全局死锁检测（GDD、Global deadlockdetector） 这项技术对性能提升特别是 Update 和 Delete 至关重要。锁是数据库 Greenplum 6 除了全局死锁检测，还引入了多项其他并发控制优化方法，这些优化对 SELECT 和 INSERT 提升比较 大。一个优化有关 procarray 锁，另一个优化和事务有关，大多数 OLTP 查询带有主键或者分布键，这种查询不需要 两阶段提交（2PC）。 集群在线扩容 Greenplum 6 实现了不停库在线增加新节点, 期间不会中断正在运行的所有查询；另外采用了 Jump 行改进带来了多项新功能，并且大大提升了事务处理性能 。正是由于社区的开放性和纯软件的中立性，与欧拉开源社区 合作让社区新版本扩充了客户的部署选项，与欧拉开源操作系统完全兼容，支持多样性计算，它提供了一个同时支持 OLAP 和 OLTP 的业务场景，同时支持传统和新型分析工作负载的环境，可帮助客户消除分析孤岛，避免数据来回移动。 此外， 它通过有助于加快创新的集成环境，为数据科学家和业务分析师提供多种分析功能。Greenplum

的弹性 和线性拓展能力，内置并行存储、并行通信、并行计算和并行优化功能，兼容 SQL 标准。拥有独 特的高效的 ORCA 优化器，具有强大、高效的 PB 级数据存储、处理和实时分析能力，同时支持 OLTP 型业务的混合负载。 Greenplum 分布式数据库简介 5 Confidential │ ©2021 VMware, Inc. Greenplum 集群化概述 Coordinator/Segment 或者是 S3 中。Greenplum 提供以下存储方式: l 堆表 (Heap Table)：默认存储方式，同时也是 PostgreSQL 的默认存储方式。支持高效的更新 和删除操作，通常用于 OLTP 。 l Append-Optimized 表：以追加的方式写入数据，有着极高的写入性能，通常用于存储数据仓 库中的事实数据，不适合做频繁的更新、删除操作。 l Append-Optimized

版权所有：Esena(陈淼 +86 18616691889) 编写：陈淼 - 102 - 堆存储 缺省情况下GP使用与PostgreSQL相同的存储模式--堆存储。堆存储模式在OLTP 类型工作负载的DB中很常用 -- 更适合数据在初始装载后经常变化的场景。UPDATE 和DELETE操作需要对ROW级别做版本控制从而确保DB事务处理的可靠性。堆表更适合 一些小表，例如维表，这种表可能会在初始化装载后经常更新数据。 另外，如果要进行大并发的INSERT，DELETE和UPDATE操作，建议关闭 log_statement参数，因为过多的日志输出也会影响这种操作的极限性能。编者认为， 不应该多度追求这种OLTP型的性能，如果可以通过批量或者微批的形式来处理业，将 可以更好的发挥和利用GP的MPP优势，不要总是热衷于跟技术较劲。 追加优化存储 在数据仓库等分析型场景，追加优 myserial CYCLE; 在 GP 中使用索引 在大多数的OLTP数据库中，索引可以显著的改善数据访问的性能。然而在分布式 数据库(例如GP)中，应该谨慎使用索引。GP执行顺序扫描已经很快，而索引是通过随 机寻址在磁盘上定位数据记录，两者适用场景不同。与传统的OLTP数据库不同的是， GP中数据是分布在多个Instance上的。这意味着每个Instance都扫描全部数据的一

级结构化、半结构化和非结构化数据存储、处理和实时分析能力，可部署于企 业裸机、容器、私有云和公有云中。值得一提的是，作为 OLAP 型的大数据平台, Greenplum 同 时还能够支持涵盖 OLTP 型业务的混合负载，从而帮助客户真正打通业务-数据-洞见-业务的闭环。 目前，Greenplum 已经为国内外各行各业客户所广泛使用,支撑着全球各大行业的核心生产系统， 其涉及领域涵

客户流失分析 响应时间 流量分析 产品关联/捆绑 零售 存储运营分析 客户忠诚度计划 协作规划和预估 预防亏损 优化供应链 当今的数据仓库方案 基于硬件 专有，昂贵 不可扩展 针对OLTP进行了优化 主流 10 数据库行业所面临的挑战 0 1 2 3 4 5 6 7 8 9 10 1995 2000 2005 2010 新一代数据库的要求 传统数据库的要求

一直采用传统查询优化器 (LQO) 。这是适用于 Greenplum 代码库的原始 PostgreSQL 规划器的衍 生产品。PostgreSQL 规划器最初是为单节点 PostgreSQL 设计的，更适用于 OLTP 查询，而不是分析数据平台中长时间运 行的查询。尽管具有精心设计的连接排序之类的功能，但架构和设计选项导致维护和添加新功能变得越来越难。1 2010 年底，Greenplum 开始在内部开发一款新型查询优化器，并在