Columnstore a Always On

Columnstore a Always On to zależność między kolumnowym formatem indeksu a mechanizmem wysokiej dostępności bazy danych.

Dwa różne mechanizmy w SQL Server

Columnstore i Always On odpowiadają za inne właściwości bazy danych SQL Server. Indeks columnstore zmienia sposób przechowywania oraz odczytywania danych. Zamiast organizować wartości przede wszystkim według wierszy, grupuje je według kolumn. Pozwala to odczytać tylko te kolumny, które są potrzebne zapytaniu, a następnie przetwarzać większe zbiory danych w sposób dostosowany do analiz i raportowania. W SQL Server występują między innymi klastrowane indeksy columnstore (clustered columnstore index, CCI) oraz nieklastrowane indeksy columnstore (nonclustered columnstore index, NCCI).

Always On Availability Groups to mechanizm wysokiej dostępności i odzyskiwania po awarii dla wskazanych baz SQL Server. Baza działająca na replice podstawowej jest synchronizowana z bazami na replikach pomocniczych za pomocą rekordów dziennika transakcji. W zależności od konfiguracji replika może działać synchronicznie albo asynchronicznie, a wybrane repliki pomocnicze mogą przyjmować połączenia tylko do odczytu. Sam indeks columnstore nie zastępuje Always On, a Always On nie zmienia przeznaczenia indeksu. Jedno rozwiązanie dotyczy wydajności i organizacji danych, drugie dostępności oraz przełączania bazy między replikami.

Jak indeks columnstore zachowuje się podczas replikacji

W grupie dostępności struktury bazy, w tym obsługiwane indeksy, są odtwarzane na replice pomocniczej na podstawie dziennika transakcji. Operacja utworzenia, przebudowania albo usunięcia indeksu wykonana na replice podstawowej jest więc elementem zmian, które muszą zostać zastosowane na pozostałych replikach. Nie oznacza to jednak, że każda replika ma identyczną chwilową gotowość do obsługi zapytań. Przy opóźnieniu transportu lub odtwarzania dziennika pomocnicza baza może nie zawierać jeszcze najnowszych zmian.

Klastrowany indeks columnstore przechowuje dane w grupach wierszy, zwanych rowgroups. Dane mogą najpierw trafiać do delta store, który jest strukturą rowstore, a następnie proces tuple mover przenosi odpowiednio przygotowane dane do skompresowanych grup columnstore. Ten cykl ma znaczenie podczas monitorowania repliki, ponieważ duże operacje ładowania, przebudowy indeksu i intensywne modyfikacje tabeli generują aktywność w dzienniku transakcji. Always On musi przesłać i odtworzyć te zmiany, dlatego wydajność indeksu na replice nie może być oceniana wyłącznie na podstawie czasu wykonania zapytania na replice podstawowej.

Replika pomocnicza, odczyt i ograniczenia wersji

Readable secondary umożliwia kierowanie zapytań tylko do odczytu na replikę pomocniczą. Połączenie kierowane przez listener grupy dostępności może używać intencji odczytu, a konfiguracja read-only routing wskazuje, gdzie takie połączenia powinny trafić. Jest to sposób na odciążenie repliki podstawowej zapytaniami analitycznymi, ale wynik na replice pomocniczej może zależeć od opóźnienia synchronizacji. Zapytanie nie powinno zakładać, że odczyt z pomocniczej repliki zawsze przedstawia dokładnie ten sam punkt czasu co odczyt z podstawowej.

Przy interpretacji dokumentacji trzeba uwzględnić wersję SQL Server. W SQL Server 2014 istniało ograniczenie, zgodnie z którym klastrowanego indeksu columnstore nie można było odczytywać z readable secondary w grupie Always On, natomiast nieklastrowany indeks columnstore był w tym scenariuszu dostępny. Dokumentacja opisuje to jako ograniczenie właściwe dla SQL Server 2014, dlatego nie należy przenosić tego faktu bez sprawdzenia na nowsze wersje silnika. W środowisku produkcyjnym trzeba potwierdzić wersję, edycję i aktualizację SQL Server, a następnie sprawdzić zachowanie konkretnego typu indeksu na replice pomocniczej.

Weryfikacja konfiguracji i diagnostyka zależności

Analizę rozpoczyna się od ustalenia, czy tabela ma CCI, NCCI, indeksy rowstore, czy kilka typów indeksów jednocześnie. Pomocne są widoki katalogowe oraz widoki dynamiczne SQL Server, w szczególności sys.indexes, sys.index_columns, sys.column_store_row_groups i sys.dm_hadr_database_replica_states. Pierwsze dwa pozwalają rozpoznać definicję indeksu, informacje o grupach wierszy pokazują stan struktur columnstore, a widok Always On dostarcza danych o roli repliki, synchronizacji i stanie bazy. Osobno należy sprawdzić, czy połączenie faktycznie trafiło na replikę pomocniczą, ponieważ sam listener nie gwarantuje poprawnego routingu bez odpowiedniej konfiguracji.

Typowe objawy problemu mogą obejmować brak oczekiwanego odciążenia repliki podstawowej, opóźnienie danych na replice pomocniczej, długie odtwarzanie dziennika albo odmowę wykonania zapytania wynikającą z ograniczenia konkretnej wersji. Nie należy automatycznie rozwiązywać takich objawów przez przebudowę indeksu. Najpierw trzeba porównać stan synchronizacji, obciążenie dysków, czas transportu i odtwarzania logu oraz plan zapytania. Po przełączeniu ról warto ponownie zweryfikować statystyki i plany, ponieważ statystyki tymczasowe utworzone na replice pomocniczej mogą zostać usunięte podczas failover. Diagnostyka powinna zatem obejmować jednocześnie definicję indeksu, wersję SQL Server, konfigurację Always On oraz rzeczywistą ścieżkę połączenia aplikacji.