Как в компаниях борются с тяжелыми запросами ⌨️ Существуют разные подходы к тому, чтобы не случилось мемной ситуации, когда аналитик случайно положил базу Как правило аналитики не имеют доступа к продовой БД и работают в аналитических репликах, но плохой запрос там может помешать обновлению дашбордов, загрузке витрин и работе коллег 🔵Автоматические лимиты в СУБД Например, по времени выполнения или объему потребляемой памяти. При превышении запрос упадет с ошибкой, и аналитику ничего не останется, кроме как оптимизировать его 🔵Киллеры плохих запросов Может существовать скрипт с более гибкими и сложными условиями, который сканирует выполняющиеся запросы и “убивает” все подозрительные 🔵Социальное давление или доска позора Тогда явных ограничений может и не быть, но каждый аналитик знает: если из-за его запроса все начнет виснуть, админы опубликуют его в общий доступ с очень неприятной припиской. Опасаясь общественного порицания, аналитики пускают в ход все свои знания об оптимизации запросов 🔵Другая версия этого - полная прозрачность Когда каждый может посмотреть содержимое и авторов выполняющихся сейчас запросов. И в личку к виновнику сразу повалят его коллеги 🔵Запрет доступа к сырым данным Могут ограничить доступ к гигантским сырым таблицам для отдельных ролей, а дать только к витринам с уже агрегированными данными. Это избавляет от лишних вычислений и сокращает количество обрабатываемых строк А какой подход выбран у вас в компании и какой предпочли бы? #sql_анна_в_данных #поболтать_анна_в_данных