ВЫБЕРИТЕ INTO С НЕНУЛЕВЫМ ограничением Redshift

#amazon-redshift

#amazon-redshift

Вопрос:

Я создаю новую таблицу dos3 из dos, используя SELECT INTO в Redshift. Однако, хотя location_code является первичным ключом (NOT NULL) в table dos, после выполнения операции SELECT INTO новая таблица преобразует его в поле с НУЛЕВЫМ значением.

Изменить значение столбца, РАВНОЕ NULL, также не поддерживается. Как этого добиться?

 SELECT
 location_code, item_no
INTO analytics.dos3 
FROM analytics.dos
WHERE date>'2020-10-20'
  

Моя таблица dos огромна, и я хочу добавить несколько столбцов в начало таблицы из другого объединения таблиц. Следовательно, используя этот подход. Объединенный запрос, который я не добавил в вопрос, поскольку он не имеет отношения к делу.

Ответ №1:

Я думаю, что вы сталкиваетесь с первым из многих ограничений «select into», и вам захочется выяснить, действительно ли это тот маршрут, по которому вы хотите пойти в этом случае использования. Позвольте мне попытаться изложить некоторые проблемы, которые я вижу.

Во-первых, «выбрать в» не очень богат с точки зрения настройки атрибутов целевой таблицы, как вы находите. CTAS (create table as) имеет больше функций, таких как настройка распределения таблиц и ключей сортировки, поэтому его обычно предпочитают «выбрать в». Вы говорите, что результирующая таблица будет добавлена и станет очень большой — наличие ключей в таблице будет хорошей идеей. CTAS также обеспечивает более высокую производительность при большом объеме перемещаемых данных. Но даже CTA не даст вам нужных определений для каждого столбца (и других, которые вам, вероятно, понадобятся при расширении этой таблицы).

Некоторые другие соображения — Поскольку вы добавляете много данных после создания этой таблицы, вы должны быть уверены, что этот большой объем данных поместится в определениях столбцов. Будут ли переменные достаточно большими? Будут ли цифры правильного размера? и т.д. Вам нужно будет установить ключи в таблице — dist, sort, primary и т. Д. — Для достижения наилучшей производительности. Кодировки столбцов тоже могут помочь. Также важно убедиться, что столбцы varchar не имеют максимального размера (64 кб) для больших таблиц — хотя наличие больших переменных не влияет на дисковое хранилище, они влияют на использование памяти во время запросов. Когда эта таблица становится очень большой, это может снизить производительность.

В целом — об очень больших таблицах нужно подумать больше, чем «просто создайте их из select into». Вы захотите создать оптимальное определение таблицы, а затем вставить в нее свои данные. (Сейчас я сойду с мыльницы)

Если вы все еще хотите пойти по этому пути, вы можете установить этот атрибут столбца постфактум (вроде). Это просто 4-шаговый процесс. 1) добавьте еще один столбец с желаемыми атрибутами, используя «alter table». 2) обновите этот новый столбец данными из того, который был создан с помощью «select into». 3) удалите исходный столбец из таблицы. 4) переименуйте новый столбец так же, как и исходный, используя «alter table». Это можно сделать для любого количества столбцов. Конечно, мне кажется проще просто создать правильную таблицу в первую очередь.

PS. помните, что Redshift не обеспечивает уникальность первичных ключей — ответственность за это несет пользователь. Поскольку вы выполняете несколько вставок в новую таблицу, вам нужно убедиться, что нет дубликатов, если это действительно PK.

Комментарии:

1. Вы абсолютно правы! Только что осознал ограничения Redshift, потратив полдня на попытки достичь этого. Наконец, после попытки ВСТАВИТЬ В SELECT etc (чтобы сохранить значение nullable) Я понял, что ничто из этого не масштабируется, и пошел по пути копирования S3

Ответ №2:

Это правильно, select into не приведет к not null в новую таблицу. Создайте свою таблицу явно со списком столбцов, типов данных, ключа распространения и т. Д., А Затем запустите insert into ..выберите список. Затем переименуйте таблицы в конце, это самый быстрый способ сделать это.

Добавление дополнительных столбцов, их обновление и удаление старых столбцов — это очень ресурсоемкий процесс, который может длиться долго в зависимости от объема данных, имеющихся в вашей таблице.