Il limite di dimensione dell'item in DynamoDB (400 KB)

Un singolo item DynamoDB può contenere al massimo 400 KB di dati. Arrivando da MongoDB (documenti da 16 MB) o da una riga relazionale senza un limite pratico, quel tetto sembra basso — e tendi a scoprirlo nel modo più duro, quando una scrittura che ha funzionato per mesi all'improvviso fallisce con una ValidationException perché un item è finalmente cresciuto troppo.

Il limite non è arbitrario, e non è una quota che puoi alzare. È un vincolo di modellazione, e gli item che lo raggiungono di solito ti stanno dicendo che i dati sono stati modellati male.

Qual è la dimensione massima di un item in DynamoDB?

DynamoDB limita un singolo item a 400 KB — un limite rigido che non puoi alzare. La dimensione conta insieme i nomi degli attributi e i valori, inclusi tutti gli elementi annidati di liste, mappe e set. Di solito gli item lo raggiungono per una crescita illimitata, come una lista incorporata che si espande all'infinito; la soluzione è la modellazione, suddividere la collezione in item separati, non la compressione.

• 400 KB per item, limite rigido. Non regolabile, non una quota flessibile.
• Dimensione = nomi degli attributi + valori, insieme. I nomi lunghi degli attributi contano, su ogni item.
• Anche annidamento e set contano. Liste, mappe e i loro valori annidati si sommano tutti.
• La causa abituale è la crescita illimitata — incorporare in un item padre una lista che cresce senza limite.
• La soluzione è la modellazione, non la compressione. Suddividi la collezione in crescita nei suoi item sotto una partition key condivisa.

Il problema: l'item che cresce all'infinito

Diciamo che tieni traccia di una flotta di veicoli, e decidi di memorizzare le letture di telemetria di ogni veicolo come una lista nell'item del veicolo:

PK: VEHICLE#A1   readings: [ {ts, lat, lng, fuel}, {ts, lat, lng, fuel}, ... ]

Per un giorno o due va bene. Ma le letture arrivano ogni pochi secondi e non si fermano mai, quindi la lista cresce senza limite. Alla fine un singolo item veicolo supera i 400 KB e ogni scrittura su di esso fallisce — non puoi più registrare alcuna telemetria per quel veicolo, perché ogni aggiornamento riscrive l'intero item (ormai sovradimensionato).

Il bug non è il limite di dimensione. È modellare una relazione uno-a-molti illimitata come una lista incorporata. Funziona solo quando il lato "molti" è limitato e piccolo.

Cosa conta davvero ai fini dei 400 KB

DynamoDB misura la dimensione totale dell'item come la somma di:

• Ogni nome di attributo, codificato in UTF-8. Un nome di 20 caratteri ripetuto su milioni di item è sia dimensione che storage che paghi — ecco perché i modellatori esperti tengono corti i nomi degli attributi.
• Ogni valore di attributo. Stringhe e binari per la loro lunghezza in byte; i numeri con una codifica compatta; booleani e null con un piccolo costo fisso.
• La struttura annidata. Una lista o una mappa conta il proprio overhead più la dimensione di ogni elemento e chiave al suo interno, fino in fondo.

Non c'è un limite separato per-attributo da pianificare — è l'intero item contro la soglia dei 400 KB. Le quote di servizio AWS specificano l'esatto conteggio dei byte.

Perché il limite esiste

Gli item grandi sono costosi da spostare. Le letture DynamoDB sono misurate in unità da 4 KB, quindi un item da 400 KB costa 100 RCU per essere letto in modo forte — e letture, scritture e replica diventano tutte più lente e costose man mano che gli item crescono. Il limite ti spinge verso item piccoli e mirati e lontano dall'anti-pattern "recupera un unico blob gigante" che i principianti di NoSQL adottano per abitudine relazionale.

Modellare per aggirarlo

Per l'esempio della flotta, smetti di incorporare. Dai a ogni lettura il proprio item nella stessa partizione del veicolo, ordinato per timestamp sulla sort key:

PK: VEHICLE#A1   SK: READING#2026-06-27T10:00:05Z   lat, lng, fuel
PK: VEHICLE#A1   SK: READING#2026-06-27T10:00:10Z   lat, lng, fuel

Ora nessun singolo item cresce, le scritture non superano mai il limite, e una singola Query su VEHICLE#A1 recupera comunque le letture di un veicolo come un'unica item collection ordinata. Le sotto-liste limitate (una manciata di tag, un blocco di config fisso) vanno bene da incorporare; quelle illimitate diventano item.

Verificare la dimensione dell'item in DynoTable

Prima di impegnarti su una forma, pesa un item rappresentativo. In DynoTable, aprilo nella Quick View e vedrai la dimensione in byte dell'item accanto ai suoi attributi — così intercetti una forma troppo pesante mentre stai esplorando dati reali, in fase di progettazione invece che alla scrittura fallita.

Preferisci restare nel browser? Il Calcolatore di dimensione degli Item DynamoDB fa la stessa cosa a partire da un campione incollato, riportando gli esatti KB e le RCU/WCU che ogni lettura e scrittura costerà.

Trappole e prossimi passi

• Attenzione alle liste incorporate che crescono con il traffico — sono la classica bomba a orologeria dei 400 KB. Limitale o suddividile.
• Accorcia i nomi degli attributi sugli item ad alta cardinalità — è dimensione e storage recuperati gratis.
• I valori grandi vanno in S3. Memorizza i blob grandi (immagini, documenti) in S3 e tieni solo la chiave sull'item.
• Correlati: denormalizzazione e relazioni uno-a-molti coprono quando incorporare vs suddividere.

Vuoi vedere a colpo d'occhio le dimensioni reali degli item in una tabella? Scarica DynoTable e ispeziona i tuoi dati direttamente.