Freigeben über

Änderungsfeed-Entwurfsmuster in Azure Cosmos DB

  • Artikel

GILT FÜR: NoSQL

Der Änderungsfeed von Azure Cosmos DB ermöglicht eine effiziente Verarbeitung großer Datasets mit vielen Schreibvorgängen. Der Änderungsfeed bietet zudem eine Alternative zum Abfragen eines gesamten Datasets, um Änderungen zu ermitteln. Dieser Artikel konzentriert sich auf allgemeine Entwurfsmuster für Änderungsfeeds, Entwurfskompromisse und Einschränkungen von Änderungsfeeds.

Azure Cosmos DB eignet sich besonders gut für IoT-, Spiele-, Verkaufs- und Vorgangsprotokollierungsanwendungen. Ein allgemeines Entwurfsmuster in diesen Anwendungen ist die Verwendung von Datenänderungen, um andere Aktionen auszulösen. Zu diesen Aktionen zählen beispielsweise folgende:

  • Auslösen einer Benachrichtigung oder eines Aufrufs einer API, wenn ein Element eingefügt, aktualisiert oder gelöscht wird.
  • Streamverarbeitung in Echtzeit für IoT oder Analyseverarbeitung in Echtzeit für operative Daten
  • Datenbewegungen wie die Synchronisierung mit einem Cache, einer Suchmaschine, einem Data Warehouse oder mit Cold Storage.

Mit dem Änderungsfeed in Azure Cosmos DB können Sie effiziente und skalierbare Lösungen für jedes dieser Muster erstellen, wie in der folgenden Abbildung gezeigt:

Diagramm, das die Verwendung eines Azure Cosmos DB-Änderungsfeeds für Echtzeit-Analysen und ereignisgesteuerte Computingszenarien zeigt

Ereignisse und Benachrichtigungen

Der Änderungsfeed von Azure Cosmos DB kann Szenarien vereinfachen, in denen eine Benachrichtigung oder ein API-Aufruf basierend auf einem bestimmten Ereignis ausgelöst oder gesendet werden muss. Sie können den Änderungsfeedprozessor verwenden, um den Container automatisch nach Änderungen abzufragen und eine externe API aufzurufen, wenn ein Schreib-, Aktualisierungs- oder Löschvorgang vorliegt.

Sie können auch selektiv eine Benachrichtigung auslösen oder einen Aufruf an eine API basierend auf bestimmten Kriterien senden. Wenn Sie z. B. mit Azure Functions aus dem Änderungsfeed lesen, können Sie Logik in die Funktion einfügen, damit nur dann eine Benachrichtigung gesendet wird, wenn eine Bedingung erfüllt ist. Während der Azure-Funktionscode für jede Änderung ausgeführt wird, wird die Benachrichtigung nur gesendet, wenn die Bedingung erfüllt ist.

Streamverarbeitung in Echtzeit-

Der Änderungsfeed von Azure Cosmos DB kann für Streamverarbeitung in Echtzeit für IoT oder Analysen in Echtzeit für operative Daten verwendet werden. Sie empfangen und speichern möglicherweise Ereignisdaten von Geräten, Sensoren, Infrastrukturen und Anwendungen und verarbeiten diese Ereignisse z. B. in Echtzeit mithilfe von Spark. In der folgenden Abbildung wird dargestellt, wie Sie eine Lambda-Architektur mithilfe des Azure Cosmos DB-Änderungsfeeds implementieren können:

Diagramm, das eine Azure Cosmos DB-basierte Lambda-Pipeline für die Erfassung und Abfrage zeigt

In vielen Fällen empfangen Streamverarbeitungsimplementierungen zunächst eine große Menge eingehender Daten in einer temporären Nachrichtenwarteschlange, z. B. mit Azure Event Hubs oder Apache Kafka. Der Änderungsfeed ist eine gute Alternative, weil Azure Cosmos DB eine anhaltend hohe Rate der Datenerfassung mit garantierter geringer Lese- und Schreiblatenz unterstützen kann. Die folgenden Vorteilen ergeben sich, wenn der Änderungsfeed von Azure Cosmos DB über eine Nachrichtenwarteschlange erfolgt:

Datenpersistenz

Daten, die in Azure Cosmos DB geschrieben wurden, werden im Änderungsfeed angezeigt. Wenn Sie im Modus der neuesten Version lesen, werden die Daten im Änderungsfeed aufbewahrt, bis sie gelöscht werden. Nachrichtenwarteschlangen wiesen in der Regel eine maximale Beibehaltungsdauer auf. Beispielsweise bietet Azure Event Hubs eine maximale Datenaufbewahrung von 90 Tagen.

Abfragefähigkeit

Zusätzlich zum Lesen aus dem Änderungsfeed eines Azure Cosmos DB-Containers können Sie auch SQL-Abfragen für die in Azure Cosmos DB gespeicherten Daten ausführen. Der Änderungsfeed ist keine Duplizierung von Daten, die sich bereits im Container befinden, sondern lediglich ein anderer Mechanismus zum Lesen der Daten. Daher sind beim Lesen von Daten aus dem Änderungsfeed diese immer konsistent mit Abfragen an denselben Azure Cosmos DB-Container.

Hochverfügbarkeit

Azure Cosmos DB bietet bis zu 99,999 % Lese- und Schreibverfügbarkeit. Im Gegensatz zu vielen Nachrichtenwarteschlangen können Azure Cosmos DB-Daten problemlos global verteilt und mit einem Ziel für die Wiederherstellungszeit (Recovery Time Objective, RTO) von null konfiguriert werden.

Nachdem Sie Elemente im Änderungsfeed verarbeitet haben, können Sie eine materialisierte Sicht erstellen und aggregierte Werte in Azure Cosmos DB persistent speichern. Wenn Sie Azure Cosmos DB zum Erstellen eines Spiels verwenden, können Sie den Änderungsfeed beispielsweise verwenden, um in Echtzeit Bestenlisten anhand der Ergebnisse von abgeschlossenen Spielen zu implementieren.

Datenverschiebung

Sie können auch aus dem Änderungsfeed lesen, um Datenverschiebungen in Echtzeit abzurufen.

Mit einem Änderungsfeed können Sie beispielsweise die folgenden Aufgaben effizient ausführen:

  • Aktualisieren eines Caches, eines Suchindex oder eines Data Warehouse mit in Azure Cosmos DB gespeicherten Daten.

  • Ausführen von Migrationsvorgängen zu einem anderen Azure Cosmos DB-Konto oder einem anderen Azure Cosmos DB-Container mit einem anderen logischen Partitionsschlüssel ohne Ausfallzeit.

  • Implementieren von Datentiering und Archivierung auf Anwendungsebene. Beispielsweise können Sie „heiße Daten“ in Azure Cosmos DB speichern und „alte Daten“ in andere Speichersysteme (z. B. Azure Blob Storage) auslagern.

Wenn Sie Daten über Partitionen und Container hinweg denormalisieren müssen, können Sie für diese Datenreplikation aus dem Änderungsfeed Ihres Containers als Quelle lesen. Datenreplikation in Echtzeit mit dem Änderungsfeed kann nur eine mögliche Konsistenz gewährleisten. Sie können überwachen, wie weit der Änderungsfeedprozessor bei der Verarbeitung von Änderungen in Ihrem Azure Cosmos DB-Container zurückliegt.

Ereignissourcing

Das Ereignissourcingmuster beinhaltet die Verwendung eines reinen Anfügespeichers zum Aufzeichnen aller Aktionen für diese Daten. Der Änderungsfeed von Azure Cosmos DB ist eine gute Wahl als zentraler Datenspeicher in Event-Sourcing-Architekturen, in denen die gesamte Datenerfassung als Schreibvorgänge (keine Aktualisierungen oder Löschungen) modelliert wird. In diesem Fall ist jeder Schreibvorgang in Azure Cosmos DB ein „Ereignis“, d. h. es gibt einen vollständigen Datensatz früherer Ereignisse im Änderungsfeed. Typische Verwendungsmöglichkeiten von Ereignissen, die vom zentralen Ereignisspeicher veröffentlicht werden, sind die Verwaltung materialisierter Sichten oder die Integration in externe Systeme. Da es keine zeitliche Beschränkung für die Datenaufbewahrung im Modus für die neueste Version im Änderungsfeed gibt, können Sie alle vergangenen Ereignisse wiedergeben, indem vom Anfang des Änderungsfeeds Ihres Azure Cosmos DB-Containers an gelesen wird. Sie können sogar mehrere Änderungsfeedconsumer den Änderungsfeed des gleichen Containers abonnieren lassen.

Azure Cosmos DB ist aufgrund der Stärken hinsichtlich horizontaler Skalierbarkeit und Hochverfügbarkeit ein großartiger zentraler und persistenter reiner Anfügespeicher im Ereignissourcingmuster. Außerdem bietet der Änderungsfeed-Prozessor eine Garantie des Typs „mindestens ein Mal“, die sicherstellt, dass wirklich alle Ereignisse verarbeitet werden.

Aktuelle Einschränkungen

Der Änderungsfeed verfügt über mehrere Modi, die jeweils wichtige Einschränkungen aufweisen, die Sie kennen sollten. Beim Entwerfen einer Anwendung, die den Änderungsfeed entweder im Modus der neuesten Version oder im Modus Alle Versionen und Löschmodus verwendet, sind mehrere Bereiche zu berücksichtigen.

Zwischenaktualisierungen

Im Modus der neuesten Version ist nur die letzte Änderung für ein bestimmtes Element im Änderungsfeed enthalten. Wenn Änderungen verarbeitet werden, lesen Sie die neueste verfügbare Elementversion. Wenn mehrere Aktualisierungen für das gleiche Element innerhalb kurzer Zeit vorhanden sind, wird möglicherweise die Verarbeitung von Zwischenaktualisierungen verpasst. Wenn Sie frühere einzelne Updates für ein Element erneut durchführen möchten, können Sie diese Updates stattdessen als Reihe von Schreibvorgängen modellieren oder „Alle Versionen und Löschmodus“ verwenden.

Löschvorgang

Der Modus der neuesten Version für den Änderungsfeed erfasst keine Löschvorgänge. Wenn Sie ein Element aus dem Container löschen, wird es auch aus dem Änderungsfeed entfernt. Die gebräuchlichste Methode zur Bearbeitung von Löschvorgängen ist das Hinzufügen eines vorläufigen Markers für die zu löschenden Elemente. Sie können eine Eigenschaft mit dem Namen deleted (gelöscht) hinzufügen und sie zum Zeitpunkt der Löschung auf true festlegen. Diese Dokumentaktualisierung wird im Änderungsfeed angezeigt. Sie können eine Gültigkeitsdauer (Time-to-Live, TTL) für dieses Element festlegen, damit es später automatisch gelöscht werden kann.

Aufbewahrung

Für den Änderungsfeed im Modus der neuesten Version gibt es eine unbegrenzte Aufbewahrungsdauer. Solange ein Element in Ihrem Container vorhanden ist, ist es im Änderungsfeed verfügbar.

Garantierte Reihenfolge

Alle Änderungsfeedmodi verfügen über eine garantierte Reihenfolge innerhalb eines Partitionsschlüsselwerts, jedoch nicht über Partitionsschlüsselwerte hinweg. Sie sollten einen Partitionsschlüssel auswählen, der Ihnen eine Garantie für eine sinnvolle Reihenfolge bietet.

Stellen Sie sich z. B. eine Einzelhandelsanwendung vor, die das Event-Sourcing-Entwurfsmuster verwendet. In dieser Anwendung sind unterschiedliche Benutzeraktionen jeweils „Ereignisse“, die als Schreibvorgänge in Azure Cosmos DB modelliert werden. Angenommen, einige Beispielereignisse sind in der folgenden Reihenfolge aufgetreten:

  1. Kunde bzw. Kundin fügt Artikel A dem Einkaufswagen hinzu.
  2. Kunde bzw. Kundin fügt Artikel B dem Einkaufswagen hinzu.
  3. Kunde bzw. Kundin entfernt Artikel A aus dem Einkaufswagen.
  4. Kunde bzw. Kundin geht zur Kasse, und der Inhalt des Einkaufswagens wird versendet.

Eine materialisierte Sicht der Inhalte des aktuellen Einkaufswagens wird für jeden Kunden verwaltet. Diese Anwendung muss sicherstellen, dass diese Ereignisse in der Reihenfolge verarbeitet werden, in der sie auftreten. Wenn der Check-Out des Einkaufswagens z. B. vor dem Entfernen von Artikel A verarbeitet würde, wäre es wahrscheinlich, dass Artikel A an den Kunden bzw. die Kundin geliefert würde, nicht der gewünschte Artikel B. Um sicherzustellen, dass diese vier Ereignisse in der Reihenfolge ihres Auftretens verarbeitet werden, müssen sie in den gleichen Partitionsschlüsselwert fallen. Wenn Sie username (jeder Kunde bzw. jede Kundin besitzt einen eindeutigen Benutzernamen) als Partitionsschlüssel ausgewählt haben, können Sie garantieren, dass diese Ereignisse im Änderungsfeed in derselben Reihenfolge erscheinen, in der sie in Azure Cosmos DB geschrieben werden.

Beispiele

Im Folgenden finden Sie einige praktische Änderungsfeed-Codebeispiele für den Modus der neuesten Version, die über die bereitgestellten Beispiele hinausgehen:

Nächste Schritte