Ontwerppatronen voor wijzigingenfeeds in Azure Cosmos DB

  • Artikel

VAN TOEPASSING OP: NoSQL

De Azure Cosmos DB-wijzigingenfeed maakt een efficiënte verwerking van grote gegevenssets met een groot aantal schrijfbewerkingen mogelijk. Wijzigingenfeed biedt ook een alternatief voor het uitvoeren van query's op een volledige gegevensset om te bepalen wat er is gewijzigd. Dit artikel is gericht op algemene ontwerppatronen voor wijzigingenfeeds, ontwerpnadelen en beperkingen van wijzigingenfeeds.

Azure Cosmos DB is geschikt voor IoT-, gaming-, retail- en operationele logboekregistratietoepassingen. Een algemeen ontwerppatroon in deze toepassingen is om wijzigingen in de gegevens te gebruiken om andere acties te activeren. Voorbeelden van deze acties zijn:

  • Een melding of een aanroep naar een API activeren wanneer een item wordt ingevoegd, bijgewerkt of verwijderd.
  • Realtime stroomverwerking voor IoT of verwerking van realtime analyses op operationele gegevens.
  • Gegevensverplaatsing, zoals synchroniseren met een cache, een zoekmachine, een datawarehouse of koude opslag.

Met de wijzigingenfeed in Azure Cosmos DB kunt u efficiënte en schaalbare oplossingen bouwen voor elk van deze patronen, zoals wordt weergegeven in de volgende afbeelding:

Diagram met het gebruik van azure Cosmos DB-wijzigingenfeed voor realtime analyses en gebeurtenisgestuurde computingscenario's.

Gebeurteniscomputing en meldingen

De Azure Cosmos DB-wijzigingenfeed kan scenario's vereenvoudigen waarbij een melding moet worden geactiveerd of een aanroep naar een API moet worden verzonden op basis van een bepaalde gebeurtenis. U kunt de wijzigingenfeedprocessor gebruiken om uw container automatisch te peilen op wijzigingen en vervolgens een externe API aan te roepen telkens wanneer er een schrijfbewerking, update of verwijdering wordt uitgevoerd.

U kunt ook selectief een melding activeren of een aanroep naar een API verzenden op basis van specifieke criteria. Als u bijvoorbeeld de wijzigingenfeed leest met behulp van Azure Functions, kunt u logica in de functie plaatsen om alleen een melding te verzenden als aan een voorwaarde is voldaan. Hoewel de Azure Function-code voor elke wijziging wordt uitgevoerd, wordt de melding alleen verzonden als aan de voorwaarde wordt voldaan.

Realtime streamverwerking

De Azure Cosmos DB-wijzigingenfeed kan worden gebruikt voor realtime streamverwerking voor IoT of realtime analyseverwerking van operationele gegevens. U kunt bijvoorbeeld gebeurtenisgegevens ontvangen en opslaan van apparaten, sensoren, infrastructuur en toepassingen, en deze gebeurtenissen vervolgens in realtime verwerken met behulp van Spark. In de volgende afbeelding ziet u hoe u een lambda-architectuur kunt implementeren met behulp van de Azure Cosmos DB-wijzigingenfeed:

Diagram met een lambda-pijplijn op basis van Azure Cosmos DB voor opname en query's.

In veel gevallen ontvangen implementaties van stroomverwerking eerst een grote hoeveelheid binnenkomende gegevens in een tijdelijke berichtenwachtrij, zoals Azure Event Hubs of Apache Kafka. De wijzigingenfeed is een goed alternatief vanwege de mogelijkheid van Azure Cosmos DB om ondersteuning te bieden voor een aanhoudend hoge mate van gegevensopname met gegarandeerde lage lees- en schrijflatentie. De voordelen van de Azure Cosmos DB-wijzigingenfeed ten opzichte van een berichtenwachtrij zijn:

Gegevenspersistentie

Gegevens die naar Azure Cosmos DB zijn geschreven, worden weergegeven in de wijzigingenfeed. De gegevens worden bewaard in de wijzigingenfeed totdat ze worden verwijderd als u leest met de modus Nieuwste versie. Berichtenwachtrijen hebben doorgaans een maximale bewaarperiode. Azure Event Hubs biedt bijvoorbeeld een maximale gegevensretentie van 90 dagen.

Mogelijkheid om query's uit te voeren

U kunt niet alleen lezen uit de wijzigingenfeed van een Azure Cosmos DB-container, maar ook SQL-query's uitvoeren op de gegevens die zijn opgeslagen in Azure Cosmos DB. De wijzigingenfeed is geen duplicatie van gegevens die zich al in de container bevinden, maar het is gewoon een ander mechanisme voor het lezen van de gegevens. Als u gegevens uit de wijzigingenfeed leest, zijn de gegevens daarom altijd consistent met query's van dezelfde Azure Cosmos DB-container.

Hoge beschikbaarheid

Azure Cosmos DB biedt een lees- en schrijfbaarheid van maximaal 99,999%. In tegenstelling tot veel berichtenwachtrijen kunnen Azure Cosmos DB-gegevens eenvoudig wereldwijd worden gedistribueerd en geconfigureerd met een beoogde hersteltijd (RTO) van nul.

Nadat u items in de wijzigingenfeed hebt verwerkt, kunt u een gerealiseerde weergave maken en geaggregeerde waarden terugzetten in Azure Cosmos DB. Als u bijvoorbeeld Azure Cosmos DB gebruikt om een game te bouwen, kunt u wijzigingenfeed gebruiken om realtime leaderboards te implementeren op basis van scores van voltooide games.

Gegevensverplaatsing

U kunt ook lezen uit de wijzigingenfeed voor realtime gegevensverplaatsing.

Met de wijzigingenfeed kunt u bijvoorbeeld de volgende taken efficiënt uitvoeren:

  • Een cache, zoekindex of datawarehouse bijwerken met gegevens die zijn opgeslagen in Azure Cosmos DB.

  • Migraties zonder downtime uitvoeren naar een ander Azure Cosmos DB-account of naar een andere Azure Cosmos DB-container met een andere logische partitiesleutel.

  • Implementeer gegevenslagen en archivering op toepassingsniveau. U kunt bijvoorbeeld 'dynamische gegevens' opslaan in Azure Cosmos DB en 'koude gegevens' verouderen naar andere opslagsystemen, zoals Azure Blob Storage.

Wanneer u gegevens in partities en containers moet denormaliseren, kunt u de wijzigingenfeed van uw container lezen als bron voor deze gegevensreplicatie. Realtime gegevensreplicatie met de wijzigingenfeed kan alleen uiteindelijke consistentie garanderen. U kunt controleren hoe ver de verwerker van de wijzigingenfeed achterloopt bij het verwerken van wijzigingen in uw Azure Cosmos DB-container.

Gebeurtenisbronnen

Het gebeurtenisbronnenpatroon omvat het gebruik van een opslag met alleen toevoegen om de volledige reeks acties op die gegevens vast te leggen. De Azure Cosmos DB-wijzigingenfeed is een uitstekende keuze als een centraal gegevensarchief in gebeurtenisbronnenarchitecturen waarin alle gegevensopname wordt gemodelleerd als schrijfbewerkingen (geen updates of verwijderingen). In dit geval is elke schrijfbewerking naar Azure Cosmos DB een 'gebeurtenis', dus er is een volledig overzicht van eerdere gebeurtenissen in de wijzigingenfeed. De gebeurtenissen die door het centrale gebeurtenissenarchief worden gepubliceerd, worden doorgaans gebruikt om gerealiseerde weergaven te onderhouden of te integreren met externe systemen. Omdat er geen tijdslimiet is voor retentie in de modus nieuwste versie van de wijzigingenfeed, kunt u alle eerdere gebeurtenissen opnieuw afspelen door te lezen vanaf het begin van de wijzigingenfeed van uw Azure Cosmos DB-container. U kunt zelfs meerdere gebruikers van een wijzigingenfeed laten abonneren op de wijzigingenfeed van dezelfde container.

Azure Cosmos DB is een geweldig centraal permanent gegevensarchief met alleen toevoegen in het gebeurtenisbronnenpatroon vanwege de sterke punten in horizontale schaalbaarheid en hoge beschikbaarheid. Bovendien biedt de verwerker van de wijzigingenfeed een 'ten minste eenmaal' -garantie, zodat u geen gebeurtenissen mist.

Huidige beperkingen

De wijzigingenfeed heeft meerdere modi die elk belangrijke beperkingen hebben die u moet begrijpen. Er zijn verschillende gebieden waarmee u rekening moet houden wanneer u een toepassing ontwerpt die gebruikmaakt van de wijzigingenfeed in de modus nieuwste versie of alle versies en de modus Verwijderen.

Tussenliggende updates

In de modus Nieuwste versie wordt alleen de meest recente wijziging voor een specifiek item opgenomen in de wijzigingenfeed. Bij het verwerken van wijzigingen leest u de meest recente beschikbare itemversie. Als er meerdere updates voor hetzelfde item in een korte periode zijn, is het mogelijk dat de verwerking van tussenliggende updates wordt gemist. Als u eerdere afzonderlijke updates voor een item opnieuw wilt afspelen, kunt u deze updates in plaats daarvan modelleren als een reeks schrijfbewerkingen of alle versies en de modus verwijderen gebruiken.

Verwijderd

De modus voor de nieuwste versie van de wijzigingenfeed legt geen verwijderingen vast. Als u een item uit uw container verwijdert, wordt het ook verwijderd uit de wijzigingenfeed. De meest voorkomende methode voor het afhandelen van verwijderingen is het toevoegen van een zachte markering aan de items die worden verwijderd. U kunt een eigenschap met de naam deleted toevoegen en instellen true op op het moment van verwijderen. Deze documentupdate wordt weergegeven in de wijzigingenfeed. U kunt een TTL (Time to Live) voor dit item instellen, zodat het later automatisch kan worden verwijderd.

Bewaartermijn

De wijzigingenfeed in de modus Nieuwste versie heeft een onbeperkte retentie. Zolang een item in uw container bestaat, is het beschikbaar in de wijzigingenfeed.

Gegarandeerde bestelling

Alle wijzigingsfeedmodi hebben een gegarandeerde volgorde binnen een partitiesleutelwaarde, maar niet voor partitiesleutelwaarden. Selecteer een partitiesleutel waarmee u een zinvolle volgorde kunt garanderen.

Denk bijvoorbeeld aan een retailtoepassing die gebruikmaakt van het ontwerppatroon gebeurtenisbronnen. In deze toepassing zijn verschillende gebruikersacties elk 'gebeurtenissen', die zijn gemodelleerd als schrijfbewerkingen naar Azure Cosmos DB. Stel dat er enkele voorbeeldgebeurtenissen zijn opgetreden in de volgende volgorde:

  1. De klant voegt item A toe aan zijn winkelwagen.
  2. De klant voegt Item B toe aan zijn winkelwagen.
  3. De klant verwijdert Artikel A uit zijn winkelwagen.
  4. Klant checkt uit en de inhoud van de winkelwagen wordt verzonden.

Voor elke klant wordt een gerealiseerde weergave van de huidige winkelwageninhoud behouden. Deze toepassing moet ervoor zorgen dat deze gebeurtenissen worden verwerkt in de volgorde waarin ze plaatsvinden. Als het uitchecken van de winkelwagen bijvoorbeeld moet worden verwerkt voordat artikel A wordt verwijderd, is het waarschijnlijk dat artikel A naar de klant is verzonden en niet naar het artikel dat de klant in plaats daarvan wilde, artikel B. Om ervoor te zorgen dat deze vier gebeurtenissen worden verwerkt in volgorde van hun optreden, moeten ze binnen dezelfde partitiesleutelwaarde vallen. Als u (elke klant heeft een unieke gebruikersnaam) als partitiesleutel selecteert username , kunt u garanderen dat deze gebeurtenissen worden weergegeven in de wijzigingenfeed in dezelfde volgorde waarin ze naar Azure Cosmos DB worden geschreven.

Voorbeelden

Hier volgen enkele voorbeelden van code voor wijzigingenfeeds in de praktijk voor de meest recente versiemodus die verder gaan dan het bereik van de opgegeven voorbeelden:

Volgende stappen