Что значит иметь несколько столбцов sortkey?

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

Если я создаю таблицу с SORTKEY (COL1, COL2), значит ли это, что все столбцы хранятся отсортированными по COL1, а затем COL2? Или, может быть, поскольку это хранилище столбцов, каждый столбец хранится в другом порядке? То есть COL1 в порядке COL1, COL2 в порядке COL2, а остальные столбцы неупорядочены?

Моя ситуация в том, что у меня есть таблица с (среди прочих) столбцом type_id и timestamp. Данные поступают примерно в порядке времени. Большинство запросов объединены с/ограничены как type_id, так и timestamp. Обычно предложения type_id более специфичны, а это означает, что гораздо больший процент строк можно исключить, посмотрев предложение type_id, чем глядя на предложение timestamp. type_id - это DISTKEY по этой причине. Я пытаюсь понять плюсы и минусы SORTKEY (type_id), SORTKEY (stamp), SORTKEY (type_id,stamp), SORTKEY (stamp,type_id).

Спасибо.

Ответ 1

Если вы объявите SORTKEY(COL1, COL2), все столбцы будут отсортированы по COL1, а затем COL2, как если бы было выполнено ORDER BY (COL1, COL2).

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

Если COL1 очень избирательно, как ваш type_id, это означает, что есть только небольшое количество строк, которое имеет тот же самый type_id. Поэтому, хотя вы можете добавить еще один столбец в SORTKEY, его утилита ограничена, поскольку большая часть устранения строки уже произошла.

Если COL1 не очень избирательно, как ваш stamp (который немного странный btw, я бы ожидал, что он будет более избирательным, чем type_id? Anyways..), это означает, что фильтрация stamp не удалит столько строк. Поэтому имеет смысл объявить второй ключ сортировки. Однако это менее эффективно, чем наоборот, поскольку удаление ранних ранее было бы дешевле. Если вы иногда фильтруете stamp, но не на type_id, это может иметь смысл сделать это, хотя.

Ответ 2

Мы также используем Redshift, и у нас есть около 2 миллиардов записей (+20 миллионов каждый день), и я должен сказать, что чем менее избирательным является sort_key, тем выше он должен быть в списке sort_key.

В нашем случае (и, пожалуйста, рекомендуется проанализировать, как вы используете/запрашиваете свои собственные данные), мы использовали временную метку в качестве первой sort_key. Проблема заключается в том, что даже за 1 секунду мы записываем около 200 строк, что приводит к тому, что наши блоки 1 МБ содержат всего несколько секунд и каждый тип данных в этом единственном блоке. Это означает, что временная метка очень избирательна, поскольку мы не можем фильтровать дальше, поскольку у нас есть все виды данных в каждом блоке.

В последнее время мы изменили порядок sort_keys. Первая имеет около 15 различных значений, вторая - около 30 и т.д., А временная метка - последняя, но все же один блок все еще измеряется в секундах.

Это приводит к тому, что мы очень часто используем первые два sort_keys в качестве фильтров: Старое решение: Год данных, выберите месяц, он упадет на 91% блоков, но после того, как он должен открыть все из них, хотя мы хотим отфильтровать дальше.

Новое решение опускается на 14/15 блоков на первом этапе, независимо от диапазона дат, затем около 95% оставшихся, а метка времени все еще падает на 91% от остальных.

Мы тщательно протестировали его с двумя 800-миллионными таблицами записей, которые были одинаковыми, за исключением порядка ключей сортировки. Чем выше период времени в предложении "where", тем лучшие результаты мы получили. Это стало еще более значительным в случае объединения.

Итак, я предлагаю знать вашу базу данных и какие запросы вы часто запускаете, потому что наиболее избирательный столбец может быть не лучшим первым sort_key. Как сказал Энно Шиодзи, все зависит от того, что вы фильтруете.

Ответ 3

Я скажу, что порядок sort_key должен быть

рассмотрите те, которые находятся в dist, сначала фильтруют и присоединяются
рассмотрим те из фильтров, join
рассмотрим те, которые находятся в фильтре
рассмотрим те, которые входят в join
рассмотрим те, которые находятся в группе, упорядочиваются (включая функцию окна)

общее правило: нижняя мощность помещается первой, если тот же уровень.