- Now let's review an introduction to Amazon DynamoDB.
Now, of course, with DynamoDB,
we gain access to a fully managed NoSQL Data store.
Again, like we've talked about earlier,
DynamoDB is in the same family
as systems like Cassandra and MongoDB
and others in that NoSQL, you know, type of database.
Now of course, DynamoDB is exclusively backed by SSDs.
So we know that when we write...
Any data written to this table
is written to multiple nodes
exclusively backed by SSD storage
to help ensure that our reads and writes
are as fast as they can be.
And of course, DynamoDB is capable
of single-digit millisecond response
if we are using an index based query.
If we're doing a full table scan,
then we can't expect a single-digit millisecond response.
But we can if we are using an index based query.
And of course,
DynamoDB, like most managed services,
is inherently highly available and fault tolerant.
Those kinds of things are already built in.
Unlike RDS where we have to opt-in
to Multi-AZ deployments
in order to gain fault tolerance.
With DynamoDB, it's already built in.
There's nothing for us to opt-in to.
It's just a part of the service.
And so,
one of the ways that DynamoDB achieves that
is to replicate the data
not only across numerous drives
but across numerous Availability Zones.
Or essentially, numerous data centers.
And so that,
the DynamoDB service is resilient
not only to the loss of a device
but also to the loss of a data center.
Now, with DynamoDB,
we don't need to provision storage.
Storage just grows automatically.
But we do need to provision the throughput.
And throughput is essentially
measured in terms of reads per second
and writes per second.
Right, so.
What is our workload?
Some tables may be read heavy,
some may be write heavy,
some may be balanced.
But every table will do
a certain number of reads per second and writes per second.
And that really is probably
the greatest thing that contributes to our cost.
Yes, we pay for storage,
but we also pay for the provisioned throughput.
Now, as far as data models in Amazon DynamoDB go,
we have tables
that are comprised of items
that are comprised of attributes.
And that's basically it.
That's what we have.
We don't have any foreign keys or anything like that.
There are no joins and no relationships.
Now of course, you could within your own application,
you could pull data from two different tables
and join that within your application.
But again, DynamoDB will not do that for you.
It inherently has no
knowledge of any relationships or foreign keys.
It's also a schema-less design.
Right, DynamoDB does not support any kind of a schema
except for maybe the primary key.
Right, the primary key is
the only thing that you have to specify
what attribute for that item will be the primary key
and the data type for that attribute.
But beyond that,
if you wanted to,
you could have every item in that table
have completely different set of attributes, right.
Your app--
If your application needs a schema,
then your application would have to enforce that schema.
But DynamoDB will not enforce any kind of a schema
outside of the primary key or an index.
And so,
speaking of the primary key,
every item does require a unique primary key.
And that is indexed.
And that's one of the ways that we can achieve
that single-digit millisecond response
is by querying based on the primary key.
And then of course, if we need to be able to query
on some other attribute other than the primary key,
we can create secondary indexes.
We have local secondary indexes
and global secondary indexes.
And those give us a way, again, to query,
to make fast single-digit millisecond queries
based on an attribute other than the primary key.
Another nice thing about DynamoDB
is that there is no limit to the size of a table.
You can just throw data at this table
and it can grow into the petabytes and beyond
and there's nothing you need to do.
Amazon will not impose a limit on that
and there's nothing we need to do
to go and provision more storage.
It just happens automatically.
There is
a 400K limit per item.
So that is something to keep in mind.
You will not be storing blobs within DynamoDB.
If you do have something larger than that,
maybe a large document of some kind,
that's in the megs or gigs.
Then a common practice would be to store that large blob
in something like S3
and then store metadata about that in DynamoDB.
So that you can form your searches in DynamoDB,
reference the key and then download that blob from S3.
DynamoDB,
a recent addition to DynamoDB in late 2018
was the ability to support transactions.
Right, so DynamoDB can be,
you know, asset compliant
if you need transactions.
So with DynamoDB transactions,
this will allow you to write
multiple updates or inserts across multiple tables
and then give you ability to roll back
if any modification to any one table fails.
Right?
So that's a very powerful feature that was
released fairly recently, again, here in late 2018.
Now, taking a closer look at the data model within DynamoDB.
Again, like we've talked about,
we have a table.
Now, in terms of data models in Amazon DynamoDB,
taking a closer look here again,
we've talked about how we have tables, right?
And here in this example, we have a user's table
and of course, this would be an item.
And then each one of these things,
we would have an attribute.
A Zip attribute,
a date of birth attribute
and a name attribute.
Now, because DynamoDB is schema-less,
it's possible that each item here
could have a completely different set of attributes.
That is probably not necessarily
the best for our application
if our application needs something predictable.
But as far as DynamoDB is concerned,
it doesn't care, right?
If you want to do that, you can.
The only thing in this example that we have to do
would be to ensure that all of our items
have the name attribute.
In this example, as a streamed value.
Right, because that,
in this example we've set as the primary key.
Now, we have different options
when it comes to primary keys in DynamoDB.
Now here in this example,
where the primary key is a partition key.
You'll notice that it's just one value.
It's only the name attribute.
But in another table,
we could also create a primary key
as a composite, right?
Remember that a composite key
is the combination of two different attributes
or two different fields.
And it's the unique combination
of those two things
that make that primary key unique.
And so, with DynamoDB, we have the ability to
create a primary key that is the combination
of a partition key and a sort key.
So you'll see here,
in the top table,
jane.doe would have to be unique.
But in this bottom table in Relationships,
jane.doe is not unique but the combination of jane.doe
and amy and the combination of jane.doe and bob.smith
are each unique, right?
So that's a composite key.
And so the ability to do this
or what this gives us is the ability to query
this table and say well show me all of
the records
where name equals jane.doe.
So that would give me all of jane.doe's friends.
And then of course as the name suggests,
the sort key here,
as the sort key suggests,
we can then use that friend attribute
to sort that list in alphabetical order.
And of course, we will take a closer look
at some of these things
as the course progresses.
As we get into the demo and other things, right?
So again, Amazon DynamoDB
is Amazon's fully managed NoSQL data store.
And we'll take a closer look at it as we move along.