Wydajność temporal tables

Wydajność tabel temporalnych obniża się wraz ze wzrostem tabeli historii, wymagając jej okresowego czyszczenia.

Jak tabela historii wpływa na czas wykonywania zapytań

Tabele temporalne przechowują bieżący wiersz oraz jego wcześniejsze wersje, a system zarządzania bazą zapisuje zakres obowiązywania każdej wersji w kolumnach okresu. W implementacji system-versioned temporal tables w Microsoft SQL Server tabela historii jest zwykłą tabelą z dodatkowymi wymaganiami dotyczącymi struktury i obsługi wersji. Przy aktualizacji lub usunięciu wiersza poprzednia wersja trafia do historii, natomiast w tabeli bieżącej pozostaje stan aktualny. Oznacza to, że liczba zapisów rośnie nie tylko wraz z liczbą rekordów, ale także wraz z częstotliwością zmian.

Sam wzrost tabeli historii nie musi spowalniać każdego zapytania. Zapytanie odczytujące wyłącznie tabelę bieżącą może działać podobnie jak przed włączeniem wersjonowania, ponieważ nie musi analizować dawnych wersji. Koszt pojawia się przede wszystkim przy zapytaniach korzystających z klauzul temporalnych, takich jak odczyt stanu z określonego momentu, wszystkich wersji rekordu albo danych obowiązujących w przedziale czasu. W takich przypadkach SQL Server może odczytywać zarówno tabelę bieżącą, jak i historię, a następnie łączyć wyniki zgodnie z okresem obowiązywania wierszy.

Indeksy okresu i selektywność zapytań temporalnych

Najważniejszym elementem dostrajania tabeli historii jest indeks odpowiadający rzeczywistym warunkom wyszukiwania. Zapytania temporalne zwykle filtrują po kolumnach okresu, na przykład po czasie rozpoczęcia i zakończenia obowiązywania wersji, ale często zawierają również identyfikator biznesowy rekordu. Indeks obejmujący wyłącznie kolumny okresu może nie być wystarczający, gdy system wyszukuje historię jednego klienta, dokumentu albo urządzenia. Wtedy przydatny jest indeks, w którym identyfikator rekordu oraz kolumny okresu są ułożone zgodnie z typowym predykatem zapytania.

Znaczenie ma także selektywność filtra. Zapytanie ograniczone do jednego identyfikatora i krótkiego przedziału czasu może odczytać niewielką część historii, nawet gdy tabela zawiera wiele wersji. Zapytanie bez filtra po identyfikatorze lub czasie może natomiast wymagać skanowania dużej części tabeli. Przy analizie planu wykonania należy sprawdzić, czy SQL Server korzysta z wyszukiwania indeksowego, czy wykonuje skan, ile wierszy szacuje optymalizator oraz ile wierszy rzeczywiście odczytuje. Duża różnica między estymacją a rzeczywistą liczbą rekordów może wskazywać na nieaktualne statystyki, niewłaściwy indeks albo niejednoznaczny warunek filtrowania.

Rozmiar historii, retencja i koszty utrzymania

Okres przechowywania wersji powinien wynikać z rzeczywistego celu audytowego lub analitycznego. Jeżeli historia nie jest ograniczana, każda kolejna zmiana powiększa tabelę, indeksy i statystyki. W SQL Server można skonfigurować retencję historii dla tabel temporalnych, ale sposób jej egzekwowania zależy od konfiguracji i wersji środowiska. Przed usuwaniem danych trzeba ustalić, czy starsze wersje są jeszcze potrzebne do raportów, odtworzenia stanu z przeszłości albo kontroli zmian.

Usuwanie dużych partii danych jednorazową operacją może powodować długie blokady, wzrost dziennika transakcji oraz zwiększone obciążenie wejścia-wyjścia. Bezpieczniejsze utrzymanie polega na kontrolowanym usuwaniu małych partii albo zastosowaniu partycjonowania tabeli historii, gdy rozmiar i charakter obciążenia uzasadniają takie rozwiązanie. Partycjonowanie według czasu może ograniczyć zakres odczytu dla zapytań z filtrem okresu i ułatwić wycofywanie najstarszych partycji, ale nie zastępuje indeksów ani poprawnie napisanych zapytań. Po większych zmianach rozmiaru historii należy odświeżyć statystyki i ponownie ocenić plany wykonania.

Diagnostyka spadku wydajności temporal tables

Ocena wydajności powinna obejmować czas odpowiedzi, liczbę odczytów logicznych, zużycie procesora, oczekiwania na operacje wejścia-wyjścia oraz blokady. Warto porównać plan i metryki dla zapytania dotyczącego wyłącznie stanu bieżącego z zapytaniem obejmującym historię. Taki test pozwala rozdzielić koszt wynikający z samego wersjonowania od kosztu wynikającego z dużej tabeli historii, braku indeksu lub nieefektywnego warunku czasowego. Należy również obserwować operacje modyfikujące dane, ponieważ każda aktualizacja lub operacja usunięcia generuje dodatkowy zapis wersji w tabeli historii.

Problemu nie rozwiązuje automatycznie samo skrócenie historii. Najpierw trzeba ustalić, czy opóźnienie wynika z nadmiernego rozmiaru tabeli, fragmentacji indeksów, nieaktualnych statystyk, blokowania, niewystarczającej pamięci czy zapytania zwracającego zbyt szeroki zakres wersji. Pomocne jest wykonanie testu na reprezentatywnym wolumenie danych oraz sprawdzenie planu po zmianie indeksu lub retencji. W przypadku środowiska produkcyjnego czynności utrzymaniowe powinny być planowane z uwzględnieniem obciążenia bazy, wielkości dziennika transakcji i wymagań dotyczących zachowania danych historycznych.