Как в компаниях борются с тяжелыми запросами ⌨️

Существуют разные подходы к тому, чтобы не случилось мемной ситуации, когда аналитик случайно положил базу

Как правило аналитики не имеют доступа к продовой БД и работают в аналитических репликах, но плохой запрос там может помешать обновлению дашбордов, загрузке витрин и работе коллег

🔵Автоматические лимиты в СУБД
Например, по времени выполнения или объему потребляемой памяти. При превышении запрос упадет с ошибкой, и аналитику ничего не останется, кроме как оптимизировать его

🔵Киллеры плохих запросов
Может существовать скрипт с более гибкими и сложными условиями, который сканирует выполняющиеся запросы и “убивает” все подозрительные

🔵Социальное давление или доска позора
Тогда явных ограничений может и не быть, но каждый аналитик знает: если из-за его запроса все начнет виснуть, админы опубликуют его в общий доступ с очень неприятной припиской. Опасаясь общественного порицания, аналитики пускают в ход все свои знания об оптимизации запросов

🔵Другая версия этого - полная прозрачность
Когда каждый может посмотреть содержимое и авторов выполняющихся сейчас запросов. И в личку к виновнику сразу повалят его коллеги

🔵Запрет доступа к сырым данным
Могут ограничить доступ к гигантским сырым таблицам для отдельных ролей, а дать только к витринам с уже агрегированными данными. Это избавляет от лишних вычислений и сокращает количество обрабатываемых строк

А какой подход выбран у вас в компании и какой предпочли бы?

#sql_анна_в_данных
#поболтать_анна_в_данных