Kompresja danych

Kompresja danych to funkcja SQL Server redukująca miejsce zajmowane przez tabele i indeksy na dysku.

Na czym polega kompresja danych w SQL Server

Kompresja danych w SQL Server zmniejsza ilość miejsca zajmowanego przez dane tabel i indeksów. Mechanizm działa w warstwie aparatu składowania i może być ustawiany dla tabel, indeksów oraz poszczególnych partycji. Kompresja nie zmienia logicznej zawartości rekordów widzianej przez zapytania. SQL Server nadal zwraca te same kolumny i wartości, ale przechowuje je w bardziej zwartej reprezentacji. Dzięki temu na tej samej powierzchni dyskowej można przechować więcej stron danych, a odczyt dużych zbiorów może wymagać pobrania mniejszej liczby stron.

W SQL Server podstawowe tryby kompresji danych w tabelach i indeksach to ROW oraz PAGE. Kompresja wierszowa ogranicza narzut wynikający ze sposobu przechowywania typów o stałej długości. W szczególności wartości o długości mniejszej od maksymalnego rozmiaru nie muszą zajmować całego zarezerwowanego obszaru, a wartości NULL i zera mogą być przechowywane przy mniejszym narzucie. Kompresja stron wykorzystuje dodatkowo powtarzające się prefiksy i wartości występujące na stronie danych, dlatego zwykle daje większą redukcję rozmiaru niż sam tryb ROW.

ROW, PAGE i zakres zastosowania

Tryb ROW jest przetwarzany na poziomie pojedynczych rekordów. Może być przydatny wtedy, gdy dane mają dużo pól o stałej długości, lecz rzeczywiste wartości często są krótsze, albo gdy oczekiwane jest ograniczenie rozmiaru bez pełnego kosztu kompresji stron. Tryb PAGE obejmuje kompresję wierszową, a następnie analizuje zawartość całej strony danych. SQL Server buduje na stronie strukturę prefiksów oraz słownik powtarzających się wartości. Rekordy mogą odwoływać się do tych wspólnych fragmentów zamiast przechowywać każdą wartość w całości.

Ustawienie kompresji dotyczy konkretnego obiektu. Tabela może mieć inną opcję niż jej indeksy, dlatego sama kompresja tabeli nie oznacza automatycznie, że wszystkie indeksy zostały skompresowane w ten sam sposób. Dla tabel partycjonowanych można ustawić różne tryby dla różnych partycji, co pozwala inaczej traktować na przykład dane historyczne i bieżące. Indeksy nieklastrowane przechowują własne struktury stron, więc ich rozmiar należy analizować niezależnie. Przy planowaniu zmiany trzeba również uwzględnić indeks klastrowany, ponieważ w tabeli z takim indeksem jego strony są jednocześnie głównym magazynem danych.

Konfiguracja i ocena efektu

Komendą używaną do zmiany kompresji jest polecenie ALTER TABLE albo ALTER INDEX z opcją DATA_COMPRESSION. Przykładowo ustawienie kompresji stron dla wszystkich partycji tabeli może wyglądać następująco: ALTER TABLE dbo.Zamowienia REBUILD PARTITION = ALL WITH (DATA_COMPRESSION = PAGE);. Dla indeksu można zastosować polecenie ALTER INDEX IX_Zamowienia_Data ON dbo.Zamowienia REBUILD WITH (DATA_COMPRESSION = ROW);. Usunięcie kompresji wykonuje się przez wskazanie wartości NONE. Operacja przebudowy może wymagać dodatkowego miejsca roboczego, czasu procesora i zasobów wejścia-wyjścia, dlatego powinna być planowana z uwzględnieniem rozmiaru obiektu oraz aktywności systemu.

Przed wdrożeniem warto oszacować możliwe oszczędności dla konkretnej tabeli lub indeksu. SQL Server udostępnia do tego procedurę systemową sp_estimate_data_compression_savings, która porównuje przewidywany rozmiar obiektu przy wybranym typie kompresji. Wynik jest estymacją, a nie gwarantowanym pomiarem po przebudowie. Rzeczywisty efekt zależy między innymi od powtarzalności danych, długości wartości, liczby kolumn, rozkładu wartości NULL, struktury indeksów oraz partycjonowania. Po zmianie należy sprawdzić rozmiary obiektów w widokach katalogowych, czas wykonywania zapytań i obciążenie procesora.

Wpływ na wydajność i diagnostykę

Kompresja zmniejsza liczbę stron, które trzeba odczytać z dysku lub pamięci, ale wymaga pracy procesora podczas zapisu i odczytu skompresowanych danych. Nie ma więc uniwersalnej reguły, że każda tabela po kompresji będzie działała szybciej. Zapytania skanujące duże zakresy często korzystają z mniejszej liczby odczytów logicznych, natomiast obciążenia o wysokiej intensywności zapisu mogą odczuć dodatkowy koszt kodowania danych. Korzyść może być również ograniczona, gdy dane są już zwarte albo zawierają mało powtarzalnych wartości.

Dobór trybu należy oprzeć na pomiarach wykonanych dla rzeczywistego obciążenia. Trzeba porównać rozmiar tabeli i indeksów, liczbę odczytów logicznych, czas zapytań, użycie procesora oraz czas operacji modyfikujących dane. Szczególną uwagę należy zwrócić na przebudowy indeksów i tabel, ponieważ mogą one czasowo zwiększyć wykorzystanie dysku, procesora i dziennika transakcji. Kompresja nie zastępuje właściwego projektowania indeksów, ograniczania zbędnych danych ani archiwizacji. Jest właściwością fizycznego sposobu przechowywania, którą należy dobierać osobno dla obiektów o różnych charakterystykach dostępu.