Redshift - Редизайн таблиц для использования клавиш DIST и SORT (проблема с производительностью) - PullRequest
Новая
       11

Redshift - Редизайн таблиц для использования клавиш DIST и SORT (проблема с производительностью)

0 голосов
/ 11 мая 2019

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

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

SELECT * FROM admin.v_extended_table_info
WHERE table_id IN (
  SELECT DISTINCT s.tbl FROM stl_scan s
    JOIN pg_user u ON u.usesysid = s.userid
    WHERE s.type=2 AND u.usename='looker'
  )
ORDER BY SPLIT_PART("scans:rr:filt:sel:del",':',1)::int DESC,
  size DESC;

На основании результатов запроса я мог бы идентифицировать множество небольших таблиц (1-1000 записей), которые распределены как EVEN, и это может быть ALL - эти таблицы используются во многих инструкциях объединений.

Кроме того, я определил, что 99% моих таблиц используют EVEN без ключа сортировки. Я не использую денормализованные таблицы, поэтому мне нужно запускать множество объединений для получения данных - для того, что я прочитал, EVEN не подходит для объединений, поскольку они могут распространяться по сети.

У меня есть 3 таблицы, связанные с потоком билетов: user, ticket и ticket_history. Все эти таблицы EVEN без ключей сортировки и diststyle как EVEN.

На данный момент я хотел бы изменить структуру таблицы user: эта таблица используется при объединении по условию ticket.user_id = user.id, где такие пункты, как user.email = 'xxxx@xxxx.com' или user.email like '%@something.com%' или group by user.email.

Первое, что я планирую сделать, это использовать diststyle в качестве дистрибутива и ключ как id. Имеет ли смысл использовать уникальное значение в качестве ключа dist? Я прочитал много постов о dist keys и все еще путаюсь со мной.

Как сортировать ключи имеет смысл использовать электронную почту как составную? Я читал, чтобы избежать столбцов, которые растут как даты, отметки времени или тождества, поэтому я не использую их как чередующиеся. Чтобы избежать этого like, я планирую создать новый столбец, чтобы определить, что такое домен электронной почты.

После этого я заменю маленькие таблицы на dist ALL и попробую снова выполнить свои запросы.

Я на правильном пути? Любой другой совет?

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

1 Ответ

2 голосов
/ 12 мая 2019

Основное правило:

  • Установите DISTKEY для наиболее часто используемого столбца в JOINs
  • Установите SORTKEY для столбца (s) чаще всего используется в WHEREs

Вы правы, что небольшие таблицы могут иметь распределение ALL, что позволит избежать отправки данных между узлами.

DISTKEY обеспечиваетнаибольшая выгода при объединении таблиц через общий столбец с одинаковым DISTKEY в обеих таблицах.Это означает, что каждая строка содержится на одном и том же узле, и данные не нужно отправлять между узлами (или, точнее, срезами).Тем не менее, вы можете выбрать только один DISTKEY, поэтому сделайте это в столбце, который чаще всего используется для JOIN.

SORTKEY обеспечивает наибольшее преимущество, когда Redshift может пропустить блоки хранения.Каждый блок хранения содержит данные для одного столбца и помечен значениями MIN и MAX.Когда таблица сортируется по определенному столбцу, она минимизирует количество дисковых блоков, которые содержат данные для данного значения столбца (поскольку все они расположены вместе, а не распределены случайным образом по всему дисковому хранилищу).Таким образом, используйте столбцы, которые наиболее часто используются в операторах WHERE.

Если поиск по шаблону user.email идет медленно, вы, безусловно, можете создать новый столбец с доменом.Или, для еще большей производительности, вы можете рассмотреть возможность создания отдельной справочной таблицы с user_id и domain, имеющей SORTKEY = domain.Это будет быстрее всего при поиске по домену.

Совет из опыта: Я бы не советовал использовать адрес электронной почты в качестве user_id, потому что люди иногда хотят изменить адрес электронной почты.Для таких столбцов id лучше использовать уникальный номер с адресом электронной почты в качестве изменяемого атрибута.(Я видел, что программные системы нуждаются в серьезной переработке, чтобы исправить такое раннее дизайнерское решение!)

...