在那个测试中，测试性能也大幅低于 Greenplum（那个测试中，各厂 商基于客户提供的完全相同的硬件环境，Greenplum 是唯一一家完成 所有测试的，特别在混合负载测试中，Greenplum 的 80 并发耗时 3 个多小时就成功完成了，其它厂商大都没有完成此项测试，唯一完成 的一家耗时 40 多小时）。 Big Date2.indd 9 16-11-22 下午3:38 10 前文提到，得益于 的是并行计算能力，是对大任务、复杂任务的快速高效计算，但如果 你指望 MPP 并行数据库能够像 OLTP 数据库一样，在极短的时间处 理大量的并发小任务，这个并非 MPP 数据库所长。请牢记，并行和 并发是两个完全不同的概念，MPP 数据库是为了解决大问题而设计的 并行计算技术，而不是大量的小问题的高并发请求。 再通俗点说，Greenplum 主要定位在 OLAP 领域，利用 Greenplum MPP 数据库做大数据计算或分析平台非常适合，例如 具有很强数据操纵能力和过程语言的流程控制能力，SQL 语言是专 门为统计和数据分析开发的语言，各种功能和函数琳琅满目，SQL 语言不仅适合开发人员，也适用于分析业务人员，大幅简化了数据 的操作和交互过程。 而对 MapReduce 编程明显是困难的，在原生的 Mapreduce 开发 框架基础上的开发，需要技术人员谙熟于 JAVA 开发和并行原理， 不仅业务分析人员无法使用，甚至技术人员也难以学习和操控。为 了解决易用性的问题，近年来

第一个支持互联网级分析技术（由Google普及）的产品 • 采用新的编程模型，在商用硬件上并行处理和执行 • 可以使客户洞察力和数据货币化程度达到前所未有的高度 MapReduce Greenplum MapReduce的优势 • 处理在任何地点存储的任何类型的数 据 • 将SQL的普遍性与MapReduce的灵 活编程模式结合起来 • 针对业务关键分析功能提供企业级集 成、支持和发布 每台机器配置6个千兆网口 • Raid10 • Solaris 10 网站日志 交易数据 详细数据 Greenplum •海量基础数据 •大数据量查询 Oracle 加工数据 •门户网站 •高并发查询 。。。。。。 用户信息 Hardware Architecture 案例分享：上海航空 结算 系统 源系统 Oracle GreenPlum 结算 ETL Staging ETL

MADlib vs. Spark: 不不同的产品，侧重点不不同 MADlib Spark 算法库 易用性 需要编程 查询优化 成熟度稍差 内存和流处理 通过 Gemfire SQL 语法支持 需要提升 磁盘数据 不是核心焦点 并发性能 不是核心焦点 大数据关联 不是核心焦点 2017.thegiac.com ⽤用户案例例 1 Greenplum

文件 ....................................................................................... - 35 - 限制并发连接数量 .............................................................................................. .................................................................................. - 168 - 关于 GP 的并发控制 ................................................................................................ 的 CPU，可根据不同的场景，配置 4 ~ 12 个不等的 Primary，这个数字的选择需要由富有经验的专业技术支持人员进行评估， 每个 Instance 所在主机配置的 Primary 越多，响应并发的能力越弱，但单个任务的 处理能力越强(这也不是绝对的，当 Primary 数量多到，即便运行单个任务时都会出 现资源争抢，可能运行的效率就会下降)。实际上，每个计算主机的 Primary 个数，

Processing) 2017 年象行中国（杭州 站）第一期 Greenplum数据库 2017 年象行中国（杭州 站）第一期 Resource Queue • SQL语句并发控制 • 基于cost的并发控制 • 基于priority的CPU控制 • 内存控制 2017 年象行中国（杭州 站）第一期 Running Example • CREATE RESOURCE QUEUE rq Runaway Detector 2017 年象行中国（杭州 站）第一期 Resource Queue • Deadlock – active_statements => ‘等待’ – SQL级并发控制 => 可能持有锁 – 拿着锁等待 => 环状等待 – Tx1: LOCK tbl; -- AccessExclusiveLock Tx2: INSERT INTO tbl; -- RowExclusiveLock 2017 年象行中国（杭州 站）第一期 Resource Queue • System PANIC – 需要睡眠/唤醒机制 – Count + LWLock + Lock • Count：记录并发数 • LWLock：保护count • Lock：睡眠/唤醒，死锁检测，状态报告 – 维护Lock在共享内存的状态 – bug => lock table corruption => PANIC

transaction processing - 联机事务处理 出色的OLTP特性 天生的优势 ● 行式存储 ● 索引 ● 直接分发 ● 完整的增删改 Greenplum 6 增强 ● 并发修改、删除 ● 系统性的优化事务和锁 26 Pivotal Confidential–Internal Use Only 行式存储 表‘SALES’ 表‘SALES’ ■ 更适合OLTP负载 ■ 支持更改删除、删除 ■ 支持更改分布键、主键（将数据从一个节点移到另一个节点） 30 Pivotal Confidential–Internal Use Only Greenplum 6：并发改删和分布式死锁检测 全局死 锁检测 gpconfig -c ‘gp_enable_global_deadlock_detector’ -v on 31 Pivotal Confidential–Internal TPS （192核单机部署 ，master+18 segments） 34 Pivotal Confidential–Internal Use Only TPC-B基准测试：UPDATE ■ 得益于并发更改特性 ■ 70倍的TPS提升 35 Pivotal Confidential–Internal Use Only TPC-B基准测试：INSERT ■ 峰值TPS提升3.6倍 36 Pivotal

