Ukázka v paměti ve službě Azure SQL Database
Platí pro: Azure SQL Database
Technologie v paměti ve službě Azure SQL Database umožňují zlepšit výkon aplikace a potenciálně snížit náklady na vaši databázi. Pomocí technologií v paměti ve službě Azure SQL Database můžete dosáhnout vylepšení výkonu s různými úlohami.
Dva ukázky v tomto článku ilustrují použití OLTP v paměti i indexů columnstore ve službě Azure SQL Database.
Další informace naleznete v tématu:
- Scénáře použití OLTP v paměti (včetně odkazů na případové studie zákazníků a informace, které vám pomůžou začít)
- Dokumentace k OLTP v paměti
- Průvodce indexy columnstore
- Hybridní transakční/analytické zpracování (HTAP), označované také jako provozní analýzy v reálném čase
Úvodní ukázku OLTP v paměti najdete tady:
- Verze: in-memory-oltp-demo-v1.0
- Zdrojový kód: in-memory-oltp-demo-source-code
1. Instalace ukázky OLTP v paměti
Ukázkovou AdventureWorksLT
databázi můžete vytvořit několika kroky na webu Azure Portal. Potom pomocí kroků v této části přidejte do databáze objekty AdventureWorksLT
OLTP v paměti a předveďte výhody výkonu.
Instalační kroky
Na webu Azure Portal vytvořte na logickém serveru databázi Premium (DTU) nebo Pro důležité obchodní informace (virtuální jádra). Nastavte zdroj na ukázkovou
AdventureWorksLT
databázi. Podrobné pokyny najdete v tématu Vytvoření první databáze ve službě Azure SQL Database.Připojte se k databázi pomocí aplikace SQL Server Management Studio (SSMS).
Zkopírujte do schránky skript OLTP Transact-SQL v paměti. Skript T-SQL vytvoří potřebné objekty v paměti v
AdventureWorksLT
ukázkové databázi, kterou jste vytvořili v kroku 1.Vložte skript T-SQL do aplikace SSMS a spusťte skript. Klauzule
MEMORY_OPTIMIZED = ON
vCREATE TABLE
příkazech je zásadní. Příklad:CREATE TABLE [SalesLT].[SalesOrderHeader_inmem]( [SalesOrderID] int IDENTITY NOT NULL PRIMARY KEY NONCLUSTERED ..., ... ) WITH (MEMORY_OPTIMIZED = ON);
Chyba 40536
Pokud při spuštění skriptu T-SQL dojde k chybě 40536, spusťte následující skript T-SQL a ověřte, jestli databáze podporuje objekty v paměti:
SELECT DATABASEPROPERTYEX(DB_NAME(), 'IsXTPSupported');
Výsledek 0
znamená, že OLTP v paměti není podporovaný a 1
znamená, že se podporuje. OLTP v paměti je k dispozici ve vrstvách Azure SQL Database Premium (DTU) a Pro důležité obchodní informace (vCore).
Informace o vytvořených položkách optimalizovaných pro paměť
Tabulky: Ukázka obsahuje následující tabulky optimalizované pro paměť:
SalesLT.Product_inmem
SalesLT.SalesOrderHeader_inmem
SalesLT.SalesOrderDetail_inmem
Demo.DemoSalesOrderHeaderSeed
Demo.DemoSalesOrderDetailSeed
V nástroji SSMS můžete filtrovat zobrazení pouze tabulek optimalizovaných pro paměť v Průzkumník objektů. Když kliknete pravým tlačítkem myši na Tabulky, přejděte na>> Nastavení>filtru je Optimalizováno pro paměť. Hodnota se 1
rovná .
Nebo můžete dotazovat zobrazení katalogu, například:
SELECT is_memory_optimized, name, type_desc, durability_desc
FROM sys.tables
WHERE is_memory_optimized = 1;
Nativně zkompilovaná uložená procedura: Můžete zkontrolovat SalesLT.usp_InsertSalesOrder_inmem
prostřednictvím dotazu zobrazení katalogu:
SELECT uses_native_compilation, OBJECT_NAME(object_id) AS module_name, definition
FROM sys.sql_modules
WHERE uses_native_compilation = 1;
2. Spuštění ukázkové úlohy OLTP
Jediným rozdílem mezi následujícími dvěma uloženými procedurami je, že první procedura používá tabulky optimalizované pro paměť, zatímco druhý postup používá běžné tabulky na disku:
SalesLT.usp_InsertSalesOrder_inmem
SalesLT.usp_InsertSalesOrder_ondisk
V této části se dozvíte, jak pomocí ostress.exe
nástroje spustit dvě uložené procedury. Můžete porovnat, jak dlouho trvá dokončení těchto dvou zátěžových běhů.
Instalace nástrojů A ostress RML
Pokud možno, měli byste běžet ostress.exe
na virtuálním počítači Azure. Virtuální počítač Azure byste vytvořili ve stejné oblasti Azure , ve které se nachází vaše AdventureWorksLT
databáze. Místo toho můžete spustit ostress.exe
na místním počítači, pokud se můžete připojit ke své databázi Azure SQL. Latence sítě mezi vaším počítačem a databází v Azure ale může snížit výhody OLTP v paměti.
Na virtuálním počítači nebo na libovolném hostiteli, který zvolíte, nainstalujte nástroje RML (Replay Markup Language). Nástroje zahrnují ostress.exe
.
Další informace naleznete v tématu:
- Diskuze
ostress.exe
v ukázkové databázi OLTP v paměti. - Ukázková databáze pro OLTP v paměti
Skript pro ostress.exe
V této části se zobrazí skript T-SQL, který je vložený do příkazového ostress.exe
řádku. Skript používá položky vytvořené skriptem T-SQL, který jste nainstalovali dříve.
Při spuštění ostress.exe
doporučujeme předat hodnoty parametrů navržené tak, aby zátěž zatížení používaly obě následující strategie:
- Spuštění velkého počtu souběžných připojení pomocí .
-n100
- Každou připojení opakujte stovkykrát pomocí .
-r500
Možná ale budete chtít začít s mnohem menšími hodnotami -n10
a -r50
zajistit, aby všechno fungovalo.
Následující skript vloží ukázkovou prodejní objednávku s pěti řádkovými položkami do následujících tabulek optimalizovaných pro paměť:
SalesLT.SalesOrderHeader_inmem
SalesLT.SalesOrderDetail_inmem
DECLARE
@i int = 0,
@od SalesLT.SalesOrderDetailType_inmem,
@SalesOrderID int,
@DueDate datetime2 = sysdatetime(),
@CustomerID int = rand() * 8000,
@BillToAddressID int = rand() * 10000,
@ShipToAddressID int = rand() * 10000;
INSERT INTO @od
SELECT OrderQty, ProductID
FROM Demo.DemoSalesOrderDetailSeed
WHERE OrderID= cast((rand()*60) as int);
WHILE (@i < 20)
BEGIN;
EXECUTE SalesLT.usp_InsertSalesOrder_inmem @SalesOrderID OUTPUT,
@DueDate, @CustomerID, @BillToAddressID, @ShipToAddressID, @od;
SET @i = @i + 1;
END
Chcete-li nastavit _ondisk verzi předchozího skriptu T-SQL pro ostress.exe
, nahradíte oba výskyty podřetězece _inmem _ondisk. Tyto nahrazení ovlivňují názvy tabulek a uložených procedur.
Nejprve spusťte _inmem zátěžové úlohy.
Ke spuštění ostress.exe
můžete použít okno příkazového řádku RML . Parametry příkazového řádku směrují ostress na:
- Souběžně spusťte 100 připojení (-n100).
- Nechte každé připojení spustit skript T-SQL 50krát (-r50).
ostress.exe -n100 -r50 -S<servername>.database.windows.net -U<login> -P<password> -d<database> -q -Q"DECLARE @i int = 0, @od SalesLT.SalesOrderDetailType_inmem, @SalesOrderID int, @DueDate datetime2 = sysdatetime(), @CustomerID int = rand() * 8000, @BillToAddressID int = rand() * 10000, @ShipToAddressID int = rand()* 10000; INSERT INTO @od SELECT OrderQty, ProductID FROM Demo.DemoSalesOrderDetailSeed WHERE OrderID= cast((rand()*60) as int); WHILE (@i < 20) begin; EXECUTE SalesLT.usp_InsertSalesOrder_inmem @SalesOrderID OUTPUT, @DueDate, @CustomerID, @BillToAddressID, @ShipToAddressID, @od; set @i += 1; end"
Spuštění předchozího příkazového ostress.exe
řádku:
Obnovte obsah dat databáze spuštěním následujícího příkazu v nástroji SSMS, abyste odstranili všechna data vložená všemi předchozími spuštěními:
EXECUTE Demo.usp_DemoReset;
Zkopírujte text předchozího
ostress.exe
příkazového řádku do schránky.<placeholders>
Nahraďte parametry-S -U -P -d
správnými hodnotami.Spusťte upravený příkazový řádek v okně cmd jazyka RML.
Výsledek je doba trvání.
Po ostress.exe
dokončení zapíše dobu trvání spuštění jako poslední řádek výstupu v okně cmd RML. Například kratší testovací běh trval přibližně 1,5 minuty:
11/12/15 00:35:00.873 [0x000030A8] OSTRESS exiting normally, elapsed time: 00:01:31.867
Resetování, úprava _ondisk a opětovné spuštění
Jakmile budete mít výsledek _inmem spuštění, proveďte následující kroky pro _ondisk spuštění:
Obnovte databázi spuštěním následujícího příkazu v aplikaci SSMS, abyste odstranili všechna data vložená předchozím spuštěním:
EXECUTE Demo.usp_DemoReset;
ostress.exe
Upravte příkazový řádek a nahraďte všechny _inmem _ondisk.Znovu spusťte
ostress.exe
podruhé a zaznamenejte výsledek doby trvání.Znovu obnovte databázi.
Očekávané výsledky porovnání
Naše testy OLTP v paměti ukázaly, že výkon se pro tuto zjednodušenou úlohu zlepšil o devětkrát a ostress.exe
běžel na virtuálním počítači Azure ve stejné oblasti Azure jako databáze.
3. Instalace ukázky analýzy v paměti
V této části porovnáte výsledky vstupně-výstupních operací a statistik při použití indexu columnstore a tradičního indexu b-tree.
Pro analýzu úloh OLTP v reálném čase je často nejvhodnější použít neclusterovaný index columnstore. Podrobnosti najdete v části Indexy columnstore popsané.
Příprava testu analýzy columnstore
Pomocí webu Azure Portal vytvořte z ukázky novou
AdventureWorksLT
databázi. Použijte libovolný cíl služby, který podporuje indexy columnstore.Zkopírujte sql_in-memory_analytics_sample do schránky.
- Skript T-SQL vytvoří potřebné objekty v
AdventureWorksLT
ukázkové databázi, kterou jste vytvořili v kroku 1. - Skript vytvoří tabulky dimenzí a dvě tabulky faktů. Tabulky faktů jsou naplněné 3,5 milionu řádků.
- U menších cílů služby může dokončení skriptu trvat 15 minut nebo déle.
- Skript T-SQL vytvoří potřebné objekty v
Vložte skript T-SQL do aplikace SSMS a spusťte skript. Klíčové slovo COLUMNSTORE v příkazu
CREATE INDEX
je:CREATE NONCLUSTERED COLUMNSTORE INDEX ...;
Nastavte
AdventureWorksLT
na nejnovější úroveň kompatibility, SQL Server 2022 (160):ALTER DATABASE AdventureworksLT SET compatibility_level = 160;
Klíčové tabulky a indexy columnstore
dbo.FactResellerSalesXL_CCI
je tabulka, která obsahuje clusterovaný index columnstore, který má pokročilou kompresi na úrovni dat .dbo.FactResellerSalesXL_PageCompressed
je tabulka, která má ekvivalentní běžný clusterovaný index, komprimovaný pouze na úrovni stránky .
4. Klíčové dotazy pro porovnání indexu columnstore
Existuje několik typů dotazů T-SQL, které můžete spustit, abyste viděli vylepšení výkonu. V kroku 2 ve skriptu T-SQL věnujte pozornost tomuto páru dotazů. Liší se pouze na jednom řádku:
FROM FactResellerSalesXL_PageCompressed AS a
FROM FactResellerSalesXL_CCI AS a
Clusterovaný index columnstore je v FactResellerSalesXL_CCI
tabulce.
Následující skript T-SQL vytiskne logickou vstupně-výstupní statistiku a časovou statistiku pomocí funkce SET STATISTICS IO a SET STATISTICS TIME pro každý dotaz.
/*********************************************************************
Step 2 -- Overview
-- Page compressed BTree table vs Columnstore table performance differences
-- Enable actual query plan in order to see Plan differences when executing.
*/
-- Ensure the database uses the latest compatibility level
ALTER DATABASE AdventureworksLT SET compatibility_level = 160
GO
-- Execute a typical query that joins the fact table with dimension tables.
-- Note this query will run on the page compressed table. Note down the time.
SET STATISTICS IO ON
SET STATISTICS TIME ON
GO
SELECT c.Year
,e.ProductCategoryKey
,FirstName + ' ' + LastName AS FullName
,COUNT(SalesOrderNumber) AS NumSales
,SUM(SalesAmount) AS TotalSalesAmt
,AVG(SalesAmount) AS AvgSalesAmt
,COUNT(DISTINCT SalesOrderNumber) AS NumOrders
,COUNT(DISTINCT a.CustomerKey) AS CountCustomers
FROM FactResellerSalesXL_PageCompressed AS a
INNER JOIN DimProduct AS b ON b.ProductKey = a.ProductKey
INNER JOIN DimCustomer AS d ON d.CustomerKey = a.CustomerKey
INNER JOIN DimProductSubCategory AS e on e.ProductSubcategoryKey = b.ProductSubcategoryKey
INNER JOIN DimDate AS c ON c.DateKey = a.OrderDateKey
GROUP BY e.ProductCategoryKey,c.Year,d.CustomerKey,d.FirstName,d.LastName
GO
SET STATISTICS IO OFF
SET STATISTICS TIME OFF
GO
-- This is the same query on a table with a clustered columnstore index (CCI).
-- The comparison numbers are the more pronounced the larger the table is (this is an 11 million row table).
SET STATISTICS IO ON
SET STATISTICS TIME ON
GO
SELECT c.Year
,e.ProductCategoryKey
,FirstName + ' ' + LastName AS FullName
,COUNT(SalesOrderNumber) AS NumSales
,SUM(SalesAmount) AS TotalSalesAmt
,AVG(SalesAmount) AS AvgSalesAmt
,COUNT(DISTINCT SalesOrderNumber) AS NumOrders
,COUNT(DISTINCT a.CustomerKey) AS CountCustomers
FROM FactResellerSalesXL_CCI AS a
INNER JOIN DimProduct AS b ON b.ProductKey = a.ProductKey
INNER JOIN DimCustomer AS d ON d.CustomerKey = a.CustomerKey
INNER JOIN DimProductSubCategory AS e on e.ProductSubcategoryKey = b.ProductSubcategoryKey
INNER JOIN DimDate AS c ON c.DateKey = a.OrderDateKey
GROUP BY e.ProductCategoryKey,c.Year,d.CustomerKey,d.FirstName,d.LastName
GO
SET STATISTICS IO OFF
SET STATISTICS TIME OFF
GO
V databázi, která používá cíl služby P2, můžete očekávat přibližně devětkrát vyšší výkon tohoto dotazu pomocí clusterovaného indexu columnstore ve srovnání s tradičním indexem rowstore. S cílem služby P15 můžete očekávat přibližně 57krát vyšší výkon pomocí indexu columnstore.
Související obsah
- Rychlý start 1: Technologie OLTP v paměti pro rychlejší výkon T-SQL
- Použití OLTP v paměti ke zlepšení výkonu aplikace
- Monitorování úložiště OLTP v paměti
- Blog: OLTP v paměti ve službě Azure SQL Database
- OLTP v paměti
- Indexy Columnstore
- Provozní analýza v reálném čase s indexy columnstore
- Technický článek: OLTP v paměti – Běžné aspekty úloh a migrace v SQL Serveru 2014