Schalen met Event HubsScaling with Event Hubs

Er zijn twee factoren die van invloed zijn op schalen met Event Hubs.There are two factors which influence scaling with Event Hubs.

  • DoorvoereenhedenThroughput units
  • PartitiesPartitions

DoorvoereenhedenThroughput units

De doorvoer capaciteit van Event Hubs wordt bepaald door doorvoer eenheden.The throughput capacity of Event Hubs is controlled by throughput units. Doorvoereenheden zijn vooraf aangeschafte capaciteitseenheden.Throughput units are pre-purchased units of capacity. Met één door Voer kunt u:A single throughput lets you:

  • Binnenkomend: Maxi maal 1 MB per seconde of 1000 gebeurtenissen per seconde (afhankelijk van wat het eerste komt).Ingress: Up to 1 MB per second or 1000 events per second (whichever comes first).
  • Uitgang: Maxi maal 2 MB per seconde of 4096 gebeurtenissen per seconde.Egress: Up to 2 MB per second or 4096 events per second.

Wanneer de capaciteit van de aangekochte doorvoereenheden wordt overschreven, wordt de invoer vertraagd en een ServerBusyException afgegeven.Beyond the capacity of the purchased throughput units, ingress is throttled and a ServerBusyException is returned. De uitvoer geeft geen vertragingsuitzonderingen af, maar is nog steeds beperkt tot de capaciteit van de aangekochte doorvoereenheden.Egress does not produce throttling exceptions, but is still limited to the capacity of the purchased throughput units. Als zich uitzonderingen met betrekking tot de publicatiesnelheid voordoen of als u meer uitgaande gegevens verwacht, controleert u hoeveel doorvoereenheden u hebt aangeschaft voor de naamruimte.If you receive publishing rate exceptions or are expecting to see higher egress, be sure to check how many throughput units you have purchased for the namespace. U kunt doorvoereenheden beheren op de blade Schaal van de naamruimten in Azure Portal.You can manage throughput units on the Scale blade of the namespaces in the Azure portal. U kunt doorvoer eenheden ook programmatisch beheren met behulp van de Event hubs-api's.You can also manage throughput units programmatically using the Event Hubs APIs.

Doorvoer eenheden zijn vooraf aangeschaft en worden per uur gefactureerd.Throughput units are pre-purchased and are billed per hour. Nadat u doorvoereenheden hebt aangeschaft, worden deze voor minimaal één uur in rekening gebracht.Once purchased, throughput units are billed for a minimum of one hour. Er kunnen Maxi maal 20 doorvoer eenheden worden aangeschaft voor een Event Hubs naam ruimte en worden gedeeld door alle Event hubs in die naam ruimte.Up to 20 throughput units can be purchased for an Event Hubs namespace and are shared across all event hubs in that namespace.

De functie automatisch verg Roten van Event hubs wordt automatisch geschaald door het aantal doorvoer eenheden te verhogen om te voldoen aan de behoeften van het gebruik.The Auto-inflate feature of Event Hubs automatically scales up by increasing the number of throughput units, to meet usage needs. Het verhogen van doorvoer eenheden voor komt het beperken van scenario's, waarbij:Increasing throughput units prevents throttling scenarios, in which:

  • Tarieven voor gegevens ingang overschrijden de ingestelde doorvoer eenheden.Data ingress rates exceed set throughput units.
  • De tarieven voor gegevens uitwissel aanvragen overschrijden de ingestelde doorvoer eenheden.Data egress request rates exceed set throughput units.

De Event Hubs-service verhoogt de door Voer wanneer de belasting groter wordt dan de minimale drempel waarde, zonder dat er aanvragen worden uitgevoerd met ServerBusy-fouten.The Event Hubs service increases the throughput when load increases beyond the minimum threshold, without any requests failing with ServerBusy errors.

Zie automatisch schalen door Voer eenhedenvoor meer informatie over de functie voor automatisch verg Roten.For more information about the auto-inflate feature, see Automatically scale throughput units.

PartitiesPartitions

Met Event Hub worden reeksen van gebeurtenissen in een of meer partities georganiseerd.Event Hub organizes sequences of events into one or more partitions. Als er nieuwere gebeurtenissen plaatsvinden, worden deze toegevoegd aan het einde van deze reeks.As newer events arrive, they're added to the end of this sequence. Een partitie kan worden beschouwd als een 'doorvoerlogboek'.A partition can be thought of as a "commit log."

