Dynamo-DB

Notes:

Dynamo DB is 1 of the 2 NO-SQL databases AWS has to offer.

It is a Document type No-SQL data store

If you’re familiar with databases you can closely relate Dynamo DB to Mongo DB except this was made
by AWS.

Dynamo DB is a fully managed database that offers single-digit millisecond latency at virtually any scale.

It’s a Document type No-SQL data store

It supports both document and key value data models. Dynamo DB’s data is stored on SSD Storage and
retains high availability by being spread across 3 geographically distinct data centers. This makes it have
different consistency models. Consistency models refer to the amount of time data takes to be
refreshed and show across all copies of data.

Eventually consistent reads: This is the default consistency read. Eventual consistency promises that
consistency across all copies of data in each datacenter Dynamo DB uses is to be reached within 1
second.

Strongly consistent reads: Will return a result that shows all writes that have received a successful
response before the read.

The use case of consistency reads depend on your application requirements if you need data to be
available on your table immediately then you would go with a strongly consistent read but if you can
wait 1 second while consistency is assured across all copies of data in all 3 data centers then you would
go with eventual consistency.

Dynamo DB runs on a cluster of nodes that can scale automatically depending on the storage needs and
also the read/writes needs of your table. It does this by adding or removing nodes to match the needs of
your application and since it’s managed by AWS it does this automatically based on the given
requirements. As opposed to a Relational-SQL Databases that do not scale out or in.

Dynamo DB is Server-less which means we can only access it via API Requests.

These include but are not limited to:

 PUT
 GET
 QUERY
 SCAN
It’s mostly used to make your applications stateless so they can be scaled with greater ease when using
a load balancer.

Major use cases of Dynamo DB include:

 Web
 Mobile (Personalization, Storing User profile)
 Gaming (leaderboards, session state information)
 IoT (meta data)
 Ad-tech

It is not good for joining multiple tables together or normalizing data like a relational database would.
However Dynamo DB does not have a scale or storage limit like RDS does and you don’t necessarily need
to scale the storage manually like RDS (with the exception of Aurora)

Dynamo DB has an advantage over Relational-SQL databases in the sense that the data in the table can
be edited without having to follow a schema, what this means is that each and every item that a table
contains can have different and any number of attributes while every attribute itself is a key and value.
You can view the table as a collection of items and an item as a set of keys and values.

When creating a table with Dynamo DB you are given a choice to provision the read and write
throughput capacity for that table and Dynamo Db will maintain performance at that level, alternatively
you can choose to auto scale and AWS will manage the scaling depending on use. When provisioning
throughput capacity on Dynamo DB please keep in mind the pricing for each unit:

 Read throughput is $0.0065 per hour for every 50 units

 Write throughput is $0.0065 per hour for every 10 units
 Storage $0.25 per Gb per Month

If you know the amount of Read/write capacity units you want you can also them with Dynamo DB just
like you would a reserved instance. This however would require you to agree to a 1 year or 3 year term
with AWS much like the reserved instance requirements.

You can use Dynamo DB and relational Databases together by using it to process high transaction rate
data that uses a flat structure like session information and therefore take most of the load off of your
relational database which is not as easy to scale.

The only requirement when creating a table is that the Partition key which is the primary key, must be
unique if it’s not, then you need to add a sort key which would make the combination of both the
partition key and sort key unique in order to create the table.

Make note that SSE (server side encryption) is possible with Dynamo DB

CloudWatch metrics on Dynamo DB are available and highlight the Provisioned and Consumed data of
your table as well as the PUT, GET, SCAN, QUERY, BATCHGET, BATCHWRITE and DELETE requests of your
table. This will give you a better idea on how much to update your capacity by using the push button
scaling with dynamo Db depending on your usage. It is important to remember that when scaling
Dynamo Db you will not incur in downtime as opposed to RDS which will have some downtime when
scaling up to a larger size instance. It’s important to remember that auto scaling with Dynamo DB needs
an IAM role in order to scale.

BONUS

NEPTUNE:

Neptune is a No-SQL Graph Database managed by AWS however it is not serve less like Dynamo DB but
functions more like RDS in these sense that you need set read replicas and launch instances. Neptune
uses open source api’s unlike Dynamo DB which uses proprietary api’s. The open source api’s are:

 TinkerPop Gremlin
 RDF SPARQL

The primary instance type for Neptune is R4 ranging from R4 large 15.2GB AM all the way up to R4
8xlarge 244 GB RAM

Features of Neptune include

 SSE (serve side encryption)

 Up to 15 Read Replicas
 Up to 64 TB of data storage
 It is highly available

The popular use cases are:

 Social network applications

 Fraud detection
 Recommendation engine
 Social network