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.

Verwendung von DynamoDB als Datenspeicher für einen Online-Shop

In diesem Anwendungsfall geht es um die Verwendung von DynamoDB als Datenspeicher für einen Online-Shop (E-Store).

Anwendungsfall

In einem Online-Shop können Benutzer verschiedene Produkte durchsuchen und diese schließlich kaufen. Basierend auf der generierten Rechnung kann ein Kunde mit einem Rabattcode oder einer Geschenkkarte bezahlen und dann den Restbetrag mit einer Kreditkarte begleichen. Die gekauften Produkte werden von einem der Warenlager abgeholt und an die angegebene Adresse versandt. Zu den typischen Zugriffsmustern für einen Online-Shop gehören folgende:

Diagramm der Entitätsbeziehungen

Dieses Diagramm der Entitätsbeziehungen (Entity Relationship Diagram, ERD) verwenden wir, um DynamoDB als Datenspeicher für einen Online-Shop zu verwenden.

Zugriffsmuster

Das sind die Zugriffsmuster, die wir in Betracht ziehen, wenn wir DynamoDB als Datenspeicher für einen Online-Shop verwenden.

Entwicklung des Schemadesigns

Importieren Sie über NoSQL-Workbench für DynamoDB die Datei AnOnlineShop_1.json, um ein neues Datenmodell namens AnOnlineShop und eine neue Tabelle namens OnlineShop zu erstellen. Beachten Sie, dass wir für den Partitionsschlüssel und den Sortierschlüssel die generischen Namen PK und SK verwenden. Diese Methode wird verwendet, um verschiedene Arten von Entitäten in derselben Tabelle zu speichern.

Schritt 1: Zugriffsmuster 1 (getCustomerByCustomerId) angehen

Importieren Sie die Datei AnOnlineShop_2.json, um das Zugriffsmuster 1 (getCustomerByCustomerId) anzugehen. Manche Entitäten haben keine Beziehungen zu anderen Entitäten, daher verwenden wir für sie den gleichen Wert von PK und SK. Beachten Sie in den Beispieldaten, dass die Schlüssel das Präfix c# verwenden, um die customerId von anderen Entitäten zu unterscheiden, die später hinzugefügt werden. Diese Vorgehensweise wird auch für andere Entitäten genutzt.

Um dieses Zugriffsmuster anzugehen, kann ein GetItem-Vorgang mit PK=customerId und SK=customerId verwendet werden.

Schritt 2: Zugriffsmuster 2 (getProductByProductId) angehen

Importieren Sie die Datei AnOnlineShop_3.json, um das Zugriffsmuster 2 (getProductByProductId) für die Entität product anzugehen. Den Produktentitäten wird das Präfix p# vorangestellt und dasselbe Sortierschlüsselattribut wurde zum Speichern der customerID und der productID verwendet. Die generische Benennung und vertikale Partitionierung ermöglichen es uns, solche Elementauflistungen zu erstellen, um ein effektives Einzeltabellendesign zu erhalten.

Um dieses Zugriffsmuster anzugehen, kann ein GetItem-Vorgang mit PK=productId und SK=productId verwendet werden.

Schritt 3: Zugriffsmuster 3 (getWarehouseByWarehouseId) angehen

Importieren Sie die Datei AnOnlineShop_4.json, um das Zugriffsmuster 3 (getWarehouseByWarehouseId) für die Entität warehouse anzugehen. Derzeit werden die Entitäten customer, product und warehouse zur selben Tabelle hinzugefügt. Sie unterscheiden sich durch Präfixe und das Attribut EntityType. Ein Typ-Attribut (oder eine Präfixbenennung) verbessert die Lesbarkeit des Modells. Würden wir einfach alphanumerische IDs für verschiedene Entitäten im selben Attribut speichern, wäre die Lesbarkeit beeinträchtigt. Ohne diese Identifikatoren wäre es schwierig, eine Entität von der anderen zu unterscheiden.

Um dieses Zugriffsmuster anzugehen, kann ein GetItem-Vorgang mit PK=warehouseId und SK=warehouseId verwendet werden.

Basistabelle:

Schritt 4: Zugriffsmuster 4 (getProductInventoryByProductId) angehen

