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

简介: 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元数据空间。

目录
相关文章
|
前端开发
2023Web前端开发八股文&面试题(万字系列)——这篇就够了!
2023Web前端开发八股文&面试题(万字系列)——这篇就够了!
2897 2
|
Python
Anaconda安装找不到的依赖包,以DBUtils包为例
在使用Anaconda安装依赖包时,有时会找不到包,可以通过本文中方法切换进行下载
1253 0
Anaconda安装找不到的依赖包,以DBUtils包为例
|
7月前
|
负载均衡 Java 应用服务中间件
Nacos注册中心
本文介绍了Nacos的安装部署、服务注册与发现、分级模型、负载均衡策略、权重控制、环境隔离及临时/持久化实例等核心功能,涵盖从本地启动到生产级配置的完整实践流程。通过实际操作演示了如何整合Spring Cloud Alibaba实现服务治理,并深入解析其架构设计与应用场景。
 Nacos注册中心
|
12月前
|
人工智能 自然语言处理 算法
微软AutoGen:多智能体协作的工业级解决方案
作为一名长期关注AI技术发展的开发者,我深深被微软AutoGen框架所展现的多智能体协作能力所震撼。在当今企业数字化转型的浪潮中,单一AI模型已难以满足复杂业务场景的需求,而AutoGen框架的出现为我们提供了一个革命性的解决方案。它不仅突破了传统单体AI的局限性,更通过其独特的多智能体协作机制,实现了真正意义上的"AI团队协作"。经过深入研究和实践,我发现AutoGen在智能体角色定义、通信协议设计、任务协调机制等方面都展现出了工业级的成熟度。特别是其对话驱动的编程范式和灵活的工作流编排能力,为企业级AI应用开发带来了前所未有的便利性和可扩展性。本文将从技术架构、实现原理到企业应用等多个维度
589 1
微软AutoGen:多智能体协作的工业级解决方案
|
前端开发 开发者 UED
React 18 与之前版本的主要区别
【10月更文挑战第12天】 总的来说,React 18 的这些区别体现了 React 团队对于提升应用性能、用户体验和开发效率的持续努力。开发者需要适应这些变化,充分利用新特性来构建更出色的应用。同时,随着技术的不断发展,React 也将继续演进,为开发者带来更多的创新和便利。
893 58
|
11月前
|
算法 数据挖掘 API
《拼多多 API 助力,拼多多店铺商品好评率快速提升》
本文介绍如何利用拼多多开放平台API自动化管理商品评论,提升店铺好评率。通过获取评论数据、自动回复差评、数据分析与批量操作,商家可高效优化好评率,提升店铺曝光与转化。内容涵盖API使用步骤、优势及注意事项,助力商家实现数据驱动的精准运营,提升顾客满意度。
|
存储 人工智能 开发工具
AI场景下的对象存储OSS数据管理实践
本文介绍了对象存储(OSS)在AI业务中的应用与实践。内容涵盖四个方面:1) 对象存储作为AI数据基石,因其低成本和高弹性成为云上数据存储首选;2) AI场景下的对象存储实践方案,包括数据获取、预处理、训练及推理阶段的具体使用方法;3) 国内主要区域的默认吞吐量提升至100Gbps,优化了大数据量下的带宽需求;4) 常用工具介绍,如OSSutil、ossfs、Python SDK等,帮助用户高效管理数据。重点讲解了OSS在AI训练和推理中的性能优化措施,以及不同工具的特点和应用场景。
1276 10
|
缓存 安全 网络安全
|
存储 开发工具 Android开发
Android系统 权限组管理和兼容性
Android系统 权限组管理和兼容性
708 0