Händelsehus och KQL-databasförbrukning

Händelsehus och KQL-databaser fungerar på en fullständigt hanterad Kusto-motor. Med en Händelsehus- 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-portalen 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 ditt händelsehus är aktivt i förhållande till antalet virtuella kärnor som används av ditt händelsehus. En autoskalningsmekanism används för att fastställa storleken på ditt händelsehus. 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 händelsehusobjektet. 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 händelsehusobjektet 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 Event House och KQL Database.
• Om du väljer ett enskilt objekt, till exempel ett händelsehusobjekt, 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 Cahce 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:

Relaterat innehåll

• Begrepp och licenser för Microsoft Fabric
• Vad är appen Kapacitetsmått för Microsoft Fabric?
• Skapa en KQL-databas