Capacità On-Demand vs Provisioned in DynamoDB
DynamoDB fattura il throughput in due modi. On-Demand addebita per richiesta — paghi ciò che usi, scalando fino a zero. Provisioned riserva una velocità fissa di lettura/scrittura che paghi che tu la usi o meno, a un prezzo per unità molto più basso. Scegliere quella sbagliata è uno dei modi più facili per pagare troppo.
L'audit log rende la scelta concreta. Le scritture di audit sono irregolari e imprevedibili: silenziose durante la notte, poi un'ondata quando un cliente lancia un'operazione di massa o un incidente genera migliaia di eventi. È proprio quella forma del traffico a determinare tutta la decisione.
Dovrei usare la capacità On-Demand o Provisioned di DynamoDB?
On-Demand addebita per richiesta e scala fino a zero, il che la rende il default sicuro per traffico irregolare, nuovo o imprevedibile. Provisioned riserva una velocità fissa di lettura/scrittura a un prezzo per unità molto più basso, e conviene solo quando un traffico sostenuto e costante mantiene quella prenotazione ben utilizzata. Scegli On-Demand a meno che il tuo volume non sia comprovato e prevedibile.
- On-Demand = paghi per richiesta, scala fino a zero. Nessuna capacità da pianificare; paghi un prezzo più alto per lettura/scrittura ma solo quando il traffico avviene.
- Provisioned = riservi una velocità costante, la paghi sempre. Molto più economica per unità se la velocità è ben utilizzata; ti accolli il costo della capacità inattiva.
- Il traffico irregolare o sconosciuto richiede On-Demand. Il traffico costante, prevedibile e ad alto volume richiede Provisioned (facoltativamente con auto-scaling).
- Puoi cambiare modalità, ma il limite è asimmetrico: da Provisioned a On-Demand è limitato a quattro volte ogni 24 ore, mentre da On-Demand a Provisioned è illimitato — non è un interruttore da azionare a ogni richiesta.
Il problema: pagare per capacità che non usi
Con la capacità Provisioned ti impegni a, poniamo, 1.000 unità di scrittura al secondo. Se l'audit log fa in media 50 scritture/secondo ma hai allocato per il picco del giorno di un incidente, paghi per 1.000 tutto il giorno usandone un ventesimo. Alloca invece per la media e l'ondata del giorno dell'incidente subisce throttling — le scritture vengono rifiutate.
Quindi la capacità fissa impone un cattivo compromesso sul traffico irregolare: pagare troppo di continuo, oppure allocare troppo poco e perdere scritture quando più conta. On-Demand esiste proprio per eliminare questo compromesso.
Come funzionano le due modalità
On-Demand addebita le unità di richiesta di lettura e scrittura che consumi davvero, senza alcuna capacità da configurare — accoglie istantaneamente picchi fino al doppio del tuo precedente picco di traffico e scala fino a zero quando è inattiva. Oltre quel salto 2x entro una breve finestra può comunque applicare throttling mentre si adegua. Paghi un sovrapprezzo per richiesta per quella elasticità.
Provisioned riserva un certo numero di Read Capacity Unit (RCU) e Write Capacity Unit (WCU) al secondo. Il prezzo per unità è molto più basso, ma paghi la prenotazione di continuo, usata o meno. Superala e DynamoDB applica throttling a meno che l'auto-scaling non sia abilitato per far crescere la capacità entro limiti configurati — anche se l'auto-scaling reagisce nell'arco di minuti, quindi un picco improvviso può comunque subire throttling prima che riesca ad adeguarsi.
Il punto di pareggio è l'utilizzo. In breve: se il tuo traffico sostenuto e prevedibile mantiene la capacità Provisioned ben utilizzata, Provisioned vince sul prezzo; se il traffico è irregolare, a raffiche o sconosciuto, On-Demand vince non addebitandoti la prenotazione inattiva.
Un esempio pratico: la bolletta dell'audit log
L'audit log scrive in media ~50 eventi/secondo ma va a raffiche di migliaia durante gli incidenti, con un traffico di lettura molto più basso (export di conformità, la saltuaria indagine). Ogni evento è piccolo — ben sotto 1 KB.
Su Provisioned dovresti riservare per la raffica (pagandola 24 ore su 24) o rischiare di applicare throttling all'ondata del giorno dell'incidente — il momento peggiore per perdere scritture di audit. Su On-Demand, le ore tranquille costano quasi nulla e una raffica fino al doppio del picco recente viene assorbita senza configurazione; paghi esattamente per le scritture avvenute.
Per questo workload On-Demand è il default corretto. La regola generale: parti da On-Demand per qualsiasi tabella nuova o irregolare, e passa a Provisioned solo una volta che il traffico si è dimostrato abbastanza stabile da mantenere una prenotazione utilizzata.
Inserisci i tuoi numeri — letture/scritture al secondo, dimensione dell'item, storage — per vedere le due modalità affiancate per una regione:
Per il quadro completo multi-regione con il free tier applicato, usa il calcolatore dei prezzi di DynamoDB.
Fallo in DynoTable
La decisione sulla capacità parte da numeri reali: quanto sono grandi gli item, quanti sono, quanto velocemente vengono scritti. Tirare a indovinare è il modo in cui le tabelle finiscono mal allocate.
Per trasformare un evento campione nelle RCU/WCU che consuma davvero, fallo passare per il calcolatore della dimensione degli item. Poi ancora la decisione alla tua tabella reale: DynoTable mostra i suoi metadati — numero e dimensione degli item — e ti permette di ispezionare item rappresentativi così da dimensionarli accuratamente.
Insidie e passaggi successivi
- Il cambio di modalità è limitato nel tempo, e in modo asimmetrico. Da Provisioned a On-Demand è limitato a quattro cambi ogni 24 ore; da On-Demand a Provisioned è illimitato. Trattalo come una decisione ponderata, non come una manopola da girare.
- L'auto-scaling non è istantaneo. Reagisce nell'arco di minuti, quindi un picco netto su Provisioned può subire throttling prima che la capacità cresca. Per traffico genuinamente a raffiche, On-Demand gestisce meglio il picco — fino al doppio del tuo precedente picco all'istante. Se sai che un picco supererà quel limite (un lancio o una promozione), imposta in anticipo il warm throughput sulla tabella per pre-allocare il margine per la raffica.
- Una partizione bollente subisce throttling a prescindere dalla modalità. Anche On-Demand ha limiti per partizione — chiavi non uniformi possono causare throttling mentre la tabella sembra sotto capacità. Vedi partizioni bollenti.
- Le hanno la loro capacità. Ogni indice è fatturato separatamente e può causare throttling delle scritture della tabella base se sotto-allocato — vedi perché una GSI causa throttling delle scritture della tabella base.
La modalità di capacità stabilisce quanto paghi per far girare la tabella in una regione. Prossimo passo: replicarla tra regioni con le Global Table di DynamoDB.
Scarica DynoTable per leggere la dimensione reale e il numero di item della tua tabella prima di impegnarti su una modalità di capacità.