Comment puis-je consommer les flux de modifications ?

Pour une seule base de données est orders, je peux demander à la base de données une liste de modifications, dans ce cas, en limitant l'ensemble de résultats à cinq modifications avec ?limit=5 :

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

L'appel d'API renvoie les modifications suivantes :

results

un tableau de modifications.

last_seq

Un jeton pouvant être fourni au point de terminaison « changes » lors d'un appel API ultérieur afin d'obtenir le lot suivant de modifications.

Découvrez comment extraire le prochain lot de modifications dans l'exemple suivant :

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

Le paramètre since permet de définir l'emplacement dans le flux de modifications que vous souhaitez démarrer à partir de :

since=0

Le début du flux des modifications.

since=now

Fin du flux des modifications.

since=<a last seq token>

À partir d'un emplacement connu dans le flux des modifications.

A la valeur nominale, le suivi du flux de modifications semble aussi simple que le chaînage des appels d'API _changes ensemble. Ensuite, IBM Cloudant transmet la réponse last_seq from one changes feed au paramètre since de la demande suivante. Mais certaines subtilités de changements ont besoin de détails plus approfondis.

Pourquoi le flux des modifications diffuse-t-il chaque modification au moins une fois?

La norme « IBM Cloudant » modifie les promesses des flux : elle prévoit désormais de renvoyer chaque document au moins une fois, ce qui n'est pas la même chose que de s'engager à renvoyer chaque document une seule fois. En d'autres termes, il est possible pour un consommateur de changes feed de voir à nouveau le même changement, ou bien un ensemble de modifications répétées.

Un consommateur du flux de modifications doit traiter les modifications Idempotence. En pratique, vous devez vous rappeler si un changement a déjà été traité avant de déclencher une action à partir d'un changement. Un consommateur de flux de modifications naïf peut envoyer un message à un smartphone à chaque réception de changement. Toutefois, un utilisateur peut recevoir des messages texte en double si une modification n'est pas traitée de manière idempotente lorsque des modifications sont effectuées.

Habituellement, ces évènements en double des flux de modifications sont courts et uniquement une poignée de ces changements sont effectués en double. Mais dans certains cas, une demande peut voir une réponse avec des milliers de modifications rejouées -potentiellement toutes les modifications depuis le début de la période. Le potentiel de rewinds rend le changes feed inapproprié pour une application qui attend un comportement de type file d'attente.

Pour rappel, le flux de modifications de IBM Cloudant garantit la diffusion d'un document au moins une fois dans un flux de modifications, mais n'offre aucune garantie quant à la présence de valeurs identiques dans plusieurs requêtes.

Est-ce que les changements opèrent en " temps réel " ?

Le flux de modifications ne garantit pas la rapidité avec laquelle une modification entrante apparaît sur un client qui consomme le flux de modifications. Les applications ne doivent pas être développées en supposant que les insertions, les mises à jour et les suppressions de données soient immédiatement propagées à un lecteur de modifications.

Pourquoi tous les changements de document individuels n'apparaissent pas dans les flux de modifications ?

Si un document est mis à jour à plusieurs reprises entre deux appels du flux des modifications, il se peut que ce dernier ne reflète que la dernière de ces modifications. Le client ne reçoit pas toutes les modifications de chaque document.

Le flux de modifications IBM Cloudant n'est pas un Journal des transactions qui contient tous les évènements qui se sont produits dans le temps.

Puis-je utiliser un flux de modifications filtrées pour les requêtes opérationnelles ?

Le filtrage du flux de modifications, et par extension, l'exécution d'une réplication filtrée, présente certains avantages :

• Copie de données de la source vers la cible tout en ignorant les documents supprimés.
• Copie de données mais sans définitions d'index (documents de conception).

Cet article de blogue décrit comment le fait de fournir un selector lors de la réplication permet le bon fonctionnement de ces cas d'utilisation.

Le flux de modifications avec un paramètre selector qui l'accompagne n'est Pas la bonne manière d'extraire des tranches de données de la base de données de manière habituelle. Il ne doit pas être utilisé pour effectuer des requêtes opérationnelles sur une base de données. Les modifications filtrées sont lentes (le filtre est appliqué à chaque document modifié un par un, sans l'aide d'un index). Ce processus est beaucoup plus lent que la création d'un index secondaire (tel qu'une vue MapReduce ) et l'interrogation de cette vue.

Un flux de modifications feed=continuous continue-t-il à s'exécuter indéfiniment?

Non, IBM Cloudant ne garantit pas la durée de connexion pour un flux de changements continus. Il peut être régulièrement déconnecté par le serveur pour diverses raisons, notamment des opérations de maintenance, des problèmes de sécurité ou des erreurs réseau. Le code qui utilise le flux de modifications doit être conçu pour utiliser un ID de séquence enregistré récemment comme valeur sincepour effectuer une nouvelle demande de reprise des flux après une erreur ou une déconnexion.

Pourquoi les flux de modification ne garantissent-ils pas le temps de commande ?

Si le cas d'utilisation est basé sur l'instruction suivante, alors ce résultat ne peut pas être obtenu avec le flux de modifications IBM Cloudant.

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

La base de données IBM Cloudant n'enregistre pas le moment où chaque modification de document a été écrite. Le flux des modifications ne garantit pas l'ordre des modifications dans le flux - elles ne sont pas garanties d'être dans l'ordre où elles ont été envoyées à la base de données à l'origine.

Toutefois, vous pouvez arriver à ce cas d'utilisation en inscrivant et en stockant la date de modification dans le corps du document :

{
  "_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"
}

Vous pouvez également créer une vue MapReduce avec last_edit_date comme clé :

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

Cette vue peut être interrogée pour renvoyer tous les documents qui sont modifiés sur ou après une date et une heure fournies :

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

Cette technique produit un ensemble de résultats triés avec le temps, sans valeurs répétées, et est performante et reproductible. L'utilisateur de ces données pas n'a pas besoin de les gérer de manière idempotente, ce qui simplifie le processus de développement.

À quoi servent les flux de modifications IBM Cloudant ?

Le flux de modifications IBM Cloudant est utile pour les tâches suivantes :

• Mise sous tension de la réplication IBM Cloudant, éventuellement avec un sélecteur pour filtrer certains changements.
• Les clients traitent le flux de modifications par lots, mais gèrent chaque modification de manière idempotente, sans se soucier de l'ordre de tri et en s'attendant à voir certaines modifications apparaître plusieurs fois.

Le flux de modifications IBM Cloudant n'est pas pertinent pour les composants suivants :

• Une file d'attente de messages. Pour plus d'informations, consultez IBM Messages for RabbitMQ sur la gestion des files d'attente.
• Un courtier de messages. Pour plus d'informations, voir IBM Event Streams sur la gestion de flux d'événements évolutifs et ordonnés dans le temps.
• Un système de publication et d'abonnement en temps réel. Pour plus d'informations, consultez IBM Databases for Redis la gestion des sujets de publication et d'abonnement.
• Un journal des transactions. Certaines bases de données enregistrent chaque modification dans un journal des transactions, mais la nature distribuée et « à cohérence finale » d’ IBM Cloudant implique qu’il n’existe pas de journal des transactions définitif classé par ordre chronologique.
• Un mécanisme d'interrogation. Pour plus d'informations, voir lesVues MapReduce pour créer des vues de vos données qui sont commandées par une clé de votre choix.