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à.
Configurazione del cluster DAX
Il DAX cluster è un cluster gestito, ma è possibile modificarne le configurazioni in base ai requisiti dell'applicazione. A causa della sua stretta integrazione con le operazioni di API DynamoDB, è necessario considerare i seguenti aspetti quando si integra l'applicazione con. DAX
In questa sezione
DAXprezzi
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 DAX cluster per delegare la scrittura.
Cache degli elementi e cache delle query
DAXmantiene 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.
| Cache degli elementi | Cache delle query |
|---|---|
| Purpose | |
|
Memorizza i risultati GetIteme BatchGetItemAPIle operazioni. |
Memorizza i risultati delle API operazioni di interrogazione e scansione. Queste operazioni possono restituire più elementi in base alle condizioni di interrogazione anziché a chiavi di elemento specifiche. |
| Access type | |
|
Utilizza l'accesso basato su chiavi. Quando un'applicazione richiede dati utilizzando |
Utilizza l'accesso basato su parametri. DAXmemorizza nella cache il set di risultati e le operazioni. |
| Cache invalidation | |
|
DAXreplica automaticamente gli elementi aggiornati nella cache degli elementi dei nodi del DAX cluster 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 la cache delle query TTL per mantenere la coerenza dei dati. Le scritture attraverso la DAX tabella di base non si riflettono nella cache delle query fino alla TTL scadenza della risposta precedentemente memorizzata nella cache ed DAX esegue una nuova query su DynamoDB. |
| Global secondary index | |
Poiché l'GetItemAPIoperazione 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 delle impostazioni TTL per le cache
TTLdetermina 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'TTLimpostazione giusta per le DAX cache implica il bilanciamento tra l'ottimizzazione delle prestazioni delle applicazioni e la coerenza dei dati. Poiché non esiste un'TTLimpostazione universale che funzioni per tutte le applicazioni, l'TTLimpostazione ottimale varia in base alle caratteristiche e ai requisiti specifici dell'applicazione. Ti consigliamo di iniziare con un'TTLimpostazione conservativa utilizzando questa guida prescrittiva. Quindi, modifica in modo iterativo TTL l'impostazione in base ai dati e alle informazioni sulle prestazioni dell'applicazione.
DAXmantiene un elenco degli elementi utilizzati meno di recente (LRU) per la cache degli elementi. L'LRUelenco tiene traccia della prima scrittura o dell'ultima lettura degli elementi dalla cache. Quando la memoria del DAX nodo è piena, DAX elimina gli elementi più vecchi anche se non sono ancora scaduti per fare spazio a nuovi elementi. L'LRUalgoritmo è sempre abilitato e non configurabile dall'utente.
Per impostare una TTL durata 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 TTL durata più lunga per ridurre il numero di errori di cache. Una TTL durata maggiore riduce anche la necessità di accedere alla tabella DynamoDB sottostante.
-
Carichi di lavoro impegnativi in termini di scrittura: per le applicazioni con aggiornamenti frequenti e non scrittiDAX, imposta una TTL durata più breve per garantire che la cache rimanga coerente con il database. Una TTL durata 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 più lunga. TTL Una TTL durata maggiore massimizza gli accessi alla cache, riducendo la latenza media di lettura.
-
Throughput e scalabilità: una TTL durata maggiore 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 DAX cluster. Una TTL durata più lunga può memorizzare più dati nella cache, il che potrebbe raggiungere i limiti di memoria e portare a LRU sfratti generalizzati.
Utilizza metriche e monitoraggio per adeguarti TTL
Esamina regolarmente le metriche, ad esempio gli accessi e gli errori nella cache e CPU l'utilizzo della memoria. Modifica le TTL impostazioni 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 TTL durata per aumentare la frequenza di accesso alla cache.
Considerate i requisiti aziendali e la conformità
Le politiche di conservazione dei dati potrebbero stabilire la TTL durata massima che è possibile impostare per le informazioni sensibili o personali.
Comportamento della cache se impostato su TTL zero
Se è TTL impostato 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'operazione di LRU rimozione o 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 DAX singolo cluster memorizza nella cache le richieste per queste tabelle. Ciò consente un uso più flessibile ed efficiente diDAX, in particolare per le applicazioni che accedono a più tabelle e richiedono letture ad alte prestazioni.
Analogamente al APIs piano dati DynamoDBDAX, le richieste richiedono un nome di tabella. Se si utilizzano più tabelle nello stesso DAX cluster, 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 con DAX 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 DAX cluster sono condivise tra tutte le tabelle memorizzate nella cache. Tuttavia, una tabella ad alto traffico può causare l'eliminazione dei dati dalle tabelle più piccole adiacenti.
-
Economie di scala: raggruppa le risorse più piccole in un DAX cluster più grande per calcolare la media del traffico secondo uno schema più stabile. Per quanto riguarda il numero totale di risorse di lettura richieste dal DAX cluster, è 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 di 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 TTL durata maggiore 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 DAX cluster nella regione B non è immediatamente a conoscenza dei nuovi dati replicati dalla regione di origine A.
Disponibilità nelle regioni 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 letturaDAX, consulta innanzitutto l'elenco delle regioni che supportano. DAX Quindi, seleziona una regione per la tua tabella DynamoDB.
DAXcomportamento di memorizzazione nella cache
DAXesegue 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: DAX i cluster 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 corrispondentiDAX, aggiunge una voce negativa nella rispettiva cache degli elementi o delle query. Questa voce rimane valida fino alla scadenza della TTL durata della cache o fino a quando non si verifica una procedura di scrittura. DAXcontinua 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 DAX quando restituisce un risultato vuoto. Ti consigliamo inoltre di impostare una durata TTL della cache inferiore per evitare risultati vuoti di lunga durata nella cache e migliorare la coerenza con la tabella.
