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à.
Questo esempio descrive come modellare i dati relazionali in Amazon DynamoDB. Una progettazione di tabella DynamoDB corrisponde allo schema della voce dell'ordine relazionale visualizzato in Modellazione relazionale. Segue l'Modello di progettazione elenchi di adiacenza, che è un modo comune di rappresentare le strutture di dati relazionali in DynamoDB.
Il modello di progettazione richiede che tu definisca un set di tipi di entità che solitamente sono collegati a varie tabelle nello schema relazionale. Le voci di entità vengono aggiunte alla tabella utilizzando una chiave primaria composta (partizione e ordinamento). La chiave di partizione di queste voci di entità è l'attributo che identifica in modo univoco la voce e al quale ci si riferisce solitamente come PK
in tutte le voci. L'attributo di chiave di ordinamento contiene un valore di attributo che puoi utilizzare per un indice invertito o un indice secondario globale. Solitamente viene chiamato SK
.
Definisci le seguenti entità che supportano lo schema della voce dell'ordine relazionale:
-
HR-Employee - PK: EmployeeID, SK: Employee Name
-
HR-Region - PK: RegionID, SK: Region Name
-
HR-Country - PK: CountryId, SK: Nome del Paese
-
HR-Location - PK: LocationID, SK: Country Name
-
HR-Job - PK: JobID, SK: Job Title
-
Dipartimento Risorse Umane - PK: DepartmentID, SK: DepartmentName
-
Cliente OE - PK: CustomerID, SK: ID AccountRep
-
OE-Order - PK OrderID, SK: CustomerID
-
OE-Product - PK: ProductID, SK: Product Name
-
OE-Warehouse - PK: WarehouseID, SK: Region Name
Dopo aver aggiunto queste voci di entità alla tabella, puoi definire le relazioni tra loro aggiungendo voci edge alle partizioni della voce di entità. La tabella seguente dimostra questa fase.

In questo esempio, le partizioni Employee
, Order
e Product
Entity
sulla tabella hanno voci edge addizionali che contengono puntatori ad altre voci di entità sulla tabella. Successivamente, definisci alcuni indici secondari globali (GSIs) per supportare tutti i modelli di accesso definiti in precedenza. Le voci di entità non utilizzano tutte lo stesso tipo di valore per la chiave primaria o l'attributo della chiave di ordinamento. Ciò che è necessario è avere la chiave primaria e gli attributi della chiave di ordinamento presenti per essere inseriti nella tabella.
Il fatto che alcune di queste entità utilizzino nomi propri e altre entità IDs come valori delle chiavi di ordinamento consente allo stesso indice secondario globale di supportare più tipi di query. Questa tecnica è chiamata GSIsovraccarico. In effetti elimina il limite di default di 20 indici secondari globali per le tabelle che contengono più tipi di elementi. Questo è mostrato nel diagramma seguente come GSI 1.

GSI2 è progettato per supportare uno schema di accesso alle applicazioni abbastanza comune, che consiste nell'ottenere tutti gli elementi della tabella che hanno un determinato stato. Per una tabella grande con una distribuzione non uniforme di voci negli stati disponibili, questo modello di accesso può risultare in un tasto di scelta rapida, a meno che le voci siano distribuite su più di una partizione logica sulla quale si può eseguire una query in parallelo. Il modello di progettazione si chiama write sharding
.
Per eseguire questa operazione per GSI 2, l'applicazione aggiunge l'attributo chiave principale GSI 2 a ogni articolo dell'ordine. Lo popola con un numero casuale in un intervallo 0N, dove N può essere calcolato generale utilizzando la formula riportata di seguito (a meno che ci sia una ragione specifica per non farlo).
ItemsPerRCU = 4KB / AvgItemSize PartitionMaxReadRate = 3K * ItemsPerRCU N = MaxRequiredIO / PartitionMaxReadRate
Ad esempio, presumi di aspettarti quanto segue:
-
Fino a due milioni di ordini saranno presenti nel sistema, aumentando fino a tre milioni in cinque anni.
-
Fino al 20 percento di questi ordini sarà in OPEN uno stato in un dato momento.
-
Il record di ordine medio è di circa 100 byte, con tre
OrderItem
record nella partizione degli ordini di circa 50 byte ciascuno, per una dimensione media dell'entità dell'ordine di 250 byte.
Per quella tabella, il calcolo del fattore N sembrerebbe a quanto segue.
ItemsPerRCU = 4KB / 250B = 16 PartitionMaxReadRate = 3K * 16 = 48K N = (0.2 * 3M) / 48K = 13
In questo caso, è necessario distribuire tutti gli ordini su almeno 13 partizioni logiche su GSI 2 per garantire che la lettura di tutti Order
gli articoli con uno OPEN
stato non provochi una partizione calda sul livello di archiviazione fisica. È buona norma aumentare questo numero per permettere anomalie nel set di dati. Quindi un modello che utilizza N = 15
probabilmente va bene. Come accennato in precedenza, è possibile eseguire questa operazione aggiungendo il valore casuale 0—N all'attributo GSI 2 PK di ogni OrderItem
record Order
and inserito nella tabella.
Questa suddivisione presume che il modello di accesso che richiede la raccolta di tutte le fatture OPEN
accada molto raramente permettendoti di utilizzare la capacità di ottimizzazione per soddisfare la richiesta. Puoi eseguire una query sull'indice secondario globale seguente utilizzando una condizione di chiave di ordinamento per State
e Date Range
per produrre un sottoinsieme di tutti gli Orders
in un determinato stato quando necessario.

