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à.
Valutazione dell’idoneità di DAX per i vari casi d’uso
Questa sezione illustra quando e perché usare DAX. L’utilizzo di questa guida consente di determinare se l’integrazione di DAX con DynamoDB è vantaggiosa per i modelli di carico di lavoro, i requisiti di prestazioni e le esigenze di coerenza dei dati dell’applicazione. Vengono inoltre illustrati gli scenari in cui DAX potrebbe non essere adatto, ad esempio, carichi di lavoro con elevati requisiti di scrittura e dati con accesso infrequente.
In questa sezione
Quando e perché scegliere DAX
È possibile prendere in considerazione l’aggiunta di DAX allo stack di applicazioni in diversi scenari. Ad esempio, DAX è utile per ridurre la latenza complessiva delle richieste di lettura su DynamoDB o per ridurre al minimo le letture ripetute degli stessi dati da una tabella. L’elenco seguente presenta esempi di scenari in cui è possibile trarre vantaggio dall’integrazione di DAX con DynamoDB:
-
Requisito di alte prestazioni
-
Letture a bassa latenza: è consigliabile prendere in considerazione l’utilizzo di DAX se l’applicazione richiede tempi di risposta di pochi microsecondi per letture a coerenza finale. DAX può anche ridurre drasticamente i tempi di risposta per l’accesso ai dati con letture frequenti.
-
-
Carichi di lavoro a elevati requisiti di lettura
-
Applicazioni ad alta intensità di lettura: per le applicazioni con un read-to-write rapporto elevato, ad esempio 10:1 o più, DAX genera più accessi alla cache e meno dati obsoleti. In questo modo si riducono le letture su una tabella. Per evitare di leggere dati obsoleti dalla cache se l’applicazione ha elevati requisiti di scrittura, assicurati di impostare un valore Utilizzo del Time to Live in DynamoDB inferiore per la cache.
-
Caching delle query più comuni: se l’applicazione legge spesso gli stessi dati, ad esempio i prodotti più diffusi su una piattaforma di e-commerce, DAX può gestire queste richieste direttamente dalla sua cache.
-
-
Schemi di traffico con momenti di maggiore carico
-
Dimensionamento più fluido delle tabelle: DAX aiuta a mitigare gli impatti dei picchi di traffico improvvisi. DAX fornisce un buffer per aumentare verticalmente la capacità delle tabelle DynamoDB in modo corretto, riducendo il rischio di limitazione (della larghezza di banda della rete) della lettura.
-
Maggiore throughput di lettura per ogni elemento: DynamoDB alloca partizioni individuali per ogni elemento. Tuttavia, una partizione inizia a sottoporre a limitazione (della larghezza di banda della rete) le letture di un elemento quando raggiunge le 3.000 unità di capacità di lettura (RCU). DAX consente di scalare le letture di un singolo elemento oltre 3.000 RCU.
-
-
Ottimizzazione dei costi
-
Riduzione dei costi di DynamoDB: la lettura con DAX può ridurre le letture inviate a una tabella DynamoDB, con un impatto diretto sui costi. Con un’elevata percentuale di riscontri nella cache, il costo ridotto di lettura delle tabelle può superare il costo di un cluster DAX, il che comporta una riduzione dei costi netti.
-
-
Requisiti di coerenza dei dati
-
Coerenza finale: DAX supporta letture a coerenza finale. Ciò rende DAX adatto a casi d’uso in cui la coerenza immediata non è fondamentale.
-
Caching di tipo write-through: le scritture eseguite su DAX sono di tipo write-through. Una volta che DAX conferma di aver scritto un elemento in DynamoDB, mantiene la versione dell’elemento nella cache degli elementi. Questo meccanismo di write-through aiuta a mantenere una maggiore coerenza dei dati tra cache e database, ma utilizza risorse aggiuntive del cluster DAX.
-
Quando non utilizzare DAX
Sebbene DAX sia potente, non è adatto a tutti gli scenari. L’elenco seguente presenta esempi di scenari in cui l’integrazione di DAX con DynamoDB non è adatta:
-
Carichi di lavoro con elevati requisiti di scrittura: il vantaggio principale di DAX è la velocizzazione delle letture, ma le scritture utilizzano più risorse DAX rispetto alle letture. Se l’applicazione è prevalentemente caratterizzata da elevati requisiti di scrittura, i vantaggi di DAX potrebbero essere limitati.
-
Dati con letture infrequenti: se l’applicazione accede ai dati raramente o se l’applicazione accede a un’ampia gamma di dati riutilizzati raramente (dati inutilizzati), è probabile che si verifichi un cache hit ratio basso. In questo caso, il sovraccarico legato alla manutenzione della cache potrebbe non giustificare l’aumento delle prestazioni.
-
Letture o scritture in blocco: se l’applicazione esegue più scritture in blocco rispetto alle singole scritture, è consigliabile utilizzare il write-around su DAX. Inoltre, per le letture collettive, è necessario eseguire scansioni complete della tabella direttamente su una tabella DynamoDB.
-
Requisiti di coerenza o transazione elevati: DAX trasmette letture e TransactGetItemschiamate estremamente coerenti a una tabella DynamoDB. È necessario effettuare queste letture sul cluster DAX per evitare di utilizzare le risorse del cluster. Gli elementi letti in questo modo non verranno archiviati nella cache; pertanto, l’instradamento di tali elementi tramite DAX non ha utilità.
-
Applicazioni semplici con requisiti prestazionali modesti: per le applicazioni con requisiti prestazionali modesti e tolleranza per la latenza diretta di DynamoDB, la complessità e il costo dell’aggiunta di DAX potrebbero non essere necessari. Da solo, DynamoDB gestisce un throughput elevato e fornisce prestazioni a una cifra in pochi millisecondi.
-
Esigenze di query complesse che vanno oltre l’accesso chiave-valore: DAX è ottimizzato per modelli di accesso chiave-valore. Se l’applicazione richiede funzionalità di query complesse con filtri complessi, come le operazioni Query e Scan, i vantaggi del caching con DAX potrebbero essere limitati.
In queste situazioni, usa Amazon ElastiCache (Redis OSS) come alternativa. ElastiCache (Redis OSS) supporta strutture di dati avanzate, come elenchi, set e hash. Offre anche funzionalità come pub/sub, indici geospaziali e scripting.
-
Requisiti di conformità: attualmente DAX non offre gli stessi accreditamenti di conformità di DynamoDB. Ad esempio, DAX non ha ancora ottenuto l’accreditamento SOC.
