Tabele zoptymalizowane pod kątem pamięci - czy naprawdę mogą być tak trudne w utrzymaniu?

Badam zalety aktualizacji z MS SQL 2012 do 2014. Jednym z głównych punktów sprzedaży SQL 2014 są tabele zoptymalizowane pod kątem pamięci, które najwyraźniej sprawiają, że zapytania są superszybkie.

Odkryłem, że istnieje kilka ograniczeń dotyczących tabel zoptymalizowanych pod względem pamięci, takich jak:

• Brak (max)wielkości pól
• Maksymalnie ~ 1 KB na wiersz
• Brak timestamppól
• Brak wyliczonych kolumn
• Bez UNIQUEograniczeń

Wszystkie te kwalifikują się jako uciążliwości, ale jeśli naprawdę chcę je obejść w celu uzyskania korzyści w zakresie wydajności, mogę opracować plan.

Prawdziwym kickerem jest fakt, że nie można uruchomić ALTER TABLEinstrukcji i musisz przejść przez ten rygor za każdym razem, gdy dodajesz pole do INCLUDElisty indeksu. Co więcej, wydaje się, że musisz wyłączyć użytkowników z systemu, aby dokonać zmian schematu w tabelach MO w aktywnej bazie danych.

Uważam to za całkowicie oburzające do tego stopnia, że ​​w rzeczywistości nie mogę uwierzyć, że Microsoft mógł zainwestować tyle kapitału na rozwój w tę funkcję, i pozostawienie jej tak niepraktycznej w utrzymaniu. To prowadzi mnie do wniosku, że musiałem mieć niewłaściwy koniec kija; Musiałem źle zrozumieć coś o tabelach zoptymalizowanych pod kątem pamięci, co skłoniło mnie do przekonania, że ​​ich utrzymanie jest o wiele trudniejsze niż w rzeczywistości.

Co więc źle zrozumiałem? Czy korzystałeś już z tabel MO? Czy istnieje jakiś tajny przełącznik lub proces, który czyni je praktycznymi w użyciu i utrzymaniu?

Nie, pamięć naprawdę nie jest dopracowana. Jeśli znasz Agile, poznasz koncepcję „minimalnego produktu do wysyłki”; to jest w pamięci. Mam wrażenie, że stwardnienie rozsiane potrzebowało odpowiedzi na SAP Hana i jej podobne. To właśnie mogli debugować w ramach czasowych wydania 2014.

Podobnie jak w przypadku wszystkich innych elementów w pamięci, wiążą się z tym koszty i korzyści. Główną korzyścią jest przepustowość, którą można osiągnąć. Jak wspomniałeś, jednym z kosztów jest narzut związany z zarządzaniem zmianami. To nie czyni go bezużytecznym produktem, moim zdaniem, po prostu zmniejsza liczbę przypadków, w których zapewni korzyść netto. Tak jak indeksy magazynu kolumn można teraz aktualizować, a indeksy można filtrować, nie mam wątpliwości, że funkcjonalność w pamięci poprawi się w kolejnych wydaniach.

SQL Server 2016 jest teraz ogólnie dostępny. Tak jak przypuszczałem, OLTP w pamięci otrzymał szereg ulepszeń. Większość zmian wprowadza funkcjonalność, z której tradycyjne tabele korzystają od pewnego czasu. Domyślam się, że przyszłe funkcje zostaną wydane jednocześnie dla tabel w pamięci i tradycyjnych. Tabele czasowe są przykładem. Nowość w tej wersji jest obsługiwana zarówno przez tabele w pamięci, jak i dyskowe .

Jednym z problemów związanych z nową technologią - zwłaszcza wersją V1, która została ujawniona dość głośno jako niekompletna - jest to, że wszyscy wskakują na modę i zakładają, że idealnie pasuje do każdego obciążenia. To nie jest. Słabym punktem Hekaton jest obciążenie OLTP poniżej 256 GB z dużą ilością punktów wyszukiwania na 2-4 gniazdach. Czy to odpowiada twojemu obciążeniu?

Wiele ograniczeń dotyczy tabel w pamięci połączonych z natywnie skompilowanymi procedurami. Możesz oczywiście ominąć niektóre z tych ograniczeń, używając tabel w pamięci, ale nie stosując natywnie skompilowanych procedur, a przynajmniej nie wyłącznie.

Oczywiście musisz sprawdzić, czy wzrost wydajności jest znaczący w twoim środowisku, a jeśli tak, to czy kompromisy są tego warte. Jeśli uzyskujesz wielki wzrost wydajności dzięki tabelom w pamięci, nie jestem pewien, dlaczego martwisz się, ile konserwacji będziesz wykonywać na kolumnach INCLUDE. Twoje indeksy w pamięci obejmują z definicji. Powinny one być naprawdę pomocne tylko w celu uniknięcia przeszukiwania zasięgu lub pełnego skanowania tradycyjnych indeksów nieklastrowych, a operacje te raczej nie powinny mieć miejsca w tabelach w pamięci (ponownie, należy sprofilować obciążenie pracą i zobaczyć, które operacje poprawiają a które nie - nie wszystkie wygrane-wygrane). Jak często marszczysz dziś kolumny INCLUDE w swoich indeksach?

