Ändringsflöde i Azure Cosmos DB

GÄLLER FÖR: SQL API API för Cassandra Gremlin API Azure Cosmos DB API för MongoDB

Ändringsflöde i Azure Cosmos DB är en beständig post med ändringar i en container i den ordning de sker. Stödet för ändringsflöde i Azure Cosmos DB fungerar genom att lyssna efter ändringar på en Azure Cosmos-container. Funktionen returnerar sedan den sorterade listan över dokument som ändrats i den ordning de ändrades. De beständiga ändringarna kan bearbetas asynkront och inkrementellt, och utdata kan distribueras över en eller flera konsumenter för parallell bearbetning.

Läs mer om designmönster för ändringsflöde.

API:er och klient-SDK:er som stöds

Den här funktionen stöds för närvarande av följande Azure Cosmos DB-API:er och klient-SDK:er.

Klientdrivrutiner SQL API API för Azure Cosmos DB för Cassandra Azure Cosmos DB API för MongoDB Gremlin-API Tabell-API
.NET Ja Ja Ja Ja Inga
Java Ja Ja Ja Ja Inga
Python Ja Ja Ja Ja Inga
Nod/JS Ja Ja Ja Ja Inga

Ändringsflöde och olika åtgärder

I dag visas alla infogningar och uppdateringar i ändringsflödet. Du kan inte filtrera ändringsflödet för en viss typ av åtgärd. Ett möjligt alternativ är att lägga till en "mjuk markör" för objektet för uppdateringar och filter baserat på det när objekt bearbetas i ändringsflödet.

Ändringsflödet loggar för närvarande inte borttagningar. På samma sätt som i föregående exempel kan du lägga till en mjuk markör för de objekt som tas bort. Du kan till exempel lägga till ett attribut i objektet "borttaget" och ställa in det på "true" och ange en TTL för objektet så att det kan tas bort automatiskt. Du kan läsa ändringsflödet för historiska objekt (den senaste ändringen som motsvarar objektet, den innehåller inte mellanliggande ändringar), till exempel objekt som lades till för fem år sedan. Du kan läsa ändringsflödet så långt tillbaka som containerns ursprung, men om ett objekt tas bort tas det bort från ändringsflödet.

Sorteringsordning för objekt i ändringsflöde

Ändringsflödesobjekt kommer i ordning efter ändringstiden. Den här sorteringsordningen garanteras per logisk partitionsnyckel.

Konsekvensnivå

När ändringsflödet används på en slutlig konsekvensnivå kan det finnas duplicerade händelser mellan efterföljande läsåtgärder för ändringsflöde (den sista händelsen för en läsåtgärd visas som den första i nästa).

Ändringsflöde i Azure Cosmos-konton i flera regioner

Om en skrivningsregion redundansväxlar i ett Azure Cosmos-konto i flera regioner fungerar ändringsflödet i den manuella redundansåtgärden och kommer att vara sammanhängande.

Ändringsflöde och TTL (Time to Live)

Om en TTL-egenskap (Time to Live) anges för ett objekt till -1 kommer ändringsflödet att finnas kvar för alltid. Om data inte tas bort finns de kvar i ändringsflödet.

Ändringsflöde och _etag, _lsn eller _ts

Det _etag formatet är internt och du bör inte vara beroende av det, eftersom det kan ändras när som helst. _ts är en tidsstämpel för att ändra eller skapa. Du kan använda _ts för kronologisk jämförelse. _lsn är ett batch-ID som endast läggs till för ändringsflöde. det representerar transaktions-ID:t. Många objekt kan ha samma _lsn. ETag på FeedResponse skiljer sig från den _etag du ser på objektet. _etag är en intern identifierare och används för samtidighetskontroll. Egenskapen _etag berättar om versionen av objektet, medan ETag-egenskapen används för sekvensering av feeden.

Arbeta med ändringsflöde

Du kan arbeta med ändringsflöde med hjälp av följande alternativ:

Ändringsflöde är tillgängligt för varje logisk partitionsnyckel i containern och kan distribueras över en eller flera konsumenter för parallell bearbetning enligt bilden nedan.

Distributed processing of Azure Cosmos DB change feed

Funktioner i ändringsflöde

  • Ändringsflöde är aktiverat som standard för alla Azure Cosmos-konton.

  • Du kan använda ditt etablerade dataflöde för att läsa från ändringsflödet, precis som andra Azure Cosmos DB-åtgärder, i alla regioner som är associerade med din Azure Cosmos-databas.

  • Ändringsflödet innehåller infogningar och uppdateringsåtgärder som görs för objekt i containern. Du kan samla in borttagningar genom att ange flaggan "mjuk borttagning" i dina objekt (till exempel dokument) i stället för borttagningar. Du kan också ange en begränsad förfalloperiod för dina objekt med TTL-funktionen. Till exempel 24 timmar och använd värdet för den egenskapen för att samla in borttagningar. Med den här lösningen måste du bearbeta ändringarna inom ett kortare tidsintervall än TTL-förfalloperioden.

  • Endast den senaste ändringen för ett visst objekt ingår i ändringsloggen. Mellanliggande ändringar kanske inte är tillgängliga.

  • Varje ändring som ingår i ändringsloggen visas exakt en gång i ändringsflödet och klienterna måste hantera logiken för kontrollpunkter. Om du vill undvika komplexiteten med att hantera kontrollpunkter tillhandahåller ändringsflödesprocessorn automatiska kontrollpunkter och "minst en gång" semantik. med ändringsflöde med ändringsflödesprocessor.

  • Ändringsflödet sorteras efter ändringsordning inom varje nyckelvärde för logisk partition. Det finns ingen garanterad ordning över partitionsnyckelvärdena.

  • Ändringar kan synkroniseras från valfri tidpunkt, dvs. det finns ingen fast kvarhållningsperiod för data som ändringar är tillgängliga för.

  • Ändringar är tillgängliga parallellt för alla logiska partitionsnycklar för en Azure Cosmos-container. Med den här funktionen kan ändringar från stora containrar bearbetas parallellt av flera konsumenter.

  • Program kan begära flera ändringsflöden på samma container samtidigt. ChangeFeedOptions.StartTime kan användas för att tillhandahålla en första startpunkt. Till exempel för att hitta fortsättningstoken som motsvarar en viss klocktid. ContinuationToken, om det anges, har företräde framför värdena StartTime och StartFromBeginning. Precisionen för ChangeFeedOptions.StartTime är ~5 sek.

Ändringsflöde i API:er för Cassandra och MongoDB

Funktionen för ändringsflöde visas som ändringsström i MongoDB API och fråga med predikat i API för Cassandra. Mer information om implementeringsinformation för MongoDB API finns i Ändringsströmmar i Azure Cosmos DB API för MongoDB.

Native Apache Cassandra tillhandahåller change data capture (CDC), en mekanism för att flagga specifika tabeller för arkivering samt avvisa skrivningar till dessa tabeller när en konfigurerbar storlek på disken för CDC-loggen har nåtts. Funktionen för ändringsflöde i Azure Cosmos DB API för Cassandra förbättrar möjligheten att köra frågor mot ändringarna med predikat via CQL. Mer information om implementeringsinformation finns i Ändringsflöde i Azure Cosmos DB API för Cassandra.

Nästa steg

Du kan nu fortsätta att lära dig mer om ändringsfeed i följande artiklar: