Wijzigingenfeed in Azure Cosmos DB lezen

  • Artikel

VAN TOEPASSING OP: NoSQL

U kunt werken met de Azure Cosmos DB-wijzigingenfeed met behulp van een push-model of een pull-model. Met een pushmodel pusht de wijzigingenfeedprocessor werk naar een client die bedrijfslogica heeft voor het verwerken van dit werk. De complexiteit van het controleren op werk en het opslaan van de status van het laatste verwerkte werk wordt echter verwerkt in de wijzigingenfeedprocessor.

Met een pull-model moet de client het werk van de server ophalen. De client heeft in dit geval niet alleen bedrijfslogica voor het verwerken van werk, maar ook de opslagstatus voor het laatste verwerkte werk, het afhandelen van taakverdeling over meerdere clients die gelijktijdig werk verwerken en het verwerken van fouten.

Bij het lezen van de Azure Cosmos DB-wijzigingenfeed raden we meestal aan een pushmodel te gebruiken, omdat u zich geen zorgen hoeft te maken over:

  • Polling van de wijzigingenfeed voor toekomstige wijzigingen.
  • Status opslaan voor de laatste verwerkte wijziging. Als u leest van de wijzigingenfeedverwerker, wordt de status automatisch opgeslagen in een leasecontainer.
  • Taakverdeling tussen meerdere clients die wijzigingen gebruiken. Bijvoorbeeld als de ene client het verwerken van wijzigingen niet kan bijhouden en een andere over beschikbare capaciteit beschikt.
  • Fouten afhandelen. Bijvoorbeeld het automatisch opnieuw proberen van mislukte wijzigingen die niet correct zijn verwerkt na een onverwerkte uitzondering in code of een tijdelijk netwerkprobleem.

In de meeste scenario's die gebruikmaken van de Azure Cosmos DB-wijzigingenfeed, wordt een van de pushmodelopties gebruikt. Er zijn echter enkele scenario's waarin u mogelijk het extra beheer op laag niveau van het pull-model wilt gebruiken. Deze omvatten:

  • Wijzigingen van een bepaalde partitiesleutel lezen
  • Het tempo bepalen waarmee uw client wijzigingen ontvangt voor verwerking
  • Een eenmalige leesbewerking uitvoeren van de bestaande gegevens in de wijzigingenfeed (bijvoorbeeld om een gegevensmigratie uit te voeren)

Wijzigingenfeed lezen met een pushmodel

Het gebruik van een pushmodel is de eenvoudigste manier om te lezen uit de wijzigingenfeed. Er zijn twee manieren waarop u de wijzigingenfeed kunt lezen met een pushmodel: Azure Functions Azure Cosmos DB-triggers en de wijzigingenfeedprocessor. Azure Functions achter de schermen gebruikmaakt van de wijzigingenfeedprocessor, dus dit zijn beide vergelijkbare manieren om de wijzigingenfeed te lezen. U kunt Azure Functions zien als een hostingplatform voor de wijzigingenfeedverwerker, niet als een geheel andere manier om de wijzigingenfeed te lezen.

Azure Functions

Azure Functions is de eenvoudigste optie als u net aan de slag gaat met de wijzigingenfeed. Vanwege de eenvoud is het ook de aanbevolen optie voor de meeste use cases van wijzigingenfeeds. Wanneer u een Azure Functions-trigger voor Azure Cosmos DB maakt, selecteert u de container waarmee u verbinding wilt maken en wordt de Azure-functie geactiveerd wanneer er een wijziging in de container is. Omdat Azure Functions achter de schermen gebruikmaakt van de wijzigingenfeedprocessor, worden wijzigingen automatisch verwerkt in de partities van uw container.

Ontwikkelen met Azure Functions is een eenvoudige ervaring en kan sneller zijn dan het zelf implementeren van de wijzigingenfeedprocessor. Triggers kunnen worden gemaakt met behulp van de Azure Functions-portal of programmatisch met behulp van SDK's. Visual Studio en VS Code bieden ondersteuning voor het schrijven van Azure Functions en u kunt zelfs de Azure Functions CLI gebruiken voor platformoverschrijdende ontwikkeling. U kunt de code op uw bureaublad schrijven en fouten opsporen en vervolgens de functie met één knop implementeren. Zie de artikelen Serverloze databasecomputing met behulp van Azure Functions en Wijzigingenfeed gebruiken met Azure Functions artikelen voor meer informatie.

Processorbibliotheek voor wijzigingenfeeds

De wijzigingenfeedprocessor geeft u meer controle over de wijzigingenfeed en verbergt nog steeds de meeste complexiteit. De processorbibliotheek voor de wijzigingenfeed volgt het waarnemerspatroon, waarbij de verwerkingsfunctie wordt aangeroepen door de bibliotheek. De wijzigingenfeedprocessor controleert automatisch op wijzigingen en pusht deze, als er wijzigingen worden gevonden, naar de client. Als u een wijzigingenfeed met hoge doorvoer hebt, kunt u meerdere clients instantiëren om de wijzigingenfeed te lezen. De wijzigingenfeedprocessor verdeelt de belasting automatisch over de verschillende clients. U hoeft geen logica te implementeren voor taakverdeling over meerdere clients of enige logica om de leasestatus te behouden.

