Tabelle, elementi e chiavi primarie

Amazon DynamoDB è un database chiave-valore e documentale completamente gestito e serverless, progettato per offrire prestazioni nell'ordine dei millisecondi a una cifra a qualsiasi livello di scalabilità. A differenza dei database relazionali, DynamoDB è privo di schema: ogni elemento può avere un insieme diverso di attributi, purché sia presente la chiave primaria.

DynamoDB archivia i dati in tabelle, che sono il contenitore di livello superiore analogo a una tabella SQL. Le tabelle vengono distribuite automaticamente su più nodi di storage in diverse AZ, fornendo ridondanza integrata senza richiedere alcuna configurazione da parte vostra.

Una tabella DynamoDB contiene una raccolta di elementi, ciascuno dei quali è una raccolta di attributi. Gli attributi sono valori tipizzati: String (S), Number (N), Binary (B), Boolean (BOOL), Null (NULL), List (L), Map (M) e i tipi Set (SS, NS, BS).

Ogni elemento di una tabella deve includere gli attributi della chiave primaria; tutti gli altri attributi sono facoltativi e possono differire tra gli elementi. Un singolo elemento può avere una dimensione massima di 400 KB, inclusi tutti i nomi e i valori dei relativi attributi.

Una chiave primaria semplice è costituita da un singolo attributo denominato partition key (detta anche hash key). DynamoDB applica una funzione hash interna al valore della partition key per determinare quale partizione di storage contiene l'elemento. Tutti gli elementi con lo stesso valore di partition key vengono archiviati insieme.

Con una chiave primaria semplice, due elementi della tabella non possono avere lo stesso valore di partition key, che identifica univocamente ogni elemento. Questo modello è adatto alle tabelle in cui i dati vengono sempre recuperati tramite un identificatore univoco, ad esempio un ID utente o un ID ordine.

Una chiave primaria composta utilizza sia una partition key sia una sort key (detta anche range key). Gli elementi con la stessa partition key vengono archiviati insieme e ordinati in base al valore della sort key, consentendo query per intervallo all'interno di una partizione.

Questo modello è estremamente flessibile: più elementi possono condividere la stessa partition key purché le relative sort key siano diverse. Ad esempio, una tabella Orders potrebbe utilizzare CustomerId come partition key e OrderDate come sort key, consentendo di interrogare tutti gli ordini di un cliente ordinati per data.

La scelta della partition key corretta è la decisione di progettazione più importante in DynamoDB. Una buona partition key ha un'elevata cardinalità (molti valori distinti) e distribuisce gli accessi in modo uniforme tra le partizioni. Scelte inadeguate causano hot partition, in cui una partizione riceve una quantità sproporzionata di traffico, provocando il throttling.

Anti-pattern da evitare: utilizzare un flag booleano (solo due valori), una data che raggruppa tutte le scritture odierne o un campo di stato con cardinalità ridotta. Scelte valide: ID utente, ID dispositivo, UUID casuale o valori composti come tenantId#entityType.

Le tre operazioni fondamentali sugli elementi DynamoDB sono:

• PutItem: scrive un nuovo elemento oppure sostituisce completamente un elemento esistente con la stessa chiave primaria
• GetItem: recupera un singolo elemento tramite la relativa chiave primaria esatta (richiede la chiave completa: partition key e, se composta, sort key)
• DeleteItem: rimuove un elemento tramite la relativa chiave primaria esatta

Tutte e tre le operazioni sono atomiche a livello di elemento. Per impostazione predefinita, GetItem utilizza letture eventualmente consistenti; aggiungendo --consistent-read si forza una lettura fortemente consistente, che restituisce sempre il valore scritto più di recente.

UpdateItem modifica attributi specifici di un elemento esistente senza sostituirlo interamente, a differenza di PutItem. È possibile aggiungere o rimuovere attributi oppure eseguire operazioni aritmetiche atomiche sugli attributi di tipo Number (ad esempio, incrementare un contatore).

Le espressioni condizionali consentono di specificare che un'operazione deve riuscire solo se una determinata condizione è vera. Ad esempio, è possibile aggiornare lo stato di un elemento solo se attualmente è PENDING. Questo permette di implementare modelli di locking ottimistico senza transazioni ed è una tecnica fondamentale per la progettazione in DynamoDB.

Query recupera gli elementi che condividono lo stesso valore di partition key, applicando facoltativamente filtri basati su condizioni sulla sort key. Query è efficiente: legge solo la partizione interessata. È possibile utilizzare condizioni sulla sort key come begins_with, between, =, <, > per restringere i risultati all'interno della partizione.

Scan legge ogni elemento della tabella e applica quindi un'espressione di filtro facoltativa. Le scansioni sono costose per le tabelle di grandi dimensioni e dovrebbero essere evitate nei pattern di query in produzione. Se vi trovate a dover utilizzare frequentemente Scan, rivalutate la progettazione della tabella oppure aggiungete un Global Secondary Index.

DynamoDB archivia tre copie dei dati in più AZ. Le letture eventualmente coerenti (impostazione predefinita) possono restituire un valore leggermente obsoleto se una scrittura recente non è ancora stata propagata a tutte le copie, ma consumano la metà delle unità di capacità di lettura rispetto alle letture fortemente coerenti.

Le letture fortemente coerenti restituiscono sempre l'ultima scrittura confermata, ma hanno un costo doppio in RCU e non sono disponibili per i Global Secondary Index. Scelga le letture eventualmente coerenti per carichi di lavoro con molte letture e throughput elevato, e quelle fortemente coerenti solo quando l'applicazione richiede i dati più aggiornati in assoluto.

DynamoDB supporta le transazioni ACID tramite TransactWriteItems e TransactGetItems. Una transazione può raggruppare fino a 100 operazioni di scrittura su più elementi e persino su più tabelle, garantendo che tutte le operazioni abbiano esito positivo oppure vengano annullate atomicamente.

Utilizzi le transazioni in scenari come il trasferimento di denaro tra conti (addebitare un elemento e accreditarne un altro) o la prenotazione di un posto (verificarne la disponibilità e riservarlo atomicamente). Le transazioni costano il doppio delle normali RCU/WCU, quindi le utilizzi solo quando l'atomicità tra più elementi è realmente necessaria.

Il limite di 400 KB per elemento di DynamoDB influenza la modellazione dei dati. Per payload di grandi dimensioni (ad esempio immagini o documenti voluminosi), archivi i dati binari in S3 e salvi in DynamoDB solo la chiave dell'oggetto S3. Per dati gerarchici profondamente annidati, modelli ogni tipo di nodo con un proprio schema di chiave di partizione usando il single-table design: una sola tabella contiene più tipi di entità, distinti dal prefisso della chiave di partizione e dallo schema della chiave di ordinamento.

Il single-table design riduce il numero di tabelle e consente pattern di accesso efficienti collocando elementi correlati nella stessa partizione. È una tecnica avanzata che riduce il sovraccarico operativo e migliora le prestazioni per pattern di accesso complessi.

Verifichi la Sua comprensione dei concetti di AWS Solutions Architect (SAA-C03) trattati in questa lezione.

In questa lezione ha imparato che: le tabelle DynamoDB contengono elementi privi di schema con un limite di 400 KB, le chiavi primarie semplici usano solo una chiave di partizione, mentre le chiavi composite aggiungono una chiave di ordinamento per le query per intervallo, e le chiavi di partizione ad alta cardinalità impediscono la formazione di partizioni sovraccariche. Utilizzi Query invece di Scan per un accesso efficiente. Nella prossima lezione esamineremo le modalità di capacità con provisioning e on-demand.