Fragmentacja Columnstore

Fragmentacja Columnstore to zjawisko rozproszenia danych w strukturach kolumnowego indeksu, obniżające jego wydajność.

Na czym polega fragmentacja indeksu columnstore

Fragmentacja columnstore oznacza pogorszenie uporządkowania i wykorzystania danych zapisanych w kolumnowym indeksie. W takim indeksie rekordy nie są przechowywane wyłącznie jako klasyczne wiersze, lecz są dzielone na grupy wierszy, a wartości poszczególnych kolumn trafiają do oddzielnych segmentów. Pozwala to odczytywać tylko te kolumny, które są potrzebne zapytaniu, oraz skutecznie stosować kompresję. Fragmentacja pojawia się wtedy, gdy struktura indeksu zawiera wiele niepełnych grup wierszy, grup o nierównomiernym rozmiarze albo grup, w których znaczna część rekordów została oznaczona jako usunięta.

Najczęściej źródłem problemu jest intensywne wykonywanie operacji UPDATE i DELETE na danych objętych indeksem columnstore. Usunięty rekord może zostać oznaczony w strukturze pomocniczej jako nieważny, ale jego fizyczne usunięcie i ponowne uporządkowanie danych następuje dopiero podczas konserwacji indeksu. Aktualizacja może natomiast oznaczać starą wersję wiersza jako usuniętą i zapisać zmienione wartości w innym miejscu. W rezultacie zapytanie analityczne może sprawdzać większą liczbę segmentów i pomijać większą liczbę rekordów oznaczonych jako nieaktualne.

Wpływ grup wierszy i usuniętych rekordów na zapytania

Columnstore osiąga dobrą wydajność między innymi dzięki przetwarzaniu danych partiami oraz eliminowaniu segmentów, które na podstawie metadanych nie mogą zawierać wartości spełniających warunek zapytania. Jeżeli wartości są rozłożone w wielu słabo skompresowanych lub niepełnych segmentach, możliwości takiego pomijania są mniejsze. Silnik może wtedy odczytać więcej danych z dysku lub pamięci, wykonać więcej operacji dekompresji i zużyć więcej czasu procesora. Fragmentacja nie musi więc oznaczać uszkodzenia indeksu. Jest to przede wszystkim stan, w którym struktura nadal jest poprawna logicznie, ale mniej korzystna dla zapytań.

Istotne jest rozróżnienie pomiędzy skompresowaną grupą wierszy a grupą delta. Nowe lub często zmieniane dane mogą przez pewien czas trafiać do obszaru delta, który jest przeznaczony do obsługi operacji transakcyjnych. Później specjalny mechanizm przenosi zamknięte grupy delta do formatu columnstore. Duża liczba małych grup delta może zwiększać narzut odczytu, natomiast skompresowane grupy z wieloma usuniętymi rekordami zawierają dane, których zapytania muszą w praktyce omijać. Ocena fragmentacji powinna zatem obejmować stan grup wierszy, liczbę wszystkich rekordów i liczbę rekordów oznaczonych jako usunięte.

Rozpoznawanie problemu w strukturze columnstore

Diagnoza powinna rozpocząć się od ustalenia, czy wolniejsze zapytania rzeczywiście korzystają z indeksu columnstore oraz czy ich plan wykonania zmienił się po wzroście liczby operacji modyfikujących dane. Sam czas wykonania pojedynczego zapytania nie wystarcza do potwierdzenia fragmentacji, ponieważ podobny objaw mogą powodować nieaktualne statystyki, ograniczona pamięć, oczekiwanie na operacje wejścia-wyjścia, blokady lub zmiana selektywności warunków. Potrzebne jest porównanie planów wykonania, obciążenia zasobów i stanu grup wierszy.

W środowisku Microsoft SQL Server informacje o fizycznym stanie grup wierszy columnstore można analizować za pomocą widoku dynamicznego sys.dm_db_column_store_row_group_physical_stats. Przydatne są między innymi kolumny opisujące stan grupy, liczbę wierszy, liczbę usuniętych wierszy oraz identyfikator partycji. Wysoki udział usuniętych wierszy w wielu grupach jest sygnałem narastającej fragmentacji. Należy jednak interpretować go razem z charakterem obciążenia. Jeżeli tabela jest stale zasilana i podlega częstym zmianom, chwilowa obecność grup delta może być normalna, a natychmiastowa przebudowa po każdej modyfikacji powodowałaby niepotrzebne zużycie zasobów.

Porządkowanie indeksu i kontrola skutków konserwacji

Podstawową operacją ograniczającą fragmentację columnstore jest reorganizacja indeksu. W Microsoft SQL Server polecenie ALTER INDEX ... REORGANIZE może usuwać fizycznie rekordy oznaczone jako usunięte oraz poprawiać ułożenie grup wierszy. Reorganizacja jest zwykle mniej radykalna niż pełna przebudowa i może być wykonywana jako operacja online, ale nadal zużywa czas procesora, pamięć oraz przepustowość wejścia-wyjścia. W przypadku danych podzielonych na partycje można ograniczyć zakres prac do tych partycji, w których rzeczywiście występuje problem.

Przebudowa indeksu tworzy jego strukturę ponownie i może usunąć skutki większych zmian w danych, lecz wymaga starannego zaplanowania. Przed jej wykonaniem trzeba sprawdzić dostępne miejsce, obciążenie bazy, czas trwania operacji oraz wpływ na równoległe zapytania. Nie powinno się stosować stałego harmonogramu przebudowy wyłącznie dlatego, że dotyczy on klasycznych indeksów wierszowych. Dla columnstore decyzję lepiej oprzeć na pomiarach: udziale usuniętych rekordów, liczbie i stanie grup wierszy, planach zapytań oraz rzeczywistym wzroście czasu odczytu. Po konserwacji należy ponownie zmierzyć te parametry, aby potwierdzić, że operacja poprawiła jakość struktury, a nie tylko zwiększyła chwilowe zużycie zasobów.