Valutazione dell'idoneità di per i vostri casi d'uso DAX - 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 per i vostri casi d'uso DAX

Questa sezione spiega quando e perché utilizzarloDAX. L'utilizzo di questa guida consente di determinare se l'integrazione DAX con DynamoDB è vantaggiosa per i modelli di carico di lavoro, i requisiti di prestazioni e le esigenze di coerenza dei dati dell'applicazione. Copre anche scenari in cui DAX potrebbero non essere adatti, 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 DAX allo stack di applicazioni in diversi scenari. Ad esempio, DAX da utilizzare 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 DAX con DynamoDB:

  • Requisito di alte prestazioni

    • Letture a bassa latenza: è consigliabile utilizzarla DAX se l'applicazione richiede tempi di risposta in microsecondi per letture alla fine coerenti. DAXpuò 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 applicazioni con un read-to-write rapporto elevato, ad esempio 10:1 o più, si DAX ottengono 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ò soddisfare queste richieste direttamente dalla cache.

  • Schemi di traffico a raffica

  • Ottimizzazione dei costi

    • Riduzione dei costi di DynamoDB: Reading DAX from 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 del DAX cluster, il che si traduce in una riduzione dei costi netti.

  • Requisiti di consistenza dei dati

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

    • Scrittura nella cache: le scritture eseguite su cui si esegue la scrittura vengono eseguite in modalità write-through. DAX Una volta DAX confermato che è stato 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 di cluster aggiuntive. 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 DAX con DynamoDB non è adatta:

  • Carichi di lavoro con elevati livelli di scrittura: il vantaggio principale di DAX è quello di velocizzare le letture, ma le scritture utilizzano più risorse rispetto alle letture. DAX Se l'applicazione utilizza prevalentemente un elevato numero di scritture, i vantaggi potrebbero essere limitati. DAX

  • Dati letti raramente: se l'applicazione accede ai dati di rado 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 la tua applicazione esegue più scritture in blocco rispetto alle singole scritture, dovresti continuare a scrivere. DAX Inoltre, per le letture collettive, è necessario eseguire scansioni complete della tabella direttamente su una tabella DynamoDB.

  • Requisiti di coerenza o transazione elevati: DAX passa letture e TransactGetItemschiamate fortemente coerenti a una tabella DynamoDB. È necessario effettuare queste letture all'interno del DAX cluster 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 non DAX serve a nulla.

  • Applicazioni semplici con requisiti di prestazioni modesti: per le applicazioni con requisiti prestazionali modesti e tolleranza per la latenza diretta di DynamoDB, la complessità e il costo dell'aggiunta potrebbero non essere necessari. DAX Da solo, DynamoDB gestisce un throughput elevato e fornisce prestazioni a una cifra in millisecondi.

  • Le richieste di interrogazione complesse vanno ben oltre l'accesso chiave-valore: è ottimizzata per modelli di accesso chiave-valore. DAX Se l'applicazione richiede funzionalità di interrogazione complesse con filtri complessi, come le operazioni di interrogazione e scansione, i vantaggi della memorizzazione nella cache potrebbero essere limitati. DAX

    In queste situazioni, usa Amazon ElastiCache (RedisOSS) come alternativa. ElastiCache (RedisOSS) 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'SOCaccreditamento.