Zasadniczo, jeśli nie jest to dla ciebie jeszcze warte w formie V1, nie używaj go. Nie jest to pytanie, na które możemy odpowiedzieć, z wyjątkiem tego, aby powiedzieć, że wielu klientów jest gotowych żyć z ograniczeniami i mimo to korzysta z tej funkcji, aby z nich skorzystać.

SQL Server 2016

Jeśli jesteś w drodze do SQL Server 2016, napisałem na blogu o ulepszeniach, które zobaczysz w OLTP w pamięci, a także o wyeliminowaniu niektórych ograniczeń . W szczególności:

• Zwiększenie maksymalnego trwałego rozmiaru stołu: 256 GB => 2 TB
• Kolumny LOB / MAX, indeksy na kolumnach zerowalnych, usunięcie wymagań zestawiania BIN2
• Zmień i ponownie skompiluj procedury
• Niektóre wsparcie dla ALTER TABLE - będzie offline, ale powinieneś być w stanie zmieniać i / lub upuszczać / odtwarzać indeksy (nie wydaje się to jednak obsługiwane w obecnych kompilacjach CTP, więc nie bierz tego jako gwarancji)
• Wyzwalacze DML, ograniczenia FK / sprawdź, MARS
• LUB NIE, WEJŚCIE, ISTNIEJE, WYRÓŻNIAJĄ, UNIA, ŁĄCZA ZEWNĘTRZNE
• Równoległość

Nie można kliknąć prawym przyciskiem myszy tabeli zoptymalizowanej pod kątem pamięci, aby pobrać projektanta i dodać nowe kolumny według własnego uznania z poziomu Sql Server Management Studio. Nie można również kliknąć nazwy tabeli w celu zmiany nazwy tabeli. (SQL 2014 w momencie pisania tego.)

Zamiast tego możesz kliknąć tabelę prawym przyciskiem myszy i wypisać polecenie tworzenia w nowym oknie zapytania. To polecenie tworzenia można zmienić, dodając dowolne nowe kolumny.

Tak więc, aby zmodyfikować tabelę, możesz przechowywać dane w nowej tabeli, tabeli tymczasowej lub zmiennej tabeli. Następnie możesz upuścić i ponownie utworzyć tabelę z nowym schematem, a na koniec skopiować z powrotem rzeczywiste dane . Ta gra z 3 pojemnikami jest tylko trochę mniej wygodna w większości przypadków.

Ale nie byłoby powodu, aby zawracać sobie głowę tabelami zoptymalizowanymi pod kątem pamięci, jeśli nie występuje problem z wydajnością, który próbujesz rozwiązać.

Następnie musisz rozważyć, czy ograniczenia i obejścia są tego warte w twoim przypadku użycia. Czy masz problem z wydajnością? Próbowałeś już wszystkiego innego? Czy poprawi to twoją wydajność o 10-100x? Używanie go lub nieużywanie go prawdopodobnie nie będzie wcale bez sensu.

możesz używać OLTP w pamięci w serwerach operacyjnych bez większego problemu. zastosowaliśmy tę technologię w firmie bankowo-płatniczej,

Zasadniczo możemy używać tabel zoptymalizowanych pod kątem pamięci, gdy obciążenie jest zbyt duże. dzięki zastosowaniu OLTP w pamięci możesz osiągnąć lepszą wydajność do 30X! Microsoft poprawia większość tych ograniczeń w SQL Server 2016 i 2017. tabele zoptymalizowane pod kątem pamięci mają zupełnie inną architekturę niż tabele oparte na dyskach.

tabele zoptymalizowane pod kątem pamięci są dwoma typami. trwałe stoły i niestabilne stoły. Trwałe i nietrwałe tabele utrzymują dane w tabeli przechowywane w pamięci. Trwałe tabele utrwalają dane na dyskach dla danych odzyskiwania i schematu. w większości scenariuszy operacyjnych powinniśmy stosować trwałe tabele, ponieważ utrata danych ma tutaj kluczowe znaczenie. w niektórych scenariuszach, na przykład ładowanie ETL i buforowanie, możemy użyć tabel nietrwałych.

możesz skorzystać z tych ebooków i nauczyć się korzystać z tej technologii:

Kalen Delaney: https://www.red-gate.com/library/sql-server-internals-in-memory-oltp

Dmitri Korotkevitch: https://www.apress.com/gp/book/9781484227718