(upbeat music)
- Welcome back to the Azure Cosmos DB Essential series.
My name is Mustafa.
I'm the portfolio PMM for Azure Cosmos DB.
And this season we're joined by Mark Brown,
a PM on the Azure Cosmos DB product team.
This season we wanna take use cases a step further
and dive into some of the architectures
customers are using to build lightweight applications.
Today, we're gonna talk about one of the major use cases
for NoSQL, building out a product catalog.
- So to share a little bit about why customers
use Azure Cosmos DB for this use case,
let's talk about some of the needs
that e-commerce customers have.
One is the need to have a product catalog.
A typical product catalog
is filled with items that all have
vastly different product attributes and variants.
Each of these has different names,
and different values, and different data types.
Maybe I want to sell, oh, I don't know,
say balloons or coffee cups,
and maybe vegetables, mm vegetables.
Each of these things is so different from the other
it would be impossible to design a database
with a schema that would work for all of them
and handle that variety.
You might also make different products available
in different regions.
And then, once we get that in front of the right people,
we need to make sure we have high availability
so that we can serve everyone visiting the web app quickly
and without downtime.
The other use case customers have that I want to touch on
is the need to store state for users on their site.
Taking into account the current expectations
around user experience,
people visiting the site would expect that
I can open this site on my computer,
add some products to my shopping cart,
then maybe close my browser, log in on my phone later,
and then have my shopping cart content right there.
This is actually fairly easy to accomplish
with Azure Cosmos DB
because Cosmos DB is designed for extreme low latency,
which makes it really great as a cache.
To make this even easier,
.net developers can use the Session State and Cache provider
available via nuget that seamlessly integrates
into ASP web applications, and uses Cosmos DB
as a fast cache and session state store for users.
Taken together for developers looking to build
retail or eCommerce applications,
Cosmos DB provides flexible schema
to allow us to represent diverse entities
in a single container.
It's also super fast,
which makes it great for user session state
or as a general key value store in an application cache.
And because Cosmos DB has built in replication
and can easily replicate data
into every region within Azure,
this means that developers
can build their eCommerce applications
and deploy them in multiple regions,
providing both higher availability and higher performance
for users where data is replicated more closely to them.
- Okay, so let's start to dig into some of the details here.
When I'm browsing a website,
I'd say my behavior's gonna pretty standard.
I'm gonna log in, search for a few things,
filter through results,
and eventually add it to my cart and forget about it.
Talk us through some of the pieces here
that make that possible.
- Okay, so for most e-commerce web applications,
there are essentially three places
you'll wanna store data.
You'll have a cold or a blob store,
a transactional store like Cosmos DB,
and then an application cache.
The blob store is where you would put things like
product images or other large static content
that doesn't make sense to store
in a transactional database.
In the transactional database,
we'll have all of our other product data
and customer data, including orders,
and also use it to provide a persistent storage
for our session state.
Then, in our cache, we'll have all sorts of things
to improve the performance and manage state itself.
- So walk us through how we might structure
our Cosmos DB database in this architecture.
- Right, so there are a number of different containers
in here that we would use.
The important data would be my customer and order data
which I'd store in a single container partition
by customer ID.
Second, I'd have my product catalog,
and this would have a document for each product
with all the data I need to render that product page
for the user,
including one or more URLs
that would then point to any of the images
I wanna render on that page.
And those URLs would basically point to blob storage
where I'd have those actual images saved.
As I pointed out earlier, Cosmos DB is schema agnostic.
Now, if I'm selling laptops and coffee cups on this site,
coffee cups, obviously, would have a value
for things like liquid ounces, a color,
and maybe a material like metal or plastic.
Laptops have attributes like CPU, RAM, SSD,
or hard disk capacity, et cetera.
So schema for storing these products as documents
is gonna relieve a lot of headaches
as we start to add more and more products to our catalog.
The other container I wanna call out here
is the one we'd use to store the session state
for the users.
In this application
we'll use the ASP net session state provider,
and use Cosmos as the underlying data store.
We could use it to store all of our cache data
such as product pages or anything else that would reduce
the number of trips to the database.
But in our scenario here,
what we really need is to use the session state
to store the contents of the user's shopping cart,
and then persist that into Cosmos DB.
This allows users to log in via some other means
like a mobile device or some other app
where they'd likely hit
a completely different set of app servers
so they can access the contents of their shopping cart
and anything else related to the session,
and basically just pick up from where they left off.
- So I also wanted to cover
a pretty crucial user experience piece
for most e-commerce applications,
and that's called search, right?
How do we go about creating that search filtering aspect?
- Typically we'll use something like Azure Cognitive Search.
Users can configure search
to index one or more containers in their database.
Then, when a user types in some text and click Search,
the request is sent to Cognitive Search
which then returns the results
which can then be rendered as a search results page
each pointing to an individual product
such that when a user clicks on that,
they are then directed to an individual product page
to view the results.
A developer would build out this search results page
and, of course, their own product pages.
But Cognitive Search
will give us everything we need to crawl through and present
relevant search results to users.
- So that's actually pretty simple.
Sure, there are some moving parts maybe
that we won't cover here
because I think that gives a pretty good idea
of how we get started if I wanted to
build something like this on my own,
but I wanted to revisit this idea of caching, right?
Cosmos DB has an integrated cache.
What's the difference between that cache
and using a container as a backup store
for the session state provider
and cache you mentioned earlier?
- Right, so the main goal of the integrated cache
is to reduce cost and latency for read heavy workloads
for queries which are exceptionally large and expensive.
You should only consider integrated cache
if you have repeated point reads on large items,
or if you have high volume of queries
that span multiple partitions, or even fan out queries
as well as scenarios where you have
say a hot partition key for your reads.
Integrated cache can both increase the performance
for your applications,
but it can also provide considerable cost savings
where there are issues with partition strategy
in your queries.
- Awesome, well, I think
that wraps up the second episode of season three.
Join us in the next episode we're gonna do the same thing
for an order processing solution
built with Azure Cosmos DB and Azure Functions.
We hope you learned something.
See you next time.
(upbeat music)