Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Schemadesign des Systems zur Beschwerdeverwaltung in DynamoDB
Anwendungsfall eines Systems zur Beschwerdeverwaltung für Unternehmen
DynamoDB ist eine Datenbank, die sich gut für den Anwendungsfall eines Systems zur Beschwerdeverwaltung (oder eines Kontaktzentrums) eignet, da es sich bei den meisten damit verbundenen Zugriffsmustern um Transaktionsabfragen handelt, die auf Schlüsselwerten basieren. Die typischen Zugriffsmuster in diesem Szenario wären:
-
Beschwerden erstellen und aktualisieren
-
Eine Beschwerde weiterleiten
-
Kommentare zu einer Beschwerde erstellen und lesen
-
Alle Beschwerden eines Kunden abrufen
-
Alle Kommentare eines Kundendienstmitarbeiters und alle Eskalationen abrufen
Einige Kommentare können Anlagen enthalten, in denen die Beschwerde oder Lösung beschrieben wird. Dies sind zwar alles wichtige Zugriffsmuster, es können jedoch zusätzliche Anforderungen gelten, z. B. das Versenden von Benachrichtigungen, wenn ein neuer Kommentar zu einer Beschwerde hinzugefügt wird, oder die Durchführung analytischer Abfragen, um die Verteilung der Beschwerden nach Schweregrad (oder Leistung des Kundendienstmitarbeiters) pro Woche zu ermitteln. Eine weitere Anforderung im Zusammenhang mit dem Lebenszyklusmanagement oder der Einhaltung von Vorschriften wäre die Archivierung der Beschwerdedaten nach dreijähriger Protokollierung der Beschwerde.
Architekturdiagramm des Systems zur Beschwerdeverwaltung
Das folgende Diagramm zeigt das Architekturdiagramm des Beschwerdemanagementsystems. Dieses Diagramm zeigt die verschiedenen AWS-Service Integrationen, die das Beschwerdemanagementsystem verwendet.

Abgesehen von den transaktionalen Zugriffsmustern mit Schlüsselwerten, die wir später im Abschnitt zur DynamoDB-Datenmodellierung behandeln, gibt es drei Anforderungen, die nicht transaktional sind. Das obige Architekturdiagramm kann in die folgenden drei Workflows unterteilt werden:
-
Eine Benachrichtigung senden, wenn ein neuer Kommentar zu einer Beschwerde hinzugefügt wird
-
Analytische Abfragen für wöchentliche Daten durchführen
-
Daten archivieren, die älter als drei Jahre sind
Schauen wir sie uns jeweils genauer an.
Eine Benachrichtigung senden, wenn ein neuer Kommentar zu einer Beschwerde hinzugefügt wird
Wir können diese Anforderung mit folgendem Workflow erfüllen:

DynamoDB-Streams ist ein Mechanismus zur Erfassung von Änderungsdaten, mit dem alle Schreibaktivitäten in Ihren DynamoDB-Tabellen aufgezeichnet werden. Sie können Lambda-Funktionen so konfigurieren, dass sie bei einigen oder allen dieser Änderungen ausgelöst werden. Ein Ereignisfilter kann auf Lambda-Triggern konfiguriert werden, um Ereignisse herauszufiltern, die für den Anwendungsfall nicht relevant sind. In diesem Fall können wir einen Filter verwenden, um Lambda nur dann auszulösen, wenn ein neuer Kommentar ausgelöst wird, und um eine Benachrichtigung an die entsprechenden E-Mail-IDs zu senden, die von AWS -Manager für Secrets oder einem anderen Speicher für Anmeldeinformationen abgerufen werden können.
Analytische Abfragen für wöchentliche Daten durchführen
DynamoDB eignet sich für Workloads, die sich hauptsächlich auf die Online-Transaktionsverarbeitung (OLTP) konzentrieren. Für die anderen 10- bis 20-prozentigen Zugriffsmuster mit analytischen Anforderungen können die Daten mit dem verwalteten Feature Nach Amazon S3 exportieren ohne Auswirkung auf den Live-Datenverkehr auf der DynamoDB-Tabelle nach S3 exportiert werden. Schauen Sie sich diesen Workflow unten an:

Amazon EventBridge kann verwendet werden, um nach Zeitplan auszulösen AWS Lambda — es ermöglicht Ihnen, einen Cron-Ausdruck zu konfigurieren, damit der Lambda-Aufruf regelmäßig erfolgt. Lambda kann den ExportToS3
API-Aufruf aufrufen DynamoDB-Daten in S3 speichern. Auf diese S3-Daten kann dann eine SQL-Engine wie Amazon Athena zugreifen, um analytische Abfragen für DynamoDB-Daten auszuführen, ohne den Workload der Live-Transaktion der Tabelle zu beeinträchtigen. Eine Athena-Beispielabfrage zur Ermittlung der Anzahl der Beschwerden pro Schweregrad würde wie folgt aussehen:
SELECT Item.severity.S as "Severity", COUNT(Item) as "Count" FROM "complaint_management"."data" WHERE NOT Item.severity.S = '' GROUP BY Item.severity.S ;
Diese führt zu folgendem Athena-Abrageergebnis:

Daten archivieren, die älter als drei Jahre sind
Sie können mit dem DynamoDB-Feature Time to Live (TTL) veraltete Daten ohne Zusatzkosten (außer im Fall von globalen Tabellenreplikaten für die Version 2019.11.21 (aktuell), bei der TTL-Löschungen, die in andere Regionen repliziert wurden, Schreibkapazität verbrauchen) aus Ihrer DynamoDB-Tabelle löschen. Diese Daten werden in DynamoDB Streams angezeigt und können für eine Archivierung in Amazon S3 genutzt werden. Der Arbeitsablauf für diese Anforderung sieht wie folgt aus:

Beziehungsdiagramm der Entitäten des Systems zur Beschwerdeverwaltung
Dies ist das Diagramm der Entitätsbeziehungen (Entity Relationship Diagram, ERD), das wir für das Schemadesign für ein System zur Beschwerdeverwaltung verwenden werden.

Zugriffsmuster für das System zur Beschwerdeverwaltung
Dies sind die Zugriffsmuster, die wir für das Schemadesign für die Beschwerdeverwaltung berücksichtigen werden.
-
createComplaint
-
updateComplaint
-
updateSeveritybyComplaintID
-
getComplaintByID der Beschwerde
-
addCommentByBeschwerde-ID
-
getAllCommentsByComplaintAusweis
-
getLatestCommentByComplaintAUSWEIS
-
AComplaintbyIDAndKundenbeschwerde-ID abrufen
-
getAllComplaintsByCustomerAusweis
-
escalateComplaintByID der Beschwerde
-
getAllEscalatedBeschwerden
-
getEscalatedComplaintsByAgentID (Reihenfolge vom neuesten zum ältesten)
-
getCommentsByAgentID (zwischen zwei Daten)
Schemadesignentwicklung des Systems zur Beschwerdeverwaltung
Da es sich um ein System zur Beschwerdeverwaltung handelt, drehen sich die meisten Zugriffsmuster um eine Beschwerde als primäre Entität. Da die ComplaintID
eine hohe Priorität aufweist, ist eine gleichmäßige Verteilung der Daten auf den zugrunde liegenden Partitionen gewährleistet. Sie ist auch das häufigste Suchkriterium für unsere identifizierten Zugriffsmuster. Deshalb ist ComplaintID
ein guter Kandidat für den Partitionsschlüssel in diesem Datensatz.
Schritt 1: Zugriffsmuster 1 (createComplaint
), 2 (updateComplaint
), 3 (updateSeveritybyComplaintID
) und 4 (getComplaintByComplaintID
) angehen
Wir können einen generischen Sortierschlüssel mit dem Wert „Metadaten“ (oder „AA“) verwenden, um beschwerdespezifische Informationen zu speichern, z. B.CustomerID
, State
, Severity
und CreationDate
. Wir verwenden Singleton-Operationen mit PK=ComplaintID
und SK=“metadata”
, um Folgendes zu tun:
-
PutItem
, um eine neue Beschwerde zu erstellen -
UpdateItem
, um den Schweregrad oder andere Felder in den Metadaten der Beschwerde zu aktualisieren -
GetItem
, um Metadaten für die Beschwerde abzurufen

