Änderungsfeed in Azure Cosmos DB

GILT FÜR: NoSQL MongoDB Cassandra Gremlin

Der Änderungsfeed in Azure Cosmos DB ist eine persistente Aufzeichnung der Änderungen an einem Container in der Reihenfolge ihres Auftretens. Zur Unterstützung des Änderungsfeeds in Azure Cosmos DB wird gelauscht, ob in einem Azure Cosmos DB-Container Änderungen auftreten. Anschließend wird die sortierte Liste von geänderten Dokumenten in der Reihenfolge ausgegeben, in der sie geändert wurden. Die persistenten Änderungen können asynchron und inkrementell verarbeitet werden, und die Ausgabe kann über einen oder mehrere Consumer für die Parallelverarbeitung verteilt werden.

Erfahren Sie mehr über Entwurfsmuster für Änderungsfeeds.

Unterstützte APIs und Client-SDKs

Dieses Feature wird derzeit von den folgenden Azure Cosmos DB-APIs und Client-SDKs unterstützt.

Clienttreiber NoSQL Apache Cassandra MongoDB Apache Gremlin Tabelle
.NET Ja Ja Ja Ja Nein
Java Ja Ja Ja Ja Nein
Python Ja Ja Ja Ja Nein
Node/JS Ja Ja Ja Ja Nein

Änderungsfeed und verschiedene Vorgänge

Heute werden alle Einfügungen und Updates im Änderungsfeed angezeigt. Sie können den Änderungsfeed nicht nach einen bestimmten Vorgangstyp filtern. Als Alternative können Sie für das Element eine „schwache Markierung“ für Aktualisierungen hinzufügen und dies bei der Verarbeitung von Elementen im Änderungsfeed entsprechend filtern.

Aktuell protokollieren Änderungsfeeds keine Löschvorgänge. Wie im vorherigen Beispiel können Sie den zu löschenden Elementen eine schwache Markierung hinzufügen. Sie können dem Element z. B. das Attribut „deleted“ (gelöscht) hinzufügen und es auf TRUE festlegen sowie eine Gültigkeitsdauer (TTL) für das Element festlegen, damit es automatisch gelöscht werden kann. Sie können den Änderungsfeed nach früheren Elementen durchsuchen (der letzten Änderung, die dem Element entspricht; zwischenzeitliche Änderungen sind nicht enthalten), z.B. nach Elementen, die vor fünf Jahren hinzugefügt wurden. Sie können den Änderungsfeed bis zum Ursprung Ihres Containers lesen, wenn jedoch ein Element gelöscht wird, wird es auch aus dem Änderungsfeed entfernt.

Sortierreihenfolge der Elemente im Änderungsfeed

Elemente im Änderungsfeed sind in der Reihenfolge des Zeitpunkts ihrer letzten Änderung aufgeführt. Diese Sortierreihenfolge ist pro logischem Partitionsschlüssel festgelegt.

Konsistenzebene

Bei Verarbeitung des Änderungsfeeds in einer späteren Konsistenzebene können in nachfolgenden Änderungsfeed-Lesevorgängen doppelte Ereignisse auftreten (das letzte Ereignis eines Lesevorgangs wird als erstes des nächsten angezeigt).

Änderungsfeed in Azure Cosmos DB-Konten mit mehreren Regionen

Wenn in einem Azure Cosmos DB-Konto mit mehreren Regionen ein Failover einer Schreibregion eintritt, funktioniert der Änderungsfeed übergreifend über den manuellen Failovervorgang und bleibt zusammenhängend.

Änderungsfeed und Gültigkeitsdauer (TTL)

Wenn eine TTL-Eigenschaft (Time to Live, Gültigkeitsdauer) für ein Element auf „-1“ festgelegt ist, bleibt der Änderungsfeed dauerhaft erhalten. Wenn die Daten nicht gelöscht werden, verbleiben sie im Änderungsfeed.

Änderungsfeed und „_etag“, „_lsn“ oder „_ts“

Das _etag-Format ist intern, und Sie sollten nicht darauf aufbauen, da es jederzeit geändert werden kann. „_ts“ ist ein Änderungs- oder Erstellungszeitstempel. Sie können „_ts“ für chronologische Vergleiche verwenden. „_lsn“ ist eine Batch-ID, die nur für den Änderungsfeed hinzugefügt wird. Sie stellt die Transaktions-ID dar. Viele Elemente können die gleiche „_lsn“ aufweisen. „ETag“ in der FeedResponse unterscheidet sich von dem „_etag“, das für das Element angezeigt wird. „_etag“ ist ein interner Bezeichner, der für die Gleichzeitigkeitssteuerung verwendet wird. Die _etag-Eigenschaft informiert über die Version des Elements, während die ETag-Eigenschaft zum Sequenzieren des Feeds verwendet wird.

Verwenden des Änderungsfeeds

Sie können den Änderungsfeed mit den folgenden Optionen verwenden:

