Modèles de conception de flux de modification dans Azure Cosmos DB for NoSQL

Le flux de modification Azure Cosmos DB vous permet de traiter efficacement des jeux de données volumineux avec des volumes d’écriture élevés. Il offre une alternative à l’interrogation de jeux de données entiers pour identifier les modifications. Cet article présente les modèles courants de conception de flux de modification, leurs compromis et leurs limitations pour vous aider à créer des solutions évolutives.

Scénarios

Azure Cosmos DB est idéal pour les applications d’IoT, de jeux, de vente au détail et de journalisation opérationnelle. Ces applications intègrent souvent un modèle de conception qui consiste à déclencher d’autres actions à l’aide de modifications de données. Ces actions sont les suivantes :

• Déclenchement d’une notification ou d’un appel d’API lorsqu’un élément est inséré, mis à jour ou supprimé
• Traitement de flux en temps réel pour l’IoT ou analyse en temps réel des données opérationnelles
• Déplacement de données tels que la synchronisation avec un cache, un moteur de recherche, un entrepôt de données ou un stockage à froid

Le flux de modification Azure Cosmos DB vous permet de créer des solutions efficaces et évolutives pour ces modèles, comme illustré dans l’image suivante :

Calcul d’événements et notifications

Le flux de modification Azure Cosmos DB simplifie les scénarios qui déclenchent une notification ou appellent une API en fonction d’un événement spécifique. Le processeur de flux de modification vous permet d’interroger automatiquement votre conteneur pour les modifications et d’appeler une API externe pour chaque écriture, mise à jour ou suppression.

Déclenchez de manière sélective une notification ou appelez une API en fonction de critères spécifiques. Par exemple, si vous lisez à partir du flux de modification à l’aide d’Azure Functions, ajoutez une logique à la fonction pour envoyer une notification seulement si une condition est remplie. Bien que le code de fonction Azure s’exécute pour chaque modification, la notification est envoyée seulement si la condition est remplie.

Traitement du flux en temps réel

Le flux de modification Azure Cosmos DB vous permet d’effectuer le traitement de flux en temps réel pour l’IoT ou l’analyse en temps réel des données opérationnelles. Par exemple, vous pouvez recevoir et stocker des données d’événement à partir d’appareils, de capteurs, d’infrastructures et d’applications, et traiter ces événements en temps réel à l’aide de Spark. L’image suivante montre comment implémenter une architecture lambda à l’aide du flux de modification Azure Cosmos DB :

Dans de nombreux cas, les implémentations de traitement de flux reçoivent d’abord un volume élevé de données entrantes dans une file d’attente de messages temporaire comme Azure Event Hubs ou Apache Kafka. Le flux de modification est une alternative intéressante en raison de la capacité d’Azure Cosmos DB à prendre en charge un taux élevé et soutenu d’ingestion de données avec une latence de lecture et d’écriture faible et garantie.

Persistance des données

Les données écrites dans Azure Cosmos DB s’affichent dans le flux de modification. En mode version la plus récente, les données restent dans le flux de modification jusqu’à la suppression. Les files d’attente de messages ont généralement une durée de conservation maximale. Par exemple, Azure Event Hubs offre une durée de conservation des données maximale de 90 jours.

Capacité de requête

Outre la lecture à partir du flux de modification d’un conteneur Azure Cosmos DB, exécutez des requêtes SQL sur les données stockées dans Azure Cosmos DB. Le flux de modification n’est pas une duplication des données qui se trouvent déjà dans le conteneur, mais plutôt un mécanisme de lecture des données différent. Par conséquent, si vous lisez des données à partir du flux de modification, elles sont toujours cohérentes avec les requêtes du même conteneur Azure Cosmos DB.

Disponibilité élevée

Azure Cosmos DB offre jusqu’à 99,999 % de disponibilité en lecture et en écriture. Contrairement à de nombreuses files d’attente de messages, les données Azure Cosmos DB peuvent être distribuées et configurées mondialement avec un objectif de temps de récupération (RTO) de zéro.

Après avoir traité des éléments dans le flux de modification, créez une vue matérialisée et conservez les valeurs agrégées dans Azure Cosmos DB. Par exemple, le flux de modification d’Azure Cosmos DB vous permet d’implémenter des classements en temps réel en fonction des scores des jeux terminés.

Déplacement des données

Lisez à partir du flux de modification pour le déplacement des données en temps réel.

Par exemple, le flux de modification vous permet d’effectuer efficacement les tâches suivantes :

• Mettre à jour un cache, un index de recherche ou un entrepôt de données avec des données stockées dans Azure Cosmos DB