Schritt 2: Zugriffsmuster 5 (addCommentByComplaintID
) angehen
Dieses Zugriffsmuster erfordert ein one-to-many Beziehungsmodell zwischen einer Beschwerde und Kommentaren zu der Beschwerde. Wir werden hier die vertikale Partitionierungstechnik nutzen, um einen Sortierschlüssel zu verwenden und eine Elementsammlung mit verschiedenen Datentypen zu erstellen. Wenn wir uns die Zugriffsmuster 6 (getAllCommentsByComplaintID
) und 7 (getLatestCommentByComplaintID
) ansehen, wissen wir, dass Kommentare nach Zeit sortiert werden müssen. Es können auch mehrere Kommentare gleichzeitig eingehen, sodass wir die Technik zusammengesetzter Sortierschlüssel zum Anfügenvon Zeit und CommentID
im Sortierschlüsselattribut verwenden können.
Andere Optionen für den Umgang mit solchen möglichen Kommentarkollisionen sind die Erhöhung der Granularität für den Zeitstempel oder das Hinzufügen einer inkrementellen Zahl als Suffix, anstatt der Comment_ID
. In diesem Fall stellen wir dem Sortierschlüsselwert für Elemente, die Kommentaren entsprechen, „comm#“ voran, um bereichsbasierte Operationen zu ermöglichen.
Wir müssen auch sicherstellen, dass currentState
in den Beschwerdemetadaten den Status angeben, wenn ein neuer Kommentar hinzugefügt wird. Das Hinzufügen eines Kommentars kann darauf hinweisen, dass die Beschwerde einem Kundendienstmitarbeiter zugewiesen wurde oder dass sie gelöst wurde usw. Um das Hinzufügen von Kommentaren und die Aktualisierung des aktuellen Status in den Metadaten der Beschwerde in gewisser all-or-nothing Weise zu bündeln, werden wir die TransactWriteItemsAPI verwenden. Der sich daraus ergebende Tabellenstatus sieht nun wie folgt aus:

Fügen wir der Tabelle weitere Daten und auch ComplaintID
als separates Feld aus unseremPK
hinzu, um das Modell zukunftssicher zu machen, falls wir zusätzliche Indizes für ComplaintID
benötigen. Beachten Sie auch, dass einige Kommentare möglicherweise Anlagen enthalten, die wir in Amazon Simple Storage Service speichern und nur deren Referenzen oder URLs in DynamoDB speichern. Es ist eine bewährte Methode, die Transaktionsdatenbank so schlank wie möglich zu halten, um Kosten und Leistung zu optimieren. Die Daten sehen jetzt wie folgt aus:

Schritt 3: Zugriffsmuster 6 (getAllCommentsByComplaintID
) und 7 (getLatestCommentByComplaintID
) angehen
Wenn Sie alle Kommentare zu einer Beschwerde abrufen möchten, können wir die query-Operation mit der begins_with
-Bedingung für den Sortierschlüssel verweden. Anstatt zusätzliche Lesekapazität zum Lesen des Metadateneintrags zu verbrauchen und dann den Aufwand für das Filtern der relevanten Ergebnisse aufzuwenden, hilft uns eine solche Sortierschlüsselbedingung dabei, nur die erforderlichen Elemente zu lesen. Ein Abfragevorgang mit PK=Complaint123
und SK
begins_with comm#
würde beispielsweise Folgendes zurückgeben, ohne den Metadateneintrag zu überspringen:

Da wir den letzten Kommentar für eine Beschwerde in Muster 7 benötigen (getLatestCommentByComplaintID
), verwenden wir zwei zusätzliche Abfrageparameter:
-
ScanIndexForward
sollte auf False festgelegt werden, um die Ergebnisse in absteigender Reihenfolge zu sortieren -
Limit
sollte auf 1 festgelegt werden, um den neuesten (nur einen) Kommentar abzurufen
Ähnlich wie bei Zugriffsmuster 6 (getAllCommentsByComplaintID
), überspringen wir die Metadateneingabe mit begins_with
comm#
als Sortierschlüsselbedingung. Jetzt können Sie das Zugriffsmuster 7 für dieses Design ausführen, indem Sie die Abfrageoperation mit PK=Complaint123
und SK=begins_with comm#
, ScanIndexForward=False
und Limit
verwenden 1. Das folgende anvisierte Element wird als Ergebnis zurückgegeben:

