Sdílet prostřednictvím

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

  • Článek

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.

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

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. Instalace ukázky OLTP v paměti

Ukázkovou AdventureWorksLT databázi můžete vytvořit několika kroky na webu Azure Portal. 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.

Instalační kroky

  1. Na webu Azure Portal vytvořte na 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.

  2. Připojení do databáze pomocí SQL Server Management Studio (SSMS)

  3. Zkopírujte skript OLTP Transact-SQL v paměti 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.

  4. Vložte skript T-SQL do aplikace SSMS a spusťte skript. Klauzule MEMORY_OPTIMIZED = ON v CREATE 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 není podporováno v paměti a 1 znamená to, že se podporuje. Technologie v paměti jsou dostupné 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 >filtr filtru>Nastavení> I 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 vaší AdventureWorksLT databáze. Místo toho ale můžete spustit ostress.exe na místní pracovní stanici, pokud se můžete připojit ke své databázi 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. Pomocí webu Azure Portal vytvořte z ukázky novou AdventureWorksLT databázi.

    • Použijte tento přesný název.
    • Zvolte libovolnou úroveň služby Premium.

  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 databázi s cenovou úrovní 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. S P15 můžete očekávat přibližně 57krát vyšší výkon pomocí indexu columnstore.

Související obsah