Synapse SQL-resursförbrukning

  • Artikel

I den här artikeln beskrivs resursförbrukningsmodeller för Synapse SQL.

Serverlös SQL-pool

Serverlös SQL-pool är en tjänst för betalning per fråga som inte kräver att du väljer rätt storlek. Eftersom systemet justeras automatiskt utifrån dina krav behöver du inte hantera infrastrukturen och välja rätt storlek för din lösning.

Dedikerad SQL-pool – Data Warehouse enheter (DWU:er) och beräkningsenheter Data Warehouse (cDWUs)

Rekommendationer om hur du väljer det perfekta antalet informationslagerenheter (DWU:er) för att optimera pris och prestanda och hur du ändrar antalet enheter.

Informationslagerenheter

En Synapse SQL-pool representerar en samling analysresurser som etableras. Analysresurser definieras som en kombination av CPU, minne och I/O. Dessa tre resurser paketeras i beräkningsenheter med namnet Data Warehouse units (DWU: er). En DWU representerar ett abstrakt, normaliserat mått för beräkningsresurser och prestanda. En ändring av tjänstnivån ändrar antalet DWU:er som är tillgängliga för systemet. Den här ändringen justerar i sin tur systemets prestanda och kostnad.

För högre prestanda kan du öka antalet informationslagerenheter. Minska informationslagerenheterna för mindre prestanda. Lagrings- och beräkningskostnader faktureras separat, så ändringar av informationslagerenheter påverkar inte lagringskostnaderna.

Prestanda för informationslagerenheter baseras på dessa arbetsbelastningsmått för informationslager:

  • Hur snabbt en standardfråga för informationslager kan skanna ett stort antal rader och sedan utföra en komplex aggregering. Den här åtgärden är I/O- och CPU-intensiv.
  • Hur snabbt informationslagret kan mata in data från Azure Storage-blobar eller Azure Data Lake. Den här åtgärden är nätverks- och cpu-intensiv.
  • Hur snabbt CREATE TABLE AS SELECT T-SQL-kommandot kan kopiera en tabell. Den här åtgärden innebär att läsa data från lagring, distribuera dem mellan noderna i installationen och skriva till lagring igen. Den här åtgärden är processor-, I/O- och nätverksintensiv.

Ökande DWU:er:

  • Linjärt ändrar systemets prestanda för genomsökningar, aggregeringar och CTAS-instruktioner
  • Ökar antalet läsare och skrivare för PolyBase-inläsningsåtgärder
  • Ökar det maximala antalet samtidiga frågor och samtidighetsplatser.

Servicenivåmål

Servicenivåmålet (SLO) är skalbarhetsinställningen som avgör kostnads- och prestandanivån för ditt informationslager. Tjänstnivåerna för Gen2 mäts i cDWU(Compute Data Warehouse Units), till exempel DW2000c. Tjänstnivåerna i Gen1 mäts i DWU:er, till exempel DW2000.

Servicenivåmålet (SLO) är skalbarhetsinställningen som avgör kostnads- och prestandanivån för ditt informationslager. Tjänstnivåerna för dedikerade Gen2-SQL-pooler mäts i informationslagerenheter (DWU), till exempel DW2000c.

Anteckning

Azure Synapse Analytics Gen2 har nyligen lagt till ytterligare skalningsfunktioner för att stödja beräkningsnivåer så låga som 100 cDWU. Befintliga informationslager på Gen1 som kräver de lägre beräkningsnivåerna kan nu uppgradera till Gen2 i de regioner som för närvarande är tillgängliga utan extra kostnad. Om din region ännu inte stöds kan du fortfarande uppgradera till en region som stöds. Mer information finns i Uppgradera till Gen2.

I T-SQL avgör inställningen SERVICE_OBJECTIVE tjänstnivån och prestandanivån för din dedikerade SQL-pool.

CREATE DATABASE mySQLDW
(Edition = 'Datawarehouse'
 ,SERVICE_OBJECTIVE = 'DW1000c'
)
;

Prestandanivåer och Data Warehouse enheter

Varje prestandanivå använder en något annorlunda måttenhet för sina informationslagerenheter. Den här skillnaden återspeglas på fakturan när skalningsenheten översätts direkt till fakturering.

  • Gen1-informationslager mäts i Data Warehouse enheter (DWU:er).
  • Gen2-informationslager mäts i beräknings- Data Warehouse enheter (cDWUs).

Både DWU:er och cDWUs stöder upp- eller nedskalning av beräkning och pausar beräkning när du inte behöver använda informationslagret. Alla dessa åtgärder är på begäran. Gen2 använder en lokal diskbaserad cache på beräkningsnoderna för att förbättra prestanda. När du skalar eller pausar systemet ogiltigförklaras cachen och därför krävs en period av cacheuppvärmning innan optimala prestanda uppnås.

När du ökar informationslagerenheterna ökar du linjärt beräkningsresurserna. Gen2 ger bästa frågeprestanda och högsta skala. Gen2-system använder också cachen på bästa sätt.

Kapacitetsbegränsningar

Varje SQL-server (till exempel myserver.database.windows.net) har en DTU-kvot (Database Transaction Unit) som tillåter ett visst antal informationslagerenheter. Mer information finns i kapacitetsbegränsningarna för arbetsbelastningshantering.

Utvärdera antalet informationslagerenheter som du behöver

Det ideala antalet informationslagerenheter beror i hög grad på din arbetsbelastning och mängden data som du har läst in i systemet.

Steg för att hitta den bästa DWU:en för din arbetsbelastning:

  1. Börja med att välja en mindre DWU.
  2. Övervaka programmets prestanda när du testar datainläsningar i systemet och observera antalet DWU:er som valts jämfört med de prestanda du observerar.
  3. Identifiera eventuella ytterligare krav för periodiska perioder med hög aktivitet. Arbetsbelastningar som visar betydande toppar och dalar i aktiviteten kan behöva skalas ofta.

SQL-pool är ett utskalningssystem som kan etablera stora mängder beräkning och frågestora mängder data. För att se dess verkliga funktioner för skalning, särskilt vid större DWU:er, rekommenderar vi att du skalar datauppsättningen när du skalar för att säkerställa att du har tillräckligt med data för att mata processorerna. För skalningstestning rekommenderar vi att du använder minst 1 TB.

Anteckning

Frågeprestandan ökar bara med mer parallellisering om arbetet kan delas upp mellan beräkningsnoder. Om du upptäcker att skalningen inte ändrar prestanda kan du behöva justera tabelldesignen och/eller dina frågor. Vägledning för frågejustering finns i Hantera användarfrågor.

Behörigheter

För att ändra informationslagerenheterna krävs de behörigheter som beskrivs i ALTER DATABASE.

Inbyggda roller i Azure, till exempel SQL DB-deltagare och SQL Server deltagare, kan ändra DWU-inställningarna.

Visa aktuella DWU-inställningar

Så här visar du den aktuella DWU-inställningen:

  1. Öppna SQL Server Object Explorer i Visual Studio.
  2. Anslut till huvuddatabasen som är associerad med den logiska SQL-servern.
  3. Välj från vyn sys.database_service_objectives dynamisk hantering. Här är ett exempel:
SELECT  db.name [Database]
,        ds.edition [Edition]
,        ds.service_objective [Service Objective]
FROM    sys.database_service_objectives   AS ds
JOIN    sys.databases                     AS db ON ds.database_id = db.database_id
;

Ändra informationslagerenheter

Azure Portal

Så här ändrar du DWU:er:

  1. Öppna Azure Portal, öppna databasen och välj Skala.

  2. Under Skala flyttar du skjutreglaget åt vänster eller höger för att ändra DWU-inställningen.

  3. Välj Spara. Ett bekräftelsemeddelande visas. Välj Ja för att bekräfta eller nej om du vill avbryta.

PowerShell

Anteckning

Vi rekommenderar att du använder Azure Az PowerShell-modulen för att interagera med Azure. Se Installera Azure PowerShell för att komma igång. Information om hur du migrerar till Az PowerShell-modulen finns i artikeln om att migrera Azure PowerShell från AzureRM till Az.

Om du vill ändra DWU:erna använder du PowerShell-cmdleten Set-AzSqlDatabase . I följande exempel anges servicenivåmålet till DW1000 för databasen MySQLDW som finns på servern MyServer.

Set-AzSqlDatabase -DatabaseName "MySQLDW" -ServerName "MyServer" -RequestedServiceObjectiveName "DW1000c"

Mer information finns i PowerShell-cmdletar för Azure Synapse Analytics

T-SQL

Med T-SQL kan du visa aktuella DWUsettings, ändra inställningarna och kontrollera förloppet.

Så här ändrar du DWU:erna:

  1. Anslut till huvuddatabasen som är associerad med servern.
  2. Använd ALTER DATABASE TSQL-instruktionen. I följande exempel anges servicenivåmålet till DW1000c för databasen MySQLDW.
ALTER DATABASE MySQLDW
MODIFY (SERVICE_OBJECTIVE = 'DW1000c')
;

REST API:er

Om du vill ändra DWU:erna använder du REST-API:et Skapa eller uppdatera databas . I följande exempel anges servicenivåmålet till DW1000c för databasen MySQLDW, som finns på servern MyServer. Servern finns i en Azure-resursgrupp med namnet ResourceGroup1.

PUT https://management.azure.com/subscriptions/{subscription-id}/resourceGroups/{resource-group-name}/providers/Microsoft.Sql/servers/{server-name}/databases/{database-name}?api-version=2014-04-01-preview HTTP/1.1
Content-Type: application/json; charset=UTF-8

{
    "properties": {
        "requestedServiceObjectiveName": DW1000
    }
}

Fler REST API-exempel finns i REST API:er för Azure Synapse Analytics.

Kontrollera status för DWU-ändringar

DWU-ändringar kan ta flera minuter att slutföra. Om du skalar automatiskt bör du överväga att implementera logik för att säkerställa att vissa åtgärder har slutförts innan du fortsätter med en annan åtgärd.

Genom att kontrollera databastillståndet via olika slutpunkter kan du implementera automatisering på rätt sätt. Portalen tillhandahåller meddelanden när en åtgärd har slutförts och databasernas aktuella tillstånd, men tillåter inte programmatisk kontroll av tillstånd.

Du kan inte kontrollera databastillståndet för skalbara åtgärder med Azure Portal.

Så här kontrollerar du status för DWU-ändringar:

  1. Anslut till huvuddatabasen som är associerad med servern.
  2. Skicka följande fråga för att kontrollera databastillståndet.
SELECT    *
FROM      sys.databases
;
  1. Skicka följande fråga för att kontrollera åtgärdens status
SELECT    *
FROM      sys.dm_operation_status
WHERE     resource_type_desc = 'Database'
AND       major_resource_id = 'MySQLDW'
;

Denna DMV returnerar information om olika hanteringsåtgärder i din dedikerade SQL-pool, till exempel åtgärden och tillståndet för åtgärden, som antingen är IN_PROGRESS eller slutförd.

Skalningsarbetsflödet

När du startar en skalningsåtgärd tar systemet först bort alla öppna sessioner och återställer alla öppna transaktioner för att säkerställa ett konsekvent tillstånd. För skalningsåtgärder sker skalning endast när den här transaktionsåterställningen har slutförts.

  • För en uppskalningsåtgärd kopplar systemet bort alla beräkningsnoder, etablerar de ytterligare beräkningsnoderna och återansluter sedan till lagringslagret.
  • För en nedskalningsåtgärd kopplar systemet bort alla beräkningsnoder och kopplar sedan endast de nödvändiga noderna till lagringslagret.

Nästa steg

Mer information om hur du hanterar prestanda finns i Resursklasser för arbetsbelastningshantering och minnes- och samtidighetsgränser.