Стол Redshift растет с 15 до 185 ГБ только от добавления DistKey

У меня есть таблица с 130 миллионами записей. Прямой дамп данных в неиндексированную таблицу составляет 15 ГБ. Когда я кладу этот стол в таблицу той же структуры, но с ключом распределения, таблица вырастает до 185 ГБ. Я не вижу ничего подобного в документации AWS. Это проблема сжатия?Стол Redshift растет с 15 до 185 ГБ только от добавления DistKey

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);

источник

2016-02-26 RagePwn

Для того чтобы дать вам солидный ответ, вам нужно предоставить более подробную информацию о своей таблице DDL. –

@JoeHarris Отредактировано сообщение с DDL. Серийный номер - это адрес электронной почты (не спрашивайте). – RagePwn

У вас есть сжатие вообще? Вы делали свой 'COPY' с включенным« COMPUPDATE ON »? Является ли этот DDL до или после DDL? Вы упоминаете 'DISTKEY', но DDL имеет только' SORTKEY. :) –

Redshift автоматически применяет сжатие к новым таблицам, когда вы в COPY данных в первый раз. 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) 
;

источник

2016-03-01 18:05:30

После ответа на ваш второй комментарий я пошел и посмотрел все кодировки сжатия, применяя их к новой таблице, которая выглядит очень похожей на то, что вы разместили. Новая таблица - 23 ГБ. Большое спасибо за Вашу помощь! – RagePwn

Рад, что это сработало. Redshift должен автоматически выполнять сжатие по умолчанию. Я действительно не знаю, почему они оставляют это до пользователя. –

О, вы столкнулись с этой магической проблемой.

Redshift имеет 1 МБ блоков данных, и поскольку он является столбчатым, все столбцы хранятся отдельно. Теперь предположим, что у вас 10 столбцов в таблице, поэтому первая входящая запись занимает 10 МБ (1 МБ * 10 столбцов). Теперь, основываясь на выбранном distkey и мощности этого поля, Redshift может хранить или не сохранять следующие значения для каждого столбца в том же блоке, где была первая запись. Если он решит сохранить все столбцы в новых блоках, значит, ваша вторая запись также стоит 10 МБ. Таким образом, 130 миллионов записей могут раздуваться до (130 м * 10) МБ. Я думаю, что ваше дело не в этом крайнем случае, поэтому несколько значений уже будут выделены блоками, а другие - новыми блоками памяти.

Я предлагаю вам попробовать другой distkey, так как этот не выглядит как хороший.

источник

2016-02-26 12:57:42 Paladin

Стол Redshift растет с 15 до 185 ГБ только от добавления DistKey

ответ

Смежные вопросы