Förbrukning av Eventhouse- och KQL-databas
Eventhouses - och KQL-databaser fungerar på en fullständigt hanterad Kusto-motor. Med en Eventhouse- eller KQL-databas kan du förvänta dig tillgänglig beräkning för din analys inom 5 till 10 sekunder. Beräkningsresurserna växer med dina dataanalysbehov. Den här artikeln beskriver rapportering av beräkningsanvändning för KQL-databaserna i Microsoft Fabric, inklusive KustoUpTime och lagring.
När du använder en Infrastrukturkapacitet visas dina användningsavgifter i Azure Portal under din prenumeration i Microsoft Cost Management. Om du vill förstå din Infrastrukturfakturering går du till Förstå din Azure-faktura på en Infrastrukturkapacitet.
Viktigt!
Ändringar i förbrukningsfrekvensen för Microsoft Fabric-arbetsbelastningar
Förbrukningsfrekvensen kan ändras när som helst. Microsoft kommer att använda rimliga ansträngningar för att meddela via e-post eller via produktmeddelande. Ändringarna ska gälla den dag som anges i Microsofts viktig information eller Microsoft Fabric-blogg. Om någon ändring av förbrukningstakten för Microsoft Fabric-arbetsbelastningar väsentligt ökar de kapacitetsenheter (CU) som krävs för att använda en viss arbetsbelastning kan kunderna använda de avbokningsalternativ som är tillgängliga för den valda betalningsmetoden.
Kapacitet
Baserat på den kapacitets-SKU som köptes i Infrastrukturresurser har du rätt till en uppsättning kapacitetsenheter (CUs) som delas mellan alla infrastrukturarbetsbelastningar. Mer information om licenser som stöds finns i Microsoft Fabric-licenser.
Kapacitet är en dedikerad uppsättning resurser som är tillgängliga vid en viss tidpunkt som ska användas. Kapacitet definierar möjligheten för en resurs att utföra en aktivitet eller att producera utdata. Olika resurser förbrukar processorer vid olika tidpunkter. Mängden kapacitet som används av en KQL-databas baseras på kustoUpTime-åtgärden .
KustoUpTime
KustoUpTime för ett händelsehus är det antal sekunder som händelsehuset är aktivt i förhållande till antalet virtuella kärnor som används av händelsehuset. En autoskalningsmekanism används för att fastställa storleken på händelsehuset. Den här mekanismen säkerställer kostnads- och prestandaoptimering baserat på ditt användningsmönster. Ett händelsehus med flera KQL-databaser kopplade till det visar bara KustoUpTime för eventhouse-objektet. Du kommer inte att se användning för KQL-databasens underobjekt.
Till exempel använder ett händelsehus med 4 KQL-databaser med 4 virtuella kärnor som är aktiva i 30 sekunder 120 sekunder kapacitetsenheter.
KustoUpTime för en KQL-databas är det antal sekunder som KQL-databasen är aktiv i förhållande till antalet virtuella kärnor som används av databasen. En autoskalningsmekanism används för att fastställa storleken på din KQL-databas. Den här mekanismen säkerställer kostnads- och prestandaoptimering baserat på ditt användningsmönster.
Till exempel använder en databas med 4 virtuella kärnor som är aktiv i 30 sekunder 120 sekunder kapacitetsenheter.
Kommentar
Om din KQL-databas är ett underobjekt i ett händelsehus, smittas KustoUpTime på nytt i eventhouse-objektet och databasobjektet visas inte i listan.
Övervaka KustoUpTime
Du kan övervaka KustoUpTime med appen Kapacitetsmått för Microsoft Fabric. Lär dig hur du förstår sidan för beräkning av måttappen på sidan Förstå beräkningssidan för måttappen. Det här exemplet visar information som är specifik för övervakning av KustoUpTime.
Kommentar
Du måste vara kapacitetsadministratör för att övervaka kapacitetsanvändningen. Mer information finns i Förstå administratörsroller för Microsoft Fabric.
Följande bild visar ett exempel på en beräkningssida från övervakningskapaciteten i appen Infrastrukturkapacitetsmått:
Här följer några insikter som du kan ta från exemplet:
- Kapaciteten som undersöks kallas rtafielddemo.
- Kapacitetsenheterna för den valda dagen användes av en enda arbetsyta med namnet RTA Field Demo.
- Vyn Objekt har filtrerats för att visa både Eventhouse och KQL Database.
- Om du väljer ett enskilt objekt, till exempel ett Eventhouse-objekt, delas CU-användningen efter åtgärder.
- Användningsdiagrammet till höger i appen visar nästan 100 % CU-användning över tid. Den här höga användningen kan förklara frågebegränsning som användarna upplever och anger ett behov av att öka kapacitetsenheterna.
Lagringsfakturering
Lagring faktureras separat från dina Fabric- eller Power BI Premium-kapacitetsenheter. Data som matas in i en KQL-databas lagras på två lagringsnivåer: OneLake Cache Storage och OneLake Standard Storage.
- OneLake Cache Storage är premiumlagring som används för att tillhandahålla de snabbaste frågesvarstiderna. När du anger cacheprincipen påverkar du den här lagringsnivån. Om du till exempel vanligtvis frågar tillbaka sju dagar kan du ange cachekvarhållningen till sju dagar för bästa prestanda. Den här lagringsnivån är jämförbar med Premium-nivån för Azure ADLS (Azure Data Lake Storage).
Kommentar
Om du aktiverar minsta förbrukning debiteras du inte för OneLake Cache Storage. När minsta kapacitet har angetts är händelsehuset alltid aktivt, vilket resulterar i 100 % KustoUpTime.
- OneLake Standard Storage är standardlagring som används för att bevara och lagra alla frågebara data. När du anger kvarhållningsprincipen påverkar du den här lagringsnivån. Om du till exempel behöver underhålla 365 dagars frågedata kan du ange kvarhållningen till 365 dagar. Den här lagringsnivån är jämförbar med den frekventa nivån för Azure ADLS (Azure Data Lake Storage).
Övervaka OneLake Storage
Med appen Kapacitetsmått för Microsoft Fabric kan alla kapacitetsadministratörer övervaka OneLake Storage. Lär dig hur du förstår lagringssidan för måttappen på sidan Förstå lagringssidan för måttappen.
Följande bild visar en exempellagringssida från övervakning av en KQL-databas i appen Infrastrukturkapacitetsmått:
