Valutazione dell'idoneità di DAX per i vostri casi d'uso - Amazon DynamoDB
Quando e perché scegliere DAXQuando non usare DAX

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 vostri casi d'uso

Questa sezione spiega 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 livelli di scrittura e dati a cui si accede raramente.

Quando e perché scegliere DAX

Puoi prendere in considerazione l'aggiunta di DAX allo stack di applicazioni in diversi scenari. Ad esempio, utilizzate DAX 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 in microsecondi per letture alla fine coerenti. DAX può anche ridurre drasticamente i tempi di risposta per l'accesso ai dati letti di frequente.

  • Carichi di lavoro ad alta intensità 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. Ciò riduce le letture su una tabella. Per evitare di leggere dati obsoleti dalla cache se l'applicazione richiede molta scrittura, assicuratevi di impostare un valore inferiore Usare time to live (TTL) in DynamoDB per la cache.

    • Memorizzazione nella cache 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 a raffica

  • Ottimizzazione dei costi

    • Riduzione dei costi di DynamoDB: la lettura da DAX può ridurre le letture inviate a una tabella DynamoDB, con un impatto diretto sui costi. Con un elevato tasso di accesso alla cache, il costo ridotto di lettura delle tabelle può superare il costo di un cluster DAX, il che si traduce in una riduzione dei costi netti.

  • Requisiti di consistenza dei dati

    • Coerenza finale: DAX supporta letture alla fine coerenti. Ciò rende DAX adatto a casi d'uso in cui la coerenza immediata non è fondamentale.

    • Scrittura nella cache: 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 scrittura aiuta a mantenere una maggiore coerenza dei dati tra cache e database, ma utilizza risorse aggiuntive del cluster DAX.

Quando non usare 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 livelli 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 un elevato livello di scrittura, i vantaggi di DAX potrebbero essere limitati.

  • Dati letti raramente: 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 calo. cache hit ratio 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 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 memorizzati nella cache; pertanto, il routing di tali elementi tramite DAX non serve a nulla.

  • 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 millisecondi.

  • Esigenze di interrogazione complesse che vanno oltre l'accesso chiave-valore: DAX è ottimizzato per modelli di accesso chiave-valore. Se l'applicazione richiede funzionalità di interrogazione complesse con filtri complessi, come le operazioni di interrogazione e scansione, i vantaggi della memorizzazione nella cache 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.