Temporal tables vs CDC (Change Data Capture)

Tabele temporalne przechowują pełną historię w samej bazie, w odróżnieniu od CDC śledzącego jedynie zmiany do przetworzenia.

Dwa mechanizmy historii danych w SQL Server

W SQL Server tabele temporalne system-versioned oraz Change Data Capture (CDC) służą do rejestrowania zmian w danych, ale rozwiązują różne problemy. Tabela temporalna przechowuje bieżące wiersze w tabeli głównej oraz ich wcześniejsze wersje w powiązanej tabeli historii. Przy aktualizacji albo usunięciu rekordu poprzedni stan jest zapisywany automatycznie, a wiersz bieżący otrzymuje nowy przedział obowiązywania. Historia pozostaje częścią modelu danych i może być odczytywana bezpośrednio zapytaniami T-SQL.

CDC nie tworzy kolejnych wersji rekordu dostępnych jako klasyczna historia obowiązywania. Mechanizm odczytuje zmiany z dziennika transakcji SQL Server i zapisuje je w tabelach przechwyconych zmian. Rekord CDC opisuje między innymi operację, czas lub pozycję zmiany oraz wartości kolumn zgodnie z konfiguracją przechwytywania. Zmiany są przeznaczone przede wszystkim do asynchronicznego pobierania przez procesy integracyjne, raportowe albo ładujące dane do innego systemu. Wybór mechanizmu zależy więc od tego, czy potrzebna jest historia stanu encji, czy strumień zmian do dalszego przetwarzania.

Jak różni się odpowiedź na pytanie „co było wtedy”

Tabela temporalna jest wygodna, gdy trzeba ustalić, jaki stan miał konkretny rekord w określonym momencie. SQL Server przechowuje dla wierszy dwa znaczniki czasu definiujące okres ważności, zwykle reprezentowane przez kolumny typu datetime2. Zapytania temporalne, takie jak FOR SYSTEM_TIME AS OF, pozwalają odtworzyć widok tabeli z przeszłości. Można również analizować zakres czasu, pobierać wszystkie wersje rekordu albo porównywać stan bieżący z historycznym. Ta perspektywa odpowiada na pytania audytowe i diagnostyczne dotyczące wartości danych.

CDC odpowiada na inne pytanie: jakie operacje zmieniły tabelę i jakie wartości zostały objęte zmianą. Dla aktualizacji przechwycone dane mogą zawierać obraz przed zmianą i obraz po zmianie, zależnie od trybu skonfigurowanego dla instancji przechwytywania. Dla wstawienia dostępne są wartości nowego rekordu, a dla usunięcia wartości usuwanego rekordu. Kolejność zmian jest istotna dla konsumenta, ponieważ proces musi odczytywać kolejne zakresy zmian i zapisywać informację o ostatnio przetworzonej pozycji. CDC nie jest zatem bezpośrednim zamiennikiem zapytań temporalnych.

Retencja, odczyt i wpływ na przepływ danych

W przypadku tabel temporalnych historia jest dostępna tak długo, jak długo znajdują się w tabeli historii. Jej rozmiar rośnie wraz z liczbą zmian, dlatego trzeba zaplanować retencję, indeksowanie i ewentualne czyszczenie starych wersji. Dodatkowe zapisy mogą zwiększać obciążenie operacji modyfikujących dane, a zapytania obejmujące długie przedziały czasu mogą odczytywać dużą liczbę historycznych wierszy. Integralność relacji między tabelą bieżącą a tabelą historii ma znaczenie dla wiarygodności odtworzonego stanu.

CDC również wymaga kontroli retencji. Przechwycone zmiany są utrzymywane przez określony czas, a zadanie czyszczenia usuwa starsze dane zgodnie z konfiguracją. Jeżeli odbiorca nie pobiera zmian wystarczająco szybko, może utracić możliwość odczytania pełnego zakresu potrzebnego do synchronizacji. Przetwarzanie CDC wymaga więc zarządzania punktami początkowymi i końcowymi zakresu zmian, obsługi przerw oraz zapewnienia idempotencji po stronie odbiorcy. Samo istnienie tabel CDC nie gwarantuje, że zewnętrzny proces poprawnie zastosował każdą zmianę.

Dobór mechanizmu do konkretnego zastosowania

Temporal tables w SQL Server pasują do sytuacji, w której podstawowym wymaganiem jest odtwarzanie historycznych stanów danych, porównywanie wersji i sprawdzanie, kiedy obowiązywała określona wartość. CDC jest właściwsze, gdy zmiany mają być pobierane etapami przez proces ETL, replikowane do innego repozytorium albo przetwarzane przez kolejny komponent. W rozwiązaniu integracyjnym trzeba uwzględnić kolejność operacji, usunięcia, aktualizacje wielokolumnowe, opóźnienia oraz możliwość ponownego uruchomienia odbiorcy. W rozwiązaniu opartym na temporal tables trzeba z kolei sprawdzić kompletność tabeli historii, okresy obowiązywania i zasady przechowywania danych.

Oba mechanizmy mogą występować w jednym systemie, ponieważ ich cele nie są identyczne. Tabela temporalna może służyć do odtworzenia stanu biznesowego na wskazany czas, a CDC do przekazywania kolejnych zmian do procesu przetwarzania. Takie połączenie wymaga jednak świadomego modelowania, aby nie traktować tabeli historii jako kolejki zdarzeń ani tabel CDC jako pełnego, bezpośrednio przeszukiwalnego archiwum. Podczas diagnostyki problemu należy ustalić, który mechanizm jest źródłem prawdy, jaki zakres czasu lub zmian ma zostać odczytany oraz czy retencja nie usunęła wymaganych rekordów.