►
From YouTube: All Things Data: Optimizing Crunchy PostgreSQL with OCS
Description
As part of the “All Things Data” series of briefings, Red Hat’s Sagy Volkov and Chirag Dave & Greg Smith from Crunchy Data gave an overview the Crunchy PostgreSQL Operator and as well as optimizing the Crunchy PostgreSQL Operator with OpenShift Container Storage. Actual performance numbers will be shown and discussed during this briefing.
OpenShift Container Storage (OCS) is software-defined storage for containers that provides you with every type of storage you need, from a simple, single source. Learn more here: openshift.com/storage
Crunchy Data is a leading provider of cloud native PostgreSQL – providing open source, cloud-agnostic PostgreSQL-as-a-Service solutions. PostgreSQL’s active development community, proven architecture, and reputation for reliability, data integrity, and ease of use makes it a prime candidate for enterprises looking for a robust relational database alternative to expensive proprietary database technologies. Learn more here: www.crunchydata.com
A
Hello,
everybody
and
thank
you
for
joining
us
today
and
welcome
back
to
another
All
Things
data
OpenShift
Commons
briefing.
Today
we
have
special
guests.
Vickie
Volkoff
is
joining
us
again.
Our
chief
storage
performance,
instigator
and
storage
and
Greg
Smith
and
Chirag
Dave
from
crunchy
data
are
joining
us
today
as
well.
We
really
are
excited
to
hear
about
all
the
performance
testing
that
has
been
done
between
crunchy
data
and
the
open
shift
container
storage
team.
Those
two
key:
please
take
it
away
good.
B
Morning,
everyone,
let's
start
with
with
the
slides,
we're
gonna,
do
very
60-seconds
brief
intro
that
is
not
needed
for
post
quests.
Our
folks
from
crunchy
are
going
to
talk
about
the
crunchy
operator,
talk
a
little
bit
about.
Why
use
a
opposite
container
storage
for
with
crunchy
and
then
I'll
talk
about
the
testing
that
was
done
talking
about
the
layouts
numbers
and
all
of
that
and
we'll
leave
few
minutes
for
questions
if
there's
anything
so
Postgres
very
old
and
trusted.
B
C
Hello,
everyone,
I'm
Greg
Smith,
director
of
open
source
strategy
for
crunchy
data.
We
like
to
give
people
just
a
brief
outline
of
things,
because
if,
if
you're,
not
working
inside
of
the
post
rest
community,
there
can
be
a
little
confusing
as
to
what's
going
on.
So
we
like
to
get
people
an
overview
from
our
perspective
and
why
why
we
think
it's
good
to
know
all
this
for
kubernetes
and
this
type
of
deployments.
C
So
crunchy
is
the
top
companies
supporting
pure
open-source
post
graphs,
and
by
that
I
mean
we
don't
have
any
commercial
or
closed
source
projects.
It's
all
open
and
we've
expanded
to
where
the
majority
of
new
community
post
stress
code
passes
through
crunchy
on
its
way
to
commit,
and
then
we
have
a
stack
of
a
dash
of
additions
to
that
base
available.
You
know
which
goes
all
the
way
up
to
the
operator
and
then
features
on
top
of
that.
C
C
You
know,
there's
a
lot
of
different
companies
working
together
and
they
all
review
and
commit
each
other's
submissions,
and
then
that
community
creates
a
shared
core
kernel:
commercial
vendors,
spin,
their
own
distributions
based
on
now
Red
Hat
ships,
a
perfectly
fine
Postgres
in
fedora,
and
it
had
Enterprise
Linux,
there's
nothing
wrong
with
that.
The
idea
is,
if
you
use
Crunchy's
certified
Postgres.
Instead,
you
add
some
auditing
and
security
features
and
then,
if
you
add
our
operator,
that's
the
next
step
to
picking
up
crunchy
best
practices
for
administration
and
scale.
C
Well
in
the
last
few
years,
our
Postgres
based
approach
is
really
jelled.
Well,
with
all
the
people
are
looking
to
do
cloud
database,
migrations
to
shrink
their
data
centers
and
that
sort
of
thing
the
the
kubernetes
has
worked
particularly
well
for
that
and
the
operators
are
the
preferred
way
to
set
up
and
manage
that
sort
of
cloud.
This
is
this
is
real
stuff.
In
production
we
have
production
customers
using
hundreds
of
crunchy
containers,
doing
work
in
and
out
every
day.
C
We
think
it's
an
important
point
because,
as
we
see
a
Cuban
at
ease,
just
dislikes
commercial
licensing
for
the
fundamental
infrastructure
pieces
and
in
a
cloud
environment
where
the
exact
number
and
distribution
of
servers
deployed
is
constantly
changing
commercial
database
licenses
in
particular,
can
be
a
real
hard
fit.
What's
nice
with
Postgres
is
we
do
have
a
wide
range
of
features?
You
know
all
the
way
to
things
like
the
no
SQL
say
he
was
just
mentioning.
You
know
we,
we
have
a
very
wide
range
of
apps.
C
C
As
for
why
to
use
an
operator
at
one
point,
we
really
spent
a
lot
of
time
trying
to
package
our
database
products
into
kubernetes
when,
when
I,
first
where'd,
the
when
I
first
read
the
initial
cube
blog,
that
was
introducing
operators
back
in
late
2016.
That
was
really
a
lightbulb
moment
for
us.
I
said
this:
the
state
driven
architecture-
it's
immediately
struck
me
as
the
right
way
to
organize
this.
This
type
of
problem
and
we've
we've
jumped
right
into
it
as
fast
as
we
can.
C
We
started
out
by
covering
the
most
urgent
database
foundations,
so
we
think
of
that
as
being
replication
and
backups,
you
know
things
where,
especially
in
the
kind
of
less
reliable
than
bare
metal
situations,
cloud
gives
you.
You
really
need
to
make
sure
your
backups
and
everything
are
great
step
one
before
you
do
anything
else,
and
then
we
work
our
way
up.
The
stack
from
there
lately
there's
been
this
another
burst
of
commercial
open
source
software's.
That
seems
like
they're
going
the
other
way.
C
I
mean
some
of
the
some
of
the
projects
like
Redis
and
are
kind
of
rien
gauging
their
customers
with
cloud-based
license
restrictions,
the
whole
thing's
kind
of
weird,
but
the
the
point
that
we
like
to
emphasize
with
post
Grass.
There
is
no
one
company
that
owns
the
entirety
of
the
Postgres
code,
it's
owned
by
the
group
that
does
the
development.
You
know
Crunchy's
as
big
as
anybody,
but
even
we
can't
just
go
in
and
change
Postgres
or
take
it
over
real
Ison's
it
or
anything.
C
It's
a
true
community
project
like
Linux,
and
that
makes
it
a
reliable
base
that
people
can
build
on
without
having
to
worry
about
it
going
away,
because
you
know
some
vert,
some
VC
person
changes
their
mind
one
day.
We
don't
have
that
problem
in
Postgres.
So
what
the
what
the
operator
is,
let
us
do.
We've
had
three
years
of
development
on
it
with
a
busy
team
and
we
don't
just
publish
the
code.
You
know
we're
doing
the
full
eating
your
own
dog
food
style.
Here.
C
C
Yeah
we
have
another
beta
I
mean
we're
just
we're,
starting
to
get
into
more
complicated
features
like
there's
a
lot
of
security
related
stuff
where
people
are
going.
Oh,
we
want.
You
know,
secure
connections,
to
work
over
this
type
of
thing,
but
then
you
discover
the
connection.
Polar
doesn't
work,
I
mean
these
are
the
sort
of
things
you
discover
after
you
build
the
initial
demo
and
go
okay.
Wait
a
Matt.
You
know,
there's
some
things
that
just
don't
work
together
quite
like
you
expect
them
to
so
we're.
C
Just
we
just
keep
cranking
out
releases,
smoothing
over
as
many
of
those
hard
parts
as
we
can,
the
idea
being
once
we
get
them
done.
You
don't
even
need
to
know
about
these
weird
problems
with
you
know,
TLS
protocol
and
how
it
interacts
with
the
two
connection.
Pullers.
You
know
we're
just
trying
to
hide
higher
and
higher
levels
of
code
with
each
new
release,
cool.
B
So
the
testing
that
I've
done
here
are
basically
on
an
opposite
container
storage
for
those
to
kind
of
you
can
say
almost
4.3
version
with
this
directly
touch
each
other.
Why
use
a
opposite
container?
Storage
for
crunching?
If
you
know
this
a
few
of
the
slides
mentioned
high
availability
features
from
de
Franchi
operator.
Well,
the
main
feature
is
the
main
reason
is
that
you
might
not
only
run
the
crunchy
operate
or
you
might
not
only
run
a
post
course
database.
B
You
might
run
various
different
of
a
database
or
you
have
other
needs
that
needs
a
persistent
storage
and
needs
a
D&C,
and
so
openshift
container
storage
basically
provide
resiliency
to
all
applications
that
need
a
persistent
storage
among
them
post
quest
via
the
crunchy
operator,
of
course,
so
cs4
fully
integrated
with
the
openshift
4,
and
that's
why
we
have
kind
of
the
two
companies
partnered
together
to
to
bring
this
up
alright.
So
let's
not
talk
about
the
testing
their
layout.
All
of
this
was
done
on
AWS.
B
B
We
have
another
set
of
nodes,
three
nodes
of
the
type
I
3e
and
the
2x,
which
are
from
the
opposite
perspective
worker
nodes,
but
they
are
in
my
testing,
considered
to
be
storage,
nodes,
meaning
they
are
running
opposite
container
storage
for
and
that's
the
only
thing
that
they
are
running.
Of
course,
besides
the
any
other
minimal
ports
that
means
to
be
run
by
openshift
each
of
these
nodes
is
we
write
core
64
gig
of
ram
each
of
these
virtual
machines,
I
should
say,
and
they
each
of
these
VMs
have
to
director
touch
nvme
devices.
B
B
So
we
left
about
25%
of
the
resources
or
20
or
25%
of
the
reach
of
these
nodes.
For
anything
that
might
you
know
that
openshift
itself
for
kubernetes
itself
might
need
benchmark
tool,
usually
most
people
with
Postgres
like
to
use
PG
bench,
but
I've
chosen
this
bench
few
reasons
it
has
emulate
a
more
realistic.
Let's
say
web
application
form
of
iOS
with
a
lot
of
random
processing
of
of
all
kinds
of
data.
B
B
Each
database
is
a
gigabyte
in
size
for
the
tables
1
million
rows.
Each
each
seized
bench
was
ran
with
16
threads,
so
each
to
connect
them
to
each
Bosco's
pod
and
the
usual
about
five
minutes
of
warning,
followed
by
ten
minutes
ones
with
the
rest
of
60
seconds.
That's
about
the
layouts!
Let's
talk
about
this
is
another
half
a
day
for
me:
work
to
create
these
nice
graphics,
but
that's
basically
showing
the
difference
between
the
single
availability
zone
and
multi
availability
zone
showing
where
exactly
in
each
of
the
storage
nodes
and
applicational
sites.
B
C
B
Of
databases,
the
total
cluster
of
transactions
is,
for
that
particular
run
what
we
were
able
to
achieve
and,
as
you
can
see,
there's
we
are
showing
the
latency
per
database,
an
average
and
even
more
important
in
95
percent
on
latency
for
for
these
ones.
From
the
you
know,
performance
perspective
on
the
graph
side
we
do
like
to
see
things
are
more
on
the
steady
side
and
not
too
many
spikes
on
the
line
which
is
really
good.
So
this
is
on
single
zone.
B
The
performance
numbers,
these
two
graphs,
editing
and
showing
here
I
was
talking
about
a
little
bit
on
the
inner
level.
On
the
left
side,
he
is
basically
the
these
are
BD
1
2
3
are
basically
the
persistent
volume
claims
that
each
node,
as
you
can
see,
we
have
three
nodes
that
are.
These
are
the
application
out.
B
Have
each
nodes
have
three
PVCs
touch
two,
because
each
node
is
running
three
postcodes
databases:
you
can
see
clearly
have
the
ratio
between
you
know
roughly
around
70
30
on
the
right
side.
These
are
the
actual
self
numbers
or
the
usage
utilization
of
OSD
devices
and
from
the
three
storage
nodes.
So
if
you
remember,
we
have
two
nvme
devices
in
each
of
these
storage
nodes,
and
this
is
the
utilization
of
between
reads
and
writes
important.
To
note
this.
B
B
B
Logically,
the
single
zone,
which
should
have
better
latency
between
all
the
nodes,
should
behave
faster
than
nodes
that
are
on
three
different
zones
that
also
should
have
higher
latencies
between
them.
But
again
and
I
always
add
that
in
my
conversation
about
performance,
don't
believe
my
numbers
go
and
go
and
check
it
yourself,
but
again,
steady
number,
even
across
three
availability
zones
and,
as
I
said,
better
numbers
in
a
single
zone
and
the
last
slides
here
is
the
same
thing
as
previously.
B
On
the
left
side,
these
are
the
ratio
of
their
read
rights
of
the
PVCs
of
each
of
the
post
quest
databases,
and
that
was
on
the
left
side
and
on
the
right
side.
These
are
the
read
rights
ratios
of
the
nvme
devices
between
the
nodes
that
are
providing
this
storage
and
I.
Think
that
if
there
are
any
questions,
we
will
be
happy
to
answer
them.
I.
C
You
know
these
are
more
like
that,
because
you
went
out
of
your
way
to
force
the
thing
to
like
struggle
and
seek
with
this
canned
whatnot.
You
didn't
just
run
it
and
let
it
go
with.
You
know
everything
in
memory.
You
know
which,
which
a
lot
of
smaller
databases
do
operate
like
that
yeah
exactly
and
just.
B
There
are
our
utilization
percentage
for,
for
example,
for
the
nvme
devices
and
they
are
in
the
higher
80s
to
the
lower
90s
on
each
of
their
storage
nodes
and
again,
like
Greg,
said,
and
that
is
the
difference
basically
between
these
two
graphs
on
the
left
on
the
right,
while
the
PVC
that
the
Postgres
or
the
crunchy
instance
is
using,
is
doing
a
single
right,
of
course,
with
openshift
container
storage.
Because
of
resiliency.
B
We
add
two
more
writes,
because
there
are
three
copies
and
and
and
and
that's
why
you
actually
don't
see
this
ratio
on
the
right
side
of
the
of
the
graphs
of
between,
like
70
and
30
70,
reads:
a
30-year
percentage,
writes
a
ratio
but,
and
and
and
also
repeating
yes.
The
goal
here
is
to
actually
measure
storage
and
not
to
measure
and
the
memory
or
Ram
of
an
AWS
virtual
machine,
and
that's
why
the
ratio
between
the
size
of
the
database
and
the
RAM
of
each
of
these
Postgres
database
is
such.
C
There's
nothing
wrong
with
that.
I
just
want
people
to
make
sure
that's
what
you're
seeing
and
you
understand
the
difference
between
it.
I
it's
a
great
job.
Focusing
at
that
thing.
It's
just
I
know
it
can
be
a
little
tricky
when
you're
your
first
time.
You
stare
at
this
graphs
to
make
sense
of
it,
so
that
that's
how
I
think
of
your
test
and
I
think
it's
very
valuable
to
have
gotten
that
information.
So
we
appreciate
your
your
digging
through
this
for
so
many
weeks.
That's.
D
True
I
would
like
to
add
another
comment
here,
so
this
is
a
great
solution.
If
anybody
is
looking
to
run
single
instance
Postgres
with
a
replicated
storage
but
bit
crunchy
operator,
you
could
still
have
those
Chris
H
a
natively
available
with
your
replica.
So
if
you're
looking
for
a
read
replica,
that
is
also
possible
with
the
operator.
So
if
you
combine
those
yes
with
the
post,
Chris
application
you
have
best
of
both
world
could
have
read
replica
plus
shorted
replication.
So
I
just
wanted
to
add
that
well.