Configurazione del cluster DAX
Il cluster DAX è un cluster gestito, ma è possibile modificarne le configurazioni in base ai requisiti delle applicazioni. A causa della stretta integrazione con le operazioni API DynamoDB, è necessario considerare i seguenti aspetti quando si integra l’applicazione con DAX.
In questa sezione
Prezzi di DAX
Il costo di un cluster dipende dal numero e dalla dimensione dei nodi allocati. Ogni nodo viene fatturato per ogni ora di esecuzione nel cluster. Per ulteriori informazioni, consulta Prezzi di Amazon DynamoDB
I riscontri nella cache non comportano costi per DynamoDB, ma influiscono sulle risorse del cluster DAX. I mancati riscontri nella cache comportano costi di lettura di DynamoDB e richiedono risorse DAX. Le scritture comportano costi di scrittura di DynamoDB e influiscono sulle risorse del cluster DAX per delegare la scrittura.
Cache degli elementi e cache delle query
DAX gestisce una cache degli elementi e una cache delle query. Comprendere le differenze tra queste cache può aiutare a determinare le caratteristiche di prestazioni e coerenza offerte all’applicazione.
| Caratteristiche delle cache | Cache degli elementi | Cache delle query |
|---|---|---|
|
Scopo |
Archivia i risultati delle operazioni API GetItem e BatchGetItem. |
Archivia i risultati delle operazioni API Query e Scan. Queste operazioni possono restituire più elementi in base alle condizioni di query anziché a chiavi di elemento specifiche. |
|
Tipo di accesso |
Utilizza accessi basati su chiavi. Quando un’applicazione richiede dati attraverso |
Utilizza l’accesso basato su parametri. DAX archivia nella cache il set di operazioni API |
|
Invalidamento della cache |
DAX replica automaticamente gli elementi aggiornati nella cache degli elementi dei nodi del cluster DAX nei seguenti scenari:
|
La cache delle query è più difficile da invalidare rispetto alla cache degli elementi. Gli aggiornamenti degli elementi potrebbero non corrispondere direttamente alle query o alle scansioni archiviate nella cache. È necessario ottimizzare attentamente il TTL della cache delle query per mantenere la coerenza dei dati. Le scritture tramite DAX o la tabella di base non si riflettono nella cache delle query finché il TTL non fa scadere la risposta precedentemente archiviata nella cache e DAX non esegue una nuova query su DynamoDB. |
|
Indice secondario globale |
Poiché l’operazione API GetItem non è supportata sugli indici secondari locali o sugli indici secondari globali, la cache degli elementi archivia nella cache solo le letture dalla tabella di base. |
La cache delle query archivia nella cache le query relative sia alle tabelle che agli indici. |
Selezione dell’impostazione del TTL per le cache
Il TTL determina il periodo per il quale i dati vengono archiviati nella cache prima che diventino obsoleti. Dopo questo periodo, i dati vengono aggiornati automaticamente alla richiesta successiva. La scelta dell’impostazione del TTL corretta per le cache DAX implica un equilibrio tra l’ottimizzazione delle prestazioni delle applicazioni e la coerenza dei dati. Poiché non esiste un’impostazione del TTL universale che funzioni per tutte le applicazioni, l’impostazione del TTL ottimale varia in base alle caratteristiche e ai requisiti specifici dell’applicazione. Si consiglia di iniziare con un’impostazione del TTL conservativa utilizzando questo prontuario. Quindi sarà possibile modificare in modo iterativo l’impostazione del TTL in base ai dati e alle informazioni sulle prestazioni dell’applicazione.
DAX conserva un elenco degli elementi utilizzati meno di recente (LRU) per la cache di elementi. L’elenco LRU tiene traccia della prima scrittura o dell’ultima lettura degli elementi dalla cache. Quando la memoria del nodo DAX è piena, DAX elimina gli elementi più vecchi, anche se non sono ancora scaduti, per fare spazio a quelli nuovi. L’algoritmo LRU è sempre abilitato e non è configurabile dall’utente.
Per impostare una durata del TTL adatta alle applicazioni, è necessario considerare i seguenti punti:
Funzionamento dei modelli di accesso ai dati
-
Carichi di lavoro con elevati requisiti di lettura: per le applicazioni con carichi di lavoro di questo tipo e aggiornamenti dei dati poco frequenti, imposta una durata del TTL più lunga per ridurre il numero di mancati riscontri nella cache. Una durata del TTL più lunga riduce anche la necessità di accedere alla tabella DynamoDB sottostante.
-
Carichi di lavoro con elevati requisiti di scrittura: per le applicazioni con aggiornamenti frequenti che non vengono scritti tramite DAX, imposta una durata del TTL più breve per garantire che la cache rimanga coerente con il database. Una durata del TTL più breve riduce anche il rischio di fornire dati obsoleti.
Valutazione dei requisiti prestazionali delle applicazioni
-
Sensibilità alla latenza: se l’applicazione richiede una bassa latenza rispetto all’aggiornamento dei dati, utilizza una durata del TTL più lunga. Una durata del TTL più lunga massimizza i riscontri nella cache, riducendo la latenza media di lettura.
-
Throughput e scalabilità: una durata del TTL più lunga riduce il carico sulle tabelle DynamoDB e migliora il throughput e la scalabilità. Tuttavia, è necessario bilanciare questo aspetto con la necessità di dati aggiornati.
Analisi dell’espulsione della cache e dell’utilizzo della memoria
-
Limiti della memoria cache: monitora l’utilizzo della memoria del cluster DAX. Una durata del TTL più lunga può archiviare più dati nella cache, il che potrebbe portare a raggiungere i limiti di memoria e a espulsioni basate in base all’algoritmo LRU.
Utilizzo di metriche e monitoraggio per regolare il TTL
Esamina regolarmente le metriche, ad esempio i riscontri e i mancati riscontri nella cache e l’utilizzo della CPU e della memoria. Modifica l’impostazione del TTL in base a queste metriche per trovare un equilibrio ottimale tra prestazioni e aggiornamento dei dati. Se i mancati riscontri nella cache sono elevati e l’utilizzo della memoria è basso, aumenta la durata del TTL per aumentare la percentuale di riscontri nella cache.
Considerazione dei requisiti aziendali e della conformità
Le policy di conservazione dei dati potrebbero dettare la durata massima del TTL che è possibile impostare per le informazioni sensibili o personali.
Comportamento della cache in caso di impostazione del TTL su zero
Se si imposta il TTL su 0, la cache degli elementi e la cache delle query presentano i seguenti comportamenti:
-
Cache degli elementi: gli elementi nella cache vengono aggiornati solo quando si verifica un’espulsione in base all’algoritmo LRU o un’operazione write-through.
-
Cache delle query: le risposte alle query non vengono archiviate nella cache.
Caching di più tabelle con un cluster DAX
Per i carichi di lavoro con più tabelle DynamoDB di piccole dimensioni che non richiedono cache individuali, un singolo cluster DAX archivia nella cache le richieste per queste tabelle. Ciò consente un uso più flessibile ed efficiente di DAX, in particolare per le applicazioni che accedono a più tabelle e richiedono letture ad alte prestazioni.
Analogamente alle API del piano dati DynamoDB, le richieste DAX richiedono un nome di tabella. Se si utilizzano più tabelle nello stesso cluster DAX, non è necessaria alcuna configurazione specifica. Tuttavia, è necessario verificare che le autorizzazioni di sicurezza del cluster consentano l’accesso a tutte le tabelle archiviate nella cache.
Considerazioni sull’utilizzo di DAX con più tabelle
Durante l’utilizzo di DAX con più tabelle DynamoDB, è necessario considerare i seguenti punti:
-
Gestione della memoria: quando si utilizza DAX con più tabelle, è necessario considerare la dimensione totale del set di dati di lavoro. Tutte le tabelle del set di dati condivideranno lo stesso spazio di memoria del tipo di nodo selezionato.
-
Allocazione delle risorse: le risorse del cluster DAX sono condivise tra tutte le tabelle archiviate nella cache. Tuttavia, una tabella a traffico elevato può causare l’espulsione dei dati dalle tabelle più piccole adiacenti.
-
Economie di scala: raggruppa le risorse più piccole in un cluster DAX più grande per calcolare la media del traffico secondo uno schema più stabile. Per il numero totale di risorse di lettura richieste dal cluster DAX, è anche conveniente disporre di tre o più nodi. Ciò aumenta anche la disponibilità di tutte le tabelle archiviate nella cache del cluster.
Replica dei dati nelle tabelle globali DAX e DynamoDB
DAX è un servizio basato sulla Regione, quindi un cluster è a conoscenza solo del traffico all’interno della sua Regione AWS. Le tabelle globali scrivono nella cache in modalità write-around quando replicano i dati da un’altra Regione.
Una durata del TTL più lunga può far sì che i dati non aggiornati rimangano nella Regione secondaria più a lungo rispetto alla Regione principale. Ciò può causare mancati riscontri nella cache locale della Regione secondaria.
Il diagramma seguente mostra la replica dei dati che si verifica a livello di tabella globale nella Regione di origine A. Il cluster DAX nella Regione B non è immediatamente a conoscenza dei nuovi dati replicati dalla Regione di origine A.
Disponibilità di DAX nelle Regioni
Non tutte le Regioni che supportano le tabelle DynamoDB supportano l’implementazione di cluster DAX. Se l’applicazione richiede una bassa latenza di lettura tramite DAX, consulta innanzitutto l’elenco delle Regioni che supportano DAX. Quindi, seleziona una Regione per la tabella DynamoDB.
Comportamento del caching di DAX
DAX esegue caching su metadati e caching negativo. La comprensione di questi comportamenti di caching aiuta a gestire in modo efficace i metadati degli attributi degli elementi archiviati nella cache e delle voci della cache negativa.
-
Caching dei metadati: i cluster DAX mantengono indefinitamente i metadati sui nomi degli attributi degli elementi archiviati nella cache. Questi metadati persistono anche dopo la scadenza dell’elemento o dopo l’espulsione dalla cache.
Col tempo, le applicazioni che utilizzano un numero illimitato di nomi di attributi possono causare il riempimento totale della memoria nel cluster DAX. Questo limite si applica solo ai nomi di attributi di primo livello, ma non ai nomi di attributi annidati. Esempi di nomi di attributi non limitati, compresi timestamp, UUID e ID di sessione. Sebbene sia possibile utilizzare timestamp e ID di sessione come valori di attributo, si consiglia di utilizzare nomi di attributi più brevi e prevedibili.
-
Caching negativo: se si verifica un errore nella cache e la lettura da una tabella DynamoDB non produce elementi corrispondenti, DAX aggiunge una voce di cache negativa nella rispettiva cache degli elementi o delle query. Questa voce rimane valida fino alla scadenza della durata del TTL della cache o fino a quando non si verifica una procedura write-through. DAX continua a restituire questa voce della cache negativa per le richieste future.
Se il comportamento di caching negativo non si adatta al modello dell’applicazione, leggi direttamente la tabella DynamoDB quando DAX restituisce un risultato vuoto. Si consiglia inoltre di impostare una durata della cache del TTL inferiore per evitare risultati vuoti a lungo termine nella cache e migliorare la coerenza con la tabella.
