(upbeat music)
- [Dipali] Let's imagine you have just built a promising app
that world has never seen before.
New users are coming in but can your databases scale
to handle all the incoming requests?
Amazon DynamoDB is built
to handle internet scale application
as traditional databases cannot handle millions
of requests per second
during Black Fridays or Cyber Mondays kind of scenarios.
You can store hundreds of terabytes of data
in DynamoDB and can expect great performance.
So let's discuss key features of DynamoDB.
DynamoDB is a fully managed, multi-region,
multi-master and highly available database
and all your data is replicated
across three availability zones
and you don't have to worry about patching and upgrading.
It's a NoSQL database.
That means it's not relational database.
Amazon DynamoDB is primarily designed
to manage semi-structured data.
DynamoDB tables do not have a fixed schema.
They are schemaless
so each data item can have a different number
of attributes, which is very different
to a relational database,
which does require the attributes in a table
to be consistent.
It will scale through massive workload
and will be distributed and that's what make it scale.
You can issue on it millions
of requests per second.
The really good thing about DynamoDB
is that you get fast and consistent performance.
So that means every retrieval will be low latency,
usually in the single-digit millisecond.
It will be integrated with IAM for security
and authorization, which is the best practice
in AWS to manage security anyway.
On top of it, we can enable event-driven programming
for your DynamoDB streams
where we can reply to events
that happen to our table
and see in real time that what we want to do about it.
It's a low cost and has auto scaling capabilities,
which makes it the perfect serverless database.
Now let's log into AWS console
and see how DynamoDB dashboard looks like.
So basically, DynamoDB is a database
but you don't need to create databases
as they are already there for you.
It's made up of tables.
So let's create our new table here.
Let's name it players.
Each table will have our primary key
and you can also define a composite key
by including a sort key.
So let's define playerid as the primary key
and country as a sort key.
Each table can have infinite number of rows
and each row may have different number of attributes,
which we don't need to define at the table creation,
which is in contrast to any RDBMS.
The maximum size of a row can be up to 400 kilobytes.
However, you can have any number of rows
of this magnitude.
So this is really important decision
while designing for your storage
that what kind of data it holds
as DynamoDB has a limitation of 400 KB
while S3 can store objects up to five terabytes in size.
So here either we can simply create table
with default settings
or can provide customized configurations.
And key thing to define here is the throughput you need
in terms of read and write capacity units.
Read capacity unit or RCU is the number
of elements you will read per second,
while write capacity unit or WCU
is number of elements you will write per second.
And you have a capacity calculator here
where you can calculate the required read
and write capacity.
So if your item size is one KB
and you want to read and write one item per second,
you will need one, one read and write capacity units.
However, if your item size is let's say 300 KB
and you want to read and write one, one item per second,
then you will need 38 read capacity units
and 300 write capacity units.
And worth noticing here
that it will also increase the cost.
You can also turn on scaling
and impose encryption on your DynamoDB data.
So let's go ahead and create this table
with default settings.
And now let's try to add some data in this table.
So as we can see here,
this table is being created.
Let's try to refresh this table.
So we can see it is available
and this is where we can create records into this table.
So let's say playerid is p01
and it represent country USA.
Create this row.
Let's try to add another row here
with playerid p02,
representing country as India.
And here we also want to add another attribute
as city that this player is from Delhi City in India.
So here we can see that we have two rows
and both the rows has different number of attributes.
So you can have any number of rows
in your DynamoDB table
with varied number of attributes.
Now you might be thinking that how DynamoDB relate
in data engineering?
Well, there are some very common use cases
that includes mobile apps,
gaming, digital ad service,
live voting, audience interaction for live events,
sensor network, log ingestion,
access control for web-based content,
metadata storage for Amazon S3 objects,
e-com, web session management, et cetera.
In terms of anti-patterns
where DynamoDB is not a good choice for,
for example, RDS-like fixed schema,
complex joins or complex transactions
or large size objects.
This is a very common pattern
and in general, if you have large data
that has low I/O rate,
so few write or very few read,
then S3 is going to be a much better storage option for you.
So the use cases are quite diverse
but basically that means
that any time if you have some data
that need to be very hot,
small in size, and needs to be ingested at scale
within a database,
then DynamoDB is going to be a great fit for that.
(upbeat music)