►
From YouTube: Optimizing Cassandra for Cloud Native Architecture | Apache Cassandra World Party 2021
Description
Presentation from the first Cassandra World Party on April 28, 2021. Learn more about Apache Cassandra at https://cassandra.apache.org/.
Subrata Ashe of Salesforece presents “Optimizing Cassandra for Cloud Native Architecture” on the optimizations his team made at Salesforce for Einstein Analytics Cassandra deployment in public cloud.
About the Presenter
Subrata is a principal MTS at Salesforce, specializing in performance at internet scale.
Apache Cassandra is an open source NoSQL distributed database trusted by thousands of companies for scalability and high availability without compromising performance. Linear scalability and proven fault-tolerance on commodity hardware or cloud infrastructure make it the perfect platform for mission-critical data. Get started: https://cassandra.apache.org/quickstart/
The Apache Cassandra World Party 4.0 was a virtual, one-day celebration on Wednesday, April 28, 2021 in preparation for the launch of 4.0, the most stable database release ever shipped.
Join the Cassandra community: https://cassandra.apache.org/community/
#ApacheCassandra #database #NoSQL
A
A
B
You
melissa,
hi,
I
am
subradha
shape.
I
am
a
principal
software
engineer
at
salesforce,
focusing
on
performance
of
distributed
systems.
I've
been
implementing
and
optimizing
cassandra
for
nearly
eight
years.
Now
in
this
lightning
talk,
I
will
be
giving
a
quick
walk
through
on
the
major
optimizations
that
we
did
in
cassandra
to
make
it
performant
and
in
our
journey
towards
cloud
native
architecture,
basically
making
cassandra
work
in
kubernetes
container,
with
strict
encryption
and
able
to
easily
port
to
any
cloud
provider.
B
In
the
agenda
for
today,
I
will
briefly
touch
upon
our
tableau
crm,
analytics
use
case,
the
major
performance
goals
that
we
had
and
the
key
optimizations
that
we
did
there
were
a
ton
of
optimizations,
but
in
the
interest
of
the
time
I
would
be
focusing
on
certain
key
major
areas
where
it
actually
helped
us
in
optimizing.
The
cost
to
serve
these
optimizations
would
be
specific
to
cloud
native
workload,
with
a
special
focus
on
cost
to
serve.
B
We
use
cassandra
as
a
primary
metadata
store
in
our
distributed
system,
stack
serving
multi-tenancy.
Our
cassandra
workload
consists
of
deterministic
rights
in
terms
of
scheduled
bad
jobs
and
random
reads,
which
are
real-time,
query
calls
to
fetch
metadata
in
terms
of
deployment.
We
are
cloud
native
with
three
availability
zones
and
root
traffic,
using
cassandra
containers
and
encryption
due
to
our
complex
implementation
of
cassandra,
both
in
terms
of
containerization
and
encryption.
We
set
the
performance
and
reliability
goals
to
follow
our
existing
data
center
deployment.
B
We
wanted
to
make
cassandra
faster
than
our
existing
already
performed
physical
data
center
deployment.
We
set
an
optimistic
p95
read,
write
latency
of
less
than
two
milliseconds
to
ensure
that
it
is
in
parity
with
existing
cluster
in
terms
of
transaction
throughput
and
speak
smoothness.
Our
availability
goal
was
also
to
achieve
five
nines
as
part
of
the
performance
initiative.
We
analyzed
our
workload
and
performed
benchmark
tests
with
encrypted
containers.
B
Since
we
already
had
an
existing
performance
cassandra
running
in
production,
we
used
the
same
configuration
for
our
cloud
deployment.
However,
due
to
the
earlier
complexities,
we
soon
hit
bottlenecks
in
terms
of
read
and
write.
We
invested
analyzing
the
areas
where
we
can
optimize
and
reduce
the
cost
to
surf.
We
wanted
to
achieve
higher
iops
with
latencies
and
better
cost
to
serve.
Now.
B
If
you
look
into
this
hotspot
that
we
have
for
right,
we
analyze
the
workload
and
benchmark
test
with
encrypted
containers,
and
this
hotspot
actually
provided
us
a
gold
mine
which
pointed
us
to
underperforming
code
path
in
flushing
right
buffers
to
disk
which
was
slowing
down.
The
reads
more
than
that
it
also
increased
the
memory
used
by
dirty
buffers
in
page
cash
and
a
long-running
rights
workload
showed
initial
signs
of
out
of
memory
with
the
root
causes
known
now.
We
know
that
there
has
been
some
issues
there.
B
We
separated
the
commit
logs
and
ss
table
storage
in
two
separate
ssd
volumes
that
enabled
us
a
guaranteed
iops
and
a
network
bandwidth
between
the
two
volumes.
We
also
changed
the
disk,
optimization
strategy
to
ssds,
and
it
came
as
a
default
option
based
on
our
findings
from
the
hotspot.
We
also
enabled
trickle
f
sync
to
true
so
that
dirty
buffers
are
flushed
at
regular
intervals.
B
After
tuning
the
iops
and
the
latency
bottlenecks,
we
looked
into
ways
to
reduce
the
network
bandwidth
usage
as
well,
which
is
also
a
driver
for
our
cost,
to
serve
iterating
on
our
design
pattern.
We
run
in
three
availability
zones
and
our
workload
is
highly
variable
in
terms
of
read
and
writes,
and
what
we
did.
We
experimented
with
different
cassandra
configurations
and
found
out
which
algorithm
and
pattern
would
be
optimal,
based
on
that,
we
enabled
internode
commit
log
and
hint
compression
and
also
set
lz4,
as
our
compression
algorithm.
B
B
This
would
not
be
possible
without
the
support
of
the
entire
community,
and
I
would
like
to
take
this
opportunity
to
thank
jeremy,
who
was
my
partner
in
crime
as
well
as
my
advisor,
whose
guidance
has
been
immensely
valuable
in
this
journey.
If
you
would
like
to
know
more
about
cloud
native
architecture
deployments
for
cassandra
feel
free
to
reach
out
to
me
on
linkedin.
Thank
you.
C
Awesome
thanks
so
much
to
brother.
I
love
these
journeys
that
people
take
where
you
know
they
adopt
a
system,
learn
more
about
it,
optimize
it
and
it
really
gets
down
almost
to
getting
cassandra
to
behave.
You
know
with
the
environment
that
you
choose
right.
I
really
really
love
this
concept
of
mechanical
sympathy
and
I
I
think
this
talk
just
so
well
highlights
it.
So
thanks
so
much
to
brother,
it
was
such
an
awesome
journey.
I
love
seeing
that
and
also
some
great
takeaways
for
the
folks
who
are
watching
from
home.