In questo esempio, le voci sono distribuite casualmente nelle 15 partizioni logiche. Questa struttura funziona perché il modello di accesso richiede un ampio numero di voci da recuperare. Quindi è improbabile che qualsiasi dei 15 thread daranno set di risultati vuoti che potrebbero rappresentare potenzialmente una capacità sprecata. Una query utilizza sempre 1 unità di capacità di lettura (RCU) o 1 unità di capacità di scrittura (WCU), anche se non viene restituito nulla o non viene scritto alcun dato.
Se il modello di accesso richiede una query ad alta velocità in questo indice secondario globale che produce un set di risultati sparse, è probabilmente meglio utilizzare un algoritmo hash per distribuire le voci piuttosto che un modello casuale. In questo caso, è possibile selezionare un attributo conosciuto quando viene eseguita la query al runtime ed eseguire l'hash di quell'attributo in uno spazio di chiave 0-14 quando vengono inseriti gli elementi. Possono poi essere letti in maniera efficace dall'indice secondario globale.
Infine, puoi rivedere i modelli di accesso definiti in precedenza. Di seguito è riportato l'elenco dei modelli di accesso e delle condizioni di query che utilizzerai con la nuova versione DynamoDB dell'applicazione per adattarli.
S. No. | Modelli di accesso | Condizioni di query |
---|---|---|
1 |
Ricerca dei dettagli dei dipendenti tramite ID dipendente |
Chiave primaria sulla tabella, ID="HR-» EMPLOYEE |
2 |
Esecuzione di query sui dettagli dei dipendenti tramite Nome dipendente |
Usa GSI -1, pk="Nome del dipendente» |
3 |
Ottenimento dei soli dettagli del lavoro corrente di un dipendente |
Chiave primaria sulla tabella, PK=HR- EMPLOYEE -1, SK inizia con «JH» |
4 |
Ottenimento di ordini per un cliente per un intervallo di date |
Usa GSI -1, PK=CUSTOMER1, SK=» STATUS - «, per ciascuno DATE StatusCode |
5 |
Mostra tutti gli ordini in corso OPEN per un intervallo di date per tutti i clienti |
Usa GSI -2, pk=Query in parallelo per l'intervallo [0.. N], SK tra OPEN -Date1 e -Date2 OPEN |
6 |
Tutti i dipendenti assunti di recente |
Usa GSI -1, PK="HR- ', SK > date1 CONFIDENTIAL |
7 |
Trova tutti i dipendenti in un magazzino specifico |
Usa GSI -1, PK= WAREHOUSE1 |
8 |
Ottenimento di tutti gli Orderitems per un prodotto, inclusi gli inventari della posizione del magazzino |
Usa GSI -1, PK= PRODUCT1 |
9 |
Ottenimento dei clienti per rappresentante account |
Usa GSI -1, ACCOUNT PK= - REP |
10 |
Ottenimento di ordini per rappresentante account e data |
Usa GSI -1, PK= ACCOUNT -REP, SK=» STATUS - DATE «, per ogni StatusCode |
11 |
Ottenimento di tutti i dipendenti con una mansione specifica |
Usa GSI -1, PK= JOBTITLE |
12 |
Ottenimento dell'inventario per prodotto e magazzino |
Chiave primaria sulla tabella, PK=OE-, SK= PRODUCT1 PRODUCT1 |
13 |
Ottenimento dell'inventario totale dei prodotti |
Chiave primaria sulla tabella, PK=OE-, SK= PRODUCT1 PRODUCT1 |
14 |
Ottenimento dei rappresentanti dell'account classificati in base al totale degli ordini e al periodo di vendita |
Usa GSI -1, PK= -Q1, YYYY =False scanIndexForward |