Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Utilizzo di DynamoDB come archivio dati per un negozio online

In questo caso di utilizzo si parla di usare DynamoDB come archivio dati per un negozio online (o e-store).

Caso d'uso

Un negozio online consente agli utenti di sfogliare diversi prodotti e alla fine di acquistarli. In base alla fattura generata, un cliente può pagare utilizzando un codice sconto o una carta regalo e poi pagare l'importo residuo con una carta di credito. I prodotti acquistati verranno ritirati da uno dei diversi magazzini e spediti all'indirizzo fornito. I modelli di accesso tipici per un negozio online includono:

Diagramma delle relazioni tra entità

Questo è il diagramma delle relazioni tra entità (ERD) che useremo per modellare DynamoDB come archivio dati per un negozio online.

Modelli di accesso

Questi sono i modelli di accesso da considerare quando si usa DynamoDB come archivio dati per un negozio online.

Evoluzione della progettazione dello schema

Utilizzo diNessun SQL workbench per DynamoDB, import AnOnlineShop_1.json per creare un nuovo modello di dati chiamato AnOnlineShop e una nuova tabella chiamata. OnlineShop Nota che usiamo i nomi generici PK e SK per la chiave di partizione e la chiave di ordinamento. Questa è una pratica utilizzata per memorizzare diversi tipi di entità nella stessa tabella.

Fase 1: Gestire il modello di accesso 1 (getCustomerByCustomerId)

Importa AnOnlineShop_2.json per gestire il pattern di accesso 1 (). getCustomerByCustomerId Alcune entità non hanno relazioni con altre entità, quindi useremo lo stesso valore di PK e SK per loro. Nei dati di esempio, nota che le chiavi utilizzano un prefisso c#per distinguere customerId da altre entità che verranno aggiunte in seguito. Questa pratica viene ripetuta anche per altre entità.

Per risolvere questo modello di accesso, un’operazione GetItem può essere utilizzata con PK=customerId e SK=customerId.

Fase 2: Gestire il modello di accesso 2 (getProductByProductId)

Importa AnOnlineShop_3.json per indirizzare il pattern di accesso 2 () per l'entità. getProductByProductId product Le entità del prodotto sono precedute da p# e lo stesso attributo chiave di ordinamento è stato utilizzato per memorizzare customerID così come productID. Denominazione generica e partizionamento verticale ci consentono di creare tali collezioni di articoli per un design efficace di una tabella singola.

Per risolvere questo modello di accesso, un’operazione GetItem può essere utilizzata con PK=productId e SK=productId.

Fase 3: Gestire il modello di accesso 3 (getWarehouseByWarehouseId)

Importa AnOnlineShop_4.json per indirizzare il pattern di accesso 3 () per l'entità. getWarehouseByWarehouseId warehouse Al momento abbiamo le entità customer, product e warehouse aggiunte alla stessa tabella. Si distinguono utilizzando i prefissi e l’attributo EntityType. Un attributo di tipo (o denominazione del prefisso) migliora la leggibilità del modello. La leggibilità ne risentirebbe se memorizzassimo semplicemente elementi alfanumerici IDs per diverse entità nello stesso attributo. Sarebbe difficile distinguere un'entità dall'altra in assenza di questi identificatori.

Per risolvere questo modello di accesso, un’operazione GetItem può essere utilizzata con PK=warehouseId e SK=warehouseId.

Tabella di base:

Fase 4: Gestire il modello di accesso 4 (getProductInventoryByProductId)

Importa AnOnlineShop_5.json per indirizzare il pattern di accesso 4 (). getProductInventoryByProductId warehouseIteml'entità viene utilizzata per tenere traccia del numero di prodotti in ogni magazzino. Questo articolo viene normalmente aggiornato quando un prodotto viene aggiunto o rimosso da un magazzino. Come si vede inERD, esiste una many-to-many relazione tra product ewarehouse. Qui, la one-to-many relazione da product a warehouse è modellata comewarehouseItem. Successivamente, product verrà modellata warehouse anche la one-to-many relazione da a.

Il pattern di accesso 4 può essere risolto con una query su PK=ProductId e SK begins_with “w#“.

Per ulteriori informazioni su begins_with() e altre espressioni che possono essere applicate alle chiavi di ordinamento, vedi Espressioni delle condizioni chiave.

Tabella di base:

Fase 5: Gestire i modelli di accesso 5 (getOrderDetailsByOrderId) e 6 (getProductByOrderId)

Aggiungi altri customerwarehouse elementi e articoli alla tabella importando AnOnlineShop _6.json. product Quindi, importa AnOnlineShop_7.json per creare una raccolta di elementi in grado di soddisfare i order modelli di accesso 5 () e 6 (). getOrderDetailsByOrderId getProductByOrderId Puoi vedere la one-to-many relazione tra order e product modellata come entità. orderItem

Per risolvere il modello di accesso 5 (getOrderDetailsByOrderId), esegui una query della tabella con PK=orderId. Questo fornirà tutte le informazioni sull'ordine, tra cui customerId e i prodotti ordinati.

Tabella di base:

Per risolvere il modello di accesso 6 (getProductByOrderId), dobbiamo leggere i prodotti solo in order. Interroga la tabella con PK=orderId e SK begins_with “p#” per realizzarlo.

Tabella di base:

Fase 6: Gestire il modello di accesso 7 (getInvoiceByOrderId)

Importa AnOnlineShop_8.json per aggiungere un'invoiceentità alla raccolta di articoli dell'ordine per gestire il modello di accesso 7 (). getInvoiceByOrderId Per risolvere questo modello di accesso, puoi usare un’operazione di query con PK=orderId e SK begins_with “i#”.

