Columnstore a replikacja

Columnstore a replikacja to zależność między kolumnowym formatem indeksu a procesem synchronizacji danych między serwerami.

Jak columnstore wpływa na replikację danych

Columnstore to kolumnowy sposób organizacji danych w indeksie bazy SQL Server. W odróżnieniu od klasycznego indeksu wierszowego, który przechowuje wartości należące do jednego rekordu obok siebie, indeks columnstore grupuje dane według kolumn. Wartości są dzielone na segmenty, kompresowane i odczytywane selektywnie. Taki układ jest korzystny przede wszystkim dla zapytań analitycznych, które skanują wiele rekordów, ale wykorzystują tylko część dostępnych kolumn.

Replikacja nie kopiuje jednak fizycznego formatu segmentów columnstore jako osobnego strumienia danych. Mechanizm replikacji synchronizuje zmiany w tabelach, na przykład operacje INSERT, UPDATE i DELETE, zgodnie z typem użytej replikacji. Po zastosowaniu zmiany w bazie docelowej dane mogą zostać zapisane w indeksie columnstore odbiorcy, jeżeli taki indeks istnieje i jego definicja została objęta konfiguracją schematu artykułu. Oznacza to, że replikowane są przede wszystkim dane i operacje na danych, a nie wewnętrzny układ stron oraz segmentów indeksu źródłowego.

Replikacja transakcyjna a indeksy kolumnowe

W replikacji transakcyjnej SQL Server zmiany są odczytywane z dziennika transakcji przez Log Reader Agent, a następnie przekazywane do dystrybucji i stosowane u subskrybenta przez Distribution Agent. Dla tabeli wykorzystującej columnstore oznacza to konieczność obsługi zmian na poziomie tabeli. Replikacja nie może założyć, że odbiorca ma identyczny stan segmentów, identyczny stopień kompresji ani taki sam rozkład danych jak wydawca.

Podczas konfigurowania artykułu istotne jest ustalenie, które elementy schematu mają zostać utworzone u subskrybenta. Definicja tabeli, klucze, ograniczenia i indeksy mogą być traktowane niezależnie, zależnie od ustawień artykułu oraz sposobu przygotowania subskrypcji. Jeżeli indeks columnstore zostanie utworzony także w bazie docelowej, operacje replikowane będą modyfikowały tabelę posiadającą kolumnową strukturę indeksową. Jeżeli indeks nie zostanie utworzony, dane nadal mogą być synchronizowane, lecz zapytania analityczne u subskrybenta będą korzystały z innego układu indeksów albo z pełnego skanowania tabeli.

Zmiany wierszowe, segmenty i opóźnienie synchronizacji

Indeks columnstore najlepiej wykorzystuje dane zapisane w dużych, zamkniętych grupach wierszy. W SQL Server podstawową jednostką organizacji takiego indeksu jest rowgroup, czyli grupa wierszy przechowywana w formacie kolumnowym. Nowe lub zmieniane rekordy mogą przez pewien czas trafiać do deltastore, który wykorzystuje strukturę wierszową. Gdy grupa osiągnie odpowiedni stan, proces Tuple Mover może przenieść ją do właściwego formatu columnstore. Z tego powodu częste małe modyfikacje nie muszą natychmiast powodować powstania optymalnie skompresowanych segmentów.

Przy replikacji trzeba rozdzielić dwa rodzaje opóźnienia. Pierwsze powstaje w samym łańcuchu replikacji: zmiana musi zostać zapisana w dzienniku, odczytana przez agenta, przekazana do dystrybucji i zastosowana u subskrybenta. Drugie wynika z organizacji indeksu columnstore po stronie odbiorcy. Nawet gdy transakcja została już zastosowana, segmenty mogą mieć inny stopień kompresji, inną liczbę usuniętych wierszy i inny układ metadanych niż na serwerze źródłowym. Nie jest to samo w sobie oznaką utraty danych, ale może wpływać na wydajność zapytań.

Szczególną uwagę należy zwrócić na aktualizacje i usuwanie rekordów. W kolumnowym indeksie usunięcie wiersza może zostać oznaczone w metadanych zamiast natychmiastowego fizycznego usunięcia ze wszystkich segmentów. Duża liczba takich zmian zwiększa udział nieaktywnych wierszy i może pogarszać efektywność skanowania. Replikowany odbiorca może więc wymagać odrębnego monitorowania fragmentacji, kompresji i liczby wierszy oczekujących w deltastore, nawet jeśli logiczna zawartość tabeli jest zgodna z wydawcą.

Kontrola zgodności i diagnostyka konfiguracji

Analiza problemu powinna rozpocząć się od ustalenia rodzaju replikacji, roli bazy oraz sposobu utworzenia artykułu. Następnie należy porównać definicję tabeli, kolumny klucza głównego, ograniczenia i indeksy po obu stronach. Sam fakt, że tabela ma indeks columnstore na serwerze źródłowym, nie potwierdza jeszcze, że identyczny indeks istnieje u subskrybenta. Warto sprawdzić metadane indeksów, ich typ, kolumny kluczowe oraz stan poszczególnych rowgroupów.

W diagnostyce pomocne są widoki katalogowe SQL Server, między innymi sys.indexes, sys.index_columns, sys.column_store_row_groups i sys.dm_db_column_store_row_group_physical_stats. Pozwalają one sprawdzić, czy indeks jest klastrowany lub nieklastrowany, ile ma segmentów, jaki jest stan rowgroupów oraz czy występują grupy otwarte, zamknięte, skompresowane albo oznaczone jako usunięte. Zgodność liczby wierszy nie wystarcza do oceny wydajności, ponieważ dwa serwery mogą przechowywać tę samą zawartość logiczną w różnie zoptymalizowany sposób.

W przypadku rozbieżności należy dodatkowo sprawdzić historię agenta dystrybucji, błędy wykonywania poleceń oraz kolejkę nieprzetworzonych transakcji. Przyczyną może być niezgodna definicja schematu, brakujący indeks, konflikt klucza, ograniczenie dotyczące operacji DML albo przeciążenie subskrybenta podczas masowego ładowania. Oddzielnie należy ocenić plan zapytań i statystyki, ponieważ spadek szybkości raportów po synchronizacji nie musi oznaczać błędu replikacji. W środowisku z laptopem lub komputerem PC analiza takich objawów zwykle zaczyna się od zebrania komunikatów SQL Server, informacji o konfiguracji oraz przykładów konkretnych zapytań.