#amazon-web-services #encoding #compression #amazon-redshift
Вопрос:
Мой кластер красного смещения показывает мне некоторые рекомендации, связанные со сжатием, такие как:
ALTER TABLE "schema"."table" ALTER COLUMN "field_a" ENCODE lzo; Но когда я это сделаю:
ANALYZE COMPRESSION schema.table; Вывод показывает что-то вроде этого:
table,id,az64,0.00 table,date,raw,0.00 table,field_a,lzo,0.00 table,field_b,lzo,0.00 table,field_c,zstd,41.92 table,field_d,zstd,36.95 table,field_e,zstd,84.74 table,field_f,az64,0.00 Как вы можете видеть field_a , поле » Что » в рекомендации на AWS панели мониторинга выиграет примерно на 0%, и даже больше, поле уже сжато с lzo типом сжатия, поэтому рекомендация не является реальной.
С другой стороны, другие поля, которые не указаны в рекомендации, выиграют в огромном проценте от применения сжатия.
Почему эта redshift рекомендация сосредоточена только на одном поле, а analyze оператор возвращает другой результат?
Если я подам ENCODE field_c заявку , field_d и field_e выгода будет в I/O disk workload и disk usage , но данные или скорость запросов будут затронуты плохим образом или это совершенно безвредно?
Ответ №1:
Есть ряд вещей, которые необходимо проверить, так как Redshift имеет ряд систем в этой области. Во-первых, сколько лет было рекомендации консоли? Также включена ли в таблице функция «Автоматическая оптимизация таблиц»?
Анализ сжатия просто выглядит так, как размер столбца может быть уменьшен, если сжатие изменится. Так что как раз о размере и, как вы правильно заметили, пропускной способности ввода-вывода. Причина, по которой улучшение может составить 0%, скорее всего, связана с тем, что данные разбиваются на блоки размером 1 МБ, и никакие блоки не сохраняются за счет уменьшения размера данных (по крайней мере, при текущем размере таблицы).
Рекомендация консоли — это «более умный» алгоритм-он рассматривает не только размер данных и пытается сделать «безопасные» рекомендации или изменения. Основная причина, по которой улучшение сжатия может снизить производительность, заключается в том, что метаданные блоков становятся менее эффективными. Поэтому, если столбец часто используется в качестве предложения WHERE, красное смещение будет уклоняться от рекомендации дополнительного сжатия. Я еще не видел, чтобы он был достаточно умен, чтобы просмотреть влияние метаданных и правильно сравнить их с улучшением пропускной способности ввода-вывода. Поэтому он просто стесняется, когда не уверен.
В случае этих других столбцов, где анализ сжатия говорит о возможности значительной экономии размера, возможно, красное смещение «стесняется». Используются ли эти столбцы в качестве предложений WHERE? Особенно простые предложения WHERE (col = значение), в которых разрешено сравнение метаданных. Просто потому, что Redshift не рекомендовал эти изменения в кодировках, не означает, что это плохо (или хорошо, или нейтрально). Он просто недостаточно знает / недостаточно умен. Существуют способы проанализировать метаданные для этих столбцов и посмотреть, что с ними сделают различные кодировки, но для этого требуется некоторое усилие. КОДИРОВАНИЕ RAW для обычных, простых столбцов предложений WHERE-это хорошее предположение, но для того, чтобы знать наверняка, требуется работа.
Комментарии:
1. спасибо за ваш ответ. Рекомендации были даны 2 дня назад. Таблица не имеет автоматической оптимизации таблиц. Я понимаю, что вы говорите, тогда хороший вариант-проверить, используются ли эти столбцы, которые reduce_pct превышают 50%, т. Е. Используются в операторах where, если они используются, лучше использовать как необработанные. В противном случае они могут быть закодированы в определенную кодировку?
2. Это был бы самый простой подход. Я бы добавил, что вы хотите «сохранить часто используемые предложения WHERE» в качестве необработанных по сравнению с все столбцы предложения WHERE, или вы можете получить все, что закодировано как необработанное, и потерять большую пропускную способность ввода-вывода. Не слишком сложный шаг, который можно добавить,-это просмотреть метаданные столбца и посмотреть, есть ли какая-либо «ценность» в том, чтобы сохранить его в исходном виде.
3. мм интересно, когда вы говорите, посмотрите колонку «метаданные», что вы имеете в виду? что я должен искать?
4. Таблица stv_blocklist позволяет просматривать метаданные таблицы и сохраняет значения minvalue и maxvalue для всех блоков для каждого столбца каждой таблицы. Теперь эти значения закодированы как BIGINT, что отлично подходит для чисел, но не так здорово для дат и строк — некоторое время назад я разработал обратное декодирование и должен написать об этом белую бумагу. Поэтому, если метаданные таблицы обновлены (проанализируйте), вы можете увидеть, как диапазон значений для блоков в столбце перекрывается или представляет почти независимые диапазоны значений. Метаданные, имеющие независимые диапазоны, имеют значение для проверки предложения WHERE.
5. Большая часть выбора ключа сортировки и всех сжатых и несжатых столбцов связана с эффективностью метаданных.