Tabella di base:

Fase 7: Gestire il modello di accesso 8 (getShipmentByOrderId)

Importa AnOnlineShop_9.json per aggiungere shipment entità alla raccolta di articoli dell'ordine in modo da soddisfare il modello di accesso 8 (). getShipmentByOrderId Stiamo estendendo lo stesso modello partizionato verticalmente aggiungendo più tipi di entità nel design a tabella singola. Da notare come la raccolta di articoli dell’ordine contenga le diverse relazioni che un’entità order ha con le entità shipment, orderItem e invoice.

Per ricevere spedizioni entro la data orderId, è possibile eseguire un'operazione di query con PK=orderId e SK begins_with “sh#”.

Tabella di base:

Fase 8: Gestire il modello di accesso 9 (getOrderByProductIdForDateRange)

Abbiamo creato una raccolta degli articoli dell’ordine nel passaggio precedente. Questo modello di accesso ha nuove dimensioni di ricerca (ProductID e Date) che richiedono la scansione dell'intera tabella e il filtraggio dei record pertinenti per recuperare gli elementi mirati. Per risolvere questo modello di accesso, dovremo creare un indice secondario globale (GSI). Importa AnOnlineShop_10.json per creare una nuova raccolta di articoli utilizzando il GSI che consente di recuperare orderItem i dati da diverse raccolte di articoli dell'ordine. I dati ora hanno GSI1-PK e GSI1-SK che saranno rispettivamente la chiave di partizione e la chiave di ordinamento di GSI1.

DynamoDB popola automaticamente gli elementi che contengono gli attributi chiave di GSI a dalla tabella alla. GSI Non è necessario eseguire manualmente inserimenti aggiuntivi in. GSI

Per risolvere il modello di accesso 9, esegui una query su GSI1 con GSI1-PK=productId e GSI1SK between (date1, date2).

Tabella di base:

GSI1:

Fase 9: Gestire i modelli di accesso 10 (getInvoiceByInvoiceId) e 11 (getPaymentByInvoiceId)

Importa AnOnlineShop_11.json per risolvere i modelli di accesso 10 (getInvoiceByInvoiceId) e 11 (getPaymentByInvoiceId), entrambi correlati a. invoice Anche se si tratta di due modelli di accesso diversi, vengono realizzati utilizzando la stessa condizione chiave. Payments sono definiti come un attributo con il tipo di dati della mappa su entità invoice.

Per risolvere il modello di accesso 10 e 11, esegui una query su GSI1 con GSI1-PK=invoiceId e GSI1-SK=invoiceId.

GSI1:

Fase 10: Gestire i modelli di accesso 12 (getShipmentDetailsByShipmentId) e 13 (getShipmentByWarehouseId)

Importa AnOnlineShop_12.json per gestire i modelli di accesso 12 (getShipmentDetailsByShipmentId) e 13 (). getShipmentByWarehouseId

Da notare che le entità shipmentItem vengono aggiunte alla raccolta di elementi dell’ordine sulla tabella di base per poter recuperare tutti i dettagli su un ordine in un'unica operazione di query.

Tabella di base:

Le chiavi di GSI1 partizione e ordinamento sono già state utilizzate per modellare una one-to-many relazione tra shipment eshipmentItem. Per risolvere il modello di accesso 12 (getShipmentDetailsByShipmentId), esegui una query su GSI1 con GSI1-PK=shipmentId e GSI1-SK=shipmentId.

GSI1:

Dovremo creare un altro GSI (GSI2) per modellare la nuova one-to-many relazione tra warehouse e shipment per il pattern di accesso 13 (getShipmentByWarehouseId). Per risolvere questo modello di accesso, esegui una query su GSI2 con GSI2-PK=warehouseId e GSI2-SK begins_with “sh#”.

GSI2:

Fase 11: Gestire i modelli di accesso 14 (getProductInventoryByWarehouseId) 15 (getInvoiceByCustomerIdForDateRange) e 16 (getProductsByCustomerIdForDateRange)

Importa AnOnlineShop_13.json per aggiungere dati relativi al prossimo set di modelli di accesso. Per risolvere il modello di accesso 14 (getProductInventoryByWarehouseId), esegui una query su GSI2 con GSI2-PK=warehouseId e GSI2-SK begins_with “p#”.

GSI2:

Per risolvere il modello di accesso 15 (getInvoiceByCustomerIdForDateRange), esegui una query su GSI2 con GSI2-PK=customerId e GSI2-SK between (i#date1, i#date2).

GSI2:

Per risolvere il modello di accesso 16 (getProductsByCustomerIdForDateRange), esegui una query su GSI2 con GSI2-PK=customerId e GSI2-SK between (p#date1, p#date2).

GSI2:

Tutti i modelli di accesso e il modo in cui la progettazione dello schema li affronta sono riassunti nella tabella seguente:

Schema finale del negozio online

Di seguito sono riportate le progettazioni dello schema finale. Per scaricare questo schema come JSON file, consulta DynamoDB Design Patterns su. GitHub

Tabella di base

GSI1

GSI2

Utilizzo di No SQL Workbench con questo schema di progettazione

Puoi importare questo schema finale in No SQL Workbench, uno strumento visivo che fornisce funzionalità di modellazione, visualizzazione dei dati e sviluppo di query per DynamoDB, per esplorare e modificare ulteriormente il tuo nuovo progetto. Per iniziare, segui queste fasi: