►
From YouTube: Cassandra Community Webinar | Understanding How CQL3 Maps to Cassandra's Internal Data Structure
Description
CQL3 is the newly ordained, canonical, and best-practices means of interacting with Cassandra. Indeed, the Apache Cassandra documentation itself declares that the Thrift API as "legacy" and recommends that CQL3 be used instead. But I've heard several people express their concern over the added layer of abstraction. There seems to be an uncertainty about what's really happening inside of Cassandra.
In this presentation we will open up the hood and take a look at exactly how Cassandra is treating CQL3 queries. Our first stop will be the Cassandra data structure itself. We will briefly review the concepts of keyspaces, columnfamilies, rows, and columns. And we will explain where this data structure excels and where it does not. Composite rowkeys and columnnames are heavily used with CQL3, so we'll cover their functionality as well.
We will then turn to CQL3. I will demonstrate the basic CQL syntax and show how it maps to the underlying data structure. We will see that CQL actually serves as a sort of best practices interface to the internal Cassandra data structure. We will take this point further by demonstrating CQL3 collections (set, list, and map) and showing how they are really just a creative use of this same internal data structure.
Attendees will leave with a clear, inside-out understanding of CQL3 and will be able use CQL with a confidence that they are following best-practices.
A
Also
sporting,
a
great
no-shave
November,
but
John
actually
looks
like
that
all
the
time
so
before
I
introduce
John
I'd
like
to
hit
a
couple
of
housekeeping
items,
and
always
please
use
the
Q&A
tab
to
answer
any
questions
to
ask
any
questions
during
the
webinar
and
John
will
anthem
at
the
end
and
then
also
I
would
like
to
draw
your
attention
to
our
new
data
stacks
Academy.
We
now
have
Java
development
courses
available
for
free
on
data
Stax
Academy
for
Apache
Cassandra.
A
B
Hey
guys
really
great
to
be
here,
I'm
rewinding,
to
the
beginning
of
my
talk.
So,
yes,
today
we're
going
to
be
talking
about
cql,
three
and
the
mapping
between
this
new
way
of
corene
in
to
Cassandra
and
the
underlined
Cassandra
data
structure.
This
is
so
that
we
can
take
full
advantage
of
the
speed
and
efficiency
inherent
in
the
underlying
data
structure.
My
name
is
John
Berryman
and
I
work
with
open
source
connections.
To
give
you
a
little
bit
of
background.
B
Historically,
we
have
done
a
lot
of
search
solutions,
so
we
we
were
one
of
the
earlier
solar
shops,
but
it
search
becomes
a
bigger
and
bigger
data
problem
we've
been
extending
into
other
interesting
realms
and
cassandra
is
one
of
them.
In
my
last
Cassandra
project
I
had
to
work
with
the
customers
for
the
first
time
that
helped
them
kind
of
understand,
see,
ql3
and
and
what
that
meant
for
their
work
there
and
what
you're
seeing
today
is
a
in
large
part,
the
understanding
that
we
gained
during
that
time
all
right.
B
So
a
quick
outline
of
what
we're
going
to
talk
about
today,
I
I,
want
to
first
talk
about
the
problem
that
cql
solves,
and
a
lot
of
that
is
going
to
require
us
to
dig
back
a
little
bit
into
the
underlying
internal
cassandra
data
model.
Well,
we
will
then
point
out
some
of
the
issues
like
usability
issues
surrounding
the
use
of
the
old
Cassandra
paradigm
and
then
we'll
introduce
C
to
L,
which,
which
proposes
to
solve
a
lot
of
these
issues
that
fit
we've
seen
in
the
past.
B
The
the
most
important
part
of
the
talk,
of
course,
though,
is
going
to
be
this
lengthy
section
about
understanding
how
cql
maps
to
the
internal
Cassandra
data
structure.
If
we
have
time
after
that,
we
will
get
into
some
of
the
neat
special
sauce
about
eql
as
it
regards
to
sets
lists
and
maps,
and
then
I'll
conclude
with
some
remarks
just
to
pull
it
all
back
together.
B
Alright,
so
let's
talk
about
the
problem
that
cql
solves
as
you
get
into
this
obviously
you're
all
here,
because
we
know
how
awesome
cassandra
is
so
just
a
quick
review.
Cassandra
is
a
distributed,
commoner
datastore.
It
has
no
single
point
of
failure.
Everyone
knows
about
the
cap.
Theorem
Cassandra
is
optimized
for
availability,
though
somewhat
unique
Cassandra
is
also
suitable,
so
that,
if
you
really
want
consistency,
you
can
have
that
with
the
same
technology.
Cassandra
is
optimized
for
lightning-fast
writes,
while
at
the
same
time
being
quite
performant
with
reeds
as
well.
B
Cassandra
is
easily
maintained
and
almost
infinitely
scalable
we've
seen
stirrers
get
up
to
hundreds
of
nodes,
and
it
appears
to
basically
still
be
linear.
So
it's
a
really
an
amazing
technology,
but
cassandra
does
come
with
some
usability
challenges.
If
you're
coming
from
a
sequel
background,
then
you
know
you
have
all
the
same
questions
about
those
people
certainly
levied
against
a
cassandra.
B
People
that
are
used
to
sequel
are
going
to
wonder
where
my
joints,
how
to
put
my
data
together?
What
what
do
you
mean?
There's
no
schema
I,
don't
care
about
flexibility.
I
want
to
be
able
to
talk
about
the
data
and
you
normalize.
You
know
what
how
why
on
earth
should
I
show
everything
about
this
object
into
one
big
flat
table.
It
just
doesn't
make
sense
from
an
old
sequel
perspective
with
Cassandra.
B
So
in
order
to
really
dig
into
this,
let's,
let's
get
down
to
basics
and
talk
about
what
the
Cassandra
data
structure
looks
like
at
the
highest
level.
You
have
key
spaces,
and
these
are
analogous
to
databases
inside
the
sequel
sequel
world
within
the
key
phases
you
have
column
families
which
would
be
analogous
to
database
tables
within
column
families.
You
have
mini
rows
and
the
rows
have
many
columns
themselves
zooming
in
on
an
individual
one
of
those
rows.
B
We
have,
we
see
the
a
row
is
actually
composed
of
a
couple
different
things:
rows
have
row
keys
and
several
different
columns
and
within
a
column,
there's
even
more
structure,
columns
have
call
names,
concept,
column,
values
or
tombstones.
If
you
just
want
to
acknowledge
that
this
column
is
dead
and
does
not
need
to
be
returned
in
a
query,
columns
have
time
stamps
to
talk
about
when
they
were
created
and
kind
of
interesting
in
Cassandra,
as
opposed
to
some
of
the
other
technologies,
because
the
columns
themselves
can
have
time
to
live.
B
B
B
You
know
all
the
types
that
you're
used
to
column
names
have
comparators
and
what
this
means
that
when
you
stick
a
column
in
it's
going
to
be
sorted
and
it's
going
to
go
to
the
appropriate
place
in
a
row.
According
to
the
the
sorting
that
you're
using
different
from
the
column
names
row
keys,
have
partition
errs
but
not
comparators.
The
partitioner
is
going
to
let
us
if
we.
B
B
Rows
can
have
any
number
of
columns.
You
know
one
row
and
to
the
next.
You
could
have
five
columns
in
one
row
in
a
million
homes
in
the
next
and
to
that
point,
Road
can
have
tons
of
column.
Millions
I
think
the
hard
limit
is
two
billion.
Currently
it
is
a
common
use
case
to
omit
column
values.
Time
to
live
is
is
useful
that
just
indicate
it
and
tombstones
is
also
very
useful,
all
right.
So
this
is
a
fun
slide.
This
is
where
we're
talking
about
why
cassandra
is
so
very
fast
and
right.
B
B
This
is
great
because
the
CPU
in
general
is
going
to
be
it's
still
going
to
be
lightning-fast
and
also
gives
you
a
really
good
understanding
of
how
to
scale
the
Santha.
Typically,
if
one
core
on
one
server
will
give
you
about
3,000
to
4,000
offs
per
second,
and
if
you,
if
you
know
exactly
how
many
offset
you
want
it's
just
a
evening,
math
problem
to
figure
out
how
many
cores
you
need
and
the
scaling
is
nearly
learning
linear.
B
Reason
people
get
a
little
more
complicated,
but
it's
important
to
understand
that,
because
when
we
want
to
use
because
the
Cassandra
data
model
well,
we
need
to
understand
how
data
is
going
in
or
being
read
back
out.
The
first
thing
you
do
when
you
want
a
column
or
a
slice
of
column,
as
you
check
the
mem
table,
and
if
you
find
what
you
want
there,
that's
easy,
you
return
it
back
and
you
never
have
to
hit
the
disk.
B
If
you
don't
find
what
you
want
there,
then
there
is
a
row
cache
and
if
you're
lucky
enough
to
find
the
data
there,
then
you
can
take
it
and
go
back
to
the
user.
If
you
still
have
to
look
for
more
data,
then
you're
going
to
have
to
go
to
disk
most
likely.
The
first
thing
do
is
check
a
bloom
filter.
Another
really
cool
data
structure
and
the
bloom
filter
is
going
to
give
you
a
hint
about
which
SS
table
on
disk.
B
B
The
this
process
is
naturally
not
going
to
be
as
fast
as
the
rice,
but
it's
still
quite
fast
and
it's
important
to
know
that
it's
going
to
be
faster
to
find
slices
of
columns
the
order
columns.
Then
it's
going
to
be
to
do
random
access
and
certainly
I
want
to
iterate
that
you're
not
going
to
do
slices
over
rows
because
columns
are
ordered
and
rows
are
just
partitioned.
B
So
when
using
this
data
structure
directly,
which
has
been
the
way
that
we've
done
it
for
years,
there
are
some
pain
points
involved
and
I'll
try
to
jump
to
and
pretty
quickly.
Let's
take
an
example
of
Twitter
and
let's
pretend
for
a
second
that
Twitter
backs
all
their
tweets
and
timelines
with
Cassandra.
If
I
want
to
submit
a
tweet,
then
maybe
I'll
do
something
like
this:
I'll
create
a
column,
family
name
tweets
and
then
using
the
pseudocode
that
looks
kind
of
like
the
old
Cassandra
CLI
I'm.
B
Going
to
go
to
the
tweets
table,
I
will
go
down
to
the
John
Berryman
row
and
then
I'll
go
over
to
a
column
named
of
a
date,
and
this
is
how
you
can
get
so
many
columns.
You
can
actually
name
columns
according
to
like
things
like
this
I'll
go
to
the
9:20
in
the
morning
date
and
I'll,
say
wonderful
morning.
This
coffee
is
great
and
that's
what
goes
in
the
column
value
later,
9:21
oops
smoke
is
coming
out
of
sequel
servers
and
then
30
minutes
later
well.
B
Now
my
coffee
is
cold
and
all
these
entries
are
our
columns
that
go
into
the
same
row
of
John
Berryman
and
in
this
data
structure
we've
been
talking
about.
So
when
you
want
to
retrieve
all
of
John's
tweets,
it's
pretty
simple,
you
just
get
that
row
and
you'll
get
a
sorted
list
of
all
the
tweets
sorted
by
date.
B
The
pain
point
and
we're
only
starting
to
see
this
year.
But
the
pain
point
is,
there's
no
schema,
and
while
it
does
provide
a
lot
of
flexibility,
think
about
what's
going
on
here,
we
have
a
table
called
tweeze
that
is
keyed
by
a
string.
Is
a
call
name,
our
dates
and
the
column
values
are
strings,
but
there's
no
real
hint
in
the
schema.
B
There
is
no
schema,
after
all,
there's
no
hint
about
what
those
strings
and
dates
are
used
for
in
order
to
find
out
what
we're
actually
getting
that
you
have
to
read
through
the
code
and
obviously
that's
that's,
not
that's
not
going
to
be
very
easy
to
extend
and
develop
with
all
right.
So,
let's
look
at
a
more
complex
pain
point
that
that
kind
of
gives
to
some
of
these
solutions
that
are
built
in
CQ.
Oh
time,
lines
are
going
to
be
more
complicated
within
tweets
with
with
time
lines.
B
Not
only
do
we
have
to
record
the
tweet
the
actual
text,
but
we
have
to
record
who
said
it
and
probably
a
bunch
of
other
metadata
as
well,
because
it's
not
just
me
it's
everyone
that
I
fall.
So
there's
several
bad
options
here
and
we'll
look
at
all
the
uncomfortable
options
in
and
talk
about
the
best
option
and
then
we'll
move
directly
into
cql
and
show
how
it
implements
the
best
option
option
in
a
carefree
way,
so
that
option
number
one.
B
Another
bad
option
is,
you
know,
maybe
it's
okay
to
just
have
one
table
if
we
just
shove
everything
into
that
table
and-
and
it
looks
great
at
first
so
you
know
same
same
scenario.
We
we
go
to
the
timeline
table,
find
the
John
Mayer
Berryman
row
and
go
to
the
date
and
insert
something
that
looks
like
JSON
that
we
can
parse
on
the
client-side
from
software
Doug
tweet,
hey,
John,
I
posted
on
reddit
upload
me.
There
is
a
backstory
to
that
check
out.
My
Pollock
I
met
a
post
about
it.
B
If
you
wanted
to
get
the
timeline
back
out,
then
it's
pretty
easy.
Just
a
gif
timeline.
One
query,
not
too
bad
right!
Penny
point
comes
when
you
want
to
update
stuff,
because
you
know
Cassandra
is
really
fast
at
rice,
but
if
I
wanted
to
update
anything
about
this,
I
would
first
have
to
read
out
that
element.
Update
the
you
know,
either
the
text
or
the
from'
to
fix
it
and
after
inserting
it
again
and
as
you
guys
probably
all
know,
a
rewrite
use
case
is
its
kind
of
an
anti-pattern
with
Cassandra.
B
The
last
option
is
is
the
best
option.
Although
I'm
sure
you'll
agree
it's
a
little
bit
confusing
at
first
as
well,
it
makes
use
of
composite
columns
so
back
up
a
little
bit.
Something
I
didn't
quite
mention
yet
is
that
columns
in
Cassandra
the
column?
Names
are
typed,
but
their
types
can
be
competent
types.
So,
instead
of
just
having
a
date
or
an
integer
or
text,
I
could
have
a
column
name
that
is
date
and
text
concatenated
together
and
if
I
use
this
I
can
use
it
for
an
interesting
pattern
like
this.
B
I
can
still
have
one
column
family,
but
instead
of
inserting
a
you
know,
one
column
or
the
tweet
I
insert
two
columns.
The
first
column
I
go
down
to
the
the
John
Berryman
row
and
I
for
a
column
named
by
the
time
and
the
literal
text
from
Allen
search
software
Doug
and
for
the
same
column,
family
I'll
go
to
the
the
next
column
over,
which
is
going
to
be
the
date
and
the
literal
screen
text
and
I'm
going
to
put
his
tweet
there
as
when,
when
it
comes
time
to
actually
pull
down
all
the
timelines.
B
It's
not
that
bad.
It's
still
just
one
quarry
and
I've
got
more
columns
I'm
pulling
down,
but
Cassander
is
going
to
be
fast
that
it's
basically
been
in
the
same
amount
of
information
across
the
net.
This
resolves
a
lot
of
prior
pain,
points
and
scales
very
nicely,
so
it
is
a
good
option
to
use
the
obvious
pain.
Point,
though,
is
it's
confusing
right
with
a
confident
column
name,
there's
even
more
code
reading
to
wrap
your
mind
around
what's
going
on,
and
so
what
would
you
find?
A
lot
of
times?
Is
people
building?
B
You
know
their
own
basically
ORM
in
front
of
this
stuff,
one
less
pain
point
in
the
interest
of
time:
I'll
just
rush
through
it.
If
you
have
really
long
rows
such
as
Justin
Bieber's
timeline,
then
you,
you
might
surprise
yourself
to
find
out
that
2
billion
columns
is
not
quite
enough.
If
you
happen
to
be
in
a
situation
like
that,
then
you
can
also
use
confident
rows
to
chocolate
columns
into
something
like
in
this
case,
beaver
month.
So
same
pain
point
are
a
little
bit
hard
to
read,
but
it
does
scale
well,
alright.
B
So
finally,
let's
let's
introduce
CQ
o
CQ
l
is
the
Cassandra
a
query
language
and
it
is
a
reintroduction
of
the
idea
of
a
schema
so
that
no
longer
you
have
to
read
through
the
code
to
understand
the
data
model,
you
can
communicate
it
efficiently
by
something
that
looks
just
very
similar
to
a
my
sequel
table.
Construction
cassandra
creates
a
common
language
that
everyone
can
can
use
to
discuss
stuff
because,
prior
to
CQ
l,
everyone
was
directly
addressing
this
cassandra
data
structure
and
building
their
own
layers
on
top
of
it.
B
That
often
did
very
similar
things,
but
not
exactly
the
same
thing.
So
there's
a
lot
of
gotchas
DQ
l
is
the
standard.
Cq
l
is
a
best
practices
interface
to
Cassandra,
so
what
C,
kill'uh
CQ
l
is
going
to
do
is
basically
it's
going
to
implement
the
composite
Rove
composite
column,
name
idea
that
we
discussed
in
the
past
two
slides,
but
you
don't
have
to
worry
about
the
details,
because
we
agree
the
details
they're
a
little
bit
messy,
but
you
do
get
the
benefit
of
nice.
Scalability
and
you'll
see
that
it's
easy
to
read.
B
Alright
without
further
ado.
Let's
take
a
look:
here's
here's,
a
quick
introduction
to
the
array
of
things
that
you
can
do
with
cql,
let's
create
a
table.
This
is
users.
We
have
four
fields:
ID
last
name,
first
name
and
date
of
birth.
You
can
have
field
types,
all
the
types
that
you're
familiar
with
and
primary
key.
You
know
what
that
means.
It's
just
the
same
idea.
Basically,
is
my
sequel
insert
this.
Basically
again
is
my
sequel,
syntax
and
it's
easy
to
read
it
and
understand.
B
What's
going
on
here,
updates
I
can
find
a
row
in
there
and
insert
update
stuff,
as
you
expect,
to
do
and
finally
select
work
at
least
four
simple
flex
work
just
like
they
would
for
my
sequel
and
the
results
look
pretty
much
like
it
would
pretty
eats
up
right,
so
you
might
be
thinking
sweet.
This
is
exactly
the
same
as
my
sequel,
yeah.
Well,
you're,
better
wait!
B
A
little
bit,
there's
some
interesting
intuition,
there's
good
intuition
that
you
can
gain
from
a
familiar
syntax,
but
it's
important
to
understand
the
differences,
because
some
of
the
intuition
can
be
misleading.
So
some
of
those
of
you
who
have
been
using
the
sender
wall
might
say
what
happened
to
all
the
wide
roads-
everything's
a
short,
my
sequel,
again,
row
again
well,
they're
still
there
and
it's
important
to
understand
how
CQL
is
rearranging
the
information
you're
putting
in
and
presenting
on
the
screen.
B
B
B
B
So
you
can
do
this
with
a
cql
insert
and
then
a
select
would
provide
this
data
back
and
in
the
bottom,
we're
going
to
have
the
representation
as
it
would
look
inside
the
cassandra
internal
data
structure,
and
I
guess
it's
important
to
make
a
note
on
vocabulary
here
when
I'm
talking
about
the
cql
organization
of
things,
I'll
talk
about
the
cql
rows,
the
CQL
fields
or
columns,
and
what
I'm
talking
about
internal
Cassandra
data
representation,
I'll
talk
about
Cassandra
rows
and
Cassandra
columns
all
right.
Let's
back
up
quick
sip
of
coffee.
B
Alright,
so
simplest
case
is
we
create
a
table
for
employees?
This
table
has
three
fields
names.
A
gin
rolled
and
name
is
the
primary
to
stick.
Some
quick
data
in
there.
That's
neat
and
that's
the
bossman
Eric
Pierre,
and
the
way
this
had
looked
inside.
Cassandra
is
like
this
in
the
bottom
two
rows.
Now
it
might
be
a
little
bit
deceiving
at
first
because
they
look
pretty
much
the
same.
Don't
they
there's
two
rows
in
both
cases,
and
it
looks
like
there's
two
columns
but
note
that
there
is
a
difference
on
the
internal
representation.
B
There
is
actually
only
two
columns
because
the
because
the
CGL
representation
there's
three
columns,
but
since
we
have
labeled
name
field
as
a
primary
key
that
that
is
telling
tql
that
hey
the
value
of
this
field
is
what
we're
going
to
use
for
the
row
keys
and
the
field
names
that
are
not
in
the
primary
key
of
what
we're
going
to
use
for
the
column
values.
So
keep
in
mind
what
cassandra
to
do
well,
we
can
find
an
employee
very
easily
because
key
row
names
are
partitioned,
let's
a
little
more
complicated
in
this
case.
B
We've
effectively
got
the
same
table,
but
we've
added
a
company
field
and
we've
changed
the
primary
key
to
not
just
be
named,
but
it's
a
composit
key,
a
compound
key
of
company
and
name
adding
a
little
bit
more
data.
In
this
time
you
see,
we've
got
a
couple
different
companies,
the
same
entries
for
Eric
and
myself,
and
then
some
people
from
the
other
company
and
the
internal
representation
looks
like
this.
So
interesting
right
in
the
cql
structure,
we
have
five
rows
in
the
internal
two
standard
structure.
We
have
two
rows.
That
is
surprising.
B
The
primary
key
is
the
thing
that
you
always
need
to
look
at
here.
The
primary
key
gives
you
the
understanding
of
how
cassandra
is
going
to
rearrange
this
data.
Whenever
you
see
a
primary
key,
the
first
element-
and
if
it's
if
the
primary
key
is
not
competent,
it
would
be
the
only
element,
but
the
first
element
of
that
primary
key
tells
Cassandra,
which
thing
to
use
as
the
rope
key.
So
in
this
case
we're
going
to
go
to
the
company
and
the
values
of
the
company
field
are
the
names
of
the
row
keys.
B
In
this
case
we
have
two
companies
and
that's
why
it
corresponds
to
two
ropes
now.
It
also
gets
a
little
bit
more
interesting
this
time
with
the
columns,
because
the
primary
key
again
is
kind
of
your
hint
here,
but
the
elements
after
the
first
element,
the
primary
key
in
this
case-
name
tell
you
what
values
are
going
to
go
in
the
column
names
of
the
internal
representation
of
Cassandra
so
take,
for
instance,
those
top
two
rows
in
the
tql
version.
Eric
and
John.
B
Right
since
name
is
the
second
element
of
the
primary
key,
then
the
actual
name
is
going
to
be
encoded
in
the
column
names
for
the
internal
data
structure
there
at
the
bottom.
Let
that
absorb
a
little
bit
we're
actually
storing
the
data.
In
the
column
names
itself-
and
these
are
competent
columns
as
well,
because
if
we
want
to
know
which
Eric
has
to
column
in
the
internal
representation,
but
one
of
them
corresponds
to
age.
So
we
concatenate
that
column
name
with
age.
B
The
other
one
corresponds
to
role
and
similarly
for
me
and
everyone
else
here,
so
things
have
become
more
complicated
up
and
you
know,
certainly,
you
can
start
to
see
why
you
would
not
want
to
directly
address
the
internal
representation,
but
cql
is
providing
you
with
a
very
nice
syntax
and
is
taking
care
of
all
the
the
kind
of
complex
work
to
get
all
the
performance
and
functionality
that
you
would.
One
of
the
Cassandra
are
using
a
strategy.
B
Keep
in
mind
of
the
second
thing
you
know,
Cassandra
is
good
at
finding
rows
by
their
partitioning
and
if
Cassandra
is
good
at
finding
slices
of
the
rows
based
on
the
sorting
of
the
columns.
So,
for
instance,
I
can
go
to
your
company
by
row
and
I
can
find
all
employees
whose
names
start
with
a
through
him
with
a
really
efficient
for
you.
B
All
right
pulling
out
all
the
stops:
let's
create
a
table
with
six
fields
and
the
primary
key
is
got
this
kind
of
weird
syntax
if
they
composite
composite
key
sorry.
This
is
a
little
bit
hard
to
read,
but
do
keep
in
mind
that
this
will
be
posted
in
it.
This
should
be
a
good
reference
for
later,
but
I've
named
all
my
fields
with
letters
to
concert
capital
letters
to
conserve
space
and
I
have
named
all
of
the
the
values
as
lowercase
letters.
B
So
once
we
add
data
into
this,
the
internal
representation
is
going
to
look
like
this
on.
The
bottom
might
be
a
little
bit
confusing
apart
at
first,
let's
break
it
apart.
I
told
you
in
the
last
slide
that
the
first
element
of
the
primary
key
is:
what
are
you
going
to
use
for
your
internal
road
names
and
it's
still
the
same
case
here.
The
only
difference
is
that
here,
the
first
portion
of
the
primary
key
is
a
competence,
a
and
B,
so
how
many
values
do?
B
B
The
primary
key
tells
what
values
are
going
to
be
stored
and
used
to
sort
by
in
the
internal
column,
names,
and
so
we're
going
to
pull
out
values
of
C
and
D
and
use
that
as
references
to
the
column,
names
and
finally,
the
things
that
are
not
mentioned
in
the
primary
Keys
gets
concatenated
to
the
internal
column
names
so
that
so
that
we
can
look
things
up
so
take
as
an
example
we'll
be
last
row
from
the
CQL
version
of
the
top.
Writing
s,
t:
u
v
w
x.
B
What
is
that
correspond
to?
Well,
we
need
to
find
the
row
that
that
is
going
to
live
in
and
the
row
name
is
going
to
be
whatever
is
in
these
first
two
fields,
so,
st
okay,
so
you
can
see
on
the
bottom
right
and
by
the
way
I
should
have
mentioned
this
earlier.
Keep
this
in
mind
when
you
review
this,
everything
is
color
coded,
so
you
can
find
exactly
where
everything
goes
to
by
color
coding.
So
SP
is
is
the
name
of
a
row
and
that's
presented
internally
at
the
bottom
right.
Next,
we
want
to.
B
B
All
right,
so
we've
got
about
ten
minutes
left
I.
Think
we've
got
a
little
time
to
go
over
kind
of
a
neat
thing
that
you
can
do
with
CQL
revolving
around
sets
lists
and
maps.
These
are
collections,
and
this
is
something
that
last
I
checked
that
my
think'll
is
not
going
to
do
for
you
I
think
I've
started
to
see
some
of
these
things
up
here
in
in
your
more
standard
databases,
but
only
it's
kind
of
a
response
to
the
whole.
No
sequel.
B
The
cool
thing
about
how
sets
lists
and
maps
work
with
Cassandra
is
it's
using
the
same
old
data
structure
that
I
showed
at
the
very
beginning,
slides.
So
once
you
understand
the
mapping,
then
you
can
understand
very
clearly
why
what
Cassandra
is
going
to
be
fast
with?
Oh,
why
some
queries
will
and
will
not
work.
So,
let's
dig
into
exactly
what
this
looks
like
so
declaring
a
table
with
sets.
Listen
map
is
pretty
simple.
Basically,
you
use
this
templated
syntax
here
at
the
bottom,
to
define
tips
with
whatever
data
type.
B
It's
important
to
know
that
primary
the
primary
key
cannot
contain
any
element
from
a
set
list
or
map
and
intuitively
that
should
probably
make
sense
right.
All
right
sets.
Listen
map
have
have
some
nice
syntax
or
surrounding
them.
You
can
insert
into
a
set
using
curly
brackets.
You
can
insert
into
a
list
using
square
brackets
and
you
can
insert
into
a
map
using
something
that
looks
kinda
like
JSON,
pretty
straightforward
right.
B
Similarly,
when
updating
you
can
do
a
lot
of
stuff
with
this,
when
updating
the
set
you
can
use
this
plus
equals
plus
notation
my
set
equals
my
set
plus
new
stuff,
you
can
pull
stuff
out
of
the
set.
That's
interesting,
I
would
lift
very
similar,
and
the
semantics
here
is
that
you
can
add
to
the
front
of
the
list
or
you
can
add,
in
the
back
of
lips.
B
That's
that's
kind
of
neat
and
with
sets,
you
can
add
new
elements
in
the
set
and
there's
a
couple
different
ways
of
doing
that
as
we
demonstrate
it
here
and
you
can
delete
elements
as
well,
which
is
not
presented
so
we're
going
to
follow
the
next
three
slides.
We're
going
to
look
at
basically
the
same
organization
I
used
in
the
previous
discussion,
but
we'll
look
at
sets,
lists
and
maps
and
see
just
how
this
is
working
internally
in
Concentra.
For
this
thing.
Well,
we
create
a
table
that
has
primary
key
X&Y.
B
Just
you
get
an
understanding
of
how
this
would
fit
in,
and
importantly,
it
has
a
my
set
field
which
carries
integers
right
so
in
this
set
we're
going
to
we're
going
to
in
this
table
we're
going
to
stick
a
couple
different
entries,
as
you
can
see
here-
and
this
corresponds
to
these
internal.
This
internal
row
now
think
about
it
from
our
initial
discussion.
Does
this
make
sense?
It
should
the
first
element
of
the
primary
key
is
the
field
X
and
how
many
unique
entities
do
we
have
in
field
X?
B
We
have
two
sorry
we
have
one.
So
that
means
it's
going
to
correspond
to
one
row
and
similarly,
Y
is
the
the
Y
field
is
the
second
part
of
the
primary
key,
so
the
values
of
the
Y
field
are
going
to
be
stuck
concatenated
into
the
internal
column.
Names
see,
there's
B
and
C.
Now
the
cool
thing
about
sets
is
their
value
also
is
concatenated
and
stuck
into
the
column
names.
B
So
next,
we'll
take
a
look
at
lists
and
again
same
with
the
primary
key
is
going
to
be
the
same
thing,
so
we
won't
discuss
that
in
there
anymore,
but
this
list
has
two
elements
in
it
and
the
way
that
this
would
look
internally
is
kind
of
similar
to
the
last
one,
but
instead
of
concatenating
the
value
of
the
list
at
the
end,
we
concatenate
this
crazy
freaking
number
to
the
end.
This
UUID
and
the
actual
value
from
the
list
goes
inside
the
the
internal
column
value
there.
B
B
So
it's
easy
to
find
a
the
my
map
associated
with
row
AC
and
it's
easy
to
pull
out
all
data,
that's
associated
with
that.
It's
not
going
to
scattered
around
at
all
when
we
sorted
they're
right
together
and
easy
to
find,
add
and
delete
as
well
all
right.
This
is
a
messy
slide.
I
do
not
expect
you
read
it
lower
your
eyes
over
a
little
bit
and
do
understand
at
least
what
I
want
you
to
to
see
here.
B
When
you
get
a
chance,
look
back
at
this
slide
and
see
what
my
examples
are:
the
way
that
I
figured
out
how
everything
works
is
I,
looked
at
it,
I
look
at
it,
both
in
CQL
and
I,
looked
at
it
in
the
old
Cassandra
CLI,
which
which
is
much
closer
to
the
internal
data
structure.
Effectively.
If
you
follow
my
example
here,
I
basically
implement
a
table
that
has
all
the
set
structures.
B
We
just
talked
about
all
the
collection
structures
and
then
I
look
at
it
both
inside
CLI
and
I,
look
at
it
inside
the
cql
shell,
and
you
can
see
for
yourself
exactly
how
things
should
shift
around.
So
if
you
ever
have
a
question
and
I
haven't
covered
it
with
this
talk
go
back
to
this
slide
right
here
anyway.
You
know
this
takes
five
minutes,
tops,
run
and
run
a
quick
example
for
yourself
and
you'll
understand
exactly
how
all
these
things
are
wired
together,
so
putting
it
all
together-
and
this
is
we're
getting
near
the
end.
B
Now,
from
the
beginning
of
the
talk
of
the
talk
you,
you
understood
that
cql
is
basically
a
reintroduction
of
the
idea
of
the
schema.
It
allows
you
to
to
easily
talk
with
others
about
the
data
structure
without
having
read
code.
D2L
creates
a
common
data
model
language.
Earlier
we
had
a
lot
of
scatter
and
the
client
ecosystem
with
everyone
doing
similar,
but
not
the
same
thing.
That
cql
is
the
standard.
It's
kind
of
the
gatekeeper
and
going
forward.
Everyone
carries
the
same
semantics.
B
Cql
is
a
bad
best
practice
best
practices,
interface
of
the
internal
Cassandra
data
structure.
There's
there's
way
that
you
can
keep
treat
Cassandra
so
that
it
scales
really
well,
but
unfortunately,
they're
a
little
bit
complicated
cql
makes
it
easier
by
putting
a
nice
syntax
on
top
of
that
and
abstracting
away.
The
messy
details
now
can
throw
at
the
end
of
the
talk
with
this
discussion
that
we've
just
concluded.
You
also
understand
the
mapping
from
cql
to
the
internal
Cassandra
data
structure.
B
So
now,
when
you
have
a
question
about,
you
know
what
they're
really
doing
on
the
inside
and
if
you
get
confused,
please
go
back
to
these
notes,
take
a
look
at
them
and
please
do
experiments
for
yourself
just
to
get
an
understanding
so
that
you
can
make
the
best
use
of
cql
and
Cassandra
yourself.
And
finally,
though,
I
didn't
get
a
chance
to
address
this
in
the
slides.
We
talked
about
tql
as
a
syntax,
but
there
is
also
a
corresponding
tql
protocol.
B
C2L
is
a
synchronous,
so
that
means
it's
going
to
be
really
fast
compared
to
the
old
transport
layer,
which
is
synchronous.
Now,
that
is
to
say
that
thrift
can
be
made
asynchronous,
it
can
be,
but
the
implementation
inga
sangra
in
cassandra
is
synchronous
and
finally,
cql
allows
for
the
possibility
of
having
prepared
statements,
which
is
just
going
to
make
it
all
that
much
faster
all
right.
So
that's
pretty
much
it
there
is
my
twitter
handle
basically
just
take
out
all
the
non
phonetic
characters
in
their
yard.
I
would
like
some
feedback.
B
Tell
me
if
you
liked
it
and
if
you
didn't
like
it
I'd
be
a
are
stood
in
understanding.
How
I
can
improve
it.
Please
do
take
a
look
at
the
OSE
blog
I,
regularly
blog
about
data
science,
Cassandra
and
other
things
as
well.
Thank
you
very
much,
and
it
looks
like
we've
got
a
little
bit
of
time
left
for
questions.
A
A
There
I
will
read
them
out
to
John
and
we
will
get
through
as
many
as
we
can,
while
you're
typing
those
we
have
another
webinar
next
week,
a
migration
from
MongoDB
to
Cassandra,
that
is
by
John
Haddad
and
Blake
Eggleston
from
shift
to
very
prominent
members
in
the
community
as
well,
and
also
just
a
reminder
Paige.
If
you
could
go
to
the
training
slide,
we
do
have
free
online
cassandra
training
now
available
at
the
dates
tax
academy
link
there.
A
A
I,
like
questions
I,
can
answer
so
will
this
webinar
be
recorded?
Yes,
the
webinar
is
recorded,
John
slides
will
be
available
along
with
the
video
recording
tomorrow
on
Planet
Cassandra,
and
we
will
make
sure
to
email.
You,
the
link
and
also
tweet
it
out.
Patrick
asks
our
solid
state
disks,
a
good
choice
for
the
discs
when
using
Cassandra.
B
At
the
same
time
now.
That
being
said,
it
still
shouldn't
be
a
terribly
scary
thing
to
go
with
spinning
media,
especially
for
like
the
commit
log.
Basically
you're,
always
writing
to
the
end
of
the
commit
log,
and
even
with
spinning
Russ
made,
it
sure
is
fast.
You
can
get.
You
can
get
I
need
to
read
up
on
it
again
by
I
think
the
number
was
into
the
gigabytes
per
second
of
data
rates,
IO
rates
as
long
as
you
don't
see
as
long
as
you
just
keep
Brighton
at
the
end,
so
hope
that
helps
yes.
A
And
we
just
posted
the
talks
from
Cassandra
Europe
summit
and
there
is
a
great
talk
about
Cassandra
on
solid-state
disk
by
I'm
blanking
on
his
name
now,
but
he
is
from
fusion-io,
so
you
can
look
out
for
that.
One
okay.
So
this
is
a
from
Michael
when
looking
at
a
tweet
timeline
example.
What
about
when
you
have
thousands
following
a
single
person,
but
each
tweet?
Do
you
have
to
update
all
of
their
timelines
at
right
time?
What
about
when
someone
starts
to
follow?
How
is
the
timeline
initialized.
B
B
That
I'm
not
aware
of
I,
would
probably
do
something
whenever
you
have
a
new
user,
follow
whenever,
for
example,
I
follow
a
new
user,
then
something
all
Klein,
probably
in
the
Twitter
store
magic,
is
going
to
know
that
whenever
a
tweet
comes
by,
it's
going
to
look
me
up
in
a
list
very
massively
parallel
process,
because
this
can
be
parallel
and
then
write.
Write
all
this
to
again.
B
A
very
large
Cassandra
cluster
I
suspect
that
they're
probably
doing
something
a
little
bit
smarter
than
that
when
you
have
individuals
that
are
followed
by
thousands
and
thousands
of
individuals
or
individuals
that
follow
thousands
and
thousands
of
individuals
up,
but
probably
one
think
it's
to
that
level.
Performance,
they're,
building
their
own
stuff
as
well.
B
A
B
So
the
internal
data
structure
is
going
to
be
I'm.
Sorry,
the
partition
key
in
that
case
is
going
to
be
that
first
element.
If
you
go
back
to
this
slide
in
just
remind
you,
that
was
the
user
name,
so
we
go
to
the
tweets
or
the
timeline
table,
column,
family
and
we
go
to
the
John
Berryman
row,
the
that
is
going
to
be
the
partition
key
and
just
to
take
a
little
bit
little
step
further.
If,
if
we're
going
to
encode
this
a
similar
problem
into
cql,
then
what
does
that
mean
procedure?
A
Yes,
thank
you.
If
offer
clarifies
I'll,
definitely
ask
you
again:
now:
we've
lost
the
question
that
I
was
on.
I
was
scrolling.
Okay,
here
we
go
so
this
one
is
from
Senka
and
sankar
asks.
I
can
understand
how
Cassandra
is
faster
in
row,
key
fetches,
but
how
is
it
faster
on
column
access?
Is
the
memory
address
stored
somewhere
else?
Does
it
fetch
the
entire
column
set
and
then
past
them.
B
If
you
do
want
a
slice
of
the
data,
then
there's
no
way
to
prove
that
that
I
know
of
there's
no
way
to
prove
by
looking
just
at
the
mem
table
that
you've
gotten
everything
some
of
the
things
might
have
already
been
sent
to
the
SS
tables.
And
when
that
happens,
you
go
through
here
everything
in
the
pipeline.
If
you're,
if
you're,
lucky
enough
that
the
SS
table
the
row
of
fragments
have
been
assembled
into
the
row,
cache
and
then
you're
good
to
go,
but
if
you're
less
lucky,
then
you
have
to
go
to
disk.
B
We
try
to
find
data
that
should
be
co-located
and
co-located,
but
we
do
at
least
go
through
some
data
structures
in
RAM
before
we
have
to
hit
the
disk,
we
go
through
those
lovely
bloom
filters,
another
great
Wikipedia
read
and
they
will
tell
you
they
basically
tell
you.
If
your
data
is
included
in
a
particular
SS
table,
they
are
very
low,
they
use
very,
very
little
memory
and
they,
the
caveat,
is,
is
that
they
lied
to
you.
B
B
If
you
make
it
past
the
bloom
filter,
you
can
look
at
the
key
cache
find
the
exact
spot
on
the
disk
to
start.
Looking,
that's
going
to
help
a
lot,
and
you
basically
do
a
hopefully
just
you
know
one
quick
scan
for
all
the
places
that
the
bloom
filter
indicate
that
the
data
might
be
reassemble.
It
stick
in
the
row
cache
and
there
you
go
so
I've
kind
of
gone
in
detail
over
what
that
slide
is
about
this.
The
TLDR
for
this
question
is
a
pulling
back.
B
B
A
B
Absolutely
and
it's
good
to
think
about
that
step
back
to
the
1990s
for
a
bit
and
everyone's
using
sequel
and
the
way
that
you
model
your
data,
is
you
think
about
just
the
way
the
data
is
related?
You
think,
in
terms
of
this
has
a
deck.
This
has
many
that
that
has
one
of
those
in
your
parens
are
connected
to
other
things,
with.
B
The
data
modeling
is
a
bit
more
constraining
up,
but
you
kind
of
live
it
on
its
head.
You
think
about
the
questions
that
you're
going
to
add
and
then,
instead
of
worrying
about
inserting
data
into
Cassandra
into
a
database
in
the
normalized
sense
with
Cassandra,
you
might
write
it.
Several
different
ways
just
write
the
same
data,
and
so
as
I've
been
harping
on
to
this
point.
The
standard
is
great
at
finding
the
internal
rows
great
at
finding
great
at
pulling
back
slices
of
the
rows
according
to
the
sorted
columns.
B
The
first
element
of
the
primary
key,
which
becomes
the
partitioning
key,
is
the
company
name,
the
second
element
of
the
primary
key,
which
becomes
there's
a
word
for
the
clustering
key
I
forget,
but
becomes
basically
this
sorting
key
is
going
to
be
the
individuals
names.
Now,
on
the
other
hand,
if
you
you
find
that
you
also
have
a
need
to
pull
back
people
sorted
by
celery,
then
you're
going
to
still
have
the
primary
key
is
going
to
be
composite.
B
The
first
part
of
it
is
going
to
be
the
company
name,
but
the
second
part
of
it
is
going
to
be
their
salary
so
that
you
can
pull
people
sorted
by
salary
and
a
little
side
note
on
that
as
well.
A
skip
lifts
is
a
really
incredible
data
structure,
but
it
encodes
everything
sorted
so
that
it
can
be
easily
scanned
in
one
direction.
B
A
B
B
That's
going
to
be
same
thing,
either
way:
Oh
what's
like
out
there
do
keep
in
mind
that
when
you
pull
elements
out
of
the
data
list
or
add
a
list
that
you
have
to
worry
about
a
little
extra
performance
to
see
there
I'm
going
to
forget
it
right
now.
But
there
is
a
surprising
reason
right
on
the
list
structure
specifically
I,
think
it
says
it
in
the
Apache
cql
three
notes
as
it's
a
flight
gotcha
but
good
to
know
about
just
in
the
Sun
next
question.
A
B
One
thing
thrift
is
going
to
be
around
for
a
while.
So
if
you,
if
you
get
thrift,
you
don't
have
to
drop
but
c2l
protocol
does
provide
some
nice
things.
That
church
is
not
going
to
have
and
I
just
barely
looted.
At
the
end
of
the
talk,
CTL
is
going
to
be
asynchronous
where
it
is
stripped,
at
least
as
it's
currently
implemented
within
Cassandra
is
synchronous.
So
that
means
that
Cassandra
is
going
to
be
twiddling
its
thumbs
while
people
get
it
get,
it
request
so
you're
going
to
be
able
to
improve
your
throughput
with
equal.
B
B
B
Yes,
you
can,
because
internally
it
just
does
Cassandra
the
data
structure
doesn't
know
the
difference.
It's
just
a
column
name,
column
value.
Just
like
anything
else
is
today,
so
you
might
be
asking
that,
because
with
counters
you
can't
combine
them
together
with
non
counter
home.
So,
but
in
your
case,
don't
worry
about
it.
This
yep,
combining
together
all
you
want
that.
A
B
This
is
going
to
be
something
where
I
don't
have
to
do
my
homework
but
I.
If
my
integration
proves
true,
everything
on
the
cql
side
is
just
kind
of
a
nice
covering
over
stuff
that
is
used
internally,
so
the
internal
Cassandra
indices,
it's
going
to
use
the
same
thing
on
it
and
instead
of
looking
like
you're
getting
indices
for
you
know
different
different
rows
and
different
points
in
in
the
rows
with
with
cql.
B
A
B
A
B
Every
everything
I
believe
is
available
in
1.2
when
I
put
these
the
first
version
he
slides
together.
I
was
definitely
working
with
a
client
on
1.2,
though
you
might
want
to
look
at
2.0
for
some
really
neat
stuff
as
come
online
system.
That
makes
cql
all
the
more
interesting
and
fun
to
use.
If
you're
interested,
please
look
at
the
Apache
ql3
documents
that
they
seem
to
be
very
well
updated
and
I
was
even
surprised.
Last
night,
as
I
was
preparing
for
this
talk,
lots
of
these
stuff
on
the
horizon,
with
Cassandra
and
eql.
A
John
this
has
been
a
hot
topic,
so
you
know
my
recommendation
would
be:
let's
have
you
give
an
updated
version
of
this
webinar?
Maybe,
as
it
applies
to
2.0
early
in
2014,
so
I
think
that
would
be
really
valuable
and
then
Paige.
If
you
could
just
put
back
John's
closing
slide,
I
want
to
leave
everyone
with
John's
Twitter
handle
there.
We
have
not
been
able
to
get
to
all
of
the
questions,
so
you
know
please
feel
free
to
hit
John
up
on
Twitter
and
John.
Thank
you
so
much
for
joining
us
today.