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列的Composite SortKey创建的，没有排序键的情况下重新创建了该表（这是一个历史表全部）的容量降至231GB。

Answer 1

这两个表的大小不同，因为根据排序键，一个表比另一个表分配了更多的块。对于更大的表，分发的方式是磁盘块未完全占用，因此需要更多的块来存储相同数量的数据。

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

Answer 2

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

用于每列的编码。（查询PG_TABLE_DEF）
用于表的分配键。（查询PG_TABLE_DEF）
在表上执行的真空。（查询SVV_VACUUM_SUMMARY）

如果我做出了错误的假设，请发表评论，然后重新调整答案。

Answer 3

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

即使压缩设置相同，表大小也会因不同的排序键而异。排序键用于将数据放入磁盘上的块中。如果一种排序键将许多相似的列值放在一起，则压缩效果更好，所需空间也较小。

红移表大小

3 个答案: