Greenplum优化总结

Greenplum优化总结

GP优化须要了解清理缓存、性能监控、执行计划分析等知识。优化主要包含如下四方面：
　　表、字段，SQL，GP配置、服务器配置，硬件及节点资源。

1、 清理缓存：

#!/usr/bin/sudo bash
gpstop -r 　　#快速中止GP数据库
sync 　　　　#清空高速缓存前尝试将数据刷新至磁盘

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

gpstart 　　#启动GP数据库

2、 性能监控Performance Monitor

　　Greenplum监控管理平台Pivotal Greenplum Command Center (GPCC)和Pivotal Greenplum (GPDB)。实际使用过程当中发现对于6-8秒的查询（单表亿级数据），GPCC反应比较慢，CPU、IO等信息为0，能够采用其余方式实时监控CPU、内存、IO、网络等信息。

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

　　slice、motion
　　GPDB 有一个特有的算子：移动（ motion ）。移动操做涉及到查询处理期间在 Segment 之间移动数据。motion 分为广播（ broadcast ）、重分布（ redistribute motion ）、Gather motion。正是 motion 算子将查询计划分割为一个个 slice ，上一层 slice 对应的进程会读取下一层各个 slice 进程广播或重分布的数据，而后进行计算。每个广播或重分布或gather会产生一个slice。每个切片在每一个数据节点会对应发起一个进程来处理该slice负责的数据。SQL中要控制切片的数量，若是太多，应适当将sql拆分，避免因为进程太多，给数据库、机器带来太多的负担，也容易致使sql失效。

　　Gather motion的做用就在于将每一个节点上面的中间结果集中到主节点上面。GP中的数据迁移方式为数据广播和数据重分布。

　　OLAP的基本多维分析操做有钻取（Drill-up和Drill-down）、切片（Slice）和切块（Dice）、以及旋转（Pivot）

4、优化Greenplum链接

　　1.分解查询，去除join或者减少join数据量
　　2.缓存映射关系
　　3.创建索引，分部键
　　4.使用官方驱动包

　　数据查询去重
　　链接查询：创建两个临时表，经过关键字段筛选
　　链接查询：创建两个临时表，经过获取最大关键字段，再比较
　　链接查询：分组排序，添加序号，获取序号最大值

5、优化表结构

　　一、表字段设计

　　　　表字段选择恰当的字段类型，例如：数字类型选择int4或int8，浮点数选择float8，字符串选择varchar(32)等。

　　二、表存储方式

　　　　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))

　　　　ROLLUP 对分组字段（或者表达式）从最详细级别到最顶级别计算聚合计数。ROLLUP的参数是一个有序分组字段列表，它计算从右向左各个级别的聚合。例如 ROLLUP(c1, c2, c3) 会为下列分组条件计算汇集：

　　　　　　(c1, c2, c3)
　　　　　　(c1, c2)
　　　　　　(c1)
　　　　　　()

　　　　CUBE 为分组字段的全部组合计算聚合。例如 CUBE(c1, c2, c3) 会计算一下聚合：

(c1, c2, c3)
(c1, c2)
(c2, c3)
(c1, c3)
(c1)
(c2)
(c3)
()

　　　　GROUPING SETS 指定对那些字段计算聚合，它能够比ROLLUP和CUBE更精确地控制分区条件。

　　七、分区

　　黄金法则

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

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

　　CPU、内存、IO、网络

　　#检查磁盘空间使用，GP里面就能够查看到对应分区的使用状况

　　# SELECT dfsegment,dfhostname,dfdevice,dfspace FROM gp_toolkit.gp_disk_free ORDER BY dfsegment;
　　# SELECT sodddatname,pg_size_pretty(sodddatsize) FROM gp_toolkit.gp_size_of_database ORDER BY sodddatname;

　　#查看现有配置值

　　# gpconfig -s work_mem;
　　Greenplum配置参数优化：5.10.2

　　GP数据库参数配置，配置文件 postgresql.conf参数
　　　　shared_buffers：刚开始能够设置一个较小的值，好比总内存的15%，而后逐渐增长，过程当中监控性能提高和swap的状况。
　　　　effective_cache_size : 这个参数告诉PostgreSQL的优化器有多少内存能够被用来缓存数据，以及帮助决定是否应该使用索引。这个数值越大，优化器使用索引的可能性也越大。 所以这个数值应该设置成shared_buffers加上可用操做系统缓存二者的总量。一般这个数值会超过系统内存总量的50%。
　　　　work_mem: 当PostgreSQL对大表进行排序时，数据库会按照此参数指定大小进行分片排序，将中间结果存放在临时文件中，这些中间结果的临时文件最终会再次合并排序，因此增长此参数能够减小临时文件个数进而提高排序效率。固然若是设置过大，会致使swap的发生，因此设置此参数时仍需谨慎，刚开始可设定为总内存的5%。
　　　　temp_buffers: 即临时缓冲区，拥有数据库访问临时数据，GP中默认值为1M，在访问比较到大的临时表时，对性能提高有很大帮助。
　　　　gp_fts_probe_threadcount: 设置ftsprobe线程数，此参数建议大于等于每台服务器segments的数目。
　　　　gp_hashjoin_tuples_per_bucket: 此参数越小，hash_tables越大，可提高join性能。
　　　　gp_interconnect_setup_timeout: 此参数在负载较大的集群中，应该设置较大的值。
　　　　gp_vmem_protect_limit: 控制了每一个段数据库为全部运行的查询分配的内存总量。若是查询须要的内存超过此值，则会失败。使用下面公式肯定合适的值：

　　　　　　(swap + (RAM * vm.overcommit_ratio)) * .9 / number_of_Segments_per_server
　　　　例如：8GB 交换空间，128GB 内存，vm.overcommit_ratio = 50，8 个段数据库
　　　　　　(8 + (128 * .5)) * .9 / 8 = 8 GB， 则设置gp_vmem_protect_limit为 8GB

　　　　gp_statement_mem: 服务器配置参数 gp_statement_mem 控制段数据库上单个查询可使用的内存总量。若是语句须要更多内存，则会溢出数据到磁盘。用下面公式肯定合适的值
　　　　　　(gp_vmem_protect_limit * .9) / max_expected_concurrent_queries
　　　　例如，若是并发度为40， gp_vmeme_protect_limit为8GB，则 gp_statement_mem 为：
　　　　　　(8192MB * .9) / 40 = 184MB，每一个查询最多可使用 184MB 内存，以后将溢出到磁盘。
　　　　gp_workfile_limit_files_per_query
　　　　若是为SQL查询分配的内存不足，Greenplum数据库会建立溢出文件（也叫工做文件）。在默认状况下，一个SQL查询最多能够建立 100000 个溢出文件，这足以知足大多数查询。 该参数决定了一个查询最多能够建立多少个溢出文件。0 意味着没有限制。限制溢出文件数据能够防止失控查询破坏整个系统。 若是分配内存不足或者出现数据倾斜，则一个SQL查询可能产生大量溢出文件。若是超过溢出文件上限，Greenplum数据库报告以下错误：
　　　　ERROR: number of workfiles per query limit exceeded
　　　　在尝试增大gp_workfile_limit_files_per_query前，先尝试经过修改 SQL、数据分布策略或者内存配置以下降溢出文件个数。
　　　　max_connections: 最大链接数，Segment建议设置成Master的5-10倍。

6、数据库查询分析

　　1. VACUUM

　　vacuum只是简单的回收空间且令其能够再次使用，没有请求排它锁，仍旧能够对表读写
　　vacuum full执行更普遍的处理，包括跨块移动行，以便把表压缩至使用最少的磁盘块数目存储。相对vacuum要慢，并且会请求排它锁。
　　按期执行：在平常维护中，须要对数据字典按期执行vacuum，能够天天在数据库空闲的时候进行。而后每隔一段较长时间（两三个月）对系统表执行一次vacuum full，这个操做须要停机，比较耗时，大表可能耗时几个小时。
　　reindex:执行vacuum以后,最好对表上的索引进行重建

