1. Superamento del throughput dell’intervallo di chiavi (partizioni calde)

Limiti delle partizioni di DynamoDB e progettazione efficace delle chiavi di partizione per la prevenzione delle partizioni calde, consulta Best practice per la progettazione delle chiavi di partizione e relativo uso in DynamoDB.

Concetti generali sulle partizioni e la distribuzione dei dati, consulta Partizioni in DynamoDB.

Ulteriori indicazioni e scenari reali per la gestione delle chiavi di partizione e del throughput, consulta Risorse aggiuntive.

DynamoDB si adatta spesso alle partizioni calde tramite il suo meccanismo automatico. split-for-heat In caso di eventi di limitazione (della larghezza di banda della rete) 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 del keyspace, il che può aiutare a distribuire il carico in modo più uniforme. In molti casi, non sono richieste altre operazioni in quanto DynamoDB ha risolto automaticamente il problema.

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

TableReadKeyRangeThroughputExceeded

TableWriteKeyRangeThroughputExceeded

IndexReadKeyRangeThroughputExceeded

IndexWriteKeyRangeThroughputExceeded

Pre-riscalda la capacità: se la limitazione (della larghezza di banda della rete) persiste, controlla se la capacità della tabella è limitata dalla sua capacità Funzionamento del throughput di DynamoDB. Utilizza il throughput a caldo o aumenta in anticipo la capacità di lettura allocata per far fronte agli aumenti di traffico previsti. L’aumento del throughput a caldo migliora la capacità della tabella di gestire picchi di traffico improvvisi prima che si verifichi la limitazione (della larghezza di banda della rete). Nel tempo, se il throughput effettivo si avvicina costantemente ai livelli di throughput a caldo, DynamoDB può suddividere le partizioni occupate in base ai modelli di utilizzo osservati.

Identifica le chiavi calde: se la tabella non ha risolto il problema automaticamente e il throughput a caldo è elevato o un aumento non è risultato utile, sarà necessario identificare le chiavi calde specifiche. Utilizza Identificazione dei tasti di scelta rapida mediante Contributor Insights CloudWatch per determinare se alcuni valori di una particolare chiave di partizione non sono validi. È un primo passo per indirizzare gli sforzi di mitigazione in modo efficace. L’identificazione potrebbe non essere sempre semplice, in particolare nel caso di partizioni calde continue (in cui partizioni diverse si surriscaldano nel tempo) o quando la limitazione (della larghezza di banda della rete) è 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 (della larghezza di banda della rete).

A seconda del caso d'uso, prendi in considerazione l'utilizzo di letture che alla fine sono consistenti: passa da letture fortemente coerenti a letture sostanzialmente coerenti, che consumano la metà RCUs e possono immediatamente raddoppiare la capacità di lettura effettiva. Per le best practice sull’implementazione di letture a coerenza finale per ridurre l’utilizzo 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 per distribuire l’accesso in modo più uniforme tra le partizioni. Questo approccio spesso fornisce la soluzione più completa ai problemi relativi alle partizioni calde risolvendo la causa principale. Tuttavia, richiede un’attenta pianificazione in quanto comporta sfide di migrazione significative.

Pre-riscalda la capacità: se la limitazione (della larghezza di banda della rete) persiste, controlla se la capacità della tabella è limitata dalla sua capacità Funzionamento del throughput di DynamoDB. Utilizza il throughput a caldo o aumenta in anticipo la capacità di scrittura allocata per far fronte agli aumenti di traffico previsti. L’aumento del throughput a caldo migliora la capacità della tabella di gestire picchi di traffico improvvisi prima che si verifichi la limitazione (della larghezza di banda della rete). Nel tempo, se il throughput effettivo si avvicina costantemente ai livelli di throughput a caldo, DynamoDB può suddividere le partizioni occupate in base ai modelli di utilizzo osservati.

Identifica le chiavi calde: se la tabella non ha risolto il problema automaticamente e il throughput a caldo è elevato o un aumento non è risultato utile, sarà necessario identificare le chiavi calde specifiche. Utilizza Identificazione dei tasti di scelta rapida mediante Contributor Insights CloudWatch per determinare se alcuni valori di una particolare chiave di partizione non sono validi. È un primo passo per indirizzare gli sforzi di mitigazione in modo efficace. Prendi in considerazione questi modelli comuni:

La limitazione (della larghezza di banda della rete) di scrittura può verificarsi anche con operazioni come BatchWriteItem o transazioni che riguardano più elementi contemporaneamente. Quando i singoli elementi di una richiesta BatchWriteItem vengono limitati, DynamoDB non propaga questi errori di limitazione (della larghezza di banda della rete) al codice dell’applicazione. Piuttosto, DynamoDB restituisce informazioni sugli elementi non elaborati nella risposta, che l’applicazione deve gestire effettuando ripetizioni di tentativi per quegli elementi specifici. Per le transazioni, l’intera operazione ha esito negativo e viene segnalata una TransactionCanceledException in caso di eventuale limitazione (della larghezza di banda della rete) di un elemento. Per questi scenari complessi, potrebbe essere necessario analizzare i modelli di scrittura e i flussi di lavoro di importazione dei dati dell’applicazione, correlarli alla tempistica degli eventi di limitazione (della larghezza di banda della rete) e implementare strategie appropriate di gestione delle ripetizioni dei tentativi.

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

Pre-riscalda la capacità: se la limitazione (della larghezza di banda della rete) persiste, controlla se il GSI è limitato dalla sua capacità Funzionamento del throughput di DynamoDB. Utilizza il throughput a caldo o aumenta in anticipo la capacità di lettura allocata per far fronte agli aumenti di traffico previsti. L’aumento del throughput a caldo migliora la capacità del GSI di gestire picchi di traffico improvvisi prima che si verifichi la limitazione (della larghezza di banda della rete). Nel tempo, se il throughput effettivo si avvicina costantemente ai livelli di throughput a caldo, DynamoDB può suddividere le partizioni occupate in base ai modelli di utilizzo osservati.

Identifica le chiavi calde: se il GSI non ha risolto il problema automaticamente e il throughput a caldo è elevato o un aumento non è risultato utile, sarà necessario identificare le chiavi calde specifiche. Utilizza Identificazione dei tasti di scelta rapida mediante Contributor Insights CloudWatch per determinare se alcuni valori di una particolare chiave di partizione non sono validi. È un primo passo per indirizzare gli sforzi di mitigazione in modo efficace. Tieni presente che GSIs, per, la distribuzione delle chiavi di partizione può differire notevolmente dalla tabella di base, creando diversi modelli di tasti di scelta rapida.

Riprogetta le chiavi di partizione del GSI: valuta se la progettazione delle chiavi del 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 tecniche Utilizzo dello sharding di scrittura per distribuire i carichi di lavoro in modo uniforme in una tabella DynamoDB agli elementi della tabella di base che influiscono sulla distribuzione del GSI per distribuire le scritture su più partizioni. Sebbene l’esecuzione di query su dati sottoposti a sharding richieda una logica applicativa aggiuntiva per aggregare i risultati, questo approccio impedisce la limitazione (della larghezza di banda della rete) distribuendo i modelli di accesso in modo più uniforme.

Riprogetta la chiave di partizione del GSI: controlla la progettazione delle chiavi di partizione del GSI per verificare che abbia una cardinalità (unicità) sufficiente per distribuire le scritture in modo uniforme. Una causa comune della limitazione (della larghezza di banda della rete) di scrittura nei GSI è l’uso di attributi a bassa cardinalità come chiavi di partizione degli stessi (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 essere riscontrate 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 applicano tecniche Utilizzo dello sharding di scrittura per distribuire i carichi di lavoro in modo uniforme in una tabella DynamoDB agli elementi della tabella di base che influiscono sulla distribuzione del GSI per distribuire le scritture su più partizioni. Sebbene l’esecuzione di query su dati sottoposti a sharding richieda una logica applicativa aggiuntiva per aggregare i risultati, questo approccio impedisce la limitazione (della larghezza di banda della rete) distribuendo i modelli di accesso in modo più uniforme.

Pre-riscalda la capacità: controlla se il GSI è limitato dalla sua capacità Funzionamento del throughput di DynamoDB. Utilizza il throughput a caldo o aumenta in anticipo la capacità di lettura allocata per far fronte agli aumenti di traffico previsti. L’aumento del throughput a caldo migliora la capacità del GSI di gestire picchi di traffico improvvisi prima che si verifichi la limitazione (della larghezza di banda della rete). Nel tempo, se il throughput effettivo si avvicina costantemente ai livelli di throughput a caldo, DynamoDB può suddividere le partizioni occupate in base ai modelli di utilizzo osservati.

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

Eventi di limitazione (della larghezza di banda della rete) a livello di partizione: ReadKeyRangeThroughputThrottleEvents e WriteKeyRangeThroughputThrottleEvents monitorano quando singole partizioni superano i limiti di throughput. ReadThrottleEvents e WriteThrottleEvents monitorano quando le richieste di lettura o scrittura superano la capacità allocata.

Utilizzo di capacità: ConsumedReadCapacityUnits e ConsumedWriteCapacityUnits mostrano i modelli di utilizzo complessivi.

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 delle chiavi.

Impatto sulla produzione: la migrazione a una nuova progettazione delle chiavi spesso richiede tempi di inattività o complesse strategie di doppia scrittura durante la transizione.

Per ulteriori informazioni sull'utilizzo GSIs per distribuire il traffico di lettura, consulta Using Global Secondary Indexes per creare indici secondari coerenti in Amazon DynamoDB.

Per una guida pratica sul dimensionamento di DynamoDB e la gestione delle partizioni calde, consulta Part 1: Scaling DynamoDB - How partitions, hot keys, and split for heat impact performance.

Per informazioni dettagliate su come funziona il split-for-heat meccanismo di DynamoDB, i suoi vantaggi e i dettagli di implementazione, consulta la Parte 3: Riepilogo e best practice.

Per le strategie dettagliate di sharding di scrittura, consulta Utilizzo dello sharding di scrittura per distribuire i carichi di lavoro in modo uniforme in una tabella DynamoDB.