阿里云HybridDB for PG实践 - 列存储加字段和默认值

本文涉及的产品
云原生数据库 PolarDB MySQL 版,Serverless 5000PCU 100GB
云原生数据库 PolarDB 分布式版,标准版 2核8GB
云数据库 RDS MySQL Serverless,0.5-2RCU 50GB
简介:

标签

PostgreSQL , Greenplum , 相对偏移 , 列存储 , appendonly , AO表


背景

Greenplum的Append only table支持更新、删除。通过什么支持呢?bitmap文件,标记被删除的行。

因此在更新,删除后,数据可能膨胀。

另一方面,列存储每列一个文件,同一行通过偏移对应起来。例如INT8的两个字段,通过偏移很快能找到某一行的A列对应的B列。

接下来谈谈加字段,在加字段时,AO表示不会REWRITE TABLE的。如果AO表以及有一些垃圾(被删除的数据)记录后,加的字段会使用相对偏移吗(换句话说,需不需要填充已删除的记录),答案是要填充。

例子

1、创建3张AO列存表。

postgres=# create table tbl1 (id int, info text) with (appendonly=true, blocksize=8192, compresstype=none, orientation=column);  
NOTICE:  Table doesn't have 'DISTRIBUTED BY' clause -- Using column named 'id' as the Greenplum Database data distribution key for this table.  
HINT:  The 'DISTRIBUTED BY' clause determines the distribution of data. Make sure column(s) chosen are the optimal data distribution key to minimize skew.  
CREATE TABLE  
  
postgres=# create table tbl2 (id int, info text) with (appendonly=true, blocksize=8192, compresstype=none, orientation=column);  
NOTICE:  Table doesn't have 'DISTRIBUTED BY' clause -- Using column named 'id' as the Greenplum Database data distribution key for this table.  
HINT:  The 'DISTRIBUTED BY' clause determines the distribution of data. Make sure column(s) chosen are the optimal data distribution key to minimize skew.  
CREATE TABLE  
  
postgres=# create table tbl3 (id int, info text) with (appendonly=true, blocksize=8192, compresstype=none, orientation=column);  
NOTICE:  Table doesn't have 'DISTRIBUTED BY' clause -- Using column named 'id' as the Greenplum Database data distribution key for this table.  
HINT:  The 'DISTRIBUTED BY' clause determines the distribution of data. Make sure column(s) chosen are the optimal data distribution key to minimize skew.  
CREATE TABLE  

2、前两张分别插入1000万记录,最后一张插入2000万记录。

postgres=# insertinto tbl1 select generate_series(1,10000000),'test';  
INSERT 0 10000000  
postgres=# insert into tbl2 select generate_series(1,10000000),'test';  
INSERT 0 10000000  
postgres=# insert into tbl3 select generate_series(1,20000000),'test';  
INSERT 0 20000000  

3、分析表,并记录它们的大小

postgres=# analyze tbl1;  
ANALYZE  
postgres=# analyze tbl2;  
ANALYZE  
postgres=# analyze tbl3;  
ANALYZE  
  
postgres=# select pg_size_pretty(pg_relation_size('tbl1'));  
 pg_size_pretty   
----------------  
 88 MB  
(1 row)  
postgres=# select pg_size_pretty(pg_relation_size('tbl2'));  
 pg_size_pretty   
----------------  
 88 MB  
(1 row)  
postgres=# select pg_size_pretty(pg_relation_size('tbl3'));  
 pg_size_pretty   
----------------  
 173 MB  
(1 row)  

4、更新第一张表,全表更新。并记录更新后的大小,翻了一倍。

postgres=# update tbl1 set info='test';  
UPDATE 10000000  
postgres=# analyze tbl1;  
ANALYZE  
postgres=# select pg_size_pretty(pg_relation_size('tbl1'));  
 pg_size_pretty   
----------------  
 173 MB  
(1 row)  

5、对三个表添加字段,设置默认值。

postgres=# alter table tbl1 add column c1 int8 default 1;  
ALTER TABLE  
postgres=# alter table tbl2 add column c1 int8 default 1;  
ALTER TABLE  
postgres=# alter table tbl3 add column c1 int8 default 1;  
ALTER TABLE  

6、分析表,查看表的大小。

postgres=# analyze tbl1;  
ANALYZE  
postgres=# analyze tbl2;  
ANALYZE  
postgres=# analyze tbl3;  
ANALYZE  
  
postgres=# select pg_size_pretty(pg_relation_size('tbl1'));  
 pg_size_pretty   
----------------  
 325 MB  
(1 row)  
  
postgres=# select pg_size_pretty(pg_relation_size('tbl2'));  
 pg_size_pretty   
----------------  
 163 MB  
(1 row)  
  
postgres=# select pg_size_pretty(pg_relation_size('tbl3'));  
 pg_size_pretty   
----------------  
 325 MB  
(1 row)  

很显然,AO表在添加字段时,以已有文件的记录数为准(即使全部都删除了,也需要在新增字段上初始化这个值),。

如果有相对偏移量的概念,至少tbl2可以忽略前1000万行的偏移。

堆表不存在这个问题,因为堆表加字段会REWRITE全表。

表膨胀的处理

《如何检测、清理Greenplum垃圾 - 阿里云HybridDB for PG最佳实践》

相关文章
|
1月前
|
SQL 分布式计算 关系型数据库
阿里云E-MapReduce Trino专属集群外连引擎及权限控制踩坑实践
本文以云厂商售后技术支持的角度,从客户的需求出发,对于阿里云EMR-Trino集群的选型,外连多引擎的场景、Ldap以及Kerberos鉴权等问题进行了简要的实践和记录,模拟客户已有的业务场景,满足客户需求的同时对过程中的问题点进行解决、记录和分析,包括但不限于Mysql、ODPS、Hive connector的配置,Hive、Delta及Hudi等不同表格式读取的兼容,aws s3、阿里云 oss协议访问异常的解决等。
|
2月前
|
存储 监控 安全
360 企业安全浏览器基于阿里云数据库 SelectDB 版内核 Apache Doris 的数据架构升级实践
为了提供更好的日志数据服务,360 企业安全浏览器设计了统一运维管理平台,并引入 Apache Doris 替代了 Elasticsearch,实现日志检索与报表分析架构的统一,同时依赖 Doris 优异性能,聚合分析效率呈数量级提升、存储成本下降 60%....为日志数据的可视化和价值发挥提供了坚实的基础。
360 企业安全浏览器基于阿里云数据库 SelectDB 版内核 Apache Doris 的数据架构升级实践
|
2月前
|
存储 数据可视化 数据管理
基于阿里云服务的数据平台架构实践
本文主要介绍基于阿里云大数据组件服务,对企业进行大数据平台建设的架构实践。
719 2
|
1月前
|
存储 调度 块存储
阿里云连续两年斩获全球存储顶会FAST最佳论文
阿里云连续两年斩获全球存储顶会FAST最佳论文
320 0
|
29天前
|
SQL 存储 API
阿里云实时计算Flink的产品化思考与实践【下】
本文整理自阿里云高级产品专家黄鹏程和阿里云技术专家陈婧敏在 FFA 2023 平台建设专场中的分享。
110805 100
阿里云实时计算Flink的产品化思考与实践【下】
|
1月前
|
弹性计算 网络协议 关系型数据库
网络技术基础阿里云实验——企业级云上网络构建实践
实验地址:<https://developer.aliyun.com/adc/scenario/65e54c7876324bbe9e1fb18665719179> 本文档指导在阿里云上构建跨地域的网络环境,涉及杭州和北京两个地域。任务包括创建VPC、交换机、ECS实例,配置VPC对等连接,以及设置安全组和网络ACL规则以实现特定服务间的互访。例如,允许北京的研发服务器ECS-DEV访问杭州的文件服务器ECS-FS的SSH服务,ECS-FS访问ECS-WEB01的SSH服务,ECS-WEB01访问ECS-DB01的MySQL服务,并确保ECS-WEB03对外提供HTTP服务。
|
1月前
|
云安全 人工智能 安全
|
1月前
|
弹性计算 算法 应用服务中间件
倚天使用|Nginx性能高27%,性价比1.5倍,基于阿里云倚天ECS的Web server实践
倚天710构建的ECS产品,基于云原生独立物理核、大cache,结合CIPU新架构,倚天ECS在Nginx场景下,具备强大的性能优势。相对典型x86,Http长连接场景性能收益27%,开启gzip压缩时性能收益达到74%。 同时阿里云G8y实例售价比G7实例低23%,是Web Server最佳选择。
|
1月前
|
弹性计算 NoSQL 测试技术
倚天使用|Redis性能高30%,阿里云倚天ECS性能摸底和迁移实践
Redis在倚天ECS环境下与同规格的基于 x86 的 ECS 实例相比,Redis 部署在基于 Yitian 710 的 ECS 上可获得高达 30% 的吞吐量优势。成本方面基于倚天710的G8y实例售价比G7实例低23%,总性价比提高50%;按照相同算法,相对G8a,性价比为1.4倍左右。
137509 5
|
1月前
|
分布式计算 关系型数据库 OLAP
阿里云AnalyticDB基于Flink CDC+Hudi实现多表全增量入湖实践
阿里云AnalyticDB基于Flink CDC+Hudi实现多表全增量入湖实践
78 0