Loggkomprimering i Azure Event Hubs
Loggkomprimering är ett sätt att behålla data i Event Hubs med hjälp av händelsenyckelbaserad kvarhållning. Som standard skapas varje händelsehubb/Kafka-ämne med tidsbaserad kvarhållning eller borttagningsrensningsprincipen , där händelser rensas när kvarhållningstiden upphör. I stället för att använda grovkornig tidsbaserad kvarhållning kan du använda en händelsenyckelbaserad kvarhållningsmekanism där Event Hubs tränar om det senast kända värdet för varje händelsenyckel i en händelsehubb eller ett Kafka-ämne.
Kommentar
Loggkomprimeringsfunktionen stöds inte på den grundläggande * nivån.
Som visas i följande bild kan en händelselogg (av en händelsehubbpartition) ha flera händelser med samma nyckel. Om du använder en komprimerad händelsehubb tar Event Hubs-tjänsten hand om att rensa gamla händelser och endast behålla de senaste händelserna för en viss händelsenyckel.
Komprimeringsnyckel
Partitionsnyckeln som du anger för varje händelse används som komprimeringsnyckel.
Gravstenar
Klientprogrammet kan markera befintliga händelser för en händelsehubb som ska tas bort under komprimeringsjobbet. Dessa markörer kallas tombstones. Klientprogram anger tombstones genom att skicka en ny händelse med en befintlig nyckel och en null
händelsenyttolast.
Så här fungerar loggkomprimering
Du kan aktivera loggkomprimering på varje händelsehubb/Kafka-ämnesnivå. Du kan mata in händelser till en komprimerad artikel från alla supportprotokoll. Azure Event Hubs-tjänsten kör ett komprimeringsjobb för varje komprimerad händelsehubb. Komprimeringsjobb rensar varje händelsehubbpartitionslogg genom att endast behålla den senaste händelsen för en viss händelsenyckel.
Vid en viss tidpunkt kan händelseloggen för en komprimerad händelsehubb ha en rensad del och en smutsig del. Den rena delen innehåller de händelser som komprimeras av komprimeringsjobbet medan den smutsiga delen består av de händelser som ännu inte har komprimerats.
Event Hubs-tjänsten hanterar körningen av komprimeringsjobbet och användaren kan inte styra det. Därför avgör Event Hubs-tjänsten när komprimering ska startas och hur snabbt den komprimerar en viss komprimerad händelsehubb.
Komprimeringsgarantier
Loggkomprimeringsfunktionen i Event Hubs ger följande garanti:
- Ordningen på meddelandena behålls alltid på nyckel- och partitionsnivå. Komprimeringsjobbet ändrar inte ordningen på meddelanden, men det tar bara bort de gamla händelserna i samma nyckel.
- Sekvensnumret och förskjutningen av ett meddelande ändras aldrig.
- Alla konsumenter som fortsätter från början av händelseloggen ser åtminstone det slutliga tillståndet för alla händelser i den ordning de skrevs.
- Konsumenter kan fortfarande se händelser som har markerats för att tas bort för den tid som definieras av Tombstone Retention Time(hours).
Användningsfall för loggkomprimering
Loggkomprimering kan vara användbart i scenarier där du strömmar samma uppsättning uppdateringsbara händelser. Eftersom komprimerade händelsehubbar bara behåller de senaste händelserna behöver användarna inte oroa sig för händelselagringens tillväxt. Därför används loggkomprimering ofta i scenarier som Change Data Capture (CDC), underhåll av händelser i tabeller för dataströmbearbetningsprogram och cachelagring av händelser.
Kvoter och begränsningar
Gräns | Basic | Standard | Premium | Dedikerad |
---|---|---|---|---|
Storlek på komprimerad händelsehubb | Ej tillämpligt | 1 GB per partition | 250 GB per partition | 250 GB per partition |
Andra kvoter och gränser finns i Event Hubs-kvoter och -gränser.
Nästa steg
Anvisningar om hur du använder loggkomprimering i Event Hubs finns i Använda loggkomprimering