Lesen des Azure Cosmos DB-Änderungsfeeds
GILT FÜR: 
NoSQL
Für die Arbeit mit dem Azure Cosmos DB-Änderungsfeed können Sie ein Pushmodell oder ein Pullmodell verwenden. Bei einem Pushmodell pusht der Änderungsfeedprozessor die Aufgaben an einen Client, der über Geschäftslogik zur Verarbeitung dieser Aufgaben verfügt. Die Komplexität der Überprüfung auf Aufgaben und das Speichern des Zustands der zuletzt verarbeiteten Aufgaben wird jedoch im Änderungsfeedprozessor behandelt.
Bei einem Pullmodell muss der Client die Aufgaben vom Server abrufen. Der Client verfügt in diesem Fall nicht nur über Geschäftslogik für die Verarbeitung von Aufgaben, sondern kümmert sich auch um die Speicherung des Zustands für die zuletzt verarbeitete Aufgabe, den Lastenausgleich für mehrere Clients, die die Aufgaben parallel verarbeiten, und die Fehlerbehandlung.
Beim Lesen aus dem Azure Cosmos DB-Änderungsfeed empfiehlt es sich in der Regel, ein Pushmodell zu verwenden, da Sie sich über Folgendes keine Gedanken machen müssen:
- Abrufen des Änderungsfeeds bei zukünftigen Änderungen.
- Speichern des Zustands für die zuletzt verarbeitete Änderung. Wenn Sie aus dem Änderungsfeedprozessor lesen, wird der Zustand automatisch in einem Leasecontainer gespeichert.
- Lastenausgleich über mehrere Clients, die Änderungen verbrauchen. Wenn beispielsweise ein Client nicht mit der Verarbeitung von Änderungen Schritt halten kann, während ein anderer noch Kapazitäten hat.
- Behandeln von Fehlern. Dies umfasst z. B. automatische Wiederholungen bei fehlerhaften Änderungen, die nach einer nicht behandelten Ausnahme im Code oder einem zeitweiligen Netzwerkproblem nicht richtig verarbeitet wurden.
In den meisten Szenarien, in denen der Azure Cosmos DB-Änderungsfeed verwendet wird, wird eine der Pushmodelloptionen genutzt. Es gibt jedoch einige Szenarien, in denen Sie möglicherweise die zusätzliche Kontrolle auf niedriger Ebene des Pullmodells benötigen. Dazu gehören:
- Lesen von Änderungen von einem bestimmten Partitionsschlüssel
- Steuern der Geschwindigkeit, mit der der Client Änderungen für die Verarbeitung empfängt
- Ausführen eines einmaligen Lesevorgangs über die vorhandenen Daten im Änderungsfeed (z. B. für eine Datenmigration)
Lesen des Änderungsfeeds mit einem Pushmodell
Die Verwendung eines Pushmodells stellt die einfachste Möglichkeit dar, aus dem Änderungsfeed zu lesen. Es bietet hierzu die folgenden beiden Methoden: Azure Functions-Trigger für Azure Cosmos DB und den Änderungsfeedprozessor. Azure Functions verwendet im Hintergrund den Änderungsfeedprozessor, sodass beide Methoden zum Lesen des Änderungsfeeds sehr ähnlich sind. Stellen Sie sich Azure Functions einfach als Hostingplattform für den Änderungsfeedprozessor vor und nicht als völlig andere Form, den Änderungsfeed zu lesen.
Azure-Funktionen
Azure Functions ist die einfachste Option, wenn Sie nur die ersten Schritte mit dem Änderungsfeed durchführen möchten. Aufgrund der Einfachheit ist es auch die empfohlene Option für die meisten Anwendungsfälle mit dem Änderungsfeed. Wenn Sie einen Azure Functions-Trigger für Azure Cosmos DB erstellen, wählen Sie den Container aus, mit dem eine Verbindung hergestellt werden soll. Die Azure-Funktion wird immer dann ausgelöst, wenn eine Änderung in diesem Container erfolgt. Da Azure Functions im Hintergrund den Änderungsfeedprozessor verwendet, wird die Änderungsverarbeitung automatisch über die Partitionen des Containers parallelisiert.
Die Entwicklung mit Azure Functions ist sehr einfach und kann schneller sein als eine eigene Bereitstellung des Änderungsfeedprozessors. Trigger können im Azure Functions-Portal oder programmgesteuert über SDKs erstellt werden. Visual Studio und VS Code bieten Unterstützung für das Schreiben von Azure-Funktionen, und Sie können sogar die Azure Functions-CLI zur plattformübergreifenden Entwicklung verwenden. Sie können den Code auf Ihrem Desktop schreiben und debuggen und dann die Funktion mit einem Klick auf eine Schaltfläche bereitstellen. Weitere Informationen finden Sie in den Artikeln Serverloses Datenbankcomputing mithilfe von Azure Functions und Verwenden des Änderungsfeeds mit Azure Functions.
Änderungsfeedprozessor-Bibliothek
Unterstützte SDKs
| .Net V3 | Java | Node.JS | Python |
|---|---|---|---|
| ✓ | ✓ | ✕ | ✕ |
Der Änderungsfeedprozessor bietet Ihnen mehr Kontrolle über den Änderungsfeed, verringert die Komplexität allerdings erheblich. Die Bibliothek für den Änderungsfeedprozessor folgt dem Beobachtermuster, bei dem Ihre Verarbeitungsfunktion von der Bibliothek aufgerufen wird. Der Änderungsfeedprozessor überprüft automatisch, ob Änderungen vorhanden sind. Beim Erkennen von Änderungen werden diese an den Client gepusht. Wenn Ihr Änderungsfeed einen hohen Durchsatz aufweist, können Sie zum Lesen des Änderungsfeeds mehrere Clients instanziieren. Der Änderungsfeedprozessor teilt die Last automatisch zwischen den verschiedenen Clients auf. Es ist nicht erforderlich, Logik für den Lastenausgleich über mehrere Clients oder Logik zum Verwalten des Leasezustands zu implementieren.
Der Änderungsfeedprozessor garantiert eine mindestens einmalige (At-Least-Once) Übermittlung aller Änderungen. Anders ausgedrückt: Wenn Sie den Änderungsfeedprozessor verwenden, wird die Verarbeitungsfunktion für jedes Element im Änderungsfeed erfolgreich aufgerufen. Wenn in der Geschäftslogik Ihrer Verarbeitungsfunktion ein Ausnahmefehler auftritt, werden die fehlerhaften Änderungen wiederholt, bis sie erfolgreich verarbeitet wurden. Um zu verhindern, dass der Änderungsfeedprozessor fortlaufend dieselben Änderungen wiederholt, sollten Sie in Ihrer Verarbeitungsfunktion Logik hinzufügen, um bei einer Ausnahme Dokumente in eine Warteschlange für unzustellbare Nachrichten zu schreiben. Erfahren Sie mehr über die Fehlerbehandlung.
In Azure Functions ist die Empfehlung zur Fehlerbehandlung identisch. Sie sollten weiterhin Logik in Ihrem Delegatcode hinzufügen, um Dokumente bei einer Ausnahme in eine Warteschlange für unzustellbare Nachrichten zu schreiben. Wenn jedoch ein Ausnahmefehler in Ihrer Azure-Funktion vorliegt, wird die Änderung, die die Ausnahme generiert hat, nicht automatisch wiederholt. Wenn in der Geschäftslogik ein Ausnahmefehler auftritt, fährt die Azure-Funktion mit der Verarbeitung der nächsten Änderung fort. Die Azure-Funktion wiederholt nicht dieselbe fehlerhafte Änderung.
Wie bei Azure Functions ist auch das Entwickeln mit der Änderungsfeedprozessor-Bibliothek einfach. Sie müssen jedoch mindestens einen Host für den Änderungsfeedprozessor bereitstellen. Ein Host ist eine Anwendungsinstanz, die den Änderungsfeedprozessor verwendet, um auf Änderungen zu lauschen. Auch wenn Azure Functions über Funktionen für die automatische Skalierung verfügt, sind Sie für das Skalieren Ihrer Hosts selbst verantwortlich. Weitere Informationen finden Sie unter Verwenden des Änderungsfeedprozessors. Die Bibliothek für den Änderungsfeedprozessor ist im Azure Cosmos DB SDK V3 enthalten.
Lesen des Änderungsfeeds mit einem Pullmodell
Mit dem Pullmodell für den Änderungsfeed können Sie den Änderungsfeed in Ihrem eigenen Tempo verwenden. Änderungen müssen vom Client angefordert werden, und es erfolgt kein automatisches Abrufen von Änderungen. Wenn Sie die letzte verarbeitete Änderung (ähnlich wie beim Leasecontainer des Pushmodells) dauerhaft als „Lesezeichen“ speichern möchten, müssen Sie ein Fortsetzungstoken speichern.
Mit dem Pullmodell für den Änderungsfeed erhalten Sie eine bessere Kontrolle auf niedriger Ebene über den Änderungsfeed. Sie haben beim Lesen des Änderungsfeeds mit dem Pullmodell drei Möglichkeiten:
- Lesen von Änderungen für einen vollständigen Container
- Lesen von Änderungen für einen bestimmten FeedRange
- Lesen von Änderungen für einen bestimmten Partitionsschlüsselwert
Ebenso wie beim Änderungsfeedprozessor können Sie die Verarbeitung von Änderungen über mehrere Clients hinweg parallelisieren. Allerdings erfolgt der Lastenausgleich auf mehrere Clients beim Pullmodell nicht automatisch. Wenn Sie das Pullmodell verwenden, um die Verarbeitung des Änderungsfeeds zu parallelisieren, erhalten Sie zunächst eine Liste von FeedRanges. Ein FeedRange stellt einen Bereich von Partitionsschlüsselwerten dar. Sie benötigen einen Orchestratorprozess, der FeedRanges abruft und auf Ihre Computer verteilt. Anschließend können Sie diese FeedRanges verwenden, damit mehrere Computer den Änderungsfeed parallel lesen können.
Es gibt beim Pullmodell keine Garantie für eine mindestens einmalige (At-Least-Once) Übermittlung. Das Pullmodell bietet Ihnen mehr Kontrolle auf niedriger Ebene, sodass Sie entscheiden können, wie Fehler behandelt werden sollen.
Änderungsfeed in APIs für Cassandra und MongoDB
Die Funktionen des Änderungsfeeds werden in der API für MongoDB als Änderungsdatenströme 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 for MongoDB.
Natives Apache Cassandra bietet Change Data Capture (CDC). Hierbei handelt es sich um 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.
Nächste Schritte
In den folgenden Artikeln erfahren Sie mehr über den Änderungsfeed: