Greenplum 列存表(AO表)的膨胀和垃圾检查与空间收缩

Greenplum释放表的空间

Greenplum释放表的空间 1

1 Greenplum产生垃圾空间说明 1

2 查看表的储存类型 2

2.1 执行查看命令 2

2.2 名词解释 3

3 AO表分析 3

3.1 查看当前数据库中有哪些AO表 3

3.2 查看AO表的膨胀率 3

3.2.1 执行查看命令 3

3.2.3 名词解释 4

3.3 检查系统中膨胀率超过N的AO表 4

3.3.1 执行命令 4

3.3.2 名词解释 5

3.4 查看膨胀数据的占用大小 5

3.5 查看表的行数 5

3.6 释放膨胀的空间 6

2.7 查看释放后的占用空间 6

2.7.1 释放膨胀空间 6

2.7.2 再次查看AO的膨胀率 6

2.8 再次查看表的行数 7

2.9 使用更改随机的方式释放空间 7

2.9.1 查看膨胀占用空间 7

2.9.2 随机改变表的分布键 7

2.9.3 查看释放后的空间 7

2.10 使用多分布键的形式释放空间 8

2.10.1 执行重新分布命令 8

2.10.2 查看数据的膨胀率 8

4 AO表总结 8

4.1 查看表的行的个数 8

4.2 更新数据的行数与占用大小 9

4.2.1 更新数据 9

4.2.2 查看表的膨胀率 9

1 Greenplum产生垃圾空间说明

Greenplum支持行储存(HEAP储存)与列(append-only)储存,对于AO存储,虽然是appendonly,但实际上GP是支持DELETE和UPDATE的,被删除或更新的行,通过BITMAP来标记删除与修改。AO存储是块级组织,当一个块内的数据大部分都被删除或更新掉时,扫描它浪费的成本实际上是很高的。而PostgreSQL是通过HOT技术以及autovacuum来避免或减少垃圾的。但是Greenplum没有自动回收的worker进程,所以需要人为的触发。接下来就分析AO表与HEAP表的问题以及如何解答,执行空间的释放有3中方法分别是:

1、执行VACUUM。(当膨胀率大于gp_appendonly_compaction_threshold参数时),为共享锁。

2、执行VACUUM FULL。(不管gp_appendonly_compaction_threshold参数的设置,都会回收垃圾空间。),为DDL锁。

3、执行重分布。(不管gp_appendonly_compaction_threshold参数,都会回收垃圾空间。),为DDL锁。

2 查看表的储存类型

2.1 执行查看命令

stagging=# \timing

Timing is on.

stagging=# select distinct relstorage from pg_class ;

relstorage

------------

h

a

x

v

c

(5 rows)

Time: 6.132 ms

2.2 名词解释

timing 打开SQL的执行时间

h = 堆表(heap)、索引

a = append only row存储表

c = append only column存储表

x = 外部表(external table)

v = 视图

3 AO表分析

3.1 查看当前数据库中有哪些AO表

stagging=# select t2.nspname, t1.relname from pg_class t1, pg_namespace t2 where t1.relnamespace=t2.oid and relstorage in ('c', 'a');

nspname | relname

---------+-------------------------------

test_ao | ao_table_test

(12 rows)

Time: 6.828 ms

可以看出来 ao_table_test为AO表

3.2 查看AO表的膨胀率

表的膨胀率也就是表中执行DELETE和UPDATE产生的垃圾

3.2.1 执行查看命令

stagging=# select * from gp_toolkit.__gp_aovisimap_compaction_info('test_ao.ao_table_test'::regclass);

NOTICE: gp_appendonly_compaction_threshold = 10

(240 rows)

Time: 127.750 ms

3.2.3 名词解释

test_ao : schema的名字

ao_table_test:当前schema下的表

gp_appendonly_compaction_threshold: AO的压缩进程,目前设置的是10

content:对应gp_configuration.content表示greenplum每个节点的唯一编号。

datafile:这条记录对应的这个表的其中一个数据文件的编号,每个数据文件假设1GB。

