Redshift表大小

Question

这对我来说更像是一个令人费解的问题，并且想要理解为什么。

我有两个表，几乎相同，唯一的区别是一列的数据类型和排序键。

table                             mbytes    rows
stg_user_event_properties_hist    460948    2378751028
stg_user_event_properties_hist_1  246442    2513860837

尽管它们的行数几乎相同，但是大小接近于两倍。

这是表格结构

stg.stg_user_event_properties_hist
(
id                bigint,
source            varchar(20),
time_of_txn       timestamp,
product           varchar(50),
region            varchar(50),
city              varchar(100),
state             varchar(100),
zip               varchar(10),
price             integer,
category          varchar(50),
model             varchar(50),
origin            varchar(50),
l_code            varchar(10),
d_name            varchar(100),
d_id              varchar(10),
medium            varchar(255),
network           varchar(255),
campaign          varchar(255),
creative          varchar(255),
event             varchar(255),
property_name     varchar(100),
property_value    varchar(4000),
source_file_name  varchar(255),
etl_batch_id      integer,
etl_row_id        integer,
load_date         timestamp       
);



stg.stg_user_event_properties_hist_1
(
id                bigint,
source            varchar(20),
time_of_txn       timestamp,
product           varchar(50),
region            varchar(50),
city              varchar(100),
state             varchar(100),
zip               varchar(10),
price             integer,
category          varchar(50),
model             varchar(50),
origin            varchar(50),
l_code            varchar(10),
d_name            varchar(100),
d_id              varchar(10),
medium            varchar(255),
network           varchar(255),
campaign          varchar(255),
creative          varchar(255),
event             varchar(255),
property_name     varchar(100),
property_value    varchar(4000),
source_file_name  varchar(255),
etl_batch_id      integer,
etl_row_id        varchar(20),
load_date         timestamp
);

差异etl_row_id在_1中具有数据类型varchar（20），在另一个表中具有整数，并且第一个表在源列上具有sortkey。

什么是尺寸差异的解释？

更新：问题是压缩和排序键，即使使用CTAS 11 of 26创建的_1表具有不同的压缩设置，第一个表是使用14列的Compound SortKey创建的，重新创建没有排序键的表（它是历史记录）表格毕竟）尺寸下降到231GB。

Answer 1

怀疑较大的表具有不同的压缩设置或根本没有压缩。您可以使用我们的视图v_generate_tbl_ddl生成包含压缩设置的表DDL。

即使使用相同的压缩设置，表大小也可能因不同的排序键而异。排序键用于将数据放入磁盘上的块中。如果一个排序键将大量相似的列值放在一起，它将更好地压缩并且需要更少的空间。

Answer 2

这两个表的大小不同，因为基于sortkeys，一个表分配的块比另一个表多。对于较大的表，分发的方式是磁盘块没有被完全占用，因此需要更多的块来存储相同数量的数据。

这是因为Redshift的1MB块大小以及它在切片和节点之间存储数据的方式。通常，数据基于diststyle分布在不同的节点和切片上。对于你的情况，我假设这种分布是以循环方式发生的。因此slice1获取第一条记录，slice2获得第二条记录等。对于Redshift，最小块大小为1MB，每次新记录进入新切片时，都会分配1MB（即使记录只需要几KB）。对于同一切片的后续记录，数据将转到相同的1MB块，直到可能为止，之后在切片上分配新的1MB块。但是，如果在此片的第一个记录之后没有更多记录，它仍然占用1MB大小的第一个块。表的总大小是被占用的所有块的总和（不管块中存在多少数据）

Answer 3

表大小的差异可能是由于以下原因。

• 用于每列的编码。 （查询PG_TABLE_DEF）
• 用于表的分配键。 （查询PG_TABLE_DEF）
• 在桌子上进行真空。 （查询SVV VACUUM SUMMARY）

如果我做了一个错误的假设请评论，我将重新调整我的答案。