Dela via

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 – DWU:er (Data Warehouse Units) och compute Data Warehouse Units (cDWUs)

Rekommendationer på att välja det ideala 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 datalager kan skanna ett stort antal rader och sedan utföra en komplex aggregering. Den här åtgärden är I/O och processorintensiv.
  • Hur snabbt informationslagret kan mata in data från Azure Storage Blobs eller Azure Data Lake. Den här åtgärden är nätverks- och processorintensiv.
  • Hur snabbt CREATE TABLE AS SELECT T-SQL-kommandot kan kopiera en tabell. Den här åtgärden omfattar att läsa data från lagring, distribuera dem mellan noderna i enheten och skriva till lagring igen. Den här åtgärden är processor-, I/O- och nätverksintensiv.

Öka 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 samtidighetsfack.

Servicenivåmål

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

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

Kommentar

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 informationslagerenheter

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

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

Både DWU:er och cDWUs stöder skalning av beräkning upp eller ned 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 prestandan. När du skalar eller pausar systemet ogiltigförklaras cacheminnet och därför krävs en period av cacheuppvärmning innan optimala prestanda uppnås.

När du ökar informationslagrets enheter ökar du linjärt databehandlingsresurserna. 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 idealiska antalet informationslagerenheter beror mycket 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 valda DWU:er jämfört med de prestanda du ser.
  3. Identifiera eventuella ytterligare krav för periodiska perioder med hög belastning. 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åga stora mängder data. Om du vill 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.

Kommentar

Frågeprestanda ökar bara med mer parallellisering om arbetet kan delas mellan beräkningsnoder. Om du upptäcker att skalningen inte ändrar prestandan 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 informationslagrets enheter krävs de behörigheter som beskrivs i ALTER DATABASE.

Inbyggda Azure-roller som SQL DB-deltagare och SQL Server-deltagare kan ändra DWU-inställningar.

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-portalen, ö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

Kommentar

Vi rekommenderar att du använder Azure Az PowerShell-modulen för att interagera med Azure. Information om hur du kommer igång finns i Installera Azure PowerShell. 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 kan 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 innehåller ett meddelande när en åtgärd och databasens aktuella tillstånd har slutförts, men tillåter inte programmatisk kontroll av tillstånd.

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

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 från alla beräkningsnoder, etablerar ytterligare beräkningsnoder och kopplar sedan till lagringslagret igen.
  • För en nedskalningsåtgärd kopplar systemet bort alla beräkningsnoder och kopplar sedan endast de noder som behövs till lagringslagret.

Nästa steg

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