Azioni basate su DynamoDB Item

API di DynamoDB si divide in tre famiglie: azioni basate su oggetti che funzionano su un singolo elemento tramite la sua chiave primaria, Query che legge un intervallo all'interno di una partizione e Scan che legge tutto. Questa guida è la prima famiglia: le quattro operazioni usi di più: GetItem, PutItem, UpdateItem, DeleteItem. Sono i più economici, chiamate più veloci offerte da DynamoDB e ottenere le giuste distinzioni (in particolare Put vs Update) previene una serie di bug di perdita accidentale dei dati.

Quali sono le operazioni basate sugli articoli di DynamoDB?

Le operazioni basate sugli elementi di DynamoDB sono le quattro chiamate che agiscono su un singolo elemento tramite la sua chiave primaria completa: GetItem lo legge, PutItem lo crea o lo sostituisce completamente, UpdateItem modifica attributi specifici sul posto e DeleteItem lo rimuove. Ciascuno indirizza esattamente un elemento, rendendoli le chiamate più veloci ed economiche, a differenza di Query e Scan, che ne leggono molti.

• GetItem: legge un elemento tramite la sua chiave primaria completa.
• PutItem: crea o sostituisci completamente un articolo.
• UpdateItem: crea o modifica attributi specifici di un articolo in atto.
• DeleteItem: rimuove un elemento tramite la sua chiave primaria completa.
• Tutti e quattro richiedono la chiave primaria completa (chiave di partizione, più chiave di ordinamento se il file la tabella ne ha uno) — riguardano esattamente un elemento.
• PutItem sovrascrive l'intero elemento; UpdateItem è chirurgico: confonderli lo è come gli attributi scompaiono silenziosamente.

Il tratto distintivo: un oggetto, chiave completa

Ogni azione basata su un elemento prende di mira un singolo elemento tramite la sua chiave primaria completa. Questo è cosa li rende veloci ed economici: DynamoDB esegue l'hashing della chiave di partizione e va direttamente al file oggetto, fatto. Nessun filtraggio, nessuna scansione. Se non conosci la chiave completa, questi non sono i file strumento giusto; ecco a cosa servono Query e Scan.

Supponiamo che tu utilizzi account utente con chiave USER#<id>:

PK: USER#204   email, displayName, plan, createdAt

• GetItem su USER#204 → quell'utente, direttamente.
• DeleteItem su USER#204 → rimuove quell'utente.

Entrambi hanno bisogno della chiave esatta. Nessuna chiave, nessuna azione basata sugli elementi.

PutItem vs UpdateItem: quello che morde

Questa è la distinzione che vale la pena interiorizzare:

• PutItem scrive l'intero elemento. Se USER#204 esiste già e tu PutItem con solo {email, displayName}, gli attributi plan e createdAt esistenti lo sono gone — un put sostituisce l'intero elemento, non si unisce.
• UpdateItem cambia solo il nome che dai. UpdateItem con a SET email = … lascia ogni altro attributo intatto e crea l'elemento se non esistesse (un upsert).

Regola pratica: raggiungere UpdateItem per modificare un elemento esistente e utilizzare PutItem solo quando intendi veramente "scrivi questo elemento come il nuovo stato completo". Entrambi PutItem e UpdateItem accettano a espressione condizionale in modo da poter effettuare la scrittura condizionale ("solo se non esiste già").

Azioni basate su Item in DynoTable

Vuoi che dietro queste azioni ci siano le chiamate API grezze? Assemblare le espressioni e il valore digitato mappe nel costruttore di espressioni DynamoDB e converti un elemento JSON semplice nel formato digitato di API con il file Convertitore DynamoDB JSON.

In DynoTable, lo stesso lavoro è visivo: apri un elemento nella griglia per leggerlo (a GetItem), modificare attributi e commit (un UpdateItem), aggiungere o sostituire una riga (a PutItem) o eliminarne uno, un elemento alla volta.

Insidie + passaggi successivi

• PutItem sostituisce l'intero elemento — per modificare alcuni campi senza perdere il file resto, usa UpdateItem.
• Devi conoscere la chiave primaria completa: nessuna chiave significa Query/Scan, non un'azione di un elemento.
• Molti elementi contemporaneamente? Non ripeterli uno per uno — operazioni batch raggruppale in meno viaggi di andata e ritorno.
• È necessario ripristinare il vecchio valore /new? Imposta ReturnValues invece di un GetItem successivo.
• Correlato: query vs scan copre il lato read-many.

Vuoi leggere, scrivere ed eliminare elementi senza scrivere una riga di codice API? Scarica DynoTable e lavora direttamente con le tue tabelle.

Costo: un articolo, un salto

Le letture basate su Item rappresentano l'accesso indirizzabile più economico in DynamoDB. Un GetItem acceso una riga da 2 KB consuma 1 RCU eventualmente consistente (un blocco da 4 KB, arrotondato in alto). Un Query che restituisce la stessa riga perché conoscevi la chiave di partizione e sort key costa la stessa capacità, ma se conosci solo la chiave di partizione e filter nel codice dell'applicazione, paghi per ogni elemento nella partizione.

Incolla un elemento rappresentativo nel file calcolatore delle dimensioni dell'articolo, quindi moltiplicare per richieste al secondo nel calcolatore dei prezzi quando utilizza un percorso caldo GetItem in loop rispetto a un Query ben codificato.

Espressioni di condizioni sulle scritture

Sia PutItem che UpdateItem accettano optional espressioni di condizione. Modelli tipici:

• attribute_not_exists(pk) on put: inserimento di sola creazione senza gara.
• attribute_exists(pk) in aggiornamento: rifiuta di creare uno stub accidentalmente.
• plan = :old in aggiornamento: concorrenza ottimistica; riprova se un altro scrittore prima ha cambiato il piano.

Anche DeleteItem supporta le condizioni: elimina solo se status = :closed, per esempio. Le condizioni non aggiungono un costo di lettura separato; DynamoDB li valuta contro l'elemento memorizzato durante il tentativo di scrittura.

Costruisci visivamente le condizioni nel file Costruttore di espressioni DynamoDB; copia il ConditionExpression più ExpressionAttributeNames e ExpressionAttributeValues nella tua chiamata SDK.

Idempotenza e sicurezza di sovrascrittura

PutItem senza condizione è l'ultimo scrittore che vince sull'intero articolo. Per webhook gestori o consumatori SQS, accoppia i put con attribute_not_exists su un elaborato attributo marker o utilizzare UpdateItem con SET processed = :true protetto da attribute_not_exists(processed).

Quando sono necessari i valori degli attributi precedenti per un registro di controllo, aggiungere ReturnValues invece sullo stesso UpdateItem di un GetItem precedente: un viaggio di andata e ritorno, nessuna corsa read/write.

Scegliere l'azione giusta per l'oggetto

La gestione temporanea scrive in DynoTable

DynoTable mette in scena UpdateItem e PutItem localmente prima del commit. Tu recensisci attributo diff, esegui controlli PartiQL opzionali, quindi esegui il commit, che si associa a chiamate API reali sopra. La riga in blocco elimina il batch in BatchWriteItem nascosto con nuovo tentativo su articoli non lavorati.

Per la generazione del codice SDK, assemblare le clausole di aggiornamento nel file costruttore di espressioni e incolla il file emesso Snippet SDK v3 accanto ai test del gestore.