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 la progettazione del modello 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

Usando NoSQL Workbench per DynamoDB, importa Onlineshop_1.json per la creazione di un nuovo modello di dati chiamato AnOnlineShope 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 modello 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 OnlineShop_3.json per risolvere il modello di accesso 2 (getProductByProductId) per l’entità 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 risolvere il modello di accesso 3 (getWarehouseByWarehouseId) per l’entità 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 ID alfanumerici 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 risolvere il modello di accesso 4 (getProductInventoryByProductId). L’entità warehouseItem 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 nell'ERD, esiste una relazione molti a molti tra product e warehouse. Ecco, la relazione uno-a-molti da product a warehouse è modellata come warehouseItem. Più tardi, la relazione uno-a-molti da warehouse a product sarà anch’essa modellata.

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 ancora altri elementi customer, product e warehouse alla tabella importando AnOnlineShop_6.json. Quindi, importa AnOnlineShop_7.json per creare una collezione di oggetti per order che può risolvere i modelli di accesso 5 (getOrderDetailsByOrderId) e 6 (getProductByOrderId). Puoi vedere la relazione uno-a-molti 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 OnlineShop_8.json per aggiungere un’entità invoice alla raccolta di elementi dell’ordineper gestire il pattern 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 entità shipment alla raccolta di articoli dell’ordine per 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 i dati orderItem provenienti 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 un GSI dalla tabella al GSI. Non è necessario inserire manualmente inserimenti aggiuntivi nel 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 affrontare 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 affrontare 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 GSI1 di partizione e ordinamento sono già state utilizzate per modellare una relazione uno a molti tra shipment e shipmentItem. 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 la progettazione della nuova relazione uno a molti tra warehouse e shipment per il modello 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 per negozio online

Di seguito sono riportate le progettazioni dello schema finale. Per scaricare questa progettazione dello schema come un file JSON, consulta Esempi di progettazione DynamoDB su GitHub.

Tabella di base

GSI1

GSI2

Utilizzo di NoSQL Workbench con questa progettazione dello schema

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