Importieren Sie die Datei AnOnlineShop_5.json, um das Zugriffsmuster 4 (getProductInventoryByProductId) anzugehen. Die Entität warehouseItem wird verwendet, um die Anzahl der Produkte in jedem Warenlager zu verfolgen. Dieses Element wird normalerweise aktualisiert, wenn ein Produkt einem Warenlager hinzugefügt oder entnommen wird. Wie aus dem Diagramm der Entitätsbeziehungen hervorgeht, besteht zwischenproduct und warehouse eine n:m-Beziehung. Hier wird die 1:n-Beziehung von product zu warehouse als warehouseItem modelliert. Später wird auch die 1:n-Beziehung von warehouse zu product modelliert.

Das Zugriffsmuster 4 kann mit der Abfrage von PK=ProductId und SK begins_with “w#“ angegangen werden.

Weitere Informationen zu begins_with() und weitere Ausdrücke, die auf Sortierschlüssel angewendet werden können, finden Sie unter Schlüsselbedingungsausdrücke.

Basistabelle:

Schritt 5: Zugriffsmuster 5 (getOrderDetailsByOrderId) und 6 (getProductByOrderId) angehen

Fügen Sie der Tabelle weitere Elemente des Typs customer, product und warehouse hinzu, indem Sie die Datei AnOnlineShop_6.json importieren. Importieren Sie dann die Datei AnOnlineShop_7.json, um eine Elementauflistung für order zu erstellen, die die Zugriffsmuster 5 (getOrderDetailsByOrderId) und 6 (getProductByOrderId) angehen kann. Sie sehen die 1:n-Beziehung zwischen order und product als OrderItem-Entitäten modelliert.

Um das Zugriffsmuster 5 (getOrderDetailsByOrderId) anzugehen, fragen Sie die Tabelle mit PK=orderId ab. Dadurch erhalten Sie alle Informationen zur Bestellung, einschließlich der customerIdund der bestellten Produkte.

Basistabelle:

Um das Zugriffsmuster 6 (getProductByOrderId) anzugehen, müssen wir nur Produkte in einer order lesen. Fragen Sie dazu die Tabelle mit PK=orderId und SK begins_with “p#” ab.

Basistabelle:

Schritt 6: Zugriffsmuster 7 (getInvoiceByOrderId) angehen

Importieren Sie die Datei AnOnlineShop_8.json, um eine Entität des Typs invoice zur Elementauflistung order hinzuzufügen und Zugriffsmuster 7 (getInvoiceByOrderId) anzugehen. Um dieses Zugriffsmuster anzugehen, können Sie einen Abfragevorgang mit PK=orderId und SK begins_with “i#” verwenden.

Basistabelle:

Schritt 7: Zugriffsmuster 8 (getShipmentByOrderId) angehen

Importieren Sie die Datei AnOnlineShop_9.json, um Entitäten des Typs shipment zur Elementauflistung order hinzuzufügen und Zugriffsmuster 8 (getShipmentByOrderId) anzugehen. Wir erweitern dasselbe vertikal partitionierte Modell, indem wir dem Einzeltabellendesign weitere Typen von Entitäten hinzufügen. Beachten Sie, dass die Elementauflistung order die verschiedenen Beziehungen enthält, die eine Entität des Typs order zu den Entitäten des Typs shipment, orderItem und invoice hat.

Um Lieferungen nach orderId abzurufen, können Sie einen Abfragevorgang mit PK=orderIdund SK begins_with “sh#” durchführen.

Basistabelle:

Schritt 8: Zugriffsmuster 9 (getOrderByProductIdForDateRange) angehen

Wir haben im vorherigen Schritt die Elementauflistung order erstellt. Dieses Zugriffsmuster hat neue Suchdimensionen (ProductID und Date), weshalb Sie die gesamte Tabelle scannen und relevante Datensätze herausfiltern müssen, um die anvisierten Elemente abzurufen. Um dieses Zugriffsmuster anzugehen, müssen wir einen globalen sekundären Index (GSI) erstellen. Importieren Sie die Datei AnOnlineShop_10.json, um mithilfe des GSI eine neue Elementauflistung zu erstellen, die das Abrufen der orderItem-Daten von mehreren order-Elementauflistungen ermöglicht. Die Daten verfügen jetzt über GSI1-PK und GSI1-SK, den zukünftigen Partitionsschlüssel und Sortierschlüssel von GSI1.

DynamoDB fügt automatisch Elemente, die die Schlüsselattribute eines GSI enthalten, aus der Tabelle in den GSI ein. Zusätzliche manuelle Einfügungen in den GSI sind nicht notwendig.

Um das Zugriffsmuster 9 anzugehen, führen Sie eine Abfrage an GSI1 mit GSI1-PK=productId und GSI1SK between (date1, date2) durch.

Basistabelle:

GSI1:

Schritt 9: Zugriffsmuster 10 (getInvoiceByInvoiceId) und 11 (getPaymentByInvoiceId) angehen

Importieren Sie die Datei AnOnlineShop_11.json, um die Zugriffsmuster 10 (getInvoiceByInvoiceId) und 11 (getPaymentByInvoiceId) anzugehen, die beide zur invoice gehören. Obwohl es sich um zwei unterschiedliche Zugriffsmuster handelt, werden sie mit derselben Schlüsselbedingung realisiert. Payments sind als Attribut mit dem Datentyp „Karte“ auf der Entität invoice definiert.

Um die Zugriffsmuster 10 und 11 anzugehen, fragen Sie GSI1 mit GSI1-PK=invoiceId und GSI1-SK=invoiceId ab.

GSI1:

Schritt 10: Zugriffsmuster 12 (getShipmentDetailsByShipmentId) und 13 (getShipmentByWarehouseId) angehen

Importieren Sie die Datei AnOnlineShop_12.json, um die Zugriffsmuster 12 (getShipmentDetailsByShipmentId) und 13 (getShipmentByWarehouseId) anzugehen.

Beachten Sie, dass shipmentItem-Entitäten zur Elementauflistung order in der Basistabelle hinzugefügt werden, damit alle Details zu einer Bestellung in einem einzigen Abfragevorgang abgerufen werden können.

Basistabelle:

Der Partitions- und der Sortierschlüssel von GSI1 wurden bereits verwendet, um eine 1:n-Beziehung zwischen shipment und shipmentItem zu modellieren. Um das Zugriffsmuster 12 (getShipmentDetailsByShipmentId) anzugehen, fragen Sie GSI1 mit GSI1-PK=shipmentId und GSI1-SK=shipmentId ab.

GSI1:

Wir müssen einen weiteren GSI (GSI2) erstellen, um die neue 1:n-Beziehung zwischen warehouse und shipment für Zugriffsmuster 13 (getShipmentByWarehouseId) zu modellieren. Um dieses Zugriffsmuster anzugehen, fragen Sie GSI2 mit GSI2-PK=warehouseId und GSI2-SK begins_with “sh#” ab.

GSI2:

Schritt 11: Zugriffsmuster 14 (getProductInventoryByWarehouseId), 15 (getInvoiceByCustomerIdForDateRange) und 16 (getProductsByCustomerIdForDateRange) angehen

Importieren Sie die Datei AnOnlineShop_13.json, um Daten hinzuzufügen, die sich auf die nächste Gruppe von Zugriffsmustern beziehen. Um das Zugriffsmuster 14 (getProductInventoryByWarehouseId) anzugehen, fragen Sie GSI2 mit GSI2-PK=warehouseId und GSI2-SK begins_with “p#” ab.

GSI2:

Um das Zugriffsmuster 15 (getInvoiceByCustomerIdForDateRange) anzugehen, fragen Sie GSI2 mit GSI2-PK=customerId und GSI2-SK between (i#date1, i#date2) ab.

GSI2:

Um das Zugriffsmuster 16 (getProductsByCustomerIdForDateRange) anzugehen, fragen Sie GSI2 mit GSI2-PK=customerId und GSI2-SK between (p#date1, p#date2) ab.

GSI2:

Alle Zugriffsmuster und wie das Schemadesign sie behandelt, sind in der folgenden Tabelle zusammengefasst:

Endgültiges Schema des Online-Shops

Dies sind die endgültigen Schemadesigns. Informationen zum Herunterladen dieses Schemadesigns als JSON-Datei finden Sie unter DynamoDB Designmuster auf GitHub.

Basistabelle

GSI1

GSI2

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: