Now let's take a look at an overview
of AWS database options.
So starting with Amazon Relational Database Service or RDS,
we get a fully managed relational database system
and by fully managed, we mean that
Amazon handles pretty much everything,
everything except writing sequel statements for you.
And so we also get our choice of popular engines
such as, you know, My Sequel, Sequel Server,
Post Cres, Oracle and so on.
Another great thing about the Relational Database Service
is that maintenance is fully automated.
Things like operating system patches,
the database engine patching, backups,
are all fully automated.
It's also highly customizable, we get access to options
and parameters so that we can tune the database.
Just because it's fully managed,
doesn't mean that we're locked out of those things.
We do get access to parameters
so that we can, like I said,
help tune that relational database
to perform the way we want it to perform
for a particular workload.
Relational Database Service
also supports high-availability with automatic failover.
We will go into more details about this service later-on
and explain exactly how that happens.
We also have Amazon ElastiCache,
Amazon ElastiCache, very much like RDS,
is also fully-managed, but this gives us access
to an in-memory cache and we get out our choice
of Redis or Memchaced.
So with Memcahced we get a simple key value store.
With Redis we actually get much more
of an in-memory database.
We have the ability to use more advanced data structures
like hashes and sorted sets and in-memory operations.
Now with Amazon DynamoDB,
we gain access to a fully managed NoSQL datastore.
This is, of course, in the same family
of data stores such as Casandra and MongoDB.
But with DynamoDB there's no
infrastructure whatsoever for us to manage.
Amazon handles all of the underlying infrastructure
as well as the database engine.
One of the benefits of DynamoDB, one of the many benefits,
is that it's highly scalable.
Your data set can grow into the petabytes and beyond,
without any additional effort on your part.
You just simply throw data at your table
and it automatically grows
and it grows, not only for the storage plane,
but also for the infrastructure
that's managing the actual throughput.
DynamoDB, like most managed services within AWS,
is also fault-tolerant, it's inherently fault-tolerant.
All of those good things are built in to that service.
So the benefit of these managed services,
like RDS and ElastiCache and DynamoDB,
is that we can offload operational burdens.
So that we as an organization,
we don't have to worry about what it means
to make that service fault-tolerant.
DynamoDB is also internally, automatically replicated.
Our data is written to numerous devices
across numerous data centers.
And again, we will go into more detail
on the service later and talk about how that happens.
DynamoDB is also event-driven,
meaning that as data is being written
or updated or deleted from a table,
then we can tie into those events
and analyze those things in near real-time
as those changes occur.
With Amazon Redshift we gain access
to Amazon's petabyte-scale data warehouse
and again, this is also fully-managed.
AWS takes care of everything from the infrastructure
to the operating system to the database engine.
And the largest cluster within Redshift
gives us access to `1.6 petabytes of storage and
we can use this to run queries - sequel queries -
across a vast dataset.
Of course Redshift, being a fork of Postgres8,
means that it's fully SQL compliant.
And again, just like other systems like DynamoDB,
Redshift is also inherently fault-tolerant,
highly durable and also replicated.
It also supports server-side encryption
and disc-based encryption.
With Amazon Neptune, we gain access
to a fully-managed graph database.
With a graph-database, we can use this to
run queries and analytics based on relationships.
This database is optimized
for relationships between entities.
So you think of things like a recommendation engine
would be really well suited to run
on a graph database such as Neptune.
Again, also inherently internally replicated for durability.
Neptune also performs continuous backups,
whereas something like the Relational Database Service
performs backups every so often,
with other services like Neptune
the backups are continuous.
We also get the very easy ability
to create read replicas with Neptune and RDS as well
so that we can offload our reads to one node
and send our writes to another node.
That can help increase performance of the system as a whole.
Now, a couple of other databases
that were released in November of 2018, during AWS reinvent,
were Amazon Timestream and the Quantum Leisure Database.
So these are very new database services
that were very recently released.
So with Amazon Timestream,
we gain access to a fully-managed, time series database.
So if you've been in the industry for, you know,
more than a year or so, you've probably seen
a scenario where you are recording time series data.
Time series data is very common
but it's also a very specific type of data
that needs to be adjusted and stored and accessed
in a particular way and if you've used
Relational Databases long enough,
you'll know that they're great for many things.
But when you're recording many events
based on the second or even sub-second,
you can very quickly,
over a relatively short period of time,
end up with potentially billions of events.
Then if you're wanting to access those quickly
or perform time-series specific types of analytics,
then relation databases tend to fall down
and tend to not perform very well
for that specific type of workload.
So the Amazon Timestream Database is specifically geared
towards that time series type of data
and it's capable of recording trillions of events per day.
So if you have scenarios where you are wanting to record
events, you know, in less than a second interval,
then Amazon Timestream may very well
be the right solution for that problem.
It also has built-in analytic functions
so you don't necessarily have to write your own code
to perform analytics on that time-series data.
You could leverage the built-in analytic functions
of Amazon Timestream itself.
And now, at the time of this video recording,
Amazon Timestream is currently in preview.
So by the time you're watching this,
it may or not be out of preview.
But, you know, keep an eye out for Amazon Timestream
if you are looking to do something with time-series data.
And lastly, that brings us to the
Amazon Quantum Ledger Database or QLDB.
With QLDB we gain access to a fully-managed ledger database.
Now when I say ledger-database, what I mean is,
when you think about a ledger,
a ledger is most typically used in something
like financial transactions if you want
to record the history of debits and credits
to and from an account
and you want that history to be accurate and immutable.
Right, so the Quantum Ledger Database
uses an append-only immutable journal.
So every transaction is simply added
to the end of that ledger
and there's no ability to go back
and modify a previous transaction.
So the nice thing about a ledger
is that it gives you a very accurate
historical journal of transactions.
They don't necessarily have to be financial,
even though that's the most common,
there are all kinds of use cases for
recording the history of certain things.
And so, with the ledger, this takes a page
from the block-chain networks such as
Bitcoin or Ethereum or others.
Whereas you have this with
those type of distributed ledgers
You're able to cryptographically prove that
the history of that ledger was immutable,
that it hasn't changed.
And so here, we get the same ability
except that the Quantum Ledger Database is centralized
and the benefit of it centralized rather than distributed
like we see with Bitcoin or Ethereum,
or other networks like that,
is that it's going to operate much faster,
there's no need to transfer the entire ledger
to all of these nodes all over the internet.
It's all centralized into one place.
And so again, we can validate the entire history
of that ledger with the cryptographic hash
which means if anyone were to somehow
modify a previous transaction,
then the ultimate hash would be invalidated,
it wouldn't match.
So again, we have the ability to verify
an entire history of transactions
with the Quantum Ledger Database.
And so those are our database options within AWS.
You can see we have a number of really amazing options
to choose from according to the types of data
and the way that we're using that data.
And so we will go into many more details
on each one of these, or most of these services
as the course progresses.