Prestandariktlinjer för Synapse Data Warehouse i Microsoft Fabric
Gäller för:✅ Warehouse i Microsoft Fabric
Det här är riktlinjer som hjälper dig att förstå prestanda för ditt lager i Microsoft Fabric. I den här artikeln finns vägledning och viktiga artiklar att fokusera på. Warehouse i Microsoft Fabric är en SaaS-plattform där aktiviteter som arbetsbelastningshantering, samtidighet och lagringshantering hanteras internt av plattformen. Förutom den här interna prestandahanteringen kan du fortfarande förbättra dina prestanda genom att utveckla högpresterande frågor mot väl utformade lager.
Prestanda för kall körning (kall cache)
Cachelagring med lokal SSD och minne sker automatiskt. De första 1–3 körningarna av en fråga går märkbart långsammare än efterföljande körningar. Om du har problem med prestanda för kall körning kan du göra ett par saker som kan förbättra prestandan för kall körning:
Om den första körningens prestanda är avgörande kan du prova att skapa statistik manuellt. Läs statistikartikeln för att bättre förstå statistikens roll och få vägledning om hur du skapar manuell statistik för att förbättra frågeprestandan. Men om den första körningens prestanda inte är kritisk kan du förlita dig på automatisk statistik som genereras i den första frågan och som fortsätter att utnyttjas i efterföljande körningar (så länge underliggande data inte ändras avsevärt).
Om du använder Power BI använder du Direct Lake-läge där det är möjligt.
Mått för att övervaka prestanda
Övervakningshubben innehåller för närvarande inte Informationslager. Om du väljer Data Warehouse kommer du inte att kunna komma åt övervakningshubben från navigeringsfältet.
Infrastrukturadministratörer kommer att kunna komma åt rapporten Kapacitetsanvändning och mått för uppdaterad information som spårar användningen av kapacitet som innehåller Warehouse.
Använda dynamiska hanteringsvyer (DMV:er) för att övervaka frågekörning
Du kan använda dynamiska hanteringsvyer (DMV:er) för att övervaka anslutningen, sessionen och begärandestatusen i informationslagret.
Statistik
Informationslagret använder en frågemotor för att skapa en körningsplan för en viss SQL-fråga. När du skickar en fråga försöker frågeoptimeraren räkna upp alla möjliga planer och välja den mest effektiva kandidaten. För att avgöra vilken plan som skulle kräva minst omkostnader måste motorn kunna utvärdera mängden arbete eller rader som kan bearbetas av varje operator. Sedan, baserat på varje plans kostnad, väljer den den med minst mängd uppskattat arbete. Statistik är objekt som innehåller relevant information om dina data, så att frågeoptimeraren kan beräkna dessa kostnader.
Du kan också uppdatera statistik manuellt efter varje datainläsning eller datauppdatering för att säkerställa att den bästa frågeplanen kan skapas.
Mer informationsstatistik och hur du kan utöka den automatiskt skapade statistiken finns i Statistik i informationslager för infrastrukturresurser.
Riktlinjer för datainmatning
Det finns fyra alternativ för datainmatning till ett lager:
- KOPIERA (Transact-SQL)
- Datapipelines
- Dataflöden
- Inmatning mellan lager
Information om vilket alternativ som är bäst för dig och för att granska några metodtips för datainmatning finns i Mata in data.
Gruppera INSERT-instruktioner i batchar (undvik trickle-infogningar)
En engångsinläsning till en liten tabell med en INSERT-instruktion, till exempel i följande exempel, kan vara den bästa metoden beroende på dina behov. Men om du behöver läsa in tusentals eller miljontals rader under dagen är singleton INSERTS inte optimala.
INSERT INTO MyLookup VALUES (1, 'Type 1')
Vägledning om hur du hanterar dessa trickle-load-scenarier finns i Metodtips för inmatning av data.
Minimera transaktionsstorlekar
INSERT-, UPDATE- och DELETE-instruktioner körs i en transaktion. När de misslyckas måste de återställas. Minimera transaktionsstorlekarna när det är möjligt för att minska risken för en lång återställning. Du kan minimera transaktionsstorlekarna genom att dela in INSERT-, UPDATE- och DELETE-instruktioner i delar. Om du till exempel har en INSERT som du förväntar dig att ta 1 timme kan du dela upp INSERT i fyra delar. Varje körning förkortas sedan till 15 minuter.
Överväg att använda CTAS (Transact-SQL) för att skriva de data som du vill behålla i en tabell i stället för att använda DELETE. Om en CTAS tar samma tid är det säkrare att köra eftersom den har minimal transaktionsloggning och kan avbrytas snabbt om det behövs.
Samordna klientprogram och Microsoft Fabric
Om du använder klientprogram kontrollerar du att du använder Microsoft Fabric i en region som är nära klientdatorn. Exempel på klientprogram är Power BI Desktop, SQL Server Management Studio och Azure Data Studio.
Använda star-schemadatadesign
Ett star-schema organiserar data i faktatabeller och dimensionstabeller. Det underlättar analytisk bearbetning genom att avnormalisera data från högnormaliserade OLTP-system, mata in transaktionsdata och företagets huvuddata i en gemensam, rensad och verifierad datastruktur som minimerar kopplingar vid frågetillfället, minskar antalet rader som läse och underlättar aggregeringar och grupperingsbearbetning.
Mer information om informationslagerdesign finns i Tabeller i datalager.
Minska storlek på frågeresultatuppsättningar
Genom att minska frågeresultatuppsättningens storlekar kan du undvika problem på klientsidan som orsakas av stora frågeresultat. Resultatuppsättningarna för SQL Query-redigeraren är begränsade till de första 10 000 raderna för att undvika dessa problem i det här webbläsarbaserade användargränssnittet. Om du behöver returnera fler än 10 000 rader använder du SQL Server Management Studio (SSMS) eller Azure Data Studio.
Välj den bästa datatypen för prestanda
När du definierar dina tabeller kan du använda den minsta datatypen som stöder dina data, vilket förbättrar frågeprestandan. Den här rekommendationen är viktig för CHAR- och VARCHAR-kolumner. Om det längsta värdet i en kolumn är 25 tecken definierar du kolumnen som VARCHAR(25). Undvik att definiera alla teckenkolumner med en stor standardlängd.
Använd heltalsbaserade datatyper om det är möjligt. SORT-, JOIN- och GROUP BY-åtgärder slutförs snabbare på heltal än på teckendata.
Information om datatyper som stöds och mer information finns i datatyper.
Prestanda för SQL-analysslutpunkter
Information och rekommendationer om prestanda för SQL-analysslutpunkten finns i Prestandaöverväganden för SQL-analysslutpunkter.