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à.
3. Superamento dei limiti dell’account
On-demand le tabelle non prevedono livelli di capacità prestabiliti da gestire, ma DynamoDB impone limiti di throughput a livello di account per prevenire un'esecuzione incontrollata e garantire un uso equo delle risorse tra tutti i clienti. Questi limiti di account per tabella fungono da protezioni regolabili, impostati per ogni combinazione di account e Regione. Quando il tasso di consumo in lettura o scrittura supera questi limiti, DynamoDB restituisce un tipo di motivo di limitazione (della larghezza di banda della rete) AccountLimitExceeded nell’eccezione di limitazione. I limiti di account predefiniti per tabella si applicano automaticamente quando le tabelle non hanno impostazioni di throughput massimo personalizzate configurate. Facoltativamente, è possibile configurare le impostazioni di throughput massimo per un controllo più preciso dei costi e la prevedibilità, oppure richiedere aumenti delle quote tramite la console Quote in Amazon DynamoDB se i requisiti dell’applicazione superano i limiti predefiniti.
Misure di mitigazione per il superamento dei limiti dell’account
Questa sezione fornisce linee guida per la risoluzione degli scenari di limitazione (della larghezza di banda della rete) dei limiti dell’account. Prima di utilizzare questa guida è necessario assicurarsi di aver identificato i motivi specifici della limitazione (della larghezza di banda della rete) nella gestione delle eccezioni dell’applicazione e di aver determinato il nome della risorsa Amazon (ARN) della risorsa interessata. Per informazioni su come recuperare i motivi della limitazione (della larghezza di banda della rete) e identificare le risorse limitate, consulta Framework di diagnosi della limitazione (della larghezza di banda della rete) di DynamoDB.
Prima di approfondire specifici scenari di limitazione (della larghezza di banda della rete), stabilisci innanzitutto se è effettivamente necessaria un’azione:
-
Valuta l’impatto sulle prestazioni: verifica se l’applicazione soddisfa ancora i requisiti prestazionali nonostante la limitazione (della larghezza di banda della rete). Molte applicazioni funzionano correttamente con o in prossimità dei limiti degli account, in particolare durante operazioni in blocco o migrazioni di dati.
-
Esamina i modelli di limitazione (della larghezza di banda della rete): se la limitazione è intermittente e l’applicazione gestisce le ripetizioni di tentativi in modo efficace, i limiti attuali potrebbero essere sufficienti per il carico di lavoro.
Se l’applicazione funziona in modo accettabile anche quando occasionalmente raggiunge i limiti dell’account, si potrebbe scegliere di monitorare semplicemente la situazione piuttosto che implementare modifiche immediate.
Se ritieni che la limitazione (della larghezza di banda della rete) stia causando problemi di prestazioni o affidabilità inaccettabili, seleziona uno specifico motivo della limitazione di seguito per trovare le opzioni di mitigazione consigliate:
TableReadAccountLimitExceeded
Quando avviene
Quando l’utilizzo di lettura della tabella ha superato la quota di throughput di lettura per tabella a livello di account per la Regione. Puoi monitorare le metriche per analizzare il CloudWatch tuo evento di limitazione. Diagnosi e monitoraggio comuni
Approccio di risoluzione
Segui la procedura riportata di seguito per questa limitazione (della larghezza di banda della rete).
-
Richiedi aumenti della quota:
Richiedi un aumento del limite di velocità di lettura per tabella (codice quota). L-CF0CBE56 Per la procedura dettagliata di invio della richiesta, consulta Richiesta di aumenti della quota per tabella.
TableWriteAccountLimitExceeded
Quando avviene
Quando l’utilizzo di scrittura della tabella ha superato la quota di throughput di scrittura per tabella a livello di account per la Regione. Puoi monitorare le CloudWatch metriche Diagnosi e monitoraggio comuni per analizzare l'evento di limitazione.
Approccio di risoluzione
Segui la procedura riportata di seguito per questa limitazione (della larghezza di banda della rete).
-
Richiedi aumenti della quota: richiedi un aumento del limite di velocità di scrittura per tabella (codice di quota). L-AB614373 Per la procedura dettagliata di invio della richiesta, consulta Richiesta di aumenti della quota per tabella.
IndexReadAccountLimitExceeded
Quando avviene
Quando le operazioni di lettura dirette a un indice secondario globale (GSI) consumano un throughput superiore a quello consentito dalla quota di lettura per tabella dell’account nella Regione AWS corrente. La quota di throughput di lettura per tabella a livello di account si applica collettivamente a una tabella e a tutti i relativi GSI combinati. Puoi monitorare le CloudWatch metriche Diagnosi e monitoraggio comuni per analizzare l'evento di limitazione.
Approccio di risoluzione
Scegli l’opzione di risoluzione appropriata in base alla distribuzione della capacità dell’account:
-
Richiedi aumenti della quota: richiedi un aumento del limite di velocità di lettura per tabella (codice di quota). L-CF0CBE56 Per la procedura dettagliata di invio della richiesta, consulta Richiesta di aumenti della quota per tabella.
-
Ottimizza l’utilizzo del GSI: controlla i modelli di progettazione del GSI e di esecuzione di query per ridurre l’utilizzo non necessario di capacità di lettura.
IndexWriteAccountLimitExceeded
Quando avviene
Le operazioni di scrittura sulla tabella di base generano gli aggiornamenti corrispondenti a un GSI che complessivamente superano la quota di velocità di scrittura per tabella a livello di account per la regione. AWS Ogni scrittura su un elemento della tabella di base che contiene attributi indicizzati da un GSI attiva un’operazione di scrittura corrispondente a quel GSI. Queste operazioni di scrittura combinate vengono conteggiate ai fini della quota di throughput di scrittura per tabella. Puoi monitorare le CloudWatch metriche Diagnosi e monitoraggio comuni per analizzare i modelli e i tempi di questi eventi di limitazione e identificare quali operazioni stanno causando l'eccessiva attività di scrittura GSI.
Approccio di risoluzione
Scegli l’opzione di risoluzione appropriata in base alla distribuzione della capacità dell’account:
-
Richiedi aumenti delle quote: richiedi un aumento del limite di velocità di scrittura per tabella (codice di quota L-AB614373) per far fronte a un traffico di scrittura GSI più elevato derivante dalle operazioni della tabella di base. La quota di throughput di scrittura per tabella si applica all’intera tabella, inclusi tutti i relativi GSI. Per la procedura dettagliata di invio della richiesta, consulta Richiesta di aumenti della quota per tabella.
-
Ottimizza le proiezioni dei GSI: controlla le proiezioni e la progettazione dei GSI per ridurre il volume di scrittura sui GSI.
Diagnosi e monitoraggio comuni
Quando si risolvono i problemi relativi agli eventi di limitazione del limite dell'account, diverse CloudWatch metriche possono aiutare a identificare se si stanno raggiungendo i limiti per tabella o a livello di account e a comprendere i modelli di distribuzione della capacità.
Metriche essenziali CloudWatch
Monitora queste metriche chiave per diagnosticare la limitazione (della larghezza di banda della rete) dei limiti degli account:
-
Eventi di limitazione (della larghezza di banda della rete) dovuti a limiti dell’account:
ReadAccountLimitThrottleEventseWriteAccountLimitThrottleEventsmonitorano quando le richieste vengono sottoposte a limitazione (della larghezza di banda della rete) a causa dei limiti a livello di account.ReadThrottleEventseWriteThrottleEventsmonitorano quando le richieste di lettura o scrittura superano la capacità allocata. -
Utilizzo di capacità per risorsa:
ConsumedReadCapacityUnitseConsumedWriteCapacityUnitsper ogni tabella e GSI mostrano l’utilizzo delle singole risorse. -
Account-wide consumo: utilizza espressioni CloudWatch matematiche metriche per sommare la capacità consumata in tutte le tabelle e i GSI per monitorare l'utilizzo totale dell'account.
Procedure di risoluzione
Richiesta di aumenti di quota per tabella
Se le applicazioni devono funzionare oltre gli attuali limiti di throughput per tabella, è necessario inviare una richiesta di aumento della quota utilizzando la procedura seguente. Ogni tabella DynamoDB del tuo AWS account (insieme a tutti i GSI associati) è soggetta a queste quote di throughput all'interno di una regione specifica. Queste quote rappresentano la capacità massima di lettura o scrittura che ogni singola tabella e i relativi GSI possono utilizzare collettivamente e si applicano indipendentemente a ciascuna tabella anziché come aggregato tra tutte le tabelle dell’account.
Facoltativamente, è possibile anche impostare limiti inferiori per tabella o per GSI configurando le relative impostazioni di throughput massimo on demand.
-
Identifica la quota specifica che deve essere aumentata:
-
Per-table limite di velocità di lettura (codice di quota L-CF0CBE56): 40.000 RCU predefiniti per tabella
-
Per-table limite di velocità di scrittura (codice quota L-AB614373): 40.000 WCU predefiniti per tabella
-
-
Utilizza la console AWS Service Quotas per richiedere un aumento:
-
Accedi al servizio DynamoDB in Service Quotas
-
Trova la quota appropriata utilizzando il codice quota
-
Richiedi un aumento in base al picco di utilizzo previsto
-
-
Fornisci una giustificazione per l’aumento, tra cui:
-
Modelli di utilizzo attuali e requisiti di traffico di picco
-
Giustificazione aziendale dell’aumento della capacità
-
Cronologia dei casi in cui è necessaria una maggiore capacità
-
Nota
L’elaborazione degli aumenti delle quote richiede in genere 24 – 48 ore. Pianifica le richieste di conseguenza e prendi in considerazione strategie di mitigazione temporanee in attesa dell’approvazione.
Ottimizzazione delle proiezioni e della progettazione dei GSI
Ottimizzazione delle proiezioni e della progettazione degli indici secondari globali (GSI) per ridurre l’utilizzo di capacità e migliorare le prestazioni.
Strategie di proiezione selettive
Se le query devono accedere solo a pochi attributi, la proiezione solo di tali attributi riduce la quantità di dati scritti nel GSI quando gli elementi della tabella di base cambiano. Per i dettagli sui tipi di proiezione, consulta Projections for Global Secondary Indexes.
-
Analizza i modelli di query: esamina i modelli di query dell’applicazione per identificare a quali attributi si accede effettivamente tramite il GSI.
-
Utilizza proiezioni selettive: effettua la proiezione solo degli attributi che sono effettivamente necessari nelle query per ridurre il volume di scrittura.
-
Prendi in considerazione
KEYS_ONLY: se le query richiedono solo gli attributi chiave, usa la proiezioneKEYS_ONLYper ridurre al minimo il volume di scrittura. -
Bilancia i compromessi tra lettura e scrittura: la proiezione di un minor numero di attributi riduce l’utilizzo di capacità di scrittura, ma può richiedere letture aggiuntive della tabella di base.
Implementazione di GSI di tipo sparse
I GSI di tipo sparse contengono solo gli elementi che hanno l’attributo indicizzato, anziché tutti gli elementi della tabella di base. Ciò riduce la densità delle partizioni e migliora le prestazioni quando si interrogano frequentemente sottoinsiemi di dati specifici.
-
Progetta GSI che includano solo elementi con valori di attributi specifici.
-
Implementa l’indicizzazione condizionale impostando l’attributo della chiave di partizione del GSI solo sugli elementi che devono essere indicizzati.
-
Usa le chiavi composite nei GSI di tipo sparse (ad esempio, status#timestamp) per distribuire ulteriormente il traffico all’interno del sottoinsieme di elementi indicizzati.
Per ulteriori informazioni sull’implementazione di queste strategie, consulta Best practice per l’utilizzo degli indici secondari in DynamoDB.