So let's talk about the advanced features
that can come up at the exam for DynamoDB,
and the first one is DynamoDB Accelerator or DAX.
So this is a fully-managed, highly available,
and seamless in-memory cache for DynamoDB.
The idea is that if you have a lot
of reads on your DynamoDB level,
then you can create a DAX cluster to solve
read congestion by caching the data, and with DynamoDB DAX,
you get microseconds latency for cache data,
so this is something you have to look out
for in terms of keywords at the exam.
It doesn't require for you to change any
of your application logic,
because the DAX cluster is compatible
with the existing dynamic DynamoDB APIs.
So you have your DynamoDB tables and your application,
and you would just create a DAX cluster made
of a few cache nodes, connect to this DAX cluster,
and then behind the scenes, the DAX cluster is connected
to your Amazon DynamoDB table.
The cache has a default TTL of five minutes,
but you can change this.
So you may ask me why should I use DAX and not ElastiCache?
Well, DAX is in front of DynamoDB,
and it's going to be very helpful
for individual objects cache,
or queries and scan queries cache.
But if you want to store, say, aggregation results,
then Amazon ElastiCache is a great way to do it,
so if you want to store a very big computation
that you've done on top of Amazon DynamoDB.
So they're not drop-in replacements for one another.
They're actually complementary, but most of the time
for caching solution on top of Amazon DynamoDB,
it's just going to be using DynamoDB Accelerator DAX.
You can also do stream processing on top of DynamoDB.
The idea is that you want to have a stream
of all the modifications that happen on your table,
whether it be create, update and delete, and the use case
for that will be for example, to react to changes
on your DynamoDB table in real time, for example,
to send a welcome email whenever you have a new user
in your user's table, or if so, you may wanna do
real-time usage analytics, or maybe you want to insert data
into a derivative table, or you want to implement
cross-region replication, or you want to invoke Lambda
on any changes made on your DynamoDB table.
So two kind of stream processing on DynamoDB,
you have DynamoDB streams with 24 hours retention,
a limited number of consumers,
and is going to be greatly used with Lambda Triggers,
or if you wanted to read it yourself, there is
something called the DynamoDB Stream Kinesis adapter,
or you can also choose to send all your changes directly
into a Kinesis data streams.
And here you can have up to one year of retention,
you can have a much higher number of consumers,
and you have a much higher number of ways
to process the data, whether we blend the functions,
can you see data analytics, can you see Data Firehose,
Glue streaming ETLs, and so on?
So let's have a look at an architectural diagram
to understand DynamoDB Streams better.
So your application does create updates
and delete operations on top of your DynamoDB table,
which is going to be either a DynamoDB Streams,
or a Kinesis data streams.
If you choose to use Kinesis data streams,
then you can use Kinesis Data Firehose,
and from this, you can send your data
into Amazon Redshift for analytics purposes,
or Amazon S3 if you want to archive some of the data,
or Amazon OpenSearch to do some indexing and some searches
on top of it, or if you are using DynamoDB Streams,
you can have a processing layer, and you can use
either the DynamoDB KCL Adapter to run your applications
on top of EC two instances or Lambda functions,
and from there, do some notifications on top of SNS,
or do some filtering and transformations
into another DynamoDB table,
or use the processing layer to do whatever you want,
such as again, send the data to Amazon OpenSearch.
So I didn't represent all the possibilities
of architectures.
Of course, you can have EC two instances reading
from Kinesis data streams.
You can have Kinesis data analytics and so on
on type of Kinesis data streams, many, many transformations,
but again, you know enough now to figure out
what is going to be the right architecture
at the right time.
DynamoDB also has a concept of global table.
So a global table is a table, of course,
that is going to be replicated across multiple regions.
So you can have a table in US-east-one,
and a table in AP-southeast-two.
And there is a two-way replication between the tables.
That means that you can write to a table either
in US-east-one and AP-southeast-two.
So here, the idea with global tables is to make DynamoDB
accessible with low latency in multiple regions,
and it is an active-active replication.
That means that your applications can read and write
to the table in any specific region.
And to enable global tables,
you must first enable DynamoDB Streams,
because this is the underlying infrastructure
to replicate a table across regions.
DynamoDB also has a feature named Time to Live, or TTL.
The idea is that you want to automatically delete items
after an expiry time stamp.
So you have your table session data, and then
you will have one last attribute called expiration time,
which is your TTL, and it has a timestamp in it.
And the idea is that you're going to define a TTL,
and as soon as the current time
in the epoch timestamp is going to be
over your expiration time column,
then automatically it's going to expire items,
and then eventually delete them through a deletion process.
So the idea is that the items
in your data table are going to be deleted after a while.
So the use cases for this would be to only store data
by keeping only the most current items,
or to adhere to regulatory obligations by for example,
deleting data after two years, or another use case
that is very common at the exam is the web session handling.
So a user would log into your website,
and then would have a session, and you would keep
the session in a central place such as DynamoDB
for two hours, and you would set the station data there,
and any kind of applications can access it.
And at some point after two hours if it hasn't been renewed,
then it will expire, and move away from this table.
You can also use DynamoDB for disaster recovery.
So what are your backups options?
Well, you can have continuous backups
with point-in-time recovery, PITR,
so it's optionally enabled,
but you can have it for the last 35 days.
And then if you enable it, you can do
a point-in-time recovery to any time
within the backup window,
and if you do happen to do a recovery,
then it will create a new table.
If you wanted to have longer term backups, then
you can use on-demand backups, and they will be retained
until you delete them explicitly,
and doing these kind of backups do not affect
the performance or the latency of your DynamoDB table.
And if you wanted to have a better management
of your backups, you could use the AWS backup service,
and this will enable you to have lifecycle policies
for your backups and so on, and also copy your backups
across regions for disaster recovery purposes.
And again, if you were to do a recovery
of one of these backups, it will create a new table.
Now let's talk about the integrations
between DynamoDB and Amazon S3.
So you can export a table into FS three, just like this,
and to do so, you must enable point-in-time recovery,
and you would export a DynamoDB table into S3,
for example, if you wanted to do some queries,
for example, using the Amazon Athena engine.
So you can export at any point in time
during the last 35 days,
because you've enabled continuous backups.
And when you do an export,
this does not affect the read capacity
of your table or your performance.
So with this, you can perform, for example,
data analysis on top of DynamoDB
through exporting through Amazon S3 first.
You can also use this to retain snapshots for auditing,
or to do any kind of big transformation,
maybe any ETL of the data before importing it back
into a new DynamoDB table, for example.
The format of the export can be in DynamoDB JSON,
or the ION format.
And similarly, you can import to Amazon S3.
So you can export from S3 into the CSV, JSON,
or ION format back into a new DynamoDB table,
and this does not consume any write capacity,
and it will create a new table.
If there are any import errors,
they will be logged in CloudWatch logs.
So that's it for DynamoDB.
I hope you liked it,
and I will see you in the next lecture.