UPDATE w indeksach kolumnowych

UPDATE w indeksach kolumnowych jest kosztowniejszy niż w klasycznych, ze względu na mechanizm kompresji danych.

Dlaczego UPDATE w indeksie kolumnowym ma wyższy koszt

Indeks kolumnowy przechowuje dane według kolumn, a nie według całych wierszy. Wartości jednej kolumny są grupowane razem, dzięki czemu powtarzalne dane można skutecznie kompresować, a zapytania odczytujące niewielką liczbę kolumn nie muszą pobierać pełnych rekordów. Taki układ jest korzystny przede wszystkim dla skanowania dużych zbiorów danych, agregacji oraz analiz obejmujących wiele wierszy. Operacja UPDATE zmienia jednak wartość istniejącą już w strukturze, która została podzielona na segmenty i poddana kompresji.

Zmiana pojedynczej wartości może wymagać obsługi nie tylko konkretnego rekordu, lecz także struktur opisujących segment, położenie danych, stan kompresji i możliwość dalszego odczytu. Jeżeli zmieniana kolumna należy do skompresowanego fragmentu, bezpośrednia modyfikacja bajtów nie zawsze jest możliwa, ponieważ nowa wartość może mieć inny rozmiar, zmienić słownik kompresji albo przestać pasować do dotychczasowego sposobu kodowania. Z tego powodu silnik bazy danych może oznaczyć stary wpis jako nieważny, zapisać nową wersję w obszarze przeznaczonym dla zmian i później wykonać scalanie lub ponowną kompresję danych.

Segmenty, kompresja i obszar zmian

W indeksach kolumnowych rekordy są zwykle organizowane w grupy nazywane segmentami. Segment zawiera wartości wybranej kolumny dla określonego zakresu wierszy, a dodatkowe metadane mogą opisywać między innymi wartości minimalne i maksymalne. Te informacje pozwalają pominąć segment, który nie może zawierać wyniku dla danego predykatu. Aktualizacja wartości może zmienić zarówno samą zawartość segmentu, jak i przydatność jego metadanych. Jeżeli nowa wartość wykracza poza wcześniejszy zakres, wcześniejsze założenia dotyczące eliminacji segmentów mogą wymagać ponownego wyliczenia.

W praktycznych implementacjach aktualizowane rekordy często trafiają do nieskompresowanej struktury pomocniczej, określanej jako obszar delt lub delta store. Rozwiązanie to pozwala szybciej przyjąć zmianę bez natychmiastowego przebudowywania dużego segmentu kolumnowego. Stary zapis może nadal zajmować miejsce w skompresowanym segmencie, lecz jest pomijany podczas logicznego odczytu, a aktualna wersja znajduje się w strukturze zmian. Gdy takich rekordów przybywa, system wykonuje operacje porządkowania, zamykania obszaru delt i kompresowania danych. Koszt aktualizacji obejmuje więc często także późniejsze prace konserwacyjne, a nie tylko chwilę wykonania instrukcji.

Wpływ wielu zmian na odczyt i utrzymanie indeksu

Pojedynczy UPDATE nie musi powodować zauważalnego problemu, szczególnie gdy zmiana dotyczy niewielkiej liczby wierszy i system może ją obsłużyć w strukturze przejściowej. Inaczej wygląda masowa aktualizacja, która modyfikuje dużą część tabeli. Wtedy rośnie liczba nieaktualnych wpisów, zwiększa się rozmiar obszaru zmian, a odczyt może wymagać połączenia danych ze skompresowanych segmentów z najnowszymi wersjami przechowywanymi poza nimi. W rezultacie zapytanie analityczne może wykonywać więcej pracy niż po pełnym uporządkowaniu indeksu.

Znaczenie ma również charakter zmienianej kolumny. Aktualizacja kolumny używanej w filtrach może zmienić zakresy wartości zapisane w metadanych segmentów i ograniczyć skuteczność pomijania niepasujących fragmentów. Zmiana kolumny o dużej liczbie różnych wartości może także gorzej współpracować z kompresją niż zmiana danych powtarzalnych. Przy częstych modyfikacjach trzeba zatem obserwować nie tylko czas samej instrukcji, lecz także rozmiar indeksu, liczbę wierszy oczekujących na uporządkowanie, udział danych nieskompresowanych oraz czas późniejszych zapytań.

Rozpoznawanie problemu podczas analizy działania bazy

Diagnoza spowolnień związanych z UPDATE powinna rozpocząć się od ustalenia, czy problem występuje podczas zapisu, czy dopiero podczas późniejszego odczytu. Należy porównać czas aktualizacji dla małej i dużej partii rekordów, sprawdzić plan wykonania oraz ustalić, czy modyfikowane wiersze są skupione w ograniczonym zakresie, czy rozproszone po wielu segmentach. Warto także rozdzielić koszt blokad, logowania transakcji, operacji wejścia-wyjścia i pracy związanej z kompresją. Sam fakt, że indeks kolumnowy powiększa czas aktualizacji, nie wskazuje jeszcze jednej przyczyny.

Przy naprawie problemu analizuje się między innymi rozmiar partii aktualizowanych rekordów, częstotliwość modyfikacji, kolejność ładowania danych i moment wykonywania operacji porządkowania. W przypadku danych, które są intensywnie zmieniane, korzystniejsze może być utrzymywanie ich początkowo w strukturze przeznaczonej do częstych zapisów, a dopiero później przenoszenie do formatu kolumnowego. Decyzja zależy od konkretnego silnika, wersji jego mechanizmu indeksów, rozkładu danych i rodzaju zapytań. Diagnostyka laptopa lub komputera PC może potwierdzić problemy z lokalnym środowiskiem narzędzi administracyjnych, lecz właściwa ocena kosztu operacji wymaga dostępu do planów wykonania i metryk samego systemu bazodanowego.