Retningslinjer for ydeevnen for Fabric Data Warehouse
Gælder for:✅ Warehouse i Microsoft Fabric
Dette er retningslinjer, der hjælper dig med at forstå ydeevnen af dit lager i Microsoft Fabric. I denne artikel finder du vejledning og vigtige artikler, du skal fokusere på. Warehouse i Microsoft Fabric er en SaaS-platform, hvor aktiviteter som administration af arbejdsbelastninger, samtidighed og lagerstyring administreres internt af platformen. Ud over denne interne ydeevnestyring kan du stadig forbedre din ydeevne ved at udvikle performante forespørgsler i forhold til veldesignede lagre.
Ydeevne for kold kørsel (kold cache)
Cachelagring med lokal SSD og hukommelse sker automatisk. De første 1-3 udførelser af en forespørgsel fungerer mærkbart langsommere end efterfølgende udførelser. Hvis du oplever problemer med ydeevnen for kold kørsel, er her et par ting, du kan gøre, som kan forbedre ydeevnen for din kolde kørsel:
Hvis ydeevnen for den første kørsel er afgørende, kan du prøve at oprette statistikker manuelt. Gennemse artiklen om statistikker for bedre at forstå statistikkernes rolle og for at få vejledning i, hvordan du opretter manuel statistik for at forbedre ydeevnen af din forespørgsel. Men hvis ydeevnen for den første kørsel ikke er kritisk, kan du stole på automatisk statistik, der genereres i den første forespørgsel og fortsat vil blive udnyttet i efterfølgende kørsler (så længe de underliggende data ikke ændres væsentligt).
Hvis du bruger Power BI, skal du bruge Direct Lake-tilstand , hvor det er muligt.
Målepunkter for overvågning af ydeevne
Overvågningshubben indeholder i øjeblikket ikke Warehouse. Hvis du vælger Data Warehouse, kan du ikke få adgang til Overvågningshub på navigationslinjen.
Fabric-administratorer kan få adgang til rapporten Kapacitetsudnyttelse og målepunkter for at få opdaterede oplysninger, der sporer udnyttelsen af kapaciteten, der omfatter Warehouse.
Brug DV'er (Dynamic Management Views) til at overvåge udførelse af forespørgsler
Du kan bruge DMV'er (Dynamic Management Views) til at overvåge forbindelse, session og anmodningsstatus på lageret.
Statistik
Lageret bruger et forespørgselsprogram til at oprette en udførelsesplan for en given SQL-forespørgsel. Når du sender en forespørgsel, forsøger forespørgselsoptimeringsprogrammet at optælle alle mulige planer og vælge den mest effektive kandidat. Hvis du vil finde ud af, hvilken plan der kræver mindst omkostninger, skal programmet kunne evaluere den arbejdsmængde eller de rækker, der kan behandles af hver operator. Derefter vælger den på baggrund af de enkelte planers omkostninger den med den mindste mængde anslået arbejde. Statistik er objekter, der indeholder relevante oplysninger om dine data, så forespørgselsoptimeringsprogrammet kan beregne disse omkostninger.
Du kan også manuelt opdatere statistikker efter hver dataindlæsning eller dataopdatering for at sikre, at den bedste forespørgselsplan kan bygges.
Du kan få flere oplysninger om statistikker, og hvordan du kan øge den automatisk oprettede statistik, under Statistik i Fabric-datawarehousing.
Retningslinjer for dataindtagelse
Der er fire muligheder for dataindtagelse i et lager:
- KOPIÉR (Transact-SQL)
- Datapipelines
- Dataflows
- Indtagelse på tværs af lagre
Hvis du vil finde ud af, hvilken indstilling der er bedst for dig, og gennemse nogle af de bedste fremgangsmåder for dataindtagelse, skal du gennemse data til indfødning.
Gruppér INSERT-sætninger i batches (undgå trickle inserts)
En engangsbelastning af en lille tabel med en INSERT-sætning, som vist i følgende eksempel, kan være den bedste fremgangsmåde afhængigt af dine behov. Men hvis du har brug for at indlæse tusindvis eller millioner af rækker hele dagen, er singleton INSERTS ikke optimale.
INSERT INTO MyLookup VALUES (1, 'Type 1')
Du kan finde en vejledning i, hvordan du håndterer disse scenarier med snildebelastning, under Bedste fremgangsmåder til indtagelse af data.
Minimer transaktionsstørrelser
INSERT-, UPDATE- og DELETE-sætninger kører i en transaktion. Når de mislykkes, skal de rulles tilbage. Hvis du vil reducere risikoen for en lang annullering, skal du minimere transaktionsstørrelser, når det er muligt. Du kan minimere transaktionsstørrelser ved at opdele INSERT-, UPDATE- og DELETE-sætninger i dele. Hvis du f.eks. har en INSERT, som du forventer at tage 1 time, kan du opdele INSERT i fire dele. Hver kørsel forkortes derefter til 15 minutter.
Overvej at bruge CTAS (Transact-SQL) til at skrive de data, du vil beholde i en tabel, i stedet for at bruge DELETE. Hvis en CTAS tager den samme mængde tid, er det sikrere at køre, da den har minimal transaktionslogføring og kan annulleres hurtigt, hvis det er nødvendigt.
Collocate-klientprogrammer og Microsoft Fabric
Hvis du bruger klientprogrammer, skal du sørge for, at du bruger Microsoft Fabric i et område, der er tæt på din klientcomputer. Eksempler på klientprogrammer omfatter Power BI Desktop, SQL Server Management Studio og Azure Data Studio.
Udnyt datadesignet stjerneskema
Et stjerneskema organiserer data i faktatabeller og dimensionstabeller. Det faciliterer analysebehandling ved at deormalisere dataene fra meget normaliserede OLTP-systemer, indtage transaktionsdata og virksomhedsmasterdata til en fælles, renset og bekræftet datastruktur, der minimerer joinforbindelser på forespørgselstidspunktet, reducerer antallet af rækker, der læses og faciliterer sammenlægninger og grupperingsbehandling.
Du kan finde flere vejledninger til lagerdesign under Tabeller i datawarehousing.
Reducer størrelsen på forespørgselsresultatsæt
Hvis du reducerer størrelsen på forespørgselsresultatsæt, kan du undgå problemer på klientsiden, der skyldes store forespørgselsresultater. Resultatsættene i SQL Query-editor er begrænset til de første 10.000 rækker for at undgå disse problemer i denne browserbaserede brugergrænseflade. Hvis du har brug for at returnere mere end 10.000 rækker, skal du bruge SQL Server Management Studio (SSMS) eller Azure Data Studio.
Vælg den bedste datatype til ydeevne
Når du definerer dine tabeller, skal du bruge den mindste datatype, der understøtter dine data, da det vil forbedre forespørgslens ydeevne. Denne anbefaling er vigtig for kolonnerne CHAR og VARCHAR. Hvis den længste værdi i en kolonne er 25 tegn, skal du definere kolonnen som VARCHAR(25). Undgå at definere alle tegnkolonner med en stor standardlængde.
Brug heltalsbaserede datatyper, hvis det er muligt. Handlingerne SORT, JOIN og GROUP BY fuldføres hurtigere på heltal end på tegndata.
Du kan se understøttede datatyper og flere oplysninger under datatyper.
Ydeevne for SQL-analyseslutpunkt
Du kan finde oplysninger om og anbefalinger til ydeevnen for SQL-analyseslutpunktet under Overvejelser i forbindelse med ydeevnen for SQL-analyseslutpunkt.
Datakomprimering
Datakomprimering konsoliderer mindre Parquet-filer i færre, større filer, hvilket optimerer læsehandlinger. Denne proces hjælper også med effektivt at administrere slettede rækker ved at fjerne dem fra uforanderlige parquetfiler. Datakomprimeringsprocessen omfatter omskrivning af tabeller eller segmenter af tabeller til nye Parquet-filer, der er optimeret til ydeevne. Du kan få flere oplysninger under Blog: Automatisk datakomprimering for Fabric Warehouse.
Datakomprimeringsprocessen integreres problemfrit i lageret. Når forespørgsler udføres, identificerer systemet tabeller, der kan drage fordel af komprimering og udfører nødvendige evalueringer. Der er ingen manuel måde at udløse datakomprimering på.