Чи має бути налаштування запитів проактивним чи реактивним?

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

Але, як і будь-який інший розробник програмного забезпечення, є додаткова функціональність, помилки та просто зміна вимог, які вимагають змінених / створених об'єктів бази даних.

Моє запитання: чи налаштування запитів має бути ініціативною чи реактивною? Іншими словами, через кілька тижнів після важкої модифікації коду / бази даних я повинен просто відкласти день, щоб перевірити продуктивність запитів і налаштувати його на основі? Навіть якщо це, здається, працює нормально ?

Або я просто повинен усвідомлювати, що менша від середньої продуктивності повинна бути перевірка бази даних та повернення до добірної дошки?

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

І те, і інше, але переважно ініціативне

Важливо перевірити під час розробки на предмет реалістичного обсягу та якості даних. Неймовірно звичайним є запит, який працює на розробниках 100 або 1000 рядків, а потім випадає 10 мільйонів виробничих рядків.

Це дозволяє також робити примітки про "індекс може допомогти тут". Або "переглянь мене". Або "буде виправлено за допомогою нової функції xxx у наступній версії БД".

Однак кілька запитів не витримають випробування часом. Розподіл даних змінюється, або він стає експоненціальним, оскільки оптимізатор вирішує використовувати інший тип з'єднання. У цьому випадку можна лише реагувати.

Сказавши, що принаймні для SQL Server різні запити «відсутніх індексів» та «найдовший запит» DMV можуть вказувати на проблемні області перед телефонним дзвінком

Редагувати: для уточнення ...

Проактивний не означає налаштування кожного запиту зараз. Це означає, що потрібно налаштувати те, що потрібно (часто виконувати) до розумного часу реакції. Здебільшого ігноруйте щотижневі запити звітів у неділю о 3 ранку.

Гаразд, я кусаю і прийму протилежний погляд. По-перше, я б сказав, що ніколи не слід починати робити щось, що, на вашу думку, призведе до неприємностей. Якщо ви хочете назвати це, застосовуючи кращі практики, продовжуйте. Це настільки, наскільки має бути активним.

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

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

У ідеальному світі все було б розроблено ідеально з самого початку і розвивалося з використанням логічної послідовності побудови. У реальному світі є обмеження щодо бюджету та часу, і ваші тестові дані можуть не виглядати як ваші виробничі дані. З цієї причини я кажу, що використовуйте здоровий глузд, щоб уникати проблем, але концентруйте свої обмежені ресурси, налаштовуючи на речі, які виявляються справжніми проблемами, а не витрачати час і гроші, які, ймовірно, не мають на пошук уявних чи потенційних проблем.

Ви будете робити 3 типи налаштування, 1 реактивну та 2 проактивні.

Реактивний

Незрозуміло, якийсь запит починає створювати проблеми. Це може бути через помилку програми чи функції, таблицю, що перевищує очікування, стрибок трафіку або оптимізатор запитів, що стає "креативним". Це може бути тип справ у середині ночі о-лайно, або це може бути реакцією на системну повільність некритичного характеру. Так чи інакше, визначальним характером реактивної настройки є те, що у вас вже є проблеми . Зайве говорити, що ви хочете робити якомога менше цього. Що приводить нас до ...

Проактивний

Тип 1: Повсякденне обслуговування

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

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

Застереження Кнута проти "передчасної оптимізації" широко відоме і належним чином поважається. Але треба використовувати правильне визначення поняття "передчасний". Деякі розробники додатків, коли їм дозволяється писати власні запити, мають тенденцію приймати перший запит, на який вони звертаються, логічно правильний, і не враховують їх ефективність, теперішню чи майбутню перспективу. Або вони можуть перевірити набір даних про розробку, який просто не є репрезентативним виробничим середовищем (порада: Не робіть цього! Розробники повинні завжди мати доступ до реалістичних даних для тестування.) Справа в тому, що правильний час для налаштування запиту - це коли він вперше розгортається, а не тоді, коли він відображається у списку неякісних SQL, і, безумовно, не тоді, коли він викликає критичну проблему.

Отже, що може бути кваліфікованим як передчасна оптимізація в землі DBA? У верхній частині мого списку було б жертвоприношення нормалізації без продемонстрованої потреби. Впевнені, що ви могли зберегти суму на батьківському рядку, а не обчислювати її під час виконання з дочірніх рядків, але чи справді вам це потрібно? Якщо ви Twitter чи Amazon, стратегічна денормалізація та попередній розрахунок можуть стати вашими найкращими друзями. Якщо ви розробляєте невелику базу даних бухгалтерського обліку для 5 користувачів, належна структура для полегшення цілісності даних має бути головним пріоритетом. Інші передчасні оптимізації також є питанням пріоритетів. Не витрачайте години на виправлення запиту, який запускається раз на день і займає 10 секунд, навіть якщо ви думаєте, що можете скоротити його до 0,1 секунди. Можливо, у вас є звіт, який працює 6 годин щодня, але вивчіть її планування як пакетну роботу, перш ніж вкладати час в її настройку. Не вкладайте гроші в окремий екземпляр реплікаційного звітування в реальному часі, якщо виробниче навантаження ніколи не перевищує 10% (якщо припускати, що ви можете керувати безпекою).

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

(І поки ти на це, дізнайся статистику! )

У ідеальному світі все налаштування здійснювалося б на стадії проектування проактивно, і нічого не було б реактивним, але світ не ідеальний. Ви виявите, що дані тесту іноді не є репрезентативними, тестові випадки будуть пропущені, завантаження будуть несподівано різними, і з’являться помилки, які спричинять проблеми з продуктивністю. У цих ситуаціях може знадобитися деяка реактивна настройка, але це не означає, що реактивна настройка є кращою. Завдання завжди повинна полягати в тому, щоб їх наздогнати.

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

Для мене тестування продуктивності завжди було частиною процесу розробки. Хочете змінити цю таблицю, змінити цей звіт, додати цю функцію? У рамках тестування ви переконуєтеся, що можете порівняти індивідуальні та загальні показники роботи з відомими базовими лініями та / або проти вимог (наприклад, деякі звіти працюють у фоновому режимі або автоматизовані іншим чином, тому виконання або, швидше, швидкість) кожного окремого запиту в система не завжди є першочерговим пріоритетом).

ІМХО, це взагалі не повинно бути реагуючим процесом - ніколи не слід чекати, поки зміна спричинить проблеми у виробництві, щоб почати на це реагувати. Коли ви вносите зміни в програму dev / test тощо, вам слід протестувати ці зміни зі схожими даними на аналогічному обладнанні з тими ж додатками та подібними моделями використання. Не дозволяйте цим змінам прискорити виробництво і здивувати вас. Це майже завжди станеться, коли не зручно проводити налаштування дня - заздалегідь заздалегідь сплатіть бюджет на цю настройку.