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:

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:

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 ExportToS3API-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.

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:

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:

Ä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=custXYZals 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:

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 auf. GitHub

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: