Czy dostrajanie zapytań powinno być proaktywne czy reaktywne?

Jako programista i początkujący DBA staram się stosować najlepsze praktyki, projektując bazy danych SQL Server (99% czasu, gdy moje oprogramowanie znajduje się nad SQL Server). Robię najlepszy możliwy projekt przed i podczas rozwoju.

Ale, podobnie jak każdy inny programista, dodano funkcjonalność, błędy i po prostu zmianę wymagań, które wymagają zmiany / utworzenia obiektów bazy danych.

Moje pytanie brzmi: czy tuning zapytań powinien być proaktywny czy reaktywny? Innymi słowy, czy po kilku tygodniach od jakiejś ciężkiej modyfikacji kodu / bazy danych powinienem poświęcić dzień na sprawdzenie wydajności zapytań i dostrojenie się do tego? Nawet jeśli wydaje się, że działa dobrze ?

A może powinienem mieć świadomość, że wydajność poniżej średniej powinna być sprawdzeniem bazy danych i powrotem do przysłowiowej tablicy?

Strojenie zapytań może zająć dużo czasu, a w zależności od początkowego projektu bazy danych może to być minimalna korzyść. Jestem ciekawy co do przyjętego sposobu działania.

Oba, ale w większości proaktywne

Ważne jest, aby podczas projektowania testować realistyczne ilości i jakość danych. Jest niewiarygodnie powszechne, że zapytanie działa na deweloperach 100 lub 1000 wierszy, a następnie spada na 10 milionów wierszy produkcyjnych.

Pozwala także robić notatki na temat „indeks może tutaj pomóc”. Lub „odwiedź mnie ponownie”. Lub „naprawi nową funkcję xxx w następnej wersji DB”.

Jednak kilka zapytań nie wytrzyma próby czasu. Dystrybucja danych zmienia się lub staje się wykładnicza, ponieważ optymalizator decyduje się na użycie innego typu łączenia. W takim przypadku możesz tylko zareagować.

Mówiąc, że przynajmniej dla SQL Server, różne zapytania „brakujący indeks” i „najdłuższe zapytanie” DMV mogą wskazywać obszary problemowe przed rozmową telefoniczną

Edytuj: aby wyjaśnić ...

Proaktywne nie oznacza teraz dostrojenia każdego zapytania. Oznacza to dostrojenie tego, co trzeba (często uruchamiać), do rozsądnego czasu reakcji. Najczęściej ignoruj ​​cotygodniowe zapytania w niedziele o 3 rano.

OK, ugryzę i przyjmę pogląd sprzeczny. Po pierwsze, powiedziałbym, że nigdy nie powinieneś zaczynać od robienia czegoś, o czym wiesz, że doprowadzi cię do kłopotów. Jeśli chcesz nazwać to stosowaniem najlepszych praktyk, śmiało. Jest to tak dalece, jak powinno być proaktywne.

Potem marnujesz czas (i pieniądze), więc zacznij z tym i dostarczaj swój produkt. Zamiast zajmować mnóstwo zapytań dotyczących dostrajania czasu projektowania, które mogą lub nigdy nie okażą się wąskimi gardłami, wykorzystaj ten czas na dodatkowe testy, w tym testy obciążenia.

Jeśli dowiesz się, że coś nie spełnia wymagań specyfikacji projektu lub jeśli coś mieści się w dolnej 10% lub 20% listy czasów odpowiedzi twojego profilera, zainwestuj czas, który potrzebujesz, aby ulepszyć cokolwiek to jest złamany.

W idealnym świecie wszystko byłoby idealnie zaprojektowane od samego początku i opracowane przy użyciu logicznej sekwencji kompilacji. W prawdziwym świecie istnieją ograniczenia dotyczące budżetu i czasu, a dane testowe mogą nie wyglądać jak dane produkcyjne. Z tego powodu mówię, aby zachować zdrowy rozsądek, aby proaktywnie unikać problemów, ale skoncentruj swoje ograniczone zasoby na dostrajaniu rzeczy, które okazują się prawdziwymi problemami, zamiast tracić czas i pieniądze, których prawdopodobnie nie masz na poszukiwanie wyobrażonych lub potencjalnych problemów.

Będziesz robił 3 rodzaje strojenia, 1 reaktywny i 2 proaktywny.

Reaktywny

Niespodziewanie niektóre zapytania zaczynają powodować problemy. Może to być spowodowane błędem lub funkcją aplikacji, tabelą przekraczającą oczekiwania, skokiem ruchu lub optymalizacją zapytań, która staje się „kreatywna”. Może to być romans w środku nocy, a nawet bzdury w odpowiedzi na spowolnienie systemu o niekrytycznym charakterze. Tak czy inaczej, charakterystyczny charakter reaktywnego strojenia jest taki, że już masz problem . Nie trzeba dodawać, że chcesz robić to jak najmniej. Co prowadzi nas do ...

Proaktywne

Typ 1: Rutynowa konserwacja

Co jakiś czas, co kilka miesięcy lub tygodni, w zależności od tego, jak często zmienia się twój schemat i jak szybko rosną twoje dane, powinieneś przejrzeć dane wyjściowe narzędzi analizy wydajności bazy danych (np. Raporty AWR dla Oracle DBA). Szukasz początkowych problemów, czyli rzeczy, które na ich drodze wymagają Reaktywnego strojenia, a także nisko wiszących owoców, przedmiotów, które prawdopodobnie nie spowodują problemów wkrótce, ale które można poprawić przy niewielkim wysiłku w nadziei, że uda się zapobiec daleko przyszłe problemy. Ile czasu powinieneś poświęcić na to, zależy od tego, ile masz czasu i na co jeszcze możesz go poświęcić, ale optymalna ilość nigdy nie wynosi zero. Możesz jednak łatwo zmniejszyć kwotę, którą musisz wydać, wykonując więcej ...

