Должна ли настройка запросов быть проактивной или реактивной?

Как разработчик программного обеспечения и начинающий администратор баз данных, я стараюсь использовать лучшие практики при проектировании баз данных SQL Server (99% времени мое программное обеспечение располагается поверх SQL Server). Я делаю лучший дизайн до и во время разработки.

Но, как и у любого другого разработчика программного обеспечения, есть добавленная функциональность, ошибки и просто изменение требований, которые требуют измененных / созданных объектов базы данных.

У меня вопрос, должна ли настройка запросов быть проактивной или реактивной? Другими словами, через несколько недель после некоторой серьезной модификации кода / базы данных, я должен просто выделить день, чтобы проверить производительность запросов и настроить их на основе этого? Даже если кажется, что все в порядке ?

Или я должен просто знать, что производительность ниже среднего должна быть проверкой базы данных и возвращением к общеизвестной доске?

Настройка запросов может занять много времени, и в зависимости от первоначального дизайна базы данных это может быть минимальным преимуществом. Мне любопытно относительно принятого способа действий.

Оба, но в основном активны

Во время разработки важно проверять реалистичные объемы и качество данных. Невероятно распространено, чтобы запрос выполнялся для разработчиков на 100 или 1000 строк, а затем не работал с 10 миллионами производственных строк.

Это позволяет вам также делать заметки о том, что «индекс может помочь здесь». Или "вернуться ко мне". Или "исправит с новой функцией ххх в следующей версии БД".

Однако несколько запросов не выдержат испытание временем. Распределение данных изменяется или становится экспоненциальным, потому что оптимизатор решает использовать другой тип соединения. В этом случае вы можете только реагировать.

Говоря, что, по крайней мере для SQL Server, различные DMV-запросы «отсутствующий индекс» и «самый длинный запрос» могут указывать на проблемные области перед телефонным звонком

Изменить: уточнить ...

Упреждающий не означает настроить каждый запрос сейчас. Это означает, что нужно настроить (часто запускать) разумное время отклика. В основном игнорируйте еженедельные запросы на воскресные отчеты в 3 часа утра.

Хорошо, я укушу и приму противоположный взгляд. Во-первых, я бы сказал, что вы никогда не должны начинать делать то, что, как вы знаете, приведет к неприятностям. Если вы хотите назвать это, применяя лучшие практики, продолжайте. Это настолько важно, чтобы быть активным.

После этого время (и деньги) теряется, так что продолжайте в том же духе и доставьте свой продукт. Вместо того, чтобы тратить время на настройку запросов на настройку, которые могут оказаться, а могут и не оказаться узкими местами, используйте это время для дополнительного тестирования, включая нагрузочное тестирование.

Когда вы обнаружите, что что-то не соответствует вашим требованиям к дизайну, или если что-то попадает в нижние 10% или 20% времени отклика вашего профилировщика, потратьте время, которое вам нужно, чтобы настроить то, что есть. сломана.

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

Вы собираетесь делать 3 типа тюнинга, 1 реактивный и 2 проактивный.

реагирующий

Неожиданно, некоторые запросы начинают вызывать у вас проблемы. Это может быть связано с ошибкой или функциональностью приложения, ростом таблицы, превышающей ожидания, всплеском трафика или оптимизмом запроса. Это может быть случай типа «посреди ночи», или это может быть в ответ на медлительность системы некритического характера. В любом случае, определяющим признаком реактивной настройки является то, что у вас уже есть проблема . Излишне говорить, что вы хотите делать как можно меньше этого. Что приводит нас к ...

Проактивная

Тип 1: текущее обслуживание

По какому-то графику, каждые несколько месяцев или недель, в зависимости от того, как часто меняется ваша схема и как быстро растут ваши данные, вы должны просматривать выходные данные инструментов анализа производительности вашей базы данных (например, отчеты AWR для администраторов баз данных Oracle). Вы ищите зарождающиеся проблемы, то есть те вещи, которые на пути к требовательной настройке, а также низко висящие фрукты, предметы, которые вряд ли вызовут проблемы в ближайшее время, но могут быть улучшены без особых усилий в надежде предотвратить проблемы будущего. Сколько времени вы должны потратить на это, будет зависеть от того, сколько времени у вас есть, и на что еще вы могли бы тратить его, но оптимальное количество никогда не бывает равным нулю. Тем не менее, вы можете легко уменьшить сумму, которую вам нужно потратить, выполнив больше ...

