От 2 минут до 3 секунд: что я проверил, прежде чем винить BI
Сегодня расскажу про один кейс, который был у меня в работе. Отчёт, который грузится 2 минуты — это проблема. А дашборд, который иногда падает, когда все открывают его одновременно — проблема ещё больше. Витрина на SQL открывалась около 2 минут, а на пиковой нагрузке весь отчёт мог упасть. Самая простая реакция — обвинить BI. Но я решил сначала проверить сам SQL-запрос. EXPLAIN очень помог мне с этим. Узким местом оказались JOIN’ы, поэтому я переписал запрос, добавил оконные функции. А ещё добавил индексы на поля, которые использовались в фильтрации на дашборде.
Теперь сама витрина грузится примерно за 3 секунды, а падения дашборда на пиковой нагрузке исчезли. Никакой магии тут нет. Прежде чем трогать настройки BI, я бы проверил три вещи: - сколько в запросе JOIN’ов и в каком порядке они идут - могут ли фильтры использовать индекс - что запрос считает повторно, хотя мог бы посчитать один раз
А где вы находили узкое место, которого не ожидали? #SQL #BI #DataAnalytics
· 22.10
Как проверяли, что после замены JOIN на оконные функции сохранился тот же результат на дубликатах ключей и пустых значениях? К замеру скорости я бы добавил сверку числа строк и контрольных итогов до и после, а нагрузочный прогон повторил с теми же фильтрами, что используют люди.
1
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён
· 22.10
Очень классный вопрос, спасибо) Да, Вы абсолютно правы =) Сверка делалась параллельно на каждом из этапов. Сначала, когда часть подзапросов оформлял в CTE. Потом и с JOINами поступал аналогично. Зафиксировал в старом запросе COUNT(*), COUNT(DISTINCT по основным ключам), агрегаты по метрикам отдельно и отдельно число строк с NULL в ключевых полях. Ещё была возможность сравнить эти два варианта витрины друг с другом через EXCEPT. Также сверены контрольные итоги на уровне самого дашборда.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён