Partager via

Modèles de conception des flux de modification dans Azure Cosmos DB

  • Article

S’APPLIQUE À : NoSQL

Le flux de modification Azure Cosmos DB permet de traiter efficacement les grands jeux de données qui ont un volume important d’écritures. Le flux de modification offre également une alternative à l’interrogation d’un jeu de données complet dans le but d’y identifier les changements. Cet article est axé sur les modèles de conception de flux de modification courants, les compromis de conception et les limitations des flux de modification.

Azure Cosmos DB est particulièrement bien adapté aux applications d’IoT, de jeux, de vente au détail et de journal des opérations. Ces applications intègrent souvent un modèle de conception qui consiste à utiliser des modifications de données pour déclencher des actions supplémentaires. Voici des exemples de ces actions :

  • Déclenchement d’une notification ou d’un appel à une API lorsqu’un élément est inséré, mis à jour ou supprimé.
  • Traitement du flux de données en temps réel pour l’IoT ou traitement d’analyse des données opérationnelles en temps réel
  • 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 scalables pour chacun de ces modèles, comme illustré dans l’image suivante :

Utilisation du flux de modification d’Azure Cosmos DB pour réaliser des analyses en temps réel et des scénarios de calculs pilotés par les événements.

Calcul d’événements et notifications

Le flux de modification Azure Cosmos DB peut simplifier les scénarios qui doivent déclencher l’envoi d’une notification ou un appel à une API en fonction d’un certain événement. Vous pouvez utiliser le processeur de flux de modification pour interroger automatiquement votre conteneur afin de détecter les modifications, puis appeler une API externe à chaque fois qu’une opération d’écriture, de mise à jour ou de suppression est effectuée.

Vous pouvez également déclencher de manière sélective une notification ou envoyer un appel à une API en fonction de critères spécifiques. Par exemple, si vous lisez le flux de modification à l’aide d’Azure Functions, vous pouvez insérer une logique dans la fonction afin d’envoyer une notification uniquement si une condition est remplie. Bien que le code Azure Function s’exécute pour chaque modification, la notification est envoyée uniquement si la condition est remplie.

Traitement du flux en temps réel

Le flux de modification Azure Cosmos DB peut être utilisé pour le traitement de flux en temps réel en vue du traitement de l’analytique en temps réel ou IoT sur 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, puis traiter ces événements en temps réel à l’aide de Spark. L’image suivante montre comment vous pouvez implémenter une architecture lambda en utilisant le flux de modification Azure Cosmos DB :

Diagramme montrant un pipeline lambda basé sur Azure Cosmos DB pour l’ingestion et l’interrogation.

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. Les avantages du flux de modification Azure Cosmos DB par rapport à une file d’attente de messages sont les suivants :

Persistance des données

Les données écrites dans Azure Cosmos DB s’affichent dans le flux de modification. Les données sont conservées dans le flux de modification jusqu’à ce qu’elles soient supprimées si vous lisez en utilisant le mode dernière version. 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

En plus de lire à partir du flux de modification d’un conteneur Azure Cosmos DB, vous pouvez exécuter des requêtes SQL sur les données qui sont 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 différent de lecture des données. Par conséquent, si vous lisez des données à partir du flux de modification, les données sont toujours cohérentes avec les requêtes du même conteneur Azure Cosmos DB.

Haute disponibilité

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 d’Azure Cosmos DB peuvent être facilement distribuées au niveau mondial et configurées avec un objectif de temps de récupération (RTO) de zéro.

Une fois que vous avez traité les éléments du flux de modification, vous pouvez créer une vue matérialisée et conserver les valeurs agrégées dans Azure Cosmos DB. Si vous utilisez Azure Cosmos DB pour créer un jeu, par exemple, vous pouvez utiliser le flux de modification pour implémenter des classements en temps réel basés sur des scores de jeux terminés.

Déplacement des données

Vous pouvez également lire le flux de modification pour le déplacement des données en temps réel.

Par exemple, le flux de modification vous aide à effectuer efficacement les tâches suivantes :

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

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

  • Implémenter une hiérarchisation et un archivage des données au niveau de l’application. Par exemple, vous pouvez stocker des « données à chaud » dans Azure Cosmos DB et vieillir les « données à froid » 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 peut garantir uniquement une cohérence éventuelle. 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 de provisionnement en événements implique l’utilisation d’un magasin avec ajout uniquement pour enregistrer la série complète d’actions sur ces données. 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 toutes les données ingérées sont modélisées en tant qu’écritures (aucune mise à jour ou suppression). Dans ce cas, chaque écriture dans Azure Cosmos DB est un « événement », de sorte que le flux de modification contient 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 consistent à maintenir des vues matérialisées ou à s’intégrer à des systèmes externes. Étant donné qu’il n’existe pas de limite de temps pour le mode de dernière version 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 de provisionnement 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 », vous assurant que vous ne manquerez pas de traiter des événements.

Limites actuelles

Le flux de modification a plusieurs modes qui ont chacun des limitations importantes que vous devez comprendre. Il existe plusieurs points à prendre en compte lorsque vous concevez une application qui utilise le flux de modification en mode dernière version ou en mode toutes les versions et les suppressions.

Mises à jour intermédiaires

Dans le mode de dernière version, seule la dernière modification d’un élément spécifique est incluse dans le flux de modification. Quand le traitement changera, vous lirez la dernière version de l’élément disponible. Si plusieurs mises à jour ont été apportées au même élément dans un laps de temps réduit, il est possible que certaines mises à jour intermédiaires ne soient pas traitées. Si vous souhaitez relire les mises à jour individuelles passées d’un élément, vous pouvez modéliser ces mises à jour sous la forme d’une série d’écritures ou utiliser le mode Toutes les versions et suppressions.

Suppressions

Le mode Dernière version du flux de modification ne capture pas les suppressions. Si vous supprimez un élément de votre conteneur, il est également retiré du flux de modification. La méthode la plus courante pour gérer les suppressions consiste à ajouter un marqueur souple sur les éléments qui sont supprimés. Vous pouvez ajouter une propriété appelée deleted et lui affecter la valeur true au moment de la suppression. Cette mise à jour de document apparaît dans le flux de modification. Vous pouvez définir une Durée de vie (TTL) sur cet élément afin qu’il puisse être automatiquement supprimé ultérieurement.

Rétention

Le flux de modification en mode Dernière version a une rétention illimitée. Tant qu’un élément existe dans votre conteneur, il est disponible dans le flux de modification.

Ordre garanti

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

Par exemple, prenons le cas d’une application de vente au détail qui utilise le modèle de conception d’approvisionnement en événements. Dans cette application, les différentes actions de l’utilisateur sont toutes 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 la validation du panier devait être traitée avant la suppression de l’article A, l’article A aurait probablement été expédié au client, et non l’article qu’il voulait à la place, l’article B. Afin de garantir le traitement de ces quatre événements dans l’ordre de leur occurrence, ils doivent être compris 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 apparaissent dans le flux de modification dans l’ordre dans lequel ils sont écrits dans Azure Cosmos DB.

Exemples

Voici quelques exemples de code de flux de modification réels pour le mode de dernière version qui vont au-delà de la portée des exemples fournis :

Étapes suivantes