Reorganizacja Columnstore Index

Reorganizacja Columnstore Index scala mniejsze fragmenty danych, poprawiając kompresję i wydajność odczytu.

Jak działa reorganizacja indeksu kolumnowego w SQL Server

Reorganizacja Columnstore Index w Microsoft SQL Server jest operacją wykonywaną poleceniem ALTER INDEX z opcją REORGANIZE. Indeks kolumnowy przechowuje dane w grupach wierszy, czyli rowgroups, a każda grupa jest dzielona na segmenty kolumnowe. Segment zawiera wartości jednej kolumny dla określonego zakresu wierszy i może zostać skompresowany niezależnie od pozostałych segmentów. Taki układ pozwala silnikowi odczytywać tylko potrzebne kolumny zamiast pobierać cały wiersz z tradycyjnego indeksu.

Podczas reorganizacji SQL Server wykonuje czynności porządkujące strukturę indeksu. Obejmują one między innymi kompresowanie zamkniętych grup delta store oraz łączenie mniejszych skompresowanych rowgroups, gdy jest to możliwe i uzasadnione zawartością danych. Grupa delta store przechowuje nowe lub zmodyfikowane wiersze w postaci indeksu B-tree, zanim zostaną przeniesione do formatu columnstore. Reorganizacja może więc zmniejszyć liczbę małych grup, poprawić stopień kompresji i ograniczyć liczbę struktur analizowanych przez zapytanie.

Rowgroups, delta store i wpływ operacji DML

Columnstore Index szczególnie dobrze działa wtedy, gdy rowgroups zawierają odpowiednio dużo wierszy i są zapisane w skompresowanej postaci. Wstawianie danych trafia początkowo do deltastore, a po osiągnięciu warunków wymaganych przez mechanizm tuple mover grupa może zostać zamknięta i skompresowana. Usuwanie wierszy nie musi natychmiast fizycznie usuwać ich z segmentu. SQL Server oznacza takie rekordy jako usunięte, a ich obecność może zwiększać koszt skanowania oraz obniżać efektywną kompresję.

Częste aktualizacje i usunięcia mogą doprowadzić do powstania wielu małych lub częściowo pustych rowgroups. Reorganizacja pomaga uporządkować taki indeks, ale nie jest uniwersalnym zamiennikiem pełnej przebudowy. Jej zadaniem jest utrzymanie istniejącej struktury przy mniejszym zakresie zmian. W przypadku poważnej fragmentacji, nieprawidłowego projektu indeksu albo konieczności odtworzenia wszystkich segmentów z nowymi metadanymi może być potrzebne polecenie ALTER INDEX ... REBUILD, którego działanie i wymagania zasobowe są inne.

Uruchomienie i kontrola reorganizacji w SQL Server

Dla konkretnego indeksu reorganizację można uruchomić na przykład poleceniem ALTER INDEX IX_Sprzedaz_Columnstore ON dbo.Sprzedaz REORGANIZE;. Nazwę tabeli i indeksu trzeba zastąpić rzeczywistymi nazwami występującymi w danej bazie. W przypadku indeksu klastrowanego lub nieklastrowanego columnstore polecenie odnosi się do obiektu indeksu, a nie do ogólnej nazwy tabeli. Operację należy wykonywać w czasie, w którym obciążenie zapytaniami i modyfikacjami danych jest możliwe do zaakceptowania, ponieważ reorganizacja zużywa czas procesora, przepustowość dysku i pamięć.

Przed podjęciem decyzji warto sprawdzić stan rowgroups w widoku katalogowym sys.dm_db_column_store_row_group_physical_stats. Widok ten udostępnia między innymi stan rowgroup, liczbę wierszy, liczbę usuniętych wierszy oraz informacje o indeksie i partycji. Przy analizie należy rozróżnić grupy OPEN, CLOSED i COMPRESSED. Duża liczba zamkniętych grup, znaczny udział usuniętych wierszy w grupach skompresowanych albo wiele małych grup może wskazywać na potrzebę konserwacji. Sam fakt występowania deltastore nie oznacza jeszcze awarii, ponieważ jest on normalnym elementem obsługi operacji zapisu.

Ocena efektu po wykonaniu reorganizacji

Po zakończeniu operacji należy ponownie odczytać statystyki rowgroups i porównać je ze stanem początkowym. Warto sprawdzić, czy zmniejszyła się liczba małych grup, czy zamknięte grupy zostały przeniesione do formatu skompresowanego oraz czy poprawił się udział użytecznych wierszy w grupach. Równolegle powinno się zmierzyć rzeczywisty czas i liczbę odczytów zapytań korzystających z indeksu. Sama zmiana liczby rowgroups nie gwarantuje przyspieszenia, jeżeli zapytanie nie filtruje kolumn objętych indeksem, korzysta z nieaktualnych statystyk albo wykonuje kosztowne operacje niezwiązane z odczytem segmentów.

Podczas diagnostyki trzeba także obserwować blokowanie, zużycie CPU, czas oczekiwania na operacje wejścia-wyjścia oraz rozmiar tabeli i indeksu. Jeśli reorganizacja nie przynosi oczekiwanej poprawy, należy zweryfikować schemat partycjonowania, kolejność i selektywność predykatów, częstotliwość modyfikacji danych oraz plan wykonania zapytania. W środowisku z SQL Server konserwacja Columnstore Index powinna być zaplanowana na podstawie obserwowanej kondycji rowgroups i profilu obciążenia, a nie uruchamiana bezwarunkowo po każdym imporcie danych. Dotyczy to zwłaszcza dużych baz, w których nieuzasadniona reorganizacja może konkurować o zasoby z normalnymi operacjami odczytu i zapisu.