Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# Capacità di throughput di DynamoDB
In questa sezione viene fornita una panoramica delle due modalità di throughput disponibili per le tabelle DynamoDB e alcune considerazioni sulla selezione della modalità di capacità appropriata per la propria applicazione. La modalità di throughput di una tabella determina come viene gestita la capacità della stessa. La modalità throughput determina anche il modo in cui ti vengono addebitate le operazioni di lettura e scrittura sulle tabelle. In Amazon DynamoDB, è possibile scegliere tra la **modalità on demand** e la **modalità con provisioning** per le proprie tabelle per soddisfare diversi requisiti di carico di lavoro.
**Topics**
+ [
## Modalità on demand
](#capacity-mode-on-demand)
+ [
## Modalità provisioning
](#capacity-mode-provisioned)
+ [
# Modalità di capacità on demand di DynamoDB
](on-demand-capacity-mode.md)
+ [
# Modalità con capacità allocata di DynamoDB
](provisioned-capacity-mode.md)
+ [
# Funzionamento del throughput di DynamoDB
](warm-throughput.md)
+ [
# Capacità di espansione e capacità adattiva di DynamoDB
](burst-adaptive-capacity.md)
+ [
# Considerazioni sul passaggio tra modalità di capacità in DynamoDB
](bp-switching-capacity-modes.md)
## Modalità on demand
La modalità on demand di Amazon DynamoDB è un’opzione di throughput serverless che semplifica la gestione dei database e scala automaticamente per supportare le applicazioni con più requisiti dei clienti. DynamoDB on demand consente di creare una tabella senza preoccuparsi della pianificazione della capacità, del monitoraggio dell’utilizzo e della configurazione delle policy di dimensionamento. DynamoDB on-demand pay-per-request offre prezzi per le richieste di lettura e scrittura in modo da pagare solo per ciò che si utilizza. Per le tabelle in modalità on demand, non è necessario specificare la velocità effettiva di lettura e scrittura che si prevede l'applicazione esegua.
La modalità on demand è l’opzione di throughput predefinita e consigliata per la maggior parte dei carichi di lavoro DynamoDB. DynamoDB gestisce tutti gli aspetti della gestione e del dimensionamento del throughput per supportare carichi di lavoro che possono iniziare con dimensioni ridotte e scalare fino a milioni di richieste al secondo. È possibile leggere e scrivere sulle tabelle DynamoDB secondo necessità senza gestire la capacità di throughput sulla tabella. Per ulteriori informazioni, consulta [Modalità di capacità on demand di DynamoDB](on-demand-capacity-mode.md).
## Modalità provisioning
Nella modalità con provisioning è necessario specificare il numero di letture e scritture di dati al secondo richieste per l’applicazione. L’addebito avverrà in base alla capacità oraria di lettura e scrittura allocata, non alla quantità di quella capacità allocata effettivamente utilizzata. Ciò consente di regolare l'utilizzo di DynamoDB in modo tale da rimanere entro il tasso di richiesta definito, al fine di ottenere la prevedibilità dei costi.
È possibile scegliere di utilizzare la capacità allocata se si dispone di carichi di lavoro costanti con una crescita prevedibile e se è possibile prevedere in modo affidabile i requisiti di capacità per l’applicazione. Per ulteriori informazioni, consulta [Modalità con capacità allocata di DynamoDB](provisioned-capacity-mode.md).
# Modalità di capacità on demand di DynamoDB
Amazon DynamoDB on demand offre un’esperienza di database davvero serverless che scala automaticamente per soddisfare i carichi di lavoro più impegnativi senza dover pianificare la capacità. L’approccio on demand semplifica il processo di configurazione, elimina la gestione e il monitoraggio della capacità e offre un dimensionamento rapido e automatico. Per quanto riguarda pay-per-request i prezzi, non devi preoccuparti della capacità inattiva perché paghi solo per il throughput effettivamente utilizzato. La fatturazione viene effettuata in base alle richieste di lettura o scrittura, quindi i costi riflettono direttamente l’utilizzo effettivo.
Se si sceglie la modalità on demand, DynamoDB adatta istantaneamente i carichi di lavoro, siano essi aumentati o diminuiti, su qualsiasi livello di traffico raggiunto in precedenza. Se il livello di traffico di un carico di lavoro raggiunge un nuovo picco, DynamoDB scala automaticamente per soddisfare i requisiti di throughput aumentati. La modalità on demand è l’opzione di throughput predefinita e consigliata perché semplifica la creazione di applicazioni moderne serverless che possono iniziare in piccolo e scalare fino a milioni di richieste al secondo. Una volta aumentata orizzontalmente la tabella on demand, in futuro è possibile ripristinare istantaneamente lo stesso throughput senza limitazione (della larghezza di banda della rete). Se il traffico verso la tabella è pari a zero, con l’opzione on demand non viene addebitato alcun costo per il throughput. Per ulteriori informazioni sulle proprietà di dimensionamento della modalità on demand, consulta [Throughput e proprietà di dimensionamento](#on-demand-capacity-mode-initial).
Le tabelle che utilizzano la modalità on demand offrono la stessa latenza di pochi millisecondi, lo stesso accordo sul livello di servizio (SLA) e la stessa sicurezza offerta da DynamoDB in modalità con provisioning.
**Nota**
Per impostazione predefinita, DynamoDB protegge da un utilizzo indesiderato e incontrollato. Per scalare i limiti di throughput di lettura e scrittura a livello di tabella di 40.000 per tutte le tabelle dell’account, è possibile richiedere un aumento di questa quota. Le richieste di throughput che superano la quota di throughput predefinito della tabella sono sottoposte a limitazione (della larghezza di banda della rete). Per ulteriori informazioni, consulta [Quote predefinite della velocità di trasmissione effettiva](ServiceQuotas.md#default-limits-throughput).
Facoltativamente, è possibile anche configurare il throughput massimo di lettura o scrittura (o entrambe) al secondo per singole tabelle on demand e singoli indici secondari globali. Configurando il throughput, è possibile mantenere limitati l’utilizzo e i costi a livello di tabella, proteggersi da un aumento involontario delle risorse utilizzate ed evitare un uso eccessivo per una gestione prevedibile dei costi. Le richieste di throughput che superano il throughput massimo della tabella sono sottoposte a limitazione (della larghezza di banda della rete). È possibile modificare il throughput massimo specifico della tabella in qualsiasi momento in base ai requisiti dell’applicazione. Per ulteriori informazioni, consulta [Throughput massimo di DynamoDB per le tabelle on demand](on-demand-capacity-mode-max-throughput.md).
Per iniziare a utilizzare la modalità on demand, è possibile creare o aggiornare una tabella. Per ulteriori informazioni, consulta [Operazioni di base sulle tabelle DynamoDB](WorkingWithTables.Basics.md).
È possibile cambiare le tabelle dalla modalità con capacità allocata alla modalità on demand fino a quattro volte in una finestra variabile di 24 ore. È possibile passare le tabelle dalla modalità on demand alla modalità con capacità allocata in qualsiasi momento.
Per ulteriori informazioni sul passaggio dalla modalità di capacità di lettura a quella di scrittura, consulta [Considerazioni sul passaggio tra modalità di capacità in DynamoDB](bp-switching-capacity-modes.md). Per le quote delle tabelle on demand, consulta [Throughput di lettura/scrittura](ServiceQuotas.md#default-limits-throughput-capacity-modes).
**Topics**
+ [
## Unità di richiesta di lettura e unità di richiesta di scrittura
](#read-write-request-units)
+ [
## Throughput e proprietà di dimensionamento
](#on-demand-capacity-mode-initial)
+ [
# Throughput massimo di DynamoDB per le tabelle on demand
](on-demand-capacity-mode-max-throughput.md)
## Unità di richiesta di lettura e unità di richiesta di scrittura
DynamoDB addebita le letture e le scritture eseguite dall’applicazione sulle tabelle in termini di *unità di richiesta di lettura* e *unità di richiesta di scrittura*.
Un’*unità di richiesta di lettura* rappresenta un’operazione a elevata consistenza di lettura al secondo o due operazioni di lettura a coerenza finale al secondo per un elemento di dimensioni fino a 4 KB. Per ulteriori informazioni sui modelli di consistenza di lettura di DynamoDB, consulta [Coerenza di lettura di DynamoDB](HowItWorks.ReadConsistency.md).
Un’*unità di richiesta di scrittura* rappresenta un’operazione di scrittura per un elemento di dimensioni fino a 1 KB.
Per ulteriori informazioni su come vengono utilizzate le unità di lettura e scrittura, consulta [Operazioni di lettura e scrittura di DynamoDB](read-write-operations.md).
## Throughput e proprietà di dimensionamento
Le tabelle DynamoDB che utilizzano la modalità di capacità on demand adattano automaticamente il volume di traffico dell'applicazione. Le nuove tabelle on demand saranno in grado di supportare fino a 4.000 scritture al secondo e 12.000 letture al secondo. La modalità di capacità on demand adatta automaticamente fino al doppio del precedente picco di traffico su una tabella. Ad esempio, si supponga che lo schema di traffico dell’applicazione vari tra 25.000 e 50.000 operazioni a elevata consistenza di lettura. Il picco di traffico precedente era di 50.000 letture al secondo. La modalità con capacità on demand supporta istantaneamente un traffico sostenuto fino a 100.000 letture al secondo. Se la propria applicazione registra un traffico di 100.000 letture al secondo, quel picco diventa il nuovo picco precedente. Questo picco precedente consente al traffico successivo di raggiungere fino a 200.000 letture al secondo.
Se il proprio carico di lavoro genera oltre il doppio del picco precedente sulla tabella, DynamoDB alloca automaticamente ulteriore capacità con l’aumentare del volume del traffico. Questa allocazione della capacità aiuta a garantire che il carico di lavoro non subisca una limitazione (della larghezza di banda della rete). Tuttavia, il throttling può verificarsi se si eccede del doppio il picco precedente entro 30 minuti. Ad esempio, si supponga che lo schema di traffico dell’applicazione vari tra 25.000 e 50.000 operazioni a elevata consistenza di lettura. Il picco di traffico precedentemente raggiunto era di 50.000 letture al secondo. Si raccomanda di pre-riscaldare la tabella oppure di scaglionare la crescita del traffico su un intervallo minimo di 30 minuti, prima di raggiungere un carico superiore a 100.000 letture al secondo. Per ulteriori informazioni sul pre-riscaldamento, consulta [Funzionamento del throughput di DynamoDB](warm-throughput.md).
DynamoDB non impone la restrizione di limitazione (della larghezza di banda della rete) di 30 minuti se il traffico di picco del carico di lavoro rimane entro il doppio del picco precedente. Se il traffico di picco supera il doppio del picco, assicurati che questa crescita si verifichi 30 minuti dopo l’ultima volta che è stato raggiunto il picco.
# Throughput massimo di DynamoDB per le tabelle on demand
Per le tabelle su richiesta, puoi facoltativamente specificare la velocità massima di lettura o scrittura (o entrambe) al secondo su singole tabelle e sugli indici secondari globali associati (). GSIs La specificazione di un throughput massimo on demand aiuta a mantenere limitati l’utilizzo e i costi a livello di tabella. Per impostazione predefinita, le impostazioni di throughput massimo non vengono applicate e la velocità di throughput on demand è limitata da una [quota di servizio AWS](ServiceQuotas.md#default-limits-throughput) di throughput di lettura e scrittura a livello di tabella di 40.000 per tutte le tabelle dell’account. Se necessario, è possibile richiedere un aumento della quota di servizio.
Quando si configura il throughput massimo per una tabella on demand, le richieste di throughput che superano la quantità massima specificata verranno sottoposte a limitazione (della larghezza di banda della rete). È possibile modificare il throughput massimo a livello di tabella in qualsiasi momento in base ai requisiti dell’applicazione.
Di seguito sono riportati alcuni casi d’uso comuni in cui è possibile trarre vantaggio dall’utilizzo del throughput massimo per le tabelle on demand:
+ **Ottimizzazione dei costi di throughput:** l’utilizzo del throughput massimo per le tabelle on demand offre un ulteriore livello di prevedibilità e gestibilità dei costi. Inoltre, offre una maggiore flessibilità nell’utilizzo della modalità on demand per supportare carichi di lavoro con modelli di traffico e budget diversi.
+ **Protezione dall’uso eccessivo**: impostando il throughput massimo è possibile prevenire un aumento accidentale dell’utilizzo di lettura o scrittura, che potrebbe derivare da codice non ottimizzato o processi non autorizzati, rispetto a una tabella on demand. Questa impostazione a livello di tabella può proteggere le organizzazioni dall’utilizzo eccessivo di risorse entro un determinato periodo di tempo.
+ **Protezione dei servizi a valle**: un’applicazione del cliente può includere tecnologie serverless e non serverless. L’architettura serverless può scalare rapidamente per soddisfare la domanda. Tuttavia, i componenti a valle con capacità fisse potrebbero risultare sovraccaricati. L’implementazione delle impostazioni di throughput massimo per le tabelle on demand può impedire la propagazione di grandi volumi di eventi a più componenti a valle con effetti collaterali imprevisti.
È possibile configurare la velocità effettiva massima per la modalità on demand per tabelle a regione singola e tabelle globali nuove ed esistenti e. GSIs È possibile anche configurare il throughput massimo durante il ripristino delle tabelle e l’importazione dei dati dai flussi di lavoro di Amazon S3.
È possibile specificare le impostazioni di throughput massimo per una tabella on demand utilizzando la [console DynamoDB](https://console.aws.amazon.com/dynamodb/), la [AWS CLI](AccessingDynamoDB.md#Tools.CLI), [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-dynamodb-table.html) o l’[API DynamoDB](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/Welcome.html).
**Nota**
Il throughput massimo per una tabella on demand viene applicato sulla base del principio del massimo impegno e dovrebbe essere considerato un obiettivo, anziché un massimale di richieste garantito. Il carico di lavoro potrebbe superare temporaneamente il throughput massimo specificato a causa della [*capacità di espansione*](burst-adaptive-capacity.md#burst-capacity). In alcuni casi, DynamoDB utilizza la *capacità di espansione* per accettare letture o scritture eccedenti rispetto alle impostazioni di throughput massimo della tabella. Con la capacità supplementare, le richieste di lettura o scrittura impreviste possono avere esito positivo anziché essere sottoposte a throttling.
**Topics**
+ [
## Considerazioni relative all’utilizzo del throughput massimo per la modalità on demand
](#consideration-use-max-throughput-ondemand)
+ [
## Richiedi limitazioni e metriche CloudWatch
](#max-throughput-ondemand-request-throttle)
## Considerazioni relative all’utilizzo del throughput massimo per la modalità on demand
Quando si utilizza il throughput massimo per le tabelle in modalità on demand, si applicano le seguenti considerazioni:
+ È possibile impostare in modo indipendente il throughput massimo per le letture e le scritture per qualsiasi tabella on demand o per un singolo indice secondario globale all’interno di tale tabella per ottimizzare l’approccio in base a requisiti specifici.
+ Puoi utilizzare Amazon CloudWatch per monitorare e comprendere i parametri di utilizzo a livello di tabella di DynamoDB e per determinare le impostazioni di throughput massimo appropriate per la modalità on-demand. Per ulteriori informazioni, consulta [Parametri e dimensioni di DynamoDB](metrics-dimensions.md).
+ Quando si specificano le impostazioni di throughput massimo di lettura o scrittura (o entrambe) su una replica di una tabella globale, le stesse impostazioni di throughput massimo vengono applicate automaticamente a tutte le tabelle di replica. Per garantire la corretta replica dei dati è necessario che le tabelle di replica e gli indici secondari in una tabella globale abbiano impostazioni di throughput di scrittura identiche. Per ulteriori informazioni, consulta [Best practice per le tabelle globali](globaltables-bestpractices.md).
+ Il throughput massimo di lettura o scrittura più piccolo che è possibile specificare è un’unità di richiesta al secondo.
+ Il throughput massimo specificato deve essere inferiore alla quota di throughput predefinita disponibile per qualsiasi tabella on demand o singolo indice secondario globale all’interno di tale tabella.
## Richiedi limitazioni e metriche CloudWatch
Se l’applicazione supera il throughput massimo di lettura o scrittura impostato nella tabella on demand, DynamoDB inizia a limitare la larghezza di banda della rete di tali richieste. Quando DynamoDB limita una lettura o una scrittura, restituisce una `ThrottlingException` al chiamante. È quindi possibile intraprendere le azioni appropriate, se necessario. Ad esempio, è possibile aumentare o disabilitare l’impostazione del throughput massimo della tabella o attendere un breve intervallo prima di ritentare la richiesta.
Per semplificare il monitoraggio, il throughput massimo configurato per una tabella o un indice secondario globale, CloudWatch fornisce le seguenti metriche: e. [OnDemandMaxReadRequestUnits](metrics-dimensions.md#OnDemandMaxReadRequestUnits) [OnDemandMaxWriteRequestUnits](metrics-dimensions.md#OnDemandMaxWriteRequestUnits)
# Modalità con capacità allocata di DynamoDB
Quando si crea una nuova tabella con provisioning in DynamoDB, è necessario specificare la *capacità di throughput allocata*, che è la quantità di throughput di lettura e scrittura che la tabella può supportare. L’addebito avverrà in base alla capacità oraria di lettura e scrittura allocata, non alla quantità di quella capacità allocata effettivamente utilizzata.
Con il cambiamento dei requisiti di accesso e dati dell’applicazione, può essere necessario modificare le impostazioni di throughput della tabella. È possibile utilizzare il dimensionamento automatico per regolare automaticamente la capacità assegnata della tabella in risposta alle modifiche del traffico. Il dimensionamento automatico di DynamoDB utilizza una [policy di dimensionamento](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-target-tracking.html) in [Application Auto Scaling.](https://docs.aws.amazon.com/autoscaling/application/userguide/what-is-application-auto-scaling.html) Per configurare il dimensionamento automatico in DynamoDB, si impostano i livelli minimo e massimo di capacità di lettura e scrittura oltre alla percentuale di utilizzo di destinazione. Application Auto Scaling crea e gestisce gli CloudWatch allarmi che attivano gli eventi di scalabilità quando la metrica si discosta dall'obiettivo. Il dimensionamento automatico monitora l’attività della tabella e ne aumenta o diminuisce le impostazioni di capacità in base a soglie preconfigurate. La scalabilità automatica si attiva quando la capacità consumata supera l'utilizzo previsto configurato per due minuti consecutivi. CloudWatch gli allarmi potrebbero avere un breve ritardo, fino a qualche minuto, prima di attivare il ridimensionamento automatico. Per ulteriori informazioni, consulta [Gestione automatica della capacità effettiva di trasmissione con il dimensionamento automatico di DynamoDB](AutoScaling.md).
Se si utilizza la scalabilità automatica di DynamoDB, le impostazioni di velocità effettiva vengono modificate automaticamente in base ai carichi di lavoro effettivi. Puoi anche utilizzare l'operazione [UpdateTable](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_UpdateTable.html) per modificare la capacità di throughput della tabella manualmente. Ad esempio, questa potrebbe essere la scelta opportuna se si ha necessità di caricare in blocco i dati da un datastore esistente nella nuova tabella DynamoDB. Puoi creare la tabella con un'impostazione di throughput di scrittura elevata, per poi ridurla al termine del caricamento in blocco dei dati.
**Nota**
Per impostazione predefinita, DynamoDB protegge da un utilizzo indesiderato e incontrollato. Per scalare i limiti di throughput di lettura e scrittura a livello di tabella di 40.000 per tutte le tabelle dell’account, è possibile richiedere un aumento di questa quota. Le richieste di throughput che superano la quota di throughput predefinito della tabella sono sottoposte a limitazione (della larghezza di banda della rete). Per ulteriori informazioni, consulta [Quote predefinite della velocità di trasmissione effettiva](ServiceQuotas.md#default-limits-throughput).
È possibile cambiare le tabelle dalla modalità con capacità allocata alla modalità on demand fino a quattro volte in una finestra variabile di 24 ore. È possibile passare le tabelle dalla modalità on demand alla modalità con capacità allocata in qualsiasi momento.
Per ulteriori informazioni sul passaggio dalla modalità di capacità di lettura a quella di scrittura, consulta [Considerazioni sul passaggio tra modalità di capacità in DynamoDB](bp-switching-capacity-modes.md).
**Topics**
+ [
## Unità di capacità in lettura e unità di capacità in scrittura
](#read-write-capacity-units)
+ [
## Scelta delle impostazioni di velocità di trasmissione effettiva iniziali
](#choosing-initial-throughput)
+ [
## Scalabilità automatica di DynamoDB
](#ddb-autoscaling)
+ [
# Gestione automatica della capacità effettiva di trasmissione con il dimensionamento automatico di DynamoDB
](AutoScaling.md)
+ [
# Capacità riservata di DynamoDB
](reserved-capacity.md)
## Unità di capacità in lettura e unità di capacità in scrittura
Per le tabelle con modalità con provisioning, è possibile specificare i requisiti di throughput in termini di *unità di capacità*. Queste unità rappresentano la quantità di dati che un’applicazione deve leggere o scrivere al secondo. È possibile modificare queste impostazioni in un secondo momento, se necessario, o abilitare la scalabilità automatica di DynamoDB per la modifica automatica.
Per un elemento di dimensioni fino a 4 KB, un’*unità di richiesta di lettura* (RCU, Read Capacity Unit) rappresenta un’operazione a elevata consistenza di lettura al secondo o due operazioni di lettura a coerenza finale al secondo. Per ulteriori informazioni sui modelli di consistenza di lettura di DynamoDB, consulta [Coerenza di lettura di DynamoDB](HowItWorks.ReadConsistency.md).
Un’*unità di capacità di scrittura* (WCU, Write Capacity Units) rappresenta una scrittura al secondo per un elemento di dimensioni fino a 1 KB. Per ulteriori informazioni sulle differenti operazioni di lettura e scrittura, consulta [Operazioni di lettura e scrittura di DynamoDB](read-write-operations.md).
## Scelta delle impostazioni di velocità di trasmissione effettiva iniziali
Ogni applicazione ha requisiti diversi di lettura e scrittura da e su un database. Nella determinazione delle impostazioni di throughput iniziali per una tabella DynamoDB, tieni presente quanto segue:
+ **Frequenze delle richieste di lettura e scrittura previste**: è necessario stimare il numero di letture e scritture da eseguire al secondo.
+ **Dimensioni degli elementi**: alcuni elementi sono abbastanza piccoli da poter essere letti o scritti utilizzando una sola unità di capacità. Elementi più grandi richiedono più unità di capacità. Stimando le dimensioni medie degli elementi nella propria tabella è possibile specificare impostazioni accurate per il throughput allocato.
+ **Requisiti di consistenza di lettura**: le unità di capacità di lettura si basano su operazioni a elevata consistenza di lettura, che utilizzano il doppio delle risorse di database rispetto alle letture a coerenza finale. Devi determinare se l'applicazione richiede letture fortemente consistenti o se è possibile stabilire un requisito meno rigido ed eseguire invece letture consistenti finali. Le operazioni di lettura in DynamoDB sono a coerenza finale per impostazione predefinita. Se necessario, in questo caso è possibile richiedere operazioni a elevata consistenza di lettura.
Ad esempio, si supponga di voler leggere 80 elementi al secondo da una tabella. Gli elementi hanno una dimensione di 3 KB e si desiderano operazioni a elevata consistenza di lettura. In questo caso, ogni lettura richiede un’unità di capacità di lettura allocata. Per determinare questo numero, dividi la dimensione dell’elemento dell’operazione per 4 KB. Quindi, arrotonda per eccesso al numero intero più vicino, come mostrato nell’esempio seguente:
+ 3 KB / 4 KB = 0,75 o **1** unità di capacità di lettura
Pertanto, per leggere 80 elementi al secondo da una tabella, imposta il throughput di lettura allocato della tabella su 80 unità di capacità di lettura, come illustrato nell’esempio seguente:
+ 1 unità di capacità di lettura per elemento × 80 letture al secondo = **80** unità di capacità di lettura
Si supponga ora di voler scrivere 100 elementi al secondo nella tabella e che ogni elemento abbia una dimensione di 512 byte. In questo caso, ogni lettura richiede un’unità di capacità di scrittura allocata. Per determinare questo numero, dividi la dimensione dell’elemento dell’operazione per 1 KB. Quindi, arrotonda per eccesso al numero intero più vicino, come mostrato nell’esempio seguente:
+ 512 byte/1 KB = 0,5 o **1** unità di capacità di scrittura
Per scrivere 100 elementi al secondo nella tabella, imposta il throughput di scrittura allocato della tabella su 100 unità di capacità di scrittura:
+ 1 unità di capacità di scrittura per elemento × 100 scritture al secondo = **100** unità di capacità di scrittura
## Scalabilità automatica di DynamoDB
Il dimensionamento automatico di DynamoDB gestisce attivamente la capacità di throughput allocata per le tabelle e indici secondari globali. Con l'Auto Scaling definisci un intervallo (limiti superiore e inferiore) per le unità di capacità in lettura e scrittura. È inoltre possibile definire una percentuale di utilizzo di destinazione all'interno di tale intervallo. La scalabilità automatica di DynamoDB cerca di mantenere l'utilizzo di destinazione, anche se il carico di lavoro dell'applicazione aumenta o diminuisce.
Con la scalabilità automatica di DynamoDB, una tabella o un indice secondario globale può aumentare la capacità in lettura e scrittura assegnata per gestire improvvisi aumenti di traffico senza che si verifichi alcuna limitazione delle richieste. Quando il carico di lavoro diminuisce, la scalabilità automatica di DynamoDB può ridurre la velocità effettiva in modo da non pagare per la capacità assegnata inutilizzata.
**Nota**
Se si utilizza il Console di gestione AWS per creare una tabella o un indice secondario globale, la scalabilità automatica di DynamoDB è abilitata per impostazione predefinita.
È possibile gestire le impostazioni di ridimensionamento automatico in qualsiasi momento utilizzando la console AWS CLI, il o uno dei AWS SDKs. Per ulteriori informazioni, consulta [Gestione automatica della capacità effettiva di trasmissione con il dimensionamento automatico di DynamoDB](AutoScaling.md).
### Tasso di utilizzo
Il tasso di utilizzo può aiutare a determinare se la capacità di provisioning è eccessiva, nel qual caso è opportuno ridurre la capacità della tabella per risparmiare sui costi. Al contrario, può anche aiutare a determinare se la capacità di provisioning è insufficiente. In questo caso, è consigliabile aumentare la capacità delle tabelle per evitare una potenziale limitazione (della larghezza di banda della rete) delle richieste durante istanze di traffico elevato impreviste. Per ulteriori informazioni, consulta [Amazon DynamoDB auto scaling: Performance and cost optimization at any scale](https://aws.amazon.com/blogs/database/amazon-dynamodb-auto-scaling-performance-and-cost-optimization-at-any-scale/).
In caso di utilizzo del dimensionamento automatico di DynamoDB, sarà anche necessario impostare una percentuale di utilizzo di destinazione. Il dimensionamento automatico utilizzerà questa percentuale come destinazione per aumentare o diminuire la capacità. Si consiglia di impostare l’utilizzo di destinazione al 70%. Per ulteriori informazioni, consulta [Gestione automatica della capacità effettiva di trasmissione con il dimensionamento automatico di DynamoDB](AutoScaling.md).
# Gestione automatica della capacità effettiva di trasmissione con il dimensionamento automatico di DynamoDB
Molti carichi di lavoro dei database sono per natura ciclici o sono difficili da prevedere in anticipo. Ad esempio, considera un'app di social network in cui la maggior parte degli utenti sono attivi durante le ore diurne. Il database deve essere in grado di gestire l'attività diurna e ciò non è necessario per gli stessi livelli di throughput durante la notte. Un altro esempio potrebbe essere una nuova app di gioco per dispositivi mobili che si sta improvvisamente diffondendo in modo rapido. Se il gioco si diffonde troppo, potrebbe superare le risorse di database disponibili, con un conseguente rallentamento delle prestazioni e diversi clienti insoddisfatti. Questi tipi di carichi di lavoro richiedono spesso l'intervento manuale per aumentare o diminuire le risorse di database in risposta alla variazione dei livelli di utilizzo.
La scalabilità automatica di Amazon DynamoDB utilizza il servizio Application AWS Auto Scaling per regolare dinamicamente la capacità di throughput assegnata per tuo conto, in risposta ai modelli di traffico effettivi. In tal modo una tabella o un indice secondario globale (GSI) può aumentare la capacità di lettura e scrittura allocata per gestire improvvisi aumenti di traffico senza limitazione (della larghezza di banda della rete). Quando il carico di lavoro diminuisce, Application Auto Scaling riduce la velocità effettiva in modo da non dover pagare per la capacità assegnata inutilizzata.
**Nota**
Se si utilizza il Console di gestione AWS per creare una tabella o un indice secondario globale, la scalabilità automatica di DynamoDB è abilitata per impostazione predefinita. Puoi modificare le tue impostazioni di scalabilità automatica in qualsiasi momento. Per ulteriori informazioni, consulta [Utilizzo della scalabilità Console di gestione AWS automatica con DynamoDB](AutoScaling.Console.md).
Quando si elimina una tabella o una replica globale di una tabella, tutti gli obiettivi scalabili, le politiche di ridimensionamento o gli CloudWatch allarmi associati non vengono eliminati automaticamente con essa.
Con Application Auto Scaling, è possibile creare una *policy di dimensionamento* per una tabella o un indice secondario globale. La policy di dimensionamento specifica se desideri dimensionare la capacità di lettura o di scrittura (o e entrambe) e indica le impostazioni delle unità di capacità minime e massime assegnate per la tabella o l'indice.
La policy di dimensionamento contiene anche un *utilizzo di destinazione*: la percentuale di velocità effettiva assegnata consumata in un dato momento. Application Auto Scaling utilizza un *monitoraggio degli obiettivi* per regolare la velocità effettiva assegnata della tabella (o dell'indice) in alto o in basso, in risposta a carichi di lavoro effettivi in modo che l'utilizzo effettivo della capacità rimanga pari o vicino all'utilizzo di destinazione.
DynamoDB fornisce il throughput allocato utilizzato per periodi di un minuto. La scalabilità automatica si attiva quando la capacità consumata supera l'utilizzo previsto configurato per due minuti consecutivi. CloudWatch gli allarmi potrebbero avere un breve ritardo, fino a qualche minuto, prima di attivare il ridimensionamento automatico. Questo ritardo garantisce una valutazione metrica accurata CloudWatch . Se i picchi di throughput utilizzato distano più di un minuto, il dimensionamento automatico potrebbe non attivarsi. Analogamente, un evento di riduzione verticale può avvenire quando 15 punti dati consecutivi sono inferiori all’utilizzo di destinazione. In entrambi i casi, dopo i trigger di auto scaling, viene richiamata l'[UpdateTable](https://docs.aws.amazon.com/amazondynamodb/latest/APIReference/API_UpdateTable.html)API. Sono quindi necessari alcuni minuti per aggiornare la capacità allocata per la tabella o l’indice. Durante questo periodo, tutte le richieste che superano la capacità allocata precedente delle tabelle verranno sottoposte a limitazione (della larghezza di banda della rete).
**Importante**
Non è possibile modificare il numero di punti dati da violare per attivare l’allarme sottostante (anche se il numero attuale potrebbe cambiare in futuro).
Puoi impostare i valori dell'utilizzo di destinazione del dimensionamento automatico tra il 20 e il 90 percento per la capacità in lettura e scrittura.
**Nota**
Oltre alle tabelle, la scalabilità automatica di DynamoDB supporta anche gli indici secondari globali. Ogni indice secondario globale dispone della propria capacità di throughput assegnata, separata da quella della relativa tabella di base. Quando si crea una policy di dimensionamento per un indice secondario globale, Application Auto Scaling regola le impostazioni di velocità effettiva assegnata per l'indice per assicurare che il suo utilizzo effettivo rimanga uguale o prossimo alle proporzioni di utilizzo desiderate.
## Funzionamento del dimensionamento automatico di DynamoDB
**Nota**
Per iniziare a utilizzare rapidamente la scalabilità automatica di DynamoDB, consulta [Utilizzo della scalabilità Console di gestione AWS automatica con DynamoDB](AutoScaling.Console.md).
Il seguente diagramma fornisce una panoramica dettagliata del modo in cui la scalabilità automatica di DynamoDB gestisce la capacità di throughput per una tabella:
![\[Il dimensionamento automatico di DynamoDB regola la capacità di throughput di una tabella per soddisfare la domanda.\]](http://docs.aws.amazon.com/it_it/amazondynamodb/latest/developerguide/images/auto-scaling.png)
Le fasi seguenti sintetizzano il processo di scalabilità automatica come illustrato nel diagramma precedente:
1. È possibile creare una policy di Application Auto Scaling per la tabella DynamoDB.
1. DynamoDB pubblica i parametri della capacità consumata su Amazon. CloudWatch
1. Se la capacità consumata della tabella supera l'utilizzo previsto (o scende al di sotto del target) per un periodo di tempo specifico, Amazon CloudWatch attiva un allarme. È possibile visualizzare l'allarme sulla console e ricevere notifiche tramite Amazon Simple Notification Service (Amazon SNS).
1. L' CloudWatch allarme richiama Application Auto Scaling per valutare la politica di scalabilità.
1. Application Auto Scaling invia una richiesta `UpdateTable` per regolare la velocità effettiva assegnata della tabella.
1. DynamoDB elabora la richiesta `UpdateTable`, aumentando (o diminuendo) in modo dinamico la capacità di throughput assegnata della tabella in modo che si avvicini all'utilizzo di destinazione.
Per comprendere come funziona la scalabilità automatica di DynamoDB, si supponga di avere una tabella denominata `ProductCatalog`. La tabella riceve carichi non frequenti di dati in blocco, perciò non esegue molta attività di scrittura. Tuttavia, ciò comporta un alto livello di attività di lettura che varia nel tempo. Monitorando i CloudWatch parametri di Amazon per`ProductCatalog`, stabilisci che la tabella richiede 1.200 unità di capacità di lettura (per evitare che DynamoDB limiti le richieste di lettura quando l'attività è al massimo). Inoltre, stabilisci che `ProductCatalog` richieda minimo 150 unità di capacità in lettura, quando il traffico di lettura è al livello minimo. Per ulteriori informazioni sulla limitazione (della larghezza di banda della rete), consulta [Risoluzione dei problemi di limitazione (della larghezza di banda della rete) in Amazon DynamoDB](TroubleshootingThrottling.md).
All'interno dell'intervallo compreso tra 150 e 1.200 unità di capacità in lettura, decidi che una percentuale di utilizzo di destinazione del 70% sia adatta per la tabella `ProductCatalog`. L'*utilizzo di destinazione* viene espresso come proporzione tra le unità di capacità utilizzate e le unità di capacità assegnata, in percentuale. Application Auto Scaling utilizza il suo algoritmo di monitoraggio degli obiettivi per garantire che la capacità di lettura assegnata di `ProductCatalog` sia regolata come richiesto in modo che l'utilizzo rimanga più o meno al 70%.
**Nota**
La scalabilità automatica di DynamoDB modifica le impostazioni della velocità di trasmissione effettiva assegnata solo quando il carico di lavoro effettivo rimane elevato (o basso) per un periodo continuativo di diversi minuti. L'algoritmo di monitoraggio degli obiettivi di Application Auto Scaling cerca di tenere l'utilizzo della destinazione pari o vicino al valore scelto a lungo termine.
I picchi di attività improvvisi e di breve durata sono soddisfatti dalla capacità di ottimizzazione integrata della tabella. Per ulteriori informazioni, consulta [Capacità di ottimizzazione](burst-adaptive-capacity.md#burst-capacity).
Per abilitare la scalabilità automatica di DynamoDB per la tabella `ProductCatalog`, viene creata una policy di dimensionamento. La policy specifica quanto segue:
+ La tabella o l'indice secondario globale che desideri gestire
+ Il tipo di capacità da gestire (capacità di lettura o capacità di scrittura)
+ I limiti superiore e inferiore per le impostazioni del throughput assegnato
+ Utilizzo di destinazione
Quando crei una politica di scalabilità, Application Auto Scaling crea un paio di allarmi CloudWatch Amazon per tuo conto. Ogni coppia rappresenta i limiti superiore e inferiore per le impostazioni della velocità di trasmissione effettiva assegnata. Questi CloudWatch allarmi vengono attivati quando l'utilizzo effettivo della tabella si discosta dall'utilizzo previsto per un periodo di tempo prolungato.
Quando viene attivato uno degli CloudWatch allarmi, Amazon SNS ti invia una notifica (se l'hai abilitata). L' CloudWatch allarme richiama quindi Application Auto Scaling, che a sua volta notifica a DynamoDB di modificare la capacità assegnata alla tabella verso l'alto o verso il basso, a seconda `ProductCatalog` dei casi.
Durante un evento di scalabilità, viene addebitato per elemento di configurazione registrato. AWS Config Quando si verifica un evento di ridimensionamento, vengono creati quattro CloudWatch allarmi per ogni evento di auto-scaling di lettura e scrittura: alarms: e ProvisionedCapacity alarms:,. ProvisionedCapacityLow ProvisionedCapacityHigh ConsumedCapacity AlarmHigh AlarmLow Ciò dà luogo a un totale di otto allarmi. Pertanto, AWS Config registra otto elementi di configurazione per ogni evento di scalabilità.
**Nota**
È possibile anche pianificare il dimensionamento di DynamoDB in modo che avvenga in determinati momenti. La procedura di base è disponibile [qui](https://docs.aws.amazon.com/autoscaling/application/userguide/get-started-exercise.html).
## Note per l’utilizzo
Prima di iniziare a utilizzare la scalabilità automatica di DynamoDB è necessario tenere presente quanto riportato di seguito:
+ La scalabilità automatica di DynamoDB può aumentare la capacità di lettura o di scrittura in base alle necessità e secondo la policy di scalabilità automatica. Tutti le quote di DynamoDB restano in vigore, come descritto in [Quote in Amazon DynamoDB](ServiceQuotas.md).
+ La scalabilità automatica di DynamoDB non impedisce di modificare manualmente le impostazioni di velocità effettiva assegnata. Queste regolazioni manuali non influiscono sugli CloudWatch allarmi esistenti correlati alla scalabilità automatica di DynamoDB.
+ Se si abilita la scalabilità automatica di DynamoDB per una tabella che ha uno o più indici secondari globali, consigliamo di applicare la scalabilità automatica in maniera uniforme anche a quegli indici. Ciò contribuirà a garantire prestazioni migliori per la scrittura e la lettura delle tabelle e a evitare la limitazione della larghezza di banda della rete. È possibile abilitare la scalabilità automatica selezionando **Apply same settings to global secondary indexes** (Applica le stesse impostazioni agli indici secondari globali) nella Console di gestione AWS. Per ulteriori informazioni, consulta [Abilitazione del dimensionamento automatico di DynamoDB su tabelle esistenti](AutoScaling.Console.md#AutoScaling.Console.ExistingTable).
+ Quando si elimina una tabella o una replica globale di una tabella, tutti gli obiettivi scalabili, le policy di ridimensionamento o gli allarmi associati non vengono eliminati automaticamente con essa. CloudWatch
+ Quando si crea un GSI per una tabella esistente, il dimensionamento automatico non è abilitato per il GSI. Dovrai gestire manualmente la capacità mentre il GSI è in fase di costruzione. Una volta completato il backfill sul GSI e raggiunto lo stato attivo, la scalabilità automatica funzionerà normalmente.
# Utilizzo della scalabilità Console di gestione AWS automatica con DynamoDB
Quando usi il Console di gestione AWS per creare una nuova tabella, la scalabilità automatica di Amazon DynamoDB è abilitata per quella tabella per impostazione predefinita. È possibile utilizzare la console anche per abilitare la scalabilità automatica per le tabelle esistenti, modificare le impostazioni di scalabilità automatica o disabilitare la scalabilità automatica.
**Nota**
Per funzionalità più avanzate come l'impostazione dei tempi di cooldown scale-in e scale-out, usa il AWS Command Line Interface () per AWS CLI gestire la scalabilità automatica di DynamoDB. Per ulteriori informazioni, consulta [Utilizzo di AWS CLI per gestire la scalabilità automatica di DynamoDB](AutoScaling.CLI.md).
**Topics**
+ [
## Prima di iniziare: concessione delle autorizzazioni utente per il dimensionamento automatico di DynamoDB
](#AutoScaling.Permissions)
+ [
## Creazione di una nuova tabella con il dimensionamento automatico abilitato
](#AutoScaling.Console.NewTable)
+ [
## Abilitazione del dimensionamento automatico di DynamoDB su tabelle esistenti
](#AutoScaling.Console.ExistingTable)
+ [
## Visualizzazione delle attività di dimensionamento automatico sulla console
](#AutoScaling.Console.ViewingActivities)
+ [
## Modifica o disabilitazione delle impostazioni di dimensionamento automatico di DynamoDB
](#AutoScaling.Console.Modifying)
## Prima di iniziare: concessione delle autorizzazioni utente per il dimensionamento automatico di DynamoDB
In AWS Identity and Access Management (IAM), la policy AWS gestita `DynamoDBFullAccess` fornisce le autorizzazioni necessarie per l'utilizzo della console DynamoDB. Tuttavia, per dimensionamento automatico di DynamoDB, gli utenti IAM richiedono autorizzazioni aggiuntive.
**Importante**
Le autorizzazioni sono necessarie per eliminare una tabella abilitata per il dimensionamento automatico. La policy AWS gestita `DynamoDBFullAccess` include tali autorizzazioni.
**Per configurare un utente per l'accesso alla console DynamoDB e la scalabilità automatica di DynamoDB, crea un ruolo e aggiungi la politica di accesso a quel ruolo. AmazonDynamo DBFull** Quindi assegna il ruolo a un utente.
## Creazione di una nuova tabella con il dimensionamento automatico abilitato
**Nota**
Il dimensionamento automatico di DynamoDB richiede la presenza di un ruolo collegato al servizio (`AWSServiceRoleForApplicationAutoScaling_DynamoDBTable`) che esegue operazioni di dimensionamento automatico per conto dell’utente. Questo ruolo viene creato automaticamente per te. Per ulteriori informazioni, consulta [Ruoli collegati ai servizi per Application Auto Scaling](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-service-linked-roles.html) nella *Guida per l’utente di Application Auto Scaling*.
**Come creare una nuova tabella con la scalabilità automatica abilitata**
1. Apri la console DynamoDB all'indirizzo. [https://console.aws.amazon.com/dynamodb/](https://console.aws.amazon.com/dynamodb/)
1. Scegliere **Create table (Crea tabella)**.
1. Nella pagina **Crea tabella**, inserisci un **Nome tabella** e i dettagli della chiave primaria.
1. Selezionando **Impostazioni predefinite**, il dimensionamento automatico sarà abilitato nella nuova tabella.
Altrimenti, seleziona **Personalizza impostazioni** ed effettua le seguenti operazioni per specificare le impostazioni personalizzate per la tabella:
1. Per **Classe tabella**, mantieni la selezione predefinita di **DynamoDB Standard**.
1. Per **Impostazioni di capacità in scrittura/lettura**, mantieni la selezione predefinita di **Provisioning effettuato**, quindi procedi come segue:
1. Per la **Capacità in lettura**, assicurati che **Auto Scaling** sia impostato su **Attivo**.
1. Per la **Capacità in scrittura**, assicurati che **Auto Scaling** sia impostato su **Attivo**.
1. Per **Capacità in lettura** e **Capacità in scrittura**, imposta la policy di dimensionamento desiderata per la tabella e, facoltativamente, per tutti gli indici secondari globali della tabella.
+ **Unità di capacità minima**: inserisci il limite inferiore dell'intervallo di dimensionamento automatico.
+ **Unità di capacità massima**: inserisci il limite superiore dell'intervallo di dimensionamento automatico.
+ **Utilizzo destinazione**: inserisci la percentuale di utilizzo destinazione per la tabella.
**Nota**
Se crei un indice secondario globale per la nuova tabella, la capacità dell'indice al momento della creazione sarà uguale alla capacità di base della tabella. Puoi modificare la capacità dell'indice nelle impostazioni della tabella dopo aver creato la tabella.
1. Scegliere **Create table (Crea tabella)**. Questa azione crea la tabella con i parametri di dimensionamento automatico specificati.
## Abilitazione del dimensionamento automatico di DynamoDB su tabelle esistenti
**Nota**
Il dimensionamento automatico di DynamoDB richiede la presenza di un ruolo collegato al servizio (`AWSServiceRoleForApplicationAutoScaling_DynamoDBTable`) che esegue operazioni di dimensionamento automatico per conto dell’utente. Questo ruolo viene creato automaticamente per te. Per ulteriori informazioni, consulta [Ruoli collegati ai servizi per Application Auto Scaling](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-service-linked-roles.html).
**Come abilitare la scalabilità automatica DynamoDB per una tabella esistente**
1. Apri la console DynamoDB all'indirizzo. [https://console.aws.amazon.com/dynamodb/](https://console.aws.amazon.com/dynamodb/)
1. Nel riquadro di navigazione sul lato sinistro della console scegli **Tables (Tabelle)**.
1. Seleziona la tabella in cui desideri abilitare il dimensionamento automatico, quindi segui questa procedura:
1. Vai alla scheda **Impostazioni aggiuntive**.
1. Nella sezione **Capacità di lettura/scrittura**, scegli **Modifica**.
1. Nella sezione **Modalità di capacità**, scegli **Assegnata**.
1. Nella sezione **Table capacity (Capacità tabella)**, imposta **Auto Scaling (Scalabilità automatica)** su **On (Attiva)** per **Read capacity (Capacità di lettura)**, **Write capacity (Capacità di scrittura)** o entrambe. Per ognuna di queste, imposta la policy di dimensionamento desiderata per la tabella e, facoltativamente, tutti gli indici secondari globali della tabella.
+ **Unità di capacità minima**: inserisci il limite inferiore dell'intervallo di dimensionamento automatico.
+ **Unità di capacità massima**: inserisci il limite superiore dell'intervallo di dimensionamento automatico.
+ **Utilizzo destinazione**: inserisci la percentuale di utilizzo destinazione per la tabella.
+ **Utilizza le stesse impostazioni di read/write capacità per tutti gli indici secondari globali**: scegli se gli indici secondari globali devono utilizzare la stessa politica di scalabilità automatica della tabella di base.
**Nota**
Per prestazioni ottimali, si consiglia di abilitare l'opzione **Usa le stesse impostazioni di read/write capacità per tutti gli** indici secondari globali. Questa opzione consente alla scalabilità automatica di DynamoDB di dimensionare uniformemente tutti gli indici secondari globali nella tabella di base. Sono inclusi gli indici secondari globali esistenti e tutti gli altri che verranno creati per questa tabella in futuro.
Se questa opzione è abilitata, non è possibile impostare una policy di dimensionamento su un singolo indice secondario globale.
1. Dopo aver selezionato le impostazioni desiderate, scegli **Save (Salva)**.
## Visualizzazione delle attività di dimensionamento automatico sulla console
Man mano che l'applicazione guida il traffico di lettura e scrittura nella tabella, la scalabilità automatica di DynamoDB modifica dinamicamente le impostazioni della velocità effettiva della tabella. Amazon CloudWatch tiene traccia della capacità fornita e consumata, degli eventi limitati, della latenza e di altri parametri per tutte le tabelle e gli indici secondari DynamoDB.
Per visualizzare queste metriche nella console DynamoDB, scegli la tabella che desideri utilizzare e seleziona la scheda **Monitora**. **Per creare una visualizzazione personalizzabile delle metriche della tabella, seleziona Visualizza tutto in. CloudWatch**
## Modifica o disabilitazione delle impostazioni di dimensionamento automatico di DynamoDB
È possibile utilizzare il Console di gestione AWS per modificare le impostazioni di autoscaling di DynamoDB. Per eseguire questa operazione, vai alla scheda **Impostazioni aggiuntive** della tua tabella e seleziona **Modifica** nella sezione **Capacità di lettura/scrittura**. Per ulteriori informazioni su queste impostazioni, consultare [Abilitazione del dimensionamento automatico di DynamoDB su tabelle esistenti](#AutoScaling.Console.ExistingTable).
# Utilizzo di AWS CLI per gestire la scalabilità automatica di DynamoDB
Invece di usare il Console di gestione AWS, puoi usare il AWS Command Line Interface (AWS CLI) per gestire la scalabilità automatica di Amazon DynamoDB. Nel tutorial in questa sezione viene illustrato come installare e configurare la AWS CLI per la gestione della scalabilità automatica di DynamoDB. In questo tutorial, esegui quanto indicato di seguito:
+ Crea una tabella DynamoDB denominata `TestTable`. Le impostazioni di velocità effettiva iniziali sono 5 unità di capacità di lettura e 5 unità di capacità di scrittura.
+ Crea una policy di Application Auto Scaling per `TestTable`. La policy cerca di mantenere un rapporto obiettivo del 50% tra capacità di scrittura utilizzata e capacità di scrittura assegnata. L'intervallo per questo parametro è compreso tra 5 e 10 unità di capacità di scrittura. (Application Auto Scaling non può regolare la velocità effettiva oltre questo intervallo).
+ Eseguire un programma Python per indirizzare il traffico di scrittura su `TestTable`. Quando il rapporto di destinazione supera il 50% per un periodo di tempo prolungato, Application Auto Scaling richiede a DynamoDB di regolare la velocità effettiva di `TestTable` verso l'alto in modo da mantenere l'utilizzo della destinazione al 50%.
+ Verificare che DynamoDB abbia regolato correttamente la capacità di scrittura assegnata per `TestTable`.
**Nota**
È possibile anche pianificare il dimensionamento di DynamoDB in modo che avvenga in determinati momenti. La procedura di base è disponibile [qui](https://docs.aws.amazon.com/autoscaling/application/userguide/get-started-exercise.html).
**Topics**
+ [
## Prima di iniziare
](#AutoScaling.CLI.BeforeYouBegin)
+ [
## Fase 1: creazione di una tabella DynamoDB
](#AutoScaling.CLI.CreateTable)
+ [
## Fase 2: registrazione di una destinazione scalabile
](#AutoScaling.CLI.RegisterScalableTarget)
+ [
## Fase 3: creazione di una policy di dimensionamento
](#AutoScaling.CLI.CreateScalingPolicy)
+ [
## Passaggio 4: Indirizza il traffico di scrittura verso TestTable
](#AutoScaling.CLI.DriveTraffic)
+ [
## Fase 5: visualizzazione delle operazioni di Application Auto Scaling
](#AutoScaling.CLI.ViewCWAlarms)
+ [
## (Opzionale) Fase 6: pulizia
](#AutoScaling.CLI.CleanUp)
## Prima di iniziare
Prima di iniziare il tutorial, completare le attività seguenti:
### Installa AWS CLI
Se non l'hai ancora fatto, installa e configura AWS CLI. A questo scopo, seguire le istruzioni fornite nella *Guida per l'utente di AWS Command Line Interface *:
+ [Installazione dell' AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/installing.html)
+ [Configurazione della AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html)
### Installazione di Python
Parte di questo tutorial richiede l'esecuzione di un programma Python (vedere [Passaggio 4: Indirizza il traffico di scrittura verso TestTable](#AutoScaling.CLI.DriveTraffic)). Se non è già installato, [scaricare Python](https://www.python.org/downloads).
## Fase 1: creazione di una tabella DynamoDB
In questo passaggio, si utilizza AWS CLI per creare`TestTable`. La chiave primaria è costituita da `pk` (chiave di partizione) e da `sk` (chiave di ordinamento). Entrambi questi attributi sono di tipo `Number`. Le impostazioni di velocità effettiva iniziali sono 5 unità di capacità di lettura e 5 unità di capacità di scrittura.
1. Utilizzate il seguente AWS CLI comando per creare la tabella.
```
aws dynamodb create-table \
--table-name TestTable \
--attribute-definitions \
AttributeName=pk,AttributeType=N \
AttributeName=sk,AttributeType=N \
--key-schema \
AttributeName=pk,KeyType=HASH \
AttributeName=sk,KeyType=RANGE \
--provisioned-throughput ReadCapacityUnits=5,WriteCapacityUnits=5
```
1. Per verificare lo stato della tabella, utilizza il comando seguente.
```
aws dynamodb describe-table \
--table-name TestTable \
--query "Table.[TableName,TableStatus,ProvisionedThroughput]"
```
La tabella è pronta per l'uso quando lo stato diventa `ACTIVE`.
## Fase 2: registrazione di una destinazione scalabile
Successivamente si registra la capacità di scrittura della tabella come destinazione scalabile con Application Auto Scaling. Ciò consente ad Application Auto Scaling di regolare la capacità di scrittura assegnata per *TestTable*, ma solo entro un intervallo di 5-10 unità di capacità.
**Nota**
La scalabilità automatica di DynamoDB richiede la presenza di un ruolo collegato al servizio (`AWSServiceRoleForApplicationAutoScaling_DynamoDBTable`) che esegue operazioni di scalabilità automatica per conto tuo. Questo ruolo viene creato automaticamente per te. Per ulteriori informazioni, consulta [Ruoli collegati ai servizi per Application Auto Scaling](https://docs.aws.amazon.com/autoscaling/application/userguide/application-auto-scaling-service-linked-roles.html) nella *Guida per l’utente di Application Auto Scaling*.
1. Utilizza il comando seguente per registrare la destinazione scalabile.
```
aws application-autoscaling register-scalable-target \
--service-namespace dynamodb \
--resource-id "table/TestTable" \
--scalable-dimension "dynamodb:table:WriteCapacityUnits" \
--min-capacity 5 \
--max-capacity 10
```
1. Utilizza il comando seguente per verificare la registrazione.
```
aws application-autoscaling describe-scalable-targets \
--service-namespace dynamodb \
--resource-id "table/TestTable"
```
**Nota**
È inoltre possibile registrare una destinazione scalabile rispetto a un indice secondario globale. Ad esempio, per un indice secondario globale ("test-index"), l'ID risorsa e gli argomenti della dimensione scalabile vengono aggiornati di conseguenza.
```
aws application-autoscaling register-scalable-target \
--service-namespace dynamodb \
--resource-id "table/TestTable/index/test-index" \
--scalable-dimension "dynamodb:index:WriteCapacityUnits" \
--min-capacity 5 \
--max-capacity 10
```
## Fase 3: creazione di una policy di dimensionamento
In questa fase, viene creata una policy di dimensionamento per `TestTable`. La policy definisce i dettagli in base ai quali Application Auto Scaling può regolare la velocità effettiva assegnata della tabella e le operazioni da intraprendere quando lo fa. Questa policy viene associata alla destinazione scalabile definita nel passaggio precedente (unità di capacità di scrittura per la tabella `TestTable`).
La policy contiene i seguenti elementi:
+ `PredefinedMetricSpecification`: il parametro che può essere regolato da Application Auto Scaling. Per DynamoDB, i seguenti valori sono valori validi per`PredefinedMetricType`:
+ `DynamoDBReadCapacityUtilization`
+ `DynamoDBWriteCapacityUtilization`
+ `ScaleOutCooldown`: la quantità minima di tempo (espressa in secondi) tra ogni evento Application Auto Scaling che aumenta la velocità effettiva assegnata. Questo parametro consente ad Application Auto Scaling di aumentare continuamente, ma non in modo aggressivo, la velocità effettiva in risposta ai carichi di lavoro reali. L'impostazione predefinita per `ScaleOutCooldown` è 0.
+ `ScaleInCooldown`: la quantità minima di tempo (espressa in secondi) tra ogni evento Application Auto Scaling che diminuisce la velocità effettiva assegnata. Questo parametro consente ad Application Auto Scaling di ridurre la velocità effettiva in maniera graduale e prevedibile. L'impostazione predefinita per `ScaleInCooldown` è 0.
+ `TargetValue`: Application Auto Scaling assicura che il rapporto tra la capacità utilizzata e la capacità assegnata rimanga pari o vicino a questo valore. `TargetValue` viene definito in percentuale.
**Nota**
Per capire meglio come funziona `TargetValue`, supponiamo di avere una tabella con un'impostazione di velocità effettiva assegnata pari a 200 unità di capacità in scrittura. Si decide di creare una policy di dimensionamento per questa tabella, con un `TargetValue` del 70%.
Si supponga ora di iniziare a guidare il traffico di scrittura verso la tabella in modo che la velocità effettiva di scrittura sia di 150 unità di capacità. Il consumed-to-provisioned rapporto è ora (150/ 200), ossia il 75 percento. Questo rapporto supera l'obiettivo, pertanto Application Auto Scaling aumenta la capacità di scrittura assegnata a 215 in modo che il rapporto sia (150/215) o 69,77%, il più vicino possibile a `TargetValue` ma senza superarlo.
Per `TestTable`, `TargetValue` si imposta al 50%. Application Auto Scaling regola il throughput assegnato dalla tabella entro un intervallo di 5-10 unità di capacità (vedi[Fase 2: registrazione di una destinazione scalabile](#AutoScaling.CLI.RegisterScalableTarget)) in modo che il consumed-to-provisioned rapporto rimanga pari o vicino al 50 percento. I valori di `ScaleOutCooldown` e `ScaleInCooldown` vengono impostati su 60 secondi.
1. Crea un file denominato `scaling-policy.json` con i seguenti contenuti.
```
{
"PredefinedMetricSpecification": {
"PredefinedMetricType": "DynamoDBWriteCapacityUtilization"
},
"ScaleOutCooldown": 60,
"ScaleInCooldown": 60,
"TargetValue": 50.0
}
```
1. Utilizzare il comando seguente per creare la politica AWS CLI .
```
aws application-autoscaling put-scaling-policy \
--service-namespace dynamodb \
--resource-id "table/TestTable" \
--scalable-dimension "dynamodb:table:WriteCapacityUnits" \
--policy-name "MyScalingPolicy" \
--policy-type "TargetTrackingScaling" \
--target-tracking-scaling-policy-configuration file://scaling-policy.json
```
1. Nell'output, tieni presente che Application Auto Scaling ha creato due CloudWatch allarmi Amazon, uno per il limite superiore e inferiore dell'intervallo target di scalabilità.
1. Usa il seguente AWS CLI comando per visualizzare maggiori dettagli sulla politica di scalabilità.
```
aws application-autoscaling describe-scaling-policies \
--service-namespace dynamodb \
--resource-id "table/TestTable" \
--policy-name "MyScalingPolicy"
```
1. Nell'output, verificare che le impostazioni delle policy corrispondano alle specifiche da [Fase 2: registrazione di una destinazione scalabile](#AutoScaling.CLI.RegisterScalableTarget) e [Fase 3: creazione di una policy di dimensionamento](#AutoScaling.CLI.CreateScalingPolicy).
## Passaggio 4: Indirizza il traffico di scrittura verso TestTable
Ora è possibile testare la policy di dimensionamento scrivendo i dati in `TestTable`. Per fare ciò, viene eseguito un programma Python.
1. Crea un file denominato `bulk-load-test-table.py` con i seguenti contenuti.
```
import boto3
dynamodb = boto3.resource('dynamodb')
table = dynamodb.Table("TestTable")
filler = "x" * 100000
i = 0
while (i < 10):
j = 0
while (j < 10):
print (i, j)
table.put_item(
Item={
'pk':i,
'sk':j,
'filler':{"S":filler}
}
)
j += 1
i += 1
```
1. Per eseguire il programma, immettere il comando seguente.
`python bulk-load-test-table.py`
La capacità di scrittura assegnata per `TestTable` è molto bassa (5 unità di capacità di scrittura), quindi il programma si blocca occasionalmente a causa della limitazione della scrittura. Questo è il comportamento previsto.
Lasciare che il programma continui a funzionare mentre si passa alla fase successiva.
## Fase 5: visualizzazione delle operazioni di Application Auto Scaling
In questa fase vengono visualizzate le operazioni di Application Auto Scaling che vengono avviate per conto tuo. Viene inoltre verificato che Application Auto Scaling abbia aggiornato la capacità di scrittura assegnata per `TestTable`.
1. Immettere il comando seguente per visualizzare le operazioni di Application Auto Scaling.
```
aws application-autoscaling describe-scaling-activities \
--service-namespace dynamodb
```
Eseguire di nuovo questo comando occasionalmente, mentre il programma Python è in esecuzione. Occorrono diversi minuti prima che la policy di dimensionamento venga richiamata. Dovrebbe essere visualizzato l'output riportato di seguito.
```
...
{
"ScalableDimension": "dynamodb:table:WriteCapacityUnits",
"Description": "Setting write capacity units to 10.",
"ResourceId": "table/TestTable",
"ActivityId": "0cc6fb03-2a7c-4b51-b67f-217224c6b656",
"StartTime": 1489088210.175,
"ServiceNamespace": "dynamodb",
"EndTime": 1489088246.85,
"Cause": "monitor alarm AutoScaling-table/TestTable-AlarmHigh-1bb3c8db-1b97-4353-baf1-4def76f4e1b9 in state ALARM triggered policy MyScalingPolicy",
"StatusMessage": "Successfully set write capacity units to 10. Change successfully fulfilled by dynamodb.",
"StatusCode": "Successful"
},
...
```
Ciò indica che Application Auto Scaling ha emesso una richiesta `UpdateTable` a DynamoDB.
1. Immettere il comando seguente per verificare che DynamoDB ha aumentato la capacità di scrittura della tabella.
```
aws dynamodb describe-table \
--table-name TestTable \
--query "Table.[TableName,TableStatus,ProvisionedThroughput]"
```
`WriteCapacityUnits` dovrebbe essersi dimensionato da `5` a `10`.
## (Opzionale) Fase 6: pulizia
In questo tutorial sono state create diverse risorse. È possibile eliminare queste risorse se non sono più necessarie.
1. Eliminare la policy di dimensionamento per `TestTable`.
```
aws application-autoscaling delete-scaling-policy \
--service-namespace dynamodb \
--resource-id "table/TestTable" \
--scalable-dimension "dynamodb:table:WriteCapacityUnits" \
--policy-name "MyScalingPolicy"
```
1. Annullare la registrazione di una destinazione scalabile.
```
aws application-autoscaling deregister-scalable-target \
--service-namespace dynamodb \
--resource-id "table/TestTable" \
--scalable-dimension "dynamodb:table:WriteCapacityUnits"
```
1. Eliminare la tabella `TestTable`.
```
aws dynamodb delete-table --table-name TestTable
```
# Utilizzo dell' AWS SDK per configurare la scalabilità automatica sulle tabelle Amazon DynamoDB
Oltre a utilizzare Console di gestione AWS and the AWS Command Line Interface (AWS CLI), puoi scrivere applicazioni che interagiscono con la scalabilità automatica di Amazon DynamoDB. Questa sezione contiene due programmi Java che puoi utilizzare per verificare questa funzionalità:
+ `EnableDynamoDBAutoscaling.java`
+ `DisableDynamoDBAutoscaling.java`
## Abilitazione di Application Auto Scaling per una tabella
Nel programma seguente viene riportato un esempio di configurazione di una policy di scalabilità automatica per una tabella DynamoDB (`TestTable`). Si procede nel seguente modo.
+ Il programma registra unità di capacità in scrittura come un obiettivo scalabile per `TestTable`. L'intervallo per questo parametro è compreso tra 5 e 10 unità di capacità di scrittura.
+ Dopo aver creato l'obiettivo scalabile, il programma sviluppa configurazioni di monitoraggio obiettivi. La policy cerca di mantenere un rapporto obiettivo del 50% tra capacità di scrittura utilizzata e capacità di scrittura assegnata.
+ In seguito, il programma crea la policy di dimensionamento in base alla configurazione di monitoraggio obiettivi.
**Nota**
Quando rimuovi manualmente una tabella o una replica globale di una tabella, non rimuovi automaticamente gli obiettivi scalabili, le politiche di scalabilità o gli allarmi associati. CloudWatch
------
#### [ Java v2 ]
```
import software.amazon.awssdk.regions.Region;
import software.amazon.awssdk.services.applicationautoscaling.ApplicationAutoScalingClient;
import software.amazon.awssdk.services.applicationautoscaling.model.ApplicationAutoScalingException;
import software.amazon.awssdk.services.applicationautoscaling.model.DescribeScalableTargetsRequest;
import software.amazon.awssdk.services.applicationautoscaling.model.DescribeScalableTargetsResponse;
import software.amazon.awssdk.services.applicationautoscaling.model.DescribeScalingPoliciesRequest;
import software.amazon.awssdk.services.applicationautoscaling.model.DescribeScalingPoliciesResponse;
import software.amazon.awssdk.services.applicationautoscaling.model.PolicyType;
import software.amazon.awssdk.services.applicationautoscaling.model.PredefinedMetricSpecification;
import software.amazon.awssdk.services.applicationautoscaling.model.PutScalingPolicyRequest;
import software.amazon.awssdk.services.applicationautoscaling.model.RegisterScalableTargetRequest;
import software.amazon.awssdk.services.applicationautoscaling.model.ScalingPolicy;
import software.amazon.awssdk.services.applicationautoscaling.model.ServiceNamespace;
import software.amazon.awssdk.services.applicationautoscaling.model.ScalableDimension;
import software.amazon.awssdk.services.applicationautoscaling.model.MetricType;
import software.amazon.awssdk.services.applicationautoscaling.model.TargetTrackingScalingPolicyConfiguration;
import java.util.List;
/**
* Before running this Java V2 code example, set up your development environment, including your credentials.
*
* For more information, see the following documentation topic:
*
* https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/get-started.html
*/
public class EnableDynamoDBAutoscaling {
public static void main(String[] args) {
final String usage = """
Usage:
\s
Where:
tableId - The table Id value (for example, table/Music).
roleARN - The ARN of the role that has ApplicationAutoScaling permissions.
policyName - The name of the policy to create.
""";
if (args.length != 3) {
System.out.println(usage);
System.exit(1);
}
System.out.println("This example registers an Amazon DynamoDB table, which is the resource to scale.");
String tableId = args[0];
String roleARN = args[1];
String policyName = args[2];
ServiceNamespace ns = ServiceNamespace.DYNAMODB;
ScalableDimension tableWCUs = ScalableDimension.DYNAMODB_TABLE_WRITE_CAPACITY_UNITS;
ApplicationAutoScalingClient appAutoScalingClient = ApplicationAutoScalingClient.builder()
.region(Region.US_EAST_1)
.build();
registerScalableTarget(appAutoScalingClient, tableId, roleARN, ns, tableWCUs);
verifyTarget(appAutoScalingClient, tableId, ns, tableWCUs);
configureScalingPolicy(appAutoScalingClient, tableId, ns, tableWCUs, policyName);
}
public static void registerScalableTarget(ApplicationAutoScalingClient appAutoScalingClient, String tableId, String roleARN, ServiceNamespace ns, ScalableDimension tableWCUs) {
try {
RegisterScalableTargetRequest targetRequest = RegisterScalableTargetRequest.builder()
.serviceNamespace(ns)
.scalableDimension(tableWCUs)
.resourceId(tableId)
.roleARN(roleARN)
.minCapacity(5)
.maxCapacity(10)
.build();
appAutoScalingClient.registerScalableTarget(targetRequest);
System.out.println("You have registered " + tableId);
} catch (ApplicationAutoScalingException e) {
System.err.println(e.awsErrorDetails().errorMessage());
}
}
// Verify that the target was created.
public static void verifyTarget(ApplicationAutoScalingClient appAutoScalingClient, String tableId, ServiceNamespace ns, ScalableDimension tableWCUs) {
DescribeScalableTargetsRequest dscRequest = DescribeScalableTargetsRequest.builder()
.scalableDimension(tableWCUs)
.serviceNamespace(ns)
.resourceIds(tableId)
.build();
DescribeScalableTargetsResponse response = appAutoScalingClient.describeScalableTargets(dscRequest);
System.out.println("DescribeScalableTargets result: ");
System.out.println(response);
}
// Configure a scaling policy.
public static void configureScalingPolicy(ApplicationAutoScalingClient appAutoScalingClient, String tableId, ServiceNamespace ns, ScalableDimension tableWCUs, String policyName) {
// Check if the policy exists before creating a new one.
DescribeScalingPoliciesResponse describeScalingPoliciesResponse = appAutoScalingClient.describeScalingPolicies(DescribeScalingPoliciesRequest.builder()
.serviceNamespace(ns)
.resourceId(tableId)
.scalableDimension(tableWCUs)
.build());
if (!describeScalingPoliciesResponse.scalingPolicies().isEmpty()) {
// If policies exist, consider updating an existing policy instead of creating a new one.
System.out.println("Policy already exists. Consider updating it instead.");
List polList = describeScalingPoliciesResponse.scalingPolicies();
for (ScalingPolicy pol : polList) {
System.out.println("Policy name:" +pol.policyName());
}
} else {
// If no policies exist, proceed with creating a new policy.
PredefinedMetricSpecification specification = PredefinedMetricSpecification.builder()
.predefinedMetricType(MetricType.DYNAMO_DB_WRITE_CAPACITY_UTILIZATION)
.build();
TargetTrackingScalingPolicyConfiguration policyConfiguration = TargetTrackingScalingPolicyConfiguration.builder()
.predefinedMetricSpecification(specification)
.targetValue(50.0)
.scaleInCooldown(60)
.scaleOutCooldown(60)
.build();
PutScalingPolicyRequest putScalingPolicyRequest = PutScalingPolicyRequest.builder()
.targetTrackingScalingPolicyConfiguration(policyConfiguration)
.serviceNamespace(ns)
.scalableDimension(tableWCUs)
.resourceId(tableId)
.policyName(policyName)
.policyType(PolicyType.TARGET_TRACKING_SCALING)
.build();
try {
appAutoScalingClient.putScalingPolicy(putScalingPolicyRequest);
System.out.println("You have successfully created a scaling policy for an Application Auto Scaling scalable target");
} catch (ApplicationAutoScalingException e) {
System.err.println("Error: " + e.awsErrorDetails().errorMessage());
}
}
}
}
```
------
#### [ Java v1 ]
Il programma richiede che venga specificato un Amazon Resource Name (ARN) per un ruolo collegato ai servizi di Application Auto Scaling valido. (Ad esempio: `arn:aws:iam::122517410325:role/AWSServiceRoleForApplicationAutoScaling_DynamoDBTable`.) Nel programma seguente, sostituisci `SERVICE_ROLE_ARN_GOES_HERE` con l'ARN reale.
```
package com.amazonaws.codesamples.autoscaling;
import com.amazonaws.services.applicationautoscaling.AWSApplicationAutoScalingClient;
import com.amazonaws.services.applicationautoscaling.AWSApplicationAutoScalingClientBuilder;
import com.amazonaws.services.applicationautoscaling.model.DescribeScalableTargetsRequest;
import com.amazonaws.services.applicationautoscaling.model.DescribeScalableTargetsResult;
import com.amazonaws.services.applicationautoscaling.model.DescribeScalingPoliciesRequest;
import com.amazonaws.services.applicationautoscaling.model.DescribeScalingPoliciesResult;
import com.amazonaws.services.applicationautoscaling.model.MetricType;
import com.amazonaws.services.applicationautoscaling.model.PolicyType;
import com.amazonaws.services.applicationautoscaling.model.PredefinedMetricSpecification;
import com.amazonaws.services.applicationautoscaling.model.PutScalingPolicyRequest;
import com.amazonaws.services.applicationautoscaling.model.RegisterScalableTargetRequest;
import com.amazonaws.services.applicationautoscaling.model.ScalableDimension;
import com.amazonaws.services.applicationautoscaling.model.ServiceNamespace;
import com.amazonaws.services.applicationautoscaling.model.TargetTrackingScalingPolicyConfiguration;
public class EnableDynamoDBAutoscaling {
static AWSApplicationAutoScalingClient aaClient = (AWSApplicationAutoScalingClient) AWSApplicationAutoScalingClientBuilder
.standard().build();
public static void main(String args[]) {
ServiceNamespace ns = ServiceNamespace.Dynamodb;
ScalableDimension tableWCUs = ScalableDimension.DynamodbTableWriteCapacityUnits;
String resourceID = "table/TestTable";
// Define the scalable target
RegisterScalableTargetRequest rstRequest = new RegisterScalableTargetRequest()
.withServiceNamespace(ns)
.withResourceId(resourceID)
.withScalableDimension(tableWCUs)
.withMinCapacity(5)
.withMaxCapacity(10)
.withRoleARN("SERVICE_ROLE_ARN_GOES_HERE");
try {
aaClient.registerScalableTarget(rstRequest);
} catch (Exception e) {
System.err.println("Unable to register scalable target: ");
System.err.println(e.getMessage());
}
// Verify that the target was created
DescribeScalableTargetsRequest dscRequest = new DescribeScalableTargetsRequest()
.withServiceNamespace(ns)
.withScalableDimension(tableWCUs)
.withResourceIds(resourceID);
try {
DescribeScalableTargetsResult dsaResult = aaClient.describeScalableTargets(dscRequest);
System.out.println("DescribeScalableTargets result: ");
System.out.println(dsaResult);
System.out.println();
} catch (Exception e) {
System.err.println("Unable to describe scalable target: ");
System.err.println(e.getMessage());
}
System.out.println();
// Configure a scaling policy
TargetTrackingScalingPolicyConfiguration targetTrackingScalingPolicyConfiguration = new TargetTrackingScalingPolicyConfiguration()
.withPredefinedMetricSpecification(
new PredefinedMetricSpecification()
.withPredefinedMetricType(MetricType.DynamoDBWriteCapacityUtilization))
.withTargetValue(50.0)
.withScaleInCooldown(60)
.withScaleOutCooldown(60);
// Create the scaling policy, based on your configuration
PutScalingPolicyRequest pspRequest = new PutScalingPolicyRequest()
.withServiceNamespace(ns)
.withScalableDimension(tableWCUs)
.withResourceId(resourceID)
.withPolicyName("MyScalingPolicy")
.withPolicyType(PolicyType.TargetTrackingScaling)
.withTargetTrackingScalingPolicyConfiguration(targetTrackingScalingPolicyConfiguration);
try {
aaClient.putScalingPolicy(pspRequest);
} catch (Exception e) {
System.err.println("Unable to put scaling policy: ");
System.err.println(e.getMessage());
}
// Verify that the scaling policy was created
DescribeScalingPoliciesRequest dspRequest = new DescribeScalingPoliciesRequest()
.withServiceNamespace(ns)
.withScalableDimension(tableWCUs)
.withResourceId(resourceID);
try {
DescribeScalingPoliciesResult dspResult = aaClient.describeScalingPolicies(dspRequest);
System.out.println("DescribeScalingPolicies result: ");
System.out.println(dspResult);
} catch (Exception e) {
e.printStackTrace();
System.err.println("Unable to describe scaling policy: ");
System.err.println(e.getMessage());
}
}
}
```
------
## Disabilitazione di Application Auto Scaling per una tabella
Nel programma seguente, il processo precedente viene invertito. Esso rimuove la policy di scalabilità automatica e annulla la registrazione dell'obiettivo scalabile.
------
#### [ Java v2 ]
```
import software.amazon.awssdk.regions.Region;
import software.amazon.awssdk.services.applicationautoscaling.ApplicationAutoScalingClient;
import software.amazon.awssdk.services.applicationautoscaling.model.ApplicationAutoScalingException;
import software.amazon.awssdk.services.applicationautoscaling.model.DeleteScalingPolicyRequest;
import software.amazon.awssdk.services.applicationautoscaling.model.DeregisterScalableTargetRequest;
import software.amazon.awssdk.services.applicationautoscaling.model.DescribeScalableTargetsRequest;
import software.amazon.awssdk.services.applicationautoscaling.model.DescribeScalableTargetsResponse;
import software.amazon.awssdk.services.applicationautoscaling.model.DescribeScalingPoliciesRequest;
import software.amazon.awssdk.services.applicationautoscaling.model.DescribeScalingPoliciesResponse;
import software.amazon.awssdk.services.applicationautoscaling.model.ScalableDimension;
import software.amazon.awssdk.services.applicationautoscaling.model.ServiceNamespace;
/**
* Before running this Java V2 code example, set up your development environment, including your credentials.
*
* For more information, see the following documentation topic:
*
* https://docs.aws.amazon.com/sdk-for-java/latest/developer-guide/get-started.html
*/
public class DisableDynamoDBAutoscaling {
public static void main(String[] args) {
final String usage = """
Usage:
\s
Where:
tableId - The table Id value (for example, table/Music).\s
policyName - The name of the policy (for example, $Music5-scaling-policy).
""";
if (args.length != 2) {
System.out.println(usage);
System.exit(1);
}
ApplicationAutoScalingClient appAutoScalingClient = ApplicationAutoScalingClient.builder()
.region(Region.US_EAST_1)
.build();
ServiceNamespace ns = ServiceNamespace.DYNAMODB;
ScalableDimension tableWCUs = ScalableDimension.DYNAMODB_TABLE_WRITE_CAPACITY_UNITS;
String tableId = args[0];
String policyName = args[1];
deletePolicy(appAutoScalingClient, policyName, tableWCUs, ns, tableId);
verifyScalingPolicies(appAutoScalingClient, tableId, ns, tableWCUs);
deregisterScalableTarget(appAutoScalingClient, tableId, ns, tableWCUs);
verifyTarget(appAutoScalingClient, tableId, ns, tableWCUs);
}
public static void deletePolicy(ApplicationAutoScalingClient appAutoScalingClient, String policyName, ScalableDimension tableWCUs, ServiceNamespace ns, String tableId) {
try {
DeleteScalingPolicyRequest delSPRequest = DeleteScalingPolicyRequest.builder()
.policyName(policyName)
.scalableDimension(tableWCUs)
.serviceNamespace(ns)
.resourceId(tableId)
.build();
appAutoScalingClient.deleteScalingPolicy(delSPRequest);
System.out.println(policyName +" was deleted successfully.");
} catch (ApplicationAutoScalingException e) {
System.err.println(e.awsErrorDetails().errorMessage());
}
}
// Verify that the scaling policy was deleted
public static void verifyScalingPolicies(ApplicationAutoScalingClient appAutoScalingClient, String tableId, ServiceNamespace ns, ScalableDimension tableWCUs) {
DescribeScalingPoliciesRequest dscRequest = DescribeScalingPoliciesRequest.builder()
.scalableDimension(tableWCUs)
.serviceNamespace(ns)
.resourceId(tableId)
.build();
DescribeScalingPoliciesResponse response = appAutoScalingClient.describeScalingPolicies(dscRequest);
System.out.println("DescribeScalableTargets result: ");
System.out.println(response);
}
public static void deregisterScalableTarget(ApplicationAutoScalingClient appAutoScalingClient, String tableId, ServiceNamespace ns, ScalableDimension tableWCUs) {
try {
DeregisterScalableTargetRequest targetRequest = DeregisterScalableTargetRequest.builder()
.scalableDimension(tableWCUs)
.serviceNamespace(ns)
.resourceId(tableId)
.build();
appAutoScalingClient.deregisterScalableTarget(targetRequest);
System.out.println("The scalable target was deregistered.");
} catch (ApplicationAutoScalingException e) {
System.err.println(e.awsErrorDetails().errorMessage());
}
}
public static void verifyTarget(ApplicationAutoScalingClient appAutoScalingClient, String tableId, ServiceNamespace ns, ScalableDimension tableWCUs) {
DescribeScalableTargetsRequest dscRequest = DescribeScalableTargetsRequest.builder()
.scalableDimension(tableWCUs)
.serviceNamespace(ns)
.resourceIds(tableId)
.build();
DescribeScalableTargetsResponse response = appAutoScalingClient.describeScalableTargets(dscRequest);
System.out.println("DescribeScalableTargets result: ");
System.out.println(response);
}
}
```
------
#### [ Java v1 ]
```
package com.amazonaws.codesamples.autoscaling;
import com.amazonaws.services.applicationautoscaling.AWSApplicationAutoScalingClient;
import com.amazonaws.services.applicationautoscaling.model.DeleteScalingPolicyRequest;
import com.amazonaws.services.applicationautoscaling.model.DeregisterScalableTargetRequest;
import com.amazonaws.services.applicationautoscaling.model.DescribeScalableTargetsRequest;
import com.amazonaws.services.applicationautoscaling.model.DescribeScalableTargetsResult;
import com.amazonaws.services.applicationautoscaling.model.DescribeScalingPoliciesRequest;
import com.amazonaws.services.applicationautoscaling.model.DescribeScalingPoliciesResult;
import com.amazonaws.services.applicationautoscaling.model.ScalableDimension;
import com.amazonaws.services.applicationautoscaling.model.ServiceNamespace;
public class DisableDynamoDBAutoscaling {
static AWSApplicationAutoScalingClient aaClient = new AWSApplicationAutoScalingClient();
public static void main(String args[]) {
ServiceNamespace ns = ServiceNamespace.Dynamodb;
ScalableDimension tableWCUs = ScalableDimension.DynamodbTableWriteCapacityUnits;
String resourceID = "table/TestTable";
// Delete the scaling policy
DeleteScalingPolicyRequest delSPRequest = new DeleteScalingPolicyRequest()
.withServiceNamespace(ns)
.withScalableDimension(tableWCUs)
.withResourceId(resourceID)
.withPolicyName("MyScalingPolicy");
try {
aaClient.deleteScalingPolicy(delSPRequest);
} catch (Exception e) {
System.err.println("Unable to delete scaling policy: ");
System.err.println(e.getMessage());
}
// Verify that the scaling policy was deleted
DescribeScalingPoliciesRequest descSPRequest = new DescribeScalingPoliciesRequest()
.withServiceNamespace(ns)
.withScalableDimension(tableWCUs)
.withResourceId(resourceID);
try {
DescribeScalingPoliciesResult dspResult = aaClient.describeScalingPolicies(descSPRequest);
System.out.println("DescribeScalingPolicies result: ");
System.out.println(dspResult);
} catch (Exception e) {
e.printStackTrace();
System.err.println("Unable to describe scaling policy: ");
System.err.println(e.getMessage());
}
System.out.println();
// Remove the scalable target
DeregisterScalableTargetRequest delSTRequest = new DeregisterScalableTargetRequest()
.withServiceNamespace(ns)
.withScalableDimension(tableWCUs)
.withResourceId(resourceID);
try {
aaClient.deregisterScalableTarget(delSTRequest);
} catch (Exception e) {
System.err.println("Unable to deregister scalable target: ");
System.err.println(e.getMessage());
}
// Verify that the scalable target was removed
DescribeScalableTargetsRequest dscRequest = new DescribeScalableTargetsRequest()
.withServiceNamespace(ns)
.withScalableDimension(tableWCUs)
.withResourceIds(resourceID);
try {
DescribeScalableTargetsResult dsaResult = aaClient.describeScalableTargets(dscRequest);
System.out.println("DescribeScalableTargets result: ");
System.out.println(dsaResult);
System.out.println();
} catch (Exception e) {
System.err.println("Unable to describe scalable target: ");
System.err.println(e.getMessage());
}
}
}
```
------
# Capacità riservata di DynamoDB
Per le tabelle con capacità allocata che utilizzano la [Classe tabella](HowItWorks.TableClasses.md) Standard, DynamoDB offre la possibilità di acquistare capacità riservata per lettura e scrittura. L’acquisto di capacità riservata è un accordo che prevede il pagamento di un importo minimo di capacità di throughput allocata per tutta la durata del contratto a fronte di prezzi scontati.
**Nota**
Non è possibile acquistare capacità riservata per unità di capacità di scrittura replicate (r). WCUs La capacità riservata viene applicata solo alla Regione in cui è stata acquistata. La capacità riservata non è disponibile nemmeno per le tabelle che utilizzano la classe di tabella DynamoDB Standard (accesso infrequente) o la modalità di capacità on demand.
La capacità riservata viene acquistata in allocazioni di 100 WCUs o 100. RCUs L’offerta di capacità riservata più piccola è di 100 unità di capacità (lettura o scrittura). La capacità riservata di DynamoDB viene offerta con un impegno annuale o, in alcune Regioni, con un impegno triennale. È possibile risparmiare fino al 54% sulle tariffe standard per un periodo di un anno e fino al 77% sulle tariffe standard per un periodo di tre anni. Per ulteriori informazioni sulle tempistiche e le modalità di acquisto, consulta [Amazon DynamoDB Reserved Capacity](https://aws.amazon.com/dynamodb/reserved-capacity/).
**Nota**
È possibile acquistare fino a un totale di 1.000.000 di unità di capacità riservata per unità di capacità di scrittura (WCUs) e unità di capacità di lettura (RCUs) utilizzando la AWS console di gestione. [Se desideri acquistare più di 1.000.000 di unità di capacità predisposta in un unico acquisto o avere una capacità riservata attiva e desideri acquistare capacità riservata aggiuntiva che comporterebbe più di 1.000.000 di unità di capacità allocata attive, segui la procedura descritta nella sezione «Come acquistare capacità riservata» in Amazon DynamoDB Reserved Capacity.](https://aws.amazon.com/dynamodb/reserved-capacity/)
Durante l’acquisto di capacità riservata di DynamoDB viene effettuato un pagamento anticipato parziale una tantum a fronte di una tariffa oraria scontata per l’utilizzo allocato impegnato. Il pagamento è per l’intero utilizzo allocato impegnato, indipendentemente dall’utilizzo effettivo, pertanto i risparmi sui costi sono strettamente legati all’utilizzo. Qualsiasi capacità allocata in eccesso rispetto alla capacità riservata acquistata viene fatturata alle tariffe standard della capacità allocata. Prenotando in anticipo le unità di capacità di lettura e scrittura, hai un risparmio significativo sui costi della capacità assegnata.
Non è possibile vendere, annullare o trasferire la capacità riservata a un’altra Regione o account.
# Funzionamento del throughput di DynamoDB
Il *throughput a caldo* si riferisce al numero di operazioni di lettura e scrittura che la tabella DynamoDB è in grado di supportare in modo istantaneo. Questi valori sono disponibili per impostazione predefinita per tutte le tabelle e gli indici secondari globali (GSI) e rappresentano il dimensionamento attuato in base all’utilizzo storico. Se si utilizza la modalità on demand o se si aggiorna il throughput allocato a questi valori, l’applicazione sarà in grado di emettere richieste fino a tali valori in modo istantaneo.
DynamoDB regolerà automaticamente i valori di throughput a caldo man mano che l’utilizzo aumenta. Puoi anche aumentare questi valori in modo proattivo quando necessario, il che è particolarmente utile per i prossimi eventi di punta come il lancio o la vendita di prodotti. Per gli eventi di picco pianificati, in cui i tassi di richiesta alla tabella DynamoDB potrebbero aumentare di 10, 100 volte o più, ora è possibile valutare se l’attuale throughput a caldo è sufficiente per gestire il traffico previsto. In caso negativo, è possibile aumentare il valore di throughput a caldo senza modificare le impostazioni di throughput o la [modalità di fatturazione](capacity-mode.md). Questo processo, denominato *pre-riscaldamento* di una tabella, consente di impostare una baseline che le tabelle possano supportare in modo istantaneo. Ciò garantisce che le applicazioni siano in grado di gestire tassi di richieste più elevati dal momento in cui si verificano. Una volta aumentati, i valori di resa a caldo non possono essere ridotti.
È possibile aumentare il valore di throughput a caldo per le operazioni di lettura, le operazioni di scrittura o entrambe. È possibile aumentare questo valore per tabelle a regione singola, tabelle globali e nuove ed esistenti. GSIs Per le tabelle globali, questa funzionalità è disponibile per la [versione 2019.11.21 (Corrente)](GlobalTables.md) e le impostazioni di throughput a caldo configurate verranno applicate automaticamente a tutte le tabelle di replica nella tabella globale. Non è previsto alcun limite per il numero di tabelle DynamoDB che è possibile pre-riscaldare in qualsiasi momento. Il tempo necessario per completare il pre-riscaldamento dipende dai valori impostati e dalla dimensione della tabella o dell’indice. È possibile inviare richieste di pre-riscaldamento simultanee e tali richieste non interferiranno con le operazioni della tabella. È possibile preriscaldare il tavolo fino al limite di quota della tabella o dell’indice previsto per l’account in quella Regione. Utilizza la [console Service Quotas](https://console.aws.amazon.com/servicequotas) per controllare i limiti attuali e aumentarli se necessario.
I valori di throughput a caldo sono disponibili per impostazione predefinita per tutte le tabelle e gli indici secondari senza alcun costo. Tuttavia, se si aumentano in modo proattivo questi valori di throughput caldo predefiniti per pre-riscaldare le tabelle, verranno addebitati i costi per tali richieste. Per ulteriori informazioni, consulta [Prezzi di Amazon DynamoDB](https://aws.amazon.com/dynamodb/pricing/).
Per ulteriori informazioni sul throughput a caldo, consulta gli argomenti riportati di seguito:
**Topics**
+ [
# Check your DynamoDB table’s current warm throughput
](check-warm-throughput.md)
+ [
# Aumento del throughput a caldo di una tabella DynamoDB esistente
](update-warm-throughput.md)
+ [
# Creazione di una nuova tabella DynamoDB con throughput caldo più elevato
](create-table-warm-throughput.md)
+ [
# Funzionamento del throughput a caldo di DynamoDB in diversi scenari
](warm-throughput-scenarios.md)
# Check your DynamoDB table’s current warm throughput
Utilizza le seguenti istruzioni AWS CLI e quelle AWS della Console per controllare il valore attuale della velocità effettiva a caldo della tabella o dell'indice.
## Console di gestione AWS
Per controllare il throughput a caldo di una tabella DynamoDB utilizzando la console DynamoDB:
1. Accedi Console di gestione AWS e apri la console DynamoDB all'indirizzo. [https://console.aws.amazon.com/dynamodb/](https://console.aws.amazon.com/dynamodb/)
1. Nel riquadro di navigazione a sinistra, selezionare Tables (Tabelle).
1. Nella pagina **Tabelle**, seleziona la tabella desiderata.
1. Seleziona **Impostazioni aggiuntive** per visualizzare il valore attuale del throughput a caldo. Questo valore viene visualizzato come unità di lettura al secondo e unità di scrittura al secondo.
## AWS CLI
L' AWS CLI esempio seguente mostra come controllare il throughput a caldo della tabella DynamoDB.
1. Esegui l’operazione `describe-table` sulla tabella DynamoDB.
```
aws dynamodb describe-table --table-name GameScores
```
1. Riceverai una risposta simile a quella seguente. Le impostazioni sul `WarmThroughput` verranno visualizzate come `ReadUnitsPerSecond` e`WriteUnitsPerSecond`. `Status` risulterà `UPDATING` quando verrà aggiornato il valore di throughput a caldo e `ACTIVE` quando sarà stato impostato il nuovo valore di throughput a caldo.
```
{
"Table": {
"AttributeDefinitions": [
{
"AttributeName": "GameTitle",
"AttributeType": "S"
},
{
"AttributeName": "TopScore",
"AttributeType": "N"
},
{
"AttributeName": "UserId",
"AttributeType": "S"
}
],
"TableName": "GameScores",
"KeySchema": [
{
"AttributeName": "UserId",
"KeyType": "HASH"
},
{
"AttributeName": "GameTitle",
"KeyType": "RANGE"
}
],
"TableStatus": "ACTIVE",
"CreationDateTime": 1726128388.729,
"ProvisionedThroughput": {
"NumberOfDecreasesToday": 0,
"ReadCapacityUnits": 0,
"WriteCapacityUnits": 0
},
"TableSizeBytes": 0,
"ItemCount": 0,
"TableArn": "arn:aws:dynamodb:us-east-1:XXXXXXXXXXXX:table/GameScores",
"TableId": "XXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX",
"BillingModeSummary": {
"BillingMode": "PAY_PER_REQUEST",
"LastUpdateToPayPerRequestDateTime": 1726128388.729
},
"GlobalSecondaryIndexes": [
{
"IndexName": "GameTitleIndex",
"KeySchema": [
{
"AttributeName": "GameTitle",
"KeyType": "HASH"
},
{
"AttributeName": "TopScore",
"KeyType": "RANGE"
}
],
"Projection": {
"ProjectionType": "INCLUDE",
"NonKeyAttributes": [
"UserId"
]
},
"IndexStatus": "ACTIVE",
"ProvisionedThroughput": {
"NumberOfDecreasesToday": 0,
"ReadCapacityUnits": 0,
"WriteCapacityUnits": 0
},
"IndexSizeBytes": 0,
"ItemCount": 0,
"IndexArn": "arn:aws:dynamodb:us-east-1:XXXXXXXXXXXX:table/GameScores/index/GameTitleIndex",
"WarmThroughput": {
"ReadUnitsPerSecond": 12000,
"WriteUnitsPerSecond": 4000,
"Status": "ACTIVE"
}
}
],
"DeletionProtectionEnabled": false,
"WarmThroughput": {
"ReadUnitsPerSecond": 12000,
"WriteUnitsPerSecond": 4000,
"Status": "ACTIVE"
}
}
}
```
# Aumento del throughput a caldo di una tabella DynamoDB esistente
Dopo aver verificato l’attuale valore di throughput a caldo della tabella DynamoDB, è possibile aggiornarla attraverso la seguente procedura:
## Console di gestione AWS
Come controllare il valore di throughput a caldo della tabella DynamoDB utilizzando la console DynamoDB:
1. Accedi Console di gestione AWS e apri la console DynamoDB all'indirizzo. [https://console.aws.amazon.com/dynamodb/](https://console.aws.amazon.com/dynamodb/)
1. Nel riquadro di navigazione a sinistra, selezionare Tables (Tabelle).
1. Nella pagina **Tabelle**, seleziona la tabella desiderata.
1. Nel campo **Throughput a caldo**, seleziona **Modifica**.
1. Nella pagina **Modifica il throughput effettivo**, seleziona **Aumentare il throughput a caldo**.
1. Regola le **Unità di lettura al secondo** e le **Unità di scrittura al secondo**. Queste due impostazioni definiscono il throughput che la tabella può gestire in modo istantaneo.
1. Seleziona **Salva**.
1. Le **unità di lettura al secondo** e le **unità di scrittura al secondo** verranno aggiornate nel campo **Throughput a caldo** al termine dell’elaborazione della richiesta.
**Nota**
L’aggiornamento del valore di throughput caldo è un’operazione asincrona. `Status` cambierà da `UPDATING` a `ACTIVE` quando l’aggiornamento sarà completo.
## AWS CLI
L' AWS CLI esempio seguente mostra come aggiornare il valore di throughput caldo della tabella DynamoDB.
1. Esegui l’operazione `update-table` sulla tabella DynamoDB.
```
aws dynamodb update-table \
--table-name GameScores \
--warm-throughput ReadUnitsPerSecond=12345,WriteUnitsPerSecond=4567 \
--global-secondary-index-updates \
"[
{
\"Update\": {
\"IndexName\": \"GameTitleIndex\",
\"WarmThroughput\": {
\"ReadUnitsPerSecond\": 88,
\"WriteUnitsPerSecond\": 77
}
}
}
]" \
--region us-east-1
```
1. Riceverai una risposta simile a quella seguente. Le impostazioni sul `WarmThroughput` verranno visualizzate come `ReadUnitsPerSecond` e`WriteUnitsPerSecond`. `Status` risulterà `UPDATING` quando verrà aggiornato il valore di throughput a caldo e `ACTIVE` quando sarà stato impostato il nuovo valore di throughput a caldo.
```
{
"TableDescription": {
"AttributeDefinitions": [
{
"AttributeName": "GameTitle",
"AttributeType": "S"
},
{
"AttributeName": "TopScore",
"AttributeType": "N"
},
{
"AttributeName": "UserId",
"AttributeType": "S"
}
],
"TableName": "GameScores",
"KeySchema": [
{
"AttributeName": "UserId",
"KeyType": "HASH"
},
{
"AttributeName": "GameTitle",
"KeyType": "RANGE"
}
],
"TableStatus": "ACTIVE",
"CreationDateTime": 1730242189.965,
"ProvisionedThroughput": {
"NumberOfDecreasesToday": 0,
"ReadCapacityUnits": 20,
"WriteCapacityUnits": 10
},
"TableSizeBytes": 0,
"ItemCount": 0,
"TableArn": "arn:aws:dynamodb:us-east-1:XXXXXXXXXXXX:table/GameScores",
"TableId": "XXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX",
"GlobalSecondaryIndexes": [
{
"IndexName": "GameTitleIndex",
"KeySchema": [
{
"AttributeName": "GameTitle",
"KeyType": "HASH"
},
{
"AttributeName": "TopScore",
"KeyType": "RANGE"
}
],
"Projection": {
"ProjectionType": "INCLUDE",
"NonKeyAttributes": [
"UserId"
]
},
"IndexStatus": "ACTIVE",
"ProvisionedThroughput": {
"NumberOfDecreasesToday": 0,
"ReadCapacityUnits": 50,
"WriteCapacityUnits": 25
},
"IndexSizeBytes": 0,
"ItemCount": 0,
"IndexArn": "arn:aws:dynamodb:us-east-1:XXXXXXXXXXXX:table/GameScores/index/GameTitleIndex",
"WarmThroughput": {
"ReadUnitsPerSecond": 50,
"WriteUnitsPerSecond": 25,
"Status": "UPDATING"
}
}
],
"DeletionProtectionEnabled": false,
"WarmThroughput": {
"ReadUnitsPerSecond": 12300,
"WriteUnitsPerSecond": 4500,
"Status": "UPDATING"
}
}
}
```
## AWS SDK
Gli esempi dell’SDK seguenti mostrano come aggiornare il valore di throughput a caldo di una tabella DynamoDB.
------
#### [ Java ]
```
import software.amazon.awssdk.services.dynamodb.DynamoDbClient;
import software.amazon.awssdk.services.dynamodb.model.DynamoDbException;
import software.amazon.awssdk.services.dynamodb.model.GlobalSecondaryIndexUpdate;
import software.amazon.awssdk.services.dynamodb.model.UpdateGlobalSecondaryIndexAction;
import software.amazon.awssdk.services.dynamodb.model.UpdateTableRequest;
import software.amazon.awssdk.services.dynamodb.model.WarmThroughput;
...
public static WarmThroughput buildWarmThroughput(final Long readUnitsPerSecond,
final Long writeUnitsPerSecond) {
return WarmThroughput.builder()
.readUnitsPerSecond(readUnitsPerSecond)
.writeUnitsPerSecond(writeUnitsPerSecond)
.build();
}
public static void updateDynamoDBTable(DynamoDbClient ddb,
String tableName,
Long tableReadUnitsPerSecond,
Long tableWriteUnitsPerSecond,
String globalSecondaryIndexName,
Long globalSecondaryIndexReadUnitsPerSecond,
Long globalSecondaryIndexWriteUnitsPerSecond) {
final WarmThroughput tableWarmThroughput = buildWarmThroughput(tableReadUnitsPerSecond, tableWriteUnitsPerSecond);
final WarmThroughput gsiWarmThroughput = buildWarmThroughput(globalSecondaryIndexReadUnitsPerSecond, globalSecondaryIndexWriteUnitsPerSecond);
final GlobalSecondaryIndexUpdate globalSecondaryIndexUpdate = GlobalSecondaryIndexUpdate.builder()
.update(UpdateGlobalSecondaryIndexAction.builder()
.indexName(globalSecondaryIndexName)
.warmThroughput(gsiWarmThroughput)
.build()
).build();
final UpdateTableRequest request = UpdateTableRequest.builder()
.tableName(tableName)
.globalSecondaryIndexUpdates(globalSecondaryIndexUpdate)
.warmThroughput(tableWarmThroughput)
.build();
try {
ddb.updateTable(request);
} catch (DynamoDbException e) {
System.err.println(e.getMessage());
System.exit(1);
}
System.out.println("Done!");
}
```
------
#### [ Python ]
```
from boto3 import resource
from botocore.exceptions import ClientError
def update_dynamodb_table_warm_throughput(table_name, table_read_units, table_write_units, gsi_name, gsi_read_units, gsi_write_units, region_name="us-east-1"):
"""
Updates the warm throughput of a DynamoDB table and a global secondary index.
:param table_name: The name of the table to update.
:param table_read_units: The new read units per second for the table's warm throughput.
:param table_write_units: The new write units per second for the table's warm throughput.
:param gsi_name: The name of the global secondary index to update.
:param gsi_read_units: The new read units per second for the GSI's warm throughput.
:param gsi_write_units: The new write units per second for the GSI's warm throughput.
:param region_name: The AWS Region name to target. defaults to us-east-1
"""
try:
ddb = resource('dynamodb', region_name)
# Update the table's warm throughput
table_warm_throughput = {
"ReadUnitsPerSecond": table_read_units,
"WriteUnitsPerSecond": table_write_units
}
# Update the global secondary index's warm throughput
gsi_warm_throughput = {
"ReadUnitsPerSecond": gsi_read_units,
"WriteUnitsPerSecond": gsi_write_units
}
# Construct the global secondary index update
global_secondary_index_update = [
{
"Update": {
"IndexName": gsi_name,
"WarmThroughput": gsi_warm_throughput
}
}
]
# Construct the update table request
update_table_request = {
"TableName": table_name,
"GlobalSecondaryIndexUpdates": global_secondary_index_update,
"WarmThroughput": table_warm_throughput
}
# Update the table
ddb.update_table(**update_table_request)
print("Table updated successfully!")
except ClientError as e:
print(f"Error updating table: {e}")
raise e
```
------
#### [ Javascript ]
```
import { DynamoDBClient, UpdateTableCommand } from "@aws-sdk/client-dynamodb";
async function updateDynamoDBTableWarmThroughput(
tableName,
tableReadUnits,
tableWriteUnits,
gsiName,
gsiReadUnits,
gsiWriteUnits,
region = "us-east-1"
) {
try {
const ddbClient = new DynamoDBClient({ region: region });
// Construct the update table request
const updateTableRequest = {
TableName: tableName,
GlobalSecondaryIndexUpdates: [
{
Update: {
IndexName: gsiName,
WarmThroughput: {
ReadUnitsPerSecond: gsiReadUnits,
WriteUnitsPerSecond: gsiWriteUnits,
},
},
},
],
WarmThroughput: {
ReadUnitsPerSecond: tableReadUnits,
WriteUnitsPerSecond: tableWriteUnits,
},
};
const command = new UpdateTableCommand(updateTableRequest);
const response = await ddbClient.send(command);
console.log(`Table updated successfully! Response: ${response}`);
} catch (error) {
console.error(`Error updating table: ${error}`);
throw error;
}
}
```
------
# Creazione di una nuova tabella DynamoDB con throughput caldo più elevato
È possibile regolare i valori di throughput a caldo quando si crea una tabella DynamoDB attraverso la procedura seguente. Queste fasi si applicano anche alla creazione di una [tabella globale](GlobalTables.md) o di un [indice secondario](SecondaryIndexes.md).
## Console di gestione AWS
Per creare una tabella DynamoDB e regolare i valori di throughput a caldo tramite la console:
1. Accedi Console di gestione AWS e apri la console DynamoDB all'indirizzo. [https://console.aws.amazon.com/dynamodb/](https://console.aws.amazon.com/dynamodb/)
1. Seleziona **Crea tabella**.
1. Seleziona un **Nome tabella**, una **Chiave di partizione** e una **Chiave di ordinamento (opzionale)**.
1. Per **Impostazioni tabella**, seleziona **Personalizza impostazioni**.
1. Nel campo **Throughput a caldo**, seleziona **Aumentare il throughput a caldo**.
1. Regola le **Unità di lettura al secondo** e le **Unità di scrittura al secondo**. Queste due impostazioni definiscono il throughput massimo che la tabella può gestire in modo istantaneo.
1. Continua ad aggiungere i dettagli rimanenti della tabella, quindi seleziona **Crea tabella**.
## AWS CLI
L' AWS CLI esempio seguente mostra come creare una tabella DynamoDB con valori di throughput caldi personalizzati.
1. Esegui l’operazione `create-table` per creare la seguente tabella DynamoDB.
```
aws dynamodb create-table \
--table-name GameScores \
--attribute-definitions AttributeName=UserId,AttributeType=S \
AttributeName=GameTitle,AttributeType=S \
AttributeName=TopScore,AttributeType=N \
--key-schema AttributeName=UserId,KeyType=HASH \
AttributeName=GameTitle,KeyType=RANGE \
--provisioned-throughput ReadCapacityUnits=20,WriteCapacityUnits=10 \
--global-secondary-indexes \
"[
{
\"IndexName\": \"GameTitleIndex\",
\"KeySchema\": [{\"AttributeName\":\"GameTitle\",\"KeyType\":\"HASH\"},
{\"AttributeName\":\"TopScore\",\"KeyType\":\"RANGE\"}],
\"Projection\":{
\"ProjectionType\":\"INCLUDE\",
\"NonKeyAttributes\":[\"UserId\"]
},
\"ProvisionedThroughput\": {
\"ReadCapacityUnits\": 50,
\"WriteCapacityUnits\": 25
},\"WarmThroughput\": {
\"ReadUnitsPerSecond\": 1987,
\"WriteUnitsPerSecond\": 543
}
}
]" \
--warm-throughput ReadUnitsPerSecond=12345,WriteUnitsPerSecond=4567 \
--region us-east-1
```
1. Riceverai una risposta simile a quella seguente. Le impostazioni sul `WarmThroughput` verranno visualizzate come `ReadUnitsPerSecond` e`WriteUnitsPerSecond`. `Status` risulterà `UPDATING` quando verrà aggiornato il valore di throughput a caldo e `ACTIVE` quando sarà stato impostato il nuovo valore di throughput a caldo.
```
{
"TableDescription": {
"AttributeDefinitions": [
{
"AttributeName": "GameTitle",
"AttributeType": "S"
},
{
"AttributeName": "TopScore",
"AttributeType": "N"
},
{
"AttributeName": "UserId",
"AttributeType": "S"
}
],
"TableName": "GameScores",
"KeySchema": [
{
"AttributeName": "UserId",
"KeyType": "HASH"
},
{
"AttributeName": "GameTitle",
"KeyType": "RANGE"
}
],
"TableStatus": "CREATING",
"CreationDateTime": 1730241788.779,
"ProvisionedThroughput": {
"NumberOfDecreasesToday": 0,
"ReadCapacityUnits": 20,
"WriteCapacityUnits": 10
},
"TableSizeBytes": 0,
"ItemCount": 0,
"TableArn": "arn:aws:dynamodb:us-east-1:XXXXXXXXXXXX:table/GameScores",
"TableId": "XXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX",
"GlobalSecondaryIndexes": [
{
"IndexName": "GameTitleIndex",
"KeySchema": [
{
"AttributeName": "GameTitle",
"KeyType": "HASH"
},
{
"AttributeName": "TopScore",
"KeyType": "RANGE"
}
],
"Projection": {
"ProjectionType": "INCLUDE",
"NonKeyAttributes": [
"UserId"
]
},
"IndexStatus": "CREATING",
"ProvisionedThroughput": {
"NumberOfDecreasesToday": 0,
"ReadCapacityUnits": 50,
"WriteCapacityUnits": 25
},
"IndexSizeBytes": 0,
"ItemCount": 0,
"IndexArn": "arn:aws:dynamodb:us-east-1:XXXXXXXXXXXX:table/GameScores/index/GameTitleIndex",
"WarmThroughput": {
"ReadUnitsPerSecond": 1987,
"WriteUnitsPerSecond": 543,
"Status": "UPDATING"
}
}
],
"DeletionProtectionEnabled": false,
"WarmThroughput": {
"ReadUnitsPerSecond": 12345,
"WriteUnitsPerSecond": 4567,
"Status": "UPDATING"
}
}
}
```
## AWS SDK
Gli esempi dell’SDK seguenti mostrano come creare una tabella DynamoDB con valori di throughput a caldo personalizzati.
------
#### [ Java ]
```
import software.amazon.awscdk.services.dynamodb.ProjectionType;
import software.amazon.awssdk.services.dynamodb.DynamoDbClient;
import software.amazon.awssdk.services.dynamodb.model.CreateTableResponse;
import software.amazon.awssdk.services.dynamodb.model.CreateTableRequest;
import software.amazon.awssdk.services.dynamodb.model.KeySchemaElement;
import software.amazon.awssdk.services.dynamodb.model.KeyType;
import software.amazon.awssdk.services.dynamodb.model.ProvisionedThroughput;
import software.amazon.awssdk.services.dynamodb.model.Projection;
import software.amazon.awssdk.services.dynamodb.model.GlobalSecondaryIndex;
import software.amazon.awssdk.services.dynamodb.model.AttributeDefinition;
import software.amazon.awssdk.services.dynamodb.model.ScalarAttributeType;
import software.amazon.awssdk.services.dynamodb.model.WarmThroughput;
...
public static WarmThroughput buildWarmThroughput(final Long readUnitsPerSecond,
final Long writeUnitsPerSecond) {
return WarmThroughput.builder()
.readUnitsPerSecond(readUnitsPerSecond)
.writeUnitsPerSecond(writeUnitsPerSecond)
.build();
}
private static AttributeDefinition buildAttributeDefinition(final String attributeName,
final ScalarAttributeType scalarAttributeType) {
return AttributeDefinition.builder()
.attributeName(attributeName)
.attributeType(scalarAttributeType)
.build();
}
private static KeySchemaElement buildKeySchemaElement(final String attributeName,
final KeyType keyType) {
return KeySchemaElement.builder()
.attributeName(attributeName)
.keyType(keyType)
.build();
}
public static void createDynamoDBTable(DynamoDbClient ddb,
String tableName,
String partitionKey,
String sortKey,
String miscellaneousKeyAttribute,
String nonKeyAttribute,
Long tableReadCapacityUnits,
Long tableWriteCapacityUnits,
Long tableWarmReadUnitsPerSecond,
Long tableWarmWriteUnitsPerSecond,
String globalSecondaryIndexName,
Long globalSecondaryIndexReadCapacityUnits,
Long globalSecondaryIndexWriteCapacityUnits,
Long globalSecondaryIndexWarmReadUnitsPerSecond,
Long globalSecondaryIndexWarmWriteUnitsPerSecond) {
// Define the table attributes
final AttributeDefinition partitionKeyAttribute = buildAttributeDefinition(partitionKey, ScalarAttributeType.S);
final AttributeDefinition sortKeyAttribute = buildAttributeDefinition(sortKey, ScalarAttributeType.S);
final AttributeDefinition miscellaneousKeyAttributeDefinition = buildAttributeDefinition(miscellaneousKeyAttribute, ScalarAttributeType.N);
final AttributeDefinition[] attributeDefinitions = {partitionKeyAttribute, sortKeyAttribute, miscellaneousKeyAttributeDefinition};
// Define the table key schema
final KeySchemaElement partitionKeyElement = buildKeySchemaElement(partitionKey, KeyType.HASH);
final KeySchemaElement sortKeyElement = buildKeySchemaElement(sortKey, KeyType.RANGE);
final KeySchemaElement[] keySchema = {partitionKeyElement, sortKeyElement};
// Define the provisioned throughput for the table
final ProvisionedThroughput provisionedThroughput = ProvisionedThroughput.builder()
.readCapacityUnits(tableReadCapacityUnits)
.writeCapacityUnits(tableWriteCapacityUnits)
.build();
// Define the Global Secondary Index (GSI)
final KeySchemaElement globalSecondaryIndexPartitionKeyElement = buildKeySchemaElement(sortKey, KeyType.HASH);
final KeySchemaElement globalSecondaryIndexSortKeyElement = buildKeySchemaElement(miscellaneousKeyAttribute, KeyType.RANGE);
final KeySchemaElement[] gsiKeySchema = {globalSecondaryIndexPartitionKeyElement, globalSecondaryIndexSortKeyElement};
final Projection gsiProjection = Projection.builder()
.projectionType(String.valueOf(ProjectionType.INCLUDE))
.nonKeyAttributes(nonKeyAttribute)
.build();
final ProvisionedThroughput gsiProvisionedThroughput = ProvisionedThroughput.builder()
.readCapacityUnits(globalSecondaryIndexReadCapacityUnits)
.writeCapacityUnits(globalSecondaryIndexWriteCapacityUnits)
.build();
// Define the warm throughput for the Global Secondary Index (GSI)
final WarmThroughput gsiWarmThroughput = buildWarmThroughput(globalSecondaryIndexWarmReadUnitsPerSecond, globalSecondaryIndexWarmWriteUnitsPerSecond);
final GlobalSecondaryIndex globalSecondaryIndex = GlobalSecondaryIndex.builder()
.indexName(globalSecondaryIndexName)
.keySchema(gsiKeySchema)
.projection(gsiProjection)
.provisionedThroughput(gsiProvisionedThroughput)
.warmThroughput(gsiWarmThroughput)
.build();
// Define the warm throughput for the table
final WarmThroughput tableWarmThroughput = buildWarmThroughput(tableWarmReadUnitsPerSecond, tableWarmWriteUnitsPerSecond);
final CreateTableRequest request = CreateTableRequest.builder()
.tableName(tableName)
.attributeDefinitions(attributeDefinitions)
.keySchema(keySchema)
.provisionedThroughput(provisionedThroughput)
.globalSecondaryIndexes(globalSecondaryIndex)
.warmThroughput(tableWarmThroughput)
.build();
CreateTableResponse response = ddb.createTable(request);
System.out.println(response);
}
```
------
#### [ Python ]
```
from boto3 import resource
from botocore.exceptions import ClientError
def create_dynamodb_table_warm_throughput(table_name, partition_key, sort_key, misc_key_attr, non_key_attr, table_provisioned_read_units, table_provisioned_write_units, table_warm_reads, table_warm_writes, gsi_name, gsi_provisioned_read_units, gsi_provisioned_write_units, gsi_warm_reads, gsi_warm_writes, region_name="us-east-1"):
"""
Creates a DynamoDB table with a warm throughput setting configured.
:param table_name: The name of the table to be created.
:param partition_key: The partition key for the table being created.
:param sort_key: The sort key for the table being created.
:param misc_key_attr: A miscellaneous key attribute for the table being created.
:param non_key_attr: A non-key attribute for the table being created.
:param table_provisioned_read_units: The newly created table's provisioned read capacity units.
:param table_provisioned_write_units: The newly created table's provisioned write capacity units.
:param table_warm_reads: The read units per second setting for the table's warm throughput.
:param table_warm_writes: The write units per second setting for the table's warm throughput.
:param gsi_name: The name of the Global Secondary Index (GSI) to be created on the table.
:param gsi_provisioned_read_units: The configured Global Secondary Index (GSI) provisioned read capacity units.
:param gsi_provisioned_write_units: The configured Global Secondary Index (GSI) provisioned write capacity units.
:param gsi_warm_reads: The read units per second setting for the Global Secondary Index (GSI)'s warm throughput.
:param gsi_warm_writes: The write units per second setting for the Global Secondary Index (GSI)'s warm throughput.
:param region_name: The AWS Region name to target. defaults to us-east-1
"""
try:
ddb = resource('dynamodb', region_name)
# Define the table attributes
attribute_definitions = [
{ "AttributeName": partition_key, "AttributeType": "S" },
{ "AttributeName": sort_key, "AttributeType": "S" },
{ "AttributeName": misc_key_attr, "AttributeType": "N" }
]
# Define the table key schema
key_schema = [
{ "AttributeName": partition_key, "KeyType": "HASH" },
{ "AttributeName": sort_key, "KeyType": "RANGE" }
]
# Define the provisioned throughput for the table
provisioned_throughput = {
"ReadCapacityUnits": table_provisioned_read_units,
"WriteCapacityUnits": table_provisioned_write_units
}
# Define the global secondary index
gsi_key_schema = [
{ "AttributeName": sort_key, "KeyType": "HASH" },
{ "AttributeName": misc_key_attr, "KeyType": "RANGE" }
]
gsi_projection = {
"ProjectionType": "INCLUDE",
"NonKeyAttributes": [non_key_attr]
}
gsi_provisioned_throughput = {
"ReadCapacityUnits": gsi_provisioned_read_units,
"WriteCapacityUnits": gsi_provisioned_write_units
}
gsi_warm_throughput = {
"ReadUnitsPerSecond": gsi_warm_reads,
"WriteUnitsPerSecond": gsi_warm_writes
}
global_secondary_indexes = [
{
"IndexName": gsi_name,
"KeySchema": gsi_key_schema,
"Projection": gsi_projection,
"ProvisionedThroughput": gsi_provisioned_throughput,
"WarmThroughput": gsi_warm_throughput
}
]
# Define the warm throughput for the table
warm_throughput = {
"ReadUnitsPerSecond": table_warm_reads,
"WriteUnitsPerSecond": table_warm_writes
}
# Create the DynamoDB client and create the table
response = ddb.create_table(
TableName=table_name,
AttributeDefinitions=attribute_definitions,
KeySchema=key_schema,
ProvisionedThroughput=provisioned_throughput,
GlobalSecondaryIndexes=global_secondary_indexes,
WarmThroughput=warm_throughput
)
print(response)
except ClientError as e:
print(f"Error creating table: {e}")
raise e
```
------
#### [ Javascript ]
```
import { DynamoDBClient, CreateTableCommand } from "@aws-sdk/client-dynamodb";
async function createDynamoDBTableWithWarmThroughput(
tableName,
partitionKey,
sortKey,
miscKeyAttr,
nonKeyAttr,
tableProvisionedReadUnits,
tableProvisionedWriteUnits,
tableWarmReads,
tableWarmWrites,
indexName,
indexProvisionedReadUnits,
indexProvisionedWriteUnits,
indexWarmReads,
indexWarmWrites,
region = "us-east-1"
) {
try {
const ddbClient = new DynamoDBClient({ region: region });
const command = new CreateTableCommand({
TableName: tableName,
AttributeDefinitions: [
{ AttributeName: partitionKey, AttributeType: "S" },
{ AttributeName: sortKey, AttributeType: "S" },
{ AttributeName: miscKeyAttr, AttributeType: "N" },
],
KeySchema: [
{ AttributeName: partitionKey, KeyType: "HASH" },
{ AttributeName: sortKey, KeyType: "RANGE" },
],
ProvisionedThroughput: {
ReadCapacityUnits: tableProvisionedReadUnits,
WriteCapacityUnits: tableProvisionedWriteUnits,
},
WarmThroughput: {
ReadUnitsPerSecond: tableWarmReads,
WriteUnitsPerSecond: tableWarmWrites,
},
GlobalSecondaryIndexes: [
{
IndexName: indexName,
KeySchema: [
{ AttributeName: sortKey, KeyType: "HASH" },
{ AttributeName: miscKeyAttr, KeyType: "RANGE" },
],
Projection: {
ProjectionType: "INCLUDE",
NonKeyAttributes: [nonKeyAttr],
},
ProvisionedThroughput: {
ReadCapacityUnits: indexProvisionedReadUnits,
WriteCapacityUnits: indexProvisionedWriteUnits,
},
WarmThroughput: {
ReadUnitsPerSecond: indexWarmReads,
WriteUnitsPerSecond: indexWarmWrites,
},
},
],
});
const response = await ddbClient.send(command);
console.log(response);
} catch (error) {
console.error(`Error creating table: ${error}`);
throw error;
}
}
```
------
# Funzionamento del throughput a caldo di DynamoDB in diversi scenari
Di seguito sono riportati alcuni scenari diversi che possono verificarsi durante l’utilizzo del throughput a caldo di DynamoDB.
**Topics**
+ [
## Throughput a caldo e modelli di accesso irregolari
](#warm-throughput-scenarios-uneven)
+ [
## Throughput a caldo per una tabella con provisioning
](#warm-throughput-scenarios-provisioned)
+ [
## Throughput a caldo per una tabella on demand
](#warm-throughput-scenarios-ondemand)
+ [
## Throughput a caldo per una tabella on demand con un throughput massimo configurato
](#warm-throughput-scenarios-max)
## Throughput a caldo e modelli di accesso irregolari
Una tabella può avere un throughput di 30.000 unità di lettura al secondo e 10.000 unità di scrittura al secondo, ma è comunque possibile che si verifichi una limitazione (della larghezza di banda della rete) delle operazioni di lettura o scrittura prima di raggiungere tali valori. Ciò è probabilmente dovuto a una partizione calda. Sebbene DynamoDB possa continuare a scalare per supportare un throughput praticamente illimitato, ogni singola partizione è limitata a 1.000 unità di scrittura al secondo e 3.000 unità di lettura al secondo. Se l’applicazione indirizza troppo traffico verso una piccola parte delle partizioni della tabella, la limitazione (della larghezza di banda della rete) può verificarsi anche prima di raggiungere i valori di throughput a caldo della tabella. Si consiglia di seguire le [best practice di DynamoDB](bp-partition-key-design.md) per garantire una scalabilità perfetta ed evitare partizioni calde.
## Throughput a caldo per una tabella con provisioning
Si prenda in considerazione una tabella con provisioning con un throughput a caldo di 30.000 unità di lettura al secondo e 10.000 unità di scrittura al secondo, ma che attualmente ha un throughput allocato di 4.000 RCU e 8.000 WCU. È possibile scalare istantaneamente il throughput allocato alla tabella fino a 30.000 RCU o 10.000 WCU aggiornando le impostazioni di throughput allocato. Quando si aumenta il throughput allocato oltre questi valori, il throughput a caldo si adeguerà automaticamente ai nuovi valori più alti, poiché è stato impostato un nuovo throughput di picco. Ad esempio, se si imposta il throughput allocato su 50.000 RCU, il throughput a caldo aumenterà a 50.000 unità di lettura al secondo.
```
"ProvisionedThroughput":
{
"ReadCapacityUnits": 4000,
"WriteCapacityUnits": 8000
}
"WarmThroughput":
{
"ReadUnitsPerSecond": 30000,
"WriteUnitsPerSecond": 10000
}
```
## Throughput a caldo per una tabella on demand
Una nuova tabella on demand inizia con un throughput a caldo di 12.000 unità di lettura al secondo e 4.000 unità di scrittura al secondo. La tabella può supportare in modo istantaneo un traffico sostenuto fino a questi livelli. Quando le richieste superano le 12.000 unità di lettura al secondo o le 4.000 unità di scrittura al secondo, il throughput a caldo si adeguerà automaticamente a valori più alti.
```
"WarmThroughput":
{
"ReadUnitsPerSecond": 12000,
"WriteUnitsPerSecond": 4000
}
```
## Throughput a caldo per una tabella on demand con un throughput massimo configurato
Si prenda in considerazione una tabella on demand con una throughput a caldo di 30.000 unità di lettura al secondo, ma con un [throughput massimo](on-demand-capacity-mode-max-throughput.md) configurato a 5.000 unità di richiesta di lettura (RRU). In questo scenario, il throughput della tabella sarà limitato al massimo di 5.000 RRU impostate. Tutte le richieste di throughput che superano questo limite subiranno una limitazione (della larghezza di banda della rete). Tuttavia, è possibile modificare il throughput massimo specifico della tabella in qualsiasi momento in base alle esigenze dell’applicazione.
```
"OnDemandThroughput":
{
"MaxReadRequestUnits": 5000,
"MaxWriteRequestUnits": 4000
}
"WarmThroughput":
{
"ReadUnitsPerSecond": 30000,
"WriteUnitsPerSecond": 10000
}
```
# Capacità di espansione e capacità adattiva di DynamoDB
Per ridurre al minimo la limitazione (della larghezza di banda della rete) dovuta alle eccezioni di throughput, DynamoDB utilizza la *capacità di espansione* per gestire i picchi di utilizzo. DynamoDB utilizza la *capacità adattiva* per aiutare a gestire modelli di accesso irregolari.
## Capacità di ottimizzazione
DynamoDB garantisce una certa flessibilità nell'assegnazione della velocità di trasmissione effettiva grazie alla *capacità di espansione*. Quando non si utilizza completamente il throughput di una partizione, DynamoDB riserva una parte della capacità inutilizzata per successive *espansioni* del throughput per la gestione dei picchi di traffico. Con la capacità supplementare, le richieste di lettura o scrittura impreviste possono avere esito positivo anziché essere sottoposte a throttling.
DynamoDB attualmente mantiene fino a cinque minuti (300 secondi) di capacità di lettura e scrittura non utilizzata. Durante un’espansione occasionale di attività di lettura o scrittura, queste unità di capacità extra possono essere utilizzate rapidamente, anche più velocemente della capacità di throughput allocata al secondo definita per la tabella.
DynamoDB può inoltre utilizzare la capacità di ottimizzazione per la manutenzione in background e altre attività senza preavviso.
Tieni presente che tali dettagli della capacità di ottimizzazione in futuro potrebbero cambiare.
## Capacità adattiva
DynamoDB distribuisce automaticamente i dati tra le [partizioni](HowItWorks.Partitions.md), che sono archiviate su più server nel Cloud AWS. Non sempre è possibile distribuire l’attività di lettura e scrittura in modo uniforme. Se l'accesso ai dati non è equilibrato, una partizione "hot" può ricevere un volume più elevato di traffico di lettura e scrittura rispetto ad altre partizioni. Poiché le operazioni di lettura e scrittura su una partizione vengono gestite in modo indipendente, si verificherà la limitazione (della larghezza di banda della rete) se una singola partizione riceve più di 3000 operazioni di lettura o più di 1000 operazioni di scrittura. La capacità adattiva funziona aumentando automaticamente la capacità di throughput per le partizioni che ricevono più traffico.
Per gestire meglio i modelli di accesso non uniformi, la capacità adattiva di DynamoDB permette all'applicazione di continuare con le attività di lettura e scrittura sulle partizioni hot senza che si verifichi una limitazione, a condizione che tale traffico non superi la capacità totale assegnata alla tabella o la capacità massima della partizione. La capacità adattiva funziona aumentando automaticamente la capacità di throughput per le partizioni che ricevono più traffico.
Nel diagramma seguente viene illustrato il funzionamento della capacità adattiva. Nella tabella di esempio sono disponibili 400 partizioni distribuite in WCUs modo uniforme su quattro partizioni, che consentono a ciascuna partizione di supportare fino a 100 al secondo. WCUs Le partizioni 1, 2 e 3 ricevono ciascuna un traffico di scrittura pari a 50. WCU/sec. Partition 4 receives 150 WCU/sec. This hot partition can accept write traffic while it still has unused burst capacity, but eventually it throttles traffic that exceeds 100 WCU/sec
La capacità adattiva di DynamoDB risponde aumentando la capacità della partizione 4 in modo che possa sostenere il carico di lavoro più elevato di 150 senza subire limitazioni. WCU/sec
![\[La capacità adattiva aumenta automaticamente il throughput per la partizione 4 con traffico più elevato per evitare la limitazione (della larghezza di banda della rete).\]](http://docs.aws.amazon.com/it_it/amazondynamodb/latest/developerguide/images/adaptive-capacity.png)
La capacità adattiva è abilitata automaticamente per tutte le tabelle DynamoDB, senza costi aggiuntivi. Non è necessario abilitarla o disabilitarla esplicitamente.
### Isolare gli elementi con accesso frequente
Se l'applicazione instrada un traffico elevato in modo sproporzionato verso uno o più elementi, la capacità adattiva eseguirà un bilanciamento delle partizioni, affinché gli elementi ad accesso frequente non siano ubicati all'interno della stessa partizione. Questo isolamento degli elementi ad accesso frequente riduce la probabilità di throttling delle richieste a causa del superamento della quota del throughput del carico di lavoro su una singola partizione. Puoi anche suddividere una raccolta di elementi in segmenti in base alla chiave di ordinamento, purché tale raccolta non generi traffico monitorato da un aumento o una diminuzione monotoni della chiave di ordinamento.
Se l'applicazione invia in modo coerente traffico elevato a un singolo elemento, la capacità adattiva può riequilibrare i dati in modo tale che una partizione contenga solo quel singolo elemento con accesso frequente. In questo caso, DynamoDB può fornire un throughput fino alla partizione massima di RCUs 3.000 e WCUs 1.000 alla chiave primaria di quel singolo elemento. La capacità adattiva non suddivide le raccolte di elementi su più partizioni della tabella quando è presente un [indice secondario locale](LSI.md).
# Considerazioni sul passaggio tra modalità di capacità in DynamoDB
Quando crei una tabella DynamoDB, devi selezionare la modalità di capacità on demand o la modalità di capacità assegnata.
È possibile cambiare le tabelle dalla modalità con capacità allocata alla modalità on demand fino a quattro volte in una finestra variabile di 24 ore. È possibile passare le tabelle dalla modalità on demand alla modalità con capacità allocata in qualsiasi momento.
**Topics**
+ [
## Passaggio dalla modalità con capacità allocata alla modalità con capacità on demand
](#switch-provisioned-to-ondemand)
+ [
## Passaggio dalla modalità con capacità on demand alla modalità con capacità allocata
](#switch-ondemand-to-provisioned)
## Passaggio dalla modalità con capacità allocata alla modalità con capacità on demand
In modalità con provisioning è possibile impostare la capacità di lettura e scrittura in base alle esigenze previste dell’applicazione. Quando si aggiorna una tabella dalla modalità assegnata a quella on demand, non è necessario specificare quanto throughput di lettura e scrittura si prevede che l'applicazione esegua. DynamoDB on-demand offre prezzi pay-per-request semplici per le richieste di lettura e scrittura in modo da pagare solo per ciò che si utilizza, facilitando il bilanciamento di costi e prestazioni. Facoltativamente, è possibile configurare il throughput massimo di lettura o di scrittura (o entrambi) per le singole tabelle on demand e gli indici secondari globali associati per mantenere costi e utilizzo limitati. Per ulteriori informazioni sull’impostazione del throughput massimo per una tabella o un indice specifico, consulta [Throughput massimo di DynamoDB per le tabelle on demand](on-demand-capacity-mode-max-throughput.md).
Quando si passa dalla modalità con capacità allocata alla modalità con capacità on demand, DynamoDB apporta numerosi cambiamenti alla struttura della tabella e delle partizioni. Questo processo può richiedere alcuni minuti. Durante la durata del passaggio, la tabella assicura un throughput consistente con l'unità di capacità in scrittura precedentemente assegnata e le quantità di unità di capacità.
### Velocità di trasmissione effettiva iniziale per la modalità di capacità on demand
Se una tabella esistente è recentemente passata alla modalità con capacità on demand per la prima volta, disporrà delle seguenti impostazioni del picco precedente, nonostante in precedenza la tabella non abbia gestito il traffico tramite la modalità con capacità on demand.
Di seguito sono riportati alcuni esempi di possibili scenari:
+ **Qualsiasi tabella con provisioning configurato al di sotto di 4000 WCU e 12.000 RCU, per cui non sia mai stato precedentemente allocato un numero superiore**. Quando passi questa tabella a on-demand per la prima volta, DynamoDB si assicurerà che sia scalabile per supportare istantaneamente almeno 4.000 unità di scrittura e 12.000 unità di lettura/sec. units/sec
+ **Una tabella con provisioning configurato come 8.000 WCU e 24.000 RCU.** Quando passi a questa tabella su richiesta, continuerà a essere in grado di supportare almeno 8.000 operazioni di scrittura e 24.000 letture in qualsiasi momento. units/sec units/sec
+ **Una tabella predisposta configurata con 8.000 WCU e 24.000 RCU, che ha consumato 6.000 operazioni di scrittura e 18.000 letture per un periodo prolungato. units/sec units/sec ** Quando passi a questa tabella su richiesta, continuerà a essere in grado di supportare almeno 8.000 unità di scrittura e 24.000 unità di lettura/sec. units/sec Il traffico precedente può inoltre consentire alla tabella di sostenere livelli di traffico molto più elevati senza limitazione della larghezza di banda della rete.
+ **Una tabella precedentemente assegnata con 10.000 WCU e 10.000 RCU, ma attualmente assegnata con 10 RCU e 10 WCU.** Passando a questa tabella su richiesta, sarà in grado di supportare almeno 10.000 unità di scrittura e 10.000 unità di lettura/sec. units/sec
### Impostazioni di dimensionamento automatico
Quando aggiorni una tabella dalla modalità assegnata a quella on demand:
+ Se utilizzi la console, tutte le (eventuali) impostazioni di scalabilità automatica verranno eliminate.
+ Se utilizzi l' AWS SDK AWS CLI o, tutte le impostazioni di ridimensionamento automatico verranno mantenute. Queste impostazioni possono essere applicate quando aggiorni nuovamente la tabella alla modalità di fatturazione assegnata.
### Modifica della modalità di capacità in blocco nella [console DynamoDB](https://console.aws.amazon.com/dynamodb)
È possibile modificare in blocco più tabelle perché passino dalla modalità con capacità allocata alla modalità con capacità on demand utilizzando la [console DynamoDB](https://console.aws.amazon.com/dynamodb). Come modificare in blocco la modalità di capacità:
1. Nella console DynamoDB apri la pagina **Tabelle**.
1. Seleziona le caselle di spunta per le tabelle che desideri aggiornare alla modalità con capacità on demand.
1. Seleziona **Operazioni**, quindi seleziona **Aggiorna la modalità di capacità su richiesta**.
Questa operazione in blocco consente di effettuare in modo efficiente il passaggio per più tabelle alla modalità con capacità on demand senza dover aggiornare ogni tabella singolarmente.
## Passaggio dalla modalità con capacità on demand alla modalità con capacità allocata
Durante il ritorno alla modalità di capacità assegnata, a partire dalla modalità di capacità on demand, la tabella assicura un throughput consistente con il picco precedente raggiunto quando la tabella era impostata sulla modalità di capacità on demand.
### Gestione della capacità
Quando aggiorni una tabella dalla modalità on demand a quella assegnata, considera quanto segue:
+ Se utilizzi l' AWS SDK AWS CLI o, scegli le impostazioni di capacità assegnate corrette della tabella e degli indici secondari globali utilizzando Amazon CloudWatch per esaminare il consumo storico (`ConsumedWriteCapacityUnits`e le `ConsumedReadCapacityUnits` metriche) per determinare le nuove impostazioni di throughput.
**Nota**
Se sposti una tabella globale alla modalità assegnata, osserva il consumo massimo tra tutte le repliche regionali per le tabelle di base e gli indici secondari globali quando stabilisci le nuove impostazioni di throughput.
+ In caso di ritorno dalla modalità on demand alla modalità con capacità allocata, è necessario impostare un numero sufficiente di unità allocate iniziali in modo da gestire la capacità della tabella o dell’indice durante la transizione.
### Gestione del dimensionamento automatico
Quando aggiorni una tabella dalla modalità on demand a quella assegnata:
+ In caso di utilizzo della console, si consiglia di abilitare il dimensionamento automatico con le impostazioni predefinite seguenti:
+ Utilizzo di destinazione: 70%
+ Capacità minima assegnata: 5 unità
+ Capacità massima assegnata: il massimo delle regioni
+ Se utilizzi l'SDK AWS CLI o, le impostazioni di ridimensionamento automatico precedenti (se presenti) vengono mantenute.