Eventhouse- og KQL-databaseforbruk
Eventhouses - og KQL-databaser opererer på en fullstendig administrert Kusto-motor. Med en Eventhouse- eller KQL-database kan du forvente tilgjengelig databehandling for analysen innen 5 til 10 sekunder. Databehandlingsressursene vokser med dine dataanalysebehov. Denne artikkelen forklarer rapportering av databehandling av KQL-databasene i Microsoft Fabric, inkludert KustoUpTime og lagring.
Når du bruker en Fabric-kapasitet, vises brukskostnadene i Azure-portalen under abonnementet ditt i Microsoft Cost Management. Hvis du vil forstå stofffaktureringen, kan du gå til Forstå Azure-fakturaen på en Fabric-kapasitet.
Viktig
Endringer i forbrukshastigheten for Arbeidsbelastning for Microsoft Fabric
Forbrukssatser kan endres når som helst. Microsoft vil bruke rimelig innsats for å varsle via e-post eller via produktvarsling. Endringer trer i kraft på datoen som er angitt i Microsofts produktmerknader eller Microsoft Fabric Blog. Hvis endringer i en forbrukssats for arbeidsbelastning i Microsoft Fabric øker kapasitetsenhetene (CU) som kreves for å bruke en bestemt arbeidsbelastning, kan kunder bruke avbestillingsalternativene som er tilgjengelige for den valgte betalingsmåten.
Kapasitet
Basert på SKU-en for kapasitet som ble kjøpt i Fabric, har du rett til et sett med kapasitetsenheter (CUer) som deles på tvers av alle fabric-arbeidsbelastninger. Hvis du vil ha mer informasjon om lisenser som støttes, kan du se Microsoft Fabric-lisenser.
Kapasitet er et dedikert sett med ressurser som er tilgjengelig på et gitt tidspunkt som skal brukes. Kapasitet definerer en ressurss mulighet til å utføre en aktivitet eller produsere utdata. Ulike ressurser bruker CUs på forskjellige tidspunkter. Mengden kapasitet som brukes av en KQL-database, er basert på KustoUpTime-operasjonen .
KustoUpTime
KustoUpTime for et eventhouse er antall sekunder eventhouse er aktivt i forhold til antall virtuelle kjerner som brukes av eventhouse. En autoskalamekanisme brukes til å bestemme størrelsen på hendelseshuset. Denne mekanismen sikrer kostnads- og ytelsesoptimalisering basert på bruksmønsteret. Et hendelseshus med flere KQL-databaser knyttet til det, viser bare KustoUpTime for eventhouse-elementet. Du vil ikke se bruk for delelementet KQL-database.
Et hendelseshus med 4 KQL-databaser som bruker fire virtuelle kjerner som er aktive i 30 sekunder, bruker for eksempel 120 sekunder med kapasitetsenheter.
KustoUpTime for en KQL-database er antall sekunder KQL-databasen er aktiv i forhold til antall virtuelle kjerner som brukes av databasen. En autoskalamekanisme brukes til å bestemme størrelsen på KQL-databasen. Denne mekanismen sikrer kostnads- og ytelsesoptimalisering basert på bruksmønsteret.
En database som bruker fire virtuelle kjerner som er aktive i 30 sekunder, bruker for eksempel 120 sekunder med kapasitetsenheter.
Merk
Hvis KQL-databasen er et underelement i et hendelseshus, blir KustoUpTime endret i hendelseshuset, og databaseelementet vises ikke i listen.
Overvåk KustoUpTime
Du kan overvåke KustoUpTime med Microsoft Fabric Capacity Metric-appen. Finn ut hvordan du forstår databehandlingssiden for Måledata-appen i Forstå måledataapp-databehandlingssiden. Dette eksemplet viser informasjon som er spesifikk for overvåking av KustoUpTime.
Merk
Du må være kapasitetsadministrator for å overvåke kapasitetsbruk. Hvis du vil ha mer informasjon, kan du se Forstå administratorroller for Microsoft Fabric.
Følgende bilde viser en eksempeldataside fra overvåkingskapasiteten i den metriske stoffkapasitetsappen:
Her er noen innsikter du kan ta fra eksemplet:
- Kapasiteten som undersøkes kalles rtafielddemo.
- Kapasitetsenhetene for den valgte dagen ble brukt av ett enkelt arbeidsområde kalt RTA Field Demo.
- Elementer-visningen er filtrert for å vise både Eventhouse og KQL Database.
- Hvis du velger ett enkelt element, for eksempel et Eventhouse-element, brytes cu-bruken etter operasjoner.
- Bruksdiagrammet, på høyre side av appen, viser nesten 100 % CU-bruk over tid. Denne høye bruken kan forklare spørringsbegrensning som brukere opplever, og indikerer et behov for å øke kapasitetsenhetene.
Fakturering av lagringsplass
Lagring faktureres separat fra fabric- eller Power BI Premium-kapasitetsenhetene. Data som inntas i en KQL-database, lagres i to lagringsnivåer: OneLake Cache Storage og OneLake Standard Storage.
- OneLake Cache Storage er premium lagringsplass som brukes til å gi de raskeste svartidene for spørringer. Når du angir hurtigbufferpolicyen, påvirker du dette lagringsnivået. Hvis du for eksempel vanligvis spør etter sju dager tilbake, kan du angi at hurtigbufferen skal ha sju dager for best ytelse. Dette lagringsnivået kan sammenlignes med Premium-nivået i Azure ADLS (Azure Data Lake Storage).
Merk
Aktivering av minimumsforbruk betyr at du ikke belastes for OneLake Cache Storage. Når minimumskapasitet er angitt, er hendelseshuset alltid aktivt, noe som resulterer i 100 % KustoUpTime.
- OneLake Standard Storage er standard lagringsplass som brukes til å beholde og lagre alle spørringsbare data. Når du angir oppbevaringspolicyen, påvirker du dette lagringsnivået. Hvis du for eksempel trenger å vedlikeholde 365 dager med spørringsdata, kan du angi oppbevaringen til 365 dager. Dette lagringsnivået kan sammenlignes med azure ADLS (Azure Data Lake Storage) hot tier.
Overvåk OneLake Storage
Microsoft Fabric Capacity Metric-appen gjør det mulig for enhver kapasitetsadministrator å overvåke OneLake Storage. Lær hvordan du forstår lagringssiden for Måledata-appen i Forstå lagringssiden for måledata-appen.
Følgende bilde viser en eksempellagringsside fra overvåking av en KQL-database i måleappen for stoffkapasitet:
