Comments 26
Таким образом , проблему можно сформулировать примерно так :
И на этом все?
То есть рассказа о богоравном SHOWPLAN и стоимости операций не будет ?
В процессе промышленной эксплуатации ситуация меняется принципиально и кардинально.
Нагрузка на СУБД меняется в самых широких диапазонах , и носит случайный характер.
Чего чего?? У вас программа меняется сама по себе и внутри ее меняется тот селект, который сделали разработчики ??
Дальше нужно писать система кеширования на стороне сервера.
индексы нормально делать не пробовали, а не "поиграться" ?
А сидеть оптимизировать запрос это рехнуться можно, бд не для этого создавались
А для чего ????
Да никак ( Можно поиграться с индексами, нормализацией - на этом всё.
Или взять нормальную СУБД, у которой блокировки не ставят раком всю базу. Любую из .. трех или пяти.
Вообще-то нет. Разработчик определяет структуру хранения данных, индексы и сам запрос. СУБД, создавая план запроса, может подстраиваться в очень узких пределах, и, как правило, если этот план отличается от того, что представляет себе разработчик, то либо косяки с индексами, либо косяки с запросом, ну или косяки с данными и хранить их надо по-другому, в другой структуре.
Ну а если разработчик делая запрос не представляет, как этот запрос будет (или должен в его представлении) выполняться, то это очень грустно. Лучшеб ему подтянуть знания. Ибо там все очень просто и элементарно. Просто чуть-чуть знаний алгоритмической сложности структур, в которых хранятся данные в СУБД, чуть-чуть знаний алгоритмической сложности операций, которые СУБД применяет для выборки данных и для соединений, немножко здравого смысла и немножко практики.
Согласен . Именно к такой мысли прихожу .
бд достаточно умна
Неа. БД не в курсе про ваши сценарии использования данных. У неё свои представления о прекрасном. Она не знает, когда надо дропнуть кэш, она не угадает, какие данные надо предварительно закешировать, она не в курсе, что вот этот тяжёлый запрос нужен раз в полгода.
Нормализация включает в себя индексы это раз.
Второе, я сталкивался с ситуацией где в инженеры СУБД уменьшали утилизацию CPU в 10-ки раз делая в SQL-запросе вложение которое «обманывала» сборщик кэша и прочее. Поэтому если я или к примеру вы знаем СУБД на уровне простейших селект/инсерт, то не стоит считать что больше вариаций никаких нет.
Не согласен. Есть и другие подходы. Перевод чтения на стенд-бай, добавление партиций, разделение данные на ноды, разделение на горячие и холодные данные. С точки зрения расширения пропускной способности базы, там можно обыграть по разному. В нашем случае, даже просто сохранение батчами начало помогать)
На хабре любят минусить за здравый смысл.
Поможет только одно. Кэши и оптимизация запросов на стороне приложений.
В самих бд нет большого смысла что то менять, максимум репликацию при масштабировании добавить и следить за нагрузкой. Все ошибки ведущие к снижению скорости созданы на стороне приложений и решаются там же.
А разве не лучше комплексные подходы? Прибить план хороший способ решить деградацию в проде. Не всегда получится подобную проблему решить оперативно
Поможет только одно. Кэши и оптимизация запросов на стороне приложений.
дичь полная. у MS SQL , DB2 и Oracle RAC огромное число настроек и метрик. Крутить надо везде, и на всех маршруте от запроса до процесса исполнения запроса. для этого есть разный мониторинг. но это уже надо думать и даже звать админов.
Вы мониторинги делать не пробовали? Все нормальные БД умеют логировать медленные запросы. Критерий медленности можно настроить.
Потом вдумчиво читаете логи и смотрите какие запросы вчера были быстрыми по вашему критерию, а сегодня стали медленными. Ну или робота отправляете это делать. С этими запросами уже можно работать и смотреть что случилось.
Сверху стоит прикрутить мониторинг медианы времени выполнения и нагрузки на ЦПУ с дисками. Так вы увидите общее просаживание производительности. И будет вообще хорошо.
мониторинг медианы времени выполнения и нагрузки на ЦПУ с дисками. Так вы увидите общее просаживание производительности.
Просаживание производительности чего ? Инфраструктуры или СУБД ?
Вы мониторинги делать не пробовали? Все нормальные БД умеют логировать медленные запросы.
s/ глупости говорите. вы так дойдете до того, что надо читать документацию по бест практик самой базы.
Существует понятие "эталонные тесты". Эталонные тесты это некоторый набор запросов составленный для тестирования бд.
Принцип использования такой: запускаем тесты, получаем результат выполнения запросов, анализируем проблемные моменты (запросы которые выполняются долго), оптимизируем структуру и запросы, запускаем эталонные тесты и сравниваем результаты, потом все с начала.
Ожидания от выполнения запросов можно определить так: "команда разработчиков считает что страница веб сервиса должна открыться за 300 ms.", - чтобы удовлетворить это ожидание данные должны появиться на фронте за ~75 ms. Под эти ожидания пишем запрос(ы) учитывая объем данных в таблице (их может быть много).
У СУБД также есть хорошие инструменты: лог долгих запросов, лог запросов, лист процессов, журнал репликации и др.
Эти инструменты также важны в работе с бд.
Ну как-то так.
Скажу вам , как бывает в реальной жизни - абсолютно принципиально по другому .
Никто ни архитектор , ни менеджер, никто из разработчиков не знает цифр
"команда разработчиков считает что страница веб сервиса должна открыться за 300 ms.", - чтобы удовлетворить это ожидание данные должны появиться на фронте за ~75 ms.
Далее , они не пишут запросы
Под эти ожидания пишем запрос(ы) учитывая объем данных в таблице (их может быть много).
Они используют фреймворки и ORM.
И потом , уже через полгода-год совсем другие люди , не имевшие никакого отношения к разработке системы создают тикет - система стала медленно работать.
В реальной жизни всё происходит сильно не по книжкам.
Query store? Специальный отчет по деградировавшим запросам? Нет, не слышал.
ПыСы. Разумеется это не серебряная пуля
Мониторинг производительности отдельного SQL запроса