Úvod do tabulek Memory-Optimized

Platí pro:SQL ServerAzure SQL DatabaseSpravovaná instance Azure SQL

Tabulky optimalizované pro paměť se vytvářejí pomocí metody CREATE TABLE (Transact-SQL).

Tabulky optimalizované pro paměť jsou ve výchozím nastavení plně odolné a podobně jako transakce na (tradičních) tabulkách založených na disku jsou transakce v tabulkách optimalizovaných pro paměť plně atomické, konzistentní, izolované a odolné (ACID). Tabulky optimalizované pro paměť a nativně zkompilované uložené procedury podporují pouze podmnožinu funkcí Transact-SQL.

Počínaje SQL Serverem 2016 a v Azure SQL Database neexistují žádná omezení pro kolace nebo kódové stránky , které jsou specifické pro In-Memory OLTP.

Primární úložiště pro tabulky optimalizované pro paměť je hlavní paměť. Řádky v tabulce se čtou a zapisují do paměti. Druhá kopie dat tabulky se udržuje na disku, ale pouze pro účely stálosti. Další informace o trvalých tabulkách najdete v tématu Vytváření a správa úložiště pro objekty Memory-Optimized . Data v tabulkách optimalizovaných pro paměť se během obnovení databáze čtou jenom z disku (například po restartování serveru).

Pro ještě větší zvýšení výkonu podporuje In-Memory OLTP trvalé tabulky se zpožděnou odolností transakcí. Opožděné trvalé transakce se uloží na disk brzy po potvrzení transakce a kontrola se vrátí klientovi. Výměnou za zvýšení výkonu jsou potvrzené transakce, které nejsou uchovány na disku, ztraceny při havárii serveru nebo přepnutí na zálohu.

Kromě výchozích tabulek optimalizovaných pro trvanlivou paměť podporuje SQL Server také netrvanlivé paměťově optimalizované tabulky, které nejsou protokolovány a jejichž data se neukládají na disku. To znamená, že transakce v těchto tabulkách nevyžadují diskové operace, ale data se ztratí, pokud dojde k chybě serveru nebo přepnutí na záložní server.

In-Memory OLTP je integrovaný s SQL Serverem, který poskytuje bezproblémové prostředí ve všech oblastech, jako je vývoj, nasazení, spravovatelnost a možnosti podpory. Databáze může obsahovat v paměti i diskové objekty.

Řádky v tabulkách optimalizovaných pro paměť jsou verzované. To znamená, že každý řádek v tabulce může mít více verzí. Všechny verze řádků jsou zachovány ve stejné datové struktuře tabulky. Správa verzí řádků slouží k povolení souběžných čtení a zápisů na stejném řádku. Další informace o souběžných čtení a zápisech na stejném řádku naleznete v tématu Transakce s Memory-Optimized Tabulky.

Následující obrázek znázorňuje více verzí. Obrázek znázorňuje tabulku se třemi řádky a každý řádek má různé verze.

Tabulka má tři řádky: r1, r2 a r3. R1 má tři verze, r2 má dvě verze a r3 má čtyři verze. Různé verze stejného řádku nemusí nutně zabírat po sobě jdoucí umístění paměti. Různé verze řádků mohou být rozptýleny v celé datové struktuře tabulky.

Datovou strukturu tabulky optimalizovanou pro paměť lze považovat za kolekci verzí řádků. Řádky v tabulkách založených na disku jsou uspořádané na stránkách a rozsahech a jednotlivé řádky jsou adresovány pomocí čísla stránky a offsetu stránky; zatímco verze řádků v tabulkách optimalizovaných pro paměť jsou adresovány pomocí 8bajtových ukazatelů paměti.

Data v tabulkách optimalizovaných pro paměť jsou přístupná dvěma způsoby:

• Prostřednictvím nativně zkompilovaných uložených procedur.

• Prostřednictvím interpretovaného jazyka Transact-SQL mimo nativně zkompilovanou uloženou proceduru. Tyto Transact-SQL příkazy můžou být buď uvnitř interpretovaných uložených procedur, nebo můžou být ad hoc Transact-SQL příkazy.

Přístup k datům v tabulkách Memory-Optimized

K tabulkám optimalizovaným pro paměť je možné přistupovat nejefektivněji z nativních zkompilovaných uložených procedur (nativně zkompilované uložené procedury). K tabulkám optimalizovaným pro paměť je také možné přistupovat pomocí (tradiční) interpretované transact-SQL. Interpretované Transact-SQL odkazuje na přístup k tabulkám optimalizovaným pro paměť bez nativně zkompilované uložené procedury. Mezi příklady interpretovaných Transact-SQL přístupu patří přístup k tabulce optimalizované pro paměť z triggeru DML, ad hoc Transact-SQL dávkové, zobrazení a funkce s hodnotou tabulky.

