Indeksy kolumnowe a OLTP

Indeksy kolumnowe a OLTP opisują ograniczenia i zastosowania tego typu indeksów w środowiskach zorientowanych na transakcje.

Indeks kolumnowy i model przechowywania danych

Indeks kolumnowy przechowuje wartości z poszczególnych kolumn w grupach danych, zamiast organizować rekordy przede wszystkim według całych wierszy. Taki układ dobrze odpowiada zapytaniom analitycznym, które odczytują kilka kolumn z dużej tabeli, filtrują dane i wykonują agregacje, takie jak suma, średnia, minimum, maksimum lub zliczanie. Silnik może pobrać tylko potrzebne kolumny, ograniczając ilość danych odczytywanych z pamięci masowej oraz przesyłanych do dalszych etapów wykonania zapytania.

W klasycznym indeksie wierszowym, nazywanym rowstore, dane są zorganizowane tak, aby szybko odnajdywać konkretne rekordy lub niewielkie zakresy rekordów. Jest to korzystne dla operacji typowych dla OLTP, czyli przetwarzania transakcji online: wyszukania pojedynczego klienta, odczytu jednego zamówienia, zmiany statusu płatności albo dodania nowego wiersza. Indeks kolumnowy wykorzystuje natomiast podobieństwo wartości w obrębie kolumn i kompresję danych, dlatego jego przewaga ujawnia się przede wszystkim przy skanowaniu dużych zbiorów i obliczeniach wykonywanych na wielu rekordach.

Dlaczego OLTP stawia inne wymagania

System OLTP obsługuje wiele krótkich, często równoczesnych transakcji. Każda z nich zwykle zmienia niewielką liczbę wierszy, a użytkownik oczekuje szybkiego potwierdzenia operacji. Przy takim obciążeniu istotne są selektywne wyszukiwanie rekordów, ograniczanie blokad, sprawne utrzymanie indeksów oraz przewidywalny czas zapisu. Indeks kolumnowy nie jest z natury zoptymalizowany wyłącznie pod ten scenariusz, ponieważ zmiana pojedynczego wiersza może wymagać obsługi danych należących do struktur kolumnowych i dodatkowych etapów utrzymania.

Wstawianie, aktualizowanie i usuwanie danych może zwiększać koszt transakcji, zwłaszcza gdy tabela jest intensywnie modyfikowana, a indeks kolumnowy obejmuje wiele kolumn. Zapis musi zachować spójność indeksu z tabelą, a jednocześnie współdziałać z mechanizmami blokowania, logowania transakcji i współbieżności. Częste modyfikacje mogą również prowadzić do powstawania obszarów przejściowych, w których nowe lub zmienione wiersze nie są jeszcze ułożone tak efektywnie jak stabilna część indeksu kolumnowego. Z tego powodu sam fakt, że tabela jest duża, nie wystarcza do uznania indeksu kolumnowego za właściwy.

Dobór indeksu do zapytań i obciążenia

Przy ocenie przydatności indeksu kolumnowego należy przeanalizować rzeczywiste zapytania, a nie tylko schemat tabeli. Korzystnym sygnałem są raporty odczytujące znaczną część tabeli, grupujące dane według kilku wymiarów albo obliczające wartości na dużym przedziale czasu. Jeżeli zapytanie wybiera pojedynczy rekord na podstawie klucza i natychmiast go aktualizuje, indeks wierszowy zwykle lepiej odpowiada jego sposobowi pracy. W praktyce jedna tabela może mieć różne struktury dostosowane do odmiennych typów zapytań, ale każda dodatkowa struktura zwiększa koszt zapisów i zajmuje miejsce.

W środowisku mieszanym często stosuje się podejście hybrydowe: operacje transakcyjne korzystają z indeksów wierszowych, natomiast odczyty raportowe mogą korzystać z indeksu kolumnowego. Taki układ wymaga sprawdzenia planów wykonania i pomiaru obciążenia podczas normalnej pracy. Należy obserwować czas odpowiedzi, zużycie procesora, odczyty z dysku, wykorzystanie pamięci, liczbę modyfikacji oraz wpływ utrzymania indeksów na zatwierdzanie transakcji. Optymalizator zapytań może wybrać indeks kolumnowy tylko wtedy, gdy przewidywany koszt jego użycia jest niższy od kosztu alternatywnego planu.

Utrzymanie spójności i diagnostyka wydajności

Problemy z indeksem kolumnowym nie zawsze wynikają z jego błędnej definicji. Przyczyną może być nieodpowiedni rozkład zapytań, zbyt częste modyfikacje tabeli, niewłaściwe statystyki, presja na pamięć albo zapytanie napisane w sposób utrudniający ograniczenie zakresu danych. Diagnostyka powinna obejmować plan wykonania, faktycznie odczytane dane, sposób filtrowania i agregacji oraz porównanie z planem wykorzystującym indeks wierszowy. Samo skrócenie czasu pojedynczego raportu nie oznacza poprawy całego systemu, jeżeli równocześnie wzrasta opóźnienie transakcji.

Przed wdrożeniem indeksu kolumnowego warto wykonać test na reprezentatywnym zbiorze danych i przy obciążeniu zbliżonym do produkcyjnego. Test powinien uwzględniać zarówno odczyty analityczne, jak i równoległe wstawianie, aktualizowanie oraz usuwanie rekordów. Po wdrożeniu trzeba kontrolować rozmiar struktur, skuteczność kompresji, aktualność statystyk i wpływ operacji konserwacyjnych na czas pracy bazy. Jeżeli profil obciążenia zmienia się z raportowego na silnie transakcyjny, wcześniejsza decyzja może wymagać ponownej oceny. Indeks kolumnowy jest narzędziem do konkretnego wzorca dostępu do danych, a nie uniwersalnym zamiennikiem indeksów wierszowych.