Fügen wir der Tabelle weitere Dummy-Daten hinzu.

Schritt 4: Zugriffsmuster 8 (getAComplaintbyCustomerIDAndComplaintID
) und 9 (getAllComplaintsByCustomerID
) angehen
Die Zugriffsmuster 8 (getAComplaintbyCustomerIDAndComplaintID
) und 9 (getAllComplaintsByCustomerID
) führen neue Suchkriterien ein:CustomerID
. Das Abrufen aus der vorhandenen Tabelle erfordert eine teure Scan
, um alle Daten zu lesen und dann relevante Elemente für die fragliche CustomerID
zu filtern. Wir können diese Suche effizienter gestalten, indem wir einen globalen sekundärer Index (GSI) mit dem Partitionsschlüssel CustomerID
erstellen. Unter Berücksichtigung der one-to-many Beziehung zwischen Kunde und Beschwerden sowie des Zugriffsmusters 9 (getAllComplaintsByCustomerID
) ComplaintID
wäre der richtige Kandidat für den Sortierschlüssel.
Die Daten im GSI würden so aussehen:

Eine Beispielabfrage auf diesem GSI für Zugriffsmuster 8 (getAComplaintbyCustomerIDAndComplaintID
) wäre: customer_id=custXYZ
, sort key=Complaint1321
. Das Ergebnis wäre:

Bei einem Abruf aller Beschwerden eines Kunden für das Zugriffsmuster 9 (getAllComplaintsByCustomerID
) würde die Anfrage an den GSI customer_id=custXYZ
als Bedingung für den Partitionsschlüssel lauten. Das Ergebnis wäre:

Schritt 5: Zugriffsmuster 10 (escalateComplaintByComplaintID
) angehen
Dieser Zugriff führt den Eskalationsaspekt ein. Für die Eskalation einer Beschwerde können wir UpdateItem
verwenden, um Attribute zum vorhandenen Metadatenelement für Beschwerden hinzuzufügen, z. B. escalated_to
und escalation_time
. DynamoDB bietet ein flexibles Schemadesign, was bedeutet, dass eine Reihe von Nicht-Schlüsselattributen für verschiedene Elemente einheitlich oder diskret sein kann. Ein Beispiel finden Sie unten:
UpdateItem with PK=Complaint1444, SK=metadata

Schritt 6: Zugriffsmuster 11 (getAllEscalatedComplaints
) und 12 (getEscalatedComplaintsByAgentID
) angehen
Es wird erwartet, dass nur eine Handvoll Beschwerden aus dem gesamten Datensatz eskaliert werden. Daher würde die Erstellung eines Index für die eskalationsbezogenen Attribute zu effizienten Suchvorgängen sowie zu einem kostengünstigem GSI-Speicher führen. Wir erreichen dies, indem wir die Technik spärlicher Index nutzen. Der GSI mit dem Partitionsschlüssel escalated_to
und dem Sortierschlüssel escalation_time
würde so aussehen:

Um alle eskalierten Beschwerden für das Zugriffsmuster 11 (getAllEscalatedComplaints
) abzurufen, scannen wir einfach diesen GSI. Beachten Sie, dass dieser Scan aufgrund der Größe des GSI performant und kosteneffizient ist. Für den Abruf von weitergeleiteten Beschwerden für einen bestimmten Kundendienstmitarbeiter (Zugriffsmuster 12) (getEscalatedComplaintsByAgentID
)) ist der Partitionsschlüssel escalated_to=agentID
und für eine Reihenfolge vom neuesten zum ältesten Element legen wir ScanIndexForward
auf False
fest.
Schritt 7: Zugriffsmuster 13 (getCommentsByAgentID
) angehen
Für das letzte Zugriffsmuster müssen wir eine Suche nach einer neuen Dimension durchführen: AgentID
. Wir benötigen auch eine zeitabhängige Reihenfolge, um Kommentare zwischen zwei Datumsangaben zu lesen. Also erstellen wir einen GSI mit dem Partitionsschlüssel agent_id
und dem Sortierschlüssel comm_date
. Die Daten in diesem GSI sehen wie folgt aus:

