Columnstore index–nowość SQL Server 2012, czyli trochę o VertiPaq
Blog o PowerPivot, a post o Columnstore… Tak dokładnie. Takie miałem zamierzenie. PowerPivot był nowością wprowadzającą w rozwiązaniu SQL Server jako pierwsze mechanizm VertiPaq. Przy nowej edycji SQL Server 2012 – o nazwie kodowej Denali powstaje cała ścieżka rozwiązań BI bazująca lub wykorzystująca mechanizm VertiPaq:
-
Model BISM (Business Intelligence Semantic Model) w którym możemy projektować rozwiązania BI
-
PowerPivot w wersji 2 (w tym Analysis Services Integreted dla SharePoint 2010 czyli PowerPivot dla SharePoint))
-
PowerView (znany pod nazwą kodową Projekt Crescent) – nowoczesne narzędzie do wizualizacji danych (w tym danych z PowerPivot i BISM)
-
SQL Server Analysis Services Tabular Mode
-
Nowe indeksy w SQL Server 2012 – Columnstore Index (projekt Apollo)
Za całą pewnością właśnie te tematy będą gościć na tym blogu. Na pierwszy ogień na moim blogu biorę właśnie nowe indeksy w SQL Server 2012. Jestem pod wrażeniem tego mechanizmu i chciałem się tym podzielić z moimi czytelnikami.
Wprowadzenie do indeksów Columnstore
Dotychczasowo wszystkie dane SQL Server przechowywał na stronach wierszami, ostatnich wersjach SQL Server 2008/2008R2 umożliwiał już kompresję danych, co dawało bardzo często dobre efekty. W rozwiązaniu VertiPaq wymyślono, iż dane będą przechowywane nie wierszami, ale kolumnami Co to daje? Otóż jeżeli posiadamy miliony rekordów dotyczących np.: ceny sprzedaży, albo ilości sprzedaży można sobie wyobrazić jak często się te wartości powtarzają, ponadto należą do tego samego typu przez co można wykonać o wiele bardziej efektywną kompresję tych danych. Kolejną zaletą jest fakt, iż w danych analitycznych rzadziej pobieramy pojedyncze wiersze, a częściej wykonujemy różnego rodzaju agregaty właśnie na poszczególnych kolumnach.
Wszystkie dane silnik SQL Server umieszcza na stronach wierszami ![]()
w przypadku COLUMNSTORE (czyli wykorzystując mechanizm VertiPaq) dane umieszczone są kolumnami: ![]()
Co jeszcze daje nam taka zmiana? Po pierwsze zmniejsza nam ilość operacji I/O zarówno ze względu na wielkość danych, po drugie pobiera jedynie te kolumny, które akurat potrzebuję do danego zapytania, ale także ze względu na fakt, iż SQL Server odczytuje dane pewnym obszarami (w przypadku COLUMNSTORE mówi się segmentami) i ze względu na sposób położenia informacji SQL Server ma lepszą ilość trafień w zaczytanych danych z pewnym wyprzedzeniem, niż ma to miejsce przy odczycie zwykłych stron bazy danych.
Odczyt niezbędnych kolumn, a nie całych wierszy ![]()
Jednak to nie wszystkie zalety wykorzystywania indeksów typu COLUMNSTORE. Otóż w przypadku bardzo dużych zbiorów danych , dane przechowywane w indeks COLUMNSTORE mogą być przetwarzane w sposób wsadowy (BATCH MODE), daje to pełne wykorzystanie możliwości zrównoleglenie, gdyż każdy wsad jest niezależny od pozostałych operacji.
Ograniczenia
Struktura indeksów COLUMNSTORE ma pewne ograniczenia lub restrykcje, głównie wynikające z architektury tych indeksów:
-
Dane w indeksie COLUMNSTORE nie mogą być modyfikowane!!!
-
Nie może być w tym indeksie więcej niż 1024 kolumn
-
Indeks ten jest jedynie nie klustrowanym indeksem
-
Nie może być unikalnym
-
Nie może być zakładany na widokach ani na widokach indeksowanych
-
Nie można używać kolumn typu SPARSE
-
Nie można zmieniać definicji indeksu pryz użyciu składni ALTER INDEX (można tym poleceniem jedynie przebudować i wyłączyć indeks)
-
Nie ma takich opcji jak INCLUDE, ASC, DESC
-
Nie wspiera mechanizmu SEEK (inne zastosowanie jest tego indeksu)
-
Nie mechanizmów (kompresji – posiada własną; replikacji, CHANGE DATA CAPTURE, CHANGE TRACKING – jest tylko do odczytu; FILESTREAM)
Jak widać stosując taki indeks do hurtowni danych ograniczenia te nie są straszne. Część z nich jest wręcz oczywista ze względu na omówioną wcześniej architekturę.
Podsumowanie
Jak widać mechanizm ten jest bardzo ciekawy i daje naprawdę niesamowite rezultaty. Wykonałem już pierwsze testy na różnej ilości danych. W kolejnych postach już niebawem na tym blogu przedstawię jak tworzyć COLUMNSTORE index, oraz omówię i przedstawię rezultaty testów jakie wykonałem.
Czekajac na Crescent…
W listopadzie w ramach konferencji PASS w USA zostało przedstawionych wiele nowych informacji dotyczących następnych produktów SQL Server i Business Intelligence (Denali, Apollo, Atlanta, Crescent, Juneau..). Na tym blogu najciekawszy dla nas jest PowerPivot. I tak parę słów podsumowania na co można liczyć w najbliższych wersjach (ponoć już CTP2 Denali nam to zaoferuje).
Po pierwsze rozszerzone będzie DAX o funkcje rankingowe. Z punktu widzenia Business Intelligence PowerPivot otrzyma wiele mechanizmów dostępnych dotychczas tylko w rozwiązaniach opartych na SQL Server Analysis Services między innymi:
-
KPI
-
Hierarchie (w tym Parent-Child hierarchies)
-
Perspektywy
-
Drillthrough
Zmienią się możliwości w zarządzaniu relacjami, będzie obsługa do relacji Wiele-do-wielu, oraz możliwość robienia wiele relacji (przypominam, iż obecnie może być tylko jedna relacja pomiędzy dwiema tabelami). W zakresie składowania danych ma dojść obsługa partycjonowania i stronicowania, natomiast bezpieczeństwa wsparcie do ról Active Directory. Bezpieczeństwa danych ma być również poziomie wiersza i kolumny.
Dużą zmianą będzie możliwość budowania tzw BISM (Business Intelligence Semantic Model). BISM będzie nowością Analysis Services w wersji Denali (SQL Server 2011). Będziemy mogli tworzyć bazę danych SSAS na serwerze w trybie in-memory, w ten sposób zainstalowane SSAS będzie mogło pracować w trybie zwykłym (jak dotychczas),a także w trybie in-memory. Podobnie jak to w tej chwili jest możliwe w przypadku integracji PowerPivot z SharePoint. Model semantyczny będzie składał się z 3 warstw:
-
warstwy danych (Data Layer)
-
warstwa logiki biznesowej (Business Logic)
-
warstwa dostępu do danych (Data Access)
Przechowywany model będzie miał w zasadzie postać relacyjną, ale będzie można wykorzystywać klientów (aplikacji), które będą mogły przy użyciu języka MDX pytać model. Drugą metodą korzystania z modelu będą aplikacje korzystające z języka wyrażeń DAX takie jak nowy produkt powstający w ramach projektu Crescent. W warstwie dostępu do danych będziemy mogli skorzystać z dwóch wariantów dostępu. Pierwszy to tzw dostęp czasu rzeczywistego, czyli dostęp bezpośredni do źródeł danych (data sources), drugi to utworzenie w pamięci tzw VertiPaq, przyspieszający znacznie działanie, ale potrzebujący czas na utworzenie takiej struktury. Wybór będzie należał dla projektanta modelu.
Pozostaje nam tylko czekać na CTP2 do Denali, który może zawierać w sobie pierwsze wersje BISM i Crescent…