节点一般配置4~8个Instance，初始化完成后很 难修改，需要提前规划； • 每个Instance都是一套独立的进程，当客户端 发起一个请求时，每个Instance都将FORK子进 程并行工作； • 对于并发请求高、面向于复杂的灵活查询的系 统，建议每个Segment配置4个或以下Instance， 这样来保证每个Instance所需资源，保证系统 系统运行稳定性，例如，减少OOM发生的概率； • 对于少数频繁查询的宽表，例如交易表、帐户表、客户表等采用列存储，其它表采用行存储 数据压缩： • 在金融业，行压缩的数据压缩比在1:6左右，一般采用zlib5级压缩 • 数据压缩对于高并发查询分析系统可以大幅降低IO消耗，提升并行处理、混合负载的性能 分布键使用： • 尽量采用一个常用关联字段作为分布键，例如账号、客户号，这个可以提高关联条件的命中率，减少关联时数据重分布 生日期”做分区，然后在机构字段上将bitmap索引 • 对于1亿条记录以下的表不分区(对于小系统，该阀值适当调低) 索引使用： • 以数据批处理为主要功能的系统一般不需建索引 • 以并发查询为主要功能，特别OLTP查询（根据KEY，Attribute等作为筛选条件）的系统按照常用字段建索引。 • 建索引的方法：对于区别度高的字段，如账号、手机号码等使用B-Tree索引，对于区别度低的字段（<10000)

............................................................................................. 10 并发控制优化 .............................................................................................. m 6 及未来发布的 Greenplum 7 丰富的 HTAP 特性，具备良好性能、可靠性和稳定性，使得 Greenplum 不仅可以作为全能的分析化平台，也能满足交易型业 务场景，能够处理多种并发混合工作负载，专为满足在多结构数据环境中进行实时分析的需求而设计。 欧拉开源操作系统是一款面向数字基础设施的操作系统，支持服务器、云计算、边缘计算、嵌入式等应用场景，支持多 样性计算，致力于提供安全、稳定、易用的操作系统。 15%-17%，值得一提的是此论文主要由中国研发团队完成，也说明了中国研发团队实力处于世界一流水平。在论文 中 Greenplum 团队提出一种全新的全局死锁检测器来减少独占锁的使用，减少独占锁的使用可以极大的提高数据库 在高并发状态下的性能，这项技术已经在 Greenplum6 实现。 在 Greenplum6 和即将发布的 Greenplum 7, 带来了多项产品改进和新增功能，这些功能提升了性能，增加了系统可

（满足完整性约束） 实现对A、I、D三个属性的支持 Isolation 隔离性 多个事务并发地执行，对每个事务来说，它并 不会感知系统中有其他事务在同时执行。 多版本并发控制Multi-Version Concurrency Control、 两阶段加锁（Two Phase Locking, 2PL）、乐观并发控制 （OCC） Durability 持久性 一个事务在提交之后，该事务对数据库的改变 Hector Garcia-Molina /Jeffrey D.Ullman/Jennifer Widom《数据库系统实现》 查询编译器/ 优化器 事务管理器 DDL编译器 执行引擎 日志和恢复 并发控制 索引/文件/ 记录管理器 缓冲区管理器 缓冲区 锁表 存储管理器 存储 查询计划 对索引、文件和 记录的请求 页命令 事务命令 查询、更新 用户/ 应用 DDL命令 缓冲区管理策略Buffer Management Policy 13 ■ Force策略的问题 对持久存储器进行频繁的随机写操作，性能下降。 ■ No-Steal策略的问题 不允许未提交事务的脏页换出，系统的并发量不高。 ▪ No-Force / Steal 有更好的性能，但是怎么保证事务的原子性和持久 性？ ❏ No-Force: 事务提交，所修改的数据页没有刷回至持久存储，如果发生断电 或者系统崩溃。

Ø实时，在线系统，客户使用 Ø事务小，频率高，并发高 • 过去的数据 —— OLAP Ø非实时（T+1，或小时级），离线系统，分析决策 Ø事务大，频率相对小，并发低 • 未来的数据 —— 趋势分析 Ø非实时，离线+在线流系统，趋势分析 Ø算法分析，持续计算 5 数据仓库体系架构 OLAP场景举例 • 业务相关场景 Ø用户状态 （注册数，活跃数，并发量，峰值） Ø金币状态 Ø道具/物品状态 通过dbsync程序，实现数据传输和加载优化 Ø 对于Greenplum上的架构和设计不断优化 Ø 继续建设多样化的postgresql数据集市，满足不同需求 • 优化现有业务的调度实现 Ø 时间周期的考量 Ø 并发与功能实现的权衡 Ø 增强任务可控性和可度量性 • 支持符合条件的新业务 Ø 抽象业务模型，整合使用分类 Ø 简化上线模型，优化上线方式 40 Greenplum扩展规划 新业务上线流程