Kompresja danych

Pierwsza próba kompresji w SQL Server wygląda obiecująco. SQL Server 2008 zapewnia dwa typy kompresji: wierszy i stron. Pierwsza jest kompresją rzeczywistą, w ramach której nieużywane miejsca na końcu kolumn są usuwane w celu zaoszczędzenia pamięci. Kompresja stron (inaczej słownikowa) normalizuje dane na każdej stronie, utrzymując dla nich wskaźnik odniesienia. W SQL Server 2008 kompresja stron zawiera kompresję wierszy: jeżeli włączona jest kompresja stron, to przy okazji uzyskuje się kompresję wierszy.

Microsoft zapewnia poręczny kreator wyliczenia kompresji, który szacuje oszczędności pamięci, jakie można uzyskać w jej wyniku. Kreator wykonuje testowy scenariusz dla każdego typu kompresji i podaje przewidywany nowy rozmiar tablicy. Podczas testów uzyskiwano rezultaty odbiegające od finalnych o 1 - 2%, co jest wynikiem bardzo dobrym.

Zakres, w jakim można skompresować tablicę, zależy od typów danych i typu kompresji. Jeżeli dane mają dużo spacji, wtedy kompresja na poziomie wierszy jest bardzo efektywna. Jeżeli natomiast tablica zawiera wiele powtarzających się danych, to kompresja stron na poziomie tabeli będzie korzystniejsza.

Znaczenie ma też uporządkowanie danych. Ponieważ SQL Server kompresuje na poziomie strony, powtarzające się dane są skupione razem i nie będą duplikowane. Dlatego pod uwagę należy brać zarówno rodzaj danych, jak i ich uporządkowanie.

Podsumowując: podobnie jak w przypadku Advanced Compression w Oracle Database 11g, rezultaty otrzymane z pomocą Data Compression w SQL Server 2008 miały duży rozrzut. Na niektórych zestawach danych uzyskano zarówno bardzo niski stopień kompresji (17%), jak i bardzo duży (76%) na innych. Najlepszy wynik uzyskano na danych nieznormalizowanych w hurtowni danych.

W zakresie kompresji SQL Server ma jedną przewagę nad Oracle: SQL Server kompresuje istniejące tablice jedną instrukcją; w Oracle Database 11g konieczne jest utworzenie nowej tablicy, umieszczenie tam danych i następnie usunięcie starej tablicy. SQL Server nie tylko uwalnia administratora od konieczności utworzenia dodatkowej kopii danych, ale pozwala na wykonywanie operacji na tablicy w czasie kompresji.

Nowym mechanizmem jest także Sparse Columns, który pozwala na przechowywanie wartości pustych bez zajmowania fizycznej pamięci. Jednak mechanizm ten nie jest kompatybilny z Data Compression.

Kompresja składowania i ulepszania indeksowania

SQL Server 2008 wprowadza także mechanizm Backup Compression, który zapewnia stopień kompresji dorównujący osiąganemu przez niezależne narzędzia. Jednak ma on kilka wad. Przede wszystkim jest dostępny tylko w edycji enterprise, ale nawet tutaj jest trudny do zarządzania. Większość instancji SQL Server nie jest edycją enterprise i dla nich robienie wyjątku w planowaniu składowania jest nie do zaakceptowania.

Rozmiar bazy danych nie jest powodem, dla którego wybiera się edycję enterprise. Ponieważ większość wersji SQL Server może obsługiwać nielimitowany rozmiar danych, edycja enterprise jest generalnie wybierana z powodu zawartych w niej mechanizmów. W rezultacie, istnieje mnóstwo serwerów SQL z bardzo dużymi zbiorami danych, które nie są klasy enterprise, a potrzebują także skompresowanego składowania, co oznacza, że prawdopodobnie w takich przypadkach dobiera się do nich niezależne rozwiązania składowania.

Ponadto rozwiązania niezależne mają scentralizowane repozytoria i zapewniają centralne raporty i alarmy. Tak więc, jeżeli użyje się wbudowanej w SQL Server kompresji, to w efekcie eliminuje się centralne zarządzanie składowaniem dla tych serwerów. Rozwiązania niezależne mają też inne mechanizmy, ale odtwarzanie na poziomie obiektu i centralne zarządzanie składowaniem to najważniejsze powody, dla których SQL Server Backup Compression nie będzie mniej wartościowy dla większości użytkowników.

Gruntownemu remontowi w SQL Server 2008 poddano indeksowanie. Indeksy nie tylko mogą być kompresowane, ale także można budować filtrowane indeksy. Mają one klauzule "where", pozwalającą na częściowe indeksowanie dużych tablic.

Przy filtrowaniu indeksów można nie tylko zaoszczędzić pamięć indeksów, również kwerendy używające tych indeksów będą szybsze, ponieważ działają na podzbiorze pełnego zbioru danych. Przykładem użycia filtrowanych indeksów może być sytuacja, gdy w tablicach znajdują się dane np. z dziesięciu lat, ale nikt ich nie indeksował od dwóch lat. Można wtedy utworzyć filtrowany indeks dokładnie dla tych dwóch lat.

SQL Server Reporting Services

SSRS (SQL Server Reporting Services) także poddano gruntownemu remontowi i nie trzeba już dłużej zdawać się na możliwości raportowania IIS. Jest to o tyle istotne, że wielu użytkowników może nie aprobować wnoszenia zmian do Windows, takich jak instalowanie IIS. Użytkownicy często nie chcą wykonywać większych zmian w instalacji Windows, a dodawanie takiego komponentu jak IIS jest postrzegane jako trudne do zabezpieczenia, co wprowadza podwójną niepewność.

Inne ulepszenie, o nazwie Tablix, jest nowym typem elementu danych, który łączy tablicę, macierz i listę. Tablix pozwala na grupowanie według kolumn lub wierszy, a także definiowanie grup sąsiednich.

Udoskonalono również Report Builder. Usunięto kilka ograniczeń, które utrudniały z nim pracę: teraz można wykonać prawie wszystko to, co zapewnia Visual Studio. Report Builder zawiera kreator automatyzujący formatowanie danych i wykresów. Zatem trudno będzie teraz znaleźć powód do pisania raportów w Visual Studio.

MICROSOFT SQL SERVER 2008