• Effectuer des migrations sans aucun temps d’arrêt vers un autre compte ou conteneur Azure Cosmos DB comportant une clé de partition logique différente.

• Implémenter une hiérarchisation et un archivage des données au niveau de l’application. Par exemple, stockez des « données chaudes » dans Azure Cosmos DB et vieillissez les « données froides » vers d’autres systèmes de stockage tels que Stockage Blob Azure.

Quand vous devez dénormaliser des données dans des partitions et des conteneurs, vous pouvez lire le flux de modification de votre conteneur en tant que source pour cette réplication de données. La réplication des données en temps réel avec le flux de modification garantit uniquement la cohérence finale. Vous pouvez superviser le retard du processeur de flux de modification dans le traitement des modifications dans votre conteneur Azure Cosmos DB.

Provisionnement en événements

Le modèle d’approvisionnement en événements enregistre la série complète d’actions sur les données à l’aide d’un magasin avec ajout uniquement. Le flux de modification Azure Cosmos DB est un bon choix de magasin de données central dans les architectures d’approvisionnement en événements dans lesquelles toute l’ingestion des données est modélisée en tant qu’écritures (aucune mise à jour ou suppression). Dans ce cas, chaque écriture dans Azure Cosmos DB est un « événement », donc le flux de modification comporte un enregistrement complet des événements passés. Les utilisations les plus courantes des événements publiés par le magasin d’événements central concernent la gestion des vues matérialisées ou l’intégration à des systèmes externes. Comme il n’existe pas de limite de temps pour la conservation en mode version la plus récente du flux de modification, vous pouvez relire tous les événements passés en lisant à partir du début du flux de modification de votre conteneur Azure Cosmos DB. Vous pouvez même faire en sorte que plusieurs consommateurs de flux de modification s’abonnent au flux de modification du même conteneur.

Azure Cosmos DB est un excellent magasin de données avec ajout uniquement, persistant et centralisé dans le modèle d’approvisionnement en événements en raison de ses atouts en matière de scalabilité horizontale et de haute disponibilité. En outre, le processeur de flux de modification offre une garantie « au moins une fois », qui permet d’être certain que tous les événements sont traités.

Limitations actuelles

Le flux de modification a plusieurs modes, chacun avec des limitations importantes que vous devez comprendre. Vous devez prendre en compte plusieurs points lorsque vous concevez une application qui utilise le flux de modification en mode version la plus récente ou en mode toutes les versions et suppressions.

Mises à jour intermédiaires

Suppressions

Retention

Ordre garanti

Tous les modes du flux de modification ont un ordre garanti au sein d’une valeur de clé de partition, mais pas entre les valeurs de clés de partitions. Vous devez sélectionner une clé de partition qui vous donne une garantie d’ordre significatif.

Prenons l’exemple d’une application de vente au détail qui utilise le modèle de conception d’approvisionnement en événements. Dans cette application, différentes actions utilisateur sont chacun des « événements » qui sont modélisés en tant qu’écritures dans Azure Cosmos DB. Imaginez que des exemples d’événements se produisent dans l’ordre suivant :

1. Le client ajoute l’article A à son panier d’achat.
2. Le client ajoute l’article B à son panier d’achat.
3. Le client supprime l’article A de son panier d’achat.
4. Le client valide son achat et le contenu du panier est expédié.

Une vue matérialisée du contenu actuel du panier d’achat est tenue à jour pour chaque client. Cette application doit s’assurer que ces événements sont traités dans l’ordre dans lequel ils se produisent. Par exemple, si le paiement du panier était traité avant la suppression de l’article A, il est probable que l’article A serait expédié au client au lieu de l’article B souhaité par le client. Pour vous assurer que ces quatre événements sont traités dans l’ordre, ils doivent se trouver dans la même valeur de clé de partition. Si vous sélectionnez username (Chaque client a un nom d’utilisateur unique.) comme clé de partition, vous pouvez garantir que ces événements s’affichent dans le flux de modification dans l’ordre dans lequel ils sont écrits dans Azure Cosmos DB.

Examples

Voici des exemples de codes de flux de modification réels pour le mode version la plus récente qui dépassent le cadre des exemples fournis :

• Pour en savoir plus, consultez Présentation du flux de modification.
• Pour en savoir plus, consultez Cas d’utilisation IoT axé sur le flux de modification.
• Pour en savoir plus, consultez Cas d’utilisation de vente au détail axé sur le flux de modification.

Contenu connexe

• Vue d’ensemble du flux de modification
• Modes du flux de modification
• Options de lecture de votre flux de modification