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à.
Valutare la capacità fornita per un provisioning di dimensioni adeguate
In questa sezione viene fornita una panoramica su come valutare se il provisioning è di dimensioni appropriate per le tabelle DynamoDB. Man mano che il carico di lavoro si evolve, è necessario modificare le procedure operative in modo appropriato, soprattutto quando la tabella DynamoDB è configurata in modalità assegnata e si corre il rischio di provisioning eccessivo o insufficiente delle tabelle.
Le procedure descritte di seguito richiedono informazioni statistiche che devono essere acquisite dalle tabelle DynamoDB che supportano l'applicazione di produzione. Per comprendere il comportamento dell'applicazione, è necessario definire un periodo di tempo sufficientemente significativo per acquisire la stagionalità dei dati dall'applicazione. Ad esempio, se l'applicazione mostra pattern settimanali, l'utilizzo di un periodo di tre settimane dovrebbe fornire spazio sufficiente per analizzare le esigenze di velocità di trasmissione effettiva dell'applicazione.
Se non sai da dove iniziare, utilizza almeno un mese di utilizzo dei dati per i calcoli seguenti.
Durante la valutazione della capacità, le tabelle DynamoDB possono configurare le unità di capacità di lettura (RCU) e le unità di capacità di scrittura (WCU) in modo indipendente. Se nelle tabelle sono configurati degli indici secondari globali (GSI), sarà necessario specificare la velocità di trasmissione effettiva che consumeranno, che sarà anche indipendente dalle RCU e dalle WCU della tabella di base.
Nota
Gli indici secondari locali (LSI) utilizzano la capacità della tabella di base.
Argomenti
Come recuperare le metriche di consumo nelle tabelle DynamoDB
Per valutare la tabella e la capacità del GSI, monitora le seguenti CloudWatch metriche e seleziona la dimensione appropriata per recuperare le informazioni della tabella o del GSI:
| unità di capacità in lettura | Unità di capacità in scrittura |
|---|---|
|
|
|
|
|
|
|
|
|
È possibile eseguire questa operazione tramite o il. AWS CLI AWS Management Console
Come identificare le tabelle DynamoDB con un provisioning insufficiente
Per la maggior parte dei carichi di lavoro, una tabella è considerata con provisioning insufficiente quando consuma costantemente più dell'80% della capacità assegnata.
La capacità di espansione è una funzionalità di DynamoDB che consente ai clienti di utilizzare temporaneamente più RCU/WCU rispetto a quanto originariamente previsto (più della velocità di trasmissione effettiva assegnata al secondo definita nella tabella). La capacità di espansione è stata creata per assorbire improvvisi aumenti di traffico dovuti a eventi speciali o picchi di utilizzo. Questa capacità di espansione ha una durata limitata. Non appena le RCU e le WCU inutilizzate si esauriscono, se si tenta di utilizzare più capacità di quella assegnata, si verificherà una limitazione. Quando il traffico delle applicazioni si avvicina al tasso di utilizzo dell'80%, il rischio di limitazione della larghezza di banda della rete è notevolmente maggiore.
La regola del tasso di utilizzo dell'80% varia in base alla stagionalità dei dati e alla crescita del traffico. Considerare i seguenti scenari:
-
Se il traffico è rimasto stabile a un tasso di utilizzo di circa il 90% negli ultimi 12 mesi, la tabella ha la capacità corretta
-
Se il traffico delle applicazioni aumenta a un tasso dell'8% mensile in meno di 3 mesi, si arriverà al 100%
-
Se il traffico delle applicazioni aumenta a un tasso dell'5% mensile in meno di 4 mesi, si arriverà al 100%
I risultati delle query precedenti forniscono un'immagine del tasso di utilizzo. Utilizzali come guida per valutare ulteriormente altre metriche che possono aiutarti a scegliere di aumentare la capacità della tabella in base alle esigenze (ad esempio: un tasso di crescita mensile o settimanale). Collabora con il tuo team operativo per definire qual è una buona percentuale per il carico di lavoro e le tabelle.
Esistono scenari speciali in cui i dati non sono affidabili quando li analizziamo su base giornaliera o settimanale. Ad esempio, con le applicazioni stagionali che presentano picchi di utilizzo durante l'orario di lavoro (ma poi scendono quasi a zero al di fuori dell'orario di lavoro), è possibile trarre vantaggio dalla pianificazione della scalabilità automatica in cui si specificano le ore del giorno (e i giorni della settimana) per aumentare la capacità fornita e quando ridurla. Invece di puntare a una maggiore capacità in modo da coprire le ore di punta, puoi anche trarre vantaggio dalle configurazioni di scalabilità automatica delle tabelle di DynamoDB se la stagionalità è meno pronunciata.
Nota
Quando crei una configurazione del dimensionamento automatico di DynamoDB per la tabella di base, ricordati di includere un'altra configurazione per tutti i GSI associati alla tabella.
Come identificare le tabelle DynamoDB con provisioning eccessivo
I risultati delle query ottenuti dagli script precedenti forniscono i dati necessari per eseguire alcune analisi iniziali. Se il set di dati presenta valori di utilizzo inferiori al 20% per diversi intervalli, è possibile che la tabella presenti un provisioning eccessivo. Per definire ulteriormente se è necessario ridurre il numero di WCU e RCU, è necessario riesaminare le altre letture negli intervalli.
Quando le tabelle contengono diversi intervalli di utilizzo ridotti, puoi davvero trarre vantaggio dall'utilizzo di politiche di auto scaling, pianificando la scalabilità automatica o semplicemente configurando le politiche di auto scaling predefinite per la tabella basate sull'utilizzo.
Se hai un carico di lavoro con un basso utilizzo e un rapporto accelerazione elevato (Max (ThrottleEvents) /Min (ThrottleEvents) nell'intervallo), ciò potrebbe accadere quando hai un carico di lavoro molto intenso in cui il traffico aumenta molto durante alcuni giorni (o ore), ma in generale il traffico è costantemente basso. In questi scenari potrebbe essere utile utilizzare la scalabilità automatica pianificata.