hidden_tupcount:有多少条记录已更新或删除(不可见)。

total_tupcount:总共有多少条记录(包括已更新或删除的记录)。

percent_hidden:不可见记录的占比。如果这个占比大于gp_appendonly_compaction_threshold参数,那么执行vacuum时,会收缩这个数据文件。

compaction_possible:这个数据文件是否可以被收缩。(通过gp_appendonly_compaction_threshold参数和percent_hidden值判断)。

在以上中可以看出在17节点上的第1号文件有2369294记录其中有671375条记录被更新或删除,其中不可见的比例为28.34%

3.3 检查系统中膨胀率超过N的AO表

3.3.1 执行命令

stagging=# select * from (select t2.nspname, t1.relname, (gp_toolkit.__gp_aovisimap_compaction_info(t1.oid)).* from pg_class t1, pg_namespace t2 where t1.relnamespace=t2.oid and relstorage in ('c', 'a')) t where t.percent_hidden > 0.2;

(144 rows)

Time: 864.715 ms

以上命令是查询膨胀率超过千分之2的AO表

3.3.2 名词解释

nspname: 表示查询的schema的名字

relname: 是当前schema的表的名字

在以上数据中可以看出在每个节点上的膨胀率也不同

3.4 查看膨胀数据的占用大小

stagging=# select pg_size_pretty(pg_relation_size('test_ao.ao_table_test'));

pg_size_pretty

----------------

16 GB

(1 row)

Time: 32.806 ms

在以上可以看出膨胀率占用了16G的空间

3.5 查看表的行数

stagging=# select count(*) from test_ao.ao_table_test;

count

-----------

140324396

(1 row)

Time: 1842.706 ms

3.6 释放膨胀的空间

在以上的数据中可以看出膨胀率大于了gp_appendonly_compaction_threshold的值可以直接使用vacuum命令进行收缩

stagging=# vacuum test_ao.ao_table_test;

VACUUM

Time: 57800.144 ms

3.7 查看释放后的占用空间

3.7.1 释放膨胀空间

stagging=# select pg_size_pretty(pg_relation_size('test_ao.ao_table_test'));

pg_size_pretty

----------------

8859 MB

(1 row)

Time: 34.990 ms

以上可以看出已经释放了大部分的空间

3.7.2 再次查看AO的膨胀率

stagging=# select * from (select t2.nspname, t1.relname, (gp_toolkit.__gp_aovisimap_compaction_info(t1.oid)).* from pg_class t1, pg_namespace t2 where t1.relnamespace=t2.oid and relstorage in ('c', 'a')) t where t.percent_hidden > 0.01;

以上命令是查询膨胀率超过万分之1的AO表

3.8 再次查看表的行数

stagging=# select count(*) from test_ao.ao_table_test;

count

-----------

140324396

(1 row)

Time: 1680.919 ms

从以上可以看出与第一次查询出来的行数一直

3.9 使用更改随机的方式释放空间

3.9.1 查看膨胀占用空间

stagging=# select * from (select t2.nspname, t1.relname, (gp_toolkit.__gp_aovisimap_compaction_info(t1.oid)).* from pg_class t1, pg_namespace t2 where t1.relnamespace=t2.oid and relstorage in ('c', 'a')) t where t.percent_hidden > 0.01;

3.9.2 随机改变表的分布键

stagging=# alter table test_ao.ao_table_test set with (reorganize=true) distributed randomly;

ALTER TABLE

Time: 81169.170 ms

3.9.3 查看释放后的空间

stagging=# select * from (select t2.nspname, t1.relname, (gp_toolkit.__gp_aovisimap_compaction_info(t1.oid)).* from pg_class t1, pg_namespace t2 where t1.relnamespace=t2.oid and relstorage in ('c', 'a')) t where t.percent_hidden > 0.01;

注意在执行随机分布键是在非业务的时候执行,执行distribute会执行排它锁不,要堵塞业务。

3.10 使用多分布键的形式释放空间

3.10.1 执行重新分布命令

