Schemadesign für wiederkehrende Zahlungen in DynamoDB - Amazon-DynamoDB

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 für wiederkehrende Zahlungen in DynamoDB

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: KontenAbonnements 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 ein NextReminderDate, 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 im Rahmen des Vorgangs auch eine Quittung, die in der Tabelle gespeichert ist und anhand eines Attributs so eingestellt ist, dass sie nach einer bestimmten Zeit ablaufen TTL

Beziehungsdiagramm für Unternehmen mit wiederkehrenden Zahlungen

Dies ist das Entitätsbeziehungsdiagramm (ERD), das wir für das Systemschema für wiederkehrende Zahlungen verwenden werden.

System für wiederkehrende Zahlungen ERD mit folgenden Entitäten: Konto, Abonnement und Quittung.

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.

  1. createSubscription

  2. createReceipt

  3. updateSubscription

  4. getDueRemindersByDate

  5. getDuePaymentsByDate

  6. getSubscriptionsByAccount

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

Tabellendesign mit den Abonnementdetails für ein Konto.

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.

Die Belegdetails und der Abonnementartikel werden aktualisiert, sodass das nächste Erinnerungsdatum für das Abonnement angezeigt wird.

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ärindex (GSI). In diesem Schritt fügen wir den Index hinzuGSI-1, der den NextReminderDate als GSI Partitionsschlüssel verwendet. Wir müssen nicht alle Artikel replizieren. Dies GSI ist ein spärlicher Index, und die Belegelemente 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.

GSI-1 Schema mit Details wie der E-Mail-Adresse. Die Anwendung muss eine Erinnerungs-E-Mail senden.

Schritt 4: Zugriffsmuster 5 (getDuePaymentsByDate) angehen

Die Anwendung verarbeitet Zahlungserinnerungen für den aktuellen Tag auf dieselbe weise in Stapeln wie Erinnerungen. Wir fügen GSI-2 diesen Schritt hinzu und er verwendet den NextPaymentDate als GSI Partitionsschlüssel. Wir müssen nicht alle Artikel replizieren. Dies GSI ist ein spärlicher Index, da die Belegelemente nicht repliziert werden. Das folgende Bild zeigt das Schema von GSI-2.

GSI-2-Schema mit Details zur Zahlungsabwicklung. NextPaymentDate ist der Partitionsschlüssel für GSI -2.

Schritt 5: Zugriffsmuster 6 (getSubscriptionsByAccount) und 7 (getReceiptsByAccount) angehen

Die Anwendung kann alle Abonnements für ein Konto abrufen, indem sie eine Abfrage in der Basistabelle verwendet, die auf die Konto-ID (diePK) abzielt, und den Bereichsoperator verwendet, um alle Elemente abzurufen, deren SK Name mit „SUB#“ beginnt. Die Anwendung kann auch dieselbe Abfragestruktur verwenden, um alle Belege abzurufen, indem sie einen Bereichsoperator verwendet, um alle Elemente abzurufen, deren Wert mit „REC#“ SK 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).

Ergebnis des Abfragevorgangs in der Basistabelle. Es zeigt das Abonnement eines bestimmten Kontos.

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#<RecieptDate>#SKU<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 beginnt_mit „#“ SUB
getReceiptsByKonto Basistabelle Query ACC#account_id SK beginnt_mit „#“ 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 auf. GitHub

Basistabelle

Basistabellendesign mit Kontoinformationen sowie den zugehörigen Abonnement- und Belegdetails.

GSI-1

GSI-1 Schema mit Abonnementdetails wie E-Mail-Adresse und NextPaymentDate.

GSI-2

GSI-2-Schema mit Zahlungsdetails wie PaymentAmount und PaymentDay.

Verwenden Sie No SQL Workbench mit diesem Schemadesign

Sie können dieses endgültige Schema in No SQL Workbench importieren, ein visuelles Tool, das Funktionen für Datenmodellierung, Datenvisualisierung und Abfrageentwicklung für DynamoDB bereitstellt, um Ihr neues Projekt weiter zu untersuchen und zu bearbeiten. Gehen Sie folgendermaßen vor, um zu beginnen:

  1. Laden Sie No Workbench herunter. SQL Weitere Informationen finden Sie unter No SQL Workbench für DynamoDB herunterladen.

  2. Laden Sie die oben aufgeführte JSON Schemadatei herunter, die bereits im No SQL Workbench-Modellformat vorliegt.

  3. Importieren Sie die JSON Schemadatei in No SQL Workbench. Weitere Informationen finden Sie unter Importieren eines vorhandenen Datenmodells.

  4. Sobald Sie in NOSQL Workbench importiert haben, können Sie das Datenmodell bearbeiten. Weitere Informationen finden Sie unter Bearbeiten eines vorhandenen Datenmodells.

  5. Verwenden Sie die Data Visualizer-Funktion von No SQL Workbench, um Ihr Datenmodell zu visualisieren, Beispieldaten hinzuzufügen oder Beispieldaten aus einer CSV Datei zu importieren.