►
Description
Title: Introduction to Apache Cassandra 1.2
Details: Join Aaron Morton, DataStax MVP for Apache Cassandra and learn the basics of the massively scalable NoSQL database. This webinar is will examine C*'s architecture and its strengths for powering mission-critical applications. Aaron will introduce you to core concepts such as Cassandra's data model, multi-datacenter replication, and tunable consistency. He'll also cover new features in Cassandra version 1.2 including virtual nodes, CQL 3 language and query tracing.
Speaker: Aaron Morton, Apache Cassandra Committer
Aaron Morton is a Freelance Developer based in New Zealand, and a Committer on the Apache Cassandra project. In 2010, he gave up the RDBMS world for the scale and reliability of Cassandra. He now spends his time advancing the Cassandra project and helping others get the best out of it.
A
Do
welcome
everyone
to
this
week's
edition
of
cassandra
community
webinar
series
delighted
to
have
with
me
today.
Aaron
Morton
Aaron
is
a
Cassandra
committer
and
he
is
based
in
New.
Zealand
he's
been
having
a
couple
of
issues
dialing
in
today,
but
Aaron.
Let's
just
test
your
audio
as
we
didn't
have
a
chance
before
hand.
A
We
can
hear
you
loudly
and
clearly
so
just
before
we
get
started
a
couple
of
housekeeping
items
first
off.
Please
do
not
forget
that
this
is
one
of
a
series
of
webinars
so
upcoming.
We
have
a
couple
on
data
modeling
and
then
on
jun,
11th
and
12th.
We
have
the
Bay
Area
Cassandra
summit.
It
is
the
premier
Cassandra
summit
annually
and
Aaron
is
actually
going
to
be
presenting
a
couple
of
sessions
there.
So
if
you
like
what
you
hear
today,
please
make
sure
to
book
your
tickets.
A
A
Usually
on
these
webinars,
we
reserve
about
10-15
minutes
at
the
end,
to
tackle
any
questions
that
you
have.
Please
use
the
Q&A
panel
inside
of
WebEx.
Ask
your
question
there
and
at
the
end,
I
will
go
through
those
and
I
will
read
them
out
to
Aaron
and
we
will
get
through
as
many
as
we
can.
So
I
will
pass
the
ball
to
you.
Aaron.
B
B
Thanks,
Christian
and
good
morning,
good
afternoon,
everyone-
hopefully
now
you
can
see
a
slide
that
says,
introduction
to
Apache
Sandra
those
Christian
said
my
name
is
Aaron
Morton
I'm,
a
middle
with
Apache
Cassandra
I've,
been
on
using
the
project
for
a
bit
over
three
years
now
and
I'm,
a
datastax
MVP
for
Cassandra
as
Christians
ends.
Well,
because
the
summit
is
coming
up
this
year
last
year
we
had
one
day
today
is
this
year.
It's
twice
as
big
two
days.
The
discount
code
is
on
the
screen
there
again
SF
summit,
25
I'll
be
doing
two
talks.
B
The
first
will
be
on
Cassandra
internals.
This
is
a
talk.
I
did
at
Apache,
calm
in
February
in
Portland,
where
I
go
through,
how
Cassandra
works
internally,
really
a
deep
dive
on
the
code
base,
and
my
second
talk
is
titled
in
case
of
emergency
break
glass
and
that
one
I'm
going
to
go
through
all
of
the
things
that
I
see
as
a
professional
Cassandra
consultant
the
problems
that
I
solve
for
people
on
the
user
list
and
try
to
distill
those
down
to
something
that
can
help
you
as
an
operator
or
a
developer
of
Cassandra.
B
Also
this
year,
datastax
are
starting
the
datastax
academy,
which
is
a
certification
program
for
Cassandra
and
during
the
summit
you'll
be
able
to
get
certification
for
free
after
the
summer.
Of
course,
you'll
have
to
pay
for
it.
So
it's
another
great
reason
to
attend
the
summit
this
year
getting
started
on
what
we're
going
to
do
today.
B
Let's
start
with
a
brief
overview
of
cassandra
and
how
we
got
to
where
we
are
today,
we'll
look
at
look
at
how
it
works
as
a
cluster
of
machines,
collaborating
together
how
the
nodes
do
their
jobs
individually
and
in
a
bit
of
a
look
at
the
data
model.
As
christian
said
earlier,
there
are,
there
is
an
upcoming
talk
on
data
modeling,
which
I'm
sure
will
go
into
a
lot
more
detail.
Will
today
so
briefly,
Cassandra
was
started
at
facebook
when
they
were
dealing
with
inbox
search.
B
B
B
If
you're
looking
to
understand
where
Cassandra
came
from
in
terms
of
technology
and
the
thing
that
inspired
it
because
everything's
built
on
previous
ideas,
the
big
ideas
that
inspired
Cassandra
were
a
paper
that
came
out
from
google
called
big
table
in
2006,
which
talked
about
a
log
structured
storage
engine
like
Cassandra
users
and
a
column
family
or
in
Peter
data
model,
which
cassandra
is
inspired
from
as
well.
There's
also
a
pay
for
the
next
year
from
Amazon
about
their
dynamo
system,
which
described
these
terms.
B
B
I
think
there's
also
a
story
there
of
scale
for
people
who
just
have
hundreds
of
gigabytes
and
don't
like
the
idea
of
storing
hundreds
of
gigabytes
on
a
single
node,
because
it's
sometimes
painful
to
move
100
gigabytes
around
the
data
center
and
there's
also
scale
ideas
around
throughput.
Netflix.
Of
course,
a
few
years
ago
did
a
test
where
they
ran.
1
million
write
operations
per
second
through
a
cluster.
The
next
story
is
operation.
B
If
you
do
suffer
a
failure
for
some
reason
chances
are,
it
won't
affect
any
data
because
we
have
redundancy
built
into
the
system
and
even
in
some
cases
where
you
do
suffer
failures,
it
might
be
only
for
a
certain
small
portion
of
your
data.
And,
lastly,
today
the
model,
not
everything,
fits
well
into
the
relational
database
model
and
the
relational
database
model
in
most
implementations
is
quite
static
and
hard
to
change
in
a
system.
B
Now,
let's
talk
about
how
you
get
a
cluster
of
machines
to
collaborate
together
to
perform
some
tasks?
Imagine
we
have
a
cluster
of
four
nodes
and
we
want
to
store
a
row.
This
row
has
columns,
but
that's
not
really
important.
At
the
moment.
It
has
a
key,
though,
which
is
essentially
your
primary
key,
and
we
use
that
and
that
our
primary
key
in
this
example
is
food,
and
we
can
store
these
this
fugro
anywhere
on
the
in
the
cluster,
with
a
replication
factor
of
three
meaning
that
we
want
to
store
on
three
nodes.
B
The
important
thing
is
to
understand
why
we
choose
knows
one
two
and
three.
So
when
it
comes
time
to
read
it
back,
we
can
find
that
row
in
Cassandra.
We
use
an
idea
called
consistent
hashing
which
allows
us
to
evenly
map
the
keys
to
know.
So
if
we
have
four
nodes,
we
want
them
to
each
have
roughly
twenty-five
percent
of
the
load.
B
B
Our
implementation
of
that
starts
with
an
idea
called
the
petitioner.
The
default
partition
of
prior
to
version
1.2
was
called
the
random
petitioner
and
all
this
guy's
does
is.
He
takes
your
roki.
Apply
the
transformation
in
the
case
of
the
random
petitioner,
that's
an
md5
hash
and
generates
a
thing.
We
call
a
token
in
1.2,
which
is
the
current
version
of
Cassandra.
The
default
is
now
and
pulled
the
murmur
three
partitioner.
It
just
uses
a
different
hash
algorithm
that
the
idea
is
the
same.
B
We
take
our
roki
and
in
this
case,
in
this
example,
we
have
two
keys
that
are
lexa
graphically
close
to
each
other
food
and
food,
and
we
run
them
through
the
partitioner
and
it
generates
some
tokens
which
are
now
essentially
randomly
distributed.
So
you
can
see
now
fuchs
now
orders
before
foo
in,
if
we
order
by
token,
in
my
example
here
to
keep
things
simple,
I'm
going
from
0
to
99,
but
rest
assured
token.
Space
is
a
very,
very
large
space.
B
It's
a
120
bit
integer
and
we
can
think
about
tokens
as
a
number
line,
but
it's
easier
to
think
about
it
as
a
ring.
When
we
do
it
like
this,
we
can
apply
some
type
of
clock.
Arithmetic
to
our
counting.
Here
we
can
say
that
after
we
count
98
99,
the
next
value
is
0,
so
we
have
now
a
continuous
space.
B
The
token
ring,
which
is
easier
to
birth,
to
just
to
break
up
an
end
and
a
range
which
is
what
we
do
prior
version
1.2
we
assigned
each
node
a
token
and
that
allowed
us
to
break
out
the
token
space
and
evenly
distribute
it.
If
we
look
at
no.2
here,
we
can
see
it
has
a
token
range
from
1
to
25,
because
the
token
range
is
starts
with
the
first
value
after
the
previous
tokens,
which
was
zero.
B
So
the
first
value
is
1
and
comes
around
to
know
too,
and
it's
inclusive
at
that
end,
so
the
token
range
is
1
for
25.
Now
we
call
this
the
primary
range-
and
it's
not
a
great
word
to
another
great
turn
to
use,
because
it
implies
apps
that
no
two
is
somehow
a
primary
or
the
master
replicas.
It's
not
it's
just
as
no
other
way
to
really
describe
this
easily.
I.
Rest
assured
that
no
two
should
not
have
any
special
claim
over
that
token
range
other
than
we
can
use.
B
B
In
version
1.2,
we
introduced
an
idea
called
virtual
nodes
and
it's
a
little
bit
more
complicated,
but
have
some
great
advantages,
and
if
you
understand
that
initially
each
node
had
what
token
range
it's
not
that
different.
What
we
do
now
is
we
give
each
node
lots
of
token
ranges
by
default
256,
and
then
they
share
those
around
just
the
same
way
as
we
did
with
the
one
token
range
the
ideas
for
implanting
virtual
nodes
other.
It
makes
it
easier
to
grow
and
shrink
your
cluster
in
more
in
smaller
steps.
B
So
we
can
grow
by
one
and
two
nodes
at
a
time
and
it
makes
it
a
lot
faster
for
us
to
replace
failed
nodes,
and
so
virtual
nodes
are
a
thing
you
can
enable
in
1.2
they're,
not
a
compulsory
idea.
You
can
use
1.2
without
virtual
mode,
going
back
to
our
model
about
how
we
locate
them
node,
whether
it's
virtual
nodes
or
not.
It's
the
same
idea.
We
take
our
rookie
in
this
case
food.
We
run
it
through
our
tichenor.
B
That
gives
us
our
token
in
this
case
90,
and
we
find
the
token
range
that
contains
their
token.
So
and
then
we
find
the
note
there's
the
primary
that
has
that
as
one
of
its
primary
token
Rangers.
So
here
we've
gone
from
foods,
token,
no
tokens
90
and
we
found
mode
one
that
gives
us
one
replica.
But
we
said
we
wanted
to
store
three.
So
we
need
a
process
to
find
all
the
replicas
and
that's
called
the
replication
strategy
and
it's
always
a
simple
way
of
doing
things.
B
And
so
we
have
a
simple
strategy
which
orders
the
nodes
deterministically
based
on
their
tokens
and
then
start
with
the
first
node
that
we
found
and
discounts
around.
So
we
get
mode,
1,
2
3,
that's
our
replication
factor
of
three
and
we're
done.
There's
always
a
complicated
way
to
do
things
and
that's
called
the
network
topology
strategies.
It
allows
us
to
run
a
replication
factor
to
stata
center
and
theta
tender
in
Cassandra
doesn't
have
to
be
a
bricks-and-mortar
facility.
B
B
Sometimes
we
do
it
to
separate
workloads.
We
could
have
one
data
center,
that's
handling
a
transactional
workloads,
that's
facing
your
API
or
your
internet
or
your
website,
and
we
can
have
another
data
center.
That's
facing
an
analytical
work
loads
through
Hadoop
integration
that
allows
your
back
office
team
to
to
query
that
data
and
pull
out
some
important
information
without
interfering
and
without
compromising
what's
happening
with
the
transactional
loads
in
the
multi
data
center
setup.
B
It's
the
same
idea
in
this
example:
I've
got
a
replication
factor
of
three
for
the
West
Coast
DC
and
the
replication
factor
of
two
for
the
East
Coast.
Normally
you'd
run
the
same,
but
this
is
just
to
illustrate
that
we
can
have
different
replication
factors
and
the
idea
is
the
same:
each
in
each
DC
there's
a
token
ring
and
load
assignments
and
we
use
the
same
process
to
find
the
replicas
in
both
locations.
B
But
we
have
to
have
some
way
to
understand
what
is
going
on
there.
How
do
we
know
that
these
nodes
are
in
different
data,
centers
and
even
different
racks,
because
we
can
be
aware
of
the
rack
that
your
nose
is
in
and
make
decisions
based
on
that
and
we
use
a
piece
of
technology
called
the
snitch.
It's
a
configuration
thing,
of
course,
there's
a
simple
snitch,
which
places
all
the
nodes
into
the
same
data
center
and
the
same
rack,
that's
kind
of
handy
to
start
easily,
there's
a
number
of
other
ones.
B
There's
a
configurate
there's
a
property
fire
one.
There
are
ones
that
look
at
the
IP
address
to
decide.
What's
the
rack
and
what's
the
data
center,
all
the
way
up
to
the
ec2
snitch
and
the
idea
of
the
easy
to
snitch
is
that
we
use
the
AWS
region
as
the
data
center
in
Cassandra,
so
uswest
one
and
US
East
one
and
we
use
the
AWS
availability
zone,
which
is
really
a
physical
building
as
the
as
the
Cassandra
rack.
B
Of
course,
we
need
clients,
someone
for
the
talk
to
the
database.
All
modes
and
Cassandra
are
peers,
there's
no
master,
no,
there's
no
name
mode.
There
is
no
nodes
that
do
tasks
that
other
nodes
cannot
but
client
can
talk
to
any
node
in
the
cluster
and
ask
it
to
do
any
job
doesn't
have
to
understand
which
nodes
store
the
data.
B
The
note
that
the
client
talks
to
is
considered
the
coordinator
for
that
request
and
a
client
can
talk
to
any
node
and
it
can
send
one
request.
One
coordinator
and
another
request
to
another
is
to
turn
that
helps
us
understand
who's
running
the
read
or
the
right
this.
So
the
coordinator
goes
through
the
process
we've
talked
about.
It
uses
the
petitioner
and
the
replication
strategy
and
the
snitch
to
find
the
replicas,
and
then
it
send
messages
to
those
nodes
directly
and
to
all
three
at
once
and
wait
asynchronously
for
those
to
return.
B
So
we
don't
have
any
additional
Network
hops
here
note
for
just
sends
messages
to
one
two
and
three
and
wait
for
them
to
return
in
the
multi
data
center
setup.
It's
a
little
bit
different.
We
have
a
local
coordinator
in
this
case
the
note
4
on
the
left-hand
side.
He
sends
those
requests
to
the
local
replicas
for
remote
data
centers.
For
reasons
of
network
efficiency,
we
only
send
one
message
over
to
the
remote
data
center
and
we
create
what
we
think
of
as
a
remote
coordinator,
who
then
forwards
that
message
on
to
other
nodes.
B
They
don't
broadcast
so
to
each
second
anode,
gossips,
2143
other
nodes
and
and
they
gossip
to
other
nodes,
and
so
information
spreads
around
the
cluster.
Just
like
gossip,
when
the
coordinator
talks
wouldn't
sorry
when
the
client
talks
for
the
coordinator
and
asks
its
ascending
messages
off
to
other
nodes,
we
have
to
have
some
way
a
saying.
Well,
don't
wait
forever
if,
if
you
don't
get
back
from
one
of
these
nodes,
maybe
that's
okay.
B
The
way
we
do,
that
is
by
specifying
a
consistency
level,
and
that
comes
across
from
the
client
with
each
request
and
it
tells
the
coordinator
hey,
consider
this
request
to
be
successful.
When
this
many
nodes
get
back
to
you
and
said
they
were
successful,
this
allows
us
to
have
requests
that
can
complete
in
the
space
of
failures.
B
B
But
if
we
were
to
do
a
write
with
a
download
in
this
case,
we
know
the
nodes
is
down
before
we
start
the
request.
The
client
talks
to
note
for
note
for
work
out
that
the
replicas
are
1
2,
&
3,
but
knows
that
three
is
unavailable.
So
we've
got
two
nodes
available.
A
quorum
of
RF
in
RS
3
is
2,
so
we
can
continue
with
the
request
and
send
that
right.
B
Those
four
sources
thing
we
call
the
hinted:
handoff
we're
locally:
it
remembers
the
right
and
that
it's
no
3
missed
it,
and
when
motoring
comes
back
online
it
sends
the
bride
over
to
note
3,
and
that
process
is
throttled
and
managed
and
all
the
nodes
in
the
cluster
do
this.
So
we
don't
overwhelm
no
3
when
it
comes
back,
but
we
get
in
there
and
we
replay
this
right
same
idea
on
the
reading
pass.
B
If
we're
doing
a
read
at
quorum
and
we
have
one
load
down,
we
can
still
do
the
request
and
we
saw
before
node
3
down.
He
missed
that
right.
So
that's
fine.
Those
1
and
2
got
the
right,
so
we
can
read
from
those
and
get
the
last
written
value,
but
what
about
when
those
three
comes
back
online
and
now
most
one
and
two
got
that
right.
That
note
3
didn't
we
have
to
work
out
who
actually
missed
the
right.
B
It
knows
one
and
two
missile
right
and
those
three
got
it
or
was
it
the
other
way
around,
and
we
do
that
by
using
time
stamps
that
are
stored
with
every
column
value.
These
things
are
call
time
stamps,
but
there's
nothing
inherently
time
about
them:
they're,
just
64-bit,
integers
and
by
convention
they
are
micro,
seconds
past
the
epoch.
B
So
in
our
coordinator
on
those
four,
if
it
doesn't
read
a
note,
3
is
back
online
and
the
particular
hint
hasn't
been
replayed
or
something
we
might
have
a
situation
like
this.
You
want
to
read
the
purple
monkey
dishwasher
columns
and
we
read
from
nodes,
1,
2
and
3,
and
they
all
come
back
with
different
values.
B
We
choose
the
value
that
has
the
highest
timestamp.
So
in
the
case
of
the
purple
column,
those
one
and
two
have
cromulent
and
timestamp
10.
So
we
use
that
those
three
didn't
have
a
value.
On
the
monthly
column.
Note
3
has
a
value,
but
it's
time
stamp
is
less,
it's
5
and
the
others
are
10
and
the
dishwasher
column.
No.3
returns
tomato
with
a
timestamp
of
15
and
wanted
to
have
tomato.
B
The
interesting
thing
here
is
we're
not
using
a
quorum
of
nodes
to
vote,
we're
using
a
quorum
of
mode
to
say
that
the
request
was
successful,
we're
using
the
time
stamp
to
choose
the
value.
So
even
though
node
3
was
the
only
know
to
say
tomahto,
it
has
a
hope,
I'm
stamp,
and
so
that's
the
values
we
would
return
to
the
client.
B
Now
this
happened
inside
of
your
read
we
have
to.
We
have
to
do
some
extra
work
here,
so
we're
reading
the
purple
column
and,
on
the
left
hand
side.
You
can
see
nodes,
1
and
2
return.
Prominent
node,
3
returns.
Enki
know
for
would
detect
those
differences
so
and
work
out
the
Delta
between
them
and
work
out
that
node
3
has
to
update
its
value
to
say
cromolyn.
B
It
sends
that
mutation
to
node3
and
it
doesn't
wait
around-
and
this
is
what's
happening
on
the
right
hand,
side
and
it
returns
the
results
to
know
to
the
client.
So
in
this
case
we
don't
really
care
that
those
three
return,
the
wrong
value.
No
three
can
continue
to
turn
the
return,
the
wrong
value,
imagine
that
its
commitments
fall
and
four
and
it's
just
dropping
right,
but
it's
still
returning
in
craigs
values,
the
cluster
as
a
whole,
operating
at
coram
will
consistently
say
that
purple
is
cromulent.
B
What
was
your
thing?
There
is
an
idea
called
strong
consistency
and
defined
in
that
Amazon
dynamo
paper.
This
just
says
that
if
the
number
of
motor
nodes
involved
in
successful
right
plus
the
number
of
nodes
involved
in
a
successful
read,
is
greater
than
the
replication
factor,
then
readers
will
always
get
the
last
written
value.
B
B
We
achieve
strong
consistency
by
using
the
quorum
to
read
and
write
operations,
as
by
far
the
most
popular
way
to
use
Cassandra
and
the
least
surprising
way
you
can
also
have
all
nodes
involved
in
the
reed
and
one
node
involved
in
the
right
or
the
other
way
around.
It
allows
you
to
tune
your
system
a
bit.
There
might
be
some
things
that
are
more
important
to
you
and
then
breeds
might
be
more
important
than
right
or
the
other
way
around.
A
A
A
B
Okay,
sorry
about
that
folks,
yes,
so
achieving
consistency.
We've
seen
the
consistency
level
that
specified
on
the
client
requests
and
we've
seen
hinted
handoff.
We
also
have
a
process
called
read
repair
which
does
extra
work
on
the
Reid
Park,
so
that
we
can
try
to
avoid
having
inconsistencies
during
a
read
and
we
have
a
manual
process
called
Andy.
Entropy
that
is
run
on
the
command
line.
Normally
is
a
scheduled
task
which
repairs
consistency
on
disk,
let's
jump
down
now
to
the
node
and
see
how
this
works
is
what
is
essentially
just
a
fast
database.
B
B
Our
right
path
is
simple
and
a
lot
like
a
relational
database
model.
We
append
to
a
ride
ahead
log
as
the
first
thing
you
do,
and
that
gives
us
our
durability
and
then
the
update
in
memory
structures
that
has
a
fancy
name
called
mem
table.
It's
really
just
a
hash
of
the
columns
and
when
we
take
your
right
request
and
we
update
the
men
table,
we
use
those
things
timestamp,
reconciliation
processes
that
we
saw
before
the
neat
thing
about
our
men.
Pabel
is
that
is
always
in
memory.
B
We
never
have
to
page
in
anything
of
this
to
do
the
update
and
it's
lock
three.
So
it's
very
fast.
We
return
back
to
the
client
and
then
later
on,
we
asynchronous
flush.
This
men
paper
this
just
like
a
checkpoint
process
in
a
relational
database,
and
we
create
files
that
are
tens
or
hundreds
of
megabytes
in
size
painting
on
what's
going
on
and
we
create
new
files.
We
don't
go
in
update
files
and
creating
new
files.
A
B
We
have
one
long
sequential
write
process
rather
than
smaller
right
processes
that
have
to
sleep
seek
around
this
way.
It's
really
well
on
SSD
based
storage,
whether
at
times
this
process
called
right
and
provocation,
which
means
that
writing
a
small
amount
of
data
may
involve
dream
data
out
and
then
right
in
the
back.
So
the
data
is
stored
in
files
that
are
immutable
and
we
call
them
SS
tables
which
just
stands
for
sorted
string
table
and
has
to
do
with
the
internal
structure
of
them
on
disc
you'll
find
several
files.
The
most
important
ones
are.
B
The
data
DB
and
the
star
on
this
slide
is
roughly
going
to
be
the
key
space
from
your
column,
family
name
and
unique
identifier
for
this
at
this
table,
and
it's
on
this
version
formats
and
things.
But
we
have
a
day
to
DB
which
contains
your
actual
rows
and
the
columns
and
the
values
we
have
an
index
DB,
which
is
an
index
of
all
the
rows
in
the
day
dddddd.
So
this
has
the
row
key
and
then
the
the
offset
in
the
data
TV
and
the
filter
component
sifting.
B
The
call
is
known
as
a
bloom
filter,
which
is
a
probabilistic
structure
that
we
use
to
detect
whether
a
particular
Roky,
definitely
those
not
or
may
exist
in
our
data
DVD
component
after
we
run
around
for
a
while
and
created
lots
of
these
immutable
files
on
disk.
We
end
up
with
a
situation
like
this.
We've
got
our
roads
through
row,
but
it's
spread
out
over
several
access
cables,
and
so
the
read
process
now
has
to
piece
this
together
to
come
up
with
a
coherent
value
of
what
we've
got
from
all
these
different
files.
B
B
So
we
look
at
the
read:
we've
got
five
SS
tables
here
and
things
above
the
dotted
line
are
in
memory,
and
so
our
soccer
things
below
the
dotted
line,
our
disk
access.
We
want
to
read
from
SF
table
1
and
we
have
to
read
from
all
these
files
to
work
out
where
the
row
is.
We
go
to
the
bloom
filter.
First
map
says
your
role
might
exist.
B
You
look
at
our
index
sampling,
which
is
in
memory
that
in
memory
samples
of
the
dash
index
BB
component,
which
allow
us
to
skip
to
a
particular
point
in
the
dash
index
CD
on
disk
and
find
the
row
were
interested
in.
So
we
don't
have
to
search
the
whole
thing
once
we've
done
that,
then
we
go
to
the
index
ZB
at
the
bottom,
and
we
do
now
read
and
if
you
look
at
SS
table
3,
you
can
see
the
bloom
filter
kicking
in
doing
its
job.
B
We
look
in
memory
in
this
fast
lookup
structure
and
we
haven't
had
them
looking
further,
so
we
haven't
gone
to
disk
to
find
that
the
road
doesn't
exist
there.
If
you
look
at
SS
table
price,
we
see
the
degenerate
case.
Bloom
filter,
false
positive,
the
bloom
filter
said
your
row
may
need
this
year
mean
they're
tackling
said
it
may
exist,
but
when
we
got
to
look
on
disk
who
couldn't
find
it,
so
we've
wasted
a
bit
of
bio.
That.
B
Everyone
wants
things
to
go
faster,
so
we
have
two
levels
of
patients
in
Cassandra.
We
have
a
key
case
which
patients
things
from
our
index
DB.
When
we
put
this
into
the
picture,
you
can
see
on
SS
tables,
1
and
2.
We
go
through
the
bloom
filter
hit
to
get
a
hit
on
the
key
cash
and
we
skipped
one
disk
access
on
the
index.
Db
file
make
things
go
even
faster.
B
We
have
a
row
case
which
cases
the
entire
row
in
memory
sits
above
all
the
disk
access
and
just
hit
that,
and
your
read
will
be
very
very
fast.
There
are
two
types
of
rotations:
one
is
invalid
in
cash
so
right
to
invalidate
vacation.
The
other
is
a
right.
True
taste:
oh
right,
update
the
patient,
there's
a
cost
to
be
had
for
running
around,
creating
a
new
file
on
disk
every
time
you
want
to
write
something,
and
that
is
that
you
have
to
run
compaction.
B
The
message
at
the
factors:
life
of
the
sort
of
log,
structured
storage,
engine
that
Cassandra
users
in
compaction,
is
a
manual
and
a
continuous
process.
Cassandra.
Does
it
all
the
time
when
it
detects
enough
files
on
disk?
You
can
also
run
it
manually.
If
you
want
to
an
all
compaction
does,
is
it
takes
our
mini
SS
tables
and
creates
one
new
SS
table?
It's
the
same
truth.
We
have
tables
one
two
and
four
you
can
see.
The
new
table
has
all
the
values
that
we
would
use
from
table.
1
2
&
4.
B
If
we
did
a
read,
so
this
reduces
the
number
of
tables
SS
tables
we
have
to
go
to
which
reduces
the
latency
on
the
read
path
and
saves
space
on
disk
quickly.
We'll
talk
about
the
data
model
as
Christian
to
the
subs
of
this
is
not
coming
webinar
on
data,
modeling
I
think
there's
actually
two
in
the
schedule,
so
I
encourage
you
to
attend
those.
B
This
is
just
a
brief
overview
and
cassandra
is
good
at
review
data
from
a
row
in
the
order
that
it's
stored
and
the
order
that
it's
stored
is
by
column
name,
so,
typically,
an
efficient
data
model,
three
normalizes,
the
data
and
users
at
storage
engine
order,
which
means
that
you
have
to
think
about
the
queries
that
you
want
to
run
ahead
of
time.
This
is
different
to
creating
systems
with
a
traditional
RDBMS,
because
you
don't
have
the
complicated
and
quite
capable
query
engine
that
you
would
have
in
something
like
my
sequel
or
SQL
Server.
B
That
would
allow
you
to
send
any
sort
of
query
you
wanted
to
later
on,
because
you
didn't
was
something
you
didn't
realize
that
you
had
to
do
earlier
at
the
moment
and
then
there
will
be
so
not
just
at
the
moment.
There
are
two
API
choices.
Thrift
is
the
API
that
we
had
originally
its
original.
It's
still
fully
supported.
Thrift
is
an
RPC
mechanism
that
was
created
by
Facebook.
It's
used
by
the
clients
that
you
see,
such
as
by
casa
and
Fanny
ax
Hector.
B
This
is
an
sql-like
language,
query,
language
and
data
model
that
introduces
the
ideas
of
tables
and
allow
the
updates
without
their
own
table,
blocking
like
you,
have
alter
table
in
the
database.
It's
useful
if
you've
got
something
like
an
ORM
which
ones
to
interrogate
the
database
to
find
the
schema
and
I'll
be
using
TTL
three
today,
because
it's
easier
to
explain
in
a
slide
deck
like
this.
One
of
the
downsides
of
thrift
is
that
it
looks
a
bit
different
in
each
different
client.
B
Picasso
looks
different
to
Hector,
of
course,
and
had
to
look
different
to
ser
me.
So
it's
a
bit
harder
to
explain
examples
today
using
the
CTL
shell
which,
using
the
binary
distribution,
it's
also
shipped
in
the
package.
If
you
install
by
package,
called
qosh
and
we'll
be
doing
a
Twitter
clones,
which
is
essentially
the
hello
world
of
the
no
sequel
and
thinking
about
our
queries
up
front,
we
want
to
post
a
tweet
to
our
followers,
get
a
tweet
Brightside
e-list
tweets
by
user.
B
Have
a
user
timeline
which
includes
my
tweets
and,
and
my
people
are
holosuite
and
list
followers.
We
start
with
the
key
space,
which
is
really
just
a
name,
speed
container.
It's
the
database-
and
this
is
a
t12
three
statement
to
create
that
you
can
see
it
specifies
the
replication
strategy
in
their
network
topology
strategy.
How
do
you
use
that
by
default
because
it's
a
bit
tricky
to
change
leader
and
we've
only
got
one
day
to
Center
and
only
11
notes,
because
it
was
my
laptop
so
that
set
that
to
one?
B
B
This
skill
is
just
like
and
on
the
database
is
nothing
scary
here,
a
username,
a
password,
a
real
name
and
the
primary
key,
which
equates
to
our
okie
that
we
talked
about
earlier.
We
can
insert
some
values
in
here,
let's
put
in
Fred
and
provide
the
password
and
his
real
name.
So
you
select
that
back
and
see
a
nice
little
display
there.
We've
got
a
table,
everything's
fine,
then
put
Bob
in
and
see
he
doesn't
specify
a
real
name.
We
just
don't
provide
that
in
the
insert
statement,
just
like
normal
SQL.
B
B
We
want
tweet,
and
so
we
have
a
tweet
ID
with
a
big
integer
value,
the
value
that
the
body
of
the
tweet,
the
username
and
the
timestamp
not
not
a
terribly
complicated
table.
We
can
insert
one
tweet
into
there
and
do
a
select
and
get
that
back
here.
Again,
I'm
here
collecting
by
tweet
ID,
because
that's
our
primary
key
and
they
the
model
now
is
a
little
bit
more
expanded.
We've
got
two
tables
now
we're
getting
a
little
bit
more
complicated.
The
user
tweet
table
stores
all
the
tweets
that
I've
sent.
B
We
have
a
tweet
ID
and
username
and
we
look
at
the
primary
key
cause.
We
have
username
and
tweet
ID.
The
first
part
of
the
primary
key.
The
username
is
considered
the
partition
key.
This
roughly
equates
to
the
road
key
that
we
saw
are
now
in
two
previous
examples.
The
second
part
is
considered
the
grouping
columns,
and
these
are
the
things
that
all
the
other
columns
are
grouped
by.
Those
are
not
part
of
the
primary
key.
B
So
on
each
internal
storage
engine
row
identified
by
username,
we
will
have
many
instances
of
this
entities
where
they
will
store
the
username,
the
body
in
the
timestamp,
and
they
will
be
grouped
by
an
ordered
by
the
tweet
IDs.
So
there's
still
one
entity
here,
a
user
tweet
which
is
identified
by
a
primary
key,
which
is
the
username
and
the
tweet
ID.
B
B
If
we
insert
a
second
road
into
the
tweet,
we
can
see
that
when
we
do
a
select
just
by
spread,
they
come
back
ordered
by
the
tweet
ID
tweet
one
and
then
tweet
2,
because
that's
what
the
grouping
columns
do
now
I
can
order
those
in
a
descending
order
we're
just
doing
order
by
I'm.
Not
breaking
that
thing.
B
I
said
before,
where
we
use
the
the
storage
engine
order,
we
can
reverse
the
order,
but
it's
not
efficient
to
come
along
and
say
get
me
all
the
tweets
for
thread
order
by
the
body,
because
we're
not
indexing
on
that.
That's
not
efficient
in
a
relational
database
and
it
won't
be
efficient.
In
Cassandra
we
have
a
timeline
feature:
the
tweets
with
I've
sent
and
the
tweets
that
I
followers
have
sent
I'm,
adding
a
little
bit
more
complexity.
B
So
they
insert
two
rows
using
this
and
then
do
a
select.
You
can
see
that
they
come
back
with
the
most
recent
tweet
OB
highest
number
first
and
that's
what
we
want.
We
want
to
get
the
most
recent
20
tweets
from
this
user.
So
we
looked
at
our
data
model.
Now
we've
added
user
tweets
and
use
a
timeline.
You
start
to
see
a
pattern
here.
The
user
name
is
used
in
the
primary
key
in
most
of
these
tables
and
that's
a
common
pattern.
B
We
have
counseling
catendra,
they
are
distributed
councils,
they
are
high-performance,
they
are
user
places
like
Twitter
to
count
impressions
and
things,
and
you
can
define
a
table
here
called
user
metrics
with
counters.
We
can
use
this
to
track,
how
many
tweets
to
use
attic
sense
or
their
number
of
followers.
You
update
them
with
a
simple
statement
like
this
update
user
metrics,
tweets,
2x,
plus
1,
and
now
it
can
count
how
many
tweets
are
particular
users
sense.
B
Again,
if
you
look
at
our
data
model,
the
user
metrics
has
username
as
primary
key
relationships
are
a
little
bit
trickier.
We
need
two
tables
to
restore
to
store
the
reflective
relationship
of
followers
and
following,
and
we
can
insert
into
following
and
paid
bulb,
is
following
thread,
and
you
turn
into
followers
and
say:
Fred
follows
fred,
has
a
follower
called
Bob
and
of
course
we
you
would
use
these
when
delivering
tweets2
right
into
the
user
timeline.
B
You
select
back
and
see
that
that's
pretty
input
there
and
so
back
to
our
data
model
now
again,
user
name
is
the
primary
key
is
using
lots
of
pay
but
lots
of
tables,
and
this
is
a
common
pattern
that
we
have
where
now
we're
breaking
this
data.
We
have
for
the
user
ups
into
the
tables
settlement,
brief
tour
of
the
data
model.
B
A
B
Counters
do
increments,
so
you
don't
have
to
deal
with
a
read/write,
modify
a
read-modify-write
padne
where
the
client
reads
the
value,
modifies
it
and
write
it
back
and
has
to
race
against
other
clients
doing
the
same
thing
with
encounter.
You
send
the
server
and
take
increment
this
by
one,
and
that
is
an
atomic
operation
on
the
server
great.
A
B
This
is
a
small
abstraction
leak.
Alice
Cassandra
node
can
only
have
sorry.
There
are
going
to
be
one
node.
That
has
the
has
a
token
as
a
particular
token'
value.
This
is
now
the
fact
of
the
initial
implement
asian.
So
we
have
to
each
note
how
to
have
a
different
token
ring
booster
at
different
token,
and
we
logically
consider
these,
as
in
each
data
center,
is
having
its
own
token
ring.
B
A
A
B
Key
and
wrote
page
with
has
options
to
save
them
periodically,
and
they
both
have
options
to
save
the
most
three
that
save
a
certain
percentage
of
the
hottest
rose.
So
if
you
have
a
very
large
patient
might
be
suffering
a
bit
on
startup
time
that
you
can
take,
you
can
say,
persist
this
cash
and
we
don't
store
the
values.
We
just
store
the
the
things
we
need
to
get
the
value
later.
That
persist,
this
cash,
every
10
minutes
and
persistent
twenty
percent
hottest
rose.
A
B
Not
an
expert
on
hate
base.
What
I
do
know,
though,
is
that
we
can
acknowledge
request
very,
very
quickly
and
my
understanding
of
page
basis.
The
use
of
the
HDFS
can
can
impinge
on
that.
If
you're
interested
in
sort
of
a
harrison
when
facebook
used
HBase
for
their
recent
messaging
system
that
they
brought
out
a
year
or
two
ago,
they
do
the
write
up
of
how
they
have
have.
They
made
the
trade-off
between
the
two
systems.
A
A
Arthur
asks.
Are
there
good
ebooks,
preferably
free
to
learn
Cassandra
further
I'll
take
a
little
bit
of
this
one
errand,
so
planet,
Cassandra
org
is
the
community
website
that
we
are
putting
a
lot
of
free
materials
out
there.
There
are
past
webinars
lots
of
blog
posts
and
articles.
The
dates
tax
website
has
stuff,
as
well
as
you
know,
of
four
books
being
written
right
now
about
Cassandra
from
O'reilly
and
Manning
and
packed,
so
those
will
be
hitting
the
shelves
in
the
second
half
of
the
year
Aaron
any
other
resources
that
you
know
of.
B
No
I
think
that,
like
say
there's
a
lot
of
information
on
Planet
Cassandra.
The
data
state's
website
itself
has
great
documentation
is
a
very
active
attaching
community.
If
you
go
to
Cassandra
board
Apache
dorg,
you
find
access
to
that
and
there's
there'll
be
a
lot
of
great
material
coming
out
of
the
summit,
which
will
all
be
made
available
as
well.
A
B
A
Okay,
great
and
oh
gosh
got
so
many
more
here.
Michael
asks
any
GUI
data
access
tools
for
Cassandra.
Actually,
my
last
company
has
toad
for
cloud
databases
that's
available
from
dell's
website.
It
is
a
free
tool
and
allows
you
to
use
SQL
to
query
cassandra
and
other
no
sequel,
databases
and
any
of
the
you
know
there.
Aaron.
B
A
B
The
rider
of
the
virtual
mode
is
that,
rather
than
one
node
having
a
chunk
having
one
chunk
of
data,
it
had
lots
of
small
ones
and
the
benefits
of
that
that
you
can
grow
your
cluster
from
three
to
four
to
five
noms.
Whereas
previously
it
was
easier
to
grow
from
three
to
six,
because
we
can
break
up
the
data
space
into
lots
of
smaller
parts.
And
if
you
have
a
large
cluster
above,
say
three
to
six.
B
It's
it's
a
tricky
one,
it's
better
to
model
things
so
that
your
read
Ricketts
edit,
your
read,
requests
tend
to
read
one
row
for
many
rows
from
home
family.
So
the
there
is,
though,
a
warning
which
is
very
wide
rows
and
talking
in
the
many
tens
of
megabytes
have
poor
performance,
as
you
might
expect.
B
If
you're
storing
something
like
time
series
data,
it's
always
a
good
idea
to
partition
into
different
rows,
based
on
some
logical
partition
in
your
data,
which
might
be
per
month
and
I'd,
recommend
you
do
a
small
test
where
you
just
write
out
a
month
worth
of
data
and
see
how
big
the
road
gets.
If
it
gets
into
the
tens
of
megabytes,
then
you
might
want
to
do
some
more
testing
to
see
what's
going
to
happen
six
months
down
the
track,
when
your
system
is
life,.
A
Thank
You,
Aaron
I
think
you're
on
a
world
record
number
of
questions
answered
here,
but
let's
try
a
couple
more
Jeremy.
How
does
the
client
connect
to
a
node
in
the
cluster
is
a
node
nominated
as
a
master
or
can
any
be
connected
to
so
I
think
you
know
coming
from
a
relational
world
there.
You
know
difficult
to
wrap
your
head
around
that
one.
B
Yep,
so
clients
can
connect
early
node
in
the
cluster.
In
fact,
many
clients
do
discovery,
so
the
client
may
know
about
a
couple
of
nodes
in
the
cluster
and
then
we'll
go
to
one
of
those
and
ask
it
for
information
about
the
impire
ring
clients
and
typically
rotate
and
recycle
around
different
note.
There's
minarets
and
failure
scenarios.
B
Once
you
get
into
larger
clusters
again
beyond
sort
of
9
to
12.
That
starts
to
become
something
that
gives
you
some
performance
benefits
and
the
smaller
prizes
that
just
a
certain
probability
that
one
of
the
nodes
you
talk
to
is
a
replica
but
technically
clients
don't
care.
It's
just
a
database
with
lots
of
like
lots
of
IP
addresses.
A
A
B
If
you're
in
a
multi
data
center
set
up,
if
you're,
using
local
quorum
for
right
and
they're,
only
waiting
on
notes
there
in
your
local
data
center
or
go
to
your
local
AWS
region.
Perhaps
if
you
use
an
each
chord,
then
you've
introduced
cross
DC
latency
into
those
situations.
If
you've
got
a
client
like
a
psionic
that
can
direct
you
to
certain
nodes,
then
you've
reduced
some
of
that
latency.
B
Then
your
client
will
just
don't
try
a
different
note.
There's
nothing
special
about
the
coordinator,
and
this
is
one
of
these
interesting
failure.
Modes
like
you
went
to
the
database
in
today.
Can
you
do
me
all
right
and
the
database
appeared
to
not
be
there,
go
to
the
next
IP
address
and
say:
hey,
you
can
do
a
right
and
it
works
so
quite
typically
failover
and
try
different,
quite
different
nodes.
A
B
Tokens
are
identified
as
specified
at
startup
or
when
you're
doing
some
sort
of
maintenance,
move
to
increase
or
decrease
number
of
nodes
loads
going
down
is
generally
thought
of
in
the
person's
caught
up
in
the
code
as
a
transient
system
and
get
problem
in
the
node
will
come
back
up.
If
a
node
fails
completely.
There
is
a
maintenance
tasks
you
can
do
to
either
replace
or
just
redistribute
that
load.
B
There's
a
script
in
the
bin
distribution
called
shuffle.
There
are
some
information
on
the
wiki
on
the
data
stack
site
and
if
you
go
through
the
user
list,
your
pipes
and
discussions
on
it,
even
the
author
of
shuffle
eric
evans,
who
is
a
great
software
engineer
service
that
says,
do
some
testing,
because
this
process
doesn't
run
very
often
so
the
education
don't
get
caught
so
go
out.
There
do
some
reading.
B
Do
some
testing
the
shuffle
process
just
move
data
around
in
just
the
same
way
we
move
data
around
when
we
do,
let
me
add
new
nodes
and
we
take
them
away
or
when
we
do
repair
so
there's
not
a
chance
of
losing
data
is
just
a
chance.
It
might
get
a
bit
confused
at
some
point
boots
and
Austin
doesn't
read
them.
A
Great
I'll
take
the
next
to
just
super
quick,
Rick
Bryant.
You
ask
about
your
data
model
and
it
looks
very
similar
to
your
relational
model.
What
I
would
say
is
please
attend
the
next
webinar
next
thursday.
At
the
same
time,
you
know
we're
going
to
talk
about
some
of
these
concepts
and
the
concept
of
thinking
differently
from
a
relational
model,
so
that
that
will
help
you
James
Gates
asks.
Is
there
a
timeline
for
these
stacks
Enterprise
to
support
one
or
two
features?
A
A
A
We
we
have
tons
of
people
monitoring
Twitter,
you
can
feel
free
to
tweet
at
planet.
Cassandra
will
make
sure
to
get
someone
back
to
you.
Stackoverflow
is
a
fantastic
resource.
Members
of
the
community
really
monitor
stack
overflow
and
then
please
attend
our
future
webinars
as
well.
Next
week
we
have
Patrick
McFadden.
He
knows
so
much
about
Cassandra
that
he
will
be
able
to
address
these
questions
as
well.
Thank
you
very
much
everyone.
We
really
appreciate
your
time
today.
Aaron!
Thank
you.