Partities bevatten gebeurtenisgegevens met de hoofdtekst van de gebeurtenis, een door de gebruiker gedefinieerde set eigenschappen waarin de gebeurtenis wordt beschreven en metagegevens, zoals de offset in de partitie, het nummer in de stroomreeks en de service-side timestamp van de acceptatie.Partitions hold event data containing the body of the event, a user-defined property bag describing the event, and metadata such as its offset in the partition, its number in the stream sequence, and the service-side timestamp at which it was accepted.

Diagram waarin de reeks gebeurtenissen van oud naar nieuw wordt weergegeven.

Event Hubs is ontworpen om te helpen bij het verwerken van grote hoeveelheden gebeurtenissen. Partitioneren draagt hier op twee manieren aan bij:Event Hubs is designed to help with processing of large volumes of events, and partitioning helps with that in two ways:

Ten eerste, hoewel Event Hubs een PaaS-service is, is er wel een onderliggende fysieke realiteit. Het bijhouden van een logboek waarbij de volgorde van gebeurtenissen wordt behouden, vereist dat deze gebeurtenissen samen in de bijbehorende opslag en replica's worden bewaard. Dit betekent dat er een doorvoerplafond is voor een dergelijk logboek.First, even though Event Hubs is a PaaS service, there's a physical reality underneath, and maintaining a log that preserves the order of events requires that these events are being kept together in the underlying storage and its replicas and that results in a throughput ceiling for such a log. Partitioneren maakt het mogelijk om meerdere parallelle logboeken te gebruiken voor dezelfde Event Hub en zo de beschikbare doorvoercapaciteit voor onbewerkte IO-gegevens te vermenigvuldigen.Partitioning allows for multiple parallel logs to be used for the same Event Hub and therefore multiplying the available raw IO throughput capacity.

Ten tweede moeten uw eigen toepassingen de verwerking van het volume aan gebeurtenissen dat naar een Event Hub wordt verzonden bij kunnen houden.Second, your own applications must be able to keep up with processing the volume of events that are being sent into an Event Hub. Dit kan complex zijn en vereist aanzienlijke, uitgeschaalde en parallelle verwerkingscapaciteit.It may be complex and requires substantial, scaled-out, parallel processing capacity. De reden voor partities is dezelfde als hierboven: De capaciteit van één proces voor het afhandelen van gebeurtenissen is beperkt en daarom hebt u verschillende processen nodig. Partities zijn de manier waarop uw oplossing deze processen voedt en zorgen ervoor dat elke gebeurtenis een duidelijke verwerkingseigenaar heeft.The rationale for partitions is the same as above: The capacity of a single process to handle events is limited, and therefore you need several processes, and partitions are how your solution feeds those processes and yet ensures that each event has a clear processing owner.

Event Hubs bewaart gebeurtenissen voor een geconfigureerde bewaartijd die wordt toegepast op het niveau van alle partities.Event Hubs retains events for a configured retention time that applies across all partitions. Gebeurtenissen worden automatisch verwijderd wanneer de retentieperiode is bereikt.Events are automatically removed when the retention period has been reached. Als u een retentieperiode van één dag opgeeft, wordt de gebeurtenis precies 24 uur nadat deze is geaccepteerd onbeschikbaar.If you specify a retention period of one day, the event will become unavailable exactly 24 hours after it has been accepted. U kunt gebeurtenissen niet expliciet verwijderen.You cannot explicitly delete events.

De toegestane retentieperiode is maximaal zeven dagen voor Event Hubs Standard en maximaal 90 dagen voor Event Hubs Dedicated.The allowed retention time is up to 7 days for Event Hubs Standard and up to 90 days for Event Hubs Dedicated. Als u gebeurtenissen wilt archiveren na de toegestane retentieperiode, kunt u deze automatisch laten opslaan in Azure Storage of Azure Data Lake door de functie Event Hubs Capture in te schakelen. Als u dergelijke diepe archieven wilt doorzoeken of analyseren, kunt u ze gemakkelijk importeren in Azure Synapse of andere vergelijkbare opslagplaatsen en analyseplatforms.If you need to archive events beyond the allowed retention period, you can have them automatically stored in Azure Storage or Azure Data Lake by turning on the Event Hubs Capture feature, and if you need to search or analyze such deep archives, you can easily import them into Azure Synapse or other similar stores and analytics platforms.

De limiet op de retentieperiode voor Event Hubs is om te voorkomen dat grote hoeveelheden historische klantgegevens worden vastgelegd in een archief dat alleen wordt geïndexeerd per timestamp en alleen sequentiële toegang toestaat.The reason for Event Hubs' limit on data retention based on time is to prevent large volumes of historic customer data getting trapped in a deep store that is only indexed by a timestamp and only allows for sequential access. De architectuurfilosofie is dat voor historische gegevens uitgebreidere indexering en directere toegang nodig is dan de real-time interface voor gebeurtenissen die Event Hubs of Kafka bieden.The architectural philosophy here is that historic data needs richer indexing and more direct access than the real-time eventing interface that Event Hubs or Kafka provide. Engines voor gebeurtenissenstromen zijn niet geschikt om te fungeren als data lakes of als langetermijnarchieven voor gebeurtenisbronnen.Event stream engines are not well suited to play the role of data lakes or long-term archives for event sourcing.

Omdat partities onafhankelijk zijn en hun eigen reeks gegevens bevatten, groeien ze vaak met verschillende snelheden.Because partitions are independent and contain their own sequence of data, they often grow at different rates. In Event Hubs is dat geen bezwaar waarvoor administratieve interventies nodig zijn, zoals in Apache Kafka, maar ongelijke distributie leidt tot ongelijkmatige belasting van uw downstream-gebeurtenisverwerkers.In Event Hubs, that is no concern that requires administrative intervention as it would be, for instance, in Apache Kafka, but uneven distribution will lead to uneven load on your downstream event processors.

Event Hubs

Het aantal partities wordt opgegeven bij het maken en moet voor Event Hubs Standard tussen 1 en 32 liggen.The number of partitions is specified at creation and must be between 1 and 32 in Event Hubs Standard. Het aantal partities kan in Event Hubs Dedicated maximaal 2000 partities per capaciteitseenheid zijn.The partition count can be up to 2000 partitions per Capacity Unit in Event Hubs Dedicated.

We raden u aan om ten minste zoveel partities te kiezen als u verwacht nodig te hebben voor aanhoudende doorvoereenheden (TU's) tijdens piekbelasting van uw toepassing voor die specifieke Event Hub.We recommend that you choose at least as many partitions as you expect to require in sustained throughput units (TU) during the peak load of your application for that particular Event Hub. U moet er rekening mee houden dat één partitie een doorvoercapaciteit heeft van 1 TU (1 MB ingaand, 2 MB uitgaand).You should calculate with a single partition having a throughput capacity of 1 TU (1 MByte in, 2 MByte out). U kunt de schaal van uw TU's aanpassen aan uw naamruimte of de capaciteitseenheden van uw cluster, onafhankelijk van het aantal partities.You can scale the TUs on your namespace or the capacity units of your cluster independent of the partition count. Een Event Hub met 32 partities of een Event Hub met één partitie genereren exact dezelfde kosten als de naamruimte is ingesteld op een capaciteit van één TU.An Event Hub with 32 partitions or an Event Hub with 1 partition incur the exact same cost when the namespace is set to 1 TU capacity.

Toepassingen regelen de toewijzing van gebeurtenissen aan partities op een van de volgende drie manieren:Applications control the mapping of events to partitions in one of three ways:

  • Door de partitiesleutel op te geven die consistent is toegewezen (met behulp van een hash-functie) aan een van de beschikbare partities.By specifying partition key, which is consistently mapped (using a hash function) to one of the available partitions.
  • Door geen partitiesleutel op te geven, zodat een broker voor iedere gebeurtenis een willekeurige partitie kan kiezen.By not specifying a partition key, which enables to broker to randomly choose a partition for a given event.
  • Door expliciet gebeurtenissen te verzenden naar een specifieke partitie.By explicitly sending events to a specific partition.

Als u een partitiesleutel opgeeft, kunnen gerelateerde gebeurtenissen in dezelfde partitie worden bewaard, in dezelfde volgorde waarin ze zijn verzonden.Specifying a partition key enables keeping related events together in the same partition and in the exact order in which they were sent. De partitiesleutel is een tekenreeks die is afgeleid van uw toepassingscontext en identificeert de relatie tussen de gebeurtenissen.The partition key is some string that is derived from your application context and identifies the interrelationship of the events.

Een reeks gebeurtenissen die wordt geïdentificeerd door een partitiesleutel is een stroom.A sequence of events identified by a partition key is a stream. Een partitie is een multiplex-logboekopslag voor veel van zulke stromen.A partition is a multiplexed log store for many such streams.

Het aantal partities van een Event Hub in een toegewezen Event Hubs-cluster kan worden verhoogd nadat de Event Hub is gemaakt, maar de distributie van stromen over partities verandert als deze klaar is, omdat de toewijzing van partitiesleutels aan partities verandert. U kunt dus het beste proberen om dergelijke wijzigingen zoveel mogelijk te vermijden als de relatieve volgorde van gebeurtenissen in uw toepassing van belang is.The partition count for an event hub in a dedicated Event Hubs cluster can be increased after the event hub has been created, but the distribution of streams across partitions will change when it's done as the mapping of partition keys to partitions changes, so you should try hard to avoid such changes if the relative order of events matters in your application.

Het instellen van het aantal partities op de maximaal toegestane waarde is verleidelijk, maar u moet er altijd rekening mee houden dat uw gebeurtenissenstromen zo moeten worden gestructureerd dat u wel kunt profiteren van meerdere partities.Setting the number of partitions to the maximum permitted value is tempting, but always keep in mind that your event streams need to be structured such that you can indeed take advantage of multiple partitions. Als u de volgorde van alle gebeurtenissen of voor een klein aantal substromen echt moet behouden, kunt u misschien niet profiteren van het gebruik van veel partities.If you need absolute order preservation across all events or only a handful of substreams, you may not be able to take advantage of many partitions. Daarnaast maken veel partities de verwerkingszijde complexer.Also, many partitions make the processing side more complex.

Hoewel u rechtstreeks gebeurtenissen naar partities kunt sturen, wordt dit niet aanbevolen.While partitions can be sent to directly, it's not recommended. In plaats daarvan kunt u constructies op een hoger niveau gebruiken. Deze vindt u in de sectie Gebeurtenisuitgever.Instead, you can use higher level constructs introduced in the Event publishers section.

Zie de artikelen Programmeergids voor Event Hubs en Beschikbaarheid en consistentie in Event Hubs voor meer informatie over partities en de verhouding tussen de beschikbaarheid en betrouwbaarheid.For more information about partitions and the trade-off between availability and reliability, see the Event Hubs programming guide and the Availability and consistency in Event Hubs article.

PartitiesleutelPartition key

U kunt een partitie sleutel gebruiken om inkomende gebeurtenis gegevens toe te wijzen aan specifieke partities voor het doel van de gegevens organisatie.You can use a partition key to map incoming event data into specific partitions for the purpose of data organization. De partitiesleutel is een door de afzender opgegeven waarde die aan een Event Hub wordt doorgegeven.The partition key is a sender-supplied value passed into an event hub. De partitiesleutel wordt verwerkt door een statische hash-functie, die zorgt voor de partitietoewijzing.It is processed through a static hashing function, which creates the partition assignment. Als u bij het publiceren van een gebeurtenis geen partitiesleutel opgeeft, wordt er gebruikgemaakt van round robin-toewijzing.If you don't specify a partition key when publishing an event, a round-robin assignment is used.

De gebeurtenisuitgever is alleen op de hoogte van de partitiesleutel en niet van de partitie waarop de gebeurtenissen worden gepubliceerd.The event publisher is only aware of its partition key, not the partition to which the events are published. Deze ontkoppeling van sleutel en partitie schermt de afzender af, zodat deze niet te veel te weten hoeft te komen over de downstreamverwerking.This decoupling of key and partition insulates the sender from needing to know too much about the downstream processing. Goede partitiesleutels zijn bijvoorbeeld een apparaatspecifieke of een gebruikersspecifieke identiteit, maar voor het groeperen van gerelateerde gebeurtenissen in dezelfde partitie kunnen ook andere kenmerken, zoals geografie, worden gebruikt.A per-device or user unique identity makes a good partition key, but other attributes such as geography can also be used to group related events into a single partition.

Volgende stappenNext steps

U kunt meer informatie over Event Hubs vinden via de volgende koppelingen:You can learn more about Event Hubs by visiting the following links: