Redshift CREATE TABLE AS занимает много времени из простого запроса - PullRequest
0 голосов
/ 17 октября 2019

Когда я запускаю определенный запрос сам по себе, он возвращается менее чем за 1 секунду. Когда я пытаюсь создать таблицу из этого запроса, используя CREATE TABLE (name) AS, она выполняется до 15 минут без завершения.

Я сделал много таблиц в качестве запросов и не имел этой проблемы. Должно ли это занять намного больше времени, чтобы составить таблицу из запроса, который сам по себе занимает менее одной секунды, чтобы вернуть?

1 Ответ

0 голосов
/ 18 октября 2019

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


Для справки, вот элементы, которые могут замедлять ваш запрос (ссылка на источник ниже):

  • Количество узлов, процессоров или слайсов: вычислительный узел разбит на кусочки. Больше узлов означает больше процессоров и больше срезов, что позволяет быстрее обрабатывать ваши запросы.

  • Типы узлов - Кластер Amazon Redshift может использовать либо плотное хранилище, либо плотные вычисленияузлы. Типы узлов с плотным хранением рекомендуются для существенных потребностей в хранении данных, в то время как типы узлов с плотным вычислением оптимизированы для ресурсоемких рабочих нагрузок. Каждый тип узла предлагает разные размеры и ограничения, чтобы помочь вам правильно масштабировать кластер. Размер узла определяет емкость, память, ЦП и цену каждого узла в кластере.

  • Распределение данных - Amazon Redshift сохраняет данные таблиц на компьютереузлы в соответствии со стилем распределения таблицы. Когда вы выполняете запрос, оптимизатор запросов перераспределяет данные на вычислительные узлы по мере необходимости для выполнения любых объединений и агрегаций. Выбор правильного стиля распределения для таблицы помогает минимизировать влияние шага перераспределения, находя данные там, где они должны быть до выполнения соединений.

  • Порядок сортировки данных - Amazon Redshift сохраняет данные таблицы на диске в отсортированном порядке в соответствии с ключами сортировки таблицы. Оптимизатор запросов и обработчик запросов используют информацию о том, где находятся данные, чтобы уменьшить количество блоков, которые необходимо сканировать, и тем самым повысить скорость запроса. Для получения дополнительной информации см. Выбор ключей сортировки.

  • Размер набора данных - Большой объем данных в кластере может снизить производительность запросов для запросов, поскольку требуется больше строкбыть отсканированы и перераспределены. Вы можете смягчить этот эффект путем регулярной очистки и архивации данных, а также с помощью предиката для ограничения набора данных запроса.

  • Параллельные операции (чаще всего) - ВыполнениеНесколько операций одновременно могут повлиять на производительность запроса. Каждая операция занимает один или несколько слотов в доступной очереди запросов и использует память, связанную с этими слотами. Если выполняются другие операции, может быть недостаточно слотов очереди запросов. В этом случае запрос должен дождаться открытия слотов, прежде чем он сможет начать обработку. Дополнительные сведения о создании и настройке очередей запросов см. В разделе Реализация управления рабочей нагрузкой.

  • Структура запроса - способ написания запроса влияет на его производительность. Насколько это возможно, пишите запросы для обработки и возвращайте столько данных, сколько соответствует вашим потребностям. Дополнительную информацию см. В разделе Рекомендации по разработке запросов Amazon Redshift.

  • Компиляция кода - Amazon Redshift генерирует и компилирует код для каждого плана выполнения запроса. Скомпилированный код выполняется быстрее, потому что он устраняет накладные расходы при использовании интерпретатора. Как правило, у вас есть некоторые накладные расходы при первом создании и компиляции временного кода. В результате производительность запроса при первом запуске может ввести в заблуждение. Накладные расходы могут быть особенно заметны при выполнении одноразовых запросов. Запустите запрос еще раз, чтобы определить его типичную производительность. Точно так жеВам нужно сравнить производительность одного и того же запроса, отправленного с разных клиентов. Механизм выполнения генерирует различный код для протоколов соединений JDBC и протоколов соединений ODBC и psql (libpq). Если два клиента используют разные протоколы, каждый клиент впервые оплачивает сборку кода даже для одного и того же запроса. Однако другие клиенты, использующие тот же протокол, получают выгоду от совместного использования кэшированного кода. Клиент, использующий ODBC, и клиент, выполняющий psql с libpq, могут использовать один и тот же скомпилированный код. Сегменты скомпилированного кода хранятся локально в кластере и удаленно в кэше уровня учетной записи AWS. Последующее выполнение одного и того же запроса может выполняться быстрее, поскольку оно может пропустить этап компиляции. Кэш сохраняется после перезагрузки кластера, но стирается из-за обновлений обслуживания. При пропадании локального кэша используется удаленный общий кэш. Если происходит попадание в удаленный кеш, кэшированный элемент извлекается в локальный кеш. Удаленный кеш распределяется между кластерами в рамках одной учетной записи AWS. Таким образом, запрос может выполняться быстрее:

    • Когда запрос выполняется на разных кластерах одной учетной записи.
    • Когда запрос выполняется в разных сеансах в кластере.
    • И часто, когда запрос имеет разные параметры запроса, но один и тот же план выполнения.

[ Факторы, влияющие на производительность запроса ]https://docs.aws.amazon.com/redshift/latest/dg/c-query-performance.html

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