Tabela zoptymalizowana pod kątem pamięci

Tabela zoptymalizowana pod kątem pamięci przechowuje dane w RAM, oferując znacznie krótszy czas dostępu.

Czym jest tabela zoptymalizowana pod kątem pamięci

Tabela zoptymalizowana pod kątem pamięci to obiekt używany w mechanizmie In-Memory OLTP systemu Microsoft SQL Server. Jej wiersze są przechowywane w pamięci operacyjnej, a dostęp do nich odbywa się z użyciem struktur zaprojektowanych dla przetwarzania danych bez klasycznego modelu blokad i stron danych stosowanego przez tradycyjne tabele dyskowe. Nie oznacza to jednak, że dane istnieją wyłącznie w ulotnym RAM-ie. SQL Server zapisuje zmiany w plikach dziennika transakcji, a trwałość danych może być zapewniona również przez pliki kontrolne i kontenery pamięciowe właściwe dla In-Memory OLTP.

Taka tabela wymaga jawnego określenia sposobu przechowywania. W SQL Server stosuje się między innymi opcję MEMORY_OPTIMIZED = ON. Podczas tworzenia należy także wskazać indeks główny, ponieważ tabela zoptymalizowana pod kątem pamięci nie korzysta z identycznego zestawu struktur indeksowych jak tabela oparta na stronach danych. Dostępne są indeksy haszujące oraz indeksy zakresowe typu BW-tree. Wybór powinien odpowiadać sposobowi wyszukiwania: indeks haszujący jest przeznaczony przede wszystkim do dopasowania wartości, natomiast indeks zakresowy obsługuje również porządkowanie i zapytania wykorzystujące przedziały.

Jak SQL Server przechowuje i modyfikuje wiersze

In-Memory OLTP używa wersjonowania wierszy. Przy aktualizacji SQL Server tworzy nową wersję wiersza, a poprzednia pozostaje dostępna do czasu, aż nie będzie już potrzebna żadnej aktywnej transakcji. Mechanizm ten wspiera wielowersyjne odczyty bez klasycznego blokowania czytelników przez zapisujących. Transakcje nadal podlegają regułom spójności i izolacji, lecz sposób wykrywania konfliktów różni się od działania zwykłych tabel. Konflikt zapisu może zostać wykryty przy zatwierdzaniu transakcji, dlatego aplikacja korzystająca z takiej tabeli powinna poprawnie obsługiwać nieudane zatwierdzenia i ewentualne ponowienie operacji.

Tabela zoptymalizowana pod kątem pamięci może być trwała albo nietrwała. Tabela trwała zachowuje dane po ponownym uruchomieniu usługi SQL Server, ponieważ zmiany są odtwarzane na podstawie informacji zapisanych na dysku. Tabela nietrwała, tworzona z opcją DURABILITY = SCHEMA_ONLY, zachowuje definicję schematu, ale jej zawartość nie jest odtwarzana po restarcie. Ten wariant nadaje się do danych tymczasowych, buforów roboczych i obszarów przejściowych, których utrata po zatrzymaniu instancji jest akceptowalna. Nie powinien zastępować magazynu danych wymagających trwałego odtworzenia.

Wymagania pamięciowe trzeba zaplanować przed wdrożeniem. Wiersze, indeksy i dodatkowe wersje utworzone przez współbieżne transakcje zajmują pamięć, a zwolnienie miejsca może następować z opóźnieniem. Rozmiar tabeli nie jest więc jedynym parametrem do oszacowania. Należy uwzględnić wzrost danych, liczbę indeksów, długość kolumn o zmiennej szerokości oraz obciążenie generowane przez aktualizacje i usuwanie wierszy.

Indeksy, transakcje i ograniczenia użycia

Struktura indeksów ma bezpośredni wpływ na działanie tabeli zoptymalizowanej pod kątem pamięci. Indeks haszujący wymaga określenia liczby kubełków, a jego skuteczność zależy od rozkładu wartości klucza. Zbyt mała liczba kubełków może powodować długie łańcuchy kolizji i zwiększać koszt wyszukiwania. Zbyt duża liczba kubełków zużywa pamięć bez proporcjonalnej korzyści. Indeks zakresowy jest właściwszy wtedy, gdy zapytania filtrują dane operatorami takimi jak >, <, BETWEEN albo sortują wynik według klucza.

Nie każda funkcja dostępna dla tradycyjnych tabel działa w identyczny sposób dla tabel In-Memory OLTP. Ograniczenia mogą dotyczyć typów danych, kluczy, ograniczeń integralności, wyzwalaczy, zapytań oraz procedur przeznaczonych do kompilacji natywnej. SQL Server określa obsługiwane elementy zależnie od wersji i poziomu zgodności bazy, dlatego przed migracją trzeba sprawdzić konkretną definicję tabeli oraz planowane zapytania w dokumentacji właściwej wersji SQL Server. Samo przeniesienie tabeli do pamięci nie gwarantuje przyspieszenia, jeśli wąskim gardłem jest dysk, sieć, nieefektywne zapytanie, nadmierna liczba indeksów albo oczekiwanie na zasoby poza tabelą.

W praktyce tabela pamięciowa jest dobierana do obciążeń charakteryzujących się dużą liczbą krótkich operacji i wysoką współbieżnością. Może być użyteczna dla kolejek wewnętrznych, tabel sesyjnych, rejestrów operacji lub intensywnie modyfikowanych struktur pomocniczych, ale jej zastosowanie powinno wynikać z pomiarów. Należy porównać czas wykonania zapytań, liczbę konfliktów transakcyjnych, zużycie pamięci, obciążenie procesora oraz zachowanie systemu podczas restartu i odtwarzania bazy.

Diagnostyka pamięciowej tabeli w środowisku SQL Server

Diagnostyka rozpoczyna się od potwierdzenia, że tabela została utworzona jako obiekt pamięciowy i ma oczekiwane indeksy. Można przeanalizować definicję tabeli w katalogach systemowych oraz sprawdzić wykorzystanie pamięci przez obiekty In-Memory OLTP za pomocą widoków dynamicznego zarządzania, w tym sys.dm_db_xtp_table_memory_stats. Warto obserwować nie tylko bieżące zużycie pamięci, ale również liczbę wierszy, rozmiar indeksów i udział pamięci zajmowanej przez wersje wierszy. Nagły wzrost tych wartości może wskazywać na długotrwałe transakcje, niepasujący indeks albo zbyt intensywne aktualizacje.

Podczas analizy problemów z wydajnością trzeba rozdzielić opóźnienie wynikające z samego dostępu do tabeli od opóźnienia powodowanego przez transakcję obejmującą wiele obiektów. Odczyt z pamięci może być szybki, lecz całe zapytanie nadal może wykonywać kosztowne operacje sortowania, agregacji, łączenia lub konwersji typów. Należy także sprawdzić, czy aplikacja nie wykonuje niepotrzebnych pełnych skanów, czy predykaty odpowiadają istniejącym indeksom oraz czy liczba jednoczesnych transakcji mieści się w zaplanowanym budżecie pamięci.

W środowisku serwerowym ważne jest kontrolowanie zachowania po restarcie i podczas odtwarzania bazy. Dla tabel trwałych należy zweryfikować poprawność plików związanych z kontenerem pamięciowym, działanie kopii zapasowych oraz czas odzyskiwania danych. Dla tabel SCHEMA_ONLY trzeba potwierdzić, że aplikacja potrafi ponownie zapełnić strukturę po uruchomieniu. Prawidłowo zaprojektowana tabela zoptymalizowana pod kątem pamięci jest elementem całego modelu danych, a nie samodzielnym sposobem na usunięcie każdego problemu z wydajnością.