Typ 2: Właściwa konstrukcja

Przestroga Knutha przeciwko „przedwczesnej optymalizacji” jest powszechnie znana i należycie szanowana. Ale należy zastosować właściwą definicję „przedwczesnego”. Niektórzy programiści aplikacji, gdy mają pozwolenie na pisanie własnych zapytań, mają tendencję do przyjmowania pierwszego zapytania, na które trafiają, które jest logicznie poprawne i nie zwracają uwagi na wydajność, teraźniejszość ani przyszłość. Lub mogą przetestować zestaw danych programistycznych, który po prostu nie jest reprezentatywny dla środowiska produkcyjnego (wskazówka: nie rób tego! Deweloperzy powinni zawsze mieć dostęp do realistycznych danych do testowania). Chodzi o to, że odpowiedni moment na dostrojenie zapytania jest wtedy, gdy jest on wdrażany po raz pierwszy, a nie kiedy pojawia się na liście słabo wykonanego SQL, a na pewno nie, gdy powoduje krytyczny problem.

Co zatem kwalifikuje się jako przedwczesna optymalizacja gruntów DBA? Na szczycie mojej listy poświęciłem normalizację bez wykazanej potrzeby. Pewnie, że możesz zachować sumę w wierszu nadrzędnym zamiast obliczać ją w czasie wykonywania z wierszy potomnych, ale czy naprawdę potrzebujesz? Jeśli jesteś na Twitterze lub Amazon, strategiczna dezormalizacja i wstępne obliczenia mogą być twoimi najlepszymi przyjaciółmi. Jeśli projektujesz małą bazę danych dla 5 użytkowników, priorytetem musi być odpowiednia struktura ułatwiająca integralność danych. Inne przedwczesne optymalizacje są również kwestią priorytetów. Nie marnuj godzin na ulepszanie zapytania, które uruchamia się raz dziennie i zajmuje 10 sekund, nawet jeśli uważasz, że możesz je skrócić do 0,1 sekundy. Może masz raport, który działa przez 6 godzin dziennie, ale zapoznaj się z planowaniem go jako zadania wsadowego przed zainwestowaniem czasu w jego dostrojenie. Nie inwestuj w osobną, replikowaną w czasie rzeczywistym instancję raportowania, jeśli obciążenie produkcyjne nigdy nie przekroczy 10% (zakładając, że możesz zarządzać bezpieczeństwem).

Testując w oparciu o realistyczne dane, wykształcając domysły na temat wzorców wzrostu i ruchu (plus limity na wzrosty) oraz stosując swoją wiedzę o dziwactwach optymalizujących platformę, możesz wdrożyć zapytania, które działają (blisko) optymalnie nie tylko teraz, ale w przyszłości i w warunkach mniej niż idealnych. Po zastosowaniu odpowiednich technik wydajność kwerendy można dokładnie przewidzieć i zoptymalizować (w tym sensie, że każdy komponent jest tak szybki, jak to konieczne).

(I kiedy już to robisz, ucz się statystyki! )

W idealnym świecie wszystkie strojenie odbywałoby się w fazie projektowania proaktywnie i nic nie byłoby reaktywne, ale świat nie jest idealny. Przekonasz się, że czasami dane testowe nie są reprezentatywne, przypadki testowe zostaną pominięte, obciążenia będą nieoczekiwanie różne i pojawią się błędy, które powodują problemy z wydajnością. Te sytuacje mogą wymagać strojenia reaktywnego, ale to nie znaczy, że strojenie reaktywne jest preferowane. Celem zawsze powinno być złapanie ich z góry.

Twoje planowanie wstecznego strojenia jest bardzo pragmatyczne. Podczas testowania powinieneś udokumentować oczekiwane czasy i przepustowość, a czasami powinien faktycznie opierać się na analizie, która pozwoli ci wiedzieć, kiedy procesy produkcyjne nie spełniają specyfikacji projektowych. W ten sposób możesz z wyprzedzeniem określić, jaki kod należy dostroić. Następnie możesz określić nie tylko, na czym polega problem, ale także dlaczego nie złapałeś go w fazie projektowania / testowania.

Dla mnie testy wydajności zawsze były częścią procesu rozwoju. Chcesz zmienić tę tabelę, zmienić ten raport, dodać tę funkcję? W ramach testów upewniasz się, że możesz porównać indywidualną i ogólną wydajność ze znanymi wartościami bazowymi i / lub z wymaganiami (np. Niektóre raporty działają w tle lub są w inny sposób zautomatyzowane, więc wydajność - a raczej szybkość - każdego zapytania w system nie zawsze jest najwyższym priorytetem).

IMHO, to wcale nie powinien być proces reaktywny - nigdy nie należy czekać, aż zmiana spowoduje, że problem z wydajnością w produkcji zacznie na nią reagować. Kiedy wprowadzasz zmiany w dev / test itp., Powinieneś testować te zmiany z podobnymi danymi na podobnym sprzęcie z tymi samymi aplikacjami i podobnymi wzorcami użytkowania. Nie pozwól, aby te zmiany zostały wprowadzone do produkcji i Cię zaskoczyły. Stanie się to prawie zawsze, gdy nie będzie wygodnie spędzić dzień na strojeniu - budżet na ten czas strojenia z dużym wyprzedzeniem.