Wijzigingenfeed in Azure Cosmos DB lezen
VAN TOEPASSING OP: 
NoSQL
U kunt met de Azure Cosmos DB-wijzigingenfeed werken met behulp van een pushmodel of een pull-model. Met een pushmodel pusht de wijzigingenfeedprocessor werk naar een client met bedrijfslogica voor het verwerken van dit werk. De complexiteit bij het controleren van werk en het opslaan van de status voor het laatst verwerkte werk wordt echter verwerkt in de verwerker van de wijzigingenfeed.
Met een pull-model moet de client het werk van de server ophalen. In dit geval heeft de client niet alleen bedrijfslogica voor het verwerken van werk, maar ook de opslagstatus voor het laatst verwerkte werk, het afhandelen van taakverdeling voor meerdere clients die werk parallel verwerken en fouten afhandelen.
Bij het lezen van de Azure Cosmos DB-wijzigingenfeed raden we u meestal aan een pushmodel te gebruiken, omdat u zich geen zorgen hoeft te maken over:
- Peil de wijzigingenfeed voor toekomstige wijzigingen.
- De status opslaan voor de laatst verwerkte wijziging. Als u leest vanuit de wijzigingenfeedprocessor, wordt de status automatisch opgeslagen in een leasecontainer.
- Taakverdeling voor meerdere clients die wijzigingen gebruiken. Als de ene client bijvoorbeeld niet kan bijhouden met het verwerken van wijzigingen en een andere client de beschikbare capaciteit heeft.
- Fouten afhandelen. Het automatisch opnieuw proberen van mislukte wijzigingen die niet correct zijn verwerkt na een niet-verwerkte uitzondering in code of een tijdelijk netwerkprobleem, is bijvoorbeeld automatisch opnieuw geprobeerd.
De meeste scenario's die gebruikmaken van de Azure Cosmos DB-wijzigingenfeed, maken gebruik van een van de pushmodelopties. Er zijn echter enkele scenario's waarin u mogelijk het extra beheer op laag niveau van het pull-model wilt. Deze omvatten:
- Wijzigingen van een bepaalde partitiesleutel lezen
- Het tempo bepalen waarop uw klant wijzigingen ontvangt voor verwerking
- Eenmalig lezen 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. U kunt op twee manieren lezen uit de wijzigingenfeed met een pushmodel: Azure Functions Azure Cosmos DB-triggers en de wijzigingenfeedprocessor. Azure Functions maakt achter de schermen gebruik van de processor voor wijzigingenfeeds, dus dit zijn beide vergelijkbare manieren om de wijzigingenfeed te lezen. U kunt Azure Functions beschouwen als een hostingplatform voor de wijzigingenfeedprocessor, 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 gebruiksvoorbeelden van wijzigingenfeeds. Wanneer u een Azure Functions-trigger voor Azure Cosmos DB maakt, selecteert u de container om verbinding te maken en wordt de Azure-functie geactiveerd wanneer er een wijziging in de container is. Omdat Azure Functions achter de schermen gebruikmaakt van de processor voor wijzigingenfeeds, wordt de verwerking van wijzigingen automatisch geparallelliseert 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 met één knop de functie implementeren. Zie Serverloze databasecomputing met Behulp van Azure Functions en Wijzigingenfeed gebruiken met Azure Functions-artikelen voor meer informatie.
Processorbibliotheek voor wijzigingenfeeds
Ondersteunde SDK's
| .Net V3 | Java | Node.JS | Python |
|---|---|---|---|
| ✓ | ✓ | ✕ | ✕ |
De wijzigingenfeedprocessor geeft u meer controle over de wijzigingenfeed en verbergt nog steeds de meeste complexiteit. De processorbibliotheek van de wijzigingenfeed volgt het waarnemerspatroon, waarbij uw verwerkingsfunctie wordt aangeroepen door de bibliotheek. De wijzigingenfeedprocessor controleert automatisch op wijzigingen en pusht ze naar de client als er wijzigingen worden gevonden. 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 tussen de verschillende clients. U hoeft geen logica te implementeren voor taakverdeling voor meerdere clients of logica om de leasestatus te behouden.
De verwerker van de wijzigingenfeed garandeert een 'ten minste één keer'-levering van alle wijzigingen. Met andere woorden, als u de verwerker van de wijzigingenfeed gebruikt, wordt uw verwerkingsfunctie met succes aangeroepen voor elk item in de wijzigingenfeed. Als er een niet-verwerkte uitzondering is in de bedrijfslogica in uw verwerkingsfunctie, worden de mislukte wijzigingen opnieuw geprobeerd totdat ze zijn verwerkt. Als u wilt voorkomen dat uw wijzigingenfeedprocessor continu dezelfde wijzigingen opnieuw probeert uit te voeren, voegt u logica toe aan uw verwerkingsfunctie om documenten te schrijven, op uitzondering van een wachtrij met dode letters. Meer informatie over foutafhandeling.
In Azure Functions is de aanbeveling voor het afhandelen van fouten hetzelfde. U moet nog steeds logica toevoegen aan uw gedelegeerde code om documenten te schrijven, op uitzondering, naar een wachtrij met onbestelbare brieven. Als er echter een niet-verwerkte uitzondering in uw Azure-functie is, wordt de wijziging die de uitzondering heeft gegenereerd, niet automatisch opnieuw geprobeerd. Als er een niet-verwerkte uitzondering is in de bedrijfslogica, gaat de Azure-functie verder met het verwerken van de volgende wijziging. De Azure-functie voert dezelfde mislukte wijziging niet opnieuw uit.
Net als Azure Functions is het ontwikkelen met de processorbibliotheek voor wijzigingenfeeds eenvoudig. U bent echter verantwoordelijk voor het implementeren van een of meer hosts voor de wijzigingenfeedprocessor. Een host is een toepassingsexemplaar dat de wijzigingenfeedverwerker gebruikt om naar wijzigingen te luisteren. Hoewel Azure Functions mogelijkheden heeft voor automatisch schalen, bent u verantwoordelijk voor het schalen van uw hosts. Zie het gebruik van de wijzigingenfeedprocessor voor meer informatie. De processorbibliotheek voor wijzigingenfeeds 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 is geen automatische polling voor wijzigingen. Als u de laatst verwerkte wijziging permanent 'bladwijzer' wilt maken (vergelijkbaar met de leasecontainer van het pushmodel), moet u een vervolgtoken opslaan.
Met behulp van het pull-model van de wijzigingenfeed krijgt u meer controle over de wijzigingenfeed. Wanneer u de wijzigingenfeed leest met het pull-model, 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 u dat kunt 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 distribueert tussen uw machines. Vervolgens kunt u deze FeedRanges gebruiken om meerdere machines de wijzigingenfeed parallel te laten lezen.
Er is geen ingebouwde 'ten minste één keer'-leveringsgarantie bij 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 de 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 voor het markeren van specifieke tabellen voor archivering en het weigeren van schrijfbewerkingen naar die tabellen zodra een configureerbare grootte voor het CDC-logboek is bereikt. De functie voor wijzigingenfeeds in Azure Cosmos DB voor Apache Cassandra verbetert de mogelijkheid om query's uit te voeren op de wijzigingen met predicaat via CQL. Zie Wijzigingenfeed in Azure Cosmos DB voor Apache Cassandra voor meer informatie over de implementatiedetails.
Volgende stappen
U kunt nu verdergaan met meer informatie over wijzigingenfeed in de volgende artikelen: