Eventhouse- en KQL-databaseverbruik

Eventhouses en KQL-databases worden uitgevoerd op een volledig beheerde engine. Met een Eventhouse- of KQL-database kunt u binnen 5 tot 10 seconden beschikbare berekeningen voor uw analyses verwachten. De rekenresources groeien met uw gegevensanalytische behoeften. In dit artikel wordt het rekengebruik van de KQL-databases in Microsoft Fabric uitgelegd, waaronder Eventhouse UpTime en storage.

Wanneer u een Fabric-capaciteit gebruikt, worden uw gebruikskosten weergegeven in de Azure-portal onder uw abonnement in Microsoft Cost Management. Als u uw Fabric-facturering wilt begrijpen, ga dan naar Begrijp uw Azure-factuur op een Fabric-capaciteit.

Capaciteit

Op basis van de SKU die in Fabric is gekocht, hebt u recht op een set capaciteitseenheden die worden gedeeld over alle Fabric workloads. Zie Microsoft Fabric-licenties voor meer informatie over ondersteunde licenties.

Capaciteit is een toegewezen set resources die op een bepaald moment beschikbaar zijn om te worden gebruikt. Capaciteit definieert de mogelijkheid van een resource om een activiteit uit te voeren of uitvoer te produceren. Verschillende resources verbruiken CU's op verschillende tijdstippen. De hoeveelheid capaciteit die door een KQL-database wordt gebruikt, is gebaseerd op de Eventhouse UpTime bewerking.

Geplande minimale capaciteit (Capacity Scheduler)

Eventhouse ondersteunt een terugkerende planning van 7 dagen in blokken van 60 minuten, waar u een minimale capaciteit per blok of geen minimum kunt instellen, terwijl automatische schaalaanpassing ingeschakeld blijft. Hiermee wordt gegarandeerde capaciteit afgestemd op uw workloadpatronen, bijvoorbeeld door een hogere basislijn te berekenen tijdens piekuren van het bedrijf en het eventhouse vrij te laten schalen tijdens rustigere perioden. Wanneer een minimum is ingesteld voor een tijdvenster, geeft Eventhouse UpTime ten minste de geplande basislijn weer voor de duur van dat venster. Zie Capacity Scheduler configureren voor meer informatie.

Throttling

Wanneer capaciteitslimieten worden bereikt, past het eventhouse throttling toe om de stabiliteit van het systeem te beschermen. Er zijn drie niveaus van throttling:

• Proactief : query's worden beperkt, maar gegevensopname wordt normaal voortgezet.
• Reactief : zowel opname als query's worden onderbroken, maar er gaan geen gegevens verloren.
• Extreem reactief : opname en query's worden onderbroken, gegevens worden gedurende een bepaalde periode bewaard, maar gegevens kunnen na een bepaalde periode verloren gaan.

Wanneer een evenementenhuis proactief overgaat, wordt de capaciteit beperkt om de beschikbaarheid gedurende een langere periode te behouden voor kleine acties (proactief en reactief), waarbij de beschikbaarheid van evenementenhuizen met verminderde prestaties behouden blijft.

Het configureren van geplande minimumcapaciteit kan de kans op proactieve of reactieve throttling tijdens verwachte piekbelasting verkleinen door ervoor te zorgen dat er basiscomputecapaciteit beschikbaar is. Beperking kan echter nog steeds optreden als de werkelijke vraag groter is dan de geplande basislijn en de beschikbare capaciteit.

Overspanningsbeveiliging op werkruimteniveau

Overspanningsbeveiliging omvat nu besturingselementen op het niveau van werkruimtes die een nauwkeuriger beheer van het gebruik van rekencapaciteit binnen uw organisatie mogelijk maken. Met deze update kunt u het capaciteitsgebruik beter beheren en kritieke workloads prioriteren.

Belangrijke verbeteringen

CU per werkruimte % limieten: u kunt een verbruiksdrempel voor rekeneenheden (CU) definiëren voor afzonderlijke werkruimten, als percentage van het totale capaciteitsgebruik. Deze drempelwaarden worden ingesteld gedurende een periode van 24 uur.

Automatische blokkering: een werkruimte wordt automatisch in een geblokkeerde status geplaatst wanneer de werkruimte de drempelwaarde overschrijdt. De werkruimte weigert nieuwe bewerkingen totdat het gebruik onder de drempelwaarde daalt of totdat u het blok handmatig verwijdert.

Bedrijfskritieke modus: u kunt werkruimten met hoge prioriteit als bedrijfskritiek aanwijzen, waardoor ze worden uitgesloten van beveiligingsregels voor pieken en deze effectief prioriteit krijgt boven andere werkruimten. Deze modus kan ook worden gebruikt om een actieve geblokkeerde status te verwijderen.

Zie Bescherming tegen pieken voor meer informatie over de Fabric capaciteitsniveau beveiliging tegen pieken.

Eventhouse UpTime

Eventhouse UpTime voor een eventhouse het aantal seconden is dat uw eventhouse actief is ten opzichte van het aantal virtuele kernen dat door uw eventhouse wordt gebruikt. Er wordt een mechanisme voor automatische schaalaanpassing gebruikt om de grootte van uw eventhouse te bepalen. Dit mechanisme zorgt voor kosten- en prestatieoptimalisatie op basis van uw gebruikspatroon. Een eventhouse met meerdere KQL-databases die eraan zijn gekoppeld, toont alleen Eventhouse UpTime voor het eventhouse-item. U ziet geen gebruik voor het subitem van de KQL-database.

Een eventhouse met 4 KQL-databases met vier virtuele kernen die gedurende 30 seconden actief is, gebruikt bijvoorbeeld 120 seconden capaciteitseenheden.

Eventhouse UpTime voor een KQL-database het aantal seconden is dat uw KQL-database actief is ten opzichte van het aantal virtuele kernen dat door uw database wordt gebruikt. Er wordt een mechanisme voor automatische schaalaanpassing gebruikt om de grootte van uw KQL-database te bepalen. Dit mechanisme zorgt voor kosten- en prestatieoptimalisatie op basis van uw gebruikspatroon.

Een database met vier virtuele kernen die gedurende 30 seconden actief is, gebruikt bijvoorbeeld 120 seconden capaciteitseenheden.

Wanneer een geplande minimale capaciteit is geconfigureerd, wordt UpTime gedurende de geplande vensters ten minste berekend op basis van de geplande basiswaarde. Buiten geplande vensters weerspiegelt UpTime het elastische gebruik dat wordt aangestuurd door automatische schaalaanpassing. Dit onderscheid helpt u bij het nauwkeurig interpreteren van verbruiksrapporten.

Eventhouse UpTime monitoren

U kunt Eventhouse UpTime- bewaken met de Microsoft Fabric Capacity Metric-app. Kom te weten hoe u de compute-pagina van de Metrics-app kunt begrijpen in De calculate-pagina van de Metrics-app begrijpen. In dit voorbeeld ziet u informatie die specifiek is voor het bewaken van Eventhouse UpTime-.

In de volgende afbeelding ziet u een voorbeeld van een compute-pagina voor capaciteitsbewaking in de app Fabric Capacity Metric:

Hier volgen enkele inzichten die u uit het voorbeeld kunt halen:

• De capaciteit die wordt onderzocht, wordt rtafielddemo genoemd.
• De capaciteitseenheden voor de geselecteerde dag zijn gebruikt door één werkruimte met de naam RTA Field Demo.
• De weergave Items wordt gefilterd om zowel Eventhouse als KQL Database weer te geven.
• Selecteer één item, zoals een Eventhouse-item, om het CU-gebruik per bewerking op te delen.
• In de gebruiksgrafiek wordt aan de rechterkant van de app bijna 100% CU-gebruik in de loop van de tijd weergegeven. Het hoge gebruik kan de query-beperking verklaren zoals door gebruikers ervaren en geeft aan dat de capaciteitseenheden verhoogd moeten worden.

Wanneer Capacity Scheduler is geconfigureerd, kan de Fabric Capacity Metrics-app tijdens geplande perioden een hoger basislijn-CU-gebruik weergeven. Correleer de geplande vensters met de gebruiksgrafiek om het capaciteitsverbruik nauwkeurig te interpreteren.

Facturering voor opslag

Opslag wordt afzonderlijk gefactureerd van uw Fabric- of Power BI Premium-capaciteitseenheden. Gegevens die zijn opgenomen in een KQL-database, worden opgeslagen in twee opslaglagen: OneLake Cache Storage en OneLake Standard Storage.

• OneLake Cache Storage is premium-opslag die wordt gebruikt om de snelste reactietijden voor query's te bieden. Wanneer u het cachebeleid instelt, is dit van invloed op deze opslaglaag. Als u bijvoorbeeld meestal zeven dagen een query uitvoert, kunt u de cacheretentie instellen op zeven dagen voor de beste prestaties. Deze opslaglaag is vergelijkbaar met de Premium-laag van Azure ADLS (Azure Data Lake Storage).

  Notitie

  Als u De Capacity Scheduler inschakelt, worden er geen kosten in rekening gebracht voor OneLake Cache Storage. Wanneer een gepland minimum is geconfigureerd, onderhoudt het eventhouse een gegarandeerde basislijn tijdens deze vensters, terwijl het elastisch blijft met automatische schaalaanpassing buiten de vensters. Kosten voor cacheopslag zijn opgenomen in de capaciteitskosten. Zie Capacity Scheduler configureren voor meer informatie.

• OneLake Standard Storage is standaardopslag die wordt gebruikt om alle querybare gegevens te behouden en op te slaan. Wanneer u het bewaarbeleid instelt, is dit van invloed op deze opslaglaag. Als u bijvoorbeeld 365 dagen aan querybare gegevens wilt onderhouden, kunt u de retentie instellen op 365 dagen. Deze opslaglaag is vergelijkbaar met de dynamische laag Azure ADLS (Azure Data Lake Storage).

OneLake Storage bewaken

Met de microsoft Fabric Capacity Metric-app kan elke capaciteitsbeheerder OneLake Storage bewaken. Meer informatie over het begrijpen van de opslagpagina van de app voor metrische gegevens in De opslagpagina van de app voor metrische gegevens.

In de volgende afbeelding ziet u een voorbeeldopslagpagina van het bewaken van een KQL-database in de app Fabric Capacity Metric:

Gerelateerde inhoud

• Concepten en licenties van Microsoft Fabric
• Wat is de Microsoft Fabric Capacity Metrics app?
• Eventhouse rekengebruik
• Overspanningsbeveiliging