Greenplum实战之查询优化

时间 2019-11-08

标签 greenplum 实战查询优化繁體版

原文原文链接

本文主要分为三部分：html

GP优化须要准备的一些关于优化以外的知识，包括清空缓存、性能监控、执行计划分析。
具体优化措施，从如下四个方面考虑：

表、字段
sql
GP配置、服务器配置
硬件及节点资源

GP的性能极限分析

1. 前置知识

1.1 GP清除缓存

数据库通常都有缓存，因此咱们为了测试查询性能，须要将缓存清除。linux

中止数据库并不能清空缓存,由于缓存是由操做系统建立的,通常只有重启操做系统能够彻底清空.
参考思路以下：git

#!/usr/bin/sudo bash

gpstop -r

sync      //清空高速缓存前尝试将数据刷新至磁盘

//释放linux内存
echo 1 > /proc/sys/vm/drop_caches
echo 2 > /proc/sys/vm/drop_caches
echo 3 > /proc/sys/vm/drop_caches

gpstart

1.2 性能监控Performance Monitor

新一代Greenplum监控管理平台Pivotal Greenplum Command Center (GPCC)。github

实际使用过程当中发现对于6-8秒的查询（单表亿级数据），GPCC反应比较慢，CPU、IO等信息为0，目前拟采用其余工具，实时监控CPU、内存、IO、网络等信息。redis

1.3 执行计划分析

EXPLAIN会为查询显示其查询计划和估算的代价，可是不执行该查询。
EXPLAIN ANALYZE除了显示查询的查询计划以外，还会执行该查询。EXPLAIN ANALYZE会丢掉任何来自SELECT语句的输出，可是该语句中的其余操做会被执行（例如INSERT、UPDATE或者DELETE）。

http://www.javashuo.com/article/p-mynyvdxx-eh.htmlsql

slice、motion

GPDB 有一个特有的算子：移动（ motion ）。移动操做涉及到查询处理期间在 Segment 之间移动数据。motion 分为广播（ broadcast ）、重分布（ redistribute motion ）、Gather motion。正是 motion 算子将查询计划分割为一个个 slice ，上一层 slice 对应的进程会读取下一层各个 slice 进程广播或重分布的数据，而后进行计算。数据库

每个广播或重分布或gather会产生一个slice。每个切片在每一个数据节点会对应发起一个进程来处理该slice负责的数据。SQL中要控制切片的数量，若是太多，应适当将sql拆分，避免因为进程太多，给数据库、机器带来太多的负担，也容易致使sql失效。缓存

Gather motion的做用就在于将每一个节点上面的中间结果集中到主节点上面。bash

优化

总的思路服务器

表、字段
sql
GP配置、OS配置
硬件及节点资源

一、表字段设计

PostgreSQL 用CPU "硬解码" 提高1倍数值运算能力助力金融大数据量计算

如上面例子所示，优化某些字段的设计，以提升性能

二、表存储方式

Heap 或 Append-Only存储：GP默认使用堆表。堆表最好用在小表，如：维表(初始化后常常更新)。Append-Only表不能update和delete。通常用来作批量数据导入。不建议单行插入。

多列查询请求

行存储 => 在select或where子句中，查询全部列或大部分列
列存储 => 在where或having子句中，查询单列的值汇总或单行过滤

若数据须要频繁地更新或者插入，则使用行存储。
若须要同时访问一个表的不少字段，则使用行存储。
对于通用或者混合型业务，建议使用行存储。
若查询访问的字段数目较少，或者仅在少许字段上进行聚合操做，则使用列存储。
若仅经常修改表的某一字段而不修改其余字段，则使用列存储。

三、压缩

对于大AO表和分区表使用压缩，以提升系统I/O。
在字段级别配置压缩。
考虑压缩比和压缩性能之间的平衡。

压缩的性能取决于硬件、查询调优设置、其它因素。

QuickLZ - 低压缩率、低cpu消耗、压缩数据块
zlib - 高压缩率、低速

四、列存储
列存里面能够启动压缩。

只适合append-only表。

五、索引
高基数的列（惟一值多）

通常来讲，在Greenplum数据库中索引不是必需的。
对于高基数的列存储表，若是须要遍历且查询选择性较高，则建立单列索引。
频繁更新的列不要创建索引。
在加载大量数据以前删除索引，加载结束后再从新建立索引。
优先使用 B 树索引。
不要为须要频繁更新的字段建立位图索引。
不要为惟一性字段、基数很是高或者很是低的字段建立位图索引。
不要为事务性负载建立位图索引。
通常来讲不要索引分区表。若是须要创建索引，则选择与分区键不一样的字段。

可优化部分小结果集查询。

六、分布键
七、分组扩展
Greenplum数据库的GROUP BY扩展能够执行某些经常使用的计算，且比应用程序或者存储过程效率高。

GROUP BY ROLLUP(col1, col2, col3)
    GROUP BY CUBE(col1, col2, col3)
    GROUP BY GROUPING SETS((col1, col2), (col1, col3))

八、分区

黄金法则

目前Greenplum支持LIST和RANGE两种分区类型。

分区的目的是尽量的缩小QUERY须要扫描的数据量，所以必须和查询条件相关联。

只为大表设置分区，不要为小表设置分区。
仅在根据查询条件能够实现分区裁剪时使用分区表。
建议优先使用范围 (Range) 分区，不然使用列表 (List) 分区。
根据查询特色合理设置分区。
不要使用相同的字段既作分区键又作分布键。
不要使用默认分区。
避免使用多级分区；尽可能少地建立分区，每一个分区的数据会多些。
经过查询计划的 EXPLAIN 结果来确保对分区表执行的查询是选择性扫描（分区裁剪）。
对于列存储的表，不要建立过多的分区，不然会形成物理文件过多：
    Physical files = Segments * Columns * Partitions。

九、根据监控定位资源占用较多的状况：

CPU
内存
IO
网络

笔者目前耗费资源比较多的是内存，主要须要优化内存、增长内存。

十、数据库配置优化

Greenplum企业应用实战第8章
《Greenplum 数据库最佳实践》第二章
https://blog.csdn.net/u012948976/article/details/52695372
查询缓存
线程数量与内存
gp_statement_mem ：单个查询可使用的内存总量。若是它太大，则并发数越小。因此要有所折衷。
http://blog.51cto.com/michaelkang/2170608

十一、硬件选型

- Greenplum企业应用实战第8章
gp性能管理

硬件考虑因素：

（1）Segment服务器具备相同的硬件配置；推荐：双核，32GB Mem，高速磁盘阵列，4个以上千兆网口。
（2）Master服务器具备较高的cpu和内存资源；
（3）基准性能：3.2GB/s（综合的系统磁盘读写速度）

十二、估值计算
估值计算是统计学的经常使用手段。由于数据量庞大，求精确数值须要耗费巨大的资源，而统计分析并不要求彻底精确的数据，所以估值计算是一种折中的方法，普遍应用于统计分析场景。

秒级任意维度分析1TB级大表 - 经过采样估值知足高效TOP N等统计分析需求

1三、服务器参数调整

共享内存
网络
系统对用户的限制，好比打开文件句柄的数量。

GP的性能极限分析

MPP架构

Greenplum实现了基于数据库的分布式数据存储和并行计算

MPP架构的极限思考？

根据木桶原理以及这篇文章（https://clickhouse.yandex/benchmark.html#[%22100000000%22,[%22Greenplum%22],[%220%22,%221%22,%222%22]]）的测试结果，segment节点的PG实例的处理速度决定。若是OLAP的处理速度在3秒内，能够计算单segment在3秒之内能处理多少速度，而后再作横向扩展。