►
Description
Presentation on SHIFT's migration from MongoDB to Cassandra. Topics will include reasons behind choosing to move to Cassandra, zero downtime migration strategy, data modeling patterns, and the benefits of using CQL3.
Speakers:
Jon Haddad, Senior Architect at SHIFT
Jon Haddad is the Sr. Architect at SHIFT and is one of the maintainers of cqlengine. Jon has spent the last decade at various startups in the LA area. His previous projects include Answerbag.com and Livestrong.com.
Blake Eggleston, Senior Developer at SHIFT
Blake Eggleston is a Senior Developer at SHIFT. He is one of the authors of CQLengine, the Python CQL3 object mapper, and a member of Tinkerpop, the graph database development group.
A
Hello,
everyone
and
welcome
to
this
edition
of
our
Cassandra
community
webinar
series
really
excited
today
to
have
a
topic
that
we
are
seeing
more
and
more
of
in
the
community,
and
those
are
companies
that
got
started
down
the
mongodb
path
and
then
subsequently
migrated
to
Cassandra.
So
we
have
with
us
today,
Blake
eggleston
and
John
had
ad
from
shift.
A
So
late
mm
he's
going
to
be
talking
about
cql
engine
that
he
helped
write
and
he
is
a
senior
developer
at
shift
and
his
colleague
John
Haddad,
who
is
the
senior
architect
and
he
maintains
cql
engine
before
I
hand
over
to
them
just
some
usual
housekeeping
rules.
We
will
take
questions
and
answers
at
the
end
of
today's
session.
Please
use
the
Q&A
tab
inside
of
WebEx
to
pose
your
question
and
we
will
get
through
as
many
of
them
as
we
can
at
the
end.
Okay,
so
thank
you
very
much
without
further
ado.
B
Christian
so
hi
everyone-
this
is
blake
eggleston
and
John
had
ad
from
shift
calm,
and
today
we're
going
to
be
talking
about
our
migration
from
MongoDB
to
Cassandra,
so
just
give
a
little
background.
Syscom
is
a
platform
aimed
at
marketers
that
allows
them
to
communicate
across
departments
and
organizations
in
one
single
place,
and
it's
also
an
application
platform
to
host
a
set
of
marketing
related
applications
that
talk
to
each
other,
as
well
as
talk
to
the
team
that
I
think
people
belong
to,
but
at
its
core
it's
mainly
a
big
messaging
platform.
C
Right
so
we
got
started
about
a
year
ago.
We
knew
that
we
wanted
to
build
everything
out
in
Python,
using
flask
and
celery
for
all
our
background
tasks
so
on
the
database
side,
window
picking
and
neo4j
neo
how
a
lot
of
kind
of
interesting
how
to
be
surrounded-
and
we
wanted
to
do
certain
types
of
queries.
So
that's
what
we
picked
it
and
later.
D
C
B
C
C
Initially
search
was
just
for
full
text,
but
it
turns
out
that
it's
powerful
enough
to
do
a
lot
of
very
complex
queries
facets
things
like
that,
we're
still
using
reddits
and
we're
using
a
library
that
we
developed
called
Jonas,
which
is
a
designer
handle,
reticent,
failover
scenarios
and
we're
still
hanging
amazon
on
the
same
side.
Servers.
C
So
we
made
the
decision
to
move
to
Sandra.
For
a
few
reasons,
a
big
one
were
the
operational
benefits,
so
has
a
lot
of
moving
pieces
and
we
have
a
really
small
dev
ops
team,
so
the
Mongo's
process,
config
servers,
shards
replica,
sets
there's
just
a
lot
of
just
stuff
and
a
lot
of
different
things
that
can
break
along
the
way.
So
for
us,
we
were
very,
very
attracted
to
the
idea
of
Cassandras
having
one
type
of
node,
and
it's
just
the
data
node.
You
can
query
any
node
which
we
love.
C
We
also
really
liked
that
we
would
have
a
better
understanding
of
how
the
data
would
be
laid
out
on
disk.
Specifically,
we
really
liked
the
law
of
structured,
merge
Street,
which
means
that
we
can
get
really
fast
rights
with
Cassandra,
and
we
know
that
our
data
is
going
to
be
structured.
We
can
have
it
be
structured
in
wide
rows
which
we'll
get
into
in
a
little
bit,
which
will
make
sure
that
our
reads
are
extremely
fast.
C
We
love
cql
three.
We
come
from
a
database.
Most
of
us
come
from
a
relational
database
background
and
c
ql
3
makes
it
easy
to
transition
from
a
relational
database
over
to
cassandra,
and
we
were
really
looking
for
something
that
we'd
be
able
to
have
in
the
long
term.
So
Cassandra
scales
linearly.
So
you
add
another
node.
You
get
that
much
more
throughput
to
your
cluster,
which
is
really
awesome
for
us
and
the
fact
that
it
supports
multiple
data,
centers
right
out
of
the
box.
C
B
Also,
exchanges
had
a
lot
fewer
question
marks
about
how
we
would
you
know
scale
our
app
as
the
application
grew
so
now
we're
something
bit
about
the
migration
and
the
mechanics
of
actually
how
we
went
about
moving
our
data
out
of
enix
andhra
because
it
was
kind
of
tricky.
So
our
goals
for
running
for
immigration
was
dead,
zero
downtime.
We
did
not
want
a
situation
where
we
were
staying
a
full
two
o'clock
in
the
morning,
shutting
out
of
sight
running
migration
scripts
and
starting
everything
back
up
and
hope
that
everything
went
well.
B
We
wanted
to
run
things
well
enough
to
where
we
can
just
run
the
migrations
during
the
day
while
people
were
using
the
site
and
not
have
any
downtime
the
other.
The
other
goal
was
to
have
no
loss
of
performance.
For
obvious
reasons,
we
didn't
want
the
migration
to
degrade
the
performance
of
the
site,
so
this
is
a
an
overview
of
what
our
migration
and
strategy
looks
like.
B
Basically,
what
we
would
do
is
we
would
make
a
branch
off
a
master,
and
the
first
branch
would
basically
mirror
all
rights
into
Cassandra,
so
the
size
was
still
running
on,
but
every
time
that
a
manga
document
was
saved,
a
corresponding
cassandra
row
was
saved
into
Cassandra
or
multiple
rows,
and
so,
let's
see
yeah
so
and
then
we
have
a
migration
script
that
was
mirror.
That
would
basically
write
all
of
the
remaining
data
into
Cassandra's.
B
So
by
the
time
the
migration
scripted
run,
we
had
a
branch
in
production
that
was
basically
ran
off
and
it
would
but
but
it
would
mirror
all
this
riots
into
Cassandra.
So
then
the
second
phase
of
this
was
the
read
branch
and
the
read
branch
just
switched
out
from
Mungo
to
Cassandra,
so
we
just
deploy
destruction
and
the
reeds
would
just
automatically
switch
over
from
Ron
lift
to
Cassandra.
The
is
kind
of
quarter
point
out
that
we
tackled
one
component
at
a
time,
so
we
didn't
try
to
do
a
whole
bunch
of
stuff
at
once.
D
B
Did
this?
Because
you
know
we,
there
are
a
few
things
we
found
along
the
way
that
you
know
when
we
were
doing
the
right
branch
doesn't
really
make
sense
with
a
reed
branch,
but
the
important
part
is
that
by
the
time
the
right
branch
was
in
production.
We
already
had
the
reed
branch
ready
to
go
and
we
are
knew
that
it
worked.
So
as
soon
as
the
migration
script
is
done,
we
deploy
read
branch
and
we'd
be
opting
out,
but
for
that
component.
C
It
doesn't
have
a
the
range
of
joins
and
aggregations
that
CQ
of
that
SQL
does,
but
essentially
it's
just
a
really
really
convenient
way
to
clear
your
data
in
Cassandra
1.2
they
added
collections
which,
if
you're,
coming
from
a
background,
you
probably
use
a
lot
of
I'll,
see
you
have
sets
lists
and
maps
and
they're
really
really
convenient
awesome.
We
actually
use
them
all
the
time.
D
C
Also
have
bachelors
bachelors
are
really
great
for
us,
since
we
end
up
doing
a
lot
of
rights
and
we
don't
necessarily
want
them
to
be
over
a
large
number
of
requests.
So
BAPS
queries
have
been
extremely
performing
for
us
and
we
absolutely
love
them,
use
them
all
over
the
place,
and
then
we
have
clustering
keys.
So
we're
going
to
get
into
the
details
of
coaching
keys
next,
essentially,
clustering
keys.
C
B
So
that
brings
us
to
the
Sandra
data
structure,
so
the
if
you
be
using
a
standard
all
you
probably
know
that
about
this,
but
since
this
is
a
talked
about
migrations,
we're
assuming
that
there's
people
out
there
that
are
still
evaluating
a
switch
to
Cassandra
and
so
we're
just
going
to
briefly
cover
how
your
data
is
stored.
This
is
really
important
to
understand.
You
start
designing
your
tables,
so
I
think
everyone
seems
this.
B
D
B
C
To
kick
off
kind
of
the
idea
behind
tql
there's
a
simplified
version
of
our
messages
table
so
we'll
get
into
kind
of
how
this
is
laid
out
on
a
disk
in
a
sec
but
effectively.
What
we
have
here
is
within
a
message.
We
have
a
message:
ID,
we
have
an
author,
we
have
the
text
of
the
message
and
we
have
lights
so
from
the
grid.
You
can
see
that
each
one
is
laid
out
in
its
own
row,
very,
very
similar
to
how
a
relational
database,
how
you
view
this
to
from
a
very,
very
simple
perspective.
C
Dql
is
a
lot
like
SQL
and
that
your
table
is
going
to
be
that's
pretty
much
the
same.
The
main
difference
is
that
each
of
your
msgs
that's
created
they're,
not
going
to
be
stored
necessarily
anywhere
near
each
other.
There's
no
guarantee
effectively.
It
depends
on
where
it
falls
in
the
hash
table.
So
if.
C
B
B
Key
ash
also
point
out
is
that
while
we
have
an
integer
for
the
reply,
ID
just
for
simplicity
sake
in
our
system,
the
reply
these
are
actually
time
uuid
and
what
that
does
is.
It
will
actually
sort
the
replies
on
disk
in
order
that
they
were
received
so
to
pull
out
the
list
replies
for
a
message.
We
just
take
a
slice
of
this
long,
visible
row
and
we
get
the
all
the
replies
to
this
message.
Back
and
they're
already
sorted
so
yeah
effectively.
C
To
add,
on
a
little
bit
to
live
like
that
effectively,
what
it
does
is
in
our
scenario
with
100
machines.
If
you
have
100
replied
to
a
single
message
and
you
want
to
get
all
those
replies,
it
basically
means
that
Cassandra
is
only
going
to
have
to
access
the
data
on
one
of
those
machines.
So
it
is
extremely
fast,
and
this
is
the
pattern
that
we
end
up
using
it
a
lot
of
cases.
B
D
B
B
It's
so
now
we're
talk
about
how
we
modeled
our
data
and
the
differences
between
and
Cassandra.
So,
obviously,
the
document
store
and
Sandra
is
a
key
column.
Value
store,
like
we
just
talked
about
one
of
the
things
that
we
had
been
using
throughout
the
application:
a
lot
worthy
mongos,
DB
reps,
which
is
kind
of
its
equivalent
of
a
foreign
key.
B
So
one
of
the
big
points
that
people
always
talk
about
when
they
start
about
modeling,
your
data
in
Cassandra
is
to
structure
your
tables
as
a
materialized
view
of
the
queries
you
intend
to
run
against
it
with
our
DBMS
is
typically,
you
start
with
third
normal
form,
and
then,
if
you
need
to
do
normalize
for
performance,
you
do
that.
But
best
practice
is
to
structure
your
data
in
third,
normal
form
with
cassandra.
B
C
Know
that
pretty
much
that
pretty
much
sums
it
up
I
mean
effectively
you
just.
You
really
just
have
to
admit
that
the
fastest
way
to
pull
out
your
data
from
the
database
is
to
do
a
single
query,
which
has
all
the
data
that
you
need
in
it
and
it's
extremely
effective.
There
is,
of
course,
a
tipping
point
which
becomes
impractical
to
copy
everything
everywhere,
so
you
definitely
have
to
kind
of
use
good
judgment
and
figure
out
when
that
makes
sense
it
when
it
does
right.
B
D
B
C
C
C
Sorry,
user,
ID,
message,
ID
and
the
actual
message
itself
and
we've
declared
the
message
ID
to
be
a
clustering
key
so
effectively.
What
that
means
is
each
user
has
one
row
that
has
a
list
of
messages
and
because
we're
using
the
time
uuid,
which
is
a
uuid
uuid
one
which
has
the
timestamp
embedded
into
it
all
the
new
stuff.
C
It
will
be
sorted
in
order
of
the
messages
that
they
came
in
so
essentially
we
can
just
take
a
slice
of
the
end
of
the
row
and
everything
is
really
really
fast
and
reliable
and
predictable,
and
we
considered
reddit
for
this
at
at
one
point.
But
with
our
goal
going
to
multiple
data,
centers
reddit
becomes
a
bit
of
a
problem
if
you're
relying
on
it
as
your
primary
data
store,
it
doesn't
really
have
it's
just
not
the
right
tool.
If
you're
going
to
have
a
Europe
data
center.
B
Tql
three
object
row
mapper,
we
developed
it
here
and
it's
open
source
so
go
check
out,
CTL
engine
org,
if
you're
using
Python
and
basically
it's
it's
essentially
an
ORM
for
cql,
and
it
exposes
your
cql
tables
as
Python
classes
and
it'll
Mac
your
columns
to
properties
on
the
class,
and
it
will
also
build
your
cql
queries
for
you.
So
this
is
made
working
with
cql.
You
know
pretty
evening,
okay,
so
all
right.
C
So,
since
moving
to
Cassandra
we're
extremely
happy
with
it,
all
of
the
things
that
we
were
expecting
operational
operationally
have
been
true.
We
haven't
had
any
problems,
we've
scaled
up
to
a
ten
node
cluster,
doing
over
a
hundred
thousand
queries
per
second
reads,
and
it's
performed
beautifully,
which
is
been
amazing
for
us.
Each
time
we
needed
to
add
a
node,
it
was,
it
worked
perfectly
and
we
literally
just
fire
up
a
machine.
It
would
join
the
cluster.
We
tinker
with
the
token
ring
a
little
bit
and
everything
would
work
great.
C
It's
been
really
really
easy
to
build
new
features
on
it.
It
takes
a
little
bit
of
planning,
make
sure
that
you're
going
to
have
your
Rose
structure
the
right
way
and
you're
going
to
query
them
efficiently,
which
at
first
can
be
a
little
confusing
because
you
might
be
used
to
storing
your
data
in
just
a
convenient.
This
is
my
object
form,
whereas
with
Cassandra,
like
I,
said
we
doing
materialized
views,
but
once
you're
used
to
that,
it's
extremely
easy
to
build
new
features,
and
one
thing
that's
been
really
great
and
extremely.
D
C
C
C
D
B
Next,
we
found
that
you
should
use
secondary
indexes
sparingly
and
really
understand
how
they
work
and
what
they
do
when
you
decide
to
use
them.
I
know
it's
kind
of
tempting
to
put
an
index
and
everything,
but
it's
actually
not
usually
the
best
thing
to
do
if
you're
running
queries
that
don't
include
a
partition,
key
you're
going
to
the
query
is
basically
going
to
hit
every
note
in
your
closure,
which
one
of
would
also,
I
think,
we'd
recommend
using
looking
into
using
a
search
engine
like
the
elastic
search
or
solar
for
ad-hoc
queries.
B
I
know:
data
sex
Enterprise
comes
with
a
variation
of
solar
that
runs
on
Cassandra,
but
basically
you
know
we
we
use
Cassandra
for
our
our
industrial
strength,
queries
that
we're
running
all
the
time,
but
there
are
other
queries
that
we
have.
You
know
have
a
bunch
of
weird
parameters,
and
strange
filter
rings
that
we
have
to
do
on
it
and
so
for
stuff,
like
that,
it's
really
helpful
to
have
a
search
index
to
check
where
against
as
well
so
yeah.
This
brings
us
to
the
end
of
the
presentation.
Here's
our
contact
info.
A
A
Jon
and
blake
buckle
your
seatbelts.
There
be
a
torrent
coming,
but
I
always
like
softball
questions.
So
John
asked
our
slides
for
this
available
and,
yes
is
the
answer.
We
will
post
those
within
about
24
hours
along
with
the
recording
of
this
webinar,
and
we
will
send
that
out
by
it.
You'll
get
an
email
notification
we're
alive,
but
that
will
be
published
on
planet
Cassandra.
B
B
We
try
to
be
a
bit
more
explicit
about
what
exactly
most
of
it
most.
The
changes
were
regarding
relationships
between
objects,
so
probably
the
biggest
difference
is
that
allows
you
to
just
have
these
references
to
arbitrary
documents
and
with
the
same
with
the
Cassandra,
you
don't
have
that
available.
So
we
would
be
a
bit
more
explicit
about
storing
IDs
of.
B
C
In
addition
to
that,
I
mean
more
specifically
on
the
embedded
document
side
of
things.
A
lot
of
cases
collections
proved
to
be
very
helpful
and
in
the
case
where
we
needed
complex
documents,
we
actually
ended
up.
Writing
an
embedded
document,
type
that
we
use
internally
qol
engine
yeah
for
CQ
engine
and
if
we
can
store
arbitrary
documents
inside
cql
tables.
Now
in
a
lot
of
cases,
if
in
some
cases
that
might
work
for
you
in
some
cases
that
might
not
it.
C
B
B
C
With
especially
with
taking
into
account,
you
can
use
wide
rows
effectively,
you
can
store
all
your
embedded
documents
in
a
single
ro
by
using
clustering
keys
and
that's
generally,
what
we
did
most
of
the
time.
Instead
of
trying
to
pack
really
really
complex
nested
structures
inside
a
single
logical
row,.
A
C
So
we
have
two
clusters
right
now:
one
is
a
smaller
three
node
cluster
and
that
one's
got
about
twenty
or
thirty
gives
a
data
in
it
and
we're
doing
only
a
few
thousand
reads
and
writes
a
second
on
it.
The
second
one
is
a
ten
node
cluster
and
we're
actually
using
the
Amazon
heiio
boxes
and
we're
doing
a
hundred
thousand
reads
a
second
on
around
a
hundred
and
fifty
gigs
of
data.
C
C
We
we
ended
up,
noticing
degradation
of
performance
on
the
manga
side
of
things,
and
there
were
some
garbage
collection
issues
where,
when
we
delete
data
it
didn't
actually
free
up
any
memory.
So,
unfortunately,
for
us
we
were
definitely
left
with
a
bit
of
a
bad
taste
our
mouths,
when
our
cluster
would
even.
D
C
A
This
is
preston
is
asking.
I
hear
that
secondary
indexes.
Mongo's
stronger
suits
any
comment
on
that.
In
some
cases,
I've
heard
organizations
tues
of
Cassandra
because
of
secondary
index
related
and
querying
possibilities.
So
if
you
could
just
talk
about
your
experience
briefly
with
secondary
indexes
and
and
then
just
reiterate,
sort
of
how
you've
adjusted
moving
forward
with
Cassandra
well.
B
B
We
had
a
table
that
would
have
a
the
user
ID
as
a
partition,
key
the
team
ID
of
the
clustering
key,
and
so
we
could
just
quickly
just
read
out
the
entire
row
and
that
that's
all
one,
that's
called
most
of
the
problems
that
not
having
those
index
of
salt
and
then,
like
I,
mentioned
earlier
for
some
of
the
more
complex
queries
we
would
complement
Cassandra
with
elastic,
search
and
be
querying
abilities
of
that
are
awesome.
I.
You
know
it's
just
incredible
being
queried.
You
can
do
the
last
research.
A
B
Not
that
I'm,
aware
of
and
I
would
probably
not
want
to
use
them
existed
that
just
kind
of
seems
a
little
scary
to
me.
You
know,
I
would
prefer
to
have
like
a
better
understanding
of
how
everything
was
working
and
also
you
know,
understand
us
about
it
to
spot-check
things
and
make
sure
that
everything
is
working.
The
way
that
is
intended,
yeah.
C
I
think
I
think
one
of
the
things
that's
really
important
to
know
about
Cassandra.
Is
you
in
really
any
database
I
think
kind
of
masked
this
by
by
giving
a
lot
of
different
operations,
which
I
think
I
think
results
in
a
good
amount
of
technical
debt
that
you
don't
actually
see
until
you
reach
a
tipping
point
and
then
it
becomes
a
massive
problem.
C
You
need
to
understand
your
data
and
you
need
to
understand
your
database,
so
whichever
database
you're
using
like
you
really
need
to
become
like
very,
very
familiar
with
how
things
are
stored
on
disk,
what
query
plans
are
actually
being
executed
and
it
you
know
everything
that
happens
from
from
the
point
of
like
writing.
Your
data
in
and.
D
C
Then
hit
this
point
where
it
just
doesn't
work
anymore
and
their
system
is
just
a
mess
so
and
I
and
I've
experienced
that
previous
companies
as
well.
So
it's
definitely
it's
tempting
to
be
able
to
just
like
throw
as
many
index
as
you
want
on
things.
But
in
the
end,
you
have
to
understand
your
data
like
there's
just
no
getting
around
that.
A
Okay,
thank
you
very
much,
and
you
know
what
I'm
thinking
is
you're
talking
there
seems
to
be
enough.
Interest
in
the
actual
migration
would
be
great
to
collaborate
on
a
broader
paper.
That
was
a
real
step
by
step.
How
you
did
it
because
I
think
a
lot
of
people
will
go
looking
for
some
sort
of
automation
square
feet.
You
make
a
you,
make
a
really
good
point
on.
You
know
doing
it
manually
how
you
did
it
so
John
is
asking
a
question
here
and
I'm,
hoping
you
can
help
him
he's
really
looking
for
help.
B
C
I
mean
that
may
be
something
that
better
take
off
line.
I
mean
if
there's
like
a
github
repo
that
maybe
we
could
look
at
with
some
like
a
readme
that
you
know
has
a
little
bit
of
detail
to
what
what
we're
trying
to
do.
I
think
that
would
be
very
helpful,
but
without
it
it's
kind
of
it's
almost
impossible
for
us
to
get
an
answer.
Yes,
do
you
be
kind
of
wild.
B
A
A
B
A
C
We
will
definitely
be
migrating
to
two
point.
Oh
there's.
Actually,
a
few
really
really
good
features
into
point,
0
that
we
find
immediately
useful,
there's
some
check
and
set
operation.
There's
some
trigger
support
and
I
know
that
there's
been
a
lot
of
improvements
to
c
ql
and
in
performance
around
tql.
So
that's
kind
of
our
like
roadmap
over
the
next
few
months,
yeah.
A
Great
and
Cassandra
20
drops
on
Tuesday
of
this
week,
so
you
know,
look
for
got
releases
coming
out
pretty
rapidly.
You
know
that
gets
firmed
up
so
anything
else,
so
Cassandra
enthusiast's
anything
else
that
you
considered
as
an
option
he's
asking
specifically
was
nuodb
considered,
as
it
offers
acid
properties
like
a
relational
database
but
much
more
scalable.
So
if
you
could
just
talk
a
little
bit
about
you.
A
C
Kind
of
think
of
how
we
I
think
I
think
the
decisions
to
use
Cassandra
really
came
about
as
an
appreciation
for
its
data
model
and
for
its
masterless
configuration
for
us
operationally.
Cassandra's
really
really
easy
to
use
like
I
said
in
the
slides
and
as
far
as
the
data
model
goes
like
it,
it
really
made
sense
to
us,
so
it's
kind
of
like
I'm,
not
I,
think
the
alternatives.
C
You
know
the
alternatives
for
us
like
or
let's
go
back
to
a
relational
database
world
which
I
really
wasn't
a
big
fan
of,
not
because
I
have
a
problem
with
SQL
I,
actually
love.
It
I
think
it's
a
really
expressive
language
and
you
can
do
some
amazing
things
with
it,
but
we
we
needed
certain
performance,
characteristics
and
I
wanted.
A
C
To
be
stored,
a
certain
way
so
Cassandra
just
did
all
that
and
I
knew
it
was
stable
and
we
knew
it
was
just
an
all-around
great
database.
So
pursuing
like
smaller,
like
niche
databases
like
I,
don't
know
anyone
using
new
OGD
and
honestly
I
hadn't,
even
heard
of
it
before
today,
not
not
to
say,
there's
anything
wrong
with
it,
but
for
us
to
try
and
evaluate
every
no
sequel
or
new
sequel
database
was
just
it.
Just
would
have
taken
a
ton
of
time
and
wasn't
really
practical.
A
D
C
Of
our
so
one
of
one
of
the
things
that
we've
done,
as
we
mentioned
and
the
slides
is
we
build
out
all
the
we
build
up,
different
views
within
Cassandra.
So
again,
I
think
this
comes
back
to
the
mindset
of
like
people
coming
from
a
relational
world
or
coming
from
like
the
mongrel
world,
where
you
store
your
document
and
you
can
query
on
it
in
10
different
ways,
whereas
with
Cassandra
you
store
your,
you
store
your
data
10
different
ways
and
use
each
of
the
different
tables
to
query
on
that.
D
A
Okay,
great
so
many
more
questions
coming
in
so
well,
we'll
try
and
get
through
as
many
as
we
can
almond
is
asking
one.
Thank
you
for
the
presentation.
Can
you
elaborate
on
the
scholar
Cassandra
API?
How
stable
is
it?
Is
there
an
active
community
around
it
and
does
it
implement
as
much
functionality
as
the
Python
Napa
fella.
B
D
C
D
A
This
is
an
interesting
one.
It's
probably
worth
spending
a
couple
of
minutes
on,
but
you
talked
about
you
know.
Your
options
were
to
go
back
to
a
relational
database.
What
was
the
original
prompt
not
to
use
a
relational
database?
What
did
you
you
know?
Why
did
you
choose
at
a
time
or
what
or,
if
it
predated
you?
Why
was
that
decision
made
in.
C
Our
cases,
though,
we
wanted
a
lot
of
flexibility
around
the
schema,
so
some
of
the
decisions
have
been
actually
made
before
lake
and
I
and
joined
the
team.
Neither
of
us
are
particularly
wild
about
mondo
to
begin
with,
but
I
think
I
think
it
was
the
flexibility
within
with
with
documents
that
that
worthy
like
driving
factor.
C
D
C
A
B
We
just
used
the
python
driver
and
basically
we
since
we're
using
cql
engine,
we
will
extend
like
the
save
method
to
automatically
index
the
documents,
but
it's
worth
it
elasticsearch
is
has
a
slight
delay
just
in
terms
of
how
long
it
I
want
to
take
the
indexing
in
practice.
It's
not
a
big
deal
really.
D
D
C
D
C
C
A
B
C
Support
so
I'm
thinking
this.
This
has
to
do
with
the
wide
like
looking
at
Cassandra
from
like
a
thrift
perspective
where
you
actually
have
to
look
at
the
column
name
and
define
it
manually.
One
of
the
reasons
why
we
like
to
teach
you
all
three
so
much
is
because,
when
you
declare
that
clustering
key
Cassandra
handles
the
column
names
for
you
so
effectively,
you
only
have
to
worry
about
illogical
names
of
the
columns
and
not
how
they're
actually
stored
on
disk.
So
in
one
of
our
slides,
we
have
an
illustration
we're
using
the
clustering
key.
C
It
actually
gets
pretended
to
the
column
name
and
that's
how
it's
that,
how
it
fixes
that's,
how
it
deals
with
the
column,
sort
order
and
like
weird
collisions,
mean
we
just
didn't.
We
didn't
really
want
to
have
to
deal
with
that
and
see.
If
you
all
three
made
it
really
easy
for
us
to
control
the
mapping
of
our
rows.
D
A
Okay,
thank
you.
This
one
sounds
like
it's
coming
from
a
user.
Currently
with
MongoDB,
we
encounter
a
number
of
issues
dealing
with
replication
delayed
you
to
read
from
secondaries
Cassandra,
says
data
and
distributed
memory
tables
at
first
have
you
encountered
similar
replication
delay
issues
with
Cassandra.
B
We
have
not
noticed
been
clear,
replication
delays
so
sure
and
I've.
You
know
also
tangible
when
you
run
a
query
against
the
Cassandra
cluster.
It
will,
if
it'll
it'll,
query
all
the
owners
of
that
data.
So
if
you,
if
you
had
a
node
and
obviously
the
data
should
be
replicated
it
about
at
least
two
other
nodes,
it
will
resolve
that
data
after
it's
on
the
back,
so
its
commander
will
heal
itself.
If
there
are
values
are
contested
between
different
machines,
yeah.
C
D
C
To
use
quorum,
which
is
the
default
and
quorum,
is
just
the
number
of
nodes
that
need
to
hold
that
data.
/
2
rounded
up.
So
if
you
have
3
3
nodes,
you
only
need
to
to
be
a
quorum
so
effectively.
You
know
that
if
you
write
something
two
nodes,
if
he's
going
to
get
it,
so
even
if
you
Cleary-
and
you
try
to
try
to
read-
and
then
you
query
the
third
node
you'll,
actually
it
will
resolve
the
differences
via
quorum.
C
So
you
kind
of
get
around
that
like
replication
problem
and
if
you
want
you
can
use
query
consistency,
all
what
you
mean
that
you're
like
guaranteed
to
get
the
data
that
was
written
and
the
nodes
can't
be
out
of
sync
and
if
they
are
for
some
reason
out
of
sync,
as
Blake
said,
it
will
get
resolved
immediately
and
you'll
get
your
data
back.
So
the
consistency
is
tunable
effectively.
It
depends
on
your.
A
C
A
And
then
you've
addressed
this
in
in
different
ways,
so
I'm
just
going
to
recommend
that
if
you
want
a
blog
post
or
food
for
thought,
there
are
several
questions
here
with
different
flavors
of
the
same
ladies
Cassandra
HBase.
Why
did
you
choose
Cassandra
of
Oracle?
Why
did
you
choose
Cassandra
over
couchbase?
Why
did
you
choose
Cassandra
versus
different
donkey
document
data
store?
So
obviously
a
very
hot
topic-
and
you
know
I
know
you
guys
do
some
blogging
and
stuff
so
maybe
worth
fleshing
out
your
thought
process
that
yeah
definitely.
C
As
far
as
a
space
goes
well,
we
actually
considered
that,
but
for
us
kind
of
I
have
the
same
operational
issue
with
with
HBase
leading
to
our
ops
team.
Is
me
part
time
and
one
other
guy,
and
we
just
don't.
We
just
don't
have
the
time
to
deal
with
like
a
Hadoop
job
tracker
and
like
all
the
things
that
you
need
to
make
like
the
HBase
world
like
happen
so
again,
like
Cassandra,
with
its
masterless
just
architecture
just
made
sense
for
us,
so
we
didn't
strongly
consider
HBase.
C
A
C
A
A
B
We
will
typically
have
a
look
there's
a
few
different
models
that
we
use.
First,
we'll
have
a
like
a
master
model
and
that
model
will
maintain
internally
the
other
views
of
the
data
as
well
as
querying
it.
So
there's
not
a
lot
of
leakage
of
functionality
over
the
place.
You
have
one
class
for
dealing
with
it.
Oh
are.
A
D
B
C
Over
before
switching
to
reach
to
Cassandra,
but
because
of
the
because
of
the
branching
strategy,
since
we're
doing
rights
first
effectively,
we
knew
that
the
all
the
new
data
would
be
in
Cassandra
and
literally
the
migration
script
was
just
to
catch
up
with
all
the
old
data.
So
once
that
was
done
all
of
our
historical
data.
For
that
one
thing
that
we
were
migrating
existed
in
both
places
right
and
as.
C
A
B
B
A
B
C
I
mean
it
ultimately
is
like,
as
Blake
mentioned
it
was,
do
we
have
staff
feel
like
we
put
Betsy
and
we
actually
use
librado,
which
is
great,
and
we
effectively
just
throw
stabbed
around
everything.
So
we
we
saw
I
think
the
biggest
case
that
we
saw
one
of
the
reasons
why
we
wanted
to
move
so
bad
was
our
message
string
with
taking
over
for
seconds,
which
is
just
insane
and
after
switching
everything
into
Cassandra,
we've
got
it
down
under
100
milliseconds.