Optimalizace výkonu pomocí technologií v paměti ve službě Azure SQL Database

  • Článek

Platí pro:Azure SQL Database

Technologie v paměti umožňují zlepšit výkon aplikace a potenciálně snížit náklady na databázi.

Kdy používat technologie v paměti

Pomocí technologií v paměti můžete dosáhnout vylepšení výkonu s různými úlohami:

  • Transakční (online transakční zpracování (OLTP)), kde většina požadavků čte nebo aktualizuje menší sadu dat, například operace vytvoření,čtení/aktualizace/odstranění (CRUD).
  • Analýza (online analytické zpracování (OLAP)), kde většina dotazů obsahuje složité výpočty pro účely generování sestav, a také pravidelně naplánované procesy, které provádějí operace načítání (nebo hromadné načítání) a/nebo zapisují změny dat do existujících tabulek. Úlohy OLAP se často aktualizují pravidelně z úloh OLTP.
  • Smíšené (hybridní zpracování transakcí/analytické zpracování (HTAP)), kde se na stejné sadě dat spouští dotazy OLTP i OLAP.

Technologie v paměti mohou zvýšit výkon těchto úloh tím, že uchovávají data, která by se měla zpracovat do paměti, pomocí nativní kompilace dotazů nebo pokročilého zpracování, jako je dávkové zpracování a instrukce SIMD, které jsou k dispozici na podkladovém hardwaru.

Přehled

Azure SQL Database podporuje následující technologie v paměti:

  • OLTP v paměti zvyšuje počet transakcí za sekundu a snižuje latenci zpracování transakcí. Scénáře, které využívají OLTP v paměti, jsou: zpracování transakcí s vysokou propustností, jako je obchodování a hraní her, příjem dat z událostí nebo zařízení IoT, ukládání do mezipaměti, načítání dat a dočasné scénáře tabulek a proměnných tabulek.
  • Clusterované indexy columnstore snižují nároky na úložiště (až 10krát) a zlepšují výkon pro dotazy generování sestav a analýz. Můžete ho použít s tabulkami faktů v datových martech, abyste do databáze vešli více dat a zlepšili výkon. Můžete ho také použít s historickými daty v provozní databázi k archivaci a dotazování až 10krát více dat.
  • Neclusterované indexy columnstore pro protokol HTAP vám pomůžou získat přehledy v reálném čase v reálném čase prostřednictvím přímého dotazování provozní databáze, aniž byste museli spouštět nákladný proces extrakce, transformace a načítání (ETL) a čekat na naplnění datového skladu. Neclusterované indexy columnstore umožňují rychlé spouštění analytických dotazů v databázi OLTP a zároveň snižují dopad na provozní úlohu.
  • Clusterované indexy columnstore optimalizované pro protokol HTAP optimalizované pro paměť umožňují provádět rychlé zpracování transakcí a souběžně spouštět analytické dotazy velmi rychle na stejných datech.

Indexy columnstore a OLTP v paměti byly zavedeny na SQL Server v roce 2012 a 2014. Azure SQL Database, Azure SQL Managed Instance a SQL Server sdílejí stejnou implementaci technologií v paměti.

Poznámka:

Podrobný kurz ukazující výhody technologie OLTP v paměti pomocí AdventureWorksLT ukázkové databáze a ostress.exe najdete v ukázce paměti ve službě Azure SQL Database.

Výhody technologie v paměti

Díky efektivnějšímu zpracování dotazů a transakcí pomáhají technologie v paměti také snížit náklady. Obvykle nemusíte upgradovat cenovou úroveň databáze, abyste dosáhli zvýšení výkonu. V některých případech můžete dokonce snížit cenovou úroveň a zároveň stále dochází ke zlepšení výkonu u technologií v paměti.

Díky použití OLTP v paměti byla obchodní řešení kvora schopná zdvojnásobit své úlohy a současně zvýšit počet DTU o 70 %. Další informace najdete v tématu OLTP v paměti ve službě Azure SQL Database.

Poznámka:

Technologie v paměti jsou k dispozici na úrovních Premium a Pro důležité obchodní informace služby Azure SQL Database.

Tento článek popisuje aspekty indexů OLTP a columnstore v paměti, které jsou specifické pro Službu SQL Database, a obsahuje také ukázky:

  • Uvidíte dopad těchto technologií na omezení velikosti úložiště a dat.
  • Uvidíte, jak spravovat přesun databází, které používají tyto technologie mezi různými cenovými úrovněmi.
  • Uvidíte dva ukázky, které ilustrují použití OLTP v paměti a také indexy columnstore.

Další informace o paměti v SYSTÉMU SQL Server najdete v tématech:

OLTP v paměti

Technologie OLTP v paměti poskytuje extrémně rychlé operace přístupu k datům tím, že uchovává všechna data v paměti. Využívá také specializované indexy, nativní kompilaci dotazů a přístup k datům bez západek za účelem zlepšení výkonu úlohy OLTP. Data OLTP v paměti můžete uspořádat dvěma způsoby:

  • Formát úložiště řádků optimalizovaný pro paměť, kde každý řádek je samostatným objektem paměti. Jedná se o klasický formát OLTP v paměti optimalizovaný pro vysoce výkonné úlohy OLTP. Existují dva typy tabulek optimalizovaných pro paměť, které lze použít ve formátu rowstore optimalizovaného pro paměť:

    • Odolné tabulky (SCHEMA_AND_DATA), kde se po restartování serveru zachovají řádky umístěné v paměti. Tento typ tabulek se chová jako tradiční tabulka rowstore s dalšími výhodami optimalizace v paměti.
    • Nedurable tables (SCHEMA_ONLY), kde se řádky po restartování nezachovají. Tento typ tabulky je určený pro dočasná data (například nahrazení dočasných tabulek) nebo pro tabulky, kde potřebujete rychle načíst data, než je přesunete do některé trvalé tabulky (tzv. pracovní tabulky).

  • Formát columnstore optimalizovaný pro paměť, ve kterém jsou data uspořádaná ve sloupcovém formátu. Tato struktura je určená pro scénáře HTAP, ve kterých potřebujete spouštět analytické dotazy na stejnou datovou strukturu, ve které běží vaše úloha OLTP.

Poznámka:

Technologie OLTP v paměti je určená pro datové struktury, které se můžou plně nacházet v paměti. Vzhledem k tomu, že data v paměti nelze přesměrovat na disk, ujistěte se, že používáte databázi, která má dostatek paměti. Další informace najdete v tématu Velikost dat a limit úložiště pro OLTP v paměti.

Velikost dat a limit úložiště pro OLTP v paměti

OLTP v paměti obsahuje tabulky optimalizované pro paměť, které se používají k ukládání uživatelských dat. Tyto tabulky se musí vejít do paměti. Vzhledem k tomu, že spravujete paměť přímo ve službě SQL Database, máme koncept kvóty pro uživatelská data. Tato myšlenka se označuje jako úložiště OLTP v paměti.

Každá podporovaná cenová úroveň jednoúčelové databáze a každá cenová úroveň elastického fondu zahrnuje určité množství úložiště OLTP v paměti.

Následující položky se počítají do limitu úložiště OLTP v paměti:

  • Řádky aktivních uživatelských dat v tabulkách a proměnných tabulek optimalizovaných pro paměť Staré verze řádků se do limitu nezapočítávají.
  • Indexy v tabulkách optimalizovaných pro paměť.
  • Provozní režie operací ALTER TABLE

Pokud dosáhnete limitu, zobrazí se chyba kvůli překročení kvóty a už nebudete moct vkládat ani aktualizovat data. Pokud chcete tuto chybu zmírnit, odstraňte data nebo zvyšte cenovou úroveň databáze nebo fondu.

Podrobnosti o monitorování využití úložiště OLTP v paměti a konfiguraci upozornění při téměř dosažení limitu najdete v tématu Monitorování úložiště v paměti.

Informace o elastických fondech

S elastickými fondy se úložiště OLTP v paměti sdílí napříč všemi databázemi ve fondu. Proto může využití v jedné databázi potenciálně ovlivnit jiné databáze. Toto jsou dvě omezení rizik:

  • Max-eDTU Nakonfigurujte databáziMaxvCore, která je nižší než počet eDTU nebo počtu virtuálních jader pro fond jako celek. Toto maximální omezení využití úložiště OLTP v paměti v jakékoli databázi ve fondu na velikost, která odpovídá počtu eDTU.
  • Min-eDTU Nakonfigurujte nebo MinvCore je větší než 0. Toto minimum zaručuje, že každá databáze ve fondu má množství dostupného úložiště OLTP v paměti, které odpovídá nakonfigurované Min-eDTU nebo vCore.

Změna úrovní služby databází, které používají technologie OLTP v paměti

Databázi můžete kdykoli upgradovat na vyšší úroveň, například z úrovně Pro obecné účely (virtuální jádro) na Pro důležité obchodní informace nebo Standard (DTU) na Premium. Dostupné funkce a prostředky se pouze zvyšují.

Downgrad úrovně ale může negativně ovlivnit vaši databázi. Dopad je zvlášť patrné, když downgradujete z Pro důležité obchodní informace na úroveň Pro obecné účely (nebo Premium na Standard nebo Basic), pokud databáze obsahuje objekty OLTP v paměti. V databázi můžete snadno najít objekty v paměti.

Tabulky optimalizované pro paměť jsou po downgradu nedostupné (i když zůstanou viditelné). Stejné aspekty platí, když snižujete cenovou úroveň elastického fondu nebo přesouváte databázi s technologiemi v paměti do elastického fondu pro obecné účely, Standard nebo Basic.

Důležité

OLTP v paměti se nepodporuje ve vrstvách Pro obecné účely ani Úrovně DTU úrovně Standard nebo Basic služby Azure SQL Database. Proto není možné přesunout databázi, která obsahuje žádné objekty OLTP v paměti do jedné z těchto úrovní. Před downgradem databáze odeberte všechny tabulky a typy tabulek optimalizovaných pro paměť a všechny nativně kompilované moduly T-SQL nebo je převeďte na objekty založené na řádcích.

Škálování prostředků na úrovni Pro důležité obchodní informace: Data v tabulkách optimalizovaných pro paměť se musí vejít do úložiště OLTP v paměti, které je přidružené k úrovni databáze, nebo je k dispozici v elastickém fondu. Pokud se pokusíte vertikálně snížit kapacitu vrstvy nebo přesunout databázi do fondu, který nemá dostatek dostupného úložiště OLTP v paměti, operace selže.

Určení, jestli existují objekty v paměti

Existuje programový způsob, jak zjistit, jestli daná databáze podporuje OLTP v paměti. Můžete spustit následující dotaz Jazyka Transact-SQL:

SELECT DatabasePropertyEx(DB_NAME(), 'IsXTPSupported');

Pokud dotaz vrátí 1, v této databázi se podporuje OLTP v paměti.

Následující dotazy identifikují všechny objekty, které je potřeba odebrat, aby bylo možné databázi downgradovat na úroveň Pro obecné účely, Standard nebo Basic:

SELECT * FROM sys.tables WHERE is_memory_optimized=1
SELECT * FROM sys.table_types WHERE is_memory_optimized=1
SELECT * FROM sys.sql_modules WHERE uses_native_compilation=1

Úložiště sloupců v paměti

Technologie columnstore v paměti umožňuje ukládat a dotazovat velké množství dat v tabulkách. Technologie Columnstore využívá formát úložiště dat založený na sloupcích a dávkové zpracování dotazů k dosažení až 10krát vyššího výkonu dotazů v úlohách OLAP oproti tradičnímu úložišti orientovanému na řádky. Můžete také dosáhnout až 10krát větší komprese dat než v případě nekomprimovaných dat.

Existují dva typy modelů columnstore, které můžete použít k uspořádání dat:

  • Clusterovaný columnstore , kde jsou všechna data v tabulce uspořádaná ve sloupcovém formátu. V tomto modelu jsou všechny řádky v tabulce umístěny ve sloupcovém formátu, které vysoce komprimují data a umožňují spouštět rychlé analytické dotazy a sestavy v tabulce. V závislosti na povaze dat se velikost dat může zmenšit o 10x-100x. Clusterovaný model columnstore také umožňuje rychlý příjem velkých objemů dat (hromadné načtení), protože velké dávky dat větší než 100 000 řádků jsou před uložením na disku komprimovány. Tento model je dobrou volbou pro scénáře klasického datového skladu.
  • Neskupené columnstore , kde jsou data uložená v tradiční tabulce rowstore a ve formátu columnstore je index, který se používá pro analytické dotazy. Tento model umožňuje hybridní transakční zpracování (HTAP): schopnost spouštět výkonnou analýzu transakční úlohy v reálném čase. Dotazy OLTP se spouští v tabulce rowstore, která je optimalizovaná pro přístup k malé sadě řádků, zatímco dotazy OLAP se spouští na indexu columnstore, který je lepší volbou pro prohledávání a analýzu. Optimalizátor dotazů dynamicky vybírá na základě dotazu formát rowstore nebo columnstore. Neclusterované indexy columnstore nezmenšují velikost dat, protože původní sada dat se uchovává v původní tabulce rowstore beze změny. Velikost dalšího indexu columnstore by ale měla mít velikost menší než ekvivalentní index B-tree.

Poznámka:

Technologie columnstore v paměti uchovává pouze data potřebná ke zpracování v paměti, zatímco data, která se do paměti nevejdou, se ukládají na disk. Proto množství dat ve strukturách columnstore v paměti může překročit množství dostupné paměti.

Velikost dat a úložiště pro indexy columnstore

Indexy columnstore se nevyžadují, aby se vešly do paměti. Jediným limitem velikosti indexů je proto maximální celková velikost databáze, která je zdokumentovaná v nákupním modelu založeném na DTU a článcích nákupních modelů založených na virtuálních jádrech.

Pokud používáte clusterované indexy columnstore, použije se pro úložiště základní tabulky sloupcová komprese. Tato komprese může výrazně snížit nároky na úložiště uživatelských dat, což znamená, že do databáze můžete umístit více dat. A kompresi lze dále zvýšit pomocí sloupcové archivační komprese. Množství komprese, které můžete dosáhnout, závisí na povaze dat, ale 10krát není komprese neobvyklá.

Pokud máte například databázi s maximální velikostí 1 terabajtu (TB) a 10násobkem komprese pomocí indexů columnstore, můžete do databáze umístit celkem 10 TB uživatelských dat.

Pokud používáte neclusterované indexy columnstore, základní tabulka je stále uložena v tradičním formátu rowstore. Úspory úložiště proto nejsou tak významné jako u clusterovaných indexů columnstore. Pokud ale nahrazujete mnoho tradičních neclusterovaných indexů jediným indexem columnstore, můžete stále vidět celkové úspory v úložišti pro tabulku.

Změna úrovní služby databází obsahujících indexy columnstore

Downgradování izolované databáze na Úroveň Basic nebo Standard nemusí být možné, pokud je cílová úroveň nižší než S3. Indexy columnstore se podporují jenom na cenové úrovni Pro důležité obchodní informace/Premium a na úrovni Standard, S3 a vyšší, a ne na úrovni Basic. Když databázi downgradujete na nepodporovanou úroveň nebo úroveň, index columnstore přestane být dostupný. Systém udržuje index columnstore, ale index nikdy nepoužívá. Pokud později upgradujete zpět na podporovanou úroveň nebo úroveň, index columnstore je okamžitě připravený k opětovnému použití.

Pokud máte clusterovaný index columnstore, po downgradu se celá tabulka stane nedostupnou. Před downgradem databáze na nepodporovanou vrstvu nebo úroveň odstraňte všechny clusterované indexy columnstore (a nahraďte je clusterovanými indexy rowstore).

Související obsah