Ä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ödet i Azure Cosmos DB är en beständig post med ändringar i en container i den ordning de inträffar. 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. Bestående ändringar 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-API:er som stöds
Den här funktionen stöds för närvarande av följande Azure Cosmos DB-API:er och klient-API:er.
| Klientdrivrutiner | SQL API | Azure Cosmos DB API för Cassandra | API för Azure Cosmos DB 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 |
| Node/JS | Ja | Ja | Ja | Ja | Inga |
Ändringsflöde och olika åtgärder
Idag ser du 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 du bearbetar objekt i ändringsflödet.
För närvarande loggas inte borttagningar av ändringsflödet. Precis 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 med namnet "deleted" och ange det till "true" och ange ett TTL-värde 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 containern har sitt ursprung, men om ett objekt tas bort tas det bort från ändringsflödet.
Sortera objektens ordning i ändringsflödet
Ändringsflödesobjekt kommer i den ordning de ändras. Den här sorteringsordningen garanteras per logisk partitionsnyckel.
Konsekvensnivå
När ändringsflödet används på en slutlig konsekvensnivå kan det finnas dubbletthändelser mellan efterföljande läsåtgärder för ändringsflöde (den sista händelsen i en läsåtgärd visas som den första i nästa).
Ändringsflöde i Azure Cosmos-konton i flera regioner
Om en skrivregion redundansväxling utförs i ett Azure Cosmos-konto för flera regioner fungerar ändringsflödet över den manuella redundansåtgärden och den kommer att vara sammanhängande.
Ändringsflöde och Time to Live (TTL)
Om en TTL-egenskap (Time to Live) anges för ett objekt till -1 bevaras ändringsflödet för alltid. Om data inte tas bort finns de kvar i ändringsflödet.
Ändringsflöde och _etag, _lsn eller _ts
Formatet _etag är internt och du bör inte vara beroende av det, eftersom det kan ändras när som helst. _ts är en ändring eller en tidsstämpel för skapande. 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. Den representerar transaktions-ID:t. Många objekt kan ha samma _lsn. ETag på FeedResponse skiljer sig från _etag som visas på objektet. _etag är en intern identifierare och används för samtidighetskontroll. Egenskapen _etag anger versionen av objektet, medan ETag-egenskapen används för att sekvensera flödet.
Arbeta med ändringsflöde
Du kan arbeta med ändringsflödet med hjälp av följande alternativ:
Ändringsflödet är tillgängligt för varje logisk partitionsnyckel i containern och kan distribueras över en eller flera konsumenter för parallell bearbetning, som du ser i bilden nedan.
Funktioner i ändringsflödet
Ändringsflödet ä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 någon av de regioner som är associerade med din Azure Cosmos-databas.
Ändringsflödet innehåller infogningar och uppdateringsåtgärder som görs på objekt i containern. Du kan samla in borttagningar genom att ange en "mjuk borttagning"-flagga 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 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 kontrollpunktslogiken. Om du vill undvika komplexiteten med att hantera kontrollpunkter tillhandahåller ändringsflödesprocessorn automatisk kontrollpunkter och "minst en gång"-semantik. med ändringsflöde med ändringsflödesprocessorn.
Ändringsflödet sorteras efter ändringsordningen i varje värde för logisk partitionsnyckel. Det finns ingen garanterad ordning i partitionsnyckelvärdena.
Ändringar kan synkroniseras från valfri tidpunkt, vilket innebär att det inte finns någon 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. Den här funktionen gör att ändringar från stora containrar kan bearbetas parallellt av flera konsumenter.
Program kan begära flera ändringsfeeds i 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 är en ändringsström i MongoDB API och fråga med predikat i API för Cassandra. Mer information om implementeringen för MongoDB-API:et finns i Change streams in the Azure Cosmos DB API for MongoDB (Ändra strömmar i API:et för Azure Cosmos DB för MongoDB).
Native Apache Cassandra tillhandahåller insamling av ändringsdata (CDC), en mekanism för att flagga specifika tabeller för arkivering samt avvisa skrivningar till dessa tabeller när en konfigurerbar storlek på disk för CDC-loggen har uppnåtts. Funktionen för ändringsflöde i Azure Cosmos DB API för Cassandra förbättrar möjligheten att fråga ändringarna med predikat via CQL. Mer information om implementeringen 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 ändringsflödet i följande artiklar: