Designmönster för ändringsflöde i Azure Cosmos DB för NoSQL

Med Azure Cosmos DB-ändringsflödet kan du effektivt bearbeta stora datamängder med höga skrivvolymer. Det är ett alternativ till att fråga hela datauppsättningar för att identifiera ändringar. Den här artikeln beskriver vanliga designmönster för ändringsflöde, deras kompromisser och begränsningar som hjälper dig att skapa skalbara lösningar.

Scenarier

Azure Cosmos DB är perfekt för IoT-, spel-, detaljhandels- och driftloggningsprogram. Ett vanligt designmönster i dessa program är att använda ändringar i data för att utlösa andra åtgärder. Dessa åtgärder omfattar:

• Utlöser ett meddelande eller ett anrop till ett API när ett objekt infogas, uppdateras eller tas bort.
• Dataströmbearbetning i realtid för IoT eller analys av driftdata.
• Dataflytt, till exempel synkronisering med en cache, en sökmotor, ett informationslager eller kall lagring.

Med ändringsflödet i Azure Cosmos DB kan du skapa effektiva, skalbara lösningar för dessa mönster, enligt följande bild:

Händelseberäkning och meddelanden

Azure Cosmos DB-ändringsflödet förenklar scenarier som utlöser ett meddelande eller anropar ett API baserat på en specifik händelse. Använd ändringsflödesprocessorn för att automatiskt avsöka containern efter ändringar och anropa ett externt API för varje skrivning, uppdatering eller borttagning.

Utlös ett meddelande selektivt eller anropa ett API baserat på specifika kriterier. Om du till exempel läser från ändringsflödet med hjälp av Azure Functions lägger du till logik i funktionen för att endast skicka ett meddelande om ett villkor uppfylls. Även om Azure-funktionskoden körs för varje ändring skickas meddelandet endast om villkoret uppfylls.

Strömbearbetning i realtid

Med Azure Cosmos DB-ändringsflödet kan du utföra dataströmbearbetning i realtid för IoT- eller realtidsanalys på driftdata. Du kan till exempel ta emot och lagra händelsedata från enheter, sensorer, infrastruktur och program och bearbeta dessa händelser i realtid med hjälp av Spark. Följande bild visar hur du implementerar en lambda-arkitektur med hjälp av Azure Cosmos DB-ändringsflödet:

I många fall får implementeringar av dataströmbearbetning först en stor mängd inkommande data till en tillfällig meddelandekö, till exempel Azure Event Hubs eller Apache Kafka. Ändringsflödet är ett bra alternativ på grund av Azure Cosmos DB:s förmåga att stödja en ihållande hög datainmatningshastighet med garanterad låg läs- och skrivsvarstid.

Databeständighet

Data som skrivs till Azure Cosmos DB visas i ändringsflödet. I det senaste versionsläget finns data kvar i ändringsflödet tills de tas bort. Meddelandeköer har vanligtvis en maximal kvarhållningsperiod. Azure Event Hubs erbjuder till exempel en maximal datakvarhållning på 90 dagar.

Frågeförmåga

Förutom att läsa från en Azure Cosmos DB-containers ändringsflöde kör du SQL-frågor på data som lagras i Azure Cosmos DB. Ändringsflödet är inte en duplicering av data som redan finns i containern, utan snarare en annan mekanism för att läsa data. Om du läser data från ändringsflödet är data därför alltid konsekventa med frågor i samma Azure Cosmos DB-container.

Hög tillgänglighet

Azure Cosmos DB tillhandahåller upp till 99,999% läs- och skrivtillgänglighet. Till skillnad från många meddelandeköer kan Azure Cosmos DB-data distribueras globalt och konfigureras med ett mål för återställningstid (RTO) på noll.

När du har bearbetat objekt i ändringsflödet skapar du en materialiserad vy och bevarar aggregerade värden i Azure Cosmos DB. Du kan till exempel använda Azure Cosmos DB:s ändringsflöde för att implementera rankningslistor i realtid baserat på poäng från slutförda spel.

Dataflytt

Läs från ändringsflödet för dataflytt i realtid.

Med ändringsflödet kan du till exempel utföra följande uppgifter effektivt:

• Uppdatera en cache, ett sökindex eller ett informationslager med data som lagras i Azure Cosmos DB.

• Utför noll stilleståndstidsmigreringar till ett annat Azure Cosmos DB-konto eller till en annan Azure Cosmos DB-container som har en annan logisk partitionsnyckel.

• Implementera datanivåindelning och arkivering på programnivå. Du kan till exempel lagra "frekventa data" i Azure Cosmos DB och åldra ut "kalla data" till andra lagringssystem som Azure Blob Storage.

När du måste avnormalisera data mellan partitioner och containrar kan du läsa från containerns ändringsflöde som källa för den här datareplikeringen. Datareplikering i realtid med ändringsflödet garanterar endast slutlig konsekvens. Du kan övervaka hur långt ändringsflödesprocessorn ligger efter vid bearbetning av ändringar i Azure Cosmos DB-containern.

Händelsekällor

Händelsekällans mönster använder ett tilläggslager för att registrera hela serien med åtgärder på data. Azure Cosmos DB-ändringsflödet är ett bra val som ett centralt datalager i arkitekturer för händelsekällor där all datainmatning modelleras som skrivningar (inga uppdateringar eller borttagningar). I det här fallet är varje skrivning till Azure Cosmos DB en "händelse", så det finns en fullständig post med tidigare händelser i ändringsflödet. Typiska användningsområden för de händelser som publiceras av det centrala händelsearkivet är att underhålla materialiserade vyer eller integrera med externa system. Eftersom det inte finns någon tidsgräns för kvarhållning i ändringsflödets senaste versionsläge kan du spela upp alla tidigare händelser genom att läsa från början av din Azure Cosmos DB-containers ändringsflöde. Du kan till och med ha flera ändringsflödeskonsumenter som prenumererar på samma containers ändringsflöde.

Azure Cosmos DB är ett utmärkt beständigt datalager med endast central tillägg i händelsekällans mönster på grund av dess styrkor i horisontell skalbarhet och hög tillgänglighet. Dessutom erbjuder ändringsflödesprocessorn en "minst en gång" -garanti, vilket säkerställer att du inte missar bearbetningen av några händelser.

Aktuella begränsningar

Ändringsflödet har flera lägen, var och en med viktiga begränsningar som du bör förstå. Det finns flera områden att tänka på när du utformar ett program som använder ändringsflödet i antingen senaste versionsläge eller alla versioner och tar bort läge.

Mellanliggande uppdateringar

Borttagningar

Kvarhållning

Garanterad order

Alla ändringsflödeslägen har en garanterad ordning inom ett partitionsnyckelvärde, men inte mellan partitionsnyckelvärden. Du bör välja en partitionsnyckel som ger dig en garanti för meningsfull ordning.

Överväg ett detaljhandelsprogram som använder designmönstret för händelsekällor. I det här programmet är olika användaråtgärder varje "händelser", som modelleras som skrivningar till Azure Cosmos DB. Tänk dig om några exempelhändelser inträffade i följande sekvens:

1. Kunden lägger till artikel A i kundvagnen.
2. Kunden lägger till artikel B i kundvagnen.
3. Kunden tar bort objekt A från kundvagnen.
4. Kunden checkar ut och kundvagnsinnehåll levereras.

En materialiserad vy över aktuellt kundvagnsinnehåll behålls för varje kund. Det här programmet måste se till att dessa händelser bearbetas i den ordning de inträffar. Om kundvagnsutcheckningen till exempel skulle bearbetas innan objekt A tas bort är det troligt att objekt A levererades till kunden i stället för det objekt B som kunden ville ha i stället. För att säkerställa att dessa fyra händelser bearbetas i ordning bör de ligga inom samma partitionsnyckelvärde. Om du väljer username (varje kund har ett unikt användarnamn) som partitionsnyckel kan du garantera att dessa händelser visas i ändringsflödet i samma ordning som de skrivs till Azure Cosmos DB.

Exempel

Här är exempel på verklig ändringsflödeskod för det senaste versionsläget som sträcker sig utanför omfånget för de angivna exemplen:

• Läs mer i Introduktion till ändringsflödet.
• Läs mer i IoT-användningsfallet centrerat kring ändringsflödet.
• Läs mer i Användningsfall för detaljhandel centrerad kring ändringsflödet.

Relaterat innehåll

• Översikt över ändringsflöde
• Ändra flödeslägen
• Alternativ för att läsa ändringsflödet