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à.
Il cluster DAX è un cluster gestito, ma è possibile modificarne le configurazioni in base ai requisiti dell'applicazione. A causa della sua stretta integrazione con le operazioni dell'API DynamoDB, è necessario considerare i seguenti aspetti quando si integra l'applicazione con DAX.
In questa sezione
Prezzi DAX
Il costo di un cluster dipende dal numero e dalla dimensione dei nodi a cui è stato assegnato il provisioning. Ogni nodo viene fatturato per ogni ora di esecuzione nel cluster. Per ulteriori informazioni, consulta Prezzi di Amazon DynamoDB
Gli accessi alla cache non comportano costi per DynamoDB, ma influiscono sulle risorse del cluster DAX. Gli errori 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 interrogazioni
DAX gestisce una cache degli elementi e una cache delle interrogazioni. Comprendere le differenze tra queste cache può aiutarvi a determinare le caratteristiche di prestazioni e coerenza che offrono all'applicazione.
| Caratteristica della cache | Cache degli elementi | Cache delle query |
|---|---|---|
|
Scopo |
Memorizza i risultati GetIteme le operazioni BatchGetItemAPI. |
Memorizza i risultati delle operazioni delle API Query e Scan. Queste operazioni possono restituire più elementi in base alle condizioni di interrogazione anziché a chiavi di elemento specifiche. |
|
Tipo di accesso |
Utilizza l'accesso basato su chiavi. Quando un'applicazione richiede dati utilizzando |
Utilizza l'accesso basato su parametri. DAX memorizza nella cache il set di risultati e le operazioni API. |
|
Invalidazione 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 memorizzate 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 scade la risposta precedentemente memorizzata nella cache e DAX non esegue una nuova query su DynamoDB. |
|
Indice secondario globale |
Poiché l'operazione GetItem API non è supportata sugli indici secondari locali o sugli indici secondari globali, la cache degli elementi memorizza nella cache solo le letture dalla tabella di base. |
La cache delle query memorizza nella cache le query relative sia alle tabelle che agli indici. |
Selezione dell'impostazione 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 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 TTL universale che funzioni per tutte le applicazioni, l'impostazione TTL ottimale varia in base alle caratteristiche e ai requisiti specifici dell'applicazione. Ti consigliamo di iniziare con un'impostazione TTL conservativa utilizzando questa guida prescrittiva. Quindi, modifica in modo iterativo l'impostazione TTL in base ai dati e alle informazioni sulle prestazioni dell'applicazione.
DAX mantiene un elenco degli elementi utilizzati più di recente (LRU) per la cache degli 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 nuovi elementi. L'algoritmo LRU è sempre abilitato e non configurabile dall'utente.
Per impostare una durata TTL adatta alle tue applicazioni, considera i seguenti punti:
Comprendi i tuoi modelli di accesso ai dati
-
Carichi di lavoro impegnativi in lettura: per le applicazioni con carichi di lavoro impegnativi in lettura e aggiornamenti dei dati poco frequenti, imposta una durata TTL più lunga per ridurre il numero di errori di cache. Una durata TTL più lunga riduce anche la necessità di accedere alla tabella DynamoDB sottostante.
-
Carichi di lavoro con elevati livelli di scrittura: per le applicazioni con aggiornamenti frequenti che non vengono scritti tramite DAX, imposta una durata TTL più breve per garantire che la cache rimanga coerente con il database. Una durata TTL più breve riduce anche il rischio di fornire dati obsoleti.
Valuta i requisiti prestazionali della tua applicazione
-
Sensibilità alla latenza: se l'applicazione richiede una bassa latenza rispetto all'aggiornamento dei dati, utilizza una durata TTL più lunga. Una durata TTL più lunga massimizza gli accessi alla cache, riducendo la latenza media di lettura.
-
Throughput e scalabilità: una durata TTL più lunga riduce il carico sulle tabelle DynamoDB e migliora la velocità effettiva e la scalabilità. Tuttavia, è necessario bilanciare questo aspetto con la necessità di dati. up-to-date
Analizza l'eliminazione della cache e l'utilizzo della memoria
-
Limiti della memoria cache: monitora l'utilizzo della memoria del cluster DAX. Una durata TTL più lunga può memorizzare più dati nella cache, il che potrebbe raggiungere i limiti di memoria e portare allo sfratto basato su LRU.
Utilizza metriche e monitoraggio per regolare il TTL
Esamina regolarmente le metriche, ad esempio gli accessi e gli errori nella cache e l'utilizzo della CPU e della memoria. Modifica l'impostazione TTL in base a queste metriche per trovare un equilibrio ottimale tra prestazioni e aggiornamento dei dati. Se gli errori nella cache sono elevati e l'utilizzo della memoria è basso, aumenta la durata del TTL per aumentare la frequenza di accesso alla cache.
Considerate i requisiti aziendali e la conformità
Le politiche di conservazione dei dati potrebbero stabilire la durata massima del TTL che è possibile impostare per le informazioni sensibili o personali.
Comportamento della cache se imposti TTL su zero
Se impostate 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'eliminazione della LRU o un'operazione di scrittura.
-
Cache delle query: le risposte alle query non vengono memorizzate nella cache.
Memorizzazione nella cache 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 memorizza 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 al APIs 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 assicurarsi che le autorizzazioni di sicurezza del cluster consentano l'accesso a tutte le tabelle memorizzate nella cache.
Considerazioni sull'utilizzo di DAX con più tabelle
Quando si utilizza 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 memorizzate nella cache. Tuttavia, una tabella a traffico elevato può causare l'eliminazione 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 memorizzate 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 al suo interno. Regione AWS Le tabelle globali scrivono nella cache quando replicano i dati da un'altra regione.
Una durata 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 errori di cache 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à della regione DAX
Non tutte le regioni che supportano le tabelle DynamoDB supportano la distribuzione di cluster DAX. Se la tua applicazione richiede una bassa latenza di lettura tramite DAX, consulta innanzitutto l'elenco delle regioni che supportano DAX. Quindi, seleziona una regione per la tua tabella DynamoDB.
Comportamento della memorizzazione nella cache DAX
DAX esegue metadati e memorizzazione nella cache negativa. La comprensione di questi comportamenti di memorizzazione nella cache vi aiuterà a gestire in modo efficace i metadati degli attributi degli elementi memorizzati nella cache e delle voci negative della cache.
-
Memorizzazione nella cache dei metadati: i cluster DAX mantengono a tempo indeterminato i metadati relativi ai nomi degli attributi degli elementi memorizzati nella cache. Questi metadati persistono anche dopo la scadenza o l'eliminazione dell'elemento dalla cache.
Nel tempo, le applicazioni che utilizzano un numero illimitato di nomi di attributi possono causare l'esaurimento della memoria nel cluster DAX. Questa limitazione si applica solo ai nomi degli attributi di primo livello, ma non ai nomi degli attributi annidati. Esempi di nomi di attributi illimitati includono timestamp e session. UUIDs IDs Sebbene sia possibile utilizzare timestamp e session IDs come valori di attributo, si consiglia di utilizzare nomi di attributi più brevi e prevedibili.
-
Cache negativa: 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 TTL della cache o fino a quando non si verifica una procedura di scrittura. DAX continua a restituire questa voce negativa della cache per le richieste future.
Se il comportamento negativo della memorizzazione nella cache non si adatta al modello dell'applicazione, leggi direttamente la tabella DynamoDB quando DAX restituisce un risultato vuoto. Consigliamo inoltre di impostare una durata della cache TTL inferiore per evitare risultati vuoti a lungo termine nella cache e migliorare la coerenza con la tabella.
