- [Speaker] Now let's review a used case
of using databases for E-commerce.
So, you'll see that there's a fair amount
going on here in this diagram.
We have a number of different types of databases
for different types of data and different
types of usage patterns.
So first, over here in the top left corner, you'll
see that we have our E-commerce application,
which is a load balanced application.
We're using here a, perhaps
an application load balancer.
We could also use a network load balancer,
and then of course we would have an auto scaled fleet
of EC2 instances and on those, we can run monolithic
application, or a series of microservices.
Now, just moving down and across, we can see
that we're leveraging DynamoDB for a number
of different things.
First, we might be storing different campaign events,
so your marketing team may be running different
marketing campaigns to target different demographics.
And we want to track all of the people that come in
through those campaigns, so perhaps they land on
a particular landing page or they carry with them
some information about that campaign as to where
it actually came from, you know, where did they click
on that ad, or where did they click on some kind a link
in order to get them to our site
to that particular landing page.
And so, we can record that kind of information
very quickly and very easily with DynamoDB.
The same is true for something like affiliate tracking,
so let's say that you have an affiliate program
for your particular online store and you have,
your affiliates out there are putting links
on their website, on their blog or what have you
and as someone clicks that link and follows that link
through to your site and makes a purchase, the affiliate
gets a commission and so you have to track, you know,
what users came in through what affiliate link
and then, of course, tie that purchase back
to that affiliate and then be able
to pay them that commission.
So again, DynamoDB is very well-suited for very quickly
ingesting that kind of information, that kind of data.
And then we might also use DynamoDB to track user
history as they view different products, as they search
for different products, we store that in DynamoDB
so that we can perform a number
of different things out of that.
In the least, we could show them, hey these are the products
that you looked at and make it easy for them to go back
to the product that they were recently looking at rather
than them having to dig and find it all over again.
So, there's, for the user experience, there's just
the matter of making shopping more convenient for them,
sort of greasing the skids, as you will, making it easy
for them to find that product and then actually buy it.
And then, of course, there's also, that kind of data
could also tie into a recommendation engine.
If you're searching for something, then maybe we want,
you know, some days later if you haven't purchased it,
then maybe we want to send an E-mail to say, "Hey,
"we saw that you were searching for this, it's on sale,
"the price has changed, or, if you're searching for this,
"you might also like these other things that are related,"
right?
And then, of course, as users are actually doing their
shopping and placing things in their cart,
we can record that information as well.
So, this is all very rich information that we can use
to establish trends, to help recommend different products
to users directly or to, perhaps users
that are somehow related to each other.
Now, other types of data, looking over here to RDS,
we would be running RDS, in production we would
run that in a Multi-AZ Deployment.
Again, keep in mind that a Multi-AZ Deployment
means that we are running both a primary and a secondary,
these are two completely physically distinct servers
and physically distinct data centers.
And then, of course, AWS is handling the synchronous
replication between those two, and so we have two
copies of our data that are live.
Now, it's not list shown on this diagram, but we could
also say that we are relying on those automated backups
going to S3 for the sake of disaster recovery,
giving us a greater degree of durability in that data.
Now, in a relational database, that may be more
well-suited for data like user accounts and the product
catalog in inventory, right, so that as users place
their orders, and there's now this relationship
between the order that they placed, the user, the order
that was placed, and the inventory that is now available.
And that type of thing, and then, of course, all
of the billing that's related to that as well,
that the actual financial transaction.
All of that we may very well need to be acid compliant,
right, we may want to record all of that using
a transaction with the ability to roll back.
Now, of course, keep in mind that a later update
to DynamoDB supports transactions,
but your team may feel more comfortable using
a relational database for that kind of thing.
It's all up to you, right.
Now, in this particular case, because we do have
the product catalog there, we could assume
that the, it would make sense that this application
would be performing a lot of reads, so at least some
tables would be very read heavy, such as the product
catalog if people are constantly querying
that and looking for items.
Now we could potentially share the product catalog
with DynamoDB so that we could read it from there,
or we could create read replicas so that all of our
application reads are performed by the read replicas.
So as users are browsing the site, as they are searching
for products, those reads are being pulled from
the read replicas and that would
reduce the load on the primary.
And then, of course, we could allow the primary
to handle only rights, right, so splitting
reads off to read replicas, we could increase
the performance for the entire system.
Now, as far as a cache, we could have certain things,
for example, we may have different types of pages
or entire pages, HTML pages that are built
out of both, perhaps, a slower query, a very
complex query or, and rendered HTML.
We may also have parts of pages, right, just related
products that are only sub-components of different
pages, right, so the related products may also be either
a sequel query and the result set of that, or
the result set and the rendered HTML.
So either way, if those kinds of things are running
a little bit slower, then we can store that in memory.
And our application would, first, look to the cache
and say, "Hey, do you have this thing
"that I'm looking for?"
If it does, then we can return that very very quickly,
right, and maybe even in microsecond latency, depending
on the engine that we're using and the nature
of that particular data.
If it doesn't, then we could, of course, go to
the relational database and pull that or we would pull
it from the read replica and then, of course, we would
do our rights to the master, to the primary.
And then, of course, we have Redshift, and Redshift,
again, is Amazon's petabyte scale data warehouse,
and so with Redshift, we want to be able to run
analytical queries and analyze all of this data
that we have in these various places, right,
so we want to be able to pull in all of this information
from DynamoDB, campaigns, affiliate tracking, product
view history, search history, shopping carts.
We pull all of that data in, we could use potentially
Data Pipeline or Lambda or something else to help
us extract, transform, and load
between DynamoDB and Redshfit.
And then we could do the same thing, pull data in
from our relational database and now we have all
of that data in one place, in one data warehouse,
and now our data analytics team can use their
existing, whatever business intelligence tools they want
to use from their local machines on premises or at home,
or wherever they are, they can connect to Redshift
using those ODBC or JDBC drivers and run whatever
complex ad-hoc queries that they can think of in order
to derive meaning out of all of this data.
Right, so, of course we didn't show it here
in this particular diagram, we didn't really have room.
But, going back to some of the other databases
that we've talked about, such as Neptune, for example.
Neptune would have a very clear place here in terms
of recording relationships between users and the products
that they've purchased or the products that they've
searched for and that would also
help us create a recommendation engine.
So, as you can see, we have a number of different
great options within AWS to store our data.
Many of them are fully managed services, allowing
us to offload the operational burden.
If you notice here, in this diagram,
there's very little operational burden,
in fact, the only operational burden that we would have
would be, essentially, the operating systems
for our EC2 instances over here.
And so you can see that we can run a fairly
complex type of scenario, in this example, E-commerce
with a smaller team, right, by offloading all of those
burdens to AWS, allowing AWS to manage many
of these services for us.