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à.
Valuta i modelli di utilizzo delle tabelle DynamoDB
In questa sezione viene fornita una panoramica su come valutare se si stanno utilizzando le tabelle DynamoDB in modo efficiente. Alcuni modelli di utilizzo non sono ottimali per DynamoDB e lasciano spazio all'ottimizzazione sia dal punto di vista delle prestazioni che dei costi.
Argomenti
Riduzione del numero di operazioni ad elevata consistenza di lettura
DynamoDB consente di configurare la consistenza di lettura in base alle richieste. Le richieste di lettura sono a consistenza finale per impostazione predefinita. Alla fine, le letture coerenti vengono addebitate a 0,5 RCU per un massimo di 4 KB di dati.
La maggior parte dei carichi di lavoro distribuiti sono flessibili e possono tollerare la consistenza finale. Tuttavia, possono esserci schemi di accesso che richiedono elevata consistenza di lettura. Le letture estremamente coerenti vengono addebitate a 1 RCU per un massimo di 4 KB di dati, il che significa sostanzialmente il doppio dei costi di lettura. DynamoDB offre la flessibilità di utilizzare entrambi i modelli di consistenza sulla stessa tabella.
È possibile valutare il carico di lavoro e il codice dell'applicazione per verificare se vengono utilizzate letture ad elevata consistenza solo dove necessario.
Riduzione del numero di transazioni per le operazioni di lettura
DynamoDB ti consente di raggruppare determinate azioni in all-or-nothing un modo, il che significa che hai la possibilità di eseguire ACID transazioni con DynamoDB. Tuttavia, come nel caso dei database relazionali, non è necessario seguire questo approccio per ogni operazione.
Un'operazione di lettura transazionale fino a 4 KB consuma 2 RCUs a differenza dell'impostazione predefinita di 0,5 RCUs per leggere la stessa quantità di dati in modo sostanzialmente coerente. I costi delle operazioni di scrittura sono raddoppiati, il che significa che una scrittura transazionale fino a 1 KB equivale a 2. WCUs
Per determinare se tutte le operazioni sulle tabelle sono transazioni, è possibile filtrare le CloudWatch metriche relative alla tabella fino alla transazione. APIs Se APIs le transazioni sono gli unici grafici disponibili sotto le SuccessfulRequestLatency metriche della tabella, ciò confermerebbe che ogni operazione è una transazione per questa tabella. In alternativa, se la tendenza complessiva dell'utilizzo della capacità corrisponde a quella delle transazioniAPI, è consigliabile rivedere il design dell'applicazione, in quanto sembra dominato da quello transazionale. APIs
Riduzione del numero di scansioni
L'uso estensivo delle operazioni Scan deriva generalmente dalla necessità di eseguire query analitiche sui dati DynamoDB. Eseguire frequenti operazioni Scan su una tabella di grandi dimensioni può essere inefficiente e costoso.
Un'alternativa migliore consiste nell'utilizzare la funzionalità Esporta in S3 e scegliere un momento temporale per esportare lo stato della tabella in S3. AWS offre servizi come Athena che possono quindi essere utilizzati per eseguire query analitiche sui dati senza consumare alcuna capacità della tabella.
La frequenza delle operazioni Scan può essere determinata utilizzando la statistica SampleCount della metrica SuccessfulRequestLatency per Scan. Se le operazioni Scan sono davvero molto frequenti, i modelli di accesso e il modello dei dati dovrebbero essere rivalutati.
Abbreviazione dei nomi di attributi
La dimensione totale di un elemento in DynamoDB è data dalla somma delle lunghezze dei nomi e dei valori dei relativi attributi. Avere nomi di attributi lunghi non solo contribuisce ai costi di archiviazione, ma potrebbe anche portare a un maggiore consumo diRCU/WCU. È consigliabile preferire nomi di attributo brevi piuttosto che lunghi. Avere nomi di attributi più brevi può aiutare a limitare la dimensione degli elementi entro il limite successivo di 4 KB/1 KB dopo il quale si consumerebbero ulterioriRCU/per accedere ai dati. WCU
Abilitazione del Time to Live (TTL) (TTL)
Time to Live (TTL) può identificare gli articoli più vecchi del tempo di scadenza impostato per un articolo e rimuoverli dalla tabella. Se i dati aumentano nel tempo e i dati più vecchi diventano irrilevanti, l'attivazione dell'opzione TTL on the table può aiutarti a ridurre i dati e a risparmiare sui costi di archiviazione.
Un altro aspetto utile TTL è che gli elementi scaduti si trovano nei flussi DynamoDB, quindi anziché limitarsi a rimuovere i dati dai dati, è possibile consumarli dal flusso e archiviarli su un livello di storage a basso costo. Inoltre, l'eliminazione degli elementi non TTL comporta costi aggiuntivi: non consuma capacità e non comporta alcun costo aggiuntivo per la progettazione di un'applicazione di pulizia.
Sostituzione delle tabelle globali con backup tra regioni
Le tabelle globali consentono di mantenere più tabelle di replica attive in diverse regioni: possono tutte accettare operazioni di scrittura e replicare i dati l'una sull'altra. È facile configurare le repliche e la sincronizzazione viene gestita automaticamente. Le repliche convergono verso uno stato coerente facendo prevalare la versione dell'ultimo utente che ha modificato il file.
Se si utilizzano le tabelle globali esclusivamente come parte di una strategia di failover o di ripristino di emergenza (DR), è possibile sostituirle con una copia di backup tra regioni per obiettivi di punti di ripristino e requisiti relativi ai tempi di ripristino relativamente permissivi. Se non è necessario un accesso locale rapido e l'elevata disponibilità continua, mantenere una replica globale della tabella potrebbe non essere l'approccio migliore per il failover.
In alternativa, prendi in considerazione l'utilizzo di AWS Backup per gestire i backup di DynamoDB. È possibile pianificare backup regolari e copiarli in più regioni per soddisfare i requisiti di DR con un approccio più conveniente rispetto all'utilizzo delle tabelle globali.
