Przykłady kodu z In-Memory pokazują tworzenie tabel zoptymalizowanych pod pamięć oraz procedur natywnie kompilowanych.
Zakres przykładów In-Memory OLTP w SQL Server
Przykłady kodu z In-Memory dotyczą w SQL Server technologii In-Memory OLTP, czyli mechanizmu przeznaczonego do wykonywania operacji na tabelach zoptymalizowanych pod pamięć. Taka tabela jest tworzona z opcją MEMORY_OPTIMIZED = ON i musi należeć do bazy danych skonfigurowanej z grupą plików zawierającą kontener MEMORY_OPTIMIZED_DATA. Przykład konfiguracji rozpoczyna się zwykle od utworzenia grupy plików poleceniem ALTER DATABASE ... ADD FILEGROUP ... CONTAINS MEMORY_OPTIMIZED_DATA, a następnie dodania do niej pliku lub kontenera.
Tabela zoptymalizowana pod pamięć różni się od zwykłej tabeli dyskowej sposobem przechowywania danych i obsługi współbieżności. Wiersze są przechowywane w strukturach zarządzanych przez silnik In-Memory OLTP, natomiast SQL Server zapisuje dane i informacje potrzebne do ich odtworzenia w plikach kontrolnych oraz plikach danych grupy MEMORY_OPTIMIZED_DATA. Nie oznacza to, że dane znikają po restarcie instancji. O trwałości decyduje między innymi parametr DURABILITY: SCHEMA_AND_DATA zachowuje schemat i dane, a SCHEMA_ONLY zachowuje schemat, lecz po ponownym uruchomieniu nie odtwarza zawartości tabeli.
Definicja tabeli i dobór indeksu
Przykładowa definicja tabeli In-Memory musi zawierać co najmniej jeden indeks. Może to być indeks haszujący zapisany jako INDEX IX_Orders_OrderId HASH (OrderId) WITH (BUCKET_COUNT = 1024) albo indeks nieklastrowany zapisany jako INDEX IX_Orders_CustomerId NONCLUSTERED (CustomerId). Indeks haszujący jest użyteczny przede wszystkim przy wyszukiwaniu po pełnej wartości klucza równości, na przykład w predykacie WHERE OrderId = @id. Parametr BUCKET_COUNT określa liczbę kubełków tablicy haszującej i powinien być dobrany do przewidywanej liczby unikatowych wartości klucza.
Indeks haszujący nie jest zamiennikiem indeksu uporządkowanego. Zapytania wykorzystujące zakresy, sortowanie lub wyszukiwanie po części warunku, takie jak WHERE OrderDate >= @from albo ORDER BY CustomerId, wymagają analizy planu i często lepiej współpracują z indeksem nieklastrowanym. W przykładach należy również uwzględnić ograniczenia obsługiwane przez konkretną wersję SQL Server, między innymi typy kolumn, klucze, ograniczenia oraz funkcje używane w wyrażeniach. Samo oznaczenie tabeli jako zoptymalizowanej pod pamięć nie gwarantuje przyspieszenia każdego zapytania.
Procedury natywnie kompilowane i transakcje
Procedura natywnie kompilowana jest tworzona przy użyciu WITH NATIVE_COMPILATION oraz SCHEMABINDING. Musi mieć jawnie określony sposób wykonywania transakcji, na przykład BEGIN ATOMIC WITH, w którym podaje się między innymi język oraz poziom izolacji. Przykładowa konstrukcja może używać TRANSACTION ISOLATION LEVEL = SNAPSHOT i zwracać dane z tabeli zoptymalizowanej pod pamięć na podstawie parametru wejściowego. Procedura jest kompilowana do kodu maszynowego przeznaczonego dla mechanizmu In-Memory OLTP, dlatego jej składnia i zestaw obsługiwanych instrukcji są bardziej ograniczone niż w zwykłym języku T-SQL.
Przygotowując przykład, trzeba rozdzielić poziom izolacji transakcji od trwałości tabeli. SCHEMA_AND_DATA i SCHEMA_ONLY opisują zachowanie danych po restarcie, natomiast SNAPSHOT, REPEATABLE READ i SERIALIZABLE opisują sposób uzyskiwania spójnego widoku oraz wykrywania konfliktów. SQL Server wykorzystuje mechanizmy kontroli wersji wierszy, więc transakcja może zakończyć się błędem konfliktu i wymagać ponowienia. Kod aplikacji powinien obsługiwać takie sytuacje, zwłaszcza gdy wiele sesji równocześnie aktualizuje te same logiczne rekordy.
Weryfikacja działania przykładu
Przykład kodu warto sprawdzić w kilku etapach. Najpierw należy potwierdzić, że baza ma grupę plików MEMORY_OPTIMIZED_DATA oraz że użytkownik wykonujący skrypt ma wymagane uprawnienia. Następnie trzeba utworzyć tabelę, indeksy i procedurę, wstawić dane testowe oraz wykonać zapytania odpowiadające rzeczywistym predykatom. Dla indeksu haszującego należy przetestować wyszukiwanie równościowe, a dla indeksu nieklastrowanego także zakresy i sortowanie. Wynik powinien być oceniany na podstawie planu wykonania, czasu, liczby operacji oraz zachowania przy współbieżności, a nie wyłącznie na podstawie udanego wykonania skryptu.
Istotnym testem jest również restart usługi SQL Server lub odtworzenie bazy w środowisku testowym. Po restarcie tabela z trwałością SCHEMA_AND_DATA powinna zawierać wcześniej zapisane rekordy, natomiast tabela SCHEMA_ONLY powinna pozostać pusta przy zachowanym schemacie. Należy także sprawdzić obsługę błędów kompilacji natywnej procedury, konfliktów transakcji, zbyt małej liczby kubełków oraz zapytań, dla których wybrany indeks nie pasuje do predykatu. Takie testy pozwalają odróżnić poprawność składni od rzeczywistej przydatności rozwiązania w SQL Server.
