distkey и sortkey на временных таблицах - Redshift - PullRequest
0 голосов
/ 18 апреля 2020

Я начинаю проводить некоторые исследования по настройке запросов и экспериментирую с использованием distkey и sortkey. Из того, что я прочитал, если я установил distkey для столбца присоединения, планировщик запросов будет использовать объединение слиянием вместо объединения ha sh, что должно быть быстрее в Redshift. Мне было интересно, относится ли это также к временным таблицам? Наши производственные таблицы на самом деле являются представлениями, поэтому они не имеют уже установленных ключей. Я не уверен, почему мы не используем настоящие складские столы.

1 Ответ

2 голосов
/ 19 апреля 2020

Да, ключи могут быть установлены для временных таблиц:

create temp table fred DISTKEY (1) as ...

это легко сделать с позицией столбца - первый столбец в этом примере. Вы также можете установить стиль распределения для временных таблиц, если пожелаете. Это может заставить данные оставаться «на узле» для промежуточных результатов в очень больших и сложных запросах. Redshift хорошо принимает разумные решения о том, как распределять промежуточные результаты, но не совершенен и не понимает природу данных. Я сделал это с хорошими результатами, когда изображения больших данных находятся в игре.

Что касается второго замечания об использовании представлений вместо таблиц - в Redshift стандартные представления в основном представляют собой SQL макросы, которые сглаживаются / оптимизируются посредством с помощью компилятора запросов Redshift. Так что использование представлений вместо таблиц само по себе неплохо. Использование представления, особенно сложных, может скрыть то, что делается запросом, и это может добавить ненужную и неожиданную сложность запроса. Ключи устанавливаются в таблицах, на которые ссылаются представления. (Я предполагаю, что представления не ссылаются на внешние таблицы / таблицы спектра)

Наконец, вы заявляете, что хотите добиться поведения Merge Join для повышения производительности. Несмотря на то, что это самый быстрый тип объединения, время и работа, необходимые для выполнения объединения слиянием во временных таблицах, не будут компенсированы этим приростом производительности (опытом). Redshift будет использовать объединение слиянием только тогда, когда есть уверенность в том, что объединяемые данные будут объединяться без проблем. Если он не совсем уверен, что это так, он должен выполнить соединение Ha sh, которое является более общим процессом. Чтобы Redshift выполнил объединение слиянием, вам нужно будет отсортировать и проанализировать временные таблицы, что будет стоить гораздо больше времени, чем экономия, которую вы получите. Гораздо важнее, чтобы ваши объединения были "DIST NONE" - без распространения данных по сети - чем переход от соединения ha sh к объединению слиянием.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...