月份：2018年11月

Greenplum数据库设计与优化

1 GP表设计

1.1 分布键

GP作为一个MPP数据库，分布键的选择对于后期使用的性能影响非常大。即使GP运行在单机环境，GP数据也是存放在多个segment上，所以必须要选择合适的分布键，特别是从单机数据库迁移到GP上的业务，因为单机数据库 不涉及分布键，所以迁移之前一定要设计好所有表的分布键。每张表必须显式指定分布键，避免使用默认分布。

  1. 尽可能的避免各个节点之间的数据交互以提高性能。两表关联查询时如果关联字段包含分布键，则数据可以在各自节点内完成运算；如果关联字段不包含分布键，则需要进行数据重分布，产生大量网络、内存开销，性能很低。
  2. 尽可能选择能使数据均匀分布在各个节点的分布键。如果数据分布不均匀，性能瓶颈就会出现在数据最多的节点上，导致其他节点很空闲，而都在等待该节点执行完成，造成性能低及资源浪费。

例如人员主题库类的业务，表之间查询、关联都是以人员为单位，而区分人员则使用的是身份ID。并且身份ID 散列度非常高，可以保证数据均匀分布。所以这类业务里的绝大多数表都非常适合使用身份ID字段作为分布键。

可以通过select gp_segment_id,count(*) from table_name group by gp_segment_id检查表数据是否均匀分发到每个segment上。

1.2 表分区

GP只支持range、list两种分区，不支持hash分区。GP使用表继承方式实现分区表，实际上每个分区都是一张单独的表，并且对于列存类型的表，每一列都需要一个单独的文件，每台服务器上的文件数=segment数*表数量*表分区数量*列数，所以为了避免文件系统上文件过多，仅对大表进行分区。

按照某个字段进行分区不会影响数据在节点上的分布，但是合理的选择分区字段可以让查询只扫描需要访问的分区，加快在单个数据节点的查询速度。

例1：

某张明细数据类的表，每天都有明细数据，经常按天查询明细数据，且数据保留N个月。则适合使用业务日期作为表分区键。按天查询数据可以只访问需要查询的分区，不会全表查询。删除过期数据时可以直接删除过期分区。

例2：

某张人员基本信息类的表，业务经常需要按省份进行统计各项指标。则适合使用省级代码作为表分区键。需要更新某省份数据时可以清空该省份分区后导入。并且统计时绝大多数操作都可以在分区内完成。

1.3 表存储方式

行存储是一行的所有列在磁盘上连续存储，所以一次IO可以从磁盘上读取整个行的数据。

列存储是在磁盘上将同一列的只保存在一起。

GP同时支持行存及列存。行列存储的特点和对比网上有很多文章可以参考，这里只列举一下各自适用的场景：

适合使用行存的场景：

  1. 数据经常需要修改
  2. 每次查询的字段占表全部列的大部分

适合使用列存的场景：

  1. 数据不需要修改或极少修改
  2. 表字段数多且经常查询其中少量字段
  3. 表数据量很大，需要压缩来提高IO性能

1.4 索引


GP则是通过索引设计提高数据检索性能 。

  1. 对于经常需要根据条件检索少量数据的高基数列建立索引
  2. 对于经常用于表关联的字段建立索引
  3. 频繁更新的列不要建立索引
  4. GP索引对数据加载性能影响很大，所以在加载大量数据前可以先删除索引，加载结束后重建索引

2 最佳实践

2.1 ANALYZE

ANALYZE用于收集表的统计信息，以优化执行计划。

如果使用INSERT、UPDATE、DELETE操作或修改大量数据之后，或导入数据后，建议执行ANALYZE。

创建新的索引之后也建议执行ANALYZE。

2.2 VACUUM

VACUUM用于回收表空间并可以再次使用，不会申请排他锁，其他会话仍可以正常读写该表。如果加上FULL参数，则会请排他锁，阻塞其他操作。

所以建议对于经常修改或删除的表，定期在闲时执行VACUUM操作，释放空间。不建议使用VACUUM FULL，可以使用create table … as操作，然后删除原表重命名新表。

2.3 加载数据

GP支持COPY方式入库和外部表方式入库。COPY方式所有数据会经过MASTER节点，由MASTER进行分发，性能较低，但是使用方便，对于少量数据可以使用COPY方式入库。外部表方式所有的segment节点都会并行加载数据，需要开启gpfdist服务并创建外部表，但是性能较高，对于大量数据建议使用外部表方式入库。

2.4 执行计划

GP采用基于成本的优化器来评估执行查询的不同策略，并选择成本最低的方法。和其他关系数据库系统的优化器相似，在计算不同执行计划的成本时，GP的优化器会考虑诸如关联表的行数、是否有索引、字段数据的基数等因素。还会考虑到数据的位置，尽可能在segment上完成任务，降低在不同segments间传输的数据量。

在一个查询运行速度比预期慢时，可以查看优选器生成的执行计划以及执行每一步的代价。这有助于确定哪一步最耗资源，进而可以修改查询或者模式，以便生成更好的计划。查看查询计划使用 EXPLAIN 语句。

执行详细描述了GP执行查询的步骤。查询计划是颗节点树，从下向上阅读，每个节点将它的执行结果数据传递给其上的节点。每个节点表示查询计划的一个步骤，每个节点都有一行信息描述了该步骤执行的操作，例如扫描、关联、聚合或者排序操作等，此外还有显示执行该操作的具体方法。例如，扫描操作可能是顺序扫描或者索引扫描，关联操作可能是哈希关联或者嵌套循环关联。

例：

postgres=# explain select datasetid,count(*) from t1 group by datasetid;

                                                      QUERY PLAN                                                       

———————————————————————————————————————–

 Gather Motion 8:1  (slice2; segments: 8)  (cost=8272479.90..8272484.15 rows=340 width=90)

   ->  HashAggregate  (cost=8272479.90..8272484.15 rows=43 width=90)

         Group By: t1.datasetid

         ->  Redistribute Motion 8:8  (slice1; segments: 8)  (cost=8272468.00..8272474.80 rows=43 width=90)

               Hash Key: t1.datasetid

               ->  HashAggregate  (cost=8272468.00..8272468.00 rows=43 width=90)

                     Group By: t1.datasetid

                     ->  Append-only Columnar Scan on t1  (cost=0.00..6662468.00 rows=40250000 width=33)

 Optimizer status: legacy query optimizer

（9 rows)

可以从上面执行计划看到会依次执行：

  1. Append-only Columnar Scan
  2. HashAggregate
  3. Redistribute Motion
  4. HashAggregate
  5. Gather Motion。

即：

  1. 在8个segments上对Append-only表进行列扫描
  2. 因为有汇聚函数，进行hash汇聚
  3. 未使用表分布键进行汇聚，所以需要进行数据重分布
  4. 重分布后进行hash汇聚
  5. master收集各节点结果并返回结果集

分析执行计划时首先要找估算代价较高的步骤。对比估算的行数及代价与操作实际需要处理的行数，以判断是否合理。

如果有分区表，判断分区裁剪是否有效。分区裁剪需要查询条件（WHERE 子句）必须和分区条件一样，不能包含子查询。

如果执行计划顺序不是最优的，检查数据库统计信息是否最新的。这时就要运行ANALYZE，生成最优计划。

注意计算倾斜。当执行诸如哈希聚合和哈希关联等操作符时，若不同Segment执行代价分布不均，就会发生计算倾斜。由于某些Segment比其他Segment使用更多的CPU和内存，性能下降明显。原因可能是关联、排序、聚合字段基数低或者数据分布不均匀。通过EXPLAIN ANALYZE 可以检测计算倾斜。每个节点都含有Segment处理的最多行数和所有Segment的平均行数。如果最大行数比均值大很多，那么至少有一个Segment需要处理更多的工作，因而有计算倾斜的可能性。

例：

postgres=# explain analyze select c1,count(*) from t1 group by c1;

                                                                      QUERY PLAN                                                                      

——————————————————————————————————————————————————

 Gather Motion 8:1  (slice1; segments: 8)  (cost=10821491.42..15184888.40 rows=145149885 width=90)

   Rows out:  311959999 rows at destination with 44285 ms to first row, 125533 ms to end, start offset by 42 ms.

   ->  HashAggregate  (cost=10821491.42..15184888.40 rows=18143736 width=90)

         Group By: c1

         Rows out:  Avg 38994999.9 rows x 8 workers.  Max 39002895 rows (seg2) with 46671 ms to first row, 75735 ms to end, start offset by 44 ms.

         Executor memory:  131464K bytes avg, 131464K bytes max (seg0).

         Work_mem used:  127901K bytes avg, 127901K bytes max (seg0). Workfile: (8 spilling, 0 reused)

         Work_mem wanted: 3020300K bytes avg, 3020885K bytes max (seg2) to lessen workfile I/O affecting 8 workers.

         (seg2)   39002895 groups total in 32 batches; 1 overflows; 40032573 spill groups.

         (seg2)   Hash chain length 4.7 avg, 19 max, using 8568049 of 8650752 buckets.

         ->  Append-only Columnar Scan on t1  (cost=0.00..6662468.00 rows=40250000 width=26)

               Rows out:  Avg 40250000.0 rows x 8 workers.  Max 40257783 rows (seg2) with 80 ms to first row, 10405 ms to end, start offset by 46 ms.

 Slice statistics:

   (slice0)    Executor memory: 413K bytes.

   (slice1)  * Executor memory: 131822K bytes avg x 8 workers, 131822K bytes max (seg0).  Work_mem: 127901K bytes max, 3020885K bytes wanted.

 Statement statistics:

   Memory used: 128000K bytes

   Memory wanted: 3021084K bytes

 Optimizer status: legacy query optimizer

 Total runtime: 144500.021 ms

（20 rows)

可以看出上面的执行计划在各个阶段内存和IO对比中max与avg差别都很小，说明数据分布很好，没有倾斜。