When Should Use Amazon DynamoDB Accelerator (AWS DAX)?
The main purpose of Amazon DynamoDB Accelerator (AWS DAX) is in-memory cache. DAX manages cache invalidation, data population, or cluster management. So it can deliver up to a 10x performance improvement – from milliseconds to microseconds – even at millions of requests per second.
AWS DAX Architecture Overview
Amazon DynamoDB Accelerator (DAX) is a fully managed, highly available, in-memory cache for DynamoDB. Please review the architecture diagram from AWS:
From the diagram, we can see DAX, applications and DAX client are in the same Virtual Private Cloud (VPC) environment. So DAX is designed to run within a VPC in order to utilize VPC’s subnets, routing tables, network gateways, and security settings. A DAX cluster consists of one or more nodes. Each node runs its own instance of the DAX caching software. One of the nodes serves as the primary node for the cluster. Additional nodes if present serves as the read replicas. At runtime, the DAX client directs all of your application’s DynamoDB API requests to the DAX cluster. If DAX can process one of these API requests directly, it does so; otherwise, it passes the request through to DynamoDB. Finally, the DAX cluster returns the results to your application.
Types of Caches in AWS DAX
There are two types of caches in AWS DAX:
- Item cache: DAX maintains an item cache to store the results from GetItem and BatchGetItem operations. The items in the cache represent eventually consistent data from DynamoDB and are stored by their primary key values.
- Query cache: DAX maintains a query cache to store the results from Query and Scan operations. The items in this cache represent result sets from queries and scans on DynamoDB tables. These result sets are stored by their parameter values.
AWS DAX Flow Diagram
There are two categories of these APIs. Read APIs include GetItem, BatchGetItem, Query, and Scan. Modify APIs include PutItem, UpdateItem, DeleteItem, and BatchWriteItem
Let’s take a look at the flow diagram on DAX to read/write operations:
The left side is read through. When your application requests the read operation, there is no cache for the first time. DAX creates a cache and reads data from DynamoDB. Then in the second time, the application will hit the cache and return the item back to the application. The right side is the example of write through. The application writes data directly into DynamoDB. DAX sync the data in the cache. Then next time, the application will hit the cache to get the results.
AWS DAX provides a way to do in-memory cache. DAX reduces the response times of eventually-consistent read workloads from single-digit milliseconds to microseconds. DAX does increase throughput and save cost by reducing the need to over-provision read capacity units. However, If your applications that require strongly consistent reads or write-intensive, then you should not use DAX. If you need more details on DynamoDB, please review it in Hands-on with DynamoDB.
- Hands-on with DynamoDB
- AWS Data Warehouse – Build with Redshift and QuickSight
- AWS Relational Database Solution: Hands-on with AWS RDS
- Which is Right Hadoop Solution for You?
- Apache Hadoop Ecosystem Cheat Sheet
- Data Storage for Big Data: Aurora, Redshift or Hadoop?
- AWS Kinesis Data Streams vs. Kinesis Data Firehose
- Streaming Platforms: Apache Kafka vs. AWS Kinesis
- AWS Machine Learning on AWS Redshift Data
- Why Use AWS Redshift Spectrum with Data Lake
- How to Design AWS DynamoDB Data Modeling
- When Should Use Amazon DynamoDB Accelerator (AWS DAX)?
- Web Application with Aurora Serverless Cluster
- Top IT Certifications for 2018
- How I Passed AWS CSAA in 3 Months
- How to Pass AWS Certified Big Data Specialty
- AWS Elastic Beanstalk or AWS Elastic Container Service for Kubernetes (AWS EKS)
- How to Use AWS CodeStar to Manage Lambda Java Project from Source to Test Locally