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à.

Esempio di modellazione dei dati relazionali in DynamoDB

Questo esempio descrive come modellare i dati relazionali in Amazon DynamoDB. Il design della tabella DynamoDB corrisponde allo schema di immissione dell'ordine relazionale mostrato in. Modellazione relazionale Questo design utilizza più tabelle specializzate anziché un unico elenco di adiacenze, fornendo confini operativi chiari e sfruttando la strategia GSIs per servire tutti i modelli di accesso in modo efficiente.

L'approccio progettuale utilizza principi orientati agli aggregati, raggruppando i dati in base a modelli di accesso anziché a rigidi confini di entità. Le principali decisioni di progettazione includono l'utilizzo di tabelle separate per entità con bassa correlazione di accesso, l'incorporamento dei dati correlati quando vi si accede sempre insieme e l'utilizzo di raccolte di elementi per identificare le relazioni.

Le tabelle seguenti e i relativi indici supportano lo schema di immissione dell'ordine relazionale:

Progettazione della tabella dei dipendenti

La tabella Employee memorizza le informazioni sui dipendenti come un'unica entità per articolo, è ottimizzata per le ricerche dirette dei dipendenti e supporta più modelli di query tramite Strategic GSIs. Questa tabella illustra il principio della progettazione di tabelle separate per entità con caratteristiche operative indipendenti e una bassa correlazione di accesso tra le entità.

La tabella utilizza una semplice chiave di partizione (employee_id) senza una chiave di ordinamento, poiché ogni dipendente è un'entità distinta. Quattro GSIs consentono l'esecuzione efficiente di interrogazioni in base a diversi attributi:

Design della tabella dei clienti

La tabella Clienti conserva le informazioni sui clienti con la denormalizzazione strategica di account_rep_id per consentire interrogazioni efficienti sui rappresentanti degli account. Questa scelta progettuale sostituisce un leggero sovraccarico di archiviazione con le prestazioni delle query, eliminando la necessità di unire i dati del cliente e del rappresentante dell'account.

La tabella supporta più numeri di telefono per cliente utilizzando un attributo list, a dimostrazione della flessibilità dello schema di DynamoDB. Il singolo GSI consente flussi di lavoro rappresentativi degli account:

Ordina Table Design

La tabella Order utilizza il partizionamento verticale con elementi separati per le intestazioni degli ordini e gli articoli degli ordini. Questo design consente di eseguire interrogazioni efficienti basate sui prodotti, mantenendo al contempo tutti i componenti dell'ordine all'interno della stessa partizione per un accesso efficiente. Ogni ordine è composto da più articoli:

La tabella include la denormalizzazione strategica di account_rep_id (duplicata dalla tabella Customer) per consentire interrogazioni dirette ai rappresentanti dell'account senza richiedere ricerche da parte dei clienti. Per scenari di scrittura ad alta produttività, gli ordini OPEN includono attributi status e shard per consentire lo sharding di scrittura su più partizioni.

Quattro GSIs supportano diversi modelli di interrogazione con proiezioni ottimizzate:

Design della tabella del prodotto

La tabella dei prodotti utilizza lo schema di raccolta degli articoli per archiviare sia i metadati dei prodotti che i dati di inventario all'interno della stessa partizione. Questo design sfrutta la relazione identificativa tra prodotti e inventario: l'inventario non può esistere senza un prodotto principale. L'utilizzo di pk=product_ID con sk=Product_ID per i metadati dei prodotti e sk=Warehouse_ID per gli articoli di inventario elimina la necessità di una tabella di inventario e di un GSI separati, riducendo i costi di circa il 50%.

Questo modello consente di eseguire query efficienti sia per il singolo inventario di magazzino (GetItem con chiave composita) che per tutto l'inventario di magazzino per un prodotto (interrogazione sulla chiave di partizione). L'attributo total_inventory nell'elemento dei metadati del prodotto fornisce un'aggregazione denormalizzata per ricerche rapide dell'inventario totale.

Ogni tabella è progettata con specifici Global Secondary Indexes (GSIs) per supportare in modo efficiente i modelli di accesso richiesti. Il design utilizza principi orientati agli aggregati con denormalizzazione strategica e indicizzazione sparsa per ottimizzare sia le prestazioni che i costi.

Le principali ottimizzazioni progettuali includono:

Infine, puoi rivedere i modelli di accesso definiti in precedenza. La tabella seguente mostra come ogni modello di accesso viene supportato in modo efficiente utilizzando il design multitavolo con strategic. GSIs Ogni modello utilizza ricerche chiave dirette o singole query GSI, evitando scansioni costose e garantendo prestazioni costanti su qualsiasi scala.