Hantera beräkning för dedikerad SQL-pool (tidigare SQL DW) i Azure Synapse Analytics
Lär dig mer om att hantera dedikerade SQL-pooler (tidigare SQL DW) i Azure Synapse Analytics. Lägre kostnader genom att pausa den dedikerade SQL-poolen eller skala den dedikerade SQL-poolen för att uppfylla prestandakraven.
Vad är beräkningshantering?
Arkitekturen för en dedikerad SQL-pool (tidigare SQL DW) separerar lagring och beräkning, vilket gör att var och en kan skalas separat. 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 faktureringen för beräkning och lagring är separat. Om du inte behöver använda din dedikerade SQL-pool (tidigare SQL DW) på ett tag kan du spara beräkningskostnader genom att pausa beräkningen.
Skalningsberäkning
Du kan skala ut eller in beräkningen genom att justera inställningen för informationslagerenheter till den dedikerade SQL-poolen (tidigare SQL DW). Prestanda för inläsning och körning av frågor ökar linjärt när du lägger till fler informationslagerenheter.
Information om utskalningssteg finns i Snabbstarter för Azure-portalen, PowerShell eller T-SQL . Du kan också utföra utskalningsåtgärder med ett REST-API.
När du utför en skalningsåtgärd stoppar den dedikerade SQL-datapoolen (tidigare SQL DW) först alla inkommande frågor och återställer sedan transaktionerna för att säkerställa att tillståndet är konsekvent. 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 (tidigare SQL DW) 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 informationslagerenheter antalet beräkningsnoder, vilket minskar beräkningsresurserna för frågor.
Följande tabell visar hur antalet distributioner per beräkningsnod ändras när informationslagrets enheter ä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 informationslagerenheter för din dedikerade SQL-pool (tidigare SQL DW) kan du prova att skala upp och ned. Kör några frågor med olika antal informationslagerenheter 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 informationslagerenheter:
- För en dedikerad SQL-pool (tidigare SQL DW) under utveckling börjar du med att välja ett mindre antal informationslagerenheter. En bra utgångspunkt är DW400c eller DW200c.
- Övervaka programmets prestanda och observera antalet valda informationslagerenheter jämfört med de prestanda du ser.
- Anta en linjär skala och bestäm hur mycket du behöver öka eller minska informationslagerenheterna.
- Fortsätt att göra justeringar tills du når en optimal prestandanivå för dina affärsbehov.
När ska du skala ut
Utskalning av informationslagerenheter 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 informationslagerenheter 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?
Lägga till informationslagerenheter som ökar parallelliteten. Om arbetet delas jämnt mellan beräkningsnoderna förbättrar den ytterligare parallelliteten frågeprestanda. Om utskalning inte ändrar dina 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äkningar
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 (tidigare SQL DW):
- 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 (tidigare SQL DW):
- Den dedikerade SQL-poolen (tidigare SQL DW) hämtar beräknings- och minnesresurser för din inställning för informationslagerenheter.
- Beräkningsavgifterna för dina informationslagerenheter återupptas.
- Dina data blir tillgängliga.
- När den dedikerade SQL-poolen (tidigare SQL DW) är online måste du starta om dina arbetsbelastningsfrågor.
Om du alltid vill att din dedikerade SQL-pool (tidigare SQL DW) ska vara tillgänglig bör du överväga att skala ned den till den minsta storleken i stället för att pausa.
Pausa och återuppta steg finns i Azure-portalen eller PowerShell-snabbstarter . 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 (tidigare SQL DW) 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 påverkar nästan inte alls den tid det tar att pausa eller skala instansen. Transaktionsfrågor, som ändrar data eller datastrukturen, kan däremot ta längre tid att stoppa. 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 som redan har körts i en timme, kan det ta en timme för systemet att lägga till de borttagna raderna igen. Om du pausar eller skalar under pågående transaktioner kan det verka som åtgärden tar lång tid eftersom pausningen och skalningen måste vänta tills återställningen har slutförts innan de kan fortsätta.
Se även Förstå transaktioner och Optimera transaktioner.
Automatisera beräkningshantering
Information om hur du automatiserar beräkningshanteringsåtgärder finns i Hantera beräkning med Azure-funktioner.
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 har slutförts innan du fortsätter med en annan åtgärd. Genom att kontrollera tillståndet för den dedikerade SQL-poolen (tidigare SQL DW) 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 (tidigare SQL DW) finns i snabbstarten för PowerShell eller T-SQL . Du kan också kontrollera tillståndet för den dedikerade SQL-poolen (tidigare SQL DW) med ett REST-API.
Behörigheter
För att skala den dedikerade SQL-poolen (tidigare SQL DW) krävs de behörigheter som beskrivs i ALTER DATABASE. Pausa och återuppta kräver behörigheten SQL DB-deltagare , särskilt Microsoft.Sql/servers/databases/action.
Nästa steg
Se hur du hanterar beräkning En annan aspekt av hanteringen av beräkningsresurser är att allokera olika beräkningsresurser för enskilda frågor. Mer information finns i Resursklasser för arbetsbelastningshantering.