Wählen Sie Ihre Cookie-Einstellungen aus

Wir verwenden essentielle Cookies und ähnliche Tools, die für die Bereitstellung unserer Website und Services erforderlich sind. Wir verwenden Performance-Cookies, um anonyme Statistiken zu sammeln, damit wir verstehen können, wie Kunden unsere Website nutzen, und Verbesserungen vornehmen können. Essentielle Cookies können nicht deaktiviert werden, aber Sie können auf „Anpassen“ oder „Ablehnen“ klicken, um Performance-Cookies abzulehnen.

Wenn Sie damit einverstanden sind, verwenden AWS und zugelassene Drittanbieter auch Cookies, um nützliche Features der Website bereitzustellen, Ihre Präferenzen zu speichern und relevante Inhalte, einschließlich relevanter Werbung, anzuzeigen. Um alle nicht notwendigen Cookies zu akzeptieren oder abzulehnen, klicken Sie auf „Akzeptieren“ oder „Ablehnen“. Um detailliertere Entscheidungen zu treffen, klicken Sie auf „Anpassen“.

Schemadesign für wiederkehrende Zahlungen in DynamoDB

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

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

System ERD für wiederkehrende Zahlungen, das die Entitäten anzeigt: 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ä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.

GSI-1-Schema mit Details wie der E-Mail-Adresse, die Anwendung benötigt, um eine Erinnerungs-E-Mail zu senden.

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.

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

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#< > #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 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 und. PaymentAmount PaymentDay

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:

  1. Laden Sie NoSQL Workbench herunter. Weitere Informationen finden Sie unter Herunterladen von NoSQL Workbench for DynamoDB.

  2. Laden Sie die oben aufgeführte JSON-Schemadatei herunter, die bereits das NoSQL-Workbench-Modellformat aufweist.

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

  4. Nach dem Import in NOSQL Workbench können Sie das Datenmodell bearbeiten. Weitere Informationen finden Sie unter Bearbeiten eines vorhandenen Datenmodells.

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

DatenschutzNutzungsbedingungen für die WebsiteCookie-Einstellungen
© 2025, Amazon Web Services, Inc. oder Tochtergesellschaften. Alle Rechte vorbehalten.