Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Conception du schéma d'un système de gestion des réclamations dans DynamoDB

Cas d'utilisation métier d'un système de gestion des réclamations

DynamoDB est une base de données parfaitement adaptée à un cas d'utilisation de système de gestion des réclamations (ou centre de contact), car la plupart des modèles d'accès qui y sont associés sont des recherches transactionnelles basées sur des paires clé-valeur. Dans ce scénario, les modèles d'accès types consisteraient à :

Certains commentaires peuvent s'accompagner de pièces jointes décrivant la réclamation ou la solution. Bien que ces modèles d'accès soient tous de type clé-valeur, d'autres exigences peuvent s'ajouter, comme l'envoi de notifications lorsqu'un nouveau commentaire est ajouté à une réclamation ou l'exécution de requêtes analytiques pour déterminer la répartition hebdomadaire des réclamations par gravité (ou les performances des agents). La nécessité d'archiver les données relatives aux réclamations trois ans après l'enregistrement de la réclamation pourrait constituer une autre exigence liée à la gestion du cycle de vie ou à la conformité.

Diagramme de l'architecture du système de gestion des réclamations

Le schéma suivant montre le schéma d'architecture du système de gestion des plaintes. Ce schéma montre les différentes Service AWS intégrations utilisées par le système de gestion des plaintes.

Outre les modèles d'accès transactionnel de type clé-valeur que nous traiterons ultérieurement dans la section sur la modélisation de données DynamoDB, nous sommes en présence de trois exigences non transactionnelles. Le diagramme d'architecture ci-dessus peut être décomposé en trois flux de travail distincts, à savoir :

Examinons de plus près chacun d'eux.

Envoyer une notification lorsqu'un nouveau commentaire est ajouté à une réclamation

Nous pouvons utiliser le flux de travail ci-dessous pour répondre à cette exigence :

Flux DynamoDB est un mécanisme de capture des modifications de données qui enregistre toutes les activités d'écriture de vos tables DynamoDB. Vous pouvez configurer des fonctions Lambda pour qu'elles se déclenchent pour tout ou partie de ces modifications. Un filtre d'événements peut être configuré au niveau des déclencheurs Lambda afin de filtrer les événements qui n'ont aucun rapport direct avec le cas d'utilisation. Dans ce cas, nous pouvons utiliser un filtre pour déclencher Lambda uniquement lorsqu'un nouveau commentaire est ajouté et envoyer une notification aux adresses e-mail voulues, qui peuvent être récupérées depuis AWS  Secrets Manager ou tout autre magasin d'informations d'identification.

Exécuter des requêtes analytiques sur les données hebdomadaires

DynamoDB convient aux charges de travail principalement axées sur le traitement transactionnel en ligne (). OLTP Pour les 10 à 20 % de modèles d'accès restants soumis à des exigences analytiques, les données peuvent être exportées vers S3 à l'aide de la fonctionnalité gérée Exporter vers Amazon S3 sans que cela n'impacte le trafic en direct de la table DynamoDB. Examinez le flux de travail ci-dessous :

Amazon EventBridge peut être utilisé pour déclencher dans AWS Lambda les délais prévus : il vous permet de configurer une expression cron pour que l'appel Lambda ait lieu périodiquement. Lambda peut appeler l'ExportToS3APIappel et stocker les données DynamoDB dans S3. Ces données S3 sont ensuite accessibles par un SQL moteur tel qu'Amazon Athena pour exécuter des requêtes analytiques sur les données DynamoDB sans affecter la charge de travail transactionnelle réelle sur la table. Voici un exemple de requête Athena qui vise à déterminer le nombre de réclamations par niveau de gravité :

SELECT Item.severity.S as "Severity", COUNT(Item) as "Count" 
FROM "complaint_management"."data" 
WHERE NOT Item.severity.S = '' 
GROUP BY Item.severity.S ;

Cette requête Athena renvoie le résultat suivant :

Archiver les données de plus de trois ans

Vous pouvez tirer parti de la fonctionnalité DynamoDB Time to Live TTL () pour supprimer les données obsolètes de votre table DynamoDB sans frais supplémentaires (sauf dans le cas des répliques de tables globales pour la version 2019.11.21 (actuelle), où les suppressions répliquées vers d'autres régions consomment de la capacité d'écriture). TTL Ces données apparaissent et peuvent être utilisées par des flux DynamoDB pour être archivées dans Amazon S3. Voici comment se présente le flux de travail pour cette exigence :

Diagramme des relations entre entités du système de gestion des réclamations

Il s'agit du diagramme des relations entre les entités (ERD) que nous utiliserons pour la conception du schéma du système de gestion des plaintes.

Modèles d'accès du système de gestion des réclamations

Voici les modèles d'accès que nous allons prendre en considération pour la conception du schéma de gestion des réclamations.

Évolution de la conception du schéma du système de gestion des réclamations

S'agissant d'un système de gestion des réclamations, la plupart des modèles d'accès sont centrés sur la réclamation en tant qu'entité principale. Du fait de sa cardinalité élevée, ComplaintID assurera une répartition uniforme des données dans les partitions sous-jacentes, et ce sera également le critère de recherche le plus courant pour nos modèles d'accès identifiés. Par conséquent, il est judicieux d'utiliser ComplaintID comme de clé de partition dans cet ensemble de données.

Étape 1 : Traitement des modèles d’accès 1 (createComplaint), 2 (updateComplaint), 3 (updateSeveritybyComplaintID) et 4 (getComplaintByComplaintID) 

Nous pouvons utiliser une valeur de clé de tri générique appelée « metadata » (ou « AA ») pour stocker les informations propres aux réclamations, telles que CustomerID, State, Severity et CreationDate. Nous utilisons des opérations singleton avec PK=ComplaintID et SK=“metadata” pour effectuer les opérations suivantes :

Étape 2 : Traitement du modèle d'accès 5 (addCommentByComplaintID)

Ce modèle d'accès nécessite un modèle de one-to-many relation entre une plainte et les commentaires sur la plainte. Nous allons employer ici la technique du partitionnement vertical pour utiliser une clé de tri et créer une collection d'éléments avec différents types de données. Dans le cas des modèles d'accès 6 (getAllCommentsByComplaintID) et 7 (getLatestCommentByComplaintID), nous savons que les commentaires devront être triés par ordre chronologique. Nous savons également que plusieurs commentaires pourront être reçus simultanément, ce qui signifie que nous pouvons utiliser la technique de clé de tri composite pour ajouter l'heure et CommentID dans l'attribut de clé de tri.

Pour faire face à ce risque de collision de commentaires, il pourrait être envisagé d'accroître la granularité de l'horodatage ou d'ajouter un nombre incrémentiel en guise de suffixe à la place de Comment_ID. Dans ce cas, nous allons faire précéder la valeur de clé de tri du préfixe « comm# » pour les éléments correspondant aux commentaires afin de permettre les opérations basées sur une plage.

Nous devons également vérifier que currentState dans les métadonnées de la réclamation reflète l'état d'ajout d'un nouveau commentaire. L'ajout d'un commentaire peut indiquer que la réclamation a été affectée à un agent, qu'elle n'a pas été résolue, etc. Afin de regrouper l'ajout de commentaires et la mise à jour de l'état actuel des métadonnées de la plainte, nous utiliserons d'une all-or-nothing manière ou d'une autre le TransactWriteItemsAPI. L'état de la table qui en résulte ressemble désormais à ceci :

Ajoutons quelques données supplémentaires dans la table et ajoutons également ComplaintID sous la forme d'un champ distinct de notre PK pour pérenniser le modèle au cas où nous aurions besoin d'index supplémentaires sur ComplaintID. Notez également que certains commentaires peuvent contenir des pièces jointes que nous stockerons dans Amazon Simple Storage Service et que nous conserverons uniquement leurs références ou URLs dans DynamoDB. Dans un souci d'optimisation des coûts et des performances, il est recommandé de garder la base de données transactionnelle aussi légère que possible. Les données ressemblent désormais à ceci :

Étape 3 : Traitement des modèles d'accès 6 (getAllCommentsByComplaintID) et 7 (getLatestCommentByComplaintID)

Pour obtenir tous les commentaires relatifs à une réclamation, nous pouvons utiliser l'opération de requête (query) avec la condition begins_with au niveau de la clé de tri. Plutôt que de consommer de la capacité de lecture supplémentaire pour lire l'entrée de métadonnées et d'avoir à filtrer les résultats pertinents, cette condition de clé de tri nous permet de lire uniquement ce dont nous avons besoin. Par exemple, une opération de requête avec PK=Complaint123 et SK begins_with comm# renverrait ce qui suit en omettant l'entrée des métadonnées :

Puisque nous avons besoin du commentaire le plus récent concernant une réclamation du modèle 7 (getLatestCommentByComplaintID), utilisons deux paramètres de requête supplémentaires :

Comme pour le modèle d'accès 6 (getAllCommentsByComplaintID), nous ignorons l'entrée de métadonnées en utilisant begins_with comm# comme condition de clé de tri. Vous pouvez désormais exécuter le modèle d'accès 7 sur ce modèle à l'aide de l'opération de requête avec PK=Complaint123 et SK=begins_with comm#ScanIndexForward=False, et Limit 1. L'élément ciblé suivant est renvoyé en résultat :

Ajoutons d'autres données fictives au tableau.

Étape 4 : Traitement des modèles d'accès 8 (getAComplaintbyCustomerIDAndComplaintID) et 9 (getAllComplaintsByCustomerID)

Les modèles d'accès 8 (getAComplaintbyCustomerIDAndComplaintID) et 9 (getAllComplaintsByCustomerID) introduisent de nouveaux critères de recherche :CustomerID. Pour le récupérer à partir de la table existante, il faut passer par une opération Scan coûteuse afin de lire toutes les données et filtrer ensuite les éléments pertinents pour le CustomerID en question. Nous pouvons rendre cette recherche plus efficace en créant un index secondaire global (GSI) avec CustomerID comme clé de partition. En tenant compte de la one-to-many relation entre le client et les plaintes ainsi que du modèle d'accès 9 (getAllComplaintsByCustomerID), ComplaintID ce serait le bon candidat pour la clé de tri.

Les données contenues dans le GSI ressembleraient à ceci :

Un exemple de requête à ce sujet GSI pour le modèle d'accès 8 (getAComplaintbyCustomerIDAndComplaintID) serait :customer_id=custXYZ,sort key=Complaint1321. Le résultat serait le suivant :

Pour obtenir toutes les plaintes d'un client concernant le modèle d'accès 9 (getAllComplaintsByCustomerID), la requête sur le GSI serait : customer_id=custXYZ en tant que condition de clé de partition. Le résultat serait le suivant :

Étape 5 : Traitement du modèle d'accès 10 (escalateComplaintByComplaintID)

Cet accès introduit la notion d'escalade. Pour transmettre une plainte à un échelon supérieur, nous pouvons utiliser UpdateItem pour ajouter des attributs tels que escalated_to et escalation_time à l'élément de métadonnées de réclamation existant. DynamoDB offre une conception de schéma flexible, ce qui signifie qu'un ensemble d'attributs qui ne correspondent pas à une clé peut être uniforme ou discret entre différents éléments. Voici un exemple :

UpdateItem with PK=Complaint1444, SK=metadata

Étape 6 : Traitement des modèles d'accès 11 (getAllEscalatedComplaints) et 12 (getEscalatedComplaintsByAgentID)

Sur l'ensemble complet de données, seules quelques réclamations devraient faire l'objet d'une escalade. Par conséquent, la création d'un index sur les attributs liés à l'escalade conduirait à des recherches efficaces ainsi qu'à un stockage rentable. GSI Pour cela, nous pouvons tirer parti de la technique de l'index fragmenté. La clé de partition GSI avec clé de partition escalated_to et la clé de tri comme escalation_time ressembleraient à ceci :

Pour recevoir toutes les plaintes transmises concernant le modèle d'accès 11 (getAllEscalatedComplaints), il suffit de le scanner. GSI Notez que cette analyse sera performante et rentable en raison de la taille duGSI. Pour obtenir les réclamations ayant fait l'objet d'une escalade pour un agent déterminé (modèle d'accès 12 (getEscalatedComplaintsByAgentID)), la clé de partition serait escalated_to=agentID et nous définirions ScanIndexForward sur False pour un ordre de tri du plus récent au plus ancien.

Étape 7 : Traitement du modèle d'accès 13 (getCommentsByAgentID)

Pour le dernier modèle d'accès, nous devons effectuer une recherche selon une nouvelle dimension : AgentID. Nous avons également besoin d'un ordre temporel pour lire les commentaires entre deux dates. Nous créons donc un GSI with agent_id comme clé de partition et comm_date comme clé de tri. Les données qu'il contient GSI ressembleront à ce qui suit :

Un exemple de requête à ce sujet GSI serait partition key agentID=AgentA etsort key=comm_date between (2023-04-30T12:30:00, 2023-05-01T09:00:00), dont le résultat est :

Tous les modèles d'accès et la façon dont ils sont traités par la conception du schéma sont résumés dans le tableau ci-dessous :

Schéma final du système de gestion des réclamations

Voici les conceptions du schéma final. Pour télécharger cette conception de schéma sous forme de JSON fichier, consultez les exemples DynamoDB sur. GitHub

Table de base

Plainte du client_ GSI

Escalades_ GSI

Agents_Commentaires_ GSI

Utilisation de No SQL Workbench avec cette conception de schéma

Vous pouvez importer ce schéma final dans No SQL Workbench, un outil visuel qui fournit des fonctionnalités de modélisation, de visualisation des données et de développement de requêtes pour DynamoDB, afin d'explorer et de modifier votre nouveau projet de manière plus approfondie. Pour commencer, procédez comme suit :