Research SQL Server 2016CTP2 – 3/13

Technologie In-Memory w tym również indeks kolumnowy, to moja ulubiona tematyka, więc oczywiście postarałem się zbadać różne aspekty zmian i działania indeksu kolumnowego. Jest to w rzeczywistości trzecia wersja tego indeksu. Indeks kolumnowy w SQL Server jest dostępny od wersji 2012. W tej wersji był bardzo ograniczony np.: mógł być tylko, jako indeks dodatkowy i to tylko do odczytu. Wersja 2014 dała nam bardzo silne rozwiązanie, czyli indeks kolumnowy, jako indeks grupujący. Ale postaram się teraz skoncentrować na tym, co nowego w wersji.

Ogólne zmiany

W SQL Server 2016CTP2 możemy zrobić indeks kolumnowy, jako indeks nie klastrujacy z możliwością modyfikacji danych. Co daje nowe większe zastosowania niż dotychczasowe możliwe scenariusze. Z całą pewnością wartościowa nowa cecha, ale nie jedna z najważniejszych w przypadku indeksu kolumnowego. O indeksie kolumnowym nie klastrowanym będzie jeszcze raz w kolejnym poście serii Research SQL Server 2016CTP2.

Wiemy dobrze, że indeks kolumnowy jest idealny do rozwiązań związanych z hurtowniami danych, gdzie agregujemy wiele informacji, jak to można było sprawdzić w wersji SQL Server 2014 indeks kolumnowy, jako indeks klastrujący powodował to, że nasze dane nieporównywalnie mniej miejsca zajmowały zarówno na dysku, jak i w pamięci. Niestety koncepcja indeksu kolumnowego nie jest optymalna pod kątem selekcji poszczególnych wierszy i to jeszcze projekcji wielu kolumn. Tutaj w wersji SQL Server 2016CTP2 możemy wykorzystać istotną zmianę, czyli możliwość budowania indeksów opierających się na B-drzewie do struktury indeksu kolumnowego. Czyli indeks kolumnowy dla dużych obliczeń i agregacji, a dla wyszukiwania pojedynczych wierszy indeksy pokrywające zbudowane na strukturze B-drzewa.

Kolejnym scenariuszem wcześniej niewspieranym, który jest zaimplementowany w SQL Server 2016CTP2 jest sytuacja, gdy agregaty w analityce wykonujemy tylko dla ograniczonego zbioru danych, tutaj z pomocą może przyjść indeks kolumnowy filtrowany. Czyli taki, który będzie posiadał warunek WHERE. Podobnie jak mamy indeksy nieklastrujące filtrowane.

Kolejnym elementem jest wsparcie dla poziomów izolacji RCSI i SI.

Wsparcie AlwaysOn było już w wersji SQL Server 2012/2014, ale teraz należałoby wziąć to pod uwagę, że możemy mieć nawet trzy repliki danych, w których będzie dostępny indeks kolumnowy.

Ostatnia drobna zmiana, to fakt, iż teraz w składni tworzenia tabeli, możemy od razu utworzyć indeks kolumnowy.

Tryb przetwarzania wsadowy – batch (wektorowe przetwarzanie)

Jednym z podstawowych elementów mającym wpływ na wydajność przetwarzania indeksu kolumnowego, było wprowadzenie nowego trybu pracy – przetwarzania wsadowego (ang. BATCH), zamiast przetwarzania wiersz po wierszu (ang. row-by-row). Przetwarzanie takie wykorzystuje mechanizmy przetwarzania wektorowego na procesorach. Każda kolejna wersja indeksu kolumnowego umożliwiała przetwarzanie w ten sposób przez kolejne operatory.

Pierwsza zauważalna zmiana w przypadku wersji SQL Server 2016CTP2 z indeksami kolumnowymi to fakt, iż przetwarzanie wsadowe jest mimo wykonywania zapytania na jednym procesorze, czyli w jednym wątku. We wcześniejszych wersjach niestety to nie miało miejsca, przez co nie było, aż tak dużego wzrostu wydajności.

Przykład zapytania wykonywanego z opcją MAXDOP 1.

Jak zobaczymy na szczegóły operatorów, to widać, iż przetwarzanie jest wsadowe.

Widać to w każdy operatorze, również w sortowaniu

To pokazuje kolejną nowość w wersji SQL Server 2016CTP2 operator sortowania działa w trybie wsadowym.

Więc, należy przetestować kolejną istotną rzecz. Jak będzie się zachowywał indeks kolumnowy w wersji SQL Server 2016CTP2 w trakcie wykonywania agregacji, lub funkcji okienkowych.

I tutaj bardzo miła niespodzianka, a dokładnie bardzo duży skok wydajności. Jest wsparcie!

Przykładowy test. Zapytanie wykonywane bez udziału indeksu kolumnowego, kosztowne mimo zbudowania odpowiedniego indeksu POC.

Tutaj to samo zapytanie, ale wykorzystujące indeks kolumnowy ze wsparciem wsadowym.

Na tym skromnym przykładzie różnica jest bardzo widoczna.

SQL Server 2016 ma wsparcie dla:

  • Operator SORT
  • Agregacji z wielowartościowymi fukcjami distinct: COUNT/COUNT, AVG/SUM, CHECKSUM_AGG, STDEV/STDEVP.
  • Okienkowych funkcji agregujących: COUNT, COUNT_BIG, SUM, AVG, MIN, MAX, and CLR.
  • Okienkowych funkcji agregujących użytkownika: CHECKSUM_AGG, STDEV, STDEVP, VAR, VARP, and GROUPING.
  • Analitycznych agregujących funkcji okienkowych: LAG< LEAD, FIRST_VALUE, LAST_VALUE, PERCENTILE_CONT, PERCENTILE_DISC, CUME_DIST, and PERCENT_RANK.

Jak widać, nowy COLUMNSTORE da bardzo duże przyśpieszenie w wielu kolejnych obszarach. A samo wsparcie dla operatora SORT przyśpieszy już wiele i tak bardzo efektywnych zapytań.

Podsumowanie

Widać, że nowy indeks kolumnowy niebędący nowością, może być jednym z głównych motywacji do przejścia do nowej wersji serwera bazodanowego. Daje w wielu obszarach przyspieszenie, mocne wsparcie z AlwaysON, a także z tabelami In-Memory (o tym będzie w oddzielnym wpisie) stanowi bardzo mocne rozwiązanie składowania danych w SQL Server. Różnorodność konfiguracji naszych struktur danych wraz z indeksem kolumnowym jest przeogromna i zależy tylko i wyłącznie od naszej specyfiki pracy. Podsumowując mamy takie warianty:

Lp Dane Indeks dodatkowy
1 W indeksie klastrowanym na B-drzewie Indeks nieklastrowany kolumnowy
2 W tabelach In-memory Indeks nieklastrowany kolumnowy
3 W indeksie klastrowanym kolumnowym Indeks nieklastrowany na B-drzewie
4 W indeksie klastrowanym kolumnowym -

 

Oczywiście scenariusze 1 i 2 mogą być jeszcze wzbogacone o wariant indeksu kolumnowego filtowanego.

Warto potestować i zastanowić się nad odpowiedniejszymi scenariuszami pod swoje dane. Temat indeksu kolumnowego powróci jeszcze w naszym cyklu.

Kolejna część cyklu Research SQL Server 2016CTP2 poświęcone będzie dla odmiany danym NoSQL, a dokładnie popularnemu w środowiskach NoSQL standardowi JSON. Zapraszam do lektury, także do wymiany komentarzy wszystkich, co również testują ten nowy serwer bazodanowy.

Share this article ...

Google Plus
Ihren LinkedIn Kontakten zeigen



This entry was posted in General, SQL Server and tagged , , , , , by Lukasz Grala. Bookmark the permalink.
Lukasz Grala

About Lukasz Grala

A Data Platform and Business Intelligence architect and consultant. An authorized Microsoft trainer and university lecturer. A holder of numerous Microsoft certificates, since 2010 Microsoft Most Valuable Professional (MVP) in the SQL Server category. An author of articles and webcasts available on TechNet portal. He runs two blogs, SQL Research and PowerPivot’s Blog. The author of various trainings and a speaker at numerous IT conferences, as well as the Polish SQL Server User Group (PLSSUG) leader.

Leave a Reply

Connect with:
  • This field its required.
  • This field its required.
    • Message is required