Redshift UPDATE чрезмерно медленный

У меня есть таблица в кластере Redshift с ~ 1 миллиардом строк. У меня есть задание, которое пытается обновить некоторые значения столбцов на основе некоторого фильтра. Обновление чего-либо в этой таблице происходит невероятно медленно. Вот пример:

SELECT col1, col2, col3
FROM SOMETABLE
WHERE col1 = 'a value of col1'
  AND col2 = 12;

Приведенный выше запрос возвращается менее чем за секунду, потому что у меня есть ключи сортировки для col1 и col2. Этому критерию соответствует только одна строка, поэтому результирующий набор — это только одна строка. Однако, если я запускаю:

UPDATE SOMETABLE
SET col3 = 20
WHERE col1 = 'a value of col1'
  AND col2 = 12;

Этот запрос занимает неизвестное количество времени (я остановил его через 20 минут). Опять же, он должен обновлять одно значение столбца одной строки.

Я также пытался следовать документации здесь: http://docs.aws.amazon.com/redshift/latest/dg/merge-specify-a-column-list.html, где говорится о создании временной промежуточной таблицы для обновления основной таблицы, но получили такие же результаты.

Любая идея, что здесь происходит?


person user37760    schedule 09.09.2014    source источник
comment
Посмотрите, есть ли у вас открытая транзакция в этой строке. Попробуйте запустить SELECT * FROM pg_stat_activity; и посмотрите, ждет ли ваше обновление.   -  person Kuberchaun    schedule 09.09.2014
comment
@Bob - только что проверил, похоже, ничего не ждет.   -  person user37760    schedule 09.09.2014
comment
Вы должны указать свои определения таблицы и индекса, версию postgres, на которой вы работаете, и любой вывод любых команд, которые вы запускаете. У вас есть триггер на столе?   -  person Kuberchaun    schedule 09.09.2014
comment
Также добавьте план объяснения для вашего выбора, и ваше обновление дополнительной информации полезно для таких вещей.   -  person Kuberchaun    schedule 09.09.2014
comment
Я ничего не знаю о красном смещении, я быстро просмотрел документацию, похоже, что это postgres 8.x с отклонениями от postgres, такими как неподдерживаемые команды и т. д. Я не знаю, пробовали ли вы это. Возможно, обновление перемещает данные с одного узла на другой, и это работает неправильно. Итак, вы можете вставить данные в какую-то таблицу, а затем удалить старые данные? миллиард строк - это много строк. черт.   -  person Greg    schedule 10.09.2014
comment
Попробуйте собрать статистику по таблице с помощью команды типа «анализировать некоторые таблицы (столбец1, столбец2, столбец3)», а также убедитесь, что таблица очищена от ненужных удаленных блоков, а данные в таблице отсортированы. Если возможно, поделитесь планом объяснения запроса.   -  person androboy    schedule 18.09.2014


Ответы (2)


Вы не упомянули, какой процент таблицы вы обновляете, но важно отметить, что UPDATE в Redshift — это двухэтапный процесс:

  1. Каждая строка, которая будет изменена, должна быть сначала помечена для удаления.
  2. Затем необходимо записать новую версию данных для каждого столбца таблицы.

Если у вас большое количество столбцов и/или вы обновляете большое количество строк, этот процесс может быть очень трудоемким для базы данных.

Вы можете поэкспериментировать с использованием оператора CREATE TABLE AS для создания новой «обновленной» версии таблицы, а затем удалить существующую таблицу и переименовать новую таблицу. Дополнительным преимуществом этого является полностью отсортированная таблица.

person Joe Harris    schedule 23.09.2014
comment
Не могли бы вы уточнить или сослаться на объяснение того, почему каждый столбец в таблице должен быть переписан при изменении одного столбца? Также любопытно, улучшилась ли производительность UPDATE за ~ 7 лет с момента получения этого ответа. Кажется, я смогу выполнить ОБНОВЛЕНИЕ в нашем наборе данных Redshift с разумной производительностью в 2021 году. - person David Backeus; 11.03.2021

На самом деле я не думаю, что RedShift предназначен для массовых обновлений, RedShift предназначен для OLAP, а не OLTP, операции обновления по своей природе неэффективны в RedShift.

В этом случае я бы предложил использовать INSERT вместо UPDATE, а также добавить еще один столбец TIMESTAMP, и когда вы выполняете анализ в RedShift, вам понадобится дополнительная логика, чтобы получить последнюю TIMESTAMP, чтобы исключить возможные дублированные записи данных.

person ciphor    schedule 23.03.2015
comment
Комментарии Redshift включают утверждение, что вставка может быть очень медленной. Это не может быть решением - person Martlark; 03.12.2015