Les bases de données modernes doivent avoir la capacité de capturer et de réagir aux données lorsqu'elles circulent en temps réel. Cela explique pourquoi MongoDB dispose d'une fonctionnalité appelée MongoDB Change Streams chargée de capturer et de répondre aux données en temps réel. Change Streams est une fonctionnalité introduite pour diffuser des informations de l'application vers la base de données en temps réel. Il est basé sur un cadre d'agrégation qui surveille les collections et permet aux modifications de se produire dans la base de données et la collection de bases de données. De plus, MongoDB Change Stream peut capturer des données à partir de capteurs IOT et mettre à jour des rapports tels que les modifications de données opérationnelles dans une entreprise. Ce blog ouvrira le débat sur MongoDB Change Stream et modifiera les recommandations en production.
Modification des flux MongoDB et suppression de la collection
Renommer ou supprimer une base de données ou une collection entraînera la fermeture du curseur s'il y avait un flux de modifications ouvert travaillant sur la collection supprimée. Renommer ou supprimer une collection fait que le curseur avec FullDocument:updateLookup renvoie null sur n'importe quel document de recherche donné. Une erreur se produit si l'on tente de reprendre après avoir supprimé une base de données avec un flux de modifications en cours d'exécution.
En outre, toutes les modifications apportées aux données avant de renommer une collection avec un flux de modifications en cours d'exécution sont perdues. La limite de documents pour le flux de modification est toujours de 16 Mo BSON ; par conséquent, les documents de plus de 16 Mo ne sont pas acceptés. Si l'on tente de travailler avec un document de plus de 16 Mo, la notification échoue et le document est remplacé par un autre document qui respecte la limite définie.
Lorsqu'une collection ou une base de données avec des flux de modifications ouverts sur elle est supprimée ou renommée, les curseurs de flux de modifications ont tendance à se fermer à mesure qu'ils avancent jusqu'à ce point dans l'oplog. Si vous modifiez les curseurs de flux avec le document complet, l'option updateLookup peut renvoyer null au document de recherche.
Par conséquent, une tentative de reprise des flux de modifications sur une collection qui a été supprimée entraînera une erreur. Toute occurrence de modification de données dans la collection entre le dernier événement du flux de modifications capturé et l'événement de suppression de la collection est perdue.
Les documents de réponse de changement de flux doivent respecter la limite de 16 Mo de documents BSON. Selon la taille des documents de la collection sur laquelle vous ouvrez le flux de modifications, les notifications peuvent échouer si le document de notification résultant dépasse 16 Mo. Un bon exemple est les opérations de mise à jour sur les flux de modifications configurées pour renvoyer un document entièrement mis à jour ou remplacer/insérer des processus avec le document à la limite ou légèrement en dessous de la limite.
MongoDB Change Stream and Replica Sets
Un ensemble de répliques MongoDB est une collection de processus dans MongoDB dont l'ensemble de données ne change pas ; c'est-à-dire que l'ensemble de données reste le même. Dans le cas d'ensembles de répliques ayant des membres arbitres, les flux de modifications sont susceptibles de rester inactifs si suffisamment de membres portant les données ne sont pas disponibles pour que la majorité ne puisse pas valider les opérations. Par exemple, nous pouvons considérer un ensemble de réplicas ayant trois membres avec deux nœuds porteurs de données aux côtés d'un arbitre. Dans le cas où le secondaire serait en panne, par exemple à la suite d'une panne, d'une mise à niveau ou d'une maintenance, il sera impossible que les opérations d'écriture soient validées à la majorité. Le flux de modifications restera ouvert mais n'enverra aucune notification. Dans le scénario en question, l'application peut rattraper toutes les opérations qui ont eu lieu pendant la période d'indisponibilité, tant que la dernière opération reçue par l'application est toujours dans l'oplog de ce jeu de réplicas particulier. De plus, la commande rs.printReplicationInfo() est utilisée pour récupérer les données d'oplog ; les données récupérées incluent une gamme d'opérations et la taille de l'oplog.
Si le temps d'arrêt est estimé de manière significative, par exemple pour effectuer une mise à niveau ou en cas de sinistre, l'augmentation de la taille de l'oplog sera la meilleure option pour conserver les opérations pendant une période supérieure à le temps d'arrêt approximatif. Pour récupérer les informations d'état de l'oplog, la commande utilisée est printReplicationInfo(). La commande récupérera non seulement les informations sur l'état de l'oplog, mais également la taille de l'oplog et la plage de temps des opérations.
MongoDB Modifier la disponibilité des flux
Les flux de modifications MongoDB sont disponibles pour les jeux de répliques et les clusters fragmentés :activation "majoritaire" de Read Concern, moteur de stockage et version du protocole de jeu de répliques. Activation de la « majorité » de la préoccupation de lecture :à partir de la version 4.2 de MongoDB, les flux de modifications sont accessibles malgré les circonstances actuelles de la prise en charge de la préoccupation de lecture « majoritaire », ce qui signifie que la prise en charge de la majorité de la préoccupation de lecture peut être activée ou désactivée. Dans MongoDB version 4.0 et versions plus anciennes, les flux de modification ne sont disponibles que si la prise en charge des problèmes de lecture "majoritaire" est activée.
- Moteur de stockage :le moteur de stockage WiredTiger est le type de moteur de stockage utilisé par les jeux de répliques et les clusters fragmentés.
- Version du protocole d'ensemble de réplicas :les ensembles de réplicas et les clusters fragmentés doivent toujours utiliser la version 1 du protocole d'ensemble de réplicas (pv1).
Clusters partagés MongoDB
Les clusters partitionnés dans MongoDB sont constitués de partitions, de mongos et de serveurs de configuration. Une partition consiste en un sous-ensemble de données partitionnées. Dans le cas de MongoDB 3.6, les fragments sont utilisés comme jeu de répliques. Mongos fournit une interface entre les clusters partitionnés et les applications clientes ; mongos joue le rôle d'un routeur de requêtes. À partir de la version 4.4 de MongoDB et des versions ultérieures, mongos prend en charge les lectures couvertes pour réduire les latences. Les serveurs de configuration sont les emplacements de stockage des paramètres de configuration et des métadonnées du cluster.
Les flux de modifications utilisent une horloge logique globale pour fournir un ordre global des modifications sur les partitions. MongoDB garantit que l'ordre des modifications est maintenu et que les notifications du flux de modifications peuvent être interprétées en toute sécurité dans l'ordre dans lequel elles ont été reçues. Par exemple, le curseur du flux de modification ouvert sur un cluster à 3 partitions renvoie les notifications de modification concernant l'ordre total des modifications sur les trois partitions.
Pour garantir l'ordre total des modifications, Mongos vérifie avec chaque fragment pour voir s'il a vu des modifications plus récentes pour chaque notification de modification. Les clusters fragmentés avec un à plusieurs fragments avec peu ou pas d'activité de collecte ou sont "froids" sont susceptibles d'avoir des effets négatifs sur le temps de réponse du flux de changement puisque les mongos doivent encore vérifier avec ces fragments froids pour s'assurer de l'ordre total des changements. Cet effet peut être plus apparent lorsque les partitions sont réparties géographiquement ou lorsque les charges de travail avec la plupart des opérations se produisent sur un sous-ensemble de partitions dans un cluster. Si la collection fragmentée a un niveau d'activité élevé, les mongos peuvent ne pas réussir à suivre les changements sur tous les fragments. Envisagez d'utiliser des filtres de notification pour ce type de collection, par exemple en transmettant le pipeline $match, qui est configuré pour filtrer uniquement les opérations d'insertion.
Dans le cas de collections fragmentées, plusieurs opérations de mise à jour appropriées sont susceptibles de provoquer l'envoi de notifications pour les documents orphelins par les flux de modifications ouverts sur la collection. À partir du moment où une collection non partitionnée est partitionnée jusqu'au moment où le flux de modifications atteint le premier bloc de migration, le documentKey dans le document de notification de flux de modifications inclut uniquement l'ID du document et non la clé de partition complète.
Conclusion
Le but des flux de changement est de rendre possible les changements de données de l'application en temps réel, sans risque de traque dans l'oplog et sans aucune trace de complexité. Les applications MongoDB utilisent des flux de modifications pour signer les modifications de données sur une base de données, une collection ou le déploiement, et y réagir immédiatement. Étant donné que les flux de modifications utilisent le cadre d'agrégation, les applications peuvent filtrer les modifications spécifiques et convertir les notifications par elles-mêmes.
