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

Verwenden SieNoSQL-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. Die Lesbarkeit wäre beeinträchtigt, wenn wir einfach alphanumerische Zahlen IDs für verschiedene Entitäten im selben Attribut speichern würden. 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 aus der ERD hervorgeht, 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 AnOnlineShop_6.json importieren. 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 shipment Entitäten zur Bestellartikelsammlung 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.

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 shipment und zu modellieren. 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:

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