Designmönster för ändringsflöde i Azure Cosmos DB
GÄLLER FÖR: 
NoSQL
Azure Cosmos DB-ändringsflödet möjliggör effektiv bearbetning av stora datamängder som har en stor mängd skrivningar. Ändringsflöde erbjuder också ett alternativ till att fråga en hel datauppsättning för att identifiera vad som har ändrats. Den här artikeln fokuserar på vanliga designmönster för ändringsflöde, designavvägningar och begränsningar för ändringsflöde.
Azure Cosmos DB passar bra 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. Exempel på dessa åtgärder är:
- 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 realtidsanalysbearbetning på 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 och skalbara lösningar för vart och ett av dessa mönster, enligt följande bild:
Händelseberäkning och meddelanden
Azure Cosmos DB-ändringsflödet kan förenkla scenarier som behöver utlösa ett meddelande eller skicka ett anrop till ett API baserat på en viss händelse. Du kan använda ändringsflödesprocessorn för att automatiskt avsöka containern efter ändringar och sedan anropa ett externt API varje gång det finns en skrivning, uppdatering eller borttagning.
Du kan också selektivt utlösa ett meddelande eller skicka ett anrop till ett API baserat på specifika kriterier. Om du till exempel läser från ändringsflödet med hjälp av Azure Functions kan du placera logik i funktionen för att skicka ett meddelande endast om ett villkor uppfylls. Även om Azure-funktionskoden skulle köras för varje ändring skickas meddelandet endast om villkoret uppfylls.
Strömbearbetning i realtid
Azure Cosmos DB-ändringsflödet kan användas för dataströmbearbetning i realtid för IoT- eller realtidsanalysbearbetning på driftdata. Du kan till exempel ta emot och lagra händelsedata från enheter, sensorer, infrastruktur och program och sedan bearbeta dessa händelser i realtid med hjälp av Spark. Följande bild visar hur du kan implementera 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. Fördelarna med Azure Cosmos DB-ändringsflödet i en meddelandekö är:
Databeständighet
Data som skrivs till Azure Cosmos DB visas i ändringsflödet. Data behålls i ändringsflödet tills de tas bort om du läser med hjälp av det senaste versionsläget. 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 kan du köra SQL-frågor på de 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 erbjuder upp till 99,999 % läs- och skrivtillgänglighet. Till skillnad från många meddelandeköer kan Azure Cosmos DB-data enkelt distribueras globalt och konfigureras med ett mål för återställningstid (RTO) på noll.
När du har bearbetat objekt i ändringsflödet kan du skapa en materialiserad vy och spara aggregerade värden i Azure Cosmos DB. Om du använder Azure Cosmos DB för att skapa ett spel kan du till exempel använda ändringsflöde för att implementera realtidsrankingar baserat på poäng från slutförda spel.
Dataflytt
Du kan också läsa från ändringsflödet för dataflytt i realtid.
Ändringsflödet hjälper dig till exempel att 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 en datanivåindelning på programnivå och arkivering. 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 kan endast garantera 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 omfattar användning av ett tilläggslager för att registrera hela serien med åtgärder på dessa 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 azure Cosmos DB-containerns ändringsflöde. Du kan till och med ha flera ändringsflödeskonsumenter som prenumererar på samma containers ändringsflöde.
Azure Cosmos DB är ett bra 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 som var och en har 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
I det senaste versionsläget ingår endast den senaste ändringen för ett specifikt objekt i ändringsflödet. När du bearbetar ändringar läser du den senaste tillgängliga objektversionen. Om det finns flera uppdateringar av samma objekt på kort tid går det att missa bearbetningen av mellanliggande uppdateringar. Om du vill spela upp tidigare enskilda uppdateringar av ett objekt kan du modellera uppdateringarna som en serie skrivningar i stället eller använda alla versioner och borttagningsläge.
Borttagningar
Ändringsflödets senaste versionsläge samlar inte in borttagningar. Om du tar bort ett objekt från containern tas det också bort från ändringsflödet. Den vanligaste metoden för att hantera borttagningar är att lägga till en mjuk markör för de objekt som tas bort. Du kan lägga till en egenskap som heter deleted och ange den till true vid tidpunkten för borttagningen. Den här dokumentuppdateringen visas i ändringsflödet. Du kan ange TTL (Time to Live) för det här objektet så att det kan tas bort automatiskt senare.
Kvarhållning
Ändringsflödet i det senaste versionsläget har en obegränsad kvarhållning. Så länge ett objekt finns i containern är det tillgängligt i ändringsflödet.
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.
Tänk dig till exempel 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:
- Kunden lägger till artikel A i kundvagnen.
- Kunden lägger till artikel B i kundvagnen.
- Kunden tar bort objekt A från kundvagnen.
- 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 skulle ha levererats till kunden, och inte det objekt som kunden ville ha i stället, objekt B. För att garantera att dessa fyra händelser bearbetas i ordning efter deras förekomst 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 följer några exempel på ändringsflödeskod i verkligheten för det senaste versionsläget som sträcker sig utanför omfånget för de tillhandahållna exemplen:
- Introduktion till ändringsflödet
- IoT-användningsfall centrerat kring ändringsflödet
- Fall för detaljhandelsanvändning centrerad kring ändringsflödet