Sdílet prostřednictvím

Ukázka v paměti ve službě Azure SQL Managed Instance

  • Článek

Platí pro: Azure SQL Managed Instance

Technologie v paměti ve službě Azure SQL Managed Instance umožňují zlepšit výkon aplikace a potenciálně snížit náklady na databázi. Pomocí technologií v paměti ve službě Azure SQL Managed Instance můžete dosáhnout vylepšení výkonu s různými úlohami.

V tomto článku uvidíte dvě ukázky, které ilustrují použití OLTP v paměti a indexy columnstore ve službě Azure SQL Managed Instance.

Další informace naleznete v tématu:

Jednodušší, ale vizuálně přitažlivější ukázka výkonu pro OLTP v paměti najdete tady:

1. Obnovení ukázkové databáze OLTP v paměti

Ukázkovou databázi můžete obnovit AdventureWorksLT několika kroky T-SQL v aplikaci SQL Server Management Studio (SSMS). Další informace o obnovení databáze do spravované instance SQL najdete v tématu Rychlý start: Obnovení databáze do služby Azure SQL Managed Instance pomocí SSMS.

Potom kroky v této části vysvětlují, jak můžete rozšířit AdventureWorksLT databázi o objekty OLTP v paměti a předvést výhody výkonu.

  1. Otevřete SSMS a připojte se ke spravované instanci SQL.

    Poznámka:

    Připojení ke službě Azure SQL Managed Instance z místní pracovní stanice nebo virtuálního počítače Azure je možné bezpečně vytvořit bez otevření veřejného přístupu. Zvažte rychlý start: Konfigurace připojení typu point-to-site ke službě Azure SQL Managed Instance z místního prostředí nebo rychlého startu: Konfigurace virtuálního počítače Azure pro připojení ke spravované instanci Azure SQL

  2. V Průzkumník objektů klikněte pravým tlačítkem na spravovanou instanci a výběrem možnosti Nový dotaz otevřete nové okno dotazu.

  3. Spusťte následující příkaz T-SQL, který používá veřejně dostupný předkonfigurovaný kontejner úložiště a klíč sdíleného přístupového podpisu k vytvoření přihlašovacích údajů ve spravované instanci SQL. U veřejně dostupného úložiště se nevyžaduje žádný podpis SAS.

    CREATE CREDENTIAL [https://mitutorials.blob.core.windows.net/examples/]
WITH IDENTITY = 'SHARED ACCESS SIGNATURE';

  4. Spuštěním následujícího příkazu obnovte ukázkové AdventureWorksLT databáze.

    RESTORE DATABASE [AdventureWorksLT] 
FROM URL = 'https://mitutorials.blob.core.windows.net/examples/AdventureWorksLT2022.bak';

  5. Spuštěním následujícího příkazu sledujte stav procesu obnovení.

    SELECT session_id as SPID, command, a.text AS Query, start_time, percent_complete
   , dateadd(second,estimated_completion_time/1000, getdate()) as estimated_completion_time
FROM sys.dm_exec_requests r
CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) a
WHERE r.command in ('BACKUP DATABASE','RESTORE DATABASE');

  6. Po dokončení procesu obnovení zobrazte AdventureWorksLT databázi v Průzkumník objektů. Pomocí zobrazení sys.dm_operation_status můžete ověřit, že AdventureWorksLT se databáze obnovila.

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 1rovná .

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), 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á verze tabulek 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 použít praktický nástroj ostress.exe ke spuštění dvou uložených procedur na stresující úrovni. Můžete porovnat, jak dlouho trvá dokončení těchto dvou zátěžových běhů.

Instalace nástrojů A ostress RML

V ideálním případě byste chtěli spustit ostress.exe na virtuálním počítači Azure. Virtuální počítač Azure byste vytvořili ve stejné oblasti Azure jako spravovaná instance SQL. Místo toho ale můžete spustit ostress.exe na místní pracovní stanici, pokud se můžete připojit ke spravované instanci Azure SQL.

Na virtuálním počítači nebo na libovolném hostiteli, který zvolíte, nainstalujte nástroje RML (Replay Markup Language). Mezi nástroje patří ostress.exe.

Další informace naleznete v tématu:

Skript pro ostress.exe

Tato část zobrazuje skript T-SQL, který je vložený do našeho příkazového řádku ostress.exe. Skript používá položky vytvořené skriptem T-SQL, který jste nainstalovali dříve.

Když spustíte ostress.exe, doporučujeme předat hodnoty parametrů navržené tak, aby zatížení ztěžoval pomocí obou následujících strategií:

  • 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

Pokud chcete _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í našeho ostress.exe příkazového řádku můžete použít okno příkazového řádku RML Cmd. 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 ostress.exe příkazového řádku:

  1. 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;

  2. Zkopírujte text předchozího ostress.exe příkazového řádku do schránky.

  3. <placeholders> Nahraďte parametry -S -U -P -d správnými skutečnými hodnotami.

  4. Spusťte upravený příkazový řádek v okně cmd jazyka RML.

Výsledek je doba trvání.

Po dokončení ostress.exe 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í:

  1. 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;

  2. Upravte příkazový řádek ostress.exe a nahraďte všechny _inmem _ondisk.

  3. Znovu spusťte ostress.exe podruhé a zaznamenejte výsledek doby trvání.

  4. Znovu obnovte databázi (pro zodpovědné odstranění toho, co může být velké množství testovacích dat).

Očekávané výsledky porovnání

Naše testy v paměti ukázaly, že výkon se pro tuto zjednodušenou úlohu zvýšil o devětkrát a ostress 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

  1. Obnovení nové AdventureWorksLT databáze do spravované instance SQL, přepsání existující databáze, kterou jste nainstalovali dříve, pomocí WITH REPLACE.

    RESTORE DATABASE [AdventureWorksLT] 
FROM URL = 'https://mitutorials.blob.core.windows.net/examples/AdventureWorksLT2022.bak'
WITH REPLACE;

  2. Zkopírujte sql_in-memory_analytics_sample do schránky.

    • Skript T-SQL vytvoří potřebné objekty v paměti 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ů.
    • Dokončení skriptu může trvat 15 minut.

  3. 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 ...;

  4. 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, který je komprimován 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 v/s Columnstore table performance differences
-- Enable actual Query Plan in order to see Plan differences when Executing
*/
-- Ensure Database is in 130 compatibility mode
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 Prior query on a table with a clustered columnstore index CCI
-- The comparison numbers are even more dramatic the larger the table is (this is an 11 million row table only)
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 závislosti na konfiguraci spravované instance SQL můžete u tohoto dotazu očekávat výrazné zvýšení výkonu pomocí clusterovaného indexu columnstore ve srovnání s tradičním indexem.

Související obsah