Eventhouse- og KQL-databaseforbrug
Eventhouses - og KQL-databaser fungerer på et fuldt administreret Kusto-program. Med en Eventhouse- eller KQL-database kan du forvente tilgængelig beregning for din analyse inden for 5 til 10 sekunder. Beregningsressourcerne vokser med dine dataanalysebehov. I denne artikel forklares rapportering af beregningsforbrug for KQL-databaser i Microsoft Fabric, herunder KustoUpTime og lager.
Når du bruger en Fabric-kapacitet, vises dine forbrugsgebyrer i Azure-portal under dit abonnement i Microsoft Cost Management. Hvis du vil forstå din Fabric-fakturering, skal du gå til Forstå din Azure-faktura på en Fabric-kapacitet.
Vigtigt
Ændringer i forbrugsfrekvensen for Microsoft Fabric-arbejdsbelastninger
Forbrugssatserne kan ændres når som helst. Microsoft vil gøre en rimelig indsats for at give besked via mail eller via meddelelse i produktet. Ændringerne træder i kraft på den dato, der er angivet i Microsofts produktbemærkninger eller Microsoft Fabric Blog. Hvis en ændring af en Microsoft Fabric-arbejdsbelastningsforbrugsrate øger de kapacitetsenheder (CU), der kræves for at bruge en bestemt arbejdsbelastning, kan kunderne bruge de annulleringsmuligheder, der er tilgængelige for den valgte betalingsmetode.
Kapacitet
Baseret på den kapacitets-SKU, der blev købt i Fabric, har du ret til et sæt kapacitetsenheder (CU'er), der deles på tværs af alle Fabric-arbejdsbelastninger. Du kan få flere oplysninger om understøttede licenser under Microsoft Fabric-licenser.
Kapacitet er et dedikeret sæt ressourcer, der er tilgængelige på et givet tidspunkt, og som skal bruges. Kapacitet definerer en ressources mulighed for at udføre en aktivitet eller producere output. Forskellige ressourcer forbruger CU'er på forskellige tidspunkter. Den kapacitet, der bruges af en KQL-database, er baseret på handlingen KustoUpTime .
KustoUpTime
KustoUpTime for et eventhouse er antallet af sekunder, som dit eventhouse er aktivt i forhold til antallet af virtuelle kerner, der bruges af dit eventhouse. Der bruges en automatisk skaleringsmekanisme til at bestemme størrelsen på dit eventhouse. Denne mekanisme sikrer optimering af omkostninger og ydeevne baseret på dit forbrugsmønster. Et eventhouse med flere KQL-databaser knyttet til det viser kun KustoUpTime for eventhouse-elementet. Du kan ikke se brugen af KQL-databasens underelement.
Et eventhouse med 4 KQL-databaser, der bruger fire virtuelle kerner, der er aktive i 30 sekunder, bruger f.eks. 120 sekunders kapacitetsenheder.
KustoUpTime for en KQL-database er det antal sekunder, som din KQL-database er aktiv i forhold til antallet af virtuelle kerner, der bruges af databasen. Der bruges en automatisk skaleringsmekanisme til at bestemme størrelsen af din KQL-database. Denne mekanisme sikrer optimering af omkostninger og ydeevne baseret på dit forbrugsmønster.
En database, der bruger fire virtuelle kerner, der er aktive i 30 sekunder, bruger f.eks. 120 sekunders kapacitetsenheder.
Bemærk
Hvis din KQL-database er et underelement i et hændelseshus, genforenes KustoUpTime i eventhouse-elementet, og databaseelementet vises ikke på listen.
Overvåg KustoUpTime
Du kan overvåge KustoUpTime med appen Microsoft Fabric Capacity Metric. Få mere at vide om, hvordan du forstår beregningssiden for appen Metrics på siden Forstå beregningssiden for appen målepunkter. I dette eksempel vises oplysninger, der er specifikke for overvågning af KustoUpTime.
Bemærk
Du skal være kapacitetsadministrator for at overvåge kapacitetsforbruget. Du kan få flere oplysninger under Forstå Microsoft Fabric-administratorroller.
På følgende billede kan du se et eksempel på en beregningsside fra overvågningskapaciteten i appen Fabric Capacity Metric:
Her er nogle indsigter, du kan tage fra eksemplet:
- Den kapacitet, der undersøges, kaldes rtafielddemo.
- Kapacitetsenhederne for den valgte dag blev brugt af et enkelt arbejdsområde med navnet RTA-feltdemo.
- Visningen Elementer er filtreret, så den viser både Eventhouse og KQL Database.
- Når du vælger et enkelt element, f.eks. et Eventhouse-element, opdeles cu-forbruget efter handlinger.
- Grafen over udnyttelse i højre side af appen viser næsten 100 % forbrug af CU over tid. Denne høje udnyttelse kan forklare forespørgselsbegrænsning, der opleves af brugere, og angiver et behov for at øge kapacitetsenhederne.
Lagerfakturering
Lagerplads faktureres separat fra dine Fabric- eller Power BI Premium Capacity-enheder. Data, der indtages i en KQL-database, gemmes i to lagerniveauer: OneLake Cache Storage og OneLake Standard Storage.
- OneLake Cache Storage er premiumlager, der bruges til at levere de hurtigste svartider for forespørgsler. Når du angiver cachepolitikken, påvirker du dette lagerniveau. Hvis du f.eks. typisk forespørger syv dage tilbage, kan du angive cacheopbevaring til syv dage for at opnå den bedste ydeevne. Dette lagerniveau kan sammenlignes med Premium-niveauet Azure ADLS (Azure Data Lake Storage).
Bemærk
Aktivering af minimumforbrug betyder, at du ikke faktureres for OneLake Cahce Storage. Når minimumkapaciteten er angivet, er hændelseshuset altid aktivt, hvilket resulterer i 100 % KustoUpTime.
- OneLake Standard Storage er standardlager, der bruges til at bevare og gemme alle data, der kan forespørges om. Når du angiver opbevaringspolitikken, påvirker du dette lagerniveau. Hvis du f.eks. har brug for at bevare 365 dages data, der kan forespørges om, kan du angive opbevaringen til 365 dage. Dette lagerniveau kan sammenlignes med det hotte Azure ADLS-niveau (Azure Data Lake Storage).
Overvåg OneLake Storage
Microsoft Fabric Capacity Metric-appen giver alle kapacitetsadministratorer mulighed for at overvåge OneLake Storage. Få mere at vide om, hvordan du forstår siden Lagring af metrics-appen på siden Om siden til lagring af målepunkter i appen.
På følgende billede vises en eksempellagerside fra overvågning af en KQL-database i appen Fabric Capacity Metric:
