Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Progettazione dello schema del sistema di gestione dei reclami in DynamoDB

Caso d'uso aziendale del sistema di gestione dei reclami

DynamoDB è un database ideale per un sistema di gestione dei reclami (o contact center) in quanto la maggior parte dei modelli di accesso ad essi associati sarebbero ricerche transazionali basate su valori chiave. I modelli di accesso tipici in questo scenario sarebbero i seguenti:

Alcuni commenti possono contenere allegati che descrivono il reclamo o la soluzione. Sebbene questi siano tutti modelli di accesso fondamentali, possono esserci requisiti aggiuntivi, come l'invio di notifiche quando viene aggiunto un nuovo commento a un reclamo o l'esecuzione di interrogazioni analitiche per determinare la distribuzione dei reclami in base alla gravità (o alle prestazioni degli agenti) a settimana. Un ulteriore requisito relativo alla gestione del ciclo di vita o alla conformità sarebbe quello di archiviare i dati dei reclami dopo tre anni dalla registrazione del reclamo.

Diagramma dell'architettura del sistema di gestione dei reclami

Il diagramma seguente mostra il diagramma dell'architettura del sistema di gestione dei reclami. Questo diagramma mostra le diverse Servizio AWS integrazioni utilizzate dal sistema di gestione dei reclami.

Oltre ai modelli di accesso transazionale chiave-valore che tratteremo più avanti nella sezione sulla modellazione dei dati di DynamoDB, abbiamo tre requisiti non transazionali. Il diagramma dell'architettura riportato sopra può essere suddiviso nei seguenti tre flussi di lavoro:

Diamo un'occhiata più approfondita a ciascuno di essi.

Invia una notifica quando un nuovo commento viene aggiunto a un reclamo

Possiamo utilizzare il flusso di lavoro seguente per soddisfare questo requisito:

DynamoDB Streams è un meccanismo di acquisizione dei dati di modifica per registrare tutte le attività di scrittura sulle tabelle DynamoDB. È possibile configurare le funzioni Lambda in modo che si attivino su alcune o tutte queste modifiche. Un filtro eventi può essere configurato sui trigger Lambda per filtrare gli eventi non pertinenti al caso d'uso. In questo caso, possiamo utilizzare un filtro per attivare Lambda solo quando viene aggiunto un nuovo commento e inviare una notifica agli ID e-mail pertinenti che possono essere recuperati da AWS  Secrets Manager o qualsiasi altro archivio di credenziali.

Esegui interrogazioni analitiche sui dati settimanali

DynamoDB è adatto per carichi di lavoro incentrati principalmente sull'elaborazione transazionale online (). OLTP Per gli altri modelli di accesso del 10-20% con requisiti analitici, i dati possono essere esportati in S3 con la funzionalità gestita Esporta su Amazon S3 senza alcun impatto sul traffico in tempo reale sulla tabella DynamoDB. Dai un'occhiata a questo flusso di lavoro qui sotto:

Amazon EventBridge può essere utilizzato per l'attivazione AWS Lambda nei tempi previsti: consente di configurare un'espressione cron per l'invocazione Lambda in modo che avvenga periodicamente. Lambda può richiamare la ExportToS3 API chiamata e archiviare i dati DynamoDB in S3. È quindi possibile accedere a questi dati S3 da un SQL motore come Amazon Athena per eseguire query analitiche sui dati DynamoDB senza influire sul carico di lavoro transazionale in tempo reale sulla tabella. Un esempio di query su Athena per trovare il numero di reclami per livello di gravità sarebbe il seguente:

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

Questa query Athena restituisce il seguente risultato:

Archivia dati più vecchi di tre anni

Puoi sfruttare la funzionalità DynamoDB Time to Live TTL () per eliminare i dati obsoleti dalla tabella DynamoDB senza costi aggiuntivi (tranne nel caso delle repliche di tabelle globali per la versione 2019.11.21 (attuale), in cui le eliminazioni replicate in altre regioni consumano capacità di scrittura). TTL Questi dati vengono visualizzati e possono essere utilizzati da DynamoDB Streams per essere archiviati in Amazon S3. Il flusso di lavoro per questo requisito è il seguente:

Diagramma delle relazioni tra entità del sistema di gestione dei reclami

Questo è il diagramma delle relazioni tra entità (ERD) che utilizzeremo per la progettazione dello schema del sistema di gestione dei reclami.

Modelli di accesso al sistema di gestione dei reclami

Questi sono i modelli di accesso che creeremo per la progettazione dello schema di gestione dei reclami.

Evoluzione della progettazione dello schema del sistema di gestione dei reclami

Poiché si tratta di un sistema di gestione dei reclami, la maggior parte dei modelli di accesso ruota attorno a un reclamo come entità principale. Essendo ComplaintID altamente importante garantirà una distribuzione uniforme dei dati nelle partizioni sottostanti ed è anche il criterio di ricerca più comune per i nostri modelli di accesso identificati. Pertanto, ComplaintID è un buon candidato per la chiave di partizione in questo set di dati.

Fase 1: gestire i modelli di accesso 1 (createComplaint), 2 (updateComplaint), 3 (updateSeveritybyComplaintID) e 4 (getComplaintByComplaintID)

Possiamo utilizzare una chiave di ordinamento generica denominata “metadati” (o “AA”) per archiviare informazioni specifiche sul reclamo, ad esempio CustomerID, State ,Severity eCreationDate. Utilizziamo operazioni singleton con PK=ComplaintID e SK=“metadata” per effettuare le seguenti operazioni:

Fase 2: Gestire il modello di accesso 5 (addCommentByComplaintID)

Questo modello di accesso richiede un modello di one-to-many relazione tra un reclamo e i commenti sul reclamo. Useremo qui la tecnica di partizionamento verticale per utilizzare una chiave di ordinamento e creare una raccolta di elementi con diversi tipi di dati. Se esaminiamo i modelli di accesso 6 (getAllCommentsByComplaintID) e 7 (getLatestCommentByComplaintID), sappiamo che i commenti dovranno essere ordinati per tempo. Possiamo anche ricevere più commenti contemporaneamente in modo da poter utilizzare la tecnica della chiave di ordinamento composita per aggiungere tempo e CommentID nell'attributo sort key.

Altre opzioni per gestire tali possibili collisioni di commenti sarebbero aumentare la granularità del timestamp o aggiungere un numero incrementale come suffisso invece di utilizzare Comment_ID. In questo caso, prefisseremo il valore della chiave di ordinamento per gli elementi corrispondenti ai commenti con “comm#” per abilitare le operazioni basate sull'intervallo.

Dobbiamo inoltre garantire che currentState nei metadati del reclamo rifletta lo stato in cui viene aggiunto un nuovo commento. L'aggiunta di un commento potrebbe indicare che il reclamo è stato assegnato a un agente o è stato risolto e così via. Al fine di raggruppare l'aggiunta di commenti e l'aggiornamento dello stato corrente nei metadati del reclamo, in un certo all-or-nothing senso, utilizzeremo il. TransactWriteItemsAPI Lo stato della tabella risultante ora è simile al seguente:

Aggiungiamo altri dati nella tabella e aggiungiamo anche ComplaintID come campo separato dal nostro PK per rendere il modello a prova di futuro nel caso in cui avessimo bisogno di indici aggiuntivi su ComplaintID. Tieni inoltre presente che alcuni commenti possono contenere allegati che archivieremo in Amazon Simple Storage Service e manterremo solo i loro riferimenti o URLs in DynamoDB. È consigliabile mantenere il database transazionale il più snello possibile per ottimizzare costi e prestazioni. L'aspetto dei dati è ora il seguente:

Fase 3: Gestire i modelli di accesso 6 (getAllCommentsByComplaintID) e 7 (getLatestCommentByComplaintID) 

Per ottenere tutti i commenti relativi a un reclamo, possiamo utilizzare l’operazione query con la condizione begins_with sulla chiave di ordinamento. Invece di consumare capacità di lettura aggiuntiva per leggere i metadati e quindi avere il sovraccarico di filtrare i risultati pertinenti, una condizione chiave di ordinamento come questa ci aiuta a leggere solo ciò di cui abbiamo bisogno. Ad esempio, un'operazione di interrogazione con PK=Complaint123 e SK begins_with comm# restituirebbe quanto segue saltando l'immissione dei metadati:

Poiché abbiamo bisogno dell'ultimo commento per un reclamo nel modello 7 (getLatestCommentByComplaintID), utilizziamo due parametri di interrogazione aggiuntivi:

Simile allo schema di accesso 6 (getAllCommentsByComplaintID), saltiamo l'immissione dei metadati utilizzando begins_with comm# come condizione chiave di ordinamento. Ora, puoi eseguire il modello di accesso 7 su questa progettazione usando l'operazione query con PK=Complaint123 e SK=begins_with comm#, ScanIndexForward=False e Limit 1. Verrà restituito come risultato l’elemento mirato seguente:

Aggiungiamo altri dati fittizi alla tabella.

