3- Limiti dell'account superati - Amazon DynamoDB
Il limite dell'account ha superato le misure di mitigazioneDiagnosi e monitoraggio comuniProcedure di risoluzione

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- Limiti dell'account superati

Le tabelle on demand non dispongono di livelli di capacità predefiniti da gestire, ma DynamoDB impone limiti di throughput a livello di account per prevenire l'esecuzione incontrollata e garantire un uso equo delle risorse da parte di tutti i clienti. Questi limiti di account per tabella fungono da salvaguardia regolabili, impostati per ogni combinazione di account e regione. Quando il tasso di consumo in lettura o scrittura supera questi limiti, DynamoDB restituisce AccountLimitExceeded un tipo di motivo di limitazione 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 velocità effettiva massima per un controllo più preciso dei costi e la prevedibilità, oppure richiedere aumenti delle quote tramite la Quote in Amazon DynamoDB console se i requisiti dell'applicazione superano i limiti predefiniti.

Il limite dell'account ha superato le misure di mitigazione

Questa sezione fornisce linee guida per la risoluzione degli scenari di limitazione dei limiti di account. Prima di utilizzare questa guida, assicurati di aver identificato i motivi specifici della limitazione nella gestione delle eccezioni dell'applicazione e di aver determinato l'Amazon Resource Name (ARN) della risorsa interessata. Per informazioni su come recuperare i motivi di limitazione e identificare le risorse limitate, consulta. Framework di diagnosi della limitazione di DynamoDB

Prima di approfondire specifici scenari di limitazione, stabilite innanzitutto se è effettivamente necessaria un'azione:

  • Valuta l'impatto sulle prestazioni: verifica se l'applicazione soddisfa ancora i requisiti prestazionali nonostante la limitazione. Molte applicazioni funzionano correttamente con o in prossimità dei limiti degli account, in particolare durante le operazioni di massa o le migrazioni dei dati.

  • Esamina i modelli di limitazione: se la limitazione è intermittente e l'applicazione gestisce i nuovi tentativi in modo efficace, i limiti attuali potrebbero essere sufficienti per il carico di lavoro.

Se la tua applicazione funziona in modo accettabile anche quando occasionalmente raggiunge i limiti dell'account, potresti scegliere di monitorare semplicemente la situazione piuttosto che implementare modifiche immediate.

Se ritieni che la limitazione stia causando problemi di prestazioni o affidabilità inaccettabili, seleziona uno dei motivi di limitazione specifici qui sotto per trovare le opzioni di mitigazione consigliate:

TableReadAccountLimitExceeded

Quando ciò accade

Il consumo di lettura della tabella ha superato la quota di velocità effettiva di lettura per tabella a livello di account per la tua regione. Puoi monitorare le CloudWatch metriche per analizzare il tuo evento di limitazione. Diagnosi e monitoraggio comuni

Approccio alla risoluzione

Utilizza i seguenti passaggi per risolvere questa limitazione:

TableWriteAccountLimitExceeded

Quando ciò accade

Il consumo di scrittura della tabella ha superato la quota di velocità effettiva di scrittura per tabella a livello di account per la tua regione. Puoi monitorare le CloudWatch metriche per analizzare il tuo evento di throttling. Diagnosi e monitoraggio comuni

Approccio alla risoluzione

Utilizza i seguenti passaggi per risolvere questa limitazione:

  • Richiedi aumenti della quota: richiedi un aumento del limite di velocità di scrittura per tabella (codice quota L-). AB614373 Per i passaggi dettagliati su come inviare la richiesta, vedi Richiesta di aumenti delle quote per tabella.

IndexReadAccountLimitExceeded

Quando ciò accade

Le operazioni di lettura dirette a un indice secondario globale (GSI) consumano una velocità effettiva superiore a quella consentita dalla quota di lettura per tabella dell'account nella regione corrente. AWS La quota di velocità effettiva di lettura per tabella a livello di account si applica collettivamente a una tabella e a tutte le relative combinazioni. GSIs Puoi monitorare le CloudWatch metriche per analizzare il tuo evento di limitazione. Diagnosi e monitoraggio comuni

Approccio alla risoluzione

Scegli la risoluzione appropriata in base alla distribuzione della capacità del tuo account:

IndexWriteAccountLimitExceeded

Quando ciò accade

Le operazioni di scrittura nella tabella di base generano gli aggiornamenti corrispondenti a un GSI che complessivamente superano la quota di velocità effettiva di scrittura per tabella a livello di account per regione. AWS Ogni scrittura su un elemento della tabella 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 velocità effettiva di scrittura per tabella. È possibile monitorare le CloudWatch metriche Diagnosi e monitoraggio comuni per analizzare i modelli e la tempistica di questi eventi di limitazione e identificare quali operazioni stanno causando l'eccessiva attività di scrittura del GSI.

Approccio alla risoluzione

Scegli la risoluzione appropriata in base alla distribuzione della capacità del tuo account:

Diagnosi e monitoraggio comuni

Per la risoluzione dei problemi relativi al superamento degli eventi di limitazione del limite di account, diverse CloudWatch metriche possono aiutare a capire se si stanno raggiungendo i limiti per tabella o per intero account e a comprendere i modelli di distribuzione della capacità.

Metriche essenziali CloudWatch

Monitora queste metriche chiave per diagnosticare la limitazione dei limiti degli account:

Procedure di risoluzione

Richiesta di aumenti delle quote per tabella

Se le applicazioni devono funzionare oltre gli attuali limiti di throughput per tabella, è necessario inviare una richiesta di aumento delle quote utilizzando la procedura riportata di seguito. Ogni tabella DynamoDB del AWS tuo account (insieme a tutte le tabelle GSIs associate) è 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 la relativa tabella GSIs possono consumare collettivamente e si applicano indipendentemente a ciascuna tabella anziché come aggregato su tutte le tabelle dell'account.

Facoltativamente, puoi anche impostare limiti inferiori per tabella o per GSI configurando le relative impostazioni di throughput massime su richiesta.

  1. Identifica la quota specifica che deve essere aumentata:

    • Limite di velocità di lettura per tabella (codice quota L-CF0CBE56): impostazione predefinita: 40.000 per tabella RCUs

    • Limite di velocità di scrittura per tabella (codice quota L-): impostazione predefinita: 40.000 per tabella AB614373 WCUs

  2. Usa la console AWS Service Quotas per richiedere un aumento:

    • Accedere al servizio DynamoDB in Service Quotas

    • Trova la quota appropriata utilizzando il codice di quota

    • Richiedi un aumento in base al picco di utilizzo previsto

  3. 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 tue richieste di conseguenza e prendi in considerazione strategie di mitigazione temporanee in attesa dell'approvazione.

Ottimizzazione delle proiezioni e della progettazione GSI

Ottimizzate le proiezioni e la progettazione del Global Secondary Index (GSI) per ridurre il consumo 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, vedere Proiezioni per indici secondari globali.

  1. Analizza i modelli di interrogazione: esamina i modelli di interrogazione dell'applicazione per identificare a quali attributi si accede effettivamente tramite il GSI.

  2. Utilizza proiezioni selettive: solo gli attributi del progetto che sono effettivamente necessari nelle query per ridurre il volume di scrittura.

  3. ConsideraKEYS_ONLY: se le tue query richiedono solo gli attributi chiave, usa la KEYS_ONLY proiezione per ridurre al minimo il volume di scrittura.

  4. Equilibrio tra lettura e scrittura: la proiezione di un minor numero di attributi riduce il consumo di capacità di scrittura, ma può richiedere letture aggiuntive della tabella di base.

Implementazione Sparse GSI

Sparse GSIs contiene 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 eseguono frequentemente query su sottoinsiemi di dati specifici.

  1. Design GSIs che include solo elementi con valori di attributo specifici.

  2. Implementa l'indicizzazione condizionale impostando l'attributo della chiave di partizione GSI solo sugli elementi che devono essere indicizzati.

  3. Usa le chiavi composite in formato sparso GSIs (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 Practices for Using Secondary Indexes in DynamoDB.