如何评估Greenplum master 空间以及segment元数据占用的空间.

本文涉及的产品
云原生数据库 PolarDB 分布式版,标准版 2核8GB
RDS PostgreSQL Serverless,0.5-4RCU 50GB 3个月
推荐场景:
对影评进行热评分析
云数据库 RDS SQL Server,基础系列 2核4GB
简介: Greenplum master节点是用来存储元数据的,包括 :序列,表,临时表,分区,函数,视图,类型,操作符,规则,触发器 等。 segment 上也会存储部分元数据,序列,表,临时表,函数,视图,类型,操作符,规则,触发器 等。 master比segment更多的信息包括:分布策略

Greenplum master节点是用来存储元数据的,包括 :
序列,表,临时表,分区,函数,视图,类型,操作符,规则,触发器 等。

segment 上也会存储部分元数据,
序列,表,临时表,函数,视图,类型,操作符,规则,触发器 等。

master比segment更多的信息包括:
分布策略,分区表,以及一些特殊的配置元数据。

gp_distribution_policy 
pg_partition 
pg_partition_encoding 
pg_partition_rule 
pg_statistic  

仅仅从元数据的角度来看,master比segment存储的信息略多一些,主要是表的分布策略和表分区的定义。

如何评估master的空间?
主要考虑几个因素 :
.1. 定义多少个对象
序列对应的元表: pg_class , pg_statistic, pg_attribute 平均每个序列一条记录
10万个序列,约占用30万条元数据。

表对应的元表: pg_class (2), pg_statistic ( 64, only on master ) , pg_attribute ( 64 ) ,gp_distribution_policy (1)。 (有变长字段,会新增TOAST元数据)
1000万张表(含分区表),约占用14亿条元数据。

临时表对应的元表: pg_class (2), pg_statistic ( 64, only on master ) , pg_attribute ( 64 ) 。 (有变长字段,会新增TOAST元数据)
1万张临时表,约占用130万条元数据。

分区: pg_partition (每个表1条), pg_partition_encoding (一般0), pg_partition_rule (每个分区表一条)
2万主表,900万个分区表,约占用902万条元数据。

函数:pg_proc (每个函数1条)
10万函数,约占用10万条元数据。

视图:pg_class
10万视图,约占用10万条元数据。

类型:pg_type
1万类型,约占用1万条元数据。

操作符:pg_operator, pg_op...
1万操作符,约占用5万条元数据。

规则:pg_rewrite
1万规则,约占用1万条元数据。

触发器:pg_trigger
1万个触发器,约占用1万条元数据。

.2. 是否使用临时对象
临时表,会产生元数据,会话关闭后,自动释放,从而产生垃圾,可能导致元数据膨胀。

.3. 膨胀率
不断的新增,删除表。或修改字段定义。会导致元数据变化,可能导致元数据膨胀。
特别是存在长事务时,由于只能回收到该事务起点以前的事务产生的垃圾,这样容易造成垃圾积累。
假设膨胀率为30%,正常情况下比这个要少点。

如何推算master节点需要多少空间?
首先需要评估每个元表的平均记录大小, 单位字节:

postgres=# select relname,relkind,round((relpages::numeric*8*1024)/reltuples::numeric,2) from pg_class where relpages<>0 and reltuples<>0 and relkind='r' and reltuples>100 order by 1;
           relname           | relkind |  round  
-----------------------------+---------+---------
 gp_distribution_policy      | r       |   40.96
 gp_fastsequence             | r       |   47.63
 gp_persistent_relation_node | r       |   33.57
 gp_relation_node            | r       |   39.77
 pg_aggregate                | r       |   60.68
 pg_amop                     | r       |   29.20
 pg_amproc                   | r       |   31.51
 pg_appendonly               | r       |  163.84
 pg_attrdef                  | r       |  160.63
 pg_attribute                | r       |   93.85
 pg_attribute_encoding       | r       |   83.22
 pg_cast                     | r       |   30.57
 pg_class                    | r       |  137.23
 pg_constraint               | r       |  548.95
 pg_conversion               | r       |   62.06
 pg_depend                   | r       |   21.42
 pg_description              | r       |   17.75
 pg_index                    | r       |   77.14
 pg_inherits                 | r       |   42.67
 pg_opclass                  | r       |   58.10
 pg_operator                 | r       |   48.19
 pg_partition_rule           | r       |  341.33
 pg_proc                     | r       |   50.83
 pg_rewrite                  | r       | 1079.57
 pg_stat_last_operation      | r       |  138.51
 pg_statistic                | r       |   78.21
 pg_type                     | r       |   93.19
 pg_window                   | r       |   28.44
 sql_features                | r       |   25.24
 supplier                    | r       |   38.89

其次,需要告知在集群中有多少元数据。
假设用户需要在GP集群中创建 :
10万个序列,1000万张表(包含分区表),同时存在1万张临时表,10万函数,10万视图,1万自定义类型,1万自定义操作符,1万条规则,1万个触发器。
需要
约14.1090亿条元数据,平均每条元数据假设200字节(实际可能更小,参考各个元表的relpages81024/reltuples 得到的一个参考值),约260GB。
算上膨胀率,Master约占用空间338GB空间。

segment的元数据大小评估:
需要扣除

gp_distribution_policy 
pg_partition 
pg_partition_encoding 
pg_partition_rule 
pg_statistic   

上面的例子,约比master少7亿数据。约占170GB元数据空间。

目录
相关文章
|
存储 关系型数据库 MySQL
空闲空间管理和文件系统结构的优化策略
对于有科班背景的读者,可以跳过本系列文章。这些文章的主要目的是通过简单易懂的汇总,帮助非科班出身的读者理解底层知识,进一步了解为什么在面试中会涉及这些底层问题。否则,某些概念将始终无法理解。这些计算机基础文章将为你打通知识的任督二脉,祝你在编程领域中取得成功!
空闲空间管理和文件系统结构的优化策略
|
存储 算法 关系型数据库
带你读《存储漫谈:Ceph原理与实践》——2.3.1 PG 数量的选择
带你读《存储漫谈:Ceph原理与实践》——2.3.1 PG 数量的选择
|
SQL 网络安全 调度
|
SQL Oracle 关系型数据库
|
存储 关系型数据库 MySQL