stagging=# alter table test_ao.ao_table_test set with (reorganize=true) distributed by (pripid,s_ext_nodenum);

ALTER TABLE

Time: 82621.274 ms

3.10.2 查看数据的膨胀率

stagging=# select * from (select t2.nspname, t1.relname, (gp_toolkit.__gp_aovisimap_compaction_info(t1.oid)).* from pg_class t1, pg_namespace t2 where t1.relnamespace=t2.oid and relstorage in ('c', 'a')) t where t.percent_hidden > 0.01;

注意在执行随机分布键是在非业务的时候执行,执行distribute会执行排它锁不,要堵塞业务。

4 AO表总结

4.1 查看表的行的个数

stagging=# select count(*) from test_ao.ao_table_test;

count

-----------

140324396

(1 row)

Time: 1764.584 ms

4.2 更新数据的行数与占用大小

4.2.1 更新数据

stagging=# update test_ao.ao_table_test set alttime='2018-10-23 11:54:57.000000' where nodenum='850000';

受影响的行: 5701,7349

时间: 104.007s

4.2.2 查看表的膨胀率

stagging=# select * from (select t2.nspname, t1.relname, (gp_toolkit.__gp_aovisimap_compaction_info(t1.oid)).* from pg_class t1, pg_namespace t2 where t1.relnamespace=t2.oid and relstorage in ('c', 'a')) t where t.percent_hidden > 0.01;

(48 rows)

Time: 874.505 ms

在以上数据中可以看出57017349除以140324396大概是40% ,膨胀率大概是28.88左右。

原创声明,本文系作者授权云+社区发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

编辑于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏nnngu

Hibernate的关联映射

首先我们了解一个名词ORM,全称是(Object Relational Mapping),即对象关系映射。ORM的实现思想就是将关系型数据库中表的数据映射成对象...

2905
来自专栏企鹅号快讯

全文搜索引擎Elasticsearch入门教程

全文搜索属于最常见的需求,开源的Elasticsearch(以下简称 Elastic)是目前全文搜索引擎的首选。 它可以快速地储存、搜索和分析海量数据。维基百科...

2407
来自专栏小樱的经验随笔

BugkuCTF SQL注入1

1794
来自专栏xingoo, 一个梦想做发明家的程序员

DB Cache

1 DB Cache 是以bock为单位组织的缓冲区,不同大小的BLOCK对应不同的缓冲区参数 2 DB Cache的命中率越高,访问性能就越好 3 Cache...

2129
来自专栏别先生

Oracle的登陆问题和初级学习增删改查(省略安装和卸载)

1:学习Oracle首先需要安装Oracle,网上已经有很多很多教程了,这里不做叙述,自己百度即可,这里安装的标准版,个人根据需求安装学习或者企业开发即可。如果...

1946
来自专栏数据库新发现

数据库服务:数据库表空间扩容

http://www.enmotech.com/services/service.html(专业数据库服务)

1464
来自专栏三丰SanFeng

Linux同步机制 - 多线程开发总结

1 对于CPU开销大的场景,能利用多核,就尽量利用多核(常常自以为某需求的运算量不大,且CPU足够快,就偷懒写个单线程,结果效率很低) 2 使用多线程的时候,默...

2139
来自专栏GreenLeaves

oracle 表空间tablespace

一、Oracle 表空间的组成 Everoone knows Oracle数据库真正存放数据的是数据文件,Oracle表空间是逻辑上的概念,他在物理上是并不存在...

2978
来自专栏java学习

Hibernate学习笔记2

定义hbm.xml映射文件和pojo类时都需要定义主键,Hibernate中定义的主键类型包括:自然主键和代理主键:

1034
来自专栏IT笔记

Solr如何使用游标进行深度分页查询

通常,我们的应用系统,如果要做一次全量数据的读取,大多数时候,采用的方式会是使用分页读取的方式,然而 分页读取的方式,在大数据量的情况下,在solr里面表现并...

4287

扫码关注云+社区

领取腾讯云代金券