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.
Geschäftsszenario für wiederkehrende Zahlungen
In diesem Anwendungsfall geht es um die Verwendung von DynamoDB zur Implementierung eines Systems für wiederkehrende Zahlungen. Das Datenmodell hat die folgenden Entitäten: Konten, Abonnements und Belege. Zu den Besonderheiten unseres Anwendungsfalls gehört Folgendes:
-
Jedes Konto kann mehrere Abonnements haben
-
Der Abonnement hat ein
NextPaymentDate, an dem die nächste Zahlung bearbeitet werden muss und einNextReminderDate, an dem eine E-Mail-Erinnerung an den Kunden gesendet wird -
Es gibt ein Element für Abonnement, das gespeichert und aktualisiert wird, wenn die Zahlung verarbeitet wurde (die durchschnittliche Artikelgröße liegt bei etwa 1 KB und der Durchsatz hängt von der Anzahl der Kontenund Abonnements ab)
-
Der Zahlungsabwickler erstellt als Teil des Prozesses auch einen Beleg, der mithilfe eines TTL-Attributs in der Tabelle gespeichert ist und nach einer bestimmten Zeit ablaufen soll
Beziehungsdiagramm für Unternehmen mit wiederkehrenden Zahlungen
Dies ist das Diagramm der Entitätsbeziehungen (Entity Relationship Diagram, ERD), das wir für das Schemadesign für der wiederkehrende Zahlungen verwenden werden.
Zugriffsmuster für das System für wiederkehrende Zahlungen
Dies sind die Zugriffsmuster, die wir für das Schemadesign für das System für wiederkehrende Zahlungen berücksichtigen werden.
-
createSubscription -
createReceipt -
updateSubscription -
getDueRemindersByDate -
getDuePaymentsByDate -
getSubscriptionsByAccount -
getReceiptsByAccount
Schemadesign für wiederkehrende Zahlungen
Die generischen Namen PK und SK werden für Schlüsselattribute verwendet, um das Speichern verschiedener Entitätstypen in derselben Tabelle zu ermöglichen, z. B. die Konto-, Abonnement- und Empfangsentitäten. Der Benutzer erstellt zunächst ein Abonnement. In diesem Fall verpflichtet sich der Benutzer, jeden Monat am selben Tag einen Betrag als Gegenleistung für ein Produkt zu bezahlen. Sie können entscheiden, an welchem Tag des Monats die Zahlung bearbeitet werden soll. Es gibt auch eine Erinnerung, die vor der Bearbeitung der Zahlung gesendet wird. Die Anwendung funktioniert mit zwei Batch-Jobs, die jeden Tag ausgeführt werden: Ein Batch-Job sendet Erinnerungen, die an diesem Tag fällig sind, und der andere Batch-Job verarbeitet alle an diesem Tag fälligen Zahlungen.
Schritt 1: Zugriffsmuster 1 (createSubscription) angehen
Zugriffsmuster 1 (createSubscription) wird verwendet, um das Abonnement zunächst zu erstellen, und die Details einschließlich SKU, NextPaymentDate, NextReminderDate und PaymentDetails werden festgelegt. In diesem Schritt wird der Status der Tabelle für nur ein Konto mit einem Abonnement angezeigt. Die Artikelsammlung kann mehrere Abonnements enthalten, es handelt sich also um eine one-to-many Beziehung.
Schritt 2: Zugriffsmuster 2 (createReceipt) und 3 (updateSubscription) angehen
Zugriffsmuster 2 (createReceipt) wird verwendet, um die Belegposition zu erstellen. Nachdem die Zahlung jeden Monat bearbeitet wurde, schreibt der Zahlungsabwickler einen Beleg zurück in die Basistabelle. Die Artikelsammlung kann mehrere Belege enthalten, es handelt sich also um eine one-to-many Beziehung. Der Zahlungsabwickler aktualisiert auch das zu aktualisierende Abonnementelement (Zugriff auf Muster 3 (updateSubscription)) für den NextReminderDate oder den NextPaymentDate für den nächsten Monat.
Schritt 3: Zugriffsmuster 4 (getDueRemindersByDate) angehen
Die Anwendung verarbeitet Zahlungserinnerungen für den aktuellen Tag stapelweise. Daher muss die Anwendung in einer anderen Dimension auf die Abonnements zugreifen: Datum statt Konto. Dies ist ein guter Anwendungsfall für einen globalen sekundären Index (GSI). In diesem Schritt fügen wir den Index GSI-1 hinzu. Dabei wird das NextReminderDate als GSI-Partitionsschlüssel genutzt. Wir müssen nicht alle Artikel replizieren. Dieses GSI ist ein spärlicher Index und die Belegpositionen werden nicht repliziert. Wir müssen auch nicht alle Attribute projizieren – wir müssen nur eine Teilmenge der Attribute einbeziehen. Das folgende Bild zeigt das Schema von GSI-1 und enthält die erforderlichen Informationen, damit die Anwendung die Erinnerungs-E-Mail senden kann.
Schritt 4: Zugriffsmuster 5 (getDuePaymentsByDate) angehen
Die Anwendung verarbeitet Zahlungserinnerungen für den aktuellen Tag auf dieselbe weise in Stapeln wie Erinnerungen. In diesem Schritt fügen wir GSI-2 hinzu. Dabei wird das NextPaymentDate als GSI-Partitionsschlüssel genutzt. Wir müssen nicht alle Artikel replizieren. Dieses GSI ist ein spärlicher Index und die Belegpositionen werden nicht repliziert. Das folgende Bild zeigt das Schema von GSI-2.
Schritt 5: Zugriffsmuster 6 (getSubscriptionsByAccount) und 7 (getReceiptsByAccount) angehen
Die Anwendung kann alle Abonnements für ein Konto mithilfe einer Abfrage in der Basistabelle abrufen, die auf die Konto-ID abzielt (der PK) und den Bereichsoperator verwendet, um alle Artikel abzurufen, bei denen der SK mit „SUB#“ beginnt. Die Anwendung kann dieselbe Abfragestruktur auch verwenden, um alle Belege abzurufen, indem sie einen Bereichsoperator verwendet, um alle Artikel abzurufen, bei denen der SK mit „REC#“ beginnt. Dadurch können wir die Zugriffsmuster 6 (getSubscriptionsByAccount) und 7 (getReceiptsByAccount) erfüllen. Die Anwendung verwendet diese Zugriffsmuster, damit der Benutzer seine aktuellen Abonnements und seine früheren Einnahmen für die letzten sechs Monate einsehen kann. In diesem Schritt wird das Tabellenschema nicht geändert. Im Folgenden sehen Sie, wie wir nur auf die Abonnementelemente im Zugriffsmuster 6 abzielen (getSubscriptionsByAccount).
Alle Zugriffsmuster und wie das Schemadesign sie behandelt, sind in der folgenden Tabelle zusammengefasst:
| Zugriffsmuster | Basis-table/GSI/LSI | Operation | Partitionsschlüsselwert | Sortierschlüsselwert |
|---|---|---|---|---|
| createSubscription | Basistabelle | PutItem | ACC #account_id | SUB#<SUBID>#SKU<SKUID> |
| createReceipt | Basistabelle | PutItem | ACC#account_id | REC#< > #SKU RecieptDate <SKUID> |
| updateSubscription | Basistabelle | UpdateItem | ACC #account_id | SUB#<SUBID>#SKU<SKUID> |
| getDueRemindersByDate | GSI-1 | Abfrage | <NextReminderDate> | |
| getDuePaymentsByDate | GSI-2 | Abfrage | <NextPaymentDate> | |
| getSubscriptionsByKonto | Basistabelle | Query | ACC#account_id | SK begins_with “SUB#” |
| getReceiptsByKonto | Basistabelle | Query | ACC#account_id | SK begins_with “REC#” |
Endgültiges Schema für wiederkehrende Zahlungen
Dies sind die endgültigen Schemadesigns. Informationen zum Herunterladen dieses Schemadesign als JSON-Datei finden Sie unter DynamoDB-Beispiele
Basistabelle
GSI-1
GSI-2
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.
