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

Question

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

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

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

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

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

Answer 1

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

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

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

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

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

РЕДАКТИРОВАТЬ: чтобы уточнить ...

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

Answer 2

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

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

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

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

Answer 3

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

Реактивный

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

Упреждающий

Тип 1: обычное обслуживание

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

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

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

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

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

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

Answer 4

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

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

Answer 5

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

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