- Welcome.
In this demonstration,
we are going to deploy a DynamoDB table
using the AWS console.
Now I'm in the console home
and I can then just search for DynamoDB
in the list and go straight to the dashboard there.
Now, as we pull this up for the first time,
we always get a little announcement here or there,
we can go ahead and close that out
to give us a little bit more screen real estate.
There are a number of options down the left hand side.
We have tables, backups, exports, capacity,
DynamoDB accelerator, and so forth, but we're gonna go here
to the bright orange button.
Create table.
Table creation in DynamoDB can be as simple
or as complicated as you make it.
We're gonna start with a table name
and let's call this a shopping cart
for the back end of an eCommerce application.
So this will be the persistent storage when customers
are modifying their cart to get ready for checkout.
Every table in DynamoDB needs a partition key.
The partition key is one of the attributes
of every item that makes up a unique element
that allows AWS to partition the underlying data
to achieve the best performance.
You can think of the partition key
almost as a primary key, but if it's not unique,
then you have to add a second attribute into the mix.
And the combination of them make a primary key.
From a strategy perspective,
this partition key needs to exhibit high cardinality.
Cardinality can be described as when you have a large range
of potential values for the key and a relative
even distribution across that range.
And so if we were to choose date, that has a high range
of values, but the actual values are going to be limited
to the most recent data.
And so instead, why don't we go ahead and select username,
especially if we use this as emails for our e-commerce site
this does tend to exhibit pretty high cardinality
and we'll leave it as a string.
And in that case,
because the username is unique,
we do not need a sort key at all.
Now we have the option here
of accepting default settings or customizing.
So let's click on customize, which changes the form.
And we have the ability to deploy our table class
as either standard or infrequent access.
If you've worked with other services like S3 or EFS,
both of those services also exhibit storage classes.
The standard IA storage class is always going
to be cheaper for storing data,
but if it's going to be accessed on a regular basis,
we will want it in dynamo DB standard.
So that's what we're going to configure for this table.
So we go down a little bit further.
We have capacity settings
and this is where we have a number of choices.
Do we want to provision our table
for a specific number of reads and writes?
We can do that.
And if we configure provisioned capacity,
we can then choose to scale as well.
So with auto scaling off,
we just get provisioned capacity and everything is static.
With auto scaling on, we configure a minimum, a maximum,
and then a target utilization.
However, if we don't want to configure this
for reads and writes, we can simply click on demand and all
of those options go away and AWS will scale according
to the load, with no minimums or maximums.
This next section is where we have the ability
to create local, secondary indexes
or global secondary indexes that can allow us
to achieve higher performance
or organize the table in different ways.
Encryption at rest, we have choices of keys
but not a choice to turn it off.
So we can choose AWS owning the entire chain of trust.
We can do an AWS manage key, which is the default CMK
in KMS for our region, or we can manage our own.
So we can leave this at the default.
The table itself does not cost us anything.
We'll add a cost center anyway.
It's only the data in the table
that causes pricing to be applied.
And so at this point, we can go in, click on create table.
And if we refresh, our table is still creating
and now it's active.
So it really doesn't take very long.
And then we can start using our table almost immediately.
And that completes this demonstration.