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:

• Kunden für eine bestimmte CustomerId abrufen

• Produkt für eine bestimmte ProductId abrufen

• Warenlager für eine bestimmte WarehouseId abrufen

• Produktbestand für alle Warenlager nach ProductId abrufen

• Bestellung für eine bestimmte OrderId abrufen

• Alle Produkte für eine bestimmte OrderId abrufen

• Rechnung für eine bestimmte OrderId abrufen

• Alle Lieferungen für eine bestimmte OrderId abrufen

• Alle Bestellungen für eine bestimmte ProductId für einen bestimmten Zeitraum abrufen

• Rechnung für eine bestimmte InvoiceId abrufen

• Alle Zahlungen für eine bestimmte InvoiceId abrufen

• Versanddetails für eine bestimmte ShipmentId abrufen

• Alle Lieferungen für eine bestimmte WarehouseId abrufen

• Bestand aller Produkte für eine bestimmte WarehouseId abrufen

• Alle Rechnungen für eine bestimmte CustomerId für einen bestimmten Zeitraum abrufen

• Alle von einer bestimmten CustomerId bestellten Produkte für einen bestimmten Zeitraum abrufen

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.

1. getCustomerByCustomerId

2. getProductByProductId

3. getWarehouseByWarehouseId

4. getProductInventoryByProductId

5. getOrderDetailsByOrderId

6. getProductByOrderId

7. getInvoiceByOrderId

8. getShipmentByOrderId

9. getOrderByProductIdForDateRange

10. getInvoiceByInvoiceId

11. getPaymentByInvoiceId

12. getShipmentDetailsByShipmentId

13. getShipmentByWarehouseId

14. getProductInventoryByWarehouseId

15. getInvoiceByCustomerIdForDateRange

16. getProductsByCustomerIdForDateRange

Entwicklung des Schemadesigns

Verwenden SieKeine SQL Workbench für DynamoDB, import AnOnlineShop_1.json, um ein neues Datenmodell namens AnOnlineShop und eine neue Tabelle namens zu erstellen. OnlineShop 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 AnOnlineShop_2.json, um das Zugriffsmuster 1 () zu verarbeiten. getCustomerByCustomerId 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 AnOnlineShop_3.json, um das Zugriffsmuster 2 (getProductByProductId) für die Entität zu adressieren. product 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 AnOnlineShop_4.json, um das Zugriffsmuster 3 (getWarehouseByWarehouseId) für die Entität zu adressieren. warehouse 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 AnOnlineShop_5.json, um das Zugriffsmuster 4 () zu adressieren. getProductInventoryByProductId warehouseItemDie Entität wird verwendet, um die Anzahl der Produkte in jedem Lager zu verfolgen. Dieses Element wird normalerweise aktualisiert, wenn ein Produkt einem Warenlager hinzugefügt oder entnommen wird. Wie in der ERD zu sehen ist, besteht ein many-to-many Zusammenhang zwischen product undwarehouse. Hier wird die one-to-many Beziehung von product bis warehouse modelliert alswarehouseItem. Später product wird auch die one-to-many Beziehung von warehouse bis 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 warehouse Elemente customerproduct, und hinzu, indem Sie _6.json importieren. AnOnlineShop Importieren Sie dann AnOnlineShop_7.json, um eine Elementsammlung zu erstellenorder, die die Zugriffsmuster 5 (getOrderDetailsByOrderId) und 6 () adressieren kann. getProductByOrderId Sie können die one-to-many Beziehung zwischen OrderItem-Entitäten order und deren product Modellierung als OrderItem-Entitäten sehen.

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 AnOnlineShop_8.json, um der Bestellartikelsammlung eine invoice Entität hinzuzufügen, die das Zugriffsmuster 7 () verarbeitet. getInvoiceByOrderId 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 AnOnlineShop_9.json, um der Bestellartikelsammlung shipment Entitäten hinzuzufügen, um das Zugriffsmuster 8 zu adressieren (). getShipmentByOrderId 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 AnOnlineShop_10.json, um mithilfe der GSI eine neue Artikelsammlung zu erstellen, die es ermöglicht, orderItem Daten aus mehreren Bestellartikelsammlungen abzurufen. 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 AnOnlineShop_11.json, um die Zugriffsmuster 10 (getInvoiceByInvoiceId) und 11 (getPaymentByInvoiceId) zu adressieren, die sich beide auf. invoice 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.

