Diagnostyka zapytań z Columnstore

Diagnostyka zapytań z Columnstore to proces analizy wydajności zapytań wykorzystujących ten kolumnowy format indeksu.

Jak kolumnowy sposób przechowywania zmienia wykonanie zapytania

Diagnostyka zapytań z Columnstore polega na sprawdzeniu, czy silnik bazy danych rzeczywiście korzysta z właściwości indeksu kolumnowego, a nie tylko odczytuje duży zakres danych bez oczekiwanej redukcji kosztu. W klasycznym indeksie wierszowym dane są organizowane przede wszystkim według rekordów. Columnstore przechowuje wartości poszczególnych kolumn w grupach wierszy, dzięki czemu zapytanie agregujące jedną lub kilka kolumn może pominąć kolumny, które nie są potrzebne do obliczeń. Ocenie podlega więc między innymi liczba odczytywanych kolumn, zakres przetwarzanych grup wierszy oraz sposób wykonania operatorów filtrujących i agregujących.

Istotnym elementem analizy jest rozróżnienie przetwarzania wektorowego od przetwarzania wierszowego. Batch mode przetwarza dane w większych paczkach wartości, co zwykle ogranicza narzut wywołań operatorów i poprawia wydajność operacji analitycznych. Row mode analizuje rekordy pojedynczo. Sama obecność indeksu Columnstore nie gwarantuje użycia batch mode, dlatego należy sprawdzić rzeczywisty plan wykonania, a nie wyciągać wniosku wyłącznie z definicji tabeli lub indeksu.

Plan wykonania, predykaty i eliminacja grup wierszy

Podstawowym źródłem informacji jest rzeczywisty plan wykonania zapytania. Należy porównać operator użyty do odczytu danych z oczekiwanym operatorem skanu indeksu kolumnowego, sprawdzić tryb wykonania oraz przeanalizować szacowaną i rzeczywistą liczbę wierszy. Duża rozbieżność między tymi wartościami może prowadzić do błędnego wyboru kolejności operatorów, nieprawidłowego rozmiaru pamięci przydzielonej na sortowanie lub agregację albo zastosowania niewłaściwego sposobu łączenia tabel.

W Columnstore szczególne znaczenie ma eliminacja grup wierszy. Dane są dzielone na rowgroups, czyli grupy wierszy opisane między innymi minimalną i maksymalną wartością kolumny. Jeżeli predykat zapytania pozwala stwierdzić, że dana grupa nie zawiera pasujących wartości, silnik może pominąć jej odczyt. Diagnostyka powinna zatem sprawdzać, czy filtr jest przekazywany do operatora skanu oraz czy jego postać umożliwia ograniczenie zakresu danych. Funkcja zastosowana na filtrowanej kolumnie, niejawna konwersja typu albo porównanie utrudniające wykorzystanie uporządkowania wartości może zwiększyć liczbę odczytywanych grup.

Trzeba również odróżnić eliminację całych kolumn od eliminacji rowgroups. Odczyt tylko kilku kolumn ogranicza ilość danych pobieranych z magazynu, lecz nie musi zmniejszyć liczby analizowanych grup wierszy. Z kolei skuteczny predykat może pominąć całe zakresy danych, ale niekoniecznie ograniczy liczbę kolumn potrzebnych do wykonania pozostałych operatorów. Te dwa mechanizmy należy analizować oddzielnie.

Agregacje, złączenia i obciążenie pamięci

Zapytania korzystające z Columnstore często wykonują agregacje, takie jak suma, liczba rekordów lub wartości minimalne i maksymalne. W planie trzeba sprawdzić, czy agregacja działa w trybie wektorowym, ile wierszy trafia do operatora oraz czy agregacja jest wykonywana przed złączeniem tabel, czy dopiero po nim. Przeniesienie redukcji danych na wcześniejszy etap może zmniejszyć koszt złączeń, ale skuteczność zależy od semantyki zapytania i dostępnych predykatów. Nie można zakładać poprawy bez porównania planu oraz pomiaru czasu, liczby odczytów i użycia procesora.

Przy analizie złączeń należy sprawdzić, czy estymowana liczność obu stron odpowiada rzeczywistym danym. Błędna estymacja może spowodować wybór złączenia wymagającego dużej ilości pamięci albo doprowadzić do wielokrotnego odczytu danych. Warto obserwować ostrzeżenia planu dotyczące spill do tempdb, czyli sytuacji, w której sortowanie, haszowanie lub agregacja nie mieści się w przydzielonej pamięci i musi wykorzystać obszar roboczy na dysku. Taki objaw może wskazywać zarówno na zbyt mały przydział pamięci, jak i na nieprawidłową ocenę liczby wierszy.

Pomiar powinien obejmować kilka powtórzeń tego samego zapytania i rozdzielać czas kompilacji od czasu wykonania. Należy rejestrować logiczne odczyty, czas procesora, czas upływający oraz plan wykonania. Wynik pojedynczego uruchomienia może być zaburzony przez stan pamięci podręcznej, równoległość, konkurencyjne obciążenie lub oczekiwanie na zasoby. Porównanie przed i po zmianie wymaga zachowania tych samych parametrów, zakresu danych i warunków środowiskowych.

Diagnostyka fragmentacji danych i weryfikacja poprawy

Wydajność indeksu kolumnowego zależy również od jakości rowgroups. Grupy o małej liczbie wierszy, dane pozostające w deltastore oraz częste modyfikacje mogą zwiększać koszt odczytu i ograniczać korzyści z kompresji. W diagnostyce należy sprawdzić, czy tabela jest głównie odczytywana, czy intensywnie modyfikowana, jak duża część danych trafia do struktur przejściowych oraz czy proces porządkowania i kompresowania grup przebiega prawidłowo. Szczególną uwagę wymagają tabele, do których stale napływają pojedyncze rekordy, ponieważ taki sposób zapisu może nie tworzyć od razu dużych, dobrze skompresowanych grup.

Nie każda wolna kwerenda wymaga przebudowy indeksu. Najpierw trzeba ustalić, czy problem wynika z braku selektywnego filtra, błędnych statystyk, niejawnej konwersji, niekorzystnego złączenia, presji pamięci czy blokowania. Dopiero po rozdzieleniu tych przyczyn można ocenić zasadność zmiany indeksu, aktualizacji statystyk lub modyfikacji zapytania. Każda zmiana powinna być zweryfikowana na reprezentatywnym zbiorze danych, z użyciem rzeczywistego planu i porównywalnych metryk.

Diagnostyka sprzętu, systemu operacyjnego i środowiska uruchomieniowego może uzupełniać analizę, gdy plan wskazuje na ograniczenia procesora, pamięci masowej lub pamięci operacyjnej. W przypadku problemów z zapytaniami Columnstore konieczne jest jednak zachowanie rozdziału między usterką infrastruktury a nieefektywnym planem wykonania. Naprawa laptopa lub komputera PC nie zastępuje analizy silnika bazy danych, planu zapytania i organizacji danych.