De wijzigingenfeedverwerker garandeert een 'at-least-once' levering van alle wijzigingen. Met andere woorden, als u de wijzigingenfeedprocessor gebruikt, wordt de verwerkingsfunctie voor elk item in de wijzigingenfeed met succes aangeroepen. Als er een onverwerkte uitzondering is in de bedrijfslogica in uw verwerkingsfunctie, worden de mislukte wijzigingen opnieuw geprobeerd totdat ze zijn verwerkt. Als u wilt voorkomen dat de verwerker van de wijzigingenfeed continu dezelfde wijzigingen opnieuw probeert uit te voeren, voegt u logica toe in uw verwerkingsfunctie om documenten bij uitzondering te schrijven naar een wachtrij met onbestelbare berichten. Meer informatie over foutafhandeling.

In Azure Functions is de aanbeveling voor het afhandelen van fouten hetzelfde. U moet nog steeds logica toevoegen aan uw gemachtigdencode om documenten bij uitzondering naar een wachtrij met onbestelbare berichten te schrijven. Als er echter een onverwerkte uitzondering in uw Azure-functie is, wordt de wijziging die de uitzondering heeft gegenereerd, niet automatisch opnieuw geprobeerd. Als er een onverwerkte uitzondering in de bedrijfslogica voorkomt, gaat de Azure-functie verder met het verwerken van de volgende wijziging. De Azure-functie probeert dezelfde mislukte wijziging niet opnieuw uit te voeren.

Net als Azure Functions is het eenvoudig om te ontwikkelen met de processorbibliotheek voor wijzigingenfeeds. U bent echter verantwoordelijk voor het implementeren van een of meer hosts voor de wijzigingenfeedprocessor. Een host is een toepassingsinstantie die gebruikmaakt van de wijzigingenfeedprocessor om te luisteren naar wijzigingen. Hoewel Azure Functions mogelijkheden voor automatisch schalen heeft, bent u verantwoordelijk voor het schalen van uw hosts. Zie de wijzigingenfeedprocessor gebruiken voor meer informatie. De processorbibliotheek voor de wijzigingenfeed maakt deel uit van de Azure Cosmos DB SDK V3.

Wijzigingenfeed lezen met een pull-model

Met het pull-model voor wijzigingenfeeds kunt u de wijzigingenfeed in uw eigen tempo gebruiken. Wijzigingen moeten worden aangevraagd door de client en er wordt geen automatische polling uitgevoerd voor wijzigingen. Als u de laatste verwerkte wijziging permanent wilt toevoegen aan een bladwijzer (vergelijkbaar met de leasecontainer van het pushmodel), moet u een vervolgtoken opslaan.

Met behulp van het pull-model voor wijzigingenfeeds krijgt u meer controle op laag niveau van de wijzigingenfeed. Wanneer u de wijzigingenfeed met het pull-model leest, hebt u drie opties:

  • Wijzigingen voor een hele container lezen
  • Wijzigingen voor een specifieke FeedRange lezen
  • Wijzigingen voor een specifieke partitiesleutelwaarde lezen

U kunt de verwerking van wijzigingen op meerdere clients parallelliseren, net zoals met de wijzigingenfeedprocessor. Het pull-model verwerkt echter niet automatisch taakverdeling tussen clients. Wanneer u het pull-model gebruikt om de verwerking van de wijzigingenfeed te parallelliseren, krijgt u eerst een lijst met FeedRanges. Een FeedRange omvat een bereik van partitiesleutelwaarden. U moet een orchestratorproces hebben dat FeedRanges verkrijgt en deze over uw machines distribueert. U kunt deze FeedRanges vervolgens gebruiken om meerdere computers de wijzigingenfeed parallel te laten lezen.

Er is geen ingebouwde leveringsgarantie ten minste één keer met het pull-model. Het pull-model biedt u controle op laag niveau om te bepalen hoe u fouten wilt afhandelen.

Wijzigingenfeed in API's voor Cassandra en MongoDB

De functionaliteit van de wijzigingenfeed wordt weergegeven als wijzigingsstromen in API voor MongoDB en Query met predicaat in API voor Cassandra. Zie Wijzigingsstromen in Azure Cosmos DB voor MongoDB voor meer informatie over de implementatiedetails voor API voor MongoDB.

Systeemeigen Apache Cassandra biedt Change Data Capture (CDC), een mechanisme om specifieke tabellen te markeren voor het archiveren en weigeren van schrijfbewerkingen naar deze tabellen zodra een configureerbare grootte op schijf voor het CDC-logboek is bereikt. De functie voor wijzigingenfeed in Azure Cosmos DB voor Apache Cassandra verbetert de mogelijkheid om via CQL query's uit te voeren op de wijzigingen met het predicaat. Zie Wijzigingenfeed in Azure Cosmos DB voor Apache Cassandra voor meer informatie over de implementatiedetails.

Volgende stappen

In de volgende artikelen vindt u nu meer informatie over wijzigingenfeeds: