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

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

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

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

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

gp_distribution_policy 
pg_partition 
pg_partition_encoding 
pg_partition_rule 
pg_statistic  
AI 代码解读

仅仅从元数据的角度来看,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
AI 代码解读

其次,需要告知在集群中有多少元数据。
假设用户需要在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   
AI 代码解读

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

目录
打赏
0
0
0
0
20696
分享
相关文章
【YashanDB知识库】崖山有哪些内存参数,Share Pool各个参数之间有什么关系
【YashanDB知识库】崖山有哪些内存参数,Share Pool各个参数之间有什么关系
【YashanDB知识库】崖山有哪些内存参数,Share Pool各个参数之间有什么关系
【YashanDB 知识库】崖山有哪些内存参数,Share Pool 各个参数之间有什么关系
在使用YashanDB时,用户常对内存参数配置有疑问,尤其是23.2及以上版本中,如SQL_POOL_SIZE+DICTIONARY_CACHE_SIZE超100报错,影响跑批性能。主要内存参数包括SHARE_POOL_SIZE、SQL_POOL_SIZE、DICTIONARY_CACHE_SIZE等,需合理配置以优化性能。SHARE POOL内含多个POOL,可动态调整。具体配置方法及观察使用情况的方式详见官网文档。
|
8月前
|
ADBPG&Greenplum成本优化问题之排查并清理冗余索引以优化空间使用如何解决
ADBPG&Greenplum成本优化问题之排查并清理冗余索引以优化空间使用如何解决
76 2
PolarDB产品使用问题之在执行ALTER TABLE语句后,备份数据的物理空间占用增加,是什么原因
PolarDB产品使用合集涵盖了从创建与管理、数据管理、性能优化与诊断、安全与合规到生态与集成、运维与支持等全方位的功能和服务,旨在帮助企业轻松构建高可用、高性能且易于管理的数据库环境,满足不同业务场景的需求。用户可以通过阿里云控制台、API、SDK等方式便捷地使用这些功能,实现数据库的高效运维与持续优化。
空闲空间管理和文件系统结构的优化策略
对于有科班背景的读者,可以跳过本系列文章。这些文章的主要目的是通过简单易懂的汇总,帮助非科班出身的读者理解底层知识,进一步了解为什么在面试中会涉及这些底层问题。否则,某些概念将始终无法理解。这些计算机基础文章将为你打通知识的任督二脉,祝你在编程领域中取得成功!
126 1
空闲空间管理和文件系统结构的优化策略
MySQL Innodb表共享空间损坏无法启动
启动mysql后随即就又关闭了,mysql服务启动失败!!
MySQL Innodb表共享空间损坏无法启动

热门文章

最新文章

下一篇
oss创建bucket
AI助理

你好,我是AI助理

可以解答问题、推荐解决方案等