Eine Beispielabfrage zu diesem GSI ist partition key agentID=AgentA
und sort key=comm_date between (2023-04-30T12:30:00, 2023-05-01T09:00:00)
, dessen Ergebnis wie folgt lautet:

Alle Zugriffsmuster und wie das Schemadesign sie behandelt, sind in der folgenden Tabelle zusammengefasst:
Zugriffsmuster | Basis-table/GSI/LSI | Operation | Partitionsschlüsselwert | Sortierschlüsselwert | Sonstige Bedingungen/Filter |
---|---|---|---|---|---|
createComplaint | Basistabelle | PutItem | PK=complaint_id | SK=metadata | |
updateComplaint | Basistabelle | UpdateItem | PK=complaint_id | SK=metadata | |
updateSeveritybyComplaintID | Basistabelle | UpdateItem | PK=complaint_id | SK=metadata | |
getComplaintByID der Beschwerde | Basistabelle | GetItem | PK=complaint_id | SK=metadata | |
addCommentByBeschwerde-ID | Basistabelle | TransactWriteItems | PK=complaint_id | SK=metadata, SK=comm#comm_date#comm_id | |
getAllCommentsByComplaintAusweis | Basistabelle | Query | PK=complaint_id | SK begins_with "child#" | |
getLatestCommentByComplaintAUSWEIS | Basistabelle | Query | PK=complaint_id | SK begins_with "child#" | scan_index_forward=False, Limit 1 |
AComplaintbyIDAndKundenbeschwerde-ID abrufen | Customer_complaint_GSI | Abfrage | customer_id=customer_id | complaint_id = complaint_id | |
getAllComplaintsByCustomerAusweis | Customer_complaint_GSI | Abfrage | customer_id=customer_id | N/A | |
escalateComplaintByID der Beschwerde | Basistabelle | UpdateItem | PK=complaint_id | SK=metadata | |
getAllEscalatedBeschwerden | Escalations_GSI | Scan | N/A | N/A | |
getEscalatedComplaintsByAgentID (Reihenfolge vom neuesten zum ältesten) | Escalations_GSI | Abfrage | escalated_to=agent_id | N/A | scan_index_forward=False |
getCommentsByAgentID (zwischen zwei Daten) | Agents_Comments_GSI | Abfrage | agent_id=agent_id | SK zwischen (date1, date2) |
Endgültiges Schema des Systems zur Beschwerdeverwaltung
Dies sind die endgültigen Schemadesigns. Informationen zum Herunterladen dieses Schemadesign als JSON-Datei finden Sie unter DynamoDB-Beispiele
Basistabelle

Customer_Complaint_GSI

Escalations_GSI

Agents_Comments_GSI

Verwendung von NoSQL Workbench mit diesem Schemadesign
Sie können dieses endgültige Schema in NoSQL Workbench importieren, um Ihr neues Projekt weiter zu untersuchen und zu bearbeiten. NoSQL Workbench ist ein visuelles Tool, das Features zur Datenmodellierung, Datenvisualisierung und Abfrageentwicklung für DynamoDB bereitstellt. Gehen Sie folgendermaßen vor, um zu beginnen:
-
Laden Sie NoSQL Workbench herunter. Weitere Informationen finden Sie unter Herunterladen von NoSQL Workbench for DynamoDB.
-
Laden Sie die oben aufgeführte JSON-Schemadatei herunter, die bereits das NoSQL-Workbench-Modellformat aufweist.
-
Importieren Sie die JSON-Schemadatei in NoSQL Workbench. Weitere Informationen finden Sie unter Importieren eines vorhandenen Datenmodells.
-
Nach dem Import in NOSQL Workbench können Sie das Datenmodell bearbeiten. Weitere Informationen finden Sie unter Bearbeiten eines vorhandenen Datenmodells.
-
Verwenden Sie das Feature Data Visualizer von NoSQL Workbench, um Ihr Datenmodell zu visualisieren, Beispieldaten hinzuzufügen oder Beispieldaten aus einer CSV-Datei zu importieren.