Question

我有一张包含1.3亿条记录的表格。将数据直接转储到未编制索引的表中为15GB。当我将该表转储到具有相同结构但具有分发键的表中时，该表增长到185GB。我在AWS文档中看不到这样的内容。这是压缩问题吗？

CREATE TABLE mongousages_withkey
(
   serialnumber      varchar(56),
   "run date"        date,
   "run usage id"    char(1016),
   datetime          varchar(37),
   alteryxversion    varchar(16),
   guid              varchar(40),
   "tool name"       varchar(258),
   "tool count"      float8,
   email             char(256),
   "last load date"  date
)
sortkey(serialnumber);

Answer 1

当您第一次COPY数据时，Redshift会自动将压缩应用于新表。 http://docs.aws.amazon.com/redshift/latest/dg/c_Loading_tables_auto_compress.html

您没有使用INSERT为您加载的版本指定压缩，因此您有无压缩。

运行ANALYZE COMPRESSION mongousages_withkey;并根据建议的编码创建一个新表。像这样：

CREATE TABLE mongousages_withkey (
    serialnumber      VARCHAR(56)  NULL ENCODE lzo
   ,"run date"        DATE         NULL ENCODE runlength
   ,"run usage id"    CHAR(1016)   NULL ENCODE lzo
   ,datetime          VARCHAR(37)  NULL ENCODE lzo
   ,alteryxversion    VARCHAR(16)  NULL ENCODE lzo
   ,guid              VARCHAR(40)  NULL ENCODE lzo
   ,"tool name"       VARCHAR(258) NULL ENCODE lzo
   ,"tool count"      FLOAT8       NULL ENCODE delta
   ,email             CHAR(256)    NULL ENCODE lzo
   ,"last load date"  DATE         NULL ENCODE runlength
)
DISTSTYLE KEY
DISTKEY(serialnumber)
SORTKEY(serialnumber)
;

Answer 2

哦，你遇到了这个神奇的问题。

Redshift有1 MB的数据块，因为它是柱状的，所有列都是分开存储的。现在假设您的表中有10列，因此第一个传入记录需要10 MB（1 MB * 10列）。现在，根据您选择的distkey和该字段的基数，Redshift可能会也可能不会在第一条记录所在的同一块中存储每列的下一个值。如果它决定将所有列存储在新块中，则意味着您的第二条记录也值10 MB。因此，1.3亿条记录有可能膨胀至（130米* 10）MB。我认为你的情况不是这么极端，因此很少有值已经分配了块，而其他值则会进入新的内存块。

我建议你尝试一个不同的distkey，因为这个看起来不是一个好的。

只需添加DistKey，Redshift表就会从15GB增加到185GB

2 个答案: