Wie nutze ich den Änderungsfeed?

Bei einer einzelnen Datenbank orders kann eine Liste von Änderungen aus der Datenbank anfordern. In diesem Fall wird die Ergebnismenge mit ?limit=5 auf fünf Änderungen begrenzt:

GET /orders/_changes?limit=5
{
  "results": [
    {
      "seq": "1-g1AAAAB5eJzLYWBg",
      "id": "00002Sc12XI8HD0YIBJ92n9ozC0Z7TaO",
      "changes": [
        {
          "rev": "1-3ef45fdbb0a5245634dc31be69db35f7"
        }
      ]
    },
    ....
  ],
  "last_seq": "5-g1AAAAB5eJzLYWBg"
}

Der API-Aufruf gibt die folgenden Änderungen zurück:

results

Einem Array von Änderungen.

last_seq

Ein Token, das bei einem nachfolgenden API-Aufruf an den Endpunkt „changes“ übermittelt werden kann, um den nächsten Satz an Änderungen abzurufen.

Im folgenden Beispiel wird gezeigt, wie die nächste Gruppe von Änderungen abgerufen wird:

GET /orders/_changes?limit=5&since=5-g1AAAAB5eJzLYWBg
{
  "results": [ ...],
  "last_seq": "10-g1AAAACbeJzLY"
}

Der Parameter since wird verwendet, um die Position im Feed für Änderungen zu definieren, von der aus Sie beginnen möchten:

since=0

Der Anfang des Feeds „Changes“.

since=now

Das Ende des Änderungs-Feeds.

since=<a last seq token>

Von einer bekannten Stelle im Änderungsfeed.

Bei Nennwert scheint das Folgen des Änderungsfeeds so einfach wie das Verketten von _changes-API-Aufrufen zu sein. Anschließend übergibt IBM Cloudant die Antwort last_seq aus einer changes feed an den Parameter since der nächsten Anforderung. Aber einige Details beim Änderungsfeed müssen näher erläutert werden.

Warum liefert der „Changes“-Feed jede Änderung mindestens einmal?

Der Standard „ IBM Cloudant “ sieht vor, dass Feeds versprechen, jedes Dokument mindestens einmal zurückzugeben; dies ist nicht dasselbe wie das Versprechen, jedes Dokument nur einmal zurückzugeben. Anders ausgedrückt ist es möglich, dass ein Nutzer des changes feed dieselbe Änderung oder auch mehrere Änderungen wiederholt sieht.

Ein Nutzer des Änderungsfeeds muss die Änderungen idempotent behandeln. In der Praxis müssen Sie sich merken, ob eine Änderung bereits behandelt wurde, bevor Sie eine Aktion aus einer Änderung heraus auslösen. Ein 'unbedarfter' Nutzer des Änderungsfeeds könnte bei jeder empfangenen Änderung eine Nachricht an ein Smartphone senden. Ein Benutzer kann Textnachrichten jedoch doppelt empfangen, falls eine Änderung nicht idempotent behandelt wird, wenn Änderungen wiederholt auftreten.

Normalerweise dauern diese "Rückspulungen" des Änderungsfeeds nur kurz an und geben nur eine Handvoll von Änderungen wieder. In einigen Fällen kann eine Anfrage jedoch eine Antwort mit Tausenden von Änderungen erhalten - möglicherweise alle Änderungen seit Beginn. Das Potenzial für rewinds macht die changes feed für eine Anwendung ungeeignet, die ein warteschlangenähnliches Verhalten erwartet.

Zur Erinnerung: Der Changes Feed von IBM Cloudant verspricht, ein Dokument mindestens einmal im Changes Feed zu liefern, gibt jedoch keine Garantie dafür, dass Werte über mehrere Anfragen hinweg identisch sind.

Arbeitet der Änderungsfeed in Echtzeit?

Der Änderungsfeed garantiert in keinerlei Hinsicht, wie schnell eine eingehende Änderung für einen Client angezeigt wird, der den Änderungsfeed nutzt. Anwendungen dürfen nicht unter der Annahme entwickelt werden, dass Einfügungen, Aktualisierungen und Löschungen von Daten sofort an einen Änderungsempfänger weitergegeben werden.

Warum werden nicht alle Änderungen einzelner Dokumente im Änderungsfeed angezeigt?

Wird ein Dokument zwischen zwei Abrufen des Änderungsfeeds mehrmals aktualisiert, spiegelt der Änderungsfeed möglicherweise nur die jüngste dieser Änderungen wider. Der Client erhält nicht jede Änderung an jedem Dokument.

Der IBM Cloudant-Änderungsfeed ist kein Transaktionsprotokoll, das jedes Ereignis in zeitlicher Reihenfolge enthält.

Kann ich einen gefilterten Änderungsfeed für operative Abfragen verwenden?

Das Filtern des Änderungs-Feeds und damit auch die Durchführung einer gefilterten Replikation hat ihre Vorteile:

• Das Kopieren von Daten von der Quelle zum Ziel, wobei gelöschte Dokumente ignoriert werden.
• Das Kopieren von Daten, jedoch ohne Indexdefinitionen (Entwurfsdokumente).

In diesem Blogbeitrag wird beschrieben, wie die Bereitstellung einer selector während der Replikation dazu führt, dass diese Anwendungsfälle reibungslos funktionieren.

Der Änderungsfeed mit einem zugehörigen Parameter selector ist aber nicht dazu geeignet, Datenausschnitte (Slices of Data) routinemäßig aus der Datenbank zu extrahieren. Es darf nicht dazu verwendet werden, operative Abfragen an eine Datenbank zu stellen. Gefilterte Änderungen sind langsam (der Filter wird auf jedes geänderte Dokument angewendet, ohne die Hilfe eines Index). Dieser Prozess nimmt viel mehr Zeit in Anspruch als das Erstellen eines Sekundärindex (wie z. B. eine MapReduce-Ansicht) und das Abfragen dieser Ansicht.

Wird ein feed=continuous-Änderungsfeed weiterhin unbegrenzt ausgeführt?

Nein, IBM Cloudant garantiert keine Verbindungsdauer für einen kontinuierlichen Änderungsfeed. Die Verbindung kann aus verschiedenen Gründen regelmäßig vom Server unterbrochen werden, darunter Wartungsarbeiten, Sicherheitsmaßnahmen oder Netzwerkfehler. Code, der den Änderungsfeed verwendet, muss so konzipiert sein, dass eine kürzlich gespeicherte Sequenz-ID als since-Wert verwendet wird, um eine neue Anforderung zum Fortsetzen des Änderungsfeeds nach einem Fehler oder einer Unterbrechung durchzuführen.

Warum garantiert der Änderungsfeed nicht die richtige zeitliche Anordnung?

Wenn der Anwendungsfall auf der folgenden Anweisung basiert, kann dieses Ergebnis nicht mit dem IBM Cloudant-Änderungsfeed erzielt werden.

"Fetch me every document that has changed since a known date, in the order they were written."

Die IBM Cloudant-Datenbank zeichnet nicht die Zeit auf, zu der jede Dokumentänderung geschrieben wurde. Der Änderungsfeed gibt keine Garantie bezüglich der Reihenfolge der Änderungen im Feed - es wird nicht garantiert, dass sie der Reihenfolge entspricht, in der die Änderungen an die Datenbank gesendet wurden.

Sie können diesen Anwendungsfall jedoch erreichen, indem Sie das Änderungsdatum im Dokumenthauptteil speichern:

{
  "_id": "2657",
  "type": "order",
  "customer": "bob@aol.com",
  "order_date": "2022-01-05T10:40:00",
  "status": "dispatched",
  "last_edit_date": "2022-01-14T19:17:20"
}

Außerdem können Sie eine MapReduce-Ansicht mit last_edit_date als Schlüssel erstellen:

function(doc) {
  emit(doc.last_edit_date, null)
}

Diese Ansicht kann abgefragt werden, um alle Dokumente zurückzugeben, die an bzw. nach einem angegebenen Datum und einer angegebenen Uhrzeit geändert wurden.

/orders/_design/query/_view/by_last_edit?startkey="2022-01-13T00:00:00"

Dieses Verfahren erzeugt eine zeitlich geordnete Ergebnismenge ohne wiederholte Werte - schnell und wiederholbar. Der Nutzer dieser Daten muss die Daten nicht idempotent verwalten, was den Entwicklungsprozess vereinfacht.

Wofür eignet sich der IBM Cloudant-Änderungsfeed?

Der IBM Cloudant-Änderungsfeed eignet sich für die folgenden Tasks:

• Unterstützung der IBM Cloudant-Replikation - optional mit einem Selektor zum Filtern einiger Änderungen.
• Kunden, die den Änderungs-Feed stapelweise verarbeiten, dabei jedoch jede Änderung idempotent behandeln, ohne auf die Sortierreihenfolge zu achten, und damit rechnen, dass manche Änderungen mehr als einmal angezeigt werden.

Der IBM Cloudant-Änderungsfeed eignet sich nicht für folgende Komponenten:

• Nachrichtenwarteschlange. Weitere Informationen finden Sie unter IBM Messages for RabbitMQ zur Verwaltung von Warteschlangen.
• Nachrichtenbroker. Weitere Informationen finden Sie unter IBM Event Streams zur Verarbeitung skalierbarer, zeitlich geordneter Ereignisströme.
• Ein echtzeitorientiertes Publish/Subscribe-System. Weitere Informationen finden Sie unter IBM Databases for Redis zur Handhabung von Publish- und Subscribe-Themen.
• Transaktionsprotokoll. Einige Datenbanken speichern jede Änderung in einem Transaktionsprotokoll, doch aufgrund des verteilten und letztendlich konsistenten Charakters von „ IBM Cloudant “ gibt es kein endgültiges, zeitlich geordnetes Transaktionsprotokoll.
• Abfragemechanismus. Weitere Informationen zum Erstellen von Ansichten Ihrer Daten, die nach einem Schlüssel Ihrer Wahl sortiert sind, finden Sie in MapReduce-Ansichten.