Delen via

Ontwerppatronen voor wijzigingenfeeds in Azure Cosmos DB

  • Artikel

VAN TOEPASSING OP: NoSQL

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

Azure Cosmos DB is geschikt voor IoT-, gaming-, retail- en operationele logboekregistratietoepassingen. Een veelvoorkomend ontwerppatroon in deze toepassingen is het gebruik van wijzigingen in de gegevens 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 realtime analyseverwerking 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 dat laat zien hoe u de wijzigingenfeed van Azure Cosmos DB gebruikt om realtime analyses en gebeurtenisgestuurde computingscenario's mogelijk te maken.

Gebeurteniscomputing en meldingen

De Wijzigingenfeed van Azure Cosmos DB kan scenario's vereenvoudigen die een melding moeten activeren of een aanroep naar een API moeten verzenden op basis van een bepaalde gebeurtenis. U kunt de verwerker van de wijzigingenfeed gebruiken om uw container automatisch te peilen op wijzigingen en vervolgens een externe API aan te roepen telkens wanneer er een schrijf-, update- of verwijderingsbewerking is.

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

Streamverwerking in realtime

De Azure Cosmos DB-wijzigingenfeed kan worden gebruikt voor realtime stroomverwerking voor IoT of realtime analyseverwerking op 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.

In veel gevallen ontvangen implementaties van stroomverwerking eerst een groot aantal binnenkomende gegevens in een tijdelijke berichtenwachtrij, zoals Azure Event Hubs of Apache Kafka. De wijzigingsfeed is een geweldig alternatief vanwege de mogelijkheid van Azure Cosmos DB om een duurzame hoge mate van gegevensopname te ondersteunen met gegarandeerde lage lees- en schrijflatentie. De voordelen van de Azure Cosmos DB-wijzigingenfeed voor een berichtenwachtrij zijn:

Gegevenspersistentie

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

Querymogelijkheid

Naast het lezen van de wijzigingenfeed van een Azure Cosmos DB-container, kunt u 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 slechts een ander mechanisme voor het lezen van de gegevens. Als u daarom gegevens uit de wijzigingenfeed leest, zijn de gegevens altijd consistent met query's van dezelfde Azure Cosmos DB-container.

Hoge beschikbaarheid

Azure Cosmos DB biedt een beschikbaarheid van maximaal 99,999% lezen en schrijven. 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 Azure Cosmos DB gebruikt om een game te bouwen, kunt u bijvoorbeeld 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:

  • Werk een cache, zoekindex of datawarehouse bij met gegevens die zijn opgeslagen in Azure Cosmos DB.

  • Voer migraties zonder downtime uit naar een ander Azure Cosmos DB-account of naar een andere Azure Cosmos DB-container met een andere logische partitiesleutel.

  • Implementeer een gegevenslaag 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 tussen 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 processor van de wijzigingenfeed achterloopt bij het verwerken van wijzigingen in uw Azure Cosmos DB-container.

Gebeurtenisbronnen

Het patroon gebeurtenisbronnen omvat het gebruik van een opslag die alleen toevoegt om de volledige reeks acties op die gegevens vast te leggen. De Wijzigingenfeed van Azure Cosmos DB is een uitstekende keuze als een centraal gegevensarchief in gebeurtenisbronnen 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 volledige record van eerdere gebeurtenissen in de wijzigingenfeed. Typische toepassingen van de gebeurtenissen die door het centrale gebeurtenisarchief worden gepubliceerd, zijn het onderhouden van gerealiseerde weergaven of voor integratie met externe systemen. Omdat er geen tijdslimiet is voor retentie in de nieuwste versiemodus 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 de wijzigingenfeed abonneren op de wijzigingenfeed van dezelfde container.

Azure Cosmos DB is een uitstekend centraal, permanent gegevensarchief in het gebeurtenisbronnenpatroon vanwege de sterke punten in horizontale schaalbaarheid en hoge beschikbaarheid. Bovendien biedt de wijzigingenfeedprocessor een garantie voor ten minste één keer , zodat u geen gebeurtenissen hoeft te verwerken.

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 nieuwste versiemodus of alle versies en de modus voor verwijderen.

Tussenliggende updates

In de nieuwste versiemodus wordt alleen de meest recente wijziging voor een specifiek item opgenomen in de wijzigingenfeed. Wanneer u wijzigingen verwerkt, leest u de meest recente versie van het beschikbare item. Als er in een korte periode meerdere updates voor hetzelfde item zijn, is het mogelijk om tussenliggende updates te missen. Als u afzonderlijke updates opnieuw wilt afspelen voor een item, kunt u deze updates modelleren als een reeks schrijfbewerkingen of alle versies en verwijdermodus gebruiken.

Verwijderingen

In de nieuwste versiemodus van de wijzigingenfeed worden geen verwijderingen vastgelegd. 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 door een zachte markering toe te voegen aan de items die worden verwijderd. U kunt een aangeroepen deleted eigenschap toevoegen en instellen true op het moment van verwijdering. Deze documentupdate wordt weergegeven in de wijzigingenfeed. U kunt een TTL (Time to Live) instellen voor dit item, zodat het later automatisch kan worden verwijderd.

Retentie

De wijzigingenfeed in de nieuwste versiemodus heeft een onbeperkte retentie. Zolang er een item in uw container bestaat, is het beschikbaar in de wijzigingenfeed.

Gegarandeerde bestelling

Alle modi voor wijzigingenfeeds hebben een gegarandeerde volgorde binnen een partitiesleutelwaarde, maar niet tussen partitiesleutelwaarden. U moet een partitiesleutel selecteren die u een garantie biedt voor zinvolle volgorde.

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

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

Voor elke klant wordt een gerealiseerde weergave van de huidige inhoud van winkelwagens bijgehouden. Deze toepassing moet ervoor zorgen dat deze gebeurtenissen worden verwerkt in de volgorde waarin ze plaatsvinden. Als het uitchecken van het winkelwagentje bijvoorbeeld moet worden verwerkt voordat item A wordt verwijderd, is het waarschijnlijk dat Item A naar de klant is verzonden en niet het item dat de klant wilde, artikel B. Om ervoor te zorgen dat deze vier gebeurtenissen in volgorde van hun exemplaar worden verwerkt, moeten ze binnen dezelfde partitiesleutelwaarde vallen. Als u selecteert username (elke klant heeft een unieke gebruikersnaam) als partitiesleutel, 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 nieuwste versiemodus die buiten het bereik van de opgegeven voorbeelden vallen:

Volgende stappen