Greenplum 性能优化之路 --（二）存储格式

一、存储格式介绍

Greenplum（以下简称 GP）有2种存储格式，Heap 表和 AO 表（AORO 表，AOCO 表）。

• Heap 表：这种存储格式是从 PostgreSQL 继承而来的，目前是 GP 默认的表存储格式，只支持行存储。

• AO 表：  AO 表最初设计是只支持 append 的（就是只能 insert ），因此全称是Append-Only，在4.3之后进行了优化，目前已经可以 update 和 delete 了，全称也改为 Append-Optimized。AO 支持行存储（AORO）和列存储（AOCO）。

二、Heap表

Heap 表是从 PostgreSQL 继承而来，使用 MVCC 来实现一致性。如果你在创建表的时候没有指定任何存储格式，那么 GP 就会使用 Heap 表。

Heap 表支持分区表，只支持行存，不支持列存和压缩。需要注意的是在处理 update 和 delete 的时候，Heap 表并没有真正删除数据，而只是依靠 version 信息屏蔽老的数据，因此如果你的表有大量的 update 或者 delete，表占用的物理空间会不断增大，这个时候需要依靠 vacuum 来清理老数据。

Heap 表不支持逻辑增量备份，因此如果要对 Heap 表做快照，每次都需要导出全量数据。

建表语句

CREATE TABLE heap(
	a int,
	b varchar(32)
) DISTRIBUTED BY (a);

　　

最佳实践：

• 如果该表是一张小表，比如数仓中的维度表，或者数据量在百万以下，推荐使用 Heap 表。

• 如果该表的使用场景是 OLTP 的，比如有较多的 update 和 delete，查询多是带索引的点查询等，推荐使用 Heap 表。

三、AO表

AO 表是 GP 特有的，设计的目的就是为了数仓中大型的事实表。AO 表支持行存和列存，并且也支持对数据进行压缩。

AO 表无论是在表的逻辑结构还是物理结构上，都与 Heap 表有很大的不同。比如上文所述 Heap 表使用 MVCC 控制 update 和 delete 之后数据的可见性，而 AO 表则使用一个附加的 bitmap 表来实现，这个表的的内容就是表示 AO 表中哪些数据是可见的。

对于有大量 update 和 delete 的 AO 表，同样需要 vacuum 进行维护，不过在 AO 表中， vacuum 需要对 bitmap 进行重置并压缩物理文件，因此通常比 Heap 的 vacuum 要慢。

AORO表

AORO 就是行存的 AO 表，同时行存也是 AO 表的默认存储方式。

AORO 支持表级别的压缩，不支持列级别的压缩。

建表语句如下，重点是 with 后的 appendonly=true，由于 AO 表默认是行存，因此 orientation=row 也可以不要，后面的 compresstype=zlib, compresslevel=4 都是压缩相关选项。

CREATE TABLE aoro(
	a int,
	b int,
	c varchar(32),
	d varchar(32)
)
WITH (appendonly=true, orientation=row, compresstype=zlib, compresslevel=4)
DISTRIBUTED BY (a)

　　

压缩选项：

• compresstype ：压缩格式，开源版本的 AORO 表只支持 zlib。

• compresslevel ：压缩级别，从1-9，简单说来，级别越低（1最低），压缩比越低，但是压缩与解压消耗的 cpu 资源就越少。默认压缩级别是1。

最佳实践____________________：

• AO 表主要是针对大表，比如数仓中的事实表。

• AO 表支持逻辑增量备份，对于比较大的表，如果需要定期做快照，建议使用 AO 表，否则每次都要导出全量数据。

• 如果该表是大表，使用场景偏 OLTP 并且 update 和 delete 频率不高，可以考虑使用 AORO 表。

• 如果该表是大表，并且查询通常都需要扫描大多数列比如查询明细（最典型的就是 SELECT * FROM ），可以考虑使用 AORO 表。

• 在设置压缩级别的时候，通常对于数据仓库用户，设置到 4 或者 5 是比较折中的一个选择。

AOCO表

AOCO 表就是列存的 AO 表。

AOCO 不仅支持表级别的压缩，同时也支持列级别的压缩。

建表语句如下，这里还加入了分区特性，关于分区可以参见上一篇：Greenplum 性能优化之路 --（一）分区表：

CREATE TABLE aoco(
	a int  ENCODING (compresstype=zlib, compresslevel=5),
	b int  ENCODING (compresstype=none),
	c varchar(32) ENCODING (compresstype=RLE_TYPE, blocksize=32768),
	d varchar(32),
	fdate date
)
WITH (appendonly=true, orientation=column, compresstype=zlib, compresslevel=6, blocksize=65536)
DISTRIBUTED BY (a)
PARTITION BY RANGE(fdate)
(
	PARTITION pn START ('2018-11-01'::date) END ('2018-11-10'::date) EVERY ('1 day'::interval),
	DEFAULT PARTITION pdefault
);

　　

压缩选项：

• compresstype：支持2种压缩格式，zlib 和 RLE_TYPE，其中 RLE_TYPE（Run-length Encoding）对于有较多重复值的列压缩比很高，因为它会将多个重复值存储为一个值，从而大大降低存储量，比如日期，性别，年龄等字段。

• compresslevel：compresstype 如果是 zlib，compresslevel 在1-9，compresstype 如果是 RLE_TYPE，compresslevel 在1-4。

• 列压缩与表压缩：AOCO 表除了支持表级别的压缩外，还支持列级别的压缩，列级别的压缩配置会覆盖表级别的压缩配置，比如上述语法中4个字段，每个字段都采用了不用的压缩方式，d 列没有定义，则会默认使用表级别的压缩方式。

• 分区压缩：在使用分区表的时候，每个分区表也可以设置不同的压缩配置，这个常用于对数据进行冷热分离，比如对于非常老的数据，由于访问频率较低，可以考虑采用较大的压缩比，减少存储量。

BLOCKSIZE：

• 表的存储块大小，通常表数据对应的物理文件就是按 blocksize 的粒度增加，也就是初始就是 blocksize 大，并且保持 blocksize 的倍数。

• blocksize 大小在8192和2097152之间，必须是 8192 的倍数，默认是 32768。

• 在 AOCO 表中，每一列也可以设置自己的 blocksize，列的配置会覆盖表的配置。

物理文件：

• AOCO 表之所以能够按照列来设置压缩等参数，本质原因在于 AOCO 表中每一列的数据都会单独存储在一个文件中。因此不同文件之间可以按不同的参数进行存储，互不影响。

• 对于 AOCO 表，如果使用了分区，那么对于每一个分区的每一列都会有一个文件，如果一个表的分区很多，又是一张大宽表，那么产生的文件就会很多，也会对性能有一些影响。

最佳实践：

• AOCO 表通常用于数仓中的核心事实表，这种表字段多，数据量大，主要是用于 OLAP 场景，也就是查询的过程不会 SELECT * FROM，而是对其中部分字段进行读取和聚合。

• 由于 AOCO 表一般用于大表，因此经常搭配压缩和分区，以减少表的实际存储量来提升性能。

• 一般情况下，压缩格式选择 zlib，压缩级别可以采用折中的 4 或者 5，但是对于有大量重复值的字段，记得要采用 RLE_TYPE 压缩格式。

• blocksize 不要设置过大，特别是对于分区表，GP 对于每个分区的每个字段都会维护一个 buffer，blocksize 过大，会导致消耗的内存过大，通常就采用默认值 32768 即可。

四、修改表结构

单独列出这一节是因为 Heap，AORO 和 AOCO 这3种表在修改表结构时表现是不一样的，这也是大家容易忽视的地方。

对于不同的表类型，同样的修改语法耗时可能会差异很多，主要原因在于对于有些修改操作会导致表重写，而表重写的时间就取决于表本身的数据量。

以下列出了不同的表结构，在不同的 ALTER 语法下的行为，其中 YES 代表需要重写表，NO代表不需要重写表。

操作	Heap	AORO	AOCO
ADD COLUMN	NO	YES	NO
DROP COLUMN	NO	NO	NO
ALTER COLUMN TYPE	YES	YES	YES
ADD COLUMN DEFAULT NULL	YES	YES	NO
ADD COLUMN DEFAULT VALUE	YES	YES	NO

可以看出 AOCO 表由于每个列都是单独一个文件，因此在修改列结构时影响最小，这也是 AOCO 表的一个优势。

五、混合存储

一张表是否可以同时使用多种存储方式呢？对于分区表，是可以的。

混合存储一般用于这样的场景，对于一张按时间分区的表，通常对于不同时间点的数据行为是不一样的，比如对于最近的数据，会有较多的明细查询，而对于比较老的数据，则是以分析为主。同时由于业务可能要保存较长时间的数据，为了节约成本，较老的数据会考虑使用压缩比较大的存储方式。

混合存储的关键就是使用到了 GP 的交换分区语法，也就是将一张独立的表与自己的一个分区表进行交换，当然这里前提是新表的结构是一样，并且交换的过程没有新数据进入。

流程如下：

1.创建一张分区表(1到5月份，每月一张表)，采用 Heap 存储

CREATE TABLE hyper_storage (
	a int,
	b varchar(32),
	fdate date
) DISTRIBUTED BY (a)
PARTITION BY RANGE(fdate)
(
	PARTITION pn START ('2018-01-01'::date) END ('2018-06-01'::date) EVERY ('1 month'::interval),
	DEFAULT PARTITION pdefault
);

storage=# \d
                           List of relations
 Schema |             Name             | Type  |    Owner     | Storage
--------+------------------------------+-------+--------------+---------
 public | hyper_storage                | table | test | heap
 public | hyper_storage_1_prt_pdefault | table | test | heap
 public | hyper_storage_1_prt_pn_1     | table | test | heap
 public | hyper_storage_1_prt_pn_2     | table | test | heap
 public | hyper_storage_1_prt_pn_3     | table | test | heap
 public | hyper_storage_1_prt_pn_4     | table | test | heap
 public | hyper_storage_1_prt_pn_5     | table | test | heap

　　

2.现在要对1月份的表修改存储格式，因此创建一张新的 AOCO 表

CREATE TABLE exchange_table(
	a int,
	b varchar(32),
	fdate date
) WITH (appendonly=true, ORIENTATION=column, compresstype=zlib, compresslevel=6)
DISTRIBUTED BY (a)

　　

3.将1月份的数据导入新表

INSERT INTO exchange_table SELECT * FROM hyper_storage_1_prt_pn_1;

　　

4.交换分区

ALTER TABLE hyper_storage EXCHANGE PARTITION pn_1 WITH TABLE exchange_table;

　　

注：pn_1是1月份的分区表的 partitionname，可以从 pg_partitions 中查询得到

5.查看结果

storage=# \d
                                  List of relations
 Schema |             Name             | Type  |    Owner     |       Storage
--------+------------------------------+-------+--------------+----------------------
 public | hyper_storage                | table | test | heap
 public | hyper_storage_1_prt_pdefault | table | test | heap
 public | hyper_storage_1_prt_pn_1     | table | test | append only columnar
 public | hyper_storage_1_prt_pn_2     | table | test | heap
 public | hyper_storage_1_prt_pn_3     | table | test | heap
 public | hyper_storage_1_prt_pn_4     | table | test | heap
 public | hyper_storage_1_prt_pn_5     | table | test | heap
public | exchange_table  | table | test | heap

　　

这样1月份的分区表就变成了 AOCO 表，而其他分区表仍然是 Heap 表

六、对比测试

各类型表占用空间比较

选取 Heap，AORO，AOCO 三种表，分别采用压缩和不压缩2种方式（Heap表不支持压缩，AO 表压缩采用zlib格式，压缩级别设置为6），插入5亿条随机数据，然后使用

select pg_size_pretty(pg_relation_size('{tablename}'));

　　

查看表所占大小，结果如下：

各类型表大小比较.png

说明：可以看出 Heap 表占用空间更大，即使 AO 表不采用压缩。AOCO 表由于是按列进行存储，所以相比行存的 AORO 表压缩比更大。当然这三者的差距取决于数据的实际情况，一般生产环境中 Heap 表不会和 AO 表有如此大的差距。

各级别压缩率比较

使用 AOCO 表，zlib 压缩格式，选取不同的压缩级别，比较数据写入时间和表所占大小，由于 zlib 支持9个级别，这里选取1,6,9 三个级别进行比较，体现出趋势即可，结果如下：

各压缩级别比较.png

说明：实际生产环境中不同压缩级别的数据，压缩比的差距可能会更大。但可以看出，越高的压缩级别，在插入的时候越耗时，其它 SQL，类似 SELECT，UPDATE 等也都是一样。

写在最后

切记，从其它系统迁移数据到 GP 上来，第一件事情就是给每张表选择合适的存储格式，特别是核心表。

---

关注“腾讯云大数据”公众号，技术交流、最新活动、服务专享一站Get~