O co chodzi z tą optymalizacją
Zdecydowana większość aplikacji IT opartych na bazach danych ma większe lub mniejsze problemy z wydajnością.
Brzmi to dosyć ogólnikowo, więc poniżej postaram się to trochę dokładniej wyjaśnić.
Nasza aplikacja, obojętnie czy będzie to system bilingowy, CRM, portal internetowy czy aplikacja mobilna pobiera dane z bazy danych.
W tym celu łączy się z bazą danych i wykonuje w niej zapytania SQL oraz kod funkcji lub procedur. W olbrzymiej większości są to krótkie zapytania, które dotyczą pojedynczych rekordów, np. wyszukanie kompletu informacji o fakturze, danych o zamówieniu, informacji o danym kliencie.
Z milionów rekordów, np. faktur, wyszukiwany jest jeden lub kilka rekordów o danej fakturze.
Logika nakazuje, aby w takim razie sięgnąć punktowo do tablicy i pobrać tylko jeden lub kilka bloków danych gdzie leżą interesujące nas rekordy. Aby to osiągnąć, używane są indeksy.
Dotarcie do konkretnego bloku danych poprzez indeks i odczyt tego bloku to zazwyczaj 24kB.
Olbrzymia większość zapytań tak robi.
Niestety, zdarzają się takie zapytania, które zamiast sięgnąć bezpośrednio do wybranych bloków, odczytują całą tablicę (wielkości np. 12 GB).
W tym przypadku musimy najpierw odczytać z dysku całą tablicę – 12 GB (tracimy czas i obciążenie I/O), a następnie przetworzyć dane przez procesor (tracimy czas i obciążenie CPU), aby odrzucić te rekordy, które są zbędne.
Mamy więc odczyt i przetwarzanie 12 GB zamiast 24 kB, czyli ok. 500 000 więcej danych niż faktycznie potrzeba i ok. 500 000 razy dłuższe obciążenie procesora.
Można powiedzieć, że jedno jego wykonanie to jak wykonanie 500 000 innych, optymalnych zapytań.
A jeżeli nieoptymalne zapytanie wykonywane jest tysiące razy dziennie?
Każde tego typu zapytanie oznacza znacznie większe obciążenie I/O oraz CPU naszego serwera bazodanowego.
Zdarzają się takie przypadki, gdzie pojedyncze zapytanie generuje nawet 80% (!!!) obciążenia serwera.
Optymalizacja polega na wyszukaniu tego typu zapytań oraz ich naprawie, czyli sprawieniu, żeby pobierały i przetwarzały możliwie jak najmniej danych, tylko te, które są faktycznie potrzebne.
Problem z wydajnością dotyczy praktycznie każdego systemu opartego o bazy danych.
Miałem okazję przeprowadzić ponad 300 audytów wydajności różnych systemów. Tylko w dwóch przypadkach optymalizacja nie miała sensu biznesowego – uzyskany wzrost wydajności byłby zbyt mały w porównaniu do kosztów optymalizacji. Obydwa systemy były wielkości kilku – kilkunastu GB i najdłuższy nieoptymalny proces (raport) wykonywał się poniżej 2s.
We wszystkich pozostałych systemach optymalizacja mogła przynieść korzyści – przyspieszenie działania aplikacji, stabilniejsze działanie serwerów aplikacji, oszczędności na sprzęcie i licencjach.
W kolejnych artykułach opiszę, z czego wynikają tego typu niewydajności oraz ile można zaoszczędzić na sprzęcie i licencjach, przedstawię także przykład optymalizacji. Dla osób technicznych poruszę techniczne aspekty optymalizacji.
Drugi z serii artykułów 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
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, warunkiem jego używania jest rejestracja na stronie www.commit-it.pl/perfcheck
Jedna odpowiedź
Ciekawe informacje na temat nieoptymalnych zapytań. Niestety w wielu przypadkach sposobem na przyspieszenie działania aplikacji jest dołożenie vCPU lub/i RAM do wirtualnej maszyny zamiast przeanalizować zapytania do bazy. Ciekawie brzmi możliwość pobrania aplikacji do samodzielnej analizy nieoptymalności zapytań – chętnie wypróbuję.