Выбор ключей сортировки и распределения для таблицы измерений в базе данных Redshift - PullRequest
0 голосов
/ 05 апреля 2019

В базе данных Redshift я хочу выбрать ключ сортировки для таблицы измерений между суррогатным ключом и естественным первичным ключом.Определение гласит: «Ключи сортировки должны выбираться на основе наиболее часто используемых столбцов при фильтрации, упорядочении или группировании данных».У меня вопрос -

У меня есть таблица Employee с (Emp_key, Emp_Id, Emp_name), и эта таблица присоединена к таблице фактов на ключе Emp.Здесь «Emp_key» является суррогатным ключом, а «Emp_id» является естественным первичным ключом.И я фильтрую запрос по Emp_id, но «Emp_key» в таблице фактов определяется как «ключ dist» и читаю, что для большого измерения определение ключей sort и dist на ключах соединения приводит к повышению производительности, и поэтому я хочу знать, какиеНужно ли выбирать между Emp_key и Emp_id для ключа сортировки в таблице измерений?

А также, другая путаница заключается в выборе сортировки для таблицы измерений «date» между «date_key» или игнорировании определения ключа сортировки.

Буду признателен за ваши предложения по этому поводу.

Спасибо!

1 Ответ

0 голосов
/ 05 апреля 2019

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

UPD: при таком дизайне я использовал бы emp_key в качестве ключа dist (чтобы объединяемые данные находились на одних и тех же узлах), а emp_id в качестве ключа сортировки (для эффективной фильтрации). Я почти уверен, что планировщик запросов будет отдавать приоритет фильтрации по объединению, поэтому сначала он отфильтрует строки из таблицы измерений, и только затем он объединит соответствующие строки из таблицы фактов. Но лучше попробовать все варианты и сравнить несколько запросов, чтобы увидеть, что работает лучше.

Если вы можете изменить дизайн, я бы просто добавил emp_id в таблицу фактов (потому что это выглядит как ключи с 1 по 1) как часть ELT и снова избежал дилеммы.

...