Der Änderungsfeed ist für jeden logischen Partitionsschlüssel innerhalb des Containers verfügbar. Er kann für eine parallele Verarbeitung über mehrere Consumer verteilt werden, wie in der folgenden Abbildung gezeigt.

Verteilte Verarbeitung des Azure Cosmos DB-Änderungsfeeds

Features des Änderungsfeeds

  • Der Änderungsfeed ist standardmäßig für alle Azure Cosmos DB-Konten aktiviert.

  • Sie können Ihren bereitgestellten Durchsatz in allen der Azure Cosmos DB-Datenbank zugeordneten Regionen zum Lesen aus dem Änderungsfeed verwenden, so wie es auch bei allen anderen Vorgängen von Azure Cosmos DB möglich ist.

  • Der Änderungsfeed enthält Einfüge- und Aktualisierungsvorgänge, die für Elemente im Container durchgeführt wurden. Sie können Löschvorgänge durch ein Kennzeichen für „vorläufiges Löschen“ erfassen, das den gelöschten Text in den Elementen (z.B. in Dokumenten) ersetzt. Alternativ können Sie über die TTL-Funktion einen begrenzten Ablaufzeitraum für die Elemente festlegen, z.B. 24 Stunden, und den Wert dieser Eigenschaft verwenden, um Löschvorgänge zu erfassen. Mit dieser Lösung müssen Sie die Änderungen in einem kürzeren Zeitraum als dem TTL-Ablaufzeitraum verarbeiten.

  • Nur die letzte Änderung für ein bestimmtes Element ist im Änderungsprotokoll enthalten. Zwischenzeitliche Änderungen sind möglicherweise nicht verfügbar.

  • Jede im Änderungsprotokoll enthaltene Änderung wird im Änderungsfeed genau einmal angezeigt, und die Clients müssen ihre Prüfpunktausführungs-Logik verwalten. Wenn Sie die Komplexität der Verwaltung von Prüfpunkten umgehen möchten, bietet der Änderungsfeedprozessor automatische Prüfpunktausführung und „Mindestens einmal“-Semantik. Verwenden des Änderungsfeeds mit dem Änderungsfeedprozessor.

  • Der Änderungsfeed ist anhand der Reihenfolge der Änderungen innerhalb der einzelnen logischen Partitionsschlüsselwerte sortiert. Es gibt keine festgelegte Reihenfolge über Partitionsschlüsselwerte hinweg.

  • Änderungen können für jeden Zeitpunkt synchronisiert werden, d.h., es gibt keine feste Datenaufbewahrungsdauer, in der die Änderungen verfügbar sind.

  • Änderungen sind für alle logischen Partitionsschlüssel eines Azure Cosmos DB-Containers parallel möglich. Auf diese Weise können Änderungen aus umfangreichen Containern parallel von mehreren Consumern verarbeitet werden.

  • Anwendungen können mehrere Änderungsfeeds gleichzeitig für den gleichen Container anfordern. Mithilfe von „ChangeFeedOptions.StartTime“ kann ein anfänglicher Startpunkt angegeben werden, z.B. um das Fortsetzungstoken zu suchen, das der angegebenen Uhrzeit entspricht. Der ContinuationToken-Wert (sofern angegeben) hat Vorrang vor den Werten StartTime und StartFromBeginning. Die Genauigkeit von „ChangeFeedOptions.StartTime“ beträgt ca. 5 Sekunden.

Änderungsfeed in APIs für Cassandra und MongoDB

Die Funktionen des Änderungsfeeds werden in der API für MongoDB als Änderungsdatenstrom und in der API für Cassandra als Abfrage mit Prädikat verfügbar gemacht. Weitere Informationen zu den Implementierungsdetails für die API für MongoDB finden Sie unter Änderungsdatenströme in Azure Cosmos DB-API for MongoDB.

Natives Apache Cassandra bietet Change Data Capture (CDC), einen Mechanismus zum Markieren bestimmter Tabellen für die Archivierung sowie zum Ablehnen von Schreibvorgängen in diesen Tabellen, nachdem eine konfigurierbare Größe auf dem Datenträger für das CDC-Protokoll erreicht wurde. Der Änderungsfeed in Azure Cosmos DB for Apache Cassandra verbessert die Möglichkeit, die Änderungen mit Prädikaten über CQL abzufragen. Weitere Informationen zu den Implementierungsdetails finden Sie unter Änderungsfeed in Azure Cosmos DB for Apache Cassandra.

Messen des Verbrauchs von Anforderungseinheiten des Änderungsfeeds

Verwenden Sie Azure Monitor, um den Verbrauch von Anforderungseinheiten (RUs) des Änderungsfeeds zu messen. Weitere Informationen finden Sie unter Überwachen des Durchsatzes oder Anforderungseinheitsverbrauchs in Azure Cosmos DB.

Nächste Schritte

In den folgenden Artikeln erfahren Sie mehr über Änderungsfeeds: