Delta store

Delta store to obszar tymczasowo przechowujący nowe lub zmodyfikowane wiersze przed ich włączeniem do skompresowanej struktury Columnstore.

Delta store – czym jest ten obszar w Columnstore

Delta store to część struktury danych Columnstore przeznaczona do przyjmowania wierszy, które pojawiają się po utworzeniu albo skompresowaniu głównego obszaru kolumnowego. Trafiają tam przede wszystkim nowe rekordy oraz zmiany, których nie opłaca się natychmiast dopisywać do już skompresowanych grup wierszy. Dzięki temu system może obsługiwać zapis bez każdorazowego przebudowywania dużych fragmentów danych. W praktyce delta store pełni funkcję bufora pomiędzy operacjami modyfikującymi a analitycznym sposobem przechowywania informacji.

W klasycznym indeksie kolumnowym dane są układane według kolumn, a nie według całych rekordów. Takie rozmieszczenie sprzyja odczytom obejmującym wiele wierszy, lecz pojedyncza zmiana może wymagać dodatkowej obsługi. Delta store rozwiązuje ten problem, ponieważ pozwala zapisać zmieniony lub nowy wiersz w formie bardziej przyjaznej dla operacji transakcyjnych. Dane pozostają dostępne dla zapytań, a ich późniejsze uporządkowanie może zostać wykonane w ramach procesu konserwacyjnego.

Nie należy utożsamiać delta store ze zwykłą kopią tabeli ani z trwałym archiwum. Jest to element większego mechanizmu zarządzania indeksem. Zawartość może zmieniać się wraz z napływem danych, łączeniem grup wierszy i czyszczeniem rekordów oznaczonych jako usunięte. Znaczenie tego obszaru zależy od konkretnej implementacji Columnstore, wersji silnika oraz sposobu wykonywania operacji zapisu.

Delta store a skompresowane grupy wierszy i zapis danych

Najważniejsza różnica między delta store a skompresowaną częścią indeksu dotyczy sposobu przygotowania danych. Grupy wierszy w Columnstore są projektowane z myślą o szybkim filtrowaniu, agregowaniu i odczycie wybranych kolumn. Wymagają jednak odpowiedniego uporządkowania oraz kompresji. Nowe rekordy nie zawsze spełniają od razu warunki pozwalające na efektywne utworzenie takiej grupy. Zapisanie ich w delta store umożliwia przyjęcie danych bez zbędnego opóźnienia.

W czasie odczytu silnik może uwzględniać zarówno grupy skompresowane, jak i aktywną zawartość delta store. Dla użytkownika końcowego tabela powinna zachowywać spójny obraz, mimo że fizycznie dane znajdują się w różnych częściach indeksu. Kosztem takiego rozwiązania jest dodatkowa praca wykonywana podczas planowania oraz realizacji zapytań. Im większa i bardziej rozproszona zawartość delta store, tym większe znaczenie ma późniejsze porządkowanie struktury.

Warto również odróżnić delta store od mechanizmów dziennika transakcyjnego, pamięci podręcznej i tabeli tymczasowej. Dziennik służy do odtwarzania oraz zabezpieczenia operacji, pamięć podręczna przyspiesza ponowne użycie danych, a tabela tymczasowa jest zwykle tworzona na potrzeby konkretnego zapytania lub procesu. Delta store jest natomiast częścią organizacji indeksu kolumnowego i uczestniczy w przejściu od zapisu wierszowego do postaci zoptymalizowanej pod kątem analizy.

Można porównać ten mechanizm do punktu przyjęcia nowych dokumentów przed ich uporządkowaniem w katalogu. Dokument nie jest pomijany tylko dlatego, że katalog został już zamknięty i skompresowany. Zostaje zapisany w wydzielonym miejscu, a następnie przeniesiony do uporządkowanej części wtedy, gdy warunki operacyjne są odpowiednie.

Delta store – typowe problemy z wydajnością i spójnością

Jednym z częstszych problemów jest narastanie liczby rekordów w delta store. Może do tego dochodzić przy intensywnym ładowaniu danych, częstych aktualizacjach pojedynczych wierszy albo usuwaniu małych partii rekordów. Sama obecność delta store nie oznacza usterki, ponieważ jest to przewidziany element działania Columnstore. Niepokój powinno budzić dopiero połączenie dużej zawartości tego obszaru z pogorszeniem czasu zapytań, zwiększonym obciążeniem procesora lub wydłużonymi operacjami konserwacyjnymi.

Trudność diagnostyczna polega na tym, że wolniejsze zapytanie nie musi wynikać wyłącznie z delta store. Podobny efekt może powodować niekorzystny plan wykonania, niewłaściwe predykaty, mała selektywność filtrów, blokady, ograniczenia pamięci albo nierównomierny rozkład danych. Dlatego nie wystarcza samo sprawdzenie, czy delta store istnieje. Potrzebne jest zestawienie jego rozmiaru i aktywności z czasem zapytań, rodzajem operacji oraz zmianami w obciążeniu.

Osobnej uwagi wymagają aktualizacje i usunięcia. W strukturach kolumnowych zmiana istniejącego wiersza może być obsługiwana inaczej niż dopisanie nowego. Część danych może zostać oznaczona jako nieaktualna, a nowa wersja może trafić do obszaru przejściowego. Przy dużej liczbie takich operacji rośnie znaczenie procesów scalania, czyszczenia i ponownej kompresji. Niewłaściwe ustawienia lub przerwane zadania konserwacyjne mogą utrzymywać strukturę w stanie przejściowym dłużej, niż zakłada projekt.

Nie powinno się usuwać ani modyfikować wewnętrznych elementów delta store ręcznie. Są one zarządzane przez silnik bazy danych, a bezpośrednia ingerencja mogłaby naruszyć spójność indeksu. Bezpieczniejsze jest rozpoznanie przyczyny, sprawdzenie dostępnych operacji konserwacyjnych oraz wykonanie ich zgodnie z dokumentacją używanego systemu.

Delta store – praktyczne wskazówki do analizy

Analizę warto rozpocząć od ustalenia, czy problem dotyczy odczytu, zapisu, czy obu rodzajów operacji. Jeżeli opóźnienie pojawia się podczas ładowania danych, należy sprawdzić wielkość partii, częstotliwość zatwierdzania transakcji i sposób wykonywania aktualizacji. Jeżeli wolniejsze są zapytania analityczne, przydatne będzie porównanie planów wykonania oraz sprawdzenie, czy silnik odczytuje wiele małych obszarów zamiast ograniczonego zestawu dobrze skompresowanych grup.

Pomocne jest prowadzenie obserwacji w czasie, a nie wykonywanie pojedynczego pomiaru. Warto rejestrować rozmiar tabeli, liczbę zmian, czas ładowania, czas najważniejszych zapytań i momenty uruchamiania zadań porządkowych. Taki dziennik pozwala rozróżnić stałą cechę obciążenia od jednorazowego skoku. Można również porównać tabele o podobnym charakterze, ale innym sposobie zasilania, aby sprawdzić, czy problem wynika z modelu danych.

Znaczenie ma także kolejność operacji. Duża liczba małych aktualizacji może zachowywać się inaczej niż pojedyncze ładowanie większego zestawu nowych rekordów. W środowisku testowym można sprawdzić, czy ograniczenie liczby drobnych transakcji, lepsze grupowanie zmian lub zaplanowanie konserwacji poza szczytem zmienia obciążenie. Każda modyfikacja powinna być oceniana na podstawie pomiaru przed i po jej wprowadzeniu.

Przy interpretacji wyników należy pamiętać, że delta store nie jest samodzielnym parametrem jakości. Jest częścią kompromisu pomiędzy szybkim przyjmowaniem zmian a późniejszą optymalizacją odczytu. Dobrze zaprojektowany proces uwzględnia oba etapy: sprawne zapisanie danych oraz kontrolowane scalanie ich z częścią skompresowaną.

Delta store – kiedy zgłosić problem do serwisu komputerowego

Jeżeli wraz ze wzrostem aktywności delta store pojawiają się długie przerwy w działaniu aplikacji, błędy odczytu, przeciążenie komputera lub powtarzające się nieudane zadania konserwacyjne, warto przygotować opis objawów i zgłosić urządzenie do sprawdzenia. Dotyczy to zwłaszcza sytuacji, w której problem występuje po aktualizacji oprogramowania, zmianie konfiguracji pamięci masowej albo nagłym wzroście liczby operacji zapisu.

Warszawskie Pogotowie Komputerowe 24/7 wykonuje naprawy z reguły do trzech dni roboczych.

Przed przekazaniem sprzętu dobrze zabezpieczyć kopię ważnych danych, zanotować moment występowania problemu oraz zachować komunikaty błędów. Przydatne będą także informacje o ostatnich zmianach, rodzaju używanej bazy danych i działaniach wykonanych tuż przed pojawieniem się spowolnienia. Tak przygotowane zgłoszenie ułatwia oddzielenie problemu z samą strukturą Columnstore od kłopotów z systemem operacyjnym, pamięcią masową, chłodzeniem lub innym elementem komputera.

W przypadku niejasnych objawów nie zaleca się samodzielnego usuwania plików indeksu, przerywania procesów konserwacyjnych ani przywracania przypadkowych kopii konfiguracji. Najpierw należy ustalić, czy dane są kompletne i czy istnieje możliwość bezpiecznego odtworzenia środowiska. Dopiero na tej podstawie można dobrać dalsze czynności, takie jak kontrola nośnika, analiza logów, sprawdzenie obciążenia lub uporządkowanie sposobu zapisu danych.