►
From YouTube: Cassandra Community Webinar | Become a Super Modeler
Description
Sure you can do some time series modeling. Maybe some user profiles. What's going to make you a super modeler? Let's take a look at some great techniques taken from real world applications where we exploit the Cassandra big table model to it's fullest advantage. We'll cover some of the new features in CQL 3 as well as some tried and true methods. In particular, we will look at fast indexing techniques to get data faster at scale. You'll be jet setting through your data like a true super modeler in no time.
Speaker: Patrick McFadin, Principal Solutions Architect at DataStax
Patrick McFadin is a Principle Solutions Architect at DataStax, the commercial company behind Apache Cassandra. Prior to his work at DataStax he was the Chief Architect at Hobsons, an education services company. He obtained a BS in Computer Engineering from Cal Poly, San Luis Obispo and holds the distinction of being the only recipient of a medal (as anyone can find out) for hacking while serving in the US Navy.
A
All
right,
thank
you
very
much
so
I'm
Patrick
McFadden
I'm
a
solution
architect
here
at
data
stacks,
and
this
is
part
two
of
a
series
that
I'm
doing
in
data
modeling.
If
you
had
seen
the
first
one.
This
is
the
continuation
of
that.
So
our
first
webinar
was
on
data
modelling
from
more
of
a
basic
point
of
view,
but
really
I
was
trying
to
speak
to
the
relational
crowd
and
say
come
on.
A
Let's,
let's
talk
about
the
differences
here
and
bring
the
relational
concepts
over
to
Casandra
topics,
to
try
to
bridge
that
gap,
some
being
an
X
Oracle,
DBA,
I
kind
of
spoke
from
that
experience.
So
hopefully
that
will
help
you,
if
you're
trying
to
make
that
crossover,
but
also
making
the
point
that
we
live
in
this
world
of
polyglot
persistence,
where
we
have
multiple
databases
and
multiple
ways
to
store
data.
A
So
how
does
this
fit
into
all
of
that
with
some
basic
entity
modeling,
which
is
just
users
and
things
like
that
and
cover
the
relational
topics
that
are
pretty
hard
to
conceptualize
in
Cassandra
and
hopefully
helped
you
with
that
which
is
like
the
one-to-many
many-to-many
type
data
models
and
we
finished
off
with
some
pretty
complicated
transaction
stuff
transaction
type
modeling!
It's
not
Cassandra
does
not
do
that
transactions,
but
you
can
emulate
a
lot
of
what
you
need,
but
I
also
argued.
They
probably
don't
need
as
much
as
you
think.
A
A
If
you'd
watch
the
first
and
you
got
kind
of
the
basics,
this
should
really.
This
would
really
take
you
to
the
next
level,
hopefully
and
understand
a
lot
more
of
just
pure
Cassandra,
how
it
can
do
things
for
you
and
how
you
can
date
a
model
of
your
application
and
that's
really
what
it
comes
down
to
is
your
application.
Has
certain
specific
needs
that
you
can
model
and
Express
and
how
you
set
up
your
data
model
in
Cassandra,
and
this
is
that
this
is
not
just
a
no
problem.
A
This
is
something
that
happens
with
any
database.
I
can
make
or
break
a
deployment
based
on
a
good
or
bad
data
model
on
any
database.
I've
done
it
before
in
Oracle,
and
so
this
is
just
really
a
common
concept,
but
this
is
specific
to
Cassandra
and
how
you
can
make
your
deployments
successful.
So,
let's
start
out
with
some
basics
again,
but
I'm
going
to
take
it
to
the
next
level
here.
So
this
is
another
type
of
data
model.
A
That's
pretty
common
in
Cassandra
and
this
time
series
a
time
series
is
a
good
fit
for
Cassandra,
just
based
on
the
wide
mode
format.
So
what
have
we
have
an
example
here
where
we
have
a
weather
station
that
collects
regular
temperature,
so
weather
station
has
a
weather
station
ID.
You
know
like
our
airport
code
and
every
minute
or
every
second,
it
collects
temperature
and
that's
a
pretty
common
type
of
time-series
application.
A
So
the
weather
station
would
be
my
row
and
then
every
new
temperature
reading
would
be
a
timestamp
of
the
column
name
and
then
the
temperature
would
be
the
column
value
and
not
just
continue,
though,
so
if
I
need
to
find
out
the
temperature
for
a
particular
time,
I
go
to
the
row
key
and
then
I,
look
at
which
event
time
that
that
happened
or
I
can
do
a
slice.
Even
that's
a
pretty
that's
a
basic
model,
but
this
isn't
about
basic
modeling
right.
So
how
about
a
super
model?
A
Well,
if
you
were
collecting
your
data
at
every
second
you're,
going
to
run
out
of
rows,
you
can
do
two-bit,
learn
you're,
going
to
run
out
of
column.
Sorry
you're
going
to
do
two
billion
columns
in
Cassandra,
but
if
you
do
it
every
second
I
think
that's
a
couple
of
months
worth
of
seconds.
You're
going
to
run
out,
so
we're
going
to
or
it
could
be
more
than
that,
but
point
is,
is
there's
a
limit
and
we
need
to
think
about
that.
A
So
this
is
where
we
get
into
a
the
better
part
of
a
good
time
series
model
and
that's
partitioning.
So
we
want
to
act.
We
want
to
try
to
put
this
in
some
sort
of
access
pattern
if
we're
going
to
be
able
to
grab
and
we're
going
to
partition
these
rows
by
day.
So
now,
what
I've
done
here
is
I've
created?
What's
called
a
compound
Roky
the
compound
row.
Cubes
is
the
thing
where
you
see
the
primary
key
is
and
in
the
bracket
area
weather
station
ID,
comma
date.
A
The
date
part
what
I'm
doing
is
I'm
just
taking
out
the
date,
not
just
the
time
price
throughout
the
time
part.
So
that
means
that
every
day
has
a
new
row
and
that's
pretty
cool.
Now,
whenever
I
go
to
acts
after
that
data,
let's
say:
okay,
I
want
this
weather
station
ID
and
I
went
yesterday
from
10
a.m.
to
11
a.m.
that's.
I
have
all
the
information
in
just
in
that
query,
where
I
can
find
this
row
and
then
I
can
go
get
that
event
time
now.
A
The
other
part
of
this
that
makes
it
cool
and
super
is
this
business
but
I
put
at
the
end
where
I
say
clustering
order
by
and
by
the
event
time
and
is
descending.
What
that
really
does
is
is
reverse
sorting
those
columns
in
that
wide
row,
and
this
is
a
powerful
feature
that
really
makes
access
efficient.
So
essentially,
what's
going
to
happen
is
it
means
that
the
last
event
that
happened
is
now
the
first
thing
in
that
row.
A
So
if
I
wanted
to
go
back
and
ask
a
question,
let's
say
I
want
to
know
with
this
weather
station
ID
on
this
date.
Give
me
the
last
10
things
that
happened.
That's
an
easy
query!
You
just
start
at
the
beginning
of
the
row
and
then
you
get
10
things
in
and
the
very
efficient,
very
fast,
but
it's
also
I,
don't
know
the
dates.
I
just
want
the
last
10
things
perfect
for
dashboarding.
If
you're
using
something
like
high
charts
or
one
of
those
JavaScript
charting
libraries,
you
can
get
some
really
fast
and
efficient.
A
Charting
with
that.
You
can
say
here,
go
get
me
all
the
last
10
things
happen,
throw
them
in
the
chart,
and
so
this
is
a
very
common
type
of
pattern,
with
weather
with
weather
data,
any
kind
of
time
series
data,
but
time
series
data
really
does
well
with
this
reverse
sort,
because
essentially
this
is
how
we
think
of
things
in
time
series
we
want
to
know
what
just
happened:
things
that
happened
a
while
ago
when
we
can
go.
Look
for
that
later,
but
most
times
it's
what
just
happened
so
another
basic
model.
A
Then
we
covered
this
in
our
last
webinar
just
refreshing.
This
thought
is
here's
a
user
entity
and
it's
one
got
one
primary
key.
It's
the
username,
which
is
there
just
one,
and
it's
boring
this-
isn't
there's
nothing
exciting
about
this.
This
is
a
pretty
standard
table.
So
how
can
we
make
this
a
little
more
interesting?
Well,
the
first
thing
we're
going
to
do
is
we're
going
to
go
down
a
little
vignette
here,
we're
going
to
go
down
the
path
of
collections.
A
So
let's
talk
about
this
new
feature
it's
in
1.2,
and
this
is
something
that
will
really
energize
your
data
model.
Quite
a
bit
now,
I'm,
pretty
excited
about
collections,
so
collections
have
three
types
set
list
and
map
each
one
has
their
own
properties
and
I'm
going
to
go
through
each
one.
So
this
is
a
nice
thing
to
add
to
your
data
model
when
you
have
something
that
needs
to
be
dynamic
inside
that
same
row,
it
keeps
you
from
having
to
do
things.
A
A
This
is
a
part
of
CQ
l3
and
in,
like
I,
said
container
1.2
and
above
so,
if
you
want
to
use
that
feature,
you're
going
to
have
to
be
on
that
version,
which
shouldn't
be
a
problem
because
in
open
source,
that's
out
there
and
engage
text
Enterprise,
it
will
be
out
very
shortly,
probably
next
month,
so
next
month
being
June.
If
you've
watched
this
in
June,
so
we
have
some
anti-patterns
that
we
need
to
talk
about
here.
A
So
one
of
those
is
the
serialization,
so
serialization
cost
is
associated
with
collection
and
that's
something
you
have
to
be
aware
of.
So
when
I
say
don't
go
crazy,
I
mean
don't
don't
think
of
this
dynamic
part
is
you're
going
to
dump
all
your
data
into
it
and
expect
good
performance
that
doesn't
say
it
doesn't
perform.
Well,
it's
just.
You
need
to
understand
that
as
your
in
your
data
model.
So
the
other
thing
is
that
there's
a
limit
to
how
many
objects
you
can
have
in
that
collection,
and
that
is
64,000.
A
That's
a
pretty
good
size
number
I
think
you
can
work
with
that
right,
so
the
serialization
cost
is
going
to
be
in
probably
going
to
be
in
your
read
time
more
than
anything.
So
if
you
have
some
tighter
essays
on
your
read
think
about
that
serialization
cost
is
an
overall
cost
in
your
budget
for
your
SLA
and
like
how
many
milliseconds
it
takes
and
just
act
accordingly.
If
you're
really
tight
on
on
milliseconds,
then
don't
put
as
much
data
in
there
because
you're
going
to
have
serialization
cost.
A
If
you
have
a
very
loose
SLA,
then
have
some
a
little
more
fun
with
that.
So
let's
go
through
these
specific
examples.
I've
got
the
table
creation
here
and
I'm,
showing
you
how
it
looks
when
you
create
the
table.
You
have
this
set
with
the
type
it
lists
with
the
type
map
of
the
types.
Well,
let's
go
through
each
one
so
set
set
is
just
like
it
sounds
it's
just
a
set
of
information,
but
the
difference
between
set
list
is
how
its
orders,
so
the
ordering
in
set
is
by
the
type
comparator.
A
So
let
me
explain
that
so
you
have
the
name.
The
collector
collection
type
set
and
then
inside
the
greater-than
less-than
brackets
you
have
the
cql
type
and
that
cql
type
is
how
it
will
manage
things
like
sorting
a
text
versus
an
inch
and
that's
the
way
you
want
it
to
be
sorted.
So,
in
my
example
here
I'm
inserting
into
this
collections.
Example,
that's
one
and
two
now
because
I'm
using
text
it
will
sort
by
text
because
one
sorts
before
two
in
the
collating
order,
that's
cool!
A
That's
what
I
want
now
I'm
going
to
go
a
little
more
in
depth
about
how
you
add
and
subtract
data.
So
if
I
want
to
add
an
element
to
the
set
I,
do
this
plus
equals
business
where
I
say
set
example
equals
set
example,
plus
the
new
element
that
I'm
going
to
add
to
the
set.
Now
when
I
do
this,
the
three
is
going
to
sort
to
the
end,
because
three
is
just
sits
in
the
collating
order.
That's
that's
fine!
A
So
that's
what
I'm,
using
a
set
for,
if
you
were
to
say
something
like
set
example,
equals
and
just
be
the
curly
bracket.
Three!
Here's
a
little
pitfall
you
should
understand:
is
it's
going
to
overwrite
that
collection?
So
you
need
to
do
the
set
example
plus
the
new
element
to
just
add
to
it,
and
that's
just
I
found
that
out
the
hard
way.
The
first
time
I
use
collections,
I'm
just
going
to
pass
that
on.
So
you
don't
have
to
do
that.
A
So
we
have
also
the
adding
an
element
to
the
to
the
beginning,
and
it's
really
because
I
know
the
sword
or
I
know
its
text.
So
in
the
second
example
I
say:
set
example:
+
0
what
kuvira's
first
and
collator
or
I'm
going
to
go
ahead
and
when
I
do
a
select,
see
that
okay
well,
look
at
that
zeroes
in
the
beginning,
because
I
have
that
sort
order.
Now,
removing
an
element
is
pretty
easy,
is
just
set
example
and
then
the
name
of
the
element
in
the
list
and
set
sorry,
and
that
is
a
random.
A
A
Next
up
is
the
list
and
a
list
is
where
you
control
the
order
by
how
you
insert
the
data
so
very
similar
to
the
set
you
have
the
collection
type
list
and
then
inside
the
greater
than
or
less
than
is
the
cql
type
and
that's
the
ql
type
again
is
it's
listed
on
our
document.
You
can
see
there's
a
lot
of
them
as
Long's
in
tax
time
stamps
time
UUID
goes
on
and
on
and
on,
but
that's
the
that's
the
type
that's
being
enforced,
but
it
has
nothing
to
do
with
the
sort
order.
A
So,
when
I
look
at
my
insert
now,
I
have
these
square
brackets
around
it.
But
this
is
more
like
what
you
would
expect
in
an
array
like
here's.
The
order
that
I
want
one
and
two
that's
the
order.
It's
going
to
be
when
I
do
a
select.
So
how
do
we
manage
that
order
again?
Here's
some
operators
on
that
so
very
similar
to
the
to
the
sex.
We
have
this
update
collections
example
and
then
I'm
going
to
do
list
example
equals
let's
example,
plus
and
then
the
three.
A
A
Now
here's
one
of
my
favorites-
that's
fits
my
favorite
right
now,
because
I
think
it
has
the
most
used
right
now
it
is
a
map.
So
map,
of
course,
is
the
key
in
a
value
and
that
the
key
is
sorted
by
the
cql
type.
So
this
is
this
is
something
to
understand.
So
in
this
example,
here
I
have
this
map
and
an
int
and
a
text.
A
So
the
cql
type
of
the
key
is
int
and
the
cql
type
of
the
value
is
text
it's
going
to
sort
by
the
int,
so
the
numerical
value
is
going
to
be
that
collating
order.
So
if
I
look
at
this
example,
where
I'm
actually
inserting
it,
you
can
see
that
I'm
I
have
this
math
or
the
curly
brackets
around
it.
It's
1,
colon
and
then
the
name
and
then
text
of
one
two
colons
text
or
two
it's
going
to
sort
by
the
1
and
the
2.
So
let's
look
at
the
operators
on
that.
A
If
I
want
to
update
an
existing
element,
I
call
it
out
by
a
fad
map
example
3
and
I
in
this
case,
I
change
it
to
trace
instead
of
3.
So
now
it's
just
going
to
update
one
thing
side,
the
map
very
handy
that
could
be
really
cool
in
your
data
model.
If
you
think
about
that
dynamic
updates,
it's
inside
the
map
now
keep
in
mind.
A
This
is
important
because
if
cassandra
has
row
level
isolation,
that
means
when
you
do
a
row
level
operation
like
this,
that
you
get
a
consistent,
read
you're
not
going
to
get
a
half
a
client
reading
that
read
will
not
get
half
of
the
data.
It
will
get
a
consistent
picture
so,
as
you
have
things
updating
all
these
lists
and
meh
sets
and
maps,
the
clients
are
doing.
The
reads:
will
get
a
consistent
list
consistent,
set
consistent
map
to
because
it's
all
on
the
same
row,
level.
A
Isolation
very
important
finally
delete
a
little
different
is
where
we
actually
have
the
delete
command.
So
we
say:
delete
this
map
example
and
then
the
element
number
three
inside
of
it
and
that
will
dynamically
remove
that
one
piece.
So
what
are
we
going
to
do
with
this?
We've
got
this
cool
collection
stuff.
How
would
we
use
it?
A
So
it's
like
bank
or
something
when
they
say
hey
the
last
time
you
logged
in
with
the
date
and
here's
the
IP
address,
so
I
need
to
store
that,
along
with
the
user
record,
so
I
can
have
a
nice
denormalize
data
structure,
so
I'm
going
to
take
advantage
of
that
row
level.
Isolation
as
well,
so
I'm
only
updating
one
row
with
some
dynamic
information
and
it's
consistent.
So
if
another
reader
comes
along,
it'll
get
a
consistent
picture.
So
how
am
I
going
to
do
this
now?
A
If
you
notice
also,
we
have
where
I'm
using
a
tiny
UID
for
the
key
and
that's
the
way
I
want
it
to
sort
a
time.
Uuid
is
essentially
a
time,
and
that
has
a
resolution
down
to
microseconds.
The
timestamp
goes
to
a
millisecond,
which
is
great
whenever
you're
displaying
it
to
a
user.
But
when
you
use
time,
UID
you're
trying
to
get
uniqueness
and
really
you
need
to
get
down
to
the
microsecond,
because
that's
that's
where
you
start
getting
the
resolution
that
makes
unique
work.
A
If
you
do
it
by
millisecond,
lots
of
things
can
happen
in
a
millisecond
on
a
computer.
So
the
time
UID
is
really
helpful
whenever
you're
trying
to
get
a
unique
value,
but
it
also
sorts
well-
and
so
in
this
case
I'm
going
to
sort
it
to
like
the
last
thing
that
happened.
So,
let's
take
a
look
at
how
I
would
use
this.
A
It
creates
a
time
UID
and
a
tiny
UID
is
a
you
know,
like
I
said
this
unique
part
with
a
microsecond,
so
it's
going
to
pull
that
informations
as
part
of
it.
It's
going
to
use
the
current
information
that
it
has
been
system
create
just
a
tiny
UID
for
you.
Now,
if
I
have
multiple
nails
in
here,
it's
going
to
use
the
same
time,
user
ID,
because
it's
going
to
happen
so
that's
also
very
convenient.
A
So
what
I'm
doing
essentially
is
I'm
changing
laughs
log
into
right
now
and
then
I'm,
adding
that
now
with
this
IP
address,
and
that's
just
going
to
add
that
to
that's
going
to
insert
this
new
record
so
now.
The
next
thing
I'm
going
to
do
is
whenever
I
add
that
I'm
going
to
go
back
and
I'm
going
to
be
able
to
see
that
that
will
help
you
know
what
IP
address
is
this
person's
logged
into?
However,
what
we're
probably
going
to
run
into
is
a
problem
where
I'm
going
to
have
a
lot
of
login.
A
So
if
you
have
someone
who's
logging
in
all
of
the
time,
you
may
want
to
not
grow
out
that
list
again
going
back
to
the
serialization
cost
and
maybe
even
limit
sides
of
the
collection.
So
here's
here's,
my
kind
of
spicy
upgraded,
which
is
the
TTL
and
a
TTL,
is
a
time
to
live,
also
known
as
an
expiring
column,
and
these
are
some
of
the
best
tools
to
use
in
some
sort
of
models
where
you
know,
data
can
just
need
to
be
disappeared
or
you're
trying
to
keep
a
certain
window
of
information.
A
In
this
case,
I
mean
I
added
this
using
TTL
of
an
it's
in
seconds
and
really
what
that
is,
is
30
days.
So
I
get
30
days
of
data
in
my
in
this
map
and
then
what's
really
nice
and
convenient
and
very
useful,
is
that
it
will
map
and
magically
disappear
at
the
end
of
30
days.
It's
just
a
great
feature
in
Cassander,
because
I've
built
plenty
of
stupid
batch
update,
delete
jobs.
It
just
go
through
and
cleaned
out
old
data.
A
You
know
that
clean
job
that
you
had
to
Khurana
or
whatever
that
it
doesn't
have
to
happen
anymore.
That's
why
this
is
very
useful,
because
we
have
plenty
of
times
where
we
just
need
data
to
live
for
a
certain
timeframe,
and
it's
just
what
do
you
do
with
it
whenever
it's
out
of
that
time
frame,
so
sander
will
just
deal
before
it
will
deal
with
it
for
you.
So
what
I
get?
A
So
when
I'm
talking
about
indexes
I'm,
not
talking
about
indexes
like
you
would
do
in
a
relational
database,
relational
databases
indexes
are
built
for
speed
inside
a
column,
and
this
is
not
what
we're
talking
about
we're
actually
doing
some
data
modeling
here,
where
we
want
to
have
our
application
intent
expressed
in
some
sort
of
data.
Mall
and
I'm
going
to
explain
this
with
some
examples,
but
that's
really
what
we're
trying
to
do
is
like
I
have
to
ask
a
question.
A
Well,
that
question
is
now
being
expressed
inside
the
data
model
and
that
more
or
less
an
index.
It
says:
oh
there's
something
I'm
going
to
look
up
and
hear
the
information
that
I
want.
So
it's
that
fast
access
to
a
very
specific
query.
So
some
some
of
you
who
have
some
experience
with
Cassandra
or
have
been
around
for
a
while
know
that
secondary
indexes
exist,
secondary
indexes
in
Cassandra,
are
not
relational
indexes
again.
Relational
indexes
are
built
for
speed.
A
Secondary
indexes
are
not
built
for
speed,
they're
built
for
convenience,
and
this
goes
back
to
the
BigTable
paper
at
Google,
where
secondary
indexes
were
meant
to
find
a
certain
column
value,
because
you
can
have
a
random
amount
of
columns.
It's
very
hard
in
a
BigTable
model
to
find
a
specific
column
with
a
value
in
it.
So
secondary
indexes
were
like
a
map
to
find
that
okay,
I,
have
a
column,
name
and
I
need
a
value
out
of
it
so
again,
convenience,
but
not
for
performance.
A
When
you
need
performance
and
you're
in
looking
up
something,
I'll
show
you
how
to
do
it.
So
my
single
most
important
thing
to
point
out
about
when
you
create
an
index
to
look
up
data
use
the
information
you
have
on
hand.
If
your
application
has
a
certain
set
of
information,
use
that
don't
do
a
get
to
get
more
data,
don't
calculate
things
if
you
can
help
it.
Sometimes
you
need
to,
but
please
be
thoughtful
of
how
you
create
your
indexes
and
the
pre-read
thing
is
really
probably
the
biggest
thing
you
don't
want
to
do
so.
A
Here's
our
goals
with
our
index
we're
going
to
use
a
row
key
we're
going
to
create
a
row
key
that
will
give
us
the
speed
and
we're
going
to
use
wide
rows
for
the
efficiency,
meaning
that
once
you
get
a
row,
key
you're
going
to
a
specific
server
that
key
exists
on
one
server
and
then
that
row
exists
on
the
server
and
when
you
use
a
wide
row
in
the
slice
you're
minimizing
this
seek
because
you're
grabbing
it
all
in
one
shot.
So
that's
what
we
want!
That's
inefficient!
So
let's
go
through
some
examples.
A
So
my
first
one
is
a
keyword
index
and
this
is
probably
the
most
basic
and,
if
you've
done
this
before
you'll
recognize
this.
You
might
also
recognize
this
if
you've
watched
any
of
my
other
data
modeling
talks
about
my
video
I
have
a
video
database
example
out
there.
So
I'm
just
uses
again
because
it
works.
So
what
a
keyword
index
is
it
uses?
A
particular
word
in
this
case.
I
have
an
example
where,
when
someone
upload
the
video
they
put
tags
on
their
video
cat
lol
funny
and
those
tags
exist
with
the
video.
A
But
what,
if
I,
have
a
specific
case,
where
I
want
people
to
be
able
to
search
for
videos
that
have
the
word
cat
in
it,
so
doing
a
random
search
on
Cassandra
like
that,
it's
just
an
anti-pattern.
It's
not
going
to
work
very
well.
If
you
put
secondary
indexes
on
there,
it's
not
going
to
be
very
fast.
It's
that's
just
the
wrong
way
to
do
it,
and
the
way
to
do
it
is
like
I
was
saying
you
want
to
make
it
fast
and
efficient
with
creating
your
own
index.
A
So,
in
this
case,
what
I'm
doing
is
I'm
taking
information
I,
have
the
tags
and
I'm
just
going
to
parse
them
out
so
I
have
my
cat.
It's
a
keyword,
I'm
going
to
use
that
and
I'm
going
to
use
that
as
the
key
the
row
key.
So
if
you
look
at
my
table
create
here,
the
tag
is
the
primary
key
and
then
the
video
ID,
which
is
the
actual
video
that
it
belongs
to
it's
going
to
create
this
wide
row.
That's
the
second
element
in
the
primary
key.
A
So
every
time
someone
adds
a
video
with
a
cat
in
it.
It's
going
to
put
that
video
ID
in
the
row
and
just
grow
up
dynamically
and
there's
probably
going
to
be
a
ton
of
cat
videos
right,
that's
what
all
the
videos
on
the
internet
have,
and
it's
just
going
to
grow
that
needs
to
so
now,
when
someone
says
I
think
give
me
all
the
videos
with
the
word
cat
in
it,
then
I'm
going
to
be
able
to
take
them
right
to
this
one
row
and
then
grab
a
slice.
A
So
that's
a
basic
one,
so
this
is
actually
taken
from
a
real
world
example
that
I
worked
on,
but
this
is
an
alteration
to
what
I
just
was
talking
about,
where
let's
say
that
you
have
a
table,
a
user
table
and
you
want
to
look
at
someone
by
their
email
address
now.
If
you
create
a
sec
and
Exxon
email,
that's
not
going
to
be
fast.
It's
going
to
be
convenient
if
you
put
a
secondary
index
on
the
user
table,
but
in
our
case
we
want
to
make
this
fast.
A
We
want
to
find
someone
quickly
based
on
their
email
address,
so
the
the
pattern
to
do
that
would
be
to
maybe
put
the
entire
email
in
a
row
key
and
then
maybe
the
user
ID
in
a
column,
but
essentially
what
you're
doing
is
creating
a
big
call.
Key
value
store,
which
isn't
very
efficient
because
you're
going
to
be
spreading
things
all
over
the
place
and
it's
just
not
not
the
best
way
to
do
things
in
Cassandra.
We
want
to
stick
with
the
wide
row
if
possible,
so
what
I?
A
A
So
you
might,
if
you
had,
like
a
bunch
of
columns,
say
or
a
bunch
of
emails
up
from
one
domain,
you're
going
to
have
a
lot
of
users
inside
of
that
row
and
what
I
would
then
caution
against
if
you're
doing
something
like
this
and
you
had
like
yahoo.com
or
gmail.com,
which
is
a
massive
Delaine,
then
you
can
even
take
it
down
a
little
further.
Take
some
letters
out
of
that
username
and
get
a
better
a
better
partition
out
of
that.
A
So
you
can
mix
and
match
this
if
you
don't
have
to
break
it
off
at
the
at
symbol,
but
think
about
the
concept
here.
We're
going
to
take
some
part
of
that
name
and
then
use
that.
So
let
me
expand
this
into
a
different
type
of
thing.
Just
kind
of
drive
this
home
again
take
it
from
a
real
world
example.
A
Now
I'm
going
to
create
partitions
based
on
the
fact
that
I
know,
there's
going
to
be
a
lot
of
whatever
I
have
and
so
I'm
going
to
try
to
keep
this
I'm
going
to
have
a
good
balance
between
rows
and
how
many
Collins
I'm
going
to
have
the
number
of
cons
I'm
going
to
have
is
really
based
on
my
SLA.
So
the
more
columns
you
have
it's
going
to
be
harder
to
keep
those
smaller
access
times,
just
based
on
the
fact
that
there's
going
to
have
to
go
further
out
to
find
the
data.
A
If
you
are
working
on
shorter
column,
values
or
in
a
shorter
amount
of
columns,
then
it's
a
faster
access
pattern.
So
there's
a
balance
there
somewhere.
You
know
maybe
a
hundred
thousand
columns
somewhere
that
ten
thousand
columns
really
based
on
what
you're
trying
to
drive
for
your
SLA.
But
how
do
you
even
get
to
the
point
where
you
can
pick
and
choose?
This
is
how
you
can
do
it
so,
with
this
product
index.
A
I
want
to
know
how
many
part,
how
many
parts
I
have
in
a
particular
store,
so
I
have
I,
have
a
store,
number
and
a
part
number
an
account.
These
are
the
three
things
I
have
well
I
want
to
count,
but
I
have
the
store
in
the
part
number.
So
how
am
I
going
to
create
a
lookup
key
for
that
now?
How
I'm
going
to
do
this
is
I'm
going
to
create
this
product
index
and
I.
Have
this
I'm
breaking
up
the
part
number
into
four
four
digits?
A
So,
when
I
have
the
question,
your
store,
867-5309
has
three
of
part:
seven:
oh
seven,
nine,
seven,
four,
eight
five,
seven
five
I'm
going
to
insert
those
parts
together
the
parts
of
the
numbers,
then,
whatever
I,
have
that
question.
I,
get
that
really
fast
and
efficient
query.
Now
I'm
going
to
be
able
to
get
exactly
what
I
need
in
within
milliseconds.
That's
what
I'm
hoping
to
do?
A
It's
not
a
scan
on
the
database
I'm
not
going
I'm
going
going
to
a
full
table
scan
or
a
ghost
batch
or
may
not
have
to
create
a
index
to
make
it
faster.
It's
just
there.
Now.
This
means
there
there's
a
couple
of
things
that
this
means
is
that
you're
going
to
have
to
manage
your
indexes
as
part
of
inserting
your
data,
and
so,
if
you're
back
to
my
video
example
with
the
tag
index,
if
I
insert
a
new
video,
I'm,
probably
gonna
have
to
insert
multiple
times
into
a
tag
index.
A
That's
okay,
remember
Cassandra
likes
to
do
right
right.
It
can
do
all
day
long
every
day,
millions
of
writes
per
second,
so
doing
multiple
writes
on
a
single
access
is
not
a
problem
and
actually
it's
kind
of
encouraged.
That's
the
pattern
that
we
want
to
follow,
and
so
using
that,
along
with
how
you
create
indexes,
is
a
really
good
pattern.
A
Okay,
so
then
my
final
index
here,
which
is
a
little
more
complicated,
but
hopefully
you
get
your
juices
flowing
on
your
next
model-
is
a
bitmap
index
and
it's
a
bitmap
pipe
index.
I
should
be
very
careful.
So
how
does
this
work?
This
is
not
built
in
a
container
by
the
way.
This
is
unbuilding.
This
myself,
so
bitmap
index
in
my
definition,
is
going
to
have
multiple
parts
to
a
key
and
I
need
to
look
it
up
by
any
one
of
those
parts.
A
So
I'm
going
to
create
a
truth
table
that
these
different
combinations
of
examples,
don't
worry,
don't
freak
out.
So
when
I
do
this
and
I
have
all
these
different
combinations
of
say
three
fields,
it
means
I,
have
seven
different
options.
That's
of
course,
there's
no,
no
choice.
It's
just
seven
different
options.
That
means
I
have
to
create
seven
inserts
for
one
set
of
data
and
in
my
a
for
field,
I
have
fifteen.
So
what
do
I
mean
by
that?
A
A
If
I
have
all
three
again
I'm
cool
with
that
with
this
truth
table
is
saying,
is
that
I
need
to
account
for
all
the
different
choices
in
one
shot,
so
I'm
really
really
really
pre
optimizing
for
the
read
here,
basically
creating
views.
So
when
I
do
the
write
cycle,
whatever
let's
say
I
go
park
that
car
in
the
lot
I
have
a
vehicle
ID
and
a
lot
ID
when
I
say
okay,
this
is
where
it
is.
I
need
to
insert
that
in
seven
places
and
those
different
combinations.
A
Let
me
show
you
how
that's
done
so
I'm
going
to
create
this
table
this
car
location
index.
My
first
three
things
make
model
in
color
now
are
going
to
make
up
this
compound
row
key
there's
three
different
options
in
there.
There's
a
vehicle
ID
and
a
lot
ID
that
are
associated
with
the
car
itself,
so
I
create
a
vehicle.
Id
is
one
of
the
parts
of
the
primary
key,
so
it
will
create
a
wide
row.
So
I
have
these
three
things
make
model
and
color.
A
How
does
it
look
on
the
insert
so
I've
put
in
all
seven
inserts
here,
and
you
can
see
the
pattern
here?
What
I
have
the
first
one
is
I
insert
all
of
them
and
then,
if
there's
different
combinations
all
through
those
seven
different
combinations
of
inserting
blanks
and
one
thing,
but
if
you
notice
it's
just
a
repeat
of
the
same
data
over
and
over
with
different
combinations
in
the
primary
key
and
so
I'm
sorry,
there
okey.
So
now
what
did
I
do
all
these
inserts
I
could
ask
interesting
questions
now.
A
I
might
on
my
data
model
that
I
created
as
an
example
on
my
own
machine
here,
I
inserted
a
lot
of
different
cars,
so
I
could
ask
some
different
questions.
So
what
about
that?
So
now
what
I
do
is
select
I
say:
give
me
the
vehicle
ID
in
line
ID,
where
I
only
think
I
know
is
the
blue,
Ford
I,
don't
know
what
the
model
is
to
compute
anything
Mustang
tempo,
whatever
you
explore
but
I
know,
there's
a
blue
Ford.
Okay,
when
I
put
in
that
that
combination
exists
in
a
row
key.
A
It's
one
row
key
that
I'm
looking
up
and
it's
very
fast
and
because
the
vehicle
ID
is
in
there
is
rose
very
efficient.
That's
my
answer.
Here's
my
vehicle
ID
in
my
line,
ID.
Now,
let's
get
even
more
general.
Let's
say:
I
just
know
that
it's
a
blue
car.
How
many
were
they'll
blue
cars
at
ok,
now
I
can
get
into
this
or
I
can
say.
A
The
blue
is
just
in
one
option,
so
notice
I
get
a
lot
more
answers
that
way,
which
means
that
if
you
were
to
actually
look
at
the
column
counts
whenever
you
do
this,
the
left
options
you
have
on
your
row
key
the
wider.
The
row
probably
will
be
because
there's
going
to
be
more
things
that
fit
in
that
bucket.
So
you
take
advantage
of
the
dynamic
nature
that
wide
row
by
using
some
data
structure
like
this
again.
A
This
is
very
specific,
but
this
should
hopefully
get
you
thinking
about
how
you
can
use
some
very
interesting
combinations
of
your
data
in
your
row
key
and
how
you
construct
your
data
model
for
those
fast
look.
Ups,
that's
what
I've
done
I've
optimized
this.
So
that
was
my
last
example.
So
this
hopefully,
will
get
your
game
up.
A
Whatever
you
do
your
data
model
and
think
about
how
it
can
really
make
your
data
application
using
Cassandra
a
lot
better
and
don't
settle
for
boring,
just
don't
think
you
have
to
throw
things
into
a
NPV
table
and
then
hope
for
the
best
and
do
some
you
know
doing
some
application
level
joins,
or
things
like
that.
But
I
see
those
things
that
makes
me
sad
because
there's
better
way
to
do
it.
The
worst
thing
you
could
do
is
take
say
a
relational
model
and
just
copy
and
paste
it
into
Cassandra.
A
That
is
not
the
right
way
to
do
things.
That
is
a
complete
anti-pattern.
So
what
we
want
to
see
is
a
mixture
of
those
things,
but
really
just
digging
into
what
Cassandra
does
so
Beth
is
distributing
your
data
scaling
out
like
crazy,
but
also
being
online
all
the
time,
so
with
all
that,
going
on
think
about
your
data
model
and
how
your
application
will
work
with
time,
no
downtime
a
good
thing,
so
we
have
one
more
and
I
hope
you're
going
to
be
there
for
this.
This
is
our
Cassandra
summit.
A
June
11th
I
get
the
big
room
and
I'm
going
to
be
talking
about
the
world's
top
next
top
data
model.
This
will
be
a
continuation
of
this
series.
That'll
be
the
third
part
of
this
series.
I
don't
know
if
there
will
be
any
fireworks
or
anything
crazy
going
on,
but
I
hope
to
see
you
there.
If
you
need
to
be
there
because
I
know
you
do
look
at
what
we
got
going
on.
First
of
all,
it's
a
Golden,
Gate
Bridge
it'll,
be
right!
A
Next
to
that
actually,
but
look
at
this,
why
not
I
mean
I
could
go
on
I
mean
look
at
the
companies
that
are
going
to
be
there
talking
about
how
they
use
Cassandra
and
they're
very
successful
doing
this.
So
why
would
you
want
to
be
there
why?
Why,
after
that,
I
don't
have
any
reason
I'm
gonna
be
there?
So
just
because
you
know,
I
got
a
lot
of
love
for
you.
I
gave
you
a
discount
code,
use
my
discount
code
to
be
there
and
here's.
The
added
bonus
is
that
we
are
doing
expert
cables.
A
I
will
be
there.
You
bring
your
data
model.
Let's
talk
about,
I
will
be
all
over
the
place,
but
you
know
I
really
want
to
talk
to
people.
This
is
why
I'm
going
I'm
doing
two
talks
and
the
third
talk
or
the
second
talk
I'm
going
to
do
there.
It's
about
our
new
drivers,
so
I
really
want
to
push
two
things
here.
Data
model
is
important,
using
our
driver
is
going
to
help
you
get
there
faster,
and
our
drivers
out
is
some
general
availability.
A
Here's
the
link
where
Michaela,
Segura
and
I
am
going
to
do
a
presentation,
joint
presentation
on
this
on
June
12th
the
second
day
and
we're
going
to
talk
about
all
these
things.
Doesn't
talk
about
data
modeling
I'm,
going
to
tell
you
how
to
do
this
with
code?
How
to
build
your
application
with
this?
We're
really.
It's
amazing
the
some
of
the
things
that
our
new
driver
can
do
for
you
I
really
hope
that
you
can
be
there.
So
that's
it.