Následující tabulka shrnuje nativní a interpretovaný Transact-SQL přístup k různým objektům.

Vlastnost	Přístup pomocí nativně zkompilované uložené procedury	Interpretovaný přístup Transact-SQL	Přístup CLR
Tabulka optimalizovaná pro paměť	Ano	Ano	č. 1
Typ tabulky optimalizovaný pro paměť	Ano	Ano	Ne
Nativně zkompilovaná uložená procedura	Vnoření nativně zkompilovaných uložených procedur je nyní podporováno. Syntaxi EXECUTE můžete použít uvnitř uložených procedur, pokud je odkazovaná procedura také nativně zkompilována.	Ano	Ne*

¹Nemůžete získat přístup k tabulce optimalizované pro paměť nebo nativně zkompilovanou uloženou proceduru z kontextového připojení (připojení z SQL Serveru při provádění modulu CLR). Můžete ale vytvořit a otevřít další připojení, ze kterého můžete přistupovat k tabulkám optimalizovaným pro paměť a nativně zkompilovaným uloženým procedurům.

Citlivá data v tabulkách optimalizovaných pro paměť je možné chránit pomocí funkce Always Encrypted. Platí následující omezení:

• Pokud používáte funkci Always Encrypted se zabezpečenými enklávami, použití klíčů s podporou enklávy pro sloupce v tabulkách optimalizovaných pro paměť se nepodporuje. To znamená, že místní šifrování se nedá použít a počáteční šifrování se provádí v klientovi.
• Funkce Always Encrypted není podporována pro žádný sloupec v tabulce optimalizované pro paměť, pokud se na tabulku odkazuje v nativně zkompilovaném modulu.

Výkon a škálovatelnost

Následující faktory ovlivňují zvýšení výkonu, které lze dosáhnout pomocí In-Memory OLTP:

Komunikace: Aplikace využívající mnoho krátkých volání uložených procedur může v porovnání s aplikací s menším počtem volání a více funkcí implementovaných v každé uložené proceduře vidět menší zvýšení výkonu.

Transact-SQL Provádění: In-Memory OLTP dosahuje nejlepšího výkonu při použití nativně kompilovaných uložených procedur, nikoli interpretovaných uložených procedur nebo provádění dotazů. Přístup k tabulkám optimalizovaným pro paměť z těchto uložených procedur může být výhodou.

Skenování rozsahu vs. bodové vyhledávání: Indexy optimalizované pro paměť, které nejsou seskupené, podporují skenování rozsahu a seřazené skeny. Pro vyhledávání bodů mají indexy hash optimalizované pro paměť lepší výkon než neclusterované indexy optimalizované pro paměť. Neclusterované indexy optimalizované pro paměť mají lepší výkon než diskové indexy.

• Počínaje SQL Serverem 2016 může plán dotazu pro tabulku optimalizovanou pro paměť prohledávat tabulku paralelně. Tím se zlepší výkon analytických dotazů.
  • Indexy hash se také paralelně dají prohledávat v SQL Serveru 2016.
  • Neclusterované indexy byly také paralelně prohledávatelné v SQL Serveru 2016.

Operace indexu: Operace indexu nejsou protokolovány a existují pouze v paměti.

Souběžnost: Aplikace, jejichž výkon je ovlivněn souběžností na úrovni databázového stroje, jako je kolize západek nebo blokování, se výrazně zlepšuje, když se aplikace přesune na In-Memory OLTP.

Následující tabulka uvádí problémy s výkonem a škálovatelností, které se běžně vyskytují v relačních databázích a jak In-Memory OLTP může zlepšit výkon.

