►
From YouTube: Using Redis as a .NET Core Data Store
Description
In this episode of On .NET, Todd Gardner walks Christos through how his company is using Redis in their .NET Core application as the main data store. He explains the architecture of the project and shows how they integrate with StackExchange.Redis.
[04:00] - Reviewing the data model
[07:56] - Reviewing the data in Redis
[10:09] - Working with Redis and .NET
Using Redis with .Net C#
https://docs.redislabs.com/latest/rs/references/client_references/client_csharp/
Quickstart: Use Azure Cache for Redis with a .NET Core app
https://docs.microsoft.com/azure/azure-cache-for-redis/cache-dotnet-core-quickstart?WT.mc_id=ondotnet-youtube-cephilli
Improve session scalability in a .NET Framework ASP.NET web application by using Azure Cache for Redis
https://docs.microsoft.com/learn/modules/aspnet-session/?WT.mc_id=ondotnet-youtube-cephilli
StackExchange.Redis on GitHub
https://github.com/StackExchange/StackExchange.Redis
Request Metrics
https://requestmetrics.com/
#dotnet #redis
A
A
And
we're
back
for
another
episode
on
on.net
and
today
again
we
have
taught
gartner
to
talk
to
us
about
the
amazing
stuff
that
he's
building
with
dot
net
core
and
this
time
we'll
be
talking
about
using
redis
as
a
data
store
for
their
solution.
Welcome
to
so
todd
once
again
nice
to
have
you
here
thanks.
A
B
Yeah
so
today
I
want
to
talk
a
little
bit
about
redis
and
how
we're
using
redis
from
from.net
core.
If
you
didn't
see
our
earlier
episode,
we're
building
a
tool
called
request:
metrics,
which
is
going
to
be
a
new
web
performance
monitoring
service.
So
you'll
drop
a
script
into
into
your
website
and
we'll
gather
all
kinds
of
information
about
how
real
users
are
experiencing
the
performance
of
your
web
pages
and
your
api
endpoints.
B
But
to
gather
all
of
this
data
together,
we
need
somewhere
to
put
it
and
because
we're
we're
trying
to
advocate
for
high
performance
web
pages.
We
need
our
web
page
our
service
to
be
super
fast,
and
so
we
chose
redis
to
do
it,
but
there's
a
number
of
constraints
that
we
ran
into
in
building
that,
and
so
I'd
like
to
to
show
you
some
of
some
of
that.
If
I
could
yeah.
A
And
just
to
be
clear,
you
know,
as
dotnet
developers,
we
have
a
vast
array
of
storage
solutions.
We
have
sql,
we
have
no
sql
anything
that
comes
to
mind
and
I
always
thought
that
redis
was
a
casting
system
right.
So
we
have
my
sql
server
stored
in
the
data
and
they
have
red.
Is
that,
like
super
fast
cast
system
where
I
can
get
the
latest
data
for
a
specific
subset?
But
now
you're
telling
us
that
we
can
use
actually
ready
for
a
full-blown
data
store
and
be
done
with
sql
right.
B
Yeah
mind-blown
right
like
it's,
the
super
fast
layer,
that's
set
between
your
traditional
data
store,
but
what,
if
you
just
use
that
super
fast
data
store?
And
then
everything
is
just
fast
and
you
don't
have
to
deal
with
the
problems
that
you
get
in
caching
and
stale
caches
and
missed
caches
and
that
sort
of
thing
well.
A
B
Let
me
show
you
so
this
is
our
initial
architecture
of
what
we're
building
request
metrics
to
be
at
the
top,
is
going
to
be
a
javascript
agent
that
our
customers
are
going
to
install
in
their
in
their
web
page
and
that's
going
to
be
what
gav
actually
gathers
the
performance
data
from
end
users.
We
funnel
all
that
data
back
to
our
service,
which
is
going
to
be
a
cluster
of
linux
services.
B
Nginx
will
pick
up
that
data
and
store
it
off
onto
the
file
system,
and
then
we
have
a
dotnet
a.net
service
called
processor
that
we
talked
about
yesterday
and
that
processor
grabs
all
those
log
files
and
chews
up
the
data
and
decides
what
we
want
to
keep
and
how
we
want
to
roll
it
up
and
stores
it
into
redis
directly
and
the
whole
reporting
ui
is
also
talking
to
redis.
So
there's
no
other
background
store.
There's
nothing
else.
Redis
is
this
key
value,
pair
memory
or
a
data
store?
B
Page
data
represents
a
page,
a
url
that
we
got
performance
data
from
from
one
of
our
customers,
so
this
could
represent
microsoft.com
like
it
is.
It
is
the
root
page
and
the
things
that
we
keep
about.
This
is
we.
We
know
about
a
url
and
a
hash.
We
generate
a
hash
for
all
the
urls
just
so
that
we
have
consistently
shaped
data
to
do
queries
based
off
of
but
the
thing
that
we're
keeping
about
this
that's
interested
or
that's
interesting.
We
call
the
page
performance
period.
B
B
What
interval
are
we
looking
at
so
this
for
us
will
be
a
minute
or
an
hour
or
a
day,
and
then
what
is
the
start
time
of
that
period,
and
so
that
kind
of
identifies
what
it?
What
are
all
these
metrics
for
and
then
all
of
our
individual
counters
are
things
like
how
many
times
was
this
page
loaded
in
the
period?
How
many
unique
people
were
loaded
in
that
period?
What's
the
total
duration
that
everybody
spent
loading?
B
We're
conscious
of
not
just
firing
in
giant
objects
with
really
verbose
names,
and
so
we
override
the
names
of
these
things
to
be
short
codes,
so
that
we're
we're
sending
fewer
characters
across.
You
know
into
the
memory
buffer
and
there's
fewer
characters
than
redis
for
us
to
capture,
and
so
this
was
one
of
the
things
that
that
complicated
our
structure.
A
little
bit
is
that
we
have
to
be
aware
of
the
total
data
size
and
minimize
that
a
little
bit.
A
B
We
haven't
so
the
serializer
that
we're
using
is
the
is
the
utf-8
json
serializer.
We
did
a
little
bit
of
a
bake
off
on
on
the
json
serializers
available
to
us.
There's
the
you
know
the
tried
and
true
newton
soft
one.
That's
been
around
forever,
there's
the
new
one
that
was
built
into
the
framework
under
the
system.data
and
then
there's
this
third-party
module
called
utf-json
and
the
newtonsoft
one
and
the
new
built-in
one
had
roughly
similar
performance
characteristics.
B
Some
constraints
like
it
wasn't
able
to
automatically
detect
things
as
well.
You
have
to
be
a
little
bit
more
explicit
with
it
of.
I
want
this
name
to
go
to
this
thing
right,
like
it
couldn't
necessarily
suss
out
that
interval
meant
interval.
If
you
don't,
if
you
don't
name
things
so,
you
just
have
to
be
a
little
bit
more
verbose,
but
because
of
that,
you
get
a
way
higher
performance
like
almost
twice
or
three
times
as
fast
as
the
built-in
one.
So.
B
A
B
Okay,
so
this
is
the
redis
desktop
manager,
which
is
just
a
little.
You
know
helper
app
that
lets
me
browse
redis
and
see
what
it
actually
looks
like,
and
here
is
a
page
performance
period
as
it's
represented
in
redis,
and
so,
if
we
look
at
this
particular
document,
you
can
see
it's
obviously
a
json
document
and
all
of
our
short
codes
are
in
there.
So
this
is
a
day
interval
that
started
on
may
19th.
B
B
This
object
itself
has
a
complex
compound
key
so
because
it's
redis
and
because
it's
fundamentally
just
a
key
value
store,
I
can't
do
queries.
I
can't
say,
hey
tell
me
all
give
me
all
the
page
performance
periods
where
this
value
is
over
this
limit.
I
simply
do
not
have
the
ability
to
do
that
without
loading,
everything
which
wouldn't
be
quite
as
fast
yeah,
and
so
when
I
want
data,
I
need
to
know
how
to
specifically
address
it
and
that's
where
our
our
system
kind
of
comes
in.
B
If
you
see
over
here
on
the
left
side,
this
particular
document
has
a
really
complex
compound.
Key
that,
for
us
represents,
is
a
grid
which
is
like
the
customer
id
the
application
id.
So
like
what
application
are
we
tracking
a
p
that
stands
for?
This
is
about
a
page,
and
then
this
is
the
hash
of
the
url.
B
So
if
I
want
the
page
performance
periods
for
a
given
application,
I
just
need
to
know
how
to
construct
this
key,
and
I
can
fetch
all
of
this
data
down
at
the
same
kind
of
performance
characteristics
that
you
would
expect
from
redis,
meaning
ridiculously
fast
like
right.
I
have
this
key.
I
can
expect
to
get
this
response
back
in,
like
five
milliseconds.
B
B
A
B
Like
you
have
to
kind
of
commit
to
async
like
once,
you
start
async,
you
kind
of
fall
into
this
waterfall
where
one
thing
is
async
the
whole
stack
kind
of
ends
up
async,
but
if
you
just
embrace
it,
it
ends
up
working
phenomenally
well
for
us
to
get
a
page
performance
period.
It's
really
the
hard
part
is
just
about
constructing
the
key.
How
do
I
build
this
compound
key
for
us
to
figure
out
what
to
do,
and
so
we
built
helpers
around
that.
B
So,
given
a
particular,
you
know
application
token
and
a
given
page
that
we're
after
assemble
a
key,
which
is
that
long
string
separated
by
colons.
I
showed
you
earlier
and
then
figure
out.
What
specific
thing
are
we
asking
for?
Are
we
asking
for
an
hour
at
this
particular
time
period
or
whatever,
and
so
by
building
that
we
can
pull
up
a
standard,
redis
client
we're
using
the
the
stack
exchange,
redis
client
out
on
nuget,
which
seems
to
be
pretty
much
the
de
facto
standard,
almost
of
redis
clients
out
there.
B
And
then
it's
just
about
you
know
getting
the
key
so
same,
underlying
behavior
that
you
would
expect
using
this
as
a
cash
system.
I
just
say:
hey
give
me
my
key
and
I
get
the
raw
string
as
long
as
that
string
isn't
null.
We
can
deserialize
it
using
that
same
high
performance,
utf-8,
jason,
serializer
back
into
an
object.
B
Stick
a
couple
of
properties
that
we
had
to
manually
build
like
the
token
and
the
page,
hash
that
we
don't
actually
serialize
for
performance
reasons
and
return
that
out
and
that's
how
all
of
our
fundamental
crud
operations
with
our
with
our
redis
system
operate.
It's
about
build
building
a
key,
get
get
me
that
key
serialize
it
out
and
return
in
return.
A
Perfect
now,
I
think
that
I
mean
performance
is
great.
Here,
performance
is
key,
so
we
know
that
this
can
deliver
on
that,
but
as
a
person
that
has
worked
on
many
systems-
and
there
are
certain
questions
that
people
will
be
asking
like
what
is
my
disaster
recovery
with
redis
and
you
know
what
happens
if
I
need
to
scale
out
or
scale
down
or
what
have
you?
So,
how
did
you
guys
solve
this
problem
right.
B
These
ones
are
set
up
using
the
standard,
redis
high
availability,
as
in
one
is
the
primary
and
the
other
two
are
backups,
so
one
is
acting
as
I
am.
The
lead
authority
figure
and
it's
just
firing
copies
of
the
data
to
the
other
ones,
which
are
read
only
now.
Redis
is
going
to
handle
its
own
failover
system
right.
So
as
long
as
we
are
addressing
the
cluster,
when
one
of
them
goes
down,
if
one
of
them
goes
down
knock
on
wood,
when
one
of
them
goes
down,
the
system
should
automatically
figure
out.
B
Oh,
my
local
redis
is
down
I'm
going
to
go
and
fire
at
one
of
the
other
ones,
and
it
should
like
elect
a
new
primary
node.
Now
that
works
for
high
availability,
it
works
pretty
pretty
well
for
that.
But
it's
not
exactly
disaster
recovery
because
what
happens
if,
for
whatever
reason
we
lose
all
of
our
boxes,
they
go
down.
B
You
can
configure
redis
during
the
installation
to
save
a
copy
of
its
in-memory
data
store
to
disk.
It's
just
it'll,
just
dump
it
into
its
own
local
directory
as
a
rdb
file,
a
redis
database
file,
and
as
it's
going,
it's
going
to
keep
that
file
relatively
up
to
date,
and
so
we
just
need
to
take
a
backup
of
this
file.
You
can
send
a
command
to
redis
through
the
redis
command
line,
to
flush
any
pending
changes
out
to
disk.
B
So
once
an
hour,
we
have
a
job
that
will
call
into
redis
and
say:
hey
flush,
your
database
down.
We
make
a
copy
of
that
database
and
we
send
it
off
site.
We
we
upload
it
to
a
third-party
service
that
is
not
inside
of
our
own
infrastructure,
because
you
know,
if
we're,
if
we're
trying
to
have
if
you've
built
your
whole
life
in
azure,
your
disaster
recovery
should
probably
not
be
in
azure.
You
probably
need
to
send
it
somewhere
else.
You
know.
B
Goes
down
so
we
take
that
file,
we
push
it
off
and
then
in
order
to
make
sure
that
it's
right
and
we
haven't
corrupted
something
right,
because
you
don't
know
that
your
backup
works
unless
you've
restored
it.
Oh
yeah,
oh
yeah,
immediately
after
we
do
that
backup,
we
restore
that
backup
into
our
development
environment,
which
has
a
couple
of
benefits.
One
is
we
always
know
that
our
backups
are
good
right.
If
our
development
environment
is
online,
the
backup
was
good
and
second,
we
always
have
real
fresh
data
to
play
with
in
our
development
environment.
A
Well,
I
wish
I
wish
every
every
development
system
was
like
that,
so
you
could
play
with
real
data
and
update
it
yeah,
but
but
it's
fantastic,
because
your
backups
are
as
good
as
your
restores
right
and
many
people
will
take
backups
but
never
test
the
restore
and
then
they're
in
a
pain
and
a
world
of
pain
when
it
comes
to
doing
disaster
recovery.
What
you
guys
have
set
up
here
is
fantastic,
so
goodness
to
you
for
doing
it
properly,.
B
There's
a
couple
of
other
cool
implications
of
this.
The
the
big
downside
that
we
already
talked
about
with
using
redis
is
that
you
can't
just
do
a
query.
I
can't
you
know,
do
a
complex
query
and
get
data
back
based
on
a
property.
At
least
I
can't
without
scanning
the
entirety
of
redis
and
doing
it
in
code,
which
kind
of
defeats
the
performance.
B
But
as
long
as
I
use
complex
keys
to
get
exactly
the
data,
I
want
it's
super
fast
and
because
of
that,
I
can
do
other
things
that
used
to
be
slow.
Like,
for
example,
almost
all
of
our
tests
in
the
system
are
integration
tests
that
talk
to
a
real
redis
system,
because
I
can
just
set
up
redis
locally
so
fast
that
all
of
my
tests
run
super
fast,
and
I
don't
need
to
worry
about
mocking
up
a
fake
data
store.
A
B
You
could
conceivably
use
it.
However,
I
think
you
are
going
to
quickly
lose
your
benefits
if
you,
if
you're,
relying
on
your
application
logic
to
enforce
those
relationships
and
complex
queries,
you're
essentially
reinventing
a
smaller
version
of
a
relational
database
in
your
own
code
right
and
if
you
need
to
do
that,
if
your
system
needs
to
guarantee
like
acid
compliance
and
guaranteed
rights
and
transactions
and
sql
querying
and
all
that
sort
of
thing
may
as
well,
leave
it
to
a
database.
B
A
Great,
so
I
learned
something
very
important
today:
the
fact
that
you
can
actually
use
readies
for
for
a
backup
or
as
a
data
store
for
your.net
core
solutions
and
it's
great
to
see
what
you
guys
are
building
there.
I
mean
just
saying
how
simple
it
was
to
interact
with
redis.
It's
great
thank
you
for
taking
time
to
show
us
what
you
have
built
so
far.