Sdílet prostřednictvím


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:

Úvodní ukázku 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 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

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

  2. Připojte se k databázi pomocí aplikace SQL Server Management Studio (SSMS).

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

  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 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 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) 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:

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.exedoporuč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.exemůž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:

  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 hodnotami.

  4. 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í:

  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. ostress.exe Upravte příkazový řádek 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.

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

  1. Pomocí webu Azure Portal vytvořte z ukázky novou AdventureWorksLT databázi. Použijte libovolný cíl služby, který podporuje indexy columnstore.

  2. 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.
  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, 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.