Throughput on-demand di DynamoDB: misurato
Quanto throughput ottiene una nuova tabella on-demand di DynamoDB?
Una tabella appena creata serve circa 4.130 scritture al secondo — AWS ne documenta 4.000 — e almeno 12.700 letture eventualmente coerenti al secondo. Abbiamo misurato entrambe il 2026-08-27 contro una tabella creata pochi minuti prima: le scritture si sono fissate a 4.130 ±2/s per ogni carico oltre la baseline che abbiamo offerto, e le letture non sono mai state limitate prima che il nostro stesso generatore di carico esaurisse il margine.
Questi due numeri, e tutto il resto in questa pagina, vengono dal contare richieste reali contro il servizio live — non dal ripetere la documentazione. Il metodo, i dati grezzi e i tre tentativi falliti sono descritti in la storia del benchmark; questa pagina è il riferimento su cui vivono i numeri.
Il tetto di scrittura su una tabella nuova
Il carico offerto è salito in finestre da 30 secondi contro una tabella che non aveva mai visto traffico. Ogni richiesta portava un item di ~1 KB con una chiave uniformemente casuale — nessun coinvolto:
| Offerto (scritture/s) | Ottenuto | Richieste limitate |
|---|---|---|
| 1.000 | 1.000 | 0 |
| 2.000 | 2.000 | 0 |
| 3.000 | 3.000 | 0 |
| 4.000 | 4.000 | 0 |
| 5.000 | 4.132 | 25.992 |
| 6.000 | 4.131 | 55.966 |
| 8.000 | 4.134 | 115.922 |
La baseline documentata di 4.000 scritture/s regge, con circa il 3% di margine sopra di essa. Il tetto è notevolmente piatto: 4.132, 4.131, 4.134 ottenute al secondo a 5.000, 6.000 e 8.000 offerte. La latenza non si degrada quando lo superi — la latenza di scrittura p50 è rimasta a 4–5 ms in-regione in ogni finestra. Il servizio non rallenta; rifiuta.
Cosa restituisce davvero la limitazione
Il primo rifiuto è arrivato 0,9–3,8 secondi dentro ogni finestra oltre la baseline (più alto il tasso offerto, più presto è arrivato). Testuale:
ThrottlingException: Throughput exceeds the current capacity of your table or index. DynamoDB is automatically scaling your table or index so please try again shortly. If exceptions persist, check if you have a hot key: https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/bp-partition-key-design.htmlDue cose da tenere a mente. È un HTTP 400, non un 5xx — una policy di retry o un alert che osserva solo i 5xx si perderà del tutto la limitazione on-demand (gli SDK la ritentano per impostazione predefinita; vedi ). E il suggerimento sulla hot key è un'ipotesi predefinita, non una diagnosi — le nostre chiavi erano uniformemente casuali, quindi su piccola scala il primo sospettato per questo messaggio è il tetto a livello di tabella, non il tuo schema di chiavi. Le quattro cause distinte di limitazione hanno una propria guida.
Il tetto di lettura
Le letture sono state eseguite contro una seconda tabella nuova seminata con
1.000 item, come GetItem (~1 KB, 0,5 unità di
lettura ciascuno):
| Offerto (letture/s) | Ottenuto | Richieste limitate |
|---|---|---|
| 4.000 | 4.000 | 0 |
| 8.000 | 7.941 | 0 |
| 12.000 | 11.119 | 0 |
| 16.000 | 12.762 | 0 |
Zero limitazioni a ogni tasso. La baseline documentata di 12.000 letture/s regge, e non siamo riusciti a trovare il suo confine reale: a 16.000/s offerte, cinque dei nostri otto runner hanno saturato lato client, quindi 12.762/s è dove la nostra flotta si è fermata — non dove si è fermato DynamoDB. Le letture hanno risposto a 2–4 ms p50 in-regione.
Come cresce il tetto sotto carico sostenuto
AWS documenta che la capacità on-demand cresce per assorbire fino al doppio del picco precedente, e che superare il doppio del picco precedente entro 30 minuti può causare limitazioni. Abbiamo mantenuto 8.000 scritture/s di carico offerto contro una tabella per 34 minuti consecutivi (quattro ondate da 8 minuti con meno di un minuto di pausa tra loro) e osservato il tetto muoversi, minuto per minuto:
| Ondata | Iniziata | Scritture/s ottenute, minuto per minuto |
|---|---|---|
| 1 | 06:06 UTC | 4.019 → 4.001 → 4.001 → 3.999 → 3.998 → 4.000 → 4.000 → 4.000 |
| 2 | 06:15 UTC | 5.046 → 5.000 → 4.996 → 4.990 → 4.991 → 4.998 → 4.992 → 4.993 |
| 3 | 06:24 UTC | 5.046 → 4.973 → 4.991 → 4.981 → 4.983 → 4.989 → 4.993 → 5.978 |
| 4 | 06:32 UTC | 7.006 → 6.991 → 6.979 → 6.996 → 6.991 → 6.988 → 7.002 → 6.990 |
Leggendo la timeline:
- Il primo tetto è appiccicoso. Per l'intero primi 8 minuti la tabella si è mantenuta alla sua baseline di ~4.000/s — la domanda sostenuta oltre la baseline non l'ha spostata entro quella finestra.
- La crescita arriva in gradini di ~1.000/s, non una rampa. Il tetto è salito a un gradino di ~5.000/s intorno al minuto 9, ~6.000/s intorno al minuto 26, e ~7.000/s un minuto dopo, poi si è mantenuto piatto a 7.000/s fino alla fine. Ogni gradino arriva bruscamente da un minuto all'altro. Due dei tre gradini sono caduti vicino ai confini delle nostre ondate, quindi le pause sotto il minuto potrebbero interagire con il meccanismo di crescita — riportiamo la tempistica come osservata.
- Mezz'ora di domanda sostenuta non ha raddoppiato il tetto. Dopo 34 minuti a 8.000/s offerte, la tabella ha servito 7.000/s — 1,75× il suo tetto di partenza, ancora sotto sia il tasso offerto sia un raddoppio netto. Le richieste limitate sono calate ondata dopo ondata (1,9M → 0,5M) man mano che la capacità cresceva.
Se il traffico del tuo giorno di lancio supererà ~4.000 scritture/s su una tabella nuova, pre-riscaldala: o guida carico sintetico prima dell'evento, o imposta esplicitamente il throughput massimo on-demand della tabella e lascia che AWS lo metta in provisioning. La guida on-demand contro con provisioning copre quando vince ciascuna modalità, e l'auto scaling è la controparte in modalità con provisioning di ciò che hai visto succedere automaticamente qui.
Due numeri che ci hanno sorpreso
- Il tempo da create ad ACTIVE varia di 3×. Una tabella on-demand nuova
ha raggiunto
ACTIVEin 7,4 secondi in un'esecuzione e 22 secondi in altre due, stessa regione, stesso schema. Preventiva per il caso lento in qualsiasi progetto tabella-per-tenant o tabella-per-test. - L'intero benchmark è costato $0,97. 672.116 scritture fatturate e 1,08 milioni di letture. L'esecuzione di crescita sostenuta da 34 minuti è costata $12,67 in più. Misurare il servizio da soli costa meno di una sola decisione di capacità sbagliata — e puoi calcolare il prezzo di un carico come questo in anticipo con il calcolatore dei prezzi DynamoDB.
Ambito e metodo, onestamente
Tutto quanto sopra è una tabella per fase, un giorno, una regione (us-east-1), item di ~1 KB, chiavi uniformemente casuali. I limiti per partizione (3.000 unità di lettura / 1.000 unità di scrittura al secondo) stanno sotto il comportamento a livello di tabella misurato qui e hanno le proprie modalità di fallimento. Le quote a livello di account e i limiti rigidi del servizio sono nel riferimento ai limiti DynamoDB, misurati nello stesso modo. E se lavori con DynamoDB ogni giorno, DynoTable è il nostro client desktop per questo — costruito dallo stesso team, con la stessa abitudine di verificare le affermazioni contro il servizio live prima di ripeterle.