Lathund för dedikerad SQL-pool (tidigare SQL DW) i Azure Synapse Analytics
Det här fuskbladet innehåller användbara tips och metodtips för att skapa dedikerade SQL-poollösningar (tidigare SQL DW).
Följande bild visar processen för att utforma ett informationslager med en dedikerad SQL-pool (tidigare SQL DW):
Frågor och åtgärder i tabeller
När du vet i förväg vilka primära åtgärder och frågor som ska köras i ditt informationslager kan du prioritera arkitekturen för ditt informationslager för de åtgärderna. Dessa frågor och åtgärder kan innehålla:
- Anslutning till en eller två faktatabeller med dimensionstabeller, filtrering av den kombinerade tabellen och sedan bifogning av resultatet i en data mart.
- Gör stora eller små uppdateringar i din försäljning.
- Lägger endast till data i dina tabeller.
När du vet åtgärdstyperna i förväg kan du optimera tabellernas design.
Datamigrering
Läs först in dina data i Azure Data Lake Storage eller Azure Blob Storage. Använd sedan COPY-instruktionen för att läsa in dina data i mellanlagringstabeller. Använd följande konfiguration:
| Design | Rekommendation |
|---|---|
| Distribution | Resursallokering (round robin) |
| Indexering | Heap |
| Partitionering | Ingen |
| Resursklass | largerc eller xlargerc |
Läs mer om datamigrering, datainläsning och ELT-processen (Extract, Load, and Transform).
Distribuerade eller replikerade tabeller
Använd följande strategier, beroende på tabellens egenskaper:
| Typ | Passar bra för... | Se upp om... |
|---|---|---|
| Replikerad | * Små dimensionstabeller i ett star-schema med mindre än 2 GB lagringsutrymme efter komprimering (~5 x komprimering) | * Många skrivtransaktioner finns i tabellen (till exempel infoga, upsert, ta bort, uppdatera) * Du ändrar Data Warehouse enheter (DWU) etablerar ofta * Du använder bara 2–3 kolumner men tabellen har många kolumner * Du indexera en replikerad tabell |
| Resursallokering (standard) | * Tillfällig/mellanlagringstabell * Ingen uppenbar kopplingsnyckel eller bra kandidatkolumn |
* Prestandan är långsam på grund av dataförflyttning |
| Hash | * Faktatabeller * Stora dimensionstabeller |
* Distributionsnyckeln kan inte uppdateras |
Tips:
- Börja med resursallokering, men försök att skapa en hashdistributionsstrategi för att dra nytta av en massiv parallell arkitektur.
- Se till att vanliga hash-nycklar har samma dataformat.
- Distribuera inte i varchar-format.
- Dimensionstabeller med en vanlig hash-nyckel för en faktatabell med många kopplingsåtgärder kan hash-distribueras.
- Använd sys.dm_pdw_nodes_db_partition_stats för att analysera eventuella snedställningar i dina data.
- Använd sys.dm_pdw_request_steps för att analysera dataförflyttningar bakom frågor, övervaka tidssändningen och blanda åtgärder. Det är praktiskt när du granskar din distributionsstrategi.
Läs mer om replikerade tabeller och distribuerade tabeller.
Indexera tabellen
Indexering är bra när du vill läsa tabeller snabbt. Det finns en unik uppsättning tekniker som du kan använda utifrån dina behov:
| Typ | Passar bra för... | Se upp om... |
|---|---|---|
| Heap | * Mellanlagring/tillfällig tabell * Små tabeller med små uppslag |
* Alla sökningar söker igenom hela tabellen |
| Grupperat index | * Tabeller med upp till 100 miljoner rader * Stora tabeller (mer än 100 miljoner rader) med endast 1–2 kolumner som används mycket |
* Används i en replikerad tabell * Du har komplexa frågor som omfattar flera åtgärder för att ansluta till och gruppera efter * Du gör uppdateringar på de indexerade kolumnerna: det tar minne |
| Grupperade columnstore-index (kolumnlagringsindex) (standard) | * Stora tabeller (mer än 100 miljoner rader) | * Används i en replikerad tabell * Du gör enorma uppdateringsåtgärder i tabellen * Du överpartitionera tabellen: radgrupper sträcker sig inte över olika distributionsnoder och partitioner |
Tips:
- Förutom ett grupperat index kanske du vill lägga till ett icke-grupperat index till en kolumn som används ofta för filtrering.
- Var försiktig med hur du hanterar minnet i en tabell med CCI. När du läser in data ska användaren (eller frågan) dra nytta av en stor resursklass. Undvik att trimma och skapa många små komprimerade radgrupper.
- På Gen2 cachelagras CCI-tabeller lokalt på datornoderna för att maximera prestanda.
- För CCI kan dåliga prestanda uppstå på grund av dålig komprimering av dina radgrupper. Om det sker ska du återskapa eller ordna om din CCI. Du bör ha minst 100 000 rader per komprimerad radgrupp. Det bästa är 1 miljon rader i en radgrupp.
- Baserat på den stegvisa frekvensen och storleken vill du automatisera när du ordnar om eller återskapar dina index. En vårstädning är aldrig fel.
- Var strategisk när du vill trimma en radgrupp. Hur stora är öppna radgrupper? Hur mycket data förväntar du dig att läsa in under de kommande dagarna?
Läs mer om index.
Partitionering
Du kan partitionera tabellen när du har en stor faktatabell (fler än 1 miljard rader). I 99 procent av fallen ska partitionsnyckeln baseras på datum.
Med mellanlagringstabeller som kräver ELT kan du dra nytta av partitionering. Det underlättar hanteringen av datalivscykeln. Var noga med att inte överpartitionera fakta- eller mellanlagringstabellen, särskilt i ett grupperat kolumnlagringsindex.
Läs mer om partitioner.
Stegvis inläsning
Om du ska läsa in data stegvis ska du först kontrollera att du allokerar större resursklasser för att läsa in dina data. Detta är särskilt viktigt när du läser in i tabeller med grupperade kolumnlagringsindex. Mer information finns i resursklasser .
Vi rekommenderar att du använder PolyBase och ADF V2 för att automatisera dina ELT-pipelines till ditt informationslager.
Överväg att använda en CTAS för att skriva de data som du vill behålla i en tabell i stället för att använda INSERT, UPDATE och DELETE för en stor batch med uppdateringar i dina historiska data.
Underhålla statistik
Det är viktigt att uppdatera statistiken när betydande ändringar sker i dina data. Se uppdatera statistik för att avgöra om betydande ändringar har inträffat. Uppdaterad statistik optimerar dina frågeplaner. Om du tycker att det tar för lång tid att behålla all statistik kan du vara mer selektiv med vilka kolumner som ska ha statistik.
Du kan även definiera frekvensen för uppdateringarna. Du kanske till exempel vill uppdatera datumkolumner, där nya värden kan läggas till, varje dag. Du får ut mest genom att använda statistik med kolumner som ingår i kopplingar, kolumner som används i WHERE-satsen och kolumner som finns i GROUP BY.
Läs mer om statistik.
Resursklass
Resursgrupper används som ett sätt att allokera minne till frågor. Om du behöver mer minne för att förbättra hastigheten för frågor eller inläsning ska du allokera högre resursklasser. Å andra sidan påverkar användning av större klasser samtidigheten. Du bör överväga det innan du flyttar alla dina användare till en stor resursklass.
Om du märker att frågor tar för lång tid kan du kontrollera att dina användare inte körs i stora resursklasser. Stora resursklasser förbrukar många samtidighetsfack. De kan orsaka att andra frågor placeras i kö.
Genom att använda Gen2 i en dedikerad SQL-pool (tidigare SQL DW) får varje resursklass 2,5 gånger mer minne än Gen1.
Lär dig mer om hur du arbetar med resursklasser och samtidighet.
Sänk kostnaderna
En viktig funktion i Azure Synapse är möjligheten att hantera beräkningsresurser. Du kan pausa din dedikerade SQL-pool (tidigare SQL DW) när du inte använder den, vilket stoppar faktureringen av beräkningsresurser. Du kan skala resurser för att uppfylla dina prestandakrav. Om du vill pausa använder du Azure-portalen eller PowerShell. Om du vill skala använder du Azure Portal, PowerShell, T-SQL eller ett REST-API.
Autoskala nu för den tid du önskar med Azure Functions:
Optimera din arkitektur för prestanda
Vi rekommenderar att du överväger SQL Database och Azure Analysis Services i en nav-och-eker-arkitektur. Den här lösningen kan isolera arbetsbelastningen mellan olika grupper av användare när du även använder avancerade funktioner från SQL Database och Azure Analysis Services. Det här är också ett sätt att tillhandahålla obegränsad samtidighet till dina användare.
Läs mer om typiska arkitekturer som utnyttjar en dedikerad SQL-pool (tidigare SQL DW) i Azure Synapse Analytics.
Distribuera med ett klick dina ekrar i SQL-databaser från en dedikerad SQL-pool (tidigare SQL DW):