Oszczędności na sprzęcie i licencjach

Najkrócej mówiąc, optymalizacja polega na ograniczeniu pobierania i przetwarzania ilości danych przez zapytania SQL.
Najczęściej występującym problemem wydajnościowym jest to, że zamiast pobrać jeden konkretny blok tabeli (dotarcie do bloku i jego odczyt to zazwyczaj 24 kB), odczytujemy, a następnie przetwarzamy całą tabelę.
Im większa jest tabele, tym bardziej nieoptymalnie działa zapytanie i tym bardziej można go przyspieszyć.
Przy wielkości tabeli rzędu 12GB nieoptymalne zapytanie będzie nawet 500 000 razy bardziej obciążało dyski i procesor.

W typowej bazie danych wykonywanych jest kilkadziesiąt tysięcy różnych zapytań SQL. Zapytań problematycznych jest od kilkudziesięciu do stu kilkudziesięciu.
Problematyczne zapytania, pomimo że jest ich stosunkowo niewiele, mogą generować od 40 do 90% obciążenia.

Przyjmijmy, że nieoptymalne zapytania generują niewiele ponad 50% obciążenia.
W takim przypadku, jeżeli uda się zoptymalizować te zapytania, obciążenie serwera bazodanowego spadnie dwukrotnie.
Oznacza to, że bez żadnej straty na wydajności można dwukrotnie zmniejszyć liczbę procesorów przeznaczonych dla bazy.
Czyli albo zastosować serwer lub maszynę wirtualną o mniejszej liczbie core-ów, albo na tej samej maszynie może działać kolejna baza danych.

Zmniejszenie ilości core to nie tylko oszczędności na sprzęcie. To także duże oszczędności na licencjach.
Gdybyśmy osiągnęli dwukrotny wzrost wydajności na serwerze z 64 licencjami Oracle Enterprise Edition, moglibyśmy zaoszczędzić zarówno na kosztach sprzętu, jak i na kosztach 32 licencji Oracle EE. Koszt katalogowy zaoszczędzonych 32 licencji (bez upustów) to 640.000 $, dodatkowo ok. 147.000 $ rocznie opłaty za asystę techniczną.

Oszczędności są oczywiście tym większe, im większy jest nasz system i im więcej mamy licencji.
Ale nawet w przypadku stosunkowo niewielkich środowisk oszczędności będą warte naszej uwagi.

Oszczędności na chmurze

 Wszystkie aplikacje i bazy danych warto optymalizować, jednak największe znaczenie ma to w rozwiązaniach chmurowych.

W chmurze płacimy za faktyczne wykorzystanie procesora, dlatego też zmniejszenie zapotrzebowania na procesor oznaczać będzie znaczne comiesięczne oszczędności.

Łatwo policzyć, jakie oszczędności przyniosłoby dwukrotne zmniejszenie obciążenia procesora.

Pamiętajmy o tym, że w przypadku serwerów bazodanowych w chmurze przepłacamy najprawdopodobniej 20-50%.

Zwiększenie szybkości działania i stabilności aplikacji

Optymalizacja to znaczne skrócenie czasu wykonania nieoptymalnych zapytań.
Zazwyczaj im dłużej wykonuje się dane zapytanie/proces, tym większa szansa, że uda się go zoptymalizować i tym większy będzie efekt optymalizacji.
Dzięki temu znikają problemy z najdłużej działającymi zapytaniami, np. raportami, procesami batch-owymi, zamknięciem miesiąca itp.
Dodatkowo zmniejszenie ilości danych pobieranych z dysku oraz zmniejszenie obciążenia procesora spowoduje, że wszystkie pozostałe zapytania będą wykonywać się szybciej (nie będzie np. oczekiwania na dostęp do dysku).

Optymalizacja powoduje także stabilniejsze działanie serwerów aplikacji (o ile mamy trójwarstwową architekturę aplikacji).
Zapytania w bazie wykonują się znacznie szybciej, co powoduje, że mniejsza jest liczba jednocześnie wykonywanych procesów w serwerze aplikacyjnym. Dużo mniejsza jest szansa wysycenia puli połączeń i kolejkowania się zadań.
Jeżeli serwery aplikacji działają niestabilnie – zawieszają się lub restartują samoistnie, to jest duża szansa, że po optymalizacji te problemy znikną.

Czasami dzięki optymalizacji udaje się to, co wydaje się niewykonalne.
Brałem ostatnio udział w podniesieniu wersji aplikacji u jednego z największych polskich operatorów telco.
Jednym z elementów upgrade-u była zmiana struktury danych w bazie oraz migracja danych do zmienionych struktur.
Dostawca aplikacji dostarczył skrypty, którymi miała być dokonany upgrade.
Testowa migracja przeprowadzona na bazie testowej trwała 12h.
Baza produkcyjne miała ok. 70 razy więcej danych.
Prosta aproksymacja – czas upgrade-u bazy produkcyjnej to ok. 35 dni.

Z biznesowego punktu widzenia to absolutnie nieakceptowalne, żeby aplikacja przez 35 dni była niedostępna.

Dzięki optymalizacji procesu migracji udało się skrócić czas migracji bazy produkcyjnej z 35 dni do 2h (!!), a całość upgrade-u aplikacji zajęła ok 12h.

To bardzo ciekawe, na pewno innych to zainteresuje, bo u nas jest wszystko OK

Przypuszczam, że co najmniej połowa z czytających tę serię artykułów pomyślała w taki lub podobny sposób.
„To ciekawe, na pewno można sporo oszczędzić. Dobrze, że nasi admini dbają o system i my takich problemów nie mamy. Może kiedyś mieliśmy, ale to już zostało poprawione”.

Niestety nie jest to prawda.
Miałem okazję audytować i optymalizować środowiska bazodanowe w największych polskich firmach, np.: Orange, Polkomtel, T-Mobile, Sygnity, IBM BCS, Atos, w polskich bankach. Wszędzie tam pracują bardzo kompetentni ludzie, o ogromnej wiedzy i doświadczeniu.
I wszędzie tam są bardzo duże możliwości optymalizacji.

Z mojego doświadczenia wynika, że na 340 audytowanych środowisk bazodanowych w 338 przypadkach istniały biznesowe przesłanki do optymalizacji, możliwe były spore oszczędności na sprzęcie i licencjach.
Zaledwie w dwóch przypadkach optymalizacja nie miała sensu.

Czy nadal jesteście pewni, że to akurat u Was problemy wydajnościowe nie występują?
I że nie przepłacacie 20-50% za sprzęt i licencje?

Sam sprawdź czy twój system działa wydajnie

Zachęcam do samodzielnego sprawdzenia możliwości optymalizacji Waszych baz danych – przygotowaliśmy program do badania wydajności baz danych (na chwilę obecną gotowa jest wersja dla Oracle, pracujemy nad wersją dla MSSQL i PostgreSQL). Program jest bezpłatny, można go pobrać po zarejestrowaniu się na stronie www.commit-it.pl/perfcheck

W kolejnym artykule opiszę studium przypadku – optymalizację systemu u jednego z największych polskich operatorów telco. Artykuł dostępny jest tutaj

Jeżeli kogoś zainteresował temat optymalizacji i chciałby się dowiedzieć czegoś więcej, zachęcam do kontaktu: optymalizacja@commit-it.pl