Problém	In-Memory dopad OLTP
Výkon Vysoké využití prostředků (využití procesoru, vstupně-výstupních operací, sítě nebo paměti).	centrální procesorová jednotka (CPU) Nativně kompilované uložené procedury můžou výrazně snížit využití procesoru, protože k provedení příkazu Transact-SQL v porovnání s interpretovanými uloženými procedurami vyžadují méně instrukcí. In-Memory OLTP může pomoct snížit investice do hardwaru ve škálovaných úlohách, protože jeden server může potenciálně zajistit propustnost více serverů. Vstup/Výstup Pokud narazíte na úzké místo ve vstupně-výstupních operacích při zpracování dat nebo indexových stránek, In-Memory OLTP může toto úzké místo snížit. Kontrolní body In-Memory objektů OLTP jsou navíc průběžné a nevedou k náhlému nárůstu vstupně-výstupních operací. Pokud se ale pracovní sada kritických tabulek výkonu nevejde do paměti, In-Memory OLTP se nepoužije, protože vyžaduje, aby data byla rezidentní v paměti. Pokud při protokolování narazíte na úzké hrdlo I/O, In-Memory OLTP může toto úzké hrdlo redukovat, protože zmenšuje množství protokolování. Pokud je jedna nebo více tabulek optimalizovaných pro paměť nakonfigurované jako nestálé tabulky, můžete eliminovat protokolování dat. Paměť In-Memory OLTP nenabízí žádné výhody výkonu. In-Memory OLTP může vyvíjet dodatečný tlak na paměť, protože objekty musí být rezidentní v paměti. Síť In-Memory OLTP nenabízí žádné výhody výkonu. Data je potřeba předávat z datové vrstvy do aplikační vrstvy.
Škálovatelnost Většina problémů se škálováním v aplikacích SQL Serveru je způsobena problémy se souběžností, jako jsou kolize při používání zámků, západek a spinlocků.	Soutěžení o zámky Typickým scénářem je kolize na poslední stránce indexu při souběžné vkládání řádků v pořadí klíčů. Vzhledem k tomu, že In-Memory OLTP při přístupu k datům nevyužívá západky, problémy se škálovatelností související se souběhy západek jsou zcela odstraněny. Obsazenost spinlocku Vzhledem k tomu, že In-Memory OLTP při přístupu k datům nepoužívá zámky, problématika škálovatelnosti související s konflikty spinlocku je plně odstraněna. Uzamčení souvisejících kolizí Pokud vaše databázová aplikace narazí na problémy s blokováním mezi operacemi čtení a zápisu, In-Memory OLTP odebere blokující problémy, protože k implementaci všech úrovní izolace transakcí používá novou formu řízení optimistické souběžnosti. In-Memory OLTP nepoužívá databázi TempDB k ukládání verzí řádků. Pokud problém se škálováním způsobuje konflikt mezi dvěma operacemi zápisu, například dvěma souběžnými transakcemi, které se pokoušejí aktualizovat stejný řádek, In-Memory OLTP umožní jedné transakci proběhnout úspěšně a druhou ukončí selháním. Neúspěšná transakce se musí znovu odeslat explicitně nebo implicitně a opakovat transakci. V obou případech musíte v aplikaci provést změny. Pokud u vaší aplikace dochází k častým konfliktům mezi dvěma operacemi zápisu, sníží se hodnota optimistického uzamčení. Aplikace není vhodná pro In-Memory OLTP. Většina aplikací OLTP nemá konflikty zápisu, pokud konflikt není výsledkem eskalace zámku.

zabezpečení Row-Level v tabulkách Memory-Optimized

Row-Level Zabezpečení je podporováno v tabulkách optimalizovaných pro paměť. Použití zásad zabezpečení Row-Level pro tabulky optimalizované pro paměť je v podstatě stejné jako tabulky založené na disku, s tím rozdílem, že vložené funkce hodnotné tabulkou používané jako predikáty zabezpečení musí být nativně zkompilovány (vytvořené pomocí možnosti WITH NATIVE_COMPILATION). Podrobnosti najdete v části Kompatibilita mezi funkcemi v tématu zabezpečeníRow-Level .

Pro tabulky optimalizované pro paměť jsou k dispozici různé integrované funkce zabezpečení, které jsou nezbytné pro zabezpečení na úrovni řádků. Podrobnosti najdete v tématu Předdefinované funkce v nativně kompilovaných modulech.

EXECUTE AS CALLER – Všechny nativní moduly teď ve výchozím nastavení podporují a používají funkci EXECUTE AS CALLER, i když není zadána nápověda. Důvodem je to, že se očekává, že všechny funkce zabezpečení na úrovni řádků používají funkci EXECUTE AS CALLER, aby funkce a všechny předdefinované funkce, které se v něm používají, byly vyhodnoceny v kontextu volajícího uživatele.
Funkce EXECUTE AS CALLER má malý dopad na výkon (přibližně 10%) způsobený kontrolami oprávnění volajícího. Pokud modul explicitně určí EXECUTE AS OWNER nebo EXECUTE AS SELF, je možné se vyhnout těmto kontrolám oprávnění a s nimi spojeným nákladům na výkon. Použití některé z těchto možností společně se zmíněnými integrovanými funkcemi však způsobuje vyšší výkon z důvodu nezbytného přepínání kontextu.

Scénáře

Stručný přehled typických scénářů, kdy In-Memory OLTP může zlepšit výkon, najdete v tématuIn-Memory OLTP.

Viz také

In-Memory OLTP (optimalizaceIn-Memory)