Redshift: стратегии DIST KEY и SORT KEY для дальних соединений

Question

У меня медленно меняющееся измерение, представляющее все изменения основных данных нашей статьи, и оно довольно обширное: 15 миллиардов строк и растет.

В настоящее время таблица распределена по естественным ансамблям, таким как (страна, поставщик).

Из-за природы таблицы большинство запросов, использующих ее, являются диапазонными соединениями, такими как тривиальный подсчет заказов по изменяющемуся атрибуту статьи:

SELECT x.article_id, x.changing_article_season, COUNT(*) counting_orders
FROM article_slow_changing_dimension x
LEFT JOIN orders y ON x.article_id=y.article_id
AND y.order_timestamp BETWEEN x.from_timestamp AND y.to_timestamp

Что может быть интересной стратегией выбораключа сортировки здесь?Я думал о выполнении SORTKEY (from_timestamp, to_timestamp), но я не уверен.

Я попробовал несколько вещей, но любой тест требует много времени для настройки и на самом деле трудно оценить эмпирически.Любая идея?

РЕДАКТИРОВАТЬ: добавление нескольких деталей на основе комментариев 1 / таблицы пылесосятся 2 / кластер довольно маленький (4 узла) и запрос выполняется довольно быстро, но он не работает, поэтому онв основном только я разработчики запускают несколько запросов.Я хотел бы оптимизировать, прежде чем приступить к производству 3 /, сейчас в нем примерно 15 миллиардов строк, а агрегация для конкретной временной отметки занимает 1 минуту;Но я бы хотел довести это до 20 секунд

Answer 1

Отличный вопрос.

Небольшой фон, ключи сортировки имеют 2 основные цели: 1) минимизировать данные, отсканированные с диска, и 2) включить объединения между большими таблицами, чтобы использовать объединение слиянием (самое быстрое объединение).https://docs.aws.amazon.com/redshift/latest/dg/query-performance-improvement-opportunities.html

SORTKEY(from_timestamp, to_timestamp) обычно очень хороший выбор, но это не улучшит производительность вашего примера запроса.Это более полезно в случае, когда вы используете эти поля в предикате, таком как WHERE from_timestamp > '2019-01-01' AND to_timestamp < current_date.

Существует предел того, насколько вы можете оптимизировать этот тип объединения диапазонов, потому что база данных должна рассматривать его как декартовуproduct (он же «CROSS JOIN» - объединить каждую строку с a с каждой строкой с b).Вы знаете , что объединение будет соответствовать одной строке, но база данных не знает .

В полноразмерном DW я бы сделал article_sk суррогатный ключ,Это значение будет соответствовать только одному значению в SCD.Это усложняет процесс ETL, поскольку во время обработки приходится вводить суррогатный ключ.

Еще одна вещь, которую вы можете сделать, - это распределить обе таблицы, используя столбец article.Это позволяет выполнять соединение на каждом срезе параллельно.Однако article, вероятно, не будет естественным ключом распределения для вашей таблицы фактов orders (обычно это будет customer или account).