Тип 2: Правильный дизайн

Предостережение Кнута против «преждевременной оптимизации» широко известно и должным образом уважается. Но правильное определение «преждевременного» должно быть использовано. Некоторые разработчики приложений, когда им разрешено писать свои собственные запросы, имеют тенденцию принимать самый первый запрос, на который они натолкнулись, который является логически правильным, и не обращают внимания на производительность, настоящее или будущее. Или же они могут проверить набор данных разработки, который просто не является репрезентативным для производственной среды (совет: не делайте этого! Разработчики всегда должны иметь доступ к реалистичным данным для тестирования). Дело в том, что правильное время для настройки запроса - это когда он впервые развертывается, а не когда он отображается в списке неэффективного SQL, и определенно не тогда, когда он вызывает критическую проблему.

Так что же можно квалифицировать как преждевременную оптимизацию на землях DBA? Наверху моего списка будет жертва нормализации без явной необходимости. Конечно, вы можете сохранить сумму в родительской строке, а не вычислять ее во время выполнения из дочерних строк, но вам действительно нужно? Если вы Twitter или Amazon, стратегическая де-нормализация и предварительный расчет могут стать вашими лучшими друзьями. Если вы разрабатываете небольшую учетную базу данных для 5 пользователей, надлежащая структура для обеспечения целостности данных должна быть главным приоритетом. Другие преждевременные оптимизации также являются вопросом приоритетов. Не тратьте часы на настройку запроса, который выполняется один раз в день и занимает 10 секунд, даже если вы думаете, что можете сократить его до 0,1 секунды. Может быть, у вас есть отчет, который работает в течение 6 часов в день, но изучите планирование как пакетное задание, прежде чем тратить время на его настройку. Не вкладывайте средства в отдельный реплицируемый экземпляр отчетности в режиме реального времени, если ваша производственная нагрузка никогда не превышает 10% (при условии, что вы можете управлять безопасностью).

Проводя тестирование на основе реалистичных данных, опираясь на обоснованные предположения о росте и моделях трафика (плюс допуски на пики), и применяя свои знания о причудах оптимизатора вашей платформы, вы можете развертывать запросы, оптимально выполняющие (близкие к) не только сейчас, но и в будущем. и при неидеальных условиях. Когда вы применяете надлежащие методы, производительность запросов можно точно прогнозировать и оптимизировать (в том смысле, что каждый компонент работает настолько быстро, насколько это необходимо).

(И пока вы на это, изучите статистику! )

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

Ваше планирование ретро-настройки очень прагматично. Когда вы тестируете, вы должны документировать ожидаемые сроки и пропускную способность, а иногда и фактически включать анализ, который позволяет вам знать, когда производственные процессы не соответствуют проектным спецификациям. Таким образом, вы сможете заранее определить, какой код нужно настроить. Затем вы можете определить не только, в чем проблема, но и почему вы не уловили ее на этапе проектирования / тестирования.

Для меня тестирование производительности всегда было частью процесса разработки. Хотите изменить эту таблицу, изменить этот отчет, добавить эту функцию? В ходе тестирования вы убедитесь, что можете сравнить индивидуальную и общую производительность с известными базовыми показателями и / или с требованиями (например, некоторые отчеты запускаются в фоновом режиме или иным образом автоматизированы, поэтому производительность - или, скорее, скорость - каждого отдельного запроса в система не всегда является главным приоритетом).

ИМХО, это вообще не должно быть реактивным процессом - вы никогда не должны ждать, пока изменение вызовет проблему производительности на производстве, чтобы начать реагировать на него. Когда вы вносите изменения в dev / test и т. Д., Вы должны тестировать эти изменения с похожими данными на аналогичном оборудовании с теми же приложениями и похожими схемами использования. Не позволяйте этим изменениям срочно отправиться в производство и удивить вас. Это почти всегда происходит, когда не удобно тратить день на настройку - заранее запланируйте бюджет на это время.