　　2. ANALYZE

　　命令：analyze [talbe [(column,..)]]
　　收集表内容的统计信息，以优化执行计划。如建立索引后，执行此命令，对于随即查询将会利用索引。
　　自动统计信息收集，在postgresql.conf中有控制自动收集的参数gp_autostats_mode设置，gp_autostats_mode三个值：none、no_change、on_no_stats（默认）
　　　　none：禁止收集统计信息
　　　　on change：当一条DML执行后影响的行数超过gp_autostats_on_change_threshold参数指定的值时，会执行完这条DML后再自动执行一个analyze 的操做来收集表的统计信息。
　　　　no_no_stats：当使用create talbe as select 、insert 、copy时，若是在目标表中没有收集过统计信息，那么会自动执行analyze 来收集这张表的信息。gp默认使用on_no_stats，对数据库的消耗比较小，可是对于不断变动的表，数据库在第一次收集统计信息以后就不会再收集了。须要人为定时执行analyze.
若是有大量的运行时间在1分钟如下的SQL，你会发现大量的时间消耗在收集统计信息上。为了下降这一部分的消耗，能够指定对某些列不收集统计信息，以下所示：

　　1. create table test(id int, name text,note text);
　　上面是已知道表列note不需出如今join列上，也不会出如今where语句的过滤条件下，由于能够把这个列设置为不收集统计信息：

　　1. alter table test alter note SET STATISTICS 0;

　　3. EXPLAIN执行计划

　　显示规划器为所提供的语句生成的执行规划。

　　　　cost：返回第一行记录前的启动时间， 和返回全部记录的总时间（以磁盘页面存取为单位计量）
　　　　rows：根据统计信息估计SQL返回结果集的行数
　　　　width：返回的结果集的每一行的长度，这个长度值是根据pg_statistic表中的统计信息来计算的。

　　4. 两种聚合方式

　　hashaggregate 根据group by字段后面的值算出hash值，并根据前面使用的聚合函数在内存中维护对应的列表，几个聚合函数就有几个数组。相同数据量的状况下，聚合字段的重复度越小，使用的内存越大。
　　groupaggregate 先将表中的数据按照group by的字段排序，在对排好序的数据进行全扫描，并进行聚合函数计算。消耗内存基本是恒定的。
　　选择方式，在SQL中有大量的聚合函数，group by的字段重复值比较少的时候，应该用groupaggregate

　　5. 关联

　　分为三类：hash join、nestloop join、merge join，在保证sql执行正确的前提下，规划器优先采用hash join。

　　hash join: 先对其中一张关联的表计算hash值，在内存中用一个散列表保存，而后对另一张表进行全表扫描，以后将每一行与这个散列表进行关联。
　　nestedloop:关联的两张表中的数据量比较小的表进行广播，如笛卡尔积：select * fromtest1，test2
　　merge join:将两张表按照关联键进行排序，而后按照归并排序的方式将数据进行关联，效率比hash join差。full outer join只能采用merge join来实现。
　　关联的广播与重分布解析P133，通常规划器会自动选择最优执行计划。有时会致使重分布和广播，比较耗时的操做。

　　6. 重分布

　　一些sql查询中，须要数据在各节点从新分布，受制于网络传输、磁盘I/O，重分布的速度比较慢。

　　关联键强制类型转换
　　　　通常，表按照指定的分布键做hash分部。若是两个表按照id:intege、id:numericr分布，关联时，须要有一个表id做强制类型转化，由于不一样类型的hash值不同，于是致使数据重分布。
　　关联键与分部键不一致
　　　　group by、开窗函数、grouping sets会引起重分布

　　查询优化
　　　　经过explain观察执行计划，从而肯定若是优化SQL。

　　7. 选择合适分布键

　　分布键选择不当会致使重分布、数据分布不均等，而数据分布不均会使SQL集中在一个segment节点的执行，限制了gp总体的速度。使全部节点数据存放是均匀的，数据分布均匀才能充分利用多台机器查询，发挥分布式的优点。join、开窗函数等尽可能以分布键做为关联键、分区键。尤为须要注意的是join、开窗函数会依据关联键、分区键作重分布或者广播操做，于是若分布键和关联键不一致，不论如何修改分布键，也是须要再次重分布的。尽可能保证where条件产生的结果集的存储也尽可能是均匀的。

　　查看某表是否分布不均： select gp_segment_id,count(*) from fact_tablegroup by gp_segment_id;
　　在segment一级，能够经过 select gp_segment_id,count(*) from fact_table group by gp_segment_id; 的方式检查每张表的数据是否均匀存放在系统级，能够直接用 df -h 或 du -h检查磁盘或者目录数据是否均匀
　　查看数据库中数据倾斜的表
　　首先定义数据倾斜率为：最大子节点数据量/平均节点数据量。为避免整张表的数据量为空，同时对结果的影响很小，在平均节点数据量基础上加上一个很小的值，SQL以下：

SELECT tabname,
max(SIZE)/(avg(SIZE)+0.001) AS max_div_avg,
sum(SIZE) total_size
FROM
(SELECT gp_segment_id,
oid::regclass tabname,
pg_relation_size(oid) SIZE
FROM gp_dist_random('pg_class')
WHERE relkind='r'
AND relstorage IN ('a','h')) t
GROUP BY tabname
ORDER BY 2 DESC;

　　8. 分区表

　　按照某字段进行分区，不影响数据在数据节点上的分布，可是，仅在单个数据节点上，对数据进行分区存储。能够加快分区字段的查询速度。

　　9. 压缩表

　　对于大AO表和分区表使用压缩，以节省存储空间并提升系统I/O，也能够在字段级别配置压缩。应用场景：

　　不须要对表进行更新和删除操做、访问表的时候基本上是全表扫描，不须要创建索引、不能常常对表添加字段或者修改字段类型。

　　9. 窗口函数

　　窗口函数能够实如今结果集的分组子集上的聚合或者排名函数，例如 sum(population) over (partition by city)。窗口函数功能强大，性能优异。由于它在数据库内部进行计算，避免了数据传输。

　　窗口函数row_number()计算一行在分组子集中的行号，例如 row_number() over (order by id)。若是查询计划显示某个表被扫描屡次，那么经过窗口函数可能能够下降扫描次数。窗口函数一般能够避免使用自关联。

　　10. 列存储和行存储

　　列存储亦即同一列的数据都连续保存在一个物理文件中，有更高的压缩率，适合在宽表中对部分字段进行筛选的场景。须要注意的是：若集群中节点较多，并且表的列也较多，每一个节点的每一列将会至少产生一个文件，那么整体上将会产生比较多的文件，对表的DDL操做就会比较慢。在和分区表使用时，将会产生更多文件，甚至可能超过linux的文件句柄限制，要尤为注意。

　　行存储：若是记录须要 update/delete，那么只能选择非压缩的行存方式。对于查询，若是选择的列的数量常常超过30个以上的列，那么也应该选择行存方式。

　　列存储：若是选择列的数量很是有限，而且但愿经过较高的压缩比换取海量数据查询时的较好的 IO性能，那么就应该选择列存模式。其中，列存分区表，每一个分区的每一个列都会有一个对应的物理文件，因此要注意避免文件过多，致使可能超越linux上容许同时打开文件数量的上限以及DDL命令的效率不好。

　　11. 函数和存储过程

　　虽然支持游标可是，尽可能不要使用游标方式处理数据，而是应该把数据做为一个总体进行操做。

　　12. 索引使用

　　若是是从超大结果集合中返回很是小的结果集（不超过5%），建议使用BTREE索引（非典型数据仓库操做），表记录的存储顺序最好与索引一致，能够进一步减小IO（好的index cluster）
where条件中的列用or的方式进行join，能够考虑使用索引。键值大量重复时，比较适合使用bitmap索引。

 

参考资料：
　　Greenplum 的分布式框架结构：http://www.javashuo.com/article/p-mynyvdxx-eh.html
　　Greenplum函数参考：https://gp-docs-cn.github.io/docs/ref_guide/function-summary.html#top