Anmerkung

GSI1-PK und GSI1-SK sind überladen und speichern Informationen über verschiedene Entitäten, sodass mehrere Zugriffsmuster vom selben GSI aus abgedeckt werden können. Weitere Informationen zur GSI-Überladung finden Sie unter Überladen globaler sekundärer Indizes (GSI).

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 AnOnlineShop_12.json, um die Zugriffsmuster 12 (getShipmentDetailsByShipmentId) und 13 () zu adressieren. getShipmentByWarehouseId

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:

Die GSI1 Partitions- und Sortierschlüssel wurden bereits verwendet, um eine one-to-many Beziehung zwischen und zu modellieren. shipment shipmentItem Um das Zugriffsmuster 12 (getShipmentDetailsByShipmentId) anzugehen, fragen Sie GSI1 mit GSI1-PK=shipmentId und GSI1-SK=shipmentId ab.

GSI1:

Wir müssen eine weitere GSI (GSI2) erstellen, um die neue one-to-many Beziehung zwischen warehouse und shipment für das Zugriffsmuster 13 () zu modellieren. getShipmentByWarehouseId 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 AnOnlineShop_13.json, um Daten hinzuzufügen, die sich auf die nächsten Zugriffsmuster 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:

Anmerkung

In NoSQL-Workbench stehen Facets für die verschiedenen Datenzugriffsmuster einer Anwendung für DynamoDB. Facets bieten Ihnen die Möglichkeit, eine Teilmenge der Daten in einer Tabelle anzuzeigen, ohne Datensätze sehen zu müssen, die den Einschränkungen des Facets nicht entsprechen. Facets gelten als visuelles Datenmodellierungswerkzeug und existieren nicht als brauchbares Konstrukt in DynamoDB, da sie eine reine Hilfe zur Modellierung von Zugriffsmustern darstellen.

Importieren Sie AnOnlineShop_facets.json, um die Facetten für diesen Anwendungsfall zu sehen.

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

Zugriffsmuster	Basistabelle/GSI/LSI	Operation	Partitionsschlüsselwert	Sortierschlüsselwert
getCustomerByCustomerId	Basistabelle	GetItem	PK=customerId	SK=customerId
getProductByProductId	Basistabelle	GetItem	PK=productId	SK=productId
getWarehouseByWarehouseId	Basistabelle	GetItem	PK=warehouseId	SK=warehouseId
getProductInventoryByProductId	Basistabelle	Query	PK=productId	SK begins_with "w#"
getOrderDetailsByOrderId	Basistabelle	Query	PK=orderId
getProductByOrderId	Basistabelle	Query	PK=orderId	SK begins_with "p#"
getInvoiceByOrderId	Basistabelle	Query	PK=orderId	SK begins_with "i#"
getShipmentByOrderId	Basistabelle	Query	PK=orderId	SK begins_with "sh#"
getOrderByProductIdForDateRange	GSI1	Abfrage	PK=productId	SK zwischen Datum1 und Datum2
getInvoiceByInvoiceId	GSI1	Abfrage	PK=invoiceId	SK=invoiceId
getPaymentByInvoiceId	GSI1	Abfrage	PK=invoiceId	SK=invoiceId
getShipmentDetailsByShipmentId	GSI1	Abfrage	PK=shipmentId	SK=shipmentId
getShipmentByWarehouseId	GSI2	Abfrage	PK=warehouseId	SK begins_with "sh#"
getProductInventoryByWarehouseId	GSI2	Abfrage	PK=warehouseId	SK begins_with "p#"
getInvoiceByCustomerIdForDateRange	GSI2	Abfrage	PK=customerId	SKU zwischen i#date1 und i#date2
getProductsByCustomerIdForDateRange	GSI2	Abfrage	PK=customerId	SK zwischen p#date1 und p#date2

Endgültiges Schema des Onlineshops

Dies sind die endgültigen Schemadesigns. Informationen zum Herunterladen dieses Schemadesign als JSON-Datei finden Sie unter DynamoDB-Entwurfsmuster 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:

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

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.