6.4 DynamoDB

DynamoDB introduction

DynamoDB is a fast and flexible NoSQL database service for all applications that need consistent, single-digit millisecond latency at any scale. It offers both of durability and low-latency read/write access to items ranging from 1 byte up to 400 KB. DynamoDB is a AWS fully managed database and supports both document and key-value data models. Its flexible data model and reliable performance make it a great fit for mobile apps, web session management, gaming, live events, digital ad serving, metadata storage for S3 object, IoT, and many other applications. If you have large objects (e.g. 10 GB or larger), store those objects in S3 and maintain the metadata in DynamoDB.

DynamoDB:

Stored on SSD storage
Spread across 3 geographically distinct data centers (i.e. 3 different facilities, or 3 different Availability Zones).
Eventual consistency reads (default). CAP -> AP.
- Consistency across all copies of data is usually reached within 1 second. Repeating a read after a short time should return the updated data. (Best read performance).
Strongly consistency reads. CAP -> CP.
- A strongly consistency read returns a result that reflects all writes that received a successful response prior to the read.

Read Consistency:

Amazon DynamoDB is available in multiple AWS regions around the world. Your data are rapidly replicated among multiple Availability Zones in a region. When your application writes data to a DynamoDB table and receives an HTTP 200 response (OK), all copies of the data are updated. The data is eventually consistent across all storage locations, usually within one second or less. DynamoDB supports eventually consistent and strongly consistent reads:

Eventually Consistent Reads.
- When you read data from a DynamoDB table, the response might not reflect the results of a recently completed write operation. The response might include some stale data. If you repeat your read request after a short time, the response should return the latest data.
Strongly Consistent Reads
- When you request a strongly consistent read, DynamoDB returns a response with the most up-to-date data, reflecting the updates from all prior write operations that were successful. A strongly consistent read might not be available if there is a network delay or outage.
Note: DynamoDB uses eventually consistent reads, unless you specify otherwise. Read operations (such as GetItem, Query, and Scan) provide a ConsistentRead parameter. If you set this parameter to true, DynamoDB uses strongly consistent reads during the operation.

Pricing:

Provisioned throughput capacity
- Write throughput $0.0065 per hour for every 10 units.
- Read throughput $0.0065 per hour for every 50 units.
Storage costs of $0.25 per GB per month.
Example:
- Let suppose your app needs to perform 1 million writes and 1 million reads per day, while storing 3 GB of data.
- First, you need to calculate how many writes and reads per second you need.
- 1 million evenly spread writes per day is equivalent to 1,000,000 writes / 24 hours / 60 minutes / 60 seconds = 11.6 writes per second.
- A DynamoDB write capacity unit can handle 1 write per second, so you need 12 write capacity units.
- Similarly, to handle 1 million strongly consistent reads per day, you need 12 read capacity units.
- With read capacity units, you are billed in blocks of 50, with write capacity units you are billed in blocks of 10.
- To calculate write capacity units = (0.0065 / 10) * 12 * 24 = $0.1872.
- To calculate read capacity units = (0.0065 / 50) * 12 * 24 = $0.0374.
- Thus, if your application will have lots of reads but not so much writes, and also need to be scalable and have a good performance, and also doesn't need anything like SQL Join queries, you will want to select DynamoDB instead of RDS.

Lab Steps

Go to AWS console and go to DynamoDB. Create Table.
Give the table a name and primary key.
In provisioned capacity, you can set both of the read capacity units and write capacity units to 1. Click Create.
Your table has been created, and you can see the region of it, the ARN (Amazon Resource Name) of it.
Go to Reserved capacity tab. Just like reserve capacity for EC2 instance, you can also reserve capacity for DynamoDB. It means you have to enter into a 1 ~ 3 years contract but it can save you lots of money.
Go to Tables, select the table you just now created. Go to Items tab and click Create Item. An item is basically a Row of a Table, or you can see it as a record. It is not like RDS, it can actually dynamically start adding columns and that's because it is NoSQL database. You can start adding different columns for different record sets.
You can use the filter to search in the table.
You can see the Metrics tab.
You can update the capacity in Capacity tab. You can change the read capacity units and write capacity units on the fly, and it means you will not have any downtime when you scale your database, so the scaling is really easy ("push button scaling"). In RDS, if you want to scale the database, you need to create a snapshot for it and you need to create a read replica and then you need to adjust the instance size and you finally will get to a point where you cannot scale it any higher, you cannot add any more read replicas, At that time, you need to consider about moving to DynamoDB which gives you "push button" scaling. In RDS, when you scale the database, it inevitably going to have some downtime because you are moving to different instance size classes, so that is really the key thing to remember when you go to the exam.

Previous6.3 RDS - Backups, Multi-AZ & Read Replicas Next6.5 Redshift

Last updated 5 years ago

Was this helpful?

DynamoDB introduction

DynamoDB:

Stored on SSD storage

Spread across 3 geographically distinct data centers (i.e. 3 different facilities, or 3 different Availability Zones).

Eventual consistency reads (default). CAP -> AP.

Consistency across all copies of data is usually reached within 1 second. Repeating a read after a short time should return the updated data. (Best read performance).

Strongly consistency reads. CAP -> CP.

A strongly consistency read returns a result that reflects all writes that received a successful response prior to the read.

Read Consistency:

Eventually Consistent Reads.

When you read data from a DynamoDB table, the response might not reflect the results of a recently completed write operation. The response might include some stale data. If you repeat your read request after a short time, the response should return the latest data.

Strongly Consistent Reads

When you request a strongly consistent read, DynamoDB returns a response with the most up-to-date data, reflecting the updates from all prior write operations that were successful. A strongly consistent read might not be available if there is a network delay or outage.

Note: DynamoDB uses eventually consistent reads, unless you specify otherwise. Read operations (such as GetItem, Query, and Scan) provide a ConsistentRead parameter. If you set this parameter to true, DynamoDB uses strongly consistent reads during the operation.

Pricing:

Provisioned throughput capacity

Write throughput $0.0065 per hour for every 10 units.
Read throughput $0.0065 per hour for every 50 units.

Storage costs of $0.25 per GB per month.

Example:

Let suppose your app needs to perform 1 million writes and 1 million reads per day, while storing 3 GB of data.
First, you need to calculate how many writes and reads per second you need.
1 million evenly spread writes per day is equivalent to 1,000,000 writes / 24 hours / 60 minutes / 60 seconds = 11.6 writes per second.
A DynamoDB write capacity unit can handle 1 write per second, so you need 12 write capacity units.
Similarly, to handle 1 million strongly consistent reads per day, you need 12 read capacity units.
With read capacity units, you are billed in blocks of 50, with write capacity units you are billed in blocks of 10.
To calculate write capacity units = (0.0065 / 10) * 12 * 24 = $0.1872.
To calculate read capacity units = (0.0065 / 50) * 12 * 24 = $0.0374.
Thus, if your application will have lots of reads but not so much writes, and also need to be scalable and have a good performance, and also doesn't need anything like SQL Join queries, you will want to select DynamoDB instead of RDS.

Lab Steps

Go to AWS console and go to DynamoDB. Create Table.

Give the table a name and primary key.

In provisioned capacity, you can set both of the read capacity units and write capacity units to 1. Click Create.

Your table has been created, and you can see the region of it, the ARN (Amazon Resource Name) of it.

Go to Reserved capacity tab. Just like reserve capacity for EC2 instance, you can also reserve capacity for DynamoDB. It means you have to enter into a 1 ~ 3 years contract but it can save you lots of money.

Go to Tables, select the table you just now created. Go to Items tab and click Create Item. An item is basically a Row of a Table, or you can see it as a record. It is not like RDS, it can actually dynamically start adding columns and that's because it is NoSQL database. You can start adding different columns for different record sets.

You can use the filter to search in the table.

You can see the Metrics tab.

You can update the capacity in Capacity tab. You can change the read capacity units and write capacity units on the fly, and it means you will not have any downtime when you scale your database, so the scaling is really easy ("push button scaling"). In RDS, if you want to scale the database, you need to create a snapshot for it and you need to create a read replica and then you need to adjust the instance size and you finally will get to a point where you cannot scale it any higher, you cannot add any more read replicas, At that time, you need to consider about moving to DynamoDB which gives you "push button" scaling. In RDS, when you scale the database, it inevitably going to have some downtime because you are moving to different instance size classes, so that is really the key thing to remember when you go to the exam.