Updatable Columnstore Index

Updatable Columnstore Index umożliwia modyfikację danych w indeksie kolumnowym bez konieczności jego ponownego budowania.

Updatable Columnstore Index w SQL Server

Updatable Columnstore Index to indeks kolumnowy w Microsoft SQL Server, który może uczestniczyć nie tylko w odczycie danych, lecz także w operacjach modyfikujących wiersze tabeli. W klasycznym indeksie kolumnowym dane są przechowywane przede wszystkim w postaci grup kolumnowych, czyli struktur zoptymalizowanych do skanowania wybranych kolumn i wykonywania agregacji na dużych zbiorach. Wersja obsługująca aktualizacje pozwala wykonywać instrukcje INSERT, UPDATE i DELETE bez usuwania indeksu i tworzenia go od początku po każdej zmianie.

Określenie „updatable” nie oznacza, że pojedynczy segment kolumnowy jest edytowany tak samo jak rekord w indeksie B-tree. SQL Server zarządza zmianami za pomocą kilku struktur. Nowe lub zmodyfikowane wiersze mogą trafić do rowgrou­py delta store, która jest przechowywana w formie wierszowej. Wiersze usuwane z już skompresowanych grup są oznaczane w delete bitmap, a zmiany aktualizowanego rekordu są logicznie realizowane jako usunięcie poprzedniej wersji i wstawienie nowej. Dzięki temu indeks pozostaje aktualny dla zapytań, chociaż nie każda modyfikacja powoduje natychmiastową przebudowę skompresowanych danych kolumnowych.

Jak SQL Server obsługuje modyfikacje danych

Wiersze przeznaczone do indeksu kolumnowego są organizowane w rowgroups. Dojrzała rowgroup zawiera dane skompresowane kolumnowo, natomiast delta rowgroup pełni funkcję obszaru przejściowego dla wierszy, które nie zostały jeszcze skompresowane. Proces odpowiedzialny za przejście danych z delta store do formatu columnstore jest nazywany tuple mover. Po zamknięciu delta rowgroup SQL Server może skompresować ją do właściwej struktury kolumnowej. Konkretne zachowanie zależy od wersji silnika, wielkości partii, obciążenia oraz stanu indeksu.

Operacja INSERT może zapełniać otwartą delta rowgroup, a przy większych partiach danych może prowadzić do bezpośredniego utworzenia skompresowanej rowgroup. Instrukcja DELETE nie musi natychmiast fizycznie usuwać danych z segmentów. Zamiast tego SQL Server rejestruje usunięcie w delete bitmap, dzięki czemu skaner indeksu pomija logicznie usunięte wiersze. Przy UPDATE zmiana wartości może wymagać zapisania nowej wersji wiersza oraz oznaczenia starej wersji jako usuniętej. Z tego powodu częste aktualizacje mogą zwiększać liczbę nieaktywnych wierszy i obniżać stopień kompresji.

Podczas wykonywania zapytania SQL Server łączy informacje ze skompresowanych rowgroups, delta store oraz mechanizmu oznaczeń usuniętych wierszy. Użytkownik odwołuje się do tabeli, a optymalizator wybiera dostępny plan wykonania. Indeks kolumnowy nie jest więc osobną kopią danych, którą trzeba ręcznie synchronizować po każdym poleceniu DML. Jego struktury wewnętrzne są aktualizowane przez silnik zgodnie z regułami właściwymi dla danego rodzaju indeksu oraz wersji SQL Server.

Ograniczenia i koszty aktualizowalnego indeksu

Aktualizowalny indeks kolumnowy jest szczególnie przydatny przy dużych tabelach analitycznych, ale nie usuwa kosztu modyfikowania danych. Wstawianie, usuwanie i aktualizowanie rekordów wymaga utrzymywania zarówno danych, jak i metadanych indeksu. W przypadku aktualizacji kolumn znajdujących się w indeksie SQL Server musi zachować spójność między tabelą bazową, rowgroups, delta store i delete bitmap. Przy dużej liczbie małych operacji DML może to powodować fragmentację logiczną oraz wzrost udziału danych oczekujących na kompresję.

Znaczenie ma również rozmiar partii. Wiele pojedynczych poleceń INSERT może wypełnić delta store niewielkimi porcjami, podczas gdy większe, odpowiednio przygotowane partie ułatwiają tworzenie pełnych rowgroups i efektywną kompresję. Nie oznacza to, że każdą operację należy mechanicznie zamieniać na jeden ogromny import, ponieważ trzeba uwzględnić blokady, dziennik transakcji, czas trwania transakcji oraz wymagania aplikacji. Sposób ładowania powinien odpowiadać charakterowi tabeli i częstotliwości późniejszych zmian.

Do oceny stanu indeksu można wykorzystać widoki katalogowe SQL Server, w szczególności sys.column_store_row_groups oraz sys.dm_db_column_store_row_group_physical_stats. Pozwalają one sprawdzić między innymi stan rowgroups, liczbę wierszy, udział danych w delta store oraz liczbę wierszy oznaczonych jako usunięte. Na tej podstawie można rozważyć operacje utrzymaniowe, takie jak reorganizacja lub przebudowa indeksu, ale ich użycie powinno wynikać z rzeczywistego stanu struktur, a nie z samego faktu, że tabela jest często modyfikowana.

Diagnostyka problemów z wydajnością columnstore

Analiza problemu z Updatable Columnstore Index powinna rozpocząć się od ustalenia, czy spowolnienie dotyczy odczytu, zapisu, kompresji, blokowania czy wzrostu dziennika transakcji. Sam komunikat o aktualizowalności indeksu nie wskazuje jeszcze przyczyny. Należy porównać czas wykonywania operacji DML, plany zapytań, wielkość tabeli, liczbę rowgroups oraz proporcję wierszy pozostających w delta store. Warto również sprawdzić, czy zapytania filtrują kolumny objęte predykatami i czy optymalizator rzeczywiście korzysta z indeksu kolumnowego.

W przypadku nieoczekiwanie wolnych aktualizacji trzeba zweryfikować zakres transakcji, poziom równoległości, blokady i oczekiwania. Długie transakcje mogą utrudniać zwalnianie zasobów, a duże serie aktualizacji mogą pozostawiać wiele logicznie usuniętych wierszy. Przydatne są dane z mechanizmów monitorowania SQL Server, informacje o planie wykonania oraz statystyki fizyczne rowgroups. Diagnostyka powinna rozróżniać sytuację, w której indeks jest prawidłowo aktualizowany, od sytuacji, w której jego struktura jest poprawna, ale sposób zasilania tabeli nie pasuje do charakteru columnstore.

Przy planowaniu naprawy należy zachować ostrożność wobec poleceń przebudowujących indeks. Rebuild może poprawić kompresję i uporządkować dane, lecz wymaga zasobów procesora, pamięci, miejsca roboczego oraz odpowiedniego okna operacyjnego. Reorganize ma inny zakres działania i nie jest zamiennikiem pełnej przebudowy w każdej sytuacji. W środowisku SQL Server decyzję powinno się opierać na pomiarach: liczbie usuniętych wierszy, stanie rowgroups, obciążeniu zapisu i faktycznych planach zapytań, a nie wyłącznie na rozmiarze tabeli.