Redshift and ultra wide tables

В попытке обработать пользовательские поля для определенных объектов в многопользовательском DW я создал сверхширокую денормализованную таблицу размеров (сотни столбцов, жестко закодированный предел столбца), что Redshift не очень нравится;) ,Redshift and ultra wide tables

user1 | attr1 | attr2 ... attr500

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

Любой указатель, как изменить дизайн для лучшей отчетности из нормализованной исходной таблицы (один пользователь имеет несколько разных атрибутов, один атрибут одна строка) для денормализации (одна строка для каждого пользователя с общими столбцами, различная для каждого из арендаторов)?

Или кто-либо попытался выполнить перенос (поворот) нормализованных записей в денормализованный вид (таблицу) в Redshift? Меня беспокоит производительность.

источник

2016-11-22 Dolfa

Не могли бы вы прояснить - вы говорите, что производительность SELECT плохая или только производительность UPDATE? (Redshift оптимизирован для запросов, а не для обновления.) Сколько строк в таблице и сколько строк обновляется? Вы используете SORTKEY и DISTKEY на столе? Можете ли вы представить образец своих запросов, чтобы продемонстрировать свою ситуацию? Спасибо. –

Таблица небольшая (таблица сцен), скажем, десятки/сотни записей, но сотни столбцов. Запрос будет выглядеть примерно так: _update stage set validFrom = sysdate, validTo = 2999-01-01_. Планировщик говорит мне, что делает «Sequential Scan». – Dolfa

Возможно, важно подумать о как Redshift хранит данные, а затем реализует обновления этих данных.

Каждый столбец хранится в собственной последовательности блоков 1 МБ, а содержимое этих блоков определяется SORTKEY. Итак, как много строк значений ключа сортировки могут поместиться в 1 МБ, сколько (и каких) значений соответствует соответствующему 1 МБ для всех остальных столбцов.

Когда вы спрашиваете RedShift к UPDATE подряд он на самом деле пишет новую версию всего блока для всех столбцов, которые соответствуют этой строке - не только блок (ы), который меняется. Если у вас 1600 столбцов, что означает, что обновление одной строки требует, чтобы Redshift записывал минимум из 1,600 МБ новых данных на диск.

Эта проблема может быть усилена, если ваше обновление касается многих строк, которые не расположены вместе. Я бы настоятельно рекомендовал выбрать SORTKEY, который точно соответствует диапазону обновляемых данных, чтобы свести к минимуму объем записи.

источник

2016-12-06 18:27:12

Мне было интересно, если Redshift касается только измененного столбца (как я и ожидал), или ему нужно удалить и вставить новые записи во все столбцы (как вы упомянули). Похоже, что позже это правда, и вы правы (что вызывает удивление, но я не знаю, что внутри базы данных столбцов так глубоко, чтобы понять, почему это происходит. Узнайте что-то новое каждый день :). – Dolfa

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

Еще одна вещь, о которой нужно знать со сверхширокими таблицами в Redshift, - это то, что они едят сумасшедшие объемы дискового пространства. Реальный пример у нас есть в производстве: 3600 строк, 1600 колос, 44 КБ, gzipped в S3, 128 ГБ в Redshift. –

ответ

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