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 rensningsprincipen för borttagning , 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.

Anteckning

Loggkomprimeringsfunktionen stöds inte på * basic-nivån .

Som du ser 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 rensning av gamla händelser och behåller bara de senaste händelserna för en viss händelsenyckel.

Diagram som visar hur ett ämne komprimeras.

Komprimeringsnyckel

Partitionsnyckeln som du anger med 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 valfritt supportprotokoll. Azure Event Hubs-tjänsten kör ett komprimeringsjobb för varje komprimerad händelsehubb. Komprimeringsjobbet rensar varje händelsehubbpartitionslogg genom att endast behålla den senaste händelsen för en viss händelsenyckel.

Diagram som visar hur loggkomprimering fungerar.

Vid en given 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 upprätthå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 går vidare 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 bekymra sig om 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