1- Superamento della velocità effettiva dell'intervallo di chiavi (partizioni calde) - Amazon DynamoDB
Il throughput dell'intervallo chiave ha superato le misure di mitigazioneDiagnosi e monitoraggio comuniProcedure di risoluzioneRisorse aggiuntive

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à.

1- Superamento della velocità effettiva dell'intervallo di chiavi (partizioni calde)

Amazon DynamoDB impone limiti di throughput specifici a livello di partizione sia per la tabella che per l'indice secondario globale (GSI). Ogni partizione ha un numero massimo di unità di capacità di lettura (RCUs) e unità di capacità di scrittura () al secondo. WCUs Quando le partizioni ricevono un traffico concentrato che supera questi limiti, subiscono una limitazione, mentre altre operazioni possono rimanere sottoutilizzate, creando «partizioni calde». La limitazione a livello di partizione di DynamoDB opera in modo indipendente per le letture e le scritture: una partizione può limitare le letture mentre le scritture continuano normalmente o viceversa. Questa limitazione può verificarsi anche quando la tabella o il GSI hanno una capacità complessiva sufficiente. Per saperne di più su:

  • Limiti delle partizioni di DynamoDB e progettazione efficace delle chiavi di partizione per la prevenzione delle partizioni a caldo, vedi Best practice per progettare e utilizzare efficacemente le chiavi di partizione in DynamoDB.

  • Concetti generali sulle partizioni e sulla distribuzione dei dati, vedere Partizioni in DynamoDB.

  • Ulteriori indicazioni e scenari reali per la gestione delle chiavi di partizione e della velocità effettiva, vedi. Risorse aggiuntive

Quando le singole partizioni superano i limiti di throughput, DynamoDB restituisce un tipo di motivo di limitazione nell'eccezione di KeyRangeThroughputExceeded limitazione. Le informazioni identificano che una partizione sta registrando un traffico elevato e il tipo di operazione (lettura o scrittura) causa il problema.

Il throughput dell'intervallo chiave ha superato le misure di mitigazione

Questa sezione fornisce indicazioni sulla risoluzione degli scenari di limitazione a livello di partizione. 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, verifica innanzitutto se il problema si risolve automaticamente:

  • DynamoDB si adatta spesso alle partizioni calde tramite il suo meccanismo automatico. split-for-heat Se notate eventi di throttling che si interrompono dopo un breve periodo, è possibile che la tabella si sia già adattata suddividendo la partizione calda. Quando le partizioni si dividono, ogni nuova partizione gestisce una sezione più piccola dello spazio delle chiavi, il che può aiutare a distribuire il carico in modo più uniforme. In molti casi, non sono necessarie ulteriori azioni poiché DynamoDB ha risolto automaticamente il problema.

    Per ulteriori informazioni sul split-for-heatmeccanismo, vedere. Risorse aggiuntive

Se la limitazione persiste, fai riferimento agli scenari di limitazione specifici riportati di seguito per opzioni di correzione mirate:

TableReadKeyRangeThroughputExceeded

Quando ciò accade

Il tasso di consumo di una o più partizioni nella tabella DynamoDB supera il limite di velocità effettiva di lettura della partizione. Questa limitazione si verifica indipendentemente dalla capacità totale assegnata alla tabella e influisce sia sulle tabelle predisposte che su richiesta. Puoi monitorare le CloudWatch metriche per analizzare il tuo evento di throttlingDiagnosi e monitoraggio comuni.

Opzioni di riparazione

Prendi in considerazione questi passaggi per risolvere i tuoi problemi di limitazione:

Sia per le modalità predisposte che per quelle su richiesta:

  • Capacità di preriscaldamento: se la limitazione persiste, controlla se la capacità del tavolo è limitata dalla sua capacità. Comprendere il throughput a caldo di DynamoDB Utilizza la velocità effettiva massima o aumenta in anticipo la capacità di lettura assegnata per far fronte agli aumenti di traffico previsti. L'aumento della velocità di trasmissione a caldo migliora la capacità del tavolo di gestire picchi di traffico improvvisi prima che si verifichino i throttling. Nel tempo, se il throughput effettivo si avvicina costantemente ai livelli di throughput caldi, DynamoDB può suddividere le partizioni occupate in base ai modelli di utilizzo osservati.

  • Identifica i tasti di scelta rapida: se la tabella non ha risolto il problema automaticamente e la velocità effettiva a caldo è elevata o un aumento non è stato utile, dovrai identificare tasti di scelta rapida specifici. Identificazione dei tasti di scelta rapida utilizzando CloudWatch Contributor InsightsUtilizzatelo per determinare se alcuni valori di una particolare chiave di partizione non sono validi. Questo è il primo passo per indirizzare efficacemente gli sforzi di mitigazione. Tieni presente che l'identificazione potrebbe non essere sempre semplice, in particolare nel caso di partizioni a caldo continuo (in cui partizioni diverse si surriscaldano nel tempo) o quando la limitazione è innescata da operazioni come le scansioni. Per questi scenari complessi, potrebbe essere necessario analizzare i modelli di accesso dell'applicazione e correlarli con la tempistica degli eventi di limitazione.

  • A seconda del caso d'uso, prendete in considerazione l'utilizzo di letture a lungo termine coerenti: passate da letture fortemente coerenti a letture sostanzialmente coerenti, che consumano la metà RCUs e possono immediatamente raddoppiare la capacità di lettura effettiva. Per le migliori pratiche sull'implementazione di letture alla fine coerenti per ridurre il consumo di capacità di lettura, consulta. Coerenza di lettura di DynamoDB

  • Migliora la progettazione delle chiavi di partizione: come soluzione a lungo termine, prendi in considerazione Miglioramento della progettazione delle chiavi di partizione la possibilità di distribuire l'accesso in modo più uniforme tra le partizioni. Questo approccio spesso fornisce la soluzione più completa ai problemi relativi alle partizioni a caldo risolvendo la causa principale. Tuttavia, richiede un'attenta pianificazione in quanto comporta sfide di migrazione significative.

TableWriteKeyRangeThroughputExceeded

Quando ciò accade

Il tasso di consumo di una o più partizioni nella tabella DynamoDB supera il limite di velocità effettiva di scrittura della partizione. Questa limitazione si verifica indipendentemente dalla capacità totale assegnata alla tabella e influisce sia sulle tabelle predisposte che su richiesta. Puoi monitorare le CloudWatch metriche per analizzare il tuo evento di throttlingDiagnosi e monitoraggio comuni.

Opzioni di riparazione

Prendi in considerazione questi passaggi per risolvere i tuoi problemi di limitazione:

Sia per le modalità predisposte che per quelle su richiesta:

  • Capacità di preriscaldamento: se la limitazione persiste, controlla se la capacità del tavolo è limitata dalla sua capacità. Comprendere il throughput a caldo di DynamoDB Utilizza una velocità effettiva elevata o aumenta in anticipo la capacità di scrittura assegnata per far fronte agli aumenti di traffico previsti. L'aumento della velocità di trasmissione a caldo migliora la capacità del tavolo di gestire picchi di traffico improvvisi prima che si verifichino i throttling. Nel tempo, se il throughput effettivo si avvicina costantemente ai livelli di throughput caldi, DynamoDB può suddividere le partizioni occupate in base ai modelli di utilizzo osservati.

  • Identifica i tasti di scelta rapida: se la tabella non ha risolto il problema automaticamente e la velocità effettiva a caldo è elevata o un aumento non è stato utile, dovrai identificare tasti di scelta rapida specifici. Identificazione dei tasti di scelta rapida utilizzando CloudWatch Contributor InsightsUtilizzatelo per determinare se alcuni valori di una particolare chiave di partizione non sono validi. Questo è il primo passo per indirizzare efficacemente gli sforzi di mitigazione. Considerate questi modelli comuni:

    • Se vedi che la stessa chiave di partizione appare spesso nei dati di limitazione, significa che si tratta di un tasto di scelta rapida concentrato.

    • Se non vedi tasti ripetuti ma stai scrivendo i dati in modo ordinato (ad esempio timestamp sequenziali o operazioni basate sulla scansione che seguono l'ordine dello spazio chiave), probabilmente hai partizioni a caldo in cui chiavi diverse diventano calde nel tempo man mano che le operazioni di scrittura si spostano nello spazio chiave.

    Tieni presente che la limitazione della scrittura può verificarsi anche con operazioni come o transazioni che riguardano più elementi contemporaneamente. BatchWriteItem Quando i singoli elementi di una BatchWriteItem richiesta vengono limitati, DynamoDB non propaga questi errori di limitazione al codice dell'applicazione. Invece, DynamoDB restituisce informazioni sugli elementi non elaborati nella risposta, che l'applicazione deve gestire riprovando quegli elementi specifici. Per le transazioni, l'intera operazione ha esito negativo e viene segnalato un TransactionCanceledException eventuale rallentamento di un elemento. Per questi scenari complessi, potrebbe essere necessario analizzare gli schemi di scrittura e i flussi di lavoro di inserimento dei dati dell'applicazione, correlarli alla tempistica degli eventi di limitazione e implementare strategie appropriate di gestione dei tentativi.

  • Migliora la progettazione delle chiavi di partizione: come soluzione a lungo termine, prendi in considerazione Miglioramento della progettazione delle chiavi di partizione la possibilità di distribuire l'accesso in modo più uniforme tra le partizioni. Questo approccio spesso fornisce la soluzione più completa ai problemi relativi alle partizioni a caldo risolvendo la causa principale. Tuttavia, richiede un'attenta pianificazione in quanto comporta sfide di migrazione significative.

IndexReadKeyRangeThroughputExceeded

Quando ciò accade

Il tasso di consumo di una o più partizioni nel GSI di DynamoDB supera il limite di velocità effettiva di lettura della partizione. Questa limitazione si verifica indipendentemente dalla capacità totale fornita dal GSI e influisce sia sulle tabelle fornite che su richiesta. È possibile monitorare le CloudWatch metriche per analizzare l'evento di throttling. Diagnosi e monitoraggio comuni

Opzioni di riparazione

Prendi in considerazione questi passaggi per risolvere i tuoi problemi di limitazione:

  • Capacità di preriscaldamento: se la limitazione persiste, controlla se il GSI è limitato dalla sua capacità. Comprendere il throughput a caldo di DynamoDB Usa una velocità effettiva elevata o aumenta in anticipo la capacità di lettura assegnata per far fronte agli aumenti di traffico previsti. L'aumento della velocità effettiva a caldo migliora la capacità del GSI di gestire picchi di traffico improvvisi prima che si verifichino i throttling. Nel tempo, se il throughput effettivo si avvicina costantemente ai livelli di throughput caldi, DynamoDB può suddividere le partizioni occupate in base ai modelli di utilizzo osservati.

  • Identifica i tasti di scelta rapida: se il GSI non ha risolto il problema automaticamente e la velocità effettiva a caldo è elevata o un aumento non è stato di aiuto, dovrai identificare tasti di scelta rapida specifici. Identificazione dei tasti di scelta rapida utilizzando CloudWatch Contributor InsightsUtilizzatelo per determinare se alcuni valori delle chiavi di partizione particolari sono caldi. Questo è il primo passo per indirizzare efficacemente gli sforzi di mitigazione. Nota che GSIs, per, la distribuzione delle chiavi di partizione può differire in modo significativo dalla tabella di base, creando diversi modelli di tasti di scelta rapida.

  • Riprogettazione delle chiavi di partizione GSI: valuta se il progetto della chiave GSI potrebbe creare hot spot artificiali (come indicatori di stato, chiavi con sola data o attributi booleani) che concentrano le letture su un numero limitato di partizioni. Prendi in considerazione l'utilizzo di chiavi composite che combinano l'attributo a bassa cardinalità con un attributo ad alta cardinalità (ad esempio, «ACTIVE #customer123" anziché solo «ACTIVE») o applicano Utilizzo dello sharding di scrittura per distribuire i carichi di lavoro in modo uniforme nella tabella DynamoDB tecniche agli elementi della tabella di base che influiscono sulla distribuzione GSI per distribuire le scritture su più partizioni. Sebbene l'interrogazione di dati frammentati richieda una logica applicativa aggiuntiva per aggregare i risultati, questo approccio impedisce la limitazione distribuendo i modelli di accesso in modo più uniforme.

IndexWriteKeyRangeThroughputExceeded

Quando ciò accade

Il tasso di consumo di una o più partizioni nel GSI di DynamoDB supera il limite di throughput di scrittura della partizione. Questa limitazione si verifica indipendentemente dalla capacità totale fornita dal GSI e influisce sia sulle tabelle predisposte che su richiesta. È possibile monitorare le CloudWatch metriche per analizzare l'evento di throttling. Diagnosi e monitoraggio comuni

Opzioni di riparazione

Prendi in considerazione questi passaggi per risolvere i tuoi problemi di limitazione:

  • Riprogettazione della chiave di partizione GSI: rivedi il design della chiave di partizione GSI per verificare che abbia una cardinalità (unicità) sufficiente per distribuire le scritture in modo uniforme. Una causa comune della limitazione della scrittura in GSI è l'uso di attributi a bassa cardinalità come chiavi di partizione GSI (come i flag di stato con solo pochi valori possibili). Anche quando la tabella di base ha chiavi di partizione ben distribuite, nel GSI possono comunque riscontrare partizioni calde se la chiave di partizione concentra le scritture su un numero limitato di valori. Ad esempio, se l'80% degli elementi presenta Status="ACTIVE», ciò crea una partizione estremamente calda in un GSI basato sullo stato. Prendi in considerazione l'utilizzo di chiavi composite che combinano l'attributo a bassa cardinalità con un attributo ad alta cardinalità (ad esempio, «ACTIVE #customer123" anziché solo «ACTIVE») o applica Utilizzo dello sharding di scrittura per distribuire i carichi di lavoro in modo uniforme nella tabella DynamoDB tecniche agli elementi della tabella di base che influiscono sulla distribuzione GSI per distribuire le scritture su più partizioni. Sebbene l'interrogazione di dati frammentati richieda una logica applicativa aggiuntiva per aggregare i risultati, questo approccio impedisce la limitazione distribuendo i modelli di accesso in modo più uniforme.

  • Capacità di preriscaldamento: verifica se la capacità del tuo GSI è limitata. Comprendere il throughput a caldo di DynamoDB Usa una velocità effettiva elevata o aumenta in anticipo la capacità di lettura assegnata per far fronte agli aumenti di traffico previsti. L'aumento della velocità effettiva a caldo migliora la capacità del GSI di gestire picchi di traffico improvvisi prima che si verifichino i throttling. Nel tempo, se il throughput effettivo si avvicina costantemente ai livelli di throughput caldi, DynamoDB può suddividere le partizioni occupate in base ai modelli di utilizzo osservati.

  • Ottimizza le proiezioni GSI: applica Ottimizzazione delle proiezioni GSI tecniche per ridurre il volume di scrittura a. GSIs La proiezione di un numero inferiore di attributi può ridurre significativamente la capacità di scrittura consumata da ogni aggiornamento GSI.

Diagnosi e monitoraggio comuni

Durante la risoluzione dei problemi di limitazione a livello di partizione, diverse CloudWatch metriche possono aiutare a identificare le partizioni calde e a confermare la causa principale.

Metriche essenziali CloudWatch

Monitora queste metriche chiave per diagnosticare la limitazione a livello di partizione:

Procedure di risoluzione

Identificazione dei tasti di scelta rapida utilizzando CloudWatch Contributor Insights

Utilizzate questa procedura per identificare quali chiavi di partizione causano il throttling.

  1. Abilita CloudWatch Contributor Insights sulla tabella o sul GSI per tenere traccia delle chiavi con più limitazioni. Prendi in considerazione la possibilità di mantenere costantemente attivo CloudWatch Contributor Insights per ricevere avvisi di limitazione in tempo reale utilizzando la modalità Throttled keys. Questa modalità si concentra esclusivamente sulle richieste limitate ed elabora gli eventi solo quando si verifica la limitazione. Questo monitoraggio mirato è un modo conveniente per mantenere una visibilità continua sui problemi di limitazione.

  2. Identifica le chiavi che causano i problemi di partizione calda.

  3. (Se è abilitata la modalità completa con accesso limitato e tasti limitati) Analizza i modelli di accesso nel tempo per determinare se i tasti di scelta rapida sono coerenti o se vengono utilizzati in periodi specifici.

Miglioramento della progettazione delle chiavi di partizione

Utilizza questo approccio quando puoi modificare lo schema della tabella per distribuire meglio il traffico tra le partizioni. Quando possibile, questa è la soluzione a lungo termine più efficace per i problemi relativi alle partizioni a caldo. Idealmente, la progettazione delle chiavi di partizione dovrebbe essere attentamente considerata durante la fase iniziale di progettazione della tabella.

La riprogettazione della chiave di partizione rappresenta una modifica fondamentale del modello di dati che influisce sull'intero ecosistema applicativo. Prima di procedere con questo approccio, considera attentamente queste limitazioni significative:

  • Complessità della migrazione dei dati: la riprogettazione delle chiavi di partizione richiede la migrazione di tutti i dati esistenti, operazione che può richiedere molte risorse e tempo per tabelle di grandi dimensioni.

  • Modifiche al codice dell'applicazione: tutto il codice dell'applicazione che legge o scrive nella tabella deve essere aggiornato per utilizzare la nuova struttura di chiavi.

  • Impatto sulla produzione: la migrazione a un nuovo design chiave spesso richiede tempi di inattività o complesse strategie di doppia scrittura durante la transizione.

Per linee guida e principi completi sulla progettazione delle chiavi di partizione, consulta e. Le migliori pratiche per progettare e utilizzare le chiavi di partizione in modo efficace in DynamoDB Progettazione di chiavi di partizione per distribuire il carico di lavoro in DynamoDB

Ottimizzazione delle proiezioni GSI

Esamina gli schemi di interrogazione dell'applicazione per determinare esattamente quali attributi devono essere disponibili quando si esegue una query sul GSI e limita le proiezioni solo a tali attributi. Quando si aggiornano attributi che non sono proiettati in un GSI, non viene eseguita alcuna operazione di scrittura su tale GSI, riducendo il consumo di velocità di scrittura durante gli aggiornamenti. Questa strategia di proiezione mirata ottimizza sia le prestazioni che i costi, pur continuando a supportare i requisiti di query dell'applicazione. Si noti che la proiezione di un numero inferiore di attributi riduce il consumo di capacità di scrittura, ma potrebbe richiedere letture aggiuntive della tabella di base.

Per ulteriori informazioni sulle strategie di proiezione efficienti, consulta Best Practices for Using Secondary Indexes in DynamoDB.

Risorse aggiuntive

I seguenti post del blog forniscono esempi pratici e dettagli pratici sui concetti trattati in questa guida: