Hash Index

Hash Index to typ indeksu wykorzystujący funkcję skrótu do szybkiego lokalizowania danych w tabelach In-Memory.

Jak działa Hash Index w tabeli In-Memory

Hash Index w Microsoft SQL Server jest rodzajem indeksu nieklastrowanego przeznaczonego dla tabel zoptymalizowanych pod kątem pamięci, czyli tabel używających mechanizmu In-Memory OLTP. Indeks nie przechowuje uporządkowanej listy kluczy tak jak indeks oparty na drzewie B. Dla wartości klucza obliczana jest wartość funkcji skrótu, a następnie rekord jest kierowany do odpowiedniego kubełka, określanego w dokumentacji jako bucket. Podczas wyszukiwania SQL Server wykonuje tę samą operację skrótu dla wartości podanej w predykacie i przechodzi bezpośrednio do właściwego obszaru indeksu.

Największą korzyść uzyskuje się przy zapytaniach wyszukujących dokładną wartość klucza, na przykład przy warunku WHERE CustomerID = 125. Hash Index jest projektowany przede wszystkim dla predykatów równościowych. Nie tworzy naturalnego porządku wartości, dlatego nie jest właściwym wyborem dla zapytań wyszukujących zakres, sortujących po indeksowanej kolumnie albo sprawdzających warunki typu <, > czy BETWEEN. W takich przypadkach optymalizator może potrzebować innego indeksu albo skanowania tabeli.

Bucket count, kolizje i rozkład kluczy

Podczas definiowania Hash Index w SQL Server trzeba określić parametr BUCKET_COUNT. Jest to liczba kubełków używanych przez strukturę skrótu, a nie gwarantowana liczba rekordów, które indeks może przechować. Wartość powinna być dobrana na podstawie przewidywanej liczby różnych wartości klucza. Zbyt mała liczba kubełków powoduje, że wiele wartości trafia do tych samych kubełków, co wydłuża przeszukiwanie łańcuchów kolizji. Zbyt duża wartość zwiększa zużycie pamięci przeznaczonej na strukturę indeksu.

Warto pamiętać, że SQL Server zaokrągla określony BUCKET_COUNT do najbliższej potęgi liczby 2. Oznacza to, że deklarowana wartość nie musi być identyczna z rzeczywistą liczbą kubełków utworzonych przez silnik. Przykładowo parametr ustawiony na wartość 1000 może skutkować utworzeniem 1024 kubełków. Przy doborze rozmiaru trzeba uwzględnić nie tylko bieżącą liczbę rekordów, lecz także spodziewany wzrost tabeli oraz liczbę unikatowych wartości klucza.

Kolizja nie oznacza utraty danych ani błędu integralności. Występuje wtedy, gdy różne wartości klucza otrzymają ten sam wynik funkcji skrótu. SQL Server przechowuje wówczas odpowiednie wpisy w tym samym kubełku i porównuje wartości kluczy, aby znaleźć właściwy rekord. Niewielka liczba kolizji jest normalna, ale długie łańcuchy kolizji mogą zmniejszyć przewagę indeksu nad innymi strukturami. Dlatego sam fakt istnienia Hash Index nie gwarantuje szybkiego wykonania każdego zapytania.

Dobór indeksu do predykatu zapytania

Hash Index powinien odpowiadać rzeczywistemu sposobowi wyszukiwania danych. Jeżeli tabela jest często odczytywana według pełnego klucza złożonego, indeks powinien obejmować kolumny używane razem w warunku równości. Pominięcie części klucza może sprawić, że SQL Server nie wykorzysta indeksu w oczekiwany sposób albo będzie musiał sprawdzić większą liczbę wpisów. Przy kluczu złożonym znaczenie ma również zgodność predykatu z kolumnami zdefiniowanymi w indeksie.

Hash Index nie zastępuje automatycznie wszystkich innych indeksów tabeli In-Memory. Jedna tabela może potrzebować różnych struktur dla różnych wzorców dostępu: jednej do wyszukiwania dokładnego identyfikatora, a innej do zapytań zakresowych lub operacji wymagających porządku wartości. Przy analizie planu wykonania należy sprawdzić, czy predykat rzeczywiście odpowiada indeksowi hashującemu oraz czy filtr nie zawiera dodatkowych warunków, które ograniczają jego użyteczność.

W praktyce ocenia się między innymi liczbę pustych kubełków, długość łańcuchów kolizji, kardynalność klucza oraz rozmiar tabeli. Liczba różnych wartości jest ważniejsza niż sama liczba wierszy, ponieważ powtarzające się klucze mogą skupiać wiele rekordów w tych samych miejscach. Należy także uwzględnić aktualizacje i usuwanie danych. Zmiana wartości kolumny klucza oznacza zmianę położenia wpisu w strukturze skrótu, a operacje te są obsługiwane przez mechanizm indeksu razem z utrzymaniem wersji rekordów używanych przez In-Memory OLTP.

Diagnostyka problemów z indeksem hashującym

Diagnostyka Hash Index rozpoczyna się od potwierdzenia, że obiekt jest tabelą zoptymalizowaną pod kątem pamięci i że indeks został utworzony dla właściwych kolumn. Następnie należy porównać definicję indeksu z zapytaniami wykonywanymi przez aplikację. Szczególną uwagę zwraca się na zapytania równościowe, zakresowe, złożone warunki filtrujące oraz sytuacje, w których wartość klucza ma bardzo niską selektywność. Indeks na kolumnie przyjmującej niewiele różnych wartości może tworzyć długie łańcuchy wpisów w kubełkach.

Przyczyną wolnego działania nie musi być uszkodzenie indeksu. Problemem może być niedopasowany BUCKET_COUNT, niekorzystny rozkład wartości, używanie operatora zakresowego albo odczyt wymagający kolumn nieobjętych właściwym indeksem. Weryfikacja powinna obejmować definicję tabeli, metadane indeksu, plan wykonania i statystyki dotyczące kubełków. Dopiero zestawienie tych informacji pozwala rozstrzygnąć, czy potrzebna jest zmiana rozmiaru struktury, dodatkowy indeks, modyfikacja zapytania czy korekta modelu danych.

Hash Index należy analizować jako element konkretnego modelu dostępu do tabeli In-Memory, a nie jako uniwersalne przyspieszenie dla wszystkich operacji. W środowisku wykorzystującym SQL Server sprawdzenie jego działania wymaga odniesienia do wersji silnika, konfiguracji tabeli zoptymalizowanej pod kątem pamięci oraz rzeczywistych planów zapytań. Przy problemach z dostępem do danych diagnostyka powinna obejmować również inne elementy serwera i aplikacji, ponieważ opóźnienie może powstawać poza samą strukturą indeksu.