Overview of Amazon Web Services Nonrelational Database – Amazon DynamoDB

Amazon DynamoDB is a managed NoSQL database. Because it is managed, users will not have to be conscious of OS or middleware. Amazon will do the construction of infrastructure, consideration of availability and robustness, application of patch etc. As DynamoDB is a NoSQL database and not an RDBMS. It provides fast, predictable performance and seamless scalability.

There is no degradation of the availability before weaving, and the service design is done assuming that it is basically available (Basically Available) basically. Although certain consideration is required for table design (key design), it is possible to have a system that has horizontal scaling (capacity securing by sharding) function and can respond to the assumed load.

On the other hand, since consistency is eventual, old data can be acquired with a certain probability immediately after updating data. But that state does not last long (usually said to be within one second), and as a result, you will always be able to acquire new data. However, DynamoDB has a mode called ‘Reading strong consistency’, and you can request that you always return a new value in exchange for cost.


Why NoSQL?

The RDBMS is configured to scale out the server because it performs strict transaction processing (ACID). In case of scaling out, it is necessary to take transaction consistency between servers and synchronize at the memory level. However, there is also a limit to this scale-out method, so the more nodes you add, the more consistent you have to match between all servers, and the consistency matching process becomes a bottleneck.

Features of Amazon DynamoDB

Writing & Reading – DynamoDB writes to three Availability Zones (AZs), but if it is confirmed that writing to two AZs is completed, it is regarded as writing completion. It is a reading model of results consistency. If reading is done immediately after writing, old data may be returned.

High availability & High scalability – Since data is stored in three AZs, both availability and robustness will be high. There is no capacity limitation in storage, accounting will occur for the used capacity. Because it is not charging with the capacity secured like EBS, cost performance is also high.

Simple Request – One cannot implement complicated queries like RDBMS. DynamoDB is not a data manipulation in the SQL statement but a simple API operation.

One Can Specify Throughput – It specifies the throughput with the capacity unit (processing capacity per second).

RDS vs DynamoDB

1. Consistency – RDS has strong consistency, while DynamoDB’s consistency is basically weak because of result matching (strong consistency specification is also possible).

2. Atomicity – Atomicity is there in RDS, while the same is Not (possible if updating within the same item) with DynamoDB.

3. Availability – DynamoDB is always available, while in RDS it is available with maintenance window.

4. Scalability – In RDS ceiling is low due to scale-up only, while in DynamoDB scaling is out by sharding.

5. Search Condition – In RDS SQL where clause freely. Pre-specified key or index only in DynamoDB.

Action from AWS IoT to DynamoDB

When saving messages to DynamoDB with AWS IoT, you can select the following two types of actions.

Action – DynamoDB Action

Contents – Save the message in one column for the set partition key and sort key

Action – DynamoDBv2 Action

Contents – Store JSON of messages in separate columns for each key (Messages are limited to JSON format)

In Amazon DynamoDB action and DynamoDBv2 action, allowable message format and storage format to DynamoDB are different, so one need to select actions according to their environment and configuration.


S3, Amazon DynamoDB is also commonly used as a data store to store message logs with AWS IoT. If you are using it, you can retrieve collective data by query and scan operation, so you can refer to data more easily than S3. This method is a useful rule action, especially when dealing with messages in the form of character strings, but in cases where DynamoDB’s schema is determined by the existing system linkage such as Lambda, the case where the DynamoDBv 2 action is easier to handle.