Retningslinjer for fabric data warehouse-ytelse
Gjelder for:✅ Lager i Microsoft Fabric
Dette er retningslinjer for å hjelpe deg med å forstå ytelsen til lageret i Microsoft Fabric. I denne artikkelen finner du veiledning og viktige artikler å fokusere på. Warehouse i Microsoft Fabric er en SaaS-plattform der aktiviteter som arbeidsbelastningsadministrasjon, samtidighet og lagringsadministrasjon administreres internt av plattformen. I tillegg til denne interne ytelsesstyringen kan du fortsatt forbedre ytelsen ved å utvikle performant-spørringer mot velutformede lagre.
Ytelse for kald kjøring (kald hurtigbuffer)
Hurtigbufring med lokal SSD og minne er automatisk. De første 1-3 kjøringene av en spørring utfører merkbart langsommere enn etterfølgende kjøringer. Hvis du opplever ytelsesproblemer med kaldt kjøring, kan du gjøre et par ting som kan forbedre ytelsen for kald kjøring:
Hvis ytelsen for den første kjøringen er avgjørende, kan du prøve å opprette statistikk manuelt. Se gjennom statistikkartikkelen for bedre å forstå statistikkrollen og for veiledning om hvordan du oppretter manuell statistikk for å forbedre spørringsytelsen. Hvis ytelsen for den første kjøringen ikke er kritisk, kan du imidlertid stole på automatisk statistikk som vil bli generert i den første spørringen, og vil fortsette å bli utnyttet i etterfølgende kjøringer (så lenge underliggende data ikke endres betydelig).
Hvis du bruker Power BI, kan du bruke Direct Lake-modus der det er mulig.
Måledata for overvåkingsytelse
Overvåkingshuben inkluderer for øyeblikket ikke Lager. Hvis du velger Data Warehouse, får du ikke tilgang til overvåkingshuben fra navigasjonsfeltet.
Fabric-administratorer vil kunne få tilgang til rapporten kapasitetsutnyttelse og måledata for oppdatert informasjon som sporer bruken av kapasitet som inkluderer Warehouse.
Bruk dynamiske administrasjonsvisninger (DMV-er) til å overvåke kjøring av spørring
Du kan bruke dynamiske administrasjonsvisninger (DMV-er) til å overvåke tilkoblings-, økt- og forespørselsstatus i lageret.
Statistikk
Lageret bruker en spørringsmotor til å opprette en utførelsesplan for en gitt SQL-spørring. Når du sender inn en spørring, prøver spørringsoptimaliseringen å nummerere alle mulige planer og velge den mest effektive kandidaten. For å finne ut hvilken plan som krever minst kostnader, må motoren kunne evaluere mengden arbeid eller rader som kan behandles av hver operator. Deretter, basert på hver plankostnad, velger den den med minst beregnet arbeid. Statistikk er objekter som inneholder relevant informasjon om dataene, slik at spørringsoptimaliseringen kan beregne disse kostnadene.
Du kan også oppdatere statistikk manuelt etter hver datainnlasting eller dataoppdatering for å sikre at den beste spørringsplanen kan bygges.
Hvis du vil ha mer informasjon om statistikk og hvordan du kan utvide den automatisk opprettede statistikken, kan du se Statistikk i datalager for stoff.
Retningslinjer for datainntak
Det finnes fire alternativer for datainntak i et lager:
- COPY (Transact-SQL)
- Datasamlebånd
- Dataflyt
- Inntak på tvers av lager
Hvis du vil finne ut hvilket alternativ som passer best for deg og se gjennom anbefalte fremgangsmåter for datainntak, kan du se gjennom Inntaksdata.
Grupper INSERT-setninger i grupper (unngå trickle-innsettinger)
En engangsbelastning til en liten tabell med en INSERT-setning, for eksempel vist i eksemplet nedenfor, kan være den beste tilnærmingen avhengig av behovene dine. Hvis du imidlertid trenger å laste inn tusenvis eller millioner av rader i løpet av dagen, er ikke singleton INSERTS optimal.
INSERT INTO MyLookup VALUES (1, 'Type 1')
Hvis du vil ha veiledning om hvordan du håndterer disse scenarioene for dryppbelastning, kan du se Anbefalte fremgangsmåter for inntak av data.
Minimere transaksjonsstørrelser
INSERT-, UPDATE- og DELETE-setninger kjører i en transaksjon. Når de mislykkes, må de rulles tilbake. Hvis du vil redusere potensialet for en lang tilbakerulling, minimerer du transaksjonsstørrelsene når det er mulig. Minimering av transaksjonsstørrelser kan gjøres ved å dele INSERT-, UPDATE- og DELETE-setninger i deler. Hvis du for eksempel har en INSERT som du forventer tar 1 time, kan du dele opp INSERT i fire deler. Hver kjøring vil da bli forkortet til 15 minutter.
Vurder å bruke CTAS (Transact-SQL) til å skrive dataene du vil beholde i en tabell i stedet for å bruke DELETE. Hvis en CTAS tar like lang tid, er det tryggere å kjøre siden den har minimal transaksjonslogging og kan avbrytes raskt om nødvendig.
Kolloker klientprogrammer og Microsoft Fabric
Hvis du bruker klientprogrammer, må du kontrollere at du bruker Microsoft Fabric i et område som er nær klientdatamaskinen. Eksempler på klientprogram inkluderer Power BI Desktop, SQL Server Management Studio og Azure Data Studio.
Bruk utforming av stjerneskjemadata
Et stjerneskjema organiserer data i faktatabeller og dimensjonstabeller. Det forenkler analysebehandling ved å denormalisere dataene fra svært normaliserte OLTP-systemer, inntak av transaksjonsdata og hoveddata for virksomheter til en felles, renset og verifisert datastruktur som minimerer sammenføyninger ved spørringstidspunktet, reduserer antall rader som leses og forenkler aggregasjoner og grupperingsbehandling.
Hvis du vil ha mer veiledning for lagerutforming, kan du se Tabeller i datalager.
Redusere størrelsene på spørringsresultatsett
Hvis du reduserer størrelsen på spørringsresultatsettet, unngår du problemer på klientsiden forårsaket av store spørringsresultater. Resultatsettene for SQL Query-redigeringsprogrammet er begrenset til de første 10 000 radene for å unngå disse problemene i dette nettleserbaserte brukergrensesnittet. Hvis du trenger å returnere mer enn 10 000 rader, kan du bruke SQL Server Management Studio (SSMS) eller Azure Data Studio.
Velg den beste datatypen for ytelse
Når du definerer tabellene, kan du bruke den minste datatypen som støtter dataene, for å forbedre spørringsytelsen. Denne anbefalingen er viktig for CHAR- og VARCHAR-kolonner. Hvis den lengste verdien i en kolonne er 25 tegn, definerer du kolonnen som VARIANSCHAR(25). Unngå å definere alle tegnkolonner med en stor standardlengde.
Bruk heltallsbaserte datatyper hvis mulig. OPERASJONENE SORTER, BLI MED og GRUPPER ETTER fullføres raskere på heltall enn på tegndata.
Hvis du vil ha mer informasjon om støttede datatyper, kan du se datatyper.
Sql Analytics-endepunktytelse
Hvis du vil ha informasjon og anbefalinger om ytelsen til SQL Analytics-endepunktet, kan du se ytelsesvurderinger for SQL Analytics-endepunktet.
Datakomprimering
Datakomprimering konsoliderer mindre Parquet-filer til færre, større filer, som optimaliserer leseoperasjoner. Denne prosessen hjelper også med effektiv administrasjon av slettede rader ved å fjerne dem fra uforanderlige parquet-filer. Datakomprimeringsprosessen innebærer å skrive tabeller eller segmenter av tabeller på nytt til nye Parquet-filer som er optimalisert for ytelse. Hvis du vil ha mer informasjon, kan du se Blogg: Automatisk datakomprimering for Fabric Warehouse.
Datakomprimeringsprosessen integreres sømløst i lageret. Når spørringer utføres, identifiserer systemet tabeller som kan dra nytte av komprimering og utføre nødvendige evalueringer. Det finnes ingen manuell måte å utløse datakomprimering på.