Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Работа Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 [5]      все
 Re: Мои наблюдения за месяц поиска работы  [new]
Balbidon
Member

Откуда: Donetsk->Emerald City
Сообщений: 358
Alex Le, ну, использование INNER JOIN семантически аналогично фильтрации, на самом деле. Большинство оптимизаторов это понимают, и Redshiff здесь не исключение, если я правильно помню. Задача решалась около 4-х лет назад, потому я могу значительно искажать детали. Пытался продемонстрировать суть, скорее, чем воспроизвести конкретный запрос.

Но добавлять предикаты из JOIN в WHERE мы тоже пробовали, т.к. времени было много, плюс серьезный интерес к теме, плюс, как я уже неоднократно упомянул выше, прямой контакт с разработчиками, которые и посоветовали промежуточную материализацию в качестве стратегии оптимизации. Опять же, быстродействие мы улучшили в 3 раза. И планы смотрели. Да, вы правы насчет скана, Redshift его делает всегдаю Т.е. получается, там была не замена скана, а изменение стратегии джойна с Hash на Merge и уход от redistribution.

Мой первоначальный посыл был в том, что во многих случаях предпочтение будет отдано не самому производительному решению, а тому, которое будет легче поддерживать.
8 июн 21, 13:34    [22332839]     Ответить | Цитировать Сообщить модератору
 Re: Мои наблюдения за месяц поиска работы  [new]
Alex Le
Member

Откуда:
Сообщений: 63
А порядок соединения в первом запросе не влиял на производительность? Чем раньше выкидываются лишние строки, тем меньше работы для соединения.
То, что вы предложили - это подход, место которому в некотором контролируемом процессе, который не допускает параллельного исполнения.
8 июн 21, 14:41    [22332905]     Ответить | Цитировать Сообщить модератору
 Re: Мои наблюдения за месяц поиска работы  [new]
Balbidon
Member

Откуда: Donetsk->Emerald City
Сообщений: 358
Alex Le, порядок не влиял, т.к. в результате работы первого джойна, каким бы он ни был, все равно данные были распределены по нодам и отсортированы в порядке, абсолютно неподходящем для второго и третьего джойнов, и происходило перераспределение (redistribution) данных, а затем, как результат, HashJoin.

Кстати, я посмотрел, в прошлом году в Amazon Redshift добавили фичу MATERIALIZED VIEW, т.е. это именно то, что нам бы очень помогло в том проекте в 2017. Мы бы вместо промежуточных таблиц создали несколько таких представлений и базовый запрос основали бы на них. Функционал бы не изменился, а вот простота и поддерживаемость кода - однозначно бы улучшились.
8 июн 21, 18:11    [22333033]     Ответить | Цитировать Сообщить модератору
 Re: Мои наблюдения за месяц поиска работы  [new]
Ivan Durak
Member

Откуда: Minsk!!!
Сообщений: 3710
Balbidon
Alex Le, порядок не влиял, т.к. в результате работы первого джойна, каким бы он ни был, все равно данные были распределены по нодам и отсортированы в порядке, абсолютно неподходящем для второго и третьего джойнов, и происходило перераспределение (redistribution) данных, а затем, как результат, HashJoin.

Кстати, я посмотрел, в прошлом году в Amazon Redshift добавили фичу MATERIALIZED VIEW, т.е. это именно то, что нам бы очень помогло в том проекте в 2017. Мы бы вместо промежуточных таблиц создали несколько таких представлений и базовый запрос основали бы на них. Функционал бы не изменился, а вот простота и поддерживаемость кода - однозначно бы улучшились.

в редшифте же есть ALL distribution. Best use case для всех справочников - только так и дистрибьютить - и никакого redistribution в фактах не будет, т.к. копии дименшенов везде есть.

p.s. А так-то я точно такой же херней занимался на гринпламе, где ALL distribution небыло.

p.p.s Ну и так-то это настолько тривиальная оптимизиция для MPP систем, что даже как-то неловко рассказывать про то что тут что-то нестандартно и трудно поддерживать....

Сообщение было отредактировано: 9 июн 21, 09:55
9 июн 21, 10:02    [22333157]     Ответить | Цитировать Сообщить модератору
 Re: Мои наблюдения за месяц поиска работы  [new]
Balbidon
Member

Откуда: Donetsk->Emerald City
Сообщений: 358
Ivan Durak,

Конечно, мы думали про ALL. Но это не работало, т.к. самый маленький dimension занимал бы половину места на ноде. Ноды были compute optimized. Пробовали даже делать ALTER TABLE со сменой distribution перед и после запроса, параллельное выполнение других оказывалось под угрозой. А выигрыш в производительности был незначительным.

Насчет тривиальности подхода никто и не спорит, но даже такое решение было отвергнуто, т.к. выходило за рамки стандартного подхода. Всего было около сотни запросов к проекте, и этот был бы первым или даже единственным, использующим такую оптимизацию.
9 июн 21, 17:22    [22333439]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 [5]      все
Все форумы / Работа Ответить