L'utilisation de la Foire aux Questions des flux de modifications de IBM Cloudant

Le cas d'utilisation principale d'un flux de modifications de la base de données IBM Cloudant consiste à alimenter la réplication des données d'une source vers une base de données cible. Le réplicateur IBM Cloudant est conçu pour gérer le flux de modifications et effectue les vérifications nécessaires pour s'assurer que les données sont copiées avec précision jusqu'à leur destination.

IBM Cloudant dispose d'une API de flux de changements bruts qui peut être utilisée pour consommer les changements d'une seule base de données, mais elle doit être utilisée avec précaution.

Le nœud final d'API _changes peut être utilisé de plusieurs manières et peut générer des données sous différents formats. Mais ici, nous nous concentrons sur les meilleures pratiques et sur la façon d'éviter certains écueils lorsque vous développez à l'aide de l'API _changes .

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 qui peut être fourni au point de terminaison changes lors d'un appel ultérieur de l'API pour obtenir le prochain lot 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 de l'alimentation des changements.
since=now: La fin de l'alimentation des changements.
since=<a last seq token>: A partir d'un endroit connu dans le flux des changements.

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 de modifications transmet-il chaque modification au moins une fois?

La norme IBM Cloudant modifie les promesses de flux pour renvoyer chaque document au moins une fois, ce qui n'est pas la même chose que de promettre de 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 promet de fournir un document au moins une fois dans un flux de modifications et ne donne aucune garantie quant aux valeurs répétées sur 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 fois entre deux appels au flux de modifications, il se peut que le flux de modifications ne reflète que la plus récente 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 ont leur utilité :

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é comme un moyen d'exécuter 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 un certain nombre de raisons, notamment des erreurs de maintenance, de sécurité ou de 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. Le consommateur de ces données n'a pas besoin de les gérer de manière autonome, 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 consomment le flux de modifications par lots, mais traitent chaque modification de manière idempotente, sans se préoccuper de l'ordre de tri et en s'attendant à voir certaines modifications plus d'une 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, voir IBM Messages for RabbitMQ pour la gestion des files d'attente.
Un courtier de messages. Pour plus d'informations, voir IBM Event Streams pour gérer des 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, voir IBM Databases for Redis pour la gestion des thèmes 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 éventuellement cohérente de IBM Cloudant signifie qu'il n'existe pas de journal des transactions ordonné dans le temps.
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.