Fase 4: Gestire i modelli di accesso 8 (getAComplaintbyCustomerIDAndComplaintID) e 9 (getAllComplaintsByCustomerID) 

I modelli di accesso 8 (getAComplaintbyCustomerIDAndComplaintID) e 9 (getAllComplaintsByCustomerID) introducono nuovi criteri di ricerca:. CustomerID Recuperarlo dalla tabella esistente richiede una costosa Scan per leggere tutti i dati e quindi filtrare gli elementi pertinenti per il CustomerID in questione. Possiamo rendere questa ricerca più efficiente creando un indice secondario globale (GSI) con CustomerID come chiave di partizione. Tenendo presente la one-to-many relazione tra cliente e reclami, nonché lo schema di accesso 9 (getAllComplaintsByCustomerID), ComplaintID sarebbe il candidato giusto per la chiave di ordinamento.

I dati contenuti in GSI sarebbero simili ai seguenti:

Un esempio di query su questo GSI per access pattern 8 (getAComplaintbyCustomerIDAndComplaintID) sarebbe:customer_id=custXYZ,. sort key=Complaint1321 Il risultato sarebbe:

Per ottenere tutti i reclami di un cliente per il pattern di accesso 9 (getAllComplaintsByCustomerID), la domanda su the GSI sarebbe: customer_id=custXYZ come condizione della chiave di partizione. Il risultato sarebbe:

Fase 5: Gestire il modello di accesso 10 (escalateComplaintByComplaintID)

Questo accesso introduce l'aspetto dell'escalation. Per inoltrare un reclamo, possiamo usare UpdateItem per aggiungere attributi come escalated_to e escalation_time all'elemento dei metadati del reclamo esistente. DynamoDB offre una progettazione flessibile dello schema, il che significa che un insieme di attributi non chiave può essere uniforme o discreto tra diversi elementi. Un esempio è fornito di seguito.

UpdateItem with PK=Complaint1444, SK=metadata

Fase 6: Gestire i modelli di accesso 11 (getAllEscalatedComplaints) e 12 (getEscalatedComplaintsByAgentID) 

Si prevede che solo alcuni reclami vengano estrapolati dall'intero set di dati. Pertanto, la creazione di un indice sugli attributi relativi all'escalation porterebbe a ricerche efficienti e a uno storage conveniente. GSI Possiamo farlo sfruttando la tecnica dell’indice sparso. La chiave di partizione GSI with as escalated_to e la chiave di ordinamento as avrebbero il seguente aspetto: escalation_time

Per ottenere tutti i reclami crescenti relativi al pattern di accesso 11 (), eseguiamo semplicemente la scansione di questo. getAllEscalatedComplaints GSI Tieni presente che questa scansione sarà efficiente ed economica grazie alle dimensioni di. GSI Per ricevere reclami più elevati per un agente specifico (shema di accesso 12 (getEscalatedComplaintsByAgentID)), la chiave di partizione sarebbe escalated_to=agentID e abbiamo impostato ScanIndexForward su False per ordinare dal più recente al meno recente.

Fase 7: Gestire il modello di accesso 13 (getCommentsByAgentID)

Per l'ultimo schema di accesso, dobbiamo eseguire una ricerca in base a una nuova dimensione: AgentID. Abbiamo anche bisogno di un ordinamento basato sul tempo per leggere i commenti tra due date, quindi creiamo un GSI with agent_id come chiave di partizione e come chiave di ordinamento. comm_date I dati in esso contenuti GSI saranno simili ai seguenti:

Un esempio di interrogazione su questo GSI argomento potrebbe essere partition key agentID=AgentA andsort key=comm_date between (2023-04-30T12:30:00, 2023-05-01T09:00:00), il cui risultato è:

Tutti i modelli di accesso e il modo in cui la progettazione dello schema li affronta sono riassunti nella tabella seguente:

Schema finale del sistema di gestione dei reclami

Di seguito sono riportate le progettazioni dello schema finale. Per scaricare questo schema come JSON file, consulta Esempi di DynamoDB su. GitHub

Tabella di base

Reclamo_del cliente_ GSI

Inasprimenti_ GSI

Agenti_Commenti_ GSI

Utilizzo di No SQL Workbench con questo schema di progettazione

Puoi importare questo schema finale in No SQL Workbench, uno strumento visivo che fornisce funzionalità di modellazione, visualizzazione dei dati e sviluppo di query per DynamoDB, per esplorare e modificare ulteriormente il tuo nuovo progetto. Per iniziare, segui queste fasi: