Hantera beräkningsresurser för dedikerad SQL-pool
Den här artikeln beskriver hur du hanterar beräkningsresurser för dedikerad SQL-pool (tidigare SQL DW) i Azure Synapse Analytics. Du kan sänka kostnaderna genom att pausa den dedikerade SQL-poolen eller skala den dedikerade SQL-poolen för att uppfylla prestandakraven.
Vad är beräkningshantering?
I arkitekturen för dedikerade SQL-pooler är lagring och beräkning åtskilda, vilket innebär att du kan skala om dem var för sig. Det gör att du kan skala om beräkningsresurserna för att uppfylla prestandabehoven oberoende av datalagringen. Du kan också pausa och återuppta beräkningsresurser.
En naturlig konsekvens av den här arkitekturen är att prissättningen för beräkning och lagring är separat. Om du inte behöver använda din dedikerade SQL-pool under en tid kan du spara beräkningskostnader genom att pausa databearbetningen.
Skalningsberäkning
Du kan skala ut eller skala tillbaka beräkning genom att justera inställningen för informationslagerenheter för din dedikerade SQL-pool. Inläsnings- och frågeprestanda kan öka linjärt när du lägger till fler DWU:er.
Information om utskalningssteg finns i snabbstarterna för Azure Portal, PowerShell eller T-SQL. Du kan också utföra utskalningsåtgärder med hjälp av ett REST-API.
För att utföra en skalningsåtgärd dödar den dedikerade SQL-poolen först alla inkommande frågor och återställer sedan transaktioner för att säkerställa ett konsekvent tillstånd. Skalningen utförs först när transaktionerna har återställts. För en skalningsåtgärd kopplar systemet bort lagringslagret från beräkningsnoderna, lägger till beräkningsnoder och kopplar sedan om lagringslagret till beräkningslagret.
Varje dedikerad SQL-pool lagras som 60 distributioner, som distribueras jämnt till beräkningsnoderna. Att lägga till fler beräkningsnoder ger mer beräkningskraft. När antalet beräkningsnoder ökar minskar antalet distributioner per beräkningsnod, vilket ger mer beräkningskraft för dina frågor. På samma sätt minskar minskande DWU:er antalet beräkningsnoder, vilket minskar beräkningsresurserna för frågor.
I följande tabell visas hur antalet distributioner per beräkningsnod ändras när DWU:erna ändras. DW30000c ger 60 beräkningsnoder och ger mycket högre frågeprestanda än DW100c.
| Informationslagerenheter | Antal beräkningsnoder | Antal distributioner per nod |
|---|---|---|
| DW100c | 1 | 60 |
| DW200c | 1 | 60 |
| DW300c | 1 | 60 |
| DW400c | 1 | 60 |
| DW500c | 1 | 60 |
| DW1000c | 2 | 30 |
| DW1500c | 3 | 20 |
| DW2000c | 4 | 15 |
| DW2500c | 5 | 12 |
| DW3000c | 6 | 10 |
| DW5000c | 10 | 6 |
| DW6000c | 12 | 5 |
| DW7500c | 15 | 4 |
| DW10000c | 20 | 3 |
| DW15000c | 30 | 2 |
| DW30000c | 60 | 1 |
Hitta rätt storlek på informationslagerenheter
Om du vill se prestandafördelarna med utskalning, särskilt för större informationslagerenheter, vill du använda minst en datauppsättning på 1 TB. Om du vill hitta det bästa antalet DWU:er för din dedikerade SQL-pool kan du prova att skala upp och ned. Kör några frågor med olika antal DWU:er när du har läst in dina data. Eftersom skalning går snabbt kan du prova olika prestandanivåer på en timme eller mindre.
Rekommendationer för att hitta det bästa antalet DWU:er:
- För en dedikerad SQL-pool under utveckling börjar du med att välja ett mindre antal DWU:er. En bra utgångspunkt är DW400c eller DW200c.
- Övervaka programmets prestanda och observera antalet DWU:er som valts jämfört med de prestanda du ser.
- Anta en linjär skala och bestäm hur mycket du behöver öka eller minska DWU:erna.
- Fortsätt att göra justeringar tills du når en optimal prestandanivå för dina affärsbehov.
När ska du skala ut
Skalning av DWU:er påverkar dessa aspekter av prestanda:
- Linjärt förbättrar systemets prestanda för genomsökningar, aggregeringar och CTAS-instruktioner
- Ökar antalet läsare och skrivare för inläsning av data
- Maximalt antal samtidiga frågor och samtidighetsfack
Rekommendationer för när DWU:er ska skalas ut:
- Innan du utför en tung datainläsning eller transformeringsåtgärd skalar du ut för att göra data tillgängliga snabbare.
- Under högsäsong skalar du ut för att hantera ett större antal samtidiga frågor.
Vad händer om utskalning inte förbättrar prestandan?
Om du lägger till DWU:er ökar parallelliteten. Om arbetet delas jämnt mellan beräkningsnoderna förbättrar den ytterligare parallelliteten frågeprestanda. Om utskalning inte ändrar prestanda finns det några orsaker till varför detta kan inträffa. Dina data kan vara skeva över distributionerna, eller så kan frågor introducera en stor mängd dataförflyttning. Information om hur du undersöker problem med frågeprestanda finns i Prestandafelsökning.
Pausa och återuppta beräkning
Om du pausar beräkningen kopplas lagringslagret från beräkningsnoderna. Beräkningsresurserna släpps från ditt konto. Du debiteras inte för beräkning medan beräkningen pausas. Om du återupptar beräkningsåterkopplingen återställs lagringen till beräkningsnoderna och avgifterna för beräkning återupptas.
När du pausar en dedikerad SQL-pool:
- Beräknings- och minnesresurser returneras till poolen med tillgängliga resurser i datacentret.
- Kostnaderna för informationslagrets enhet är noll under pausen.
- Datalagring påverkas inte och dina data förblir intakta.
- Alla åtgärder som körs eller köas avbryts.
- DMV-räknare återställs.
När du återupptar en dedikerad SQL-pool:
- Den dedikerade SQL-poolen hämtar beräknings- och minnesresurser för din DWU-inställning.
- Beräkningsavgifter för dina DWU:er återupptas.
- Dina data blir tillgängliga.
- När den dedikerade SQL-poolen är online måste du starta om dina arbetsbelastningsfrågor.
Om du alltid vill att din dedikerade SQL-pool ska vara tillgänglig bör du överväga att skala ned den till den minsta storleken i stället för att pausa.
Information om hur du pausar och återupptar steg finns i snabbstarterna för Azure Portal eller PowerShell. Du kan också använda rest-API:et pausa eller återuppta REST-API:et.
Tömma transaktioner före pausning eller skalning
Vi rekommenderar att du väntar tills befintliga transaktioner har slutförts innan du startar en paus- eller skalningsåtgärd.
När du pausar eller skalar din dedikerade SQL-pool avbryts dina frågor i bakgrunden när du initierar paus- eller skalningsbegäran. Att avbryta en enkel SELECT-fråga är en snabb åtgärd och har nästan ingen effekt på den tid det tar att pausa eller skala instansen. Transaktionsfrågor, som ändrar dina data eller datastrukturen, kanske inte kan stoppas snabbt. Transaktionsfrågor måste per definition slutföras i sin helhet eller så måste ändringarna återställas.
Det kan ta lång tid att återställa arbetet som en transaktionsfråga har utfört, till och med längre tid än den ursprungliga ändringen som frågan tillämpade. Om du till exempel avbryter en fråga som tog bort rader och redan har körts i en timme kan det ta systemet en timme att infoga tillbaka de borttagna raderna. Om du kör paus eller skalning medan transaktionerna pågår kan det ta lång tid att pausa eller skala eftersom pausning och skalning måste vänta tills återställningen har slutförts innan den kan fortsätta.
Mer information finns i Använda transaktioner och Optimera transaktioner.
Automatisera beräkningshantering
Information om hur du automatiserar beräkningshanteringsåtgärder finns i Använda Azure Functions för att hantera beräkningsresurser för din dedikerade SQL-pool.
Var och en av åtgärderna för att skala ut, pausa och återuppta kan ta flera minuter att slutföra. Om du skalar, pausar eller återupptar automatiskt rekommenderar vi att du implementerar logik för att säkerställa att vissa åtgärder är slutförda innan du fortsätter med en annan åtgärd. Genom att kontrollera det dedikerade SQL-pooltillståndet via olika slutpunkter kan du implementera automatisering av sådana åtgärder korrekt.
Information om hur du kontrollerar tillståndet för den dedikerade SQL-poolen finns i snabbstarterna för PowerShell eller T-SQL. Du kan också kontrollera det dedikerade SQL-pooltillståndet med ett REST-API.
Behörigheter
För att skala den dedikerade SQL-poolen krävs de behörigheter som beskrivs i ALTER DATABASE. Pausa och återuppta kräver rollen SQL DB-deltagare , särskilt Microsoft.Sql/servers/databases/action.