►
Description
Presentation and discussion for CEP-7: Storage Attached Index by Caleb Rackliffe. https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-7%3A+Storage+Attached+Index
CEP = Cassandra Enhancement Proposal.
What is Apache Cassandra?
Apache Cassandra is an open source NoSQL distributed database trusted by thousands of companies for scalability and high availability without compromising performance. Linear scalability and proven fault-tolerance on commodity hardware or cloud infrastructure make it the perfect platform for mission-critical data. https://cassandra.apache.org
What is the Contributor Meeting?
The Apache Cassandra community hosts informal monthly meetings to enable real-time collaboration for contributors to discuss CEPs and other issues, and ask questions. Meetings take place the last Tuesday of each month at 10:00 PT / 13:00 ET / 17:00 UTC / 22:30 IST. Learn more and join: https://cwiki.apache.org/confluence/display/CASSANDRA/Cassandra+Contributor+Meeting
Learn and Participate
Meetups: https://www.meetup.com/cassandra-global/
Apache Cassandra Website: https://cassandra.apache.org
ASF Slack #cassandra: https://join.slack.com/t/the-asf/shared_invite/zt-1t3o62k9f-fkEZ31LfB~plEHZjh~0sGg
Twitter: https://twitter.com/cassandra
LinkedIn: https://www.linkedin.com/company/apache-cassandra/posts/
Planet Cassandra Website: https://planetcassandra.org/
Planet Cassandra YouTube: https://www.youtube.com/@PlanetCassandra/streams
Planet Cassandra Discord: https://discord.com/invite/Ut8YctQWac
A
Cool
good
morning,
everyone,
my
name,
is
Hugh
Ashbrook
I
work
on
the
Community
side
of
things
with
Cassandra.
This
is
Welcome
to
our
monthly
contributor
meeting,
where
we
look
at
different
CPS,
Cassandra
enhancement
proposals
and
the
work
going
on
there,
and
we
hear
from
David's
working
on
them
and
just
go
into
more
detail
about
what's
happening
and
all
that
kind
of
thing
today
we're
going
to
be
looking
at
cp7
storage
attached
indexing,
where
Caleb's
going
to
be
talking
about
it
about
the
work
there.
Some
very
exciting
stuff
happened.
A
A
If
you
have
any
questions
as
we
go
just
pop
them
in
the
chat
there,
you
can
also
unmute
and
ask
questions.
If
you
need
that's
all
good,
there
will
be
q
a
at
the
end
specifically,
but
if
you
want
app
questions
as
we
go,
just
just
jump
in
with
them,
it's
very
informal
happy
to
chat
about
whatever
but
yeah
Caleb's
gonna
go
into
detail
here.
So
I
will
I'll
hand
over
Caleb
and
thank
you.
B
All
right,
hello,
everybody,
so
just
to
kind
of
provide
an
overview
of
what
to
expect
from
this
time.
Wise.
You
know,
20
30
minutes
is
what
I
expect
it'll
be
QA
at
the
end
and
I
don't
have
any
hard
stops
so
I'll,
you
know
I'll
hang
around
as
long
as
people
want
to
talk,
or
my
stomach
doesn't
complain
too
too
hard
to
me
about
about
grabbing
lunch.
B
So
so
what
I'm
going
to
do
is
go
through
kind
of
the
really
quick,
very
Abridged
history
of
the
secondary
indexing.
You
know
indexing
in
general
in
the
Cassandra
ecosystem.
You
know
and
kind
of
how
the
product
project
has
approached
that
from
the
beginning
and
talk
about
some
of
our
various
attempts
to
to
solve
that
problem
or
to
do
something
in
that
problem.
Space
leading
up
to
the
storage
attached
index
project,
which
is
cep
E7
and
I
I'm
a
I'm
imagining
everyone
can
see.
B
My
screen
share
I
tried
to
make
this
pretty
huge
and
legible,
but
I
may
refer
to
some
of
these
documents.
These
are
all
you
know
publicly
available
and
I
can
share
links
and
all
that,
but
we'll
go
through
that
and
then
I'll
talk
a
little
bit.
You
know
some
more
specifics
about
storage,
Dash
indexing
and
how
that
project
is
going.
B
What
it's
sort
of
you
know
current
state
and
next
steps
are.
You
know
where
we
expect
to
see
that,
and
you
know
in
release
terms
and
and
and
all
that,
so
so
I'll
kind
of
go
back
and
start
at
the
beginning.
You
know
Cassandra
when
it's
sort
of,
like
first
got
dumped
into
into
open
source
space.
First
we
came
in
Apache
project.
B
You
know
you
have
the
the
databases
of
distributed
key
Value
Store.
You
know
it's
very
primitive
in
terms
of
its
cray
capabilities
very
limited,
and
there
are
just
a
lot
of
things,
a
lot
of
problems
you
have
to
solve
with
data
modeling,
rather
than
being
something
like
the
relational
databases.
Most
people
are
coming
to
this
from
where
you
can
sort
of
throw
up
something
in
you
know,
whatever
normal
form,
you
want
and
then
can
be
reasonably
assured
that
you'll
be
able
to
query
it.
B
The
way
you
want
so
again
they're
early
sort
of
history
of
Cassandra,
we
just
had
people
where
we
said.
Okay,
you
want
to
query
your
data
that
way,
you're
just
going
to
need
another
table.
Sorry
right
and
you
know,
for
people
who
needed
Cassandra
for
what
I
was
good
at
this
was
this
is
okay
I
mean
the
story
worked
worked
in
in
some
cases,
however,
we
we
did,
we
did
take
some.
B
Let's
just
have
a
hidden
table,
a
hidden
local
table
that
that
will
will
back
the
index
that
literally
uses
the
same
storage
engine
Primitives
as
regular
tables
do
and
and
that's
kind
of
how
we'll
we'll
approach
that
it
is
completely
separate
from
the
you
know:
storage
artifacts,
on
disk
for
the
backing
table.
You
know
we
have
our
whole.
B
You
know
design
where
we
have
mem
tables
and
SS
tables
and
and
all
that
indexes
and
Cassandra
at
that
point,
they're
just
a
completely
separate
and
parallel
parallel
sort
of
ecosystem
on
disk
right
and
over
time.
I
think
you
know,
a
lot
of
difficulties
emerged
with
that
I.
Think
one
of
the
the
first
big
difficulties
was
that
just
from
a
from
a
storage
and
on
disk,
you
know
usage
perspective.
B
You
know
with
project
like
leucine
and
and
and
those
projects
that
had
been
working
on
that
problem.
You
know
for
for
a
decade,
so
we
had
something
done.
This
was
you
know,
was
blooded
and,
and
you
know,
used
too
much
space,
and
you
know
that
has
some
sort
of
knock-on
effects
for
for
the
performance
of
you
know,
rights
and
reads,
and,
and
so
things
were
sub-optimal
there,
the
other
thing
that
is
really
sub-optimal
about
the
way
we
approached
that
was
just
the
general
operational
environment
was
difficult.
B
B
Those
things
were
all
because
the
sort
of
storage
situation
for
the
index
is
completely.
You
know
parallelism
separated
from
the
backing
table.
We
we
were
not
able
to
do
those
things
easily.
We
ended
up
creating
you
know
an
entire
management
apparatus
around
trying
to
figure
out
whether
the
index
was
built
or
not.
B
So
you
know
it
was
always
sort
of
something
that
didn't
get
first
class
treatment.
I
think
you
know
within
the
project,
so
I
think
this
was
now
maybe
up
to
about
2014
2015
time
frame
around
that
time,
a
little
bit
before
that.
But
around
that
time
we
had
something
called
sassy
sort
of
you
know
came
onto
the
onto
the
stage.
This
is
before
we
had
the
cep
process
and,
and
so
I
think
the
sort
of
like
large
contributions
from
their
parties-
and
you
know
major
new
things.
B
There
wasn't
really
a
community
process
for
that,
but
a
bunch
of
people
at
Apple
built
this
thing
called
sassy
sassy
stood
for
storage
or
SS
table
attached
secondary
index
and
in
a
lot
of
ways,
this
sort
of
anticipated.
What
essay
I
became
and
I'll
talk
about
that
a
little
bit,
but
the
idea
with
sassy
and
again
this
is
something
that
has
actually
carried
forward
in
Sai-
is
that
when
we
looked
at
secondary
indexes
in
Cassandra,
we
would
think
about
them
in
relation
to
and
attach
to
Cassandra's
major
storage
engine
components.
B
So
we
think
about
in
Cassandra.
You
know
mem
tables
and
SS
tables.
Okay,
we're
going
to
actually
have
our
index
components
attached
to
those
things,
follow
the
life
cycle
of
those
things
and
that'll
open
up
a
bunch
of
of
nice
optimizations
that
over
time
you
know
we
should
be
able
to
take
advantage
of.
So,
for
instance,
you
know
sassy
sort
of
made
it
possible
to
say
Okay.
B
If
you
have
a
situation
where
you
have
existing
data
and
you
want
to
put
an
index
on
that
data-
let's
say
I,
you
know
have
about
20
column
table
and
you
know:
I've
got
fairly
large
partitions
and
I
want
to
search
within
those
partitions.
You
know
on
something
other
than
the
primary
key
right,
or
it
could
even
be
some
component
of
the
primary
key
right,
but
I
want
to
I
want
to
do
like
a
numeric
range
search
or
I
want
to
do.
B
You
know
a
like
query
or
whatever
else
it
is
so
I
put
an
index
on
that.
On
that
column
there
you
go.
The
index
is
obviously
not
going
to
be
usable
until
it's
built
and
that
you
know
takes
some
time,
but
let's
say
I
get
80
of
the
way,
and
this
is
a
big
data
set
in
a
local
context.
I
get
80
of
the
way
through
and
the
node
explodes,
or
you
know,
I
I
have
to
shut
down
the
node.
You
know
for
some
reason
or
it's
something
fails
for
whatever
reason.
B
Now,
when
I
come
back
up
with
sassy
again,
you
know,
with
with
the
serve
default.
The
old
you
know
Legacy
secondary
index,
we
were,
you
know,
never
able
to
build
a
good
mechanism
for
doing
incremental
index
building
for
sassy
or
for
Sai,
because
all
the
index
components
we
have
are
attached
to
the
backing.
You
know
core
on
this
components.
We
can
just
say
Okay,
let's
just
look
at
all
the
SS
tables
and
which
ones
have
I
built
indexes
for
cool
okay.
B
Well,
this
one
and
this
one
okay
well,
I,
have
you
know
these
20
of
the
remaining
Essence
tables?
I,
don't
have
indexes
for
yet.
So
let's
build
those
while
we,
you
know,
while
we're
keeping
the
index
unavailable
for
queries
right,
let's
just
build
those
and
then
when
they're
done
we're
done,
we
can
make
the
index
available.
We
don't
have
to
go
back
and
start
from
the
beginning
right.
B
So
so
the
SS
table,
attached
concept
is
sort
of
one
of
the
say,
the
big
two
or
three
Concepts
that
that
Sai,
you
know,
cep
7
build
on,
and
so
so
that's
kind
of
one
big
thing
and
so
sassy
introduced
that
the
the
problem
with
sassy
so
made
some
nice
conceptual
advancements.
But
sassy
had
a
couple
of
problems.
B
The
the
query
side
of
things
still
works
best
when
we
have
a
large
local
sample
space,
we
have
like
token
restricted
queries
or
queries
within
a
large
partition.
You
certainly
don't
have
to
do
that,
but
that's
just
where
you
get
the
most
query
through,
but
and
when
you,
when
you
do
that
indexing
a
partition
ends
up
not
being
super
efficient.
If
all
you're
doing
is
saying,
hey
well,
this
partition
might
be
a
match
or
might
have
a
match.
B
B
If
we
wanted
to
do
something
interesting
with
sassy
or
a
sassy
like
system,
the
other
thing
with
sassy
is
that
it
did
not
take
advantage
of
a
lot
of
opportunities
for
I'd,
say
like
compression
answer,
optimization
of
of
the
on
disk
storage
picture
when
you
indexed
more
than
one
column
on
a
backing
table.
So
there
were
a
lot
of
things
that
that
were
duplicated.
B
You
know
grew
linearly
with
the
number
of
columns
that
you
indexed,
you
know
modulo
what
kind
of
what
data
type
you
had
and
some
you
know
other
details
around
that,
so
that
was
kind
of
the
second
big
thing
with
sassy.
The
third
thing
was
sort
of
aside
from
that.
You
know
sort
of
area
of
missed
opportunity
based
on
the
fact
that
a
bunch
of
you
know
indexed
columns
shared
a
bunch
of
things
related
to
the
SS
table
and
at
the
stable
level.
B
Is
that
the
actual
sort
of
terms
dictionary,
the
actual
inverted
indexes
or
the
numeric?
You
know
range
in
the
indexes
and
then
the
postings
sort
of
bringing
some
terminology
from
seeing
the
postings
for
individual
column
indexes
in
in
sassy
those
formats
on
this
or
not?
It's
not
optimized
for
for
skipping
for
just
general
General
on
this
usage,
and
so
there
were
a
lot
of
opportunities
to
improve
there.
B
So
so
we
we
sat
back
and
we
said
okay,
you
know,
can
we
can
we
evolve
sassy?
Can
we
try
to
make
minor
optimizations
to
to
sassy
to
sort
of
get
it
where
we,
where
we
want
it
to
be,
and
the
the
results
of
kind
of
that
whole
discussion
I
mean
a
lot
of
that.
That
was
mostly
inside
data
Stacks.
But
the
result
of
that
discussion
was
end
up
being
cep7.
B
So
as
the
sort
of
communities
process,
the
cep
process
for
making
major
enhancements
to
the
database
matured.
That
sort
of
went
along
with
with
the
creation
of
cp7,
as
you
can
see,
we're
up
into
like
the
30s.
Now
this
was
a
fairly
early
cep,
I
guess
in
the
history
of
ceps,
not
not
in
the
first
couple,
but
definitely
in
that
first
raft
of
things
and
sort
of
here
we
described
we
described
what
we
would
do
in
in.
B
We
took
a
lot
of
the
concepts
from
sassy
in
terms
of
like
the
essence
table,
attachment
and
sort
of
the
framework
that
Sassy
had
to
have
built
into
the
into
the
core
database
around
SS
table
writing
for
for
listening
to
events
during
during
those
sort
of
linear
right
of
an
essays
table.
So
we
we
took
all
those
things
but
then
kind
of
everything
else
we
completely
redid.
B
One
reads
for
secondary
indexes
that
were
sort
of
Incorrect
and
we
built
a
thing
called
replica
filtering
protection
which
I
won't
go
into,
but
it's
a
fun
bedtime
read
if
you
want
to
fall
asleep,
and
so
we
we
took
all
of
the
things
that
had
potential
with
the
SS
table
attached
concept
and
we
sort
of
brought
them
all
the
way,
I
think
to
a
productionized
state
and
so
I'm,
actually
gonna
I'm
gonna.
Stop
there
actually
and
do
a
quick
check
for
questions.
I,
don't
like
to
go
too
long.
C
B
I
mean
I
I
think
the
closest
thing,
the
closest
thing
that
we
we
have
to
something
like
Global
indexes
right
now
or
materialized
views
and
I
think
that
I
think
that
that
can
become
viable
at
some
point,
especially
once
once
we
have
a
chord
I
think
a
lot
of
people's
problems
with
materialized
views
historically
have
been.
You
know
the
way
that
they
update
I,
remember
talking
to
Paulo,
like
man.
This
is
probably
like
five
years
ago
at
one
of
our
one
of
the
data
sex
engineering.
B
You
know
meetups
where
he
was
actually.
You
know
gonna
try
to
do
some
work
on
materialized
views,
and
he
just
you
know,
never
never
got
to
it
when
it
comes
to
local,
secondary
indexes
versus
materialized
views,
I
think
what
what
we'll
end
up
with
and
that
the
I
probably
should
have
talked
about
this
a
little
bit
just
in
the
like.
Why
do
we
care
about
secondary
indexes?
What
are
they
useful
for
in
a
database
like
Cassandra
in
in
the
first
place,
and
so
I'll?
B
Do
that
and
I
think
that
helps
answer
this
question
so
I
think
the
case
where
the
case
where
local
secondary
Nexus
enter
that's
going
to
be
oh,
okay,
yeah
I
know
sorry.
My
dog
is
interested
in
this
topic.
The
case
where
local
secondary
indexes
are
useful
to
me
is
when
we
have
large
local
search
spaces.
So
we
have,
we
have
token
restricted
queries
like
say
something
you
might
do
from.
B
You
know
the
analytics
side
you
have
large
partitions
to
search
across
and
I
think
this
is
going
to
get
easier,
as
some
of
the
enhancements
in
5-0
start
to
hit
the
mainstream
and
start
to
get
more
used.
When
we
have
a
situation
where
people
aren't
afraid
to
have
larger
partitions
and
they're,
not
bending
over
backwards
as
much
as
we
have
historically
to
to
break
those
things
down
the
the
local
indexes
to
me,
it's
the
optimal
choice,
see
optimal
data
modeling
Choice.
B
B
You
know
when
we're
filtering
across
those
things
like
this
is
going
to
be
I,
think
Super
useful
for,
for
that
you
know,
and,
and
there
it's
it's
not
that
I
think
in
that
case
the
these
sort
of
complexity
or
the
overhead
of
having
a
global
index.
It's
just
not
necessary
the
then
the
other
thing
is
I.
Think
that
the
when
the
query
patterns
work,
you
know
when
you
actually
have
this
sort
of
large
local
search.
Space
related
query
pattern.
B
B
We're
gonna
have
to
have
decent
messaging
around
which
one
to
use
in
which
situations
but
I
think
that
I
think
that,
especially
in
conjunction
with
a
chord,
you
know
where
we're
you
know
we're
doing
local
reads:
you
know
and
of
course,
is
going
to
be
partition
restricted
or
at
least
restricted
to
a
small
number
of
keys.
Most
of
the
time,
I
think
I,
think
I,
say
I
will
I
say
we'll
have
a
niche
there.
B
C
C
And
I
think
it
goes
down
to
and
I
don't
know
if
this
is
in
later
part
of
what
you're
talking
about,
but
into
the
performance
of
scatter
gather
like
what
should
be.
What
should
you
expect
unsafe?
Do
you
have
a
thousand
node
cluster
and
you,
you
use
an
Sai
and
you
create
an
Sai
index.
What
should
you
expect.
B
Any
given
query
so
I
think
that
when
you,
when
we're
we're
talking
about
like
high,
read
and
write
volume,
use
cases
Sai
and
any
Cassandra
secondary
index,
I
I
say
this
a
lot,
but
any
consumer
secondary
index
will
be
best
suited
for
again
that
large
partition,
large
local
local
search
space
sort
of
query.
That's
the
thing
that
will
scale
as
the
number
of
nodes
in
the
cluster
increases.
It
will
scale
along
with
that
they're.
Now.
Having
said
that,
the
way
we
do
scatter
gather
queries
in
Cassandra
is
very
naive
and
I.
B
You
know
traditionally
like
in
a
system
like
elastic
or
solar,
like
elastic
solar,
Cloud,
all
those
you
know
related
Technologies,
the
the
way
that
scatter
gather
typically
happens
is
sort
of
in
this.
Like
two-step
process.
In
this,
like
two
pass
query
sort
of
apparatus
where
you
you
go,
you
know,
hey
I,
need
I
need
to
contact.
B
B
Just
enough
for
me
to
get
some
identifiers
have
some
sorting
information
because
say:
I'm
sorting
a
lot
of
the
time
as
well
in
a
query
like
that,
so
I
can
get
these
things
and
I
can
sort
and
I
can
find
the
top
10
things
that
I
need
across
an
entire.
You
know
whatever,
let's
say
50
or
100,
node
elasticsearch
cluster
and
then
once
I
know
those
things
I'm
going
to
go.
Just
go
back
to
the
nodes
that
have
those
10
documents
and
I'm
going
to
actually
read
the
documents
in
a
second
pass
right.
B
So
so,
when
you
do
that,
you
kind
of
we
fall
kind
of
out
of
the
typical
consistency
level
apparatus
of
Cassandra.
You
end
up
having
to
sort
of
approximate
like
we
have
this
with
DSC
search,
a
product
that
some
of
you
you
know
about
where
we
have
to
kind
of
approximate.
What
that
consistency
level.
Is
you
know
if
you
want
to
map
it
to
Cassandra,
but
there
really
is
a
mismatch
there,
conceptually
and
in
Cassandra.
The
way
that
you
know
these
Global
query.
So
it's
got
to
go
to
queries.
B
B
Rather
than
all
of
it,
whereas
I
say
I
would
actually
default
to
contacting
all
of
it.
So
if
you're
doing
something
where
you're
going
to
get
back,
like
a
million
matches
for
your
query,
it's
not
going
to
be
super
useful
right
now
at
some
point
later.
I
think
Jonathan
might
actually
be
trying
to
do
some
of
this
with
like
with
the
vector
search
cep,
but
at
some
point
later,
when
some
sorting
is
involved-
and
you
know
we
have
that-
then
you
know
you
it's
just
code.
B
B
Anyway,
so
so
that
is,
that
is
the
sort
of
like
why
we
built
it.
You
know
what
kind
of
things
we
think
it'll
be
good
for
the
I
think
a
lot
of
apps,
where
you
have
where
you
have
reasonably
large
individualized
data
sets
like
if
any
of
you,
if
you
think
about
something
like
iCloud
photos
or
you
think
about
something
like
like
mint.
B
These
are
the
kinds
of
things
I,
think
that
really
SDI
should
hit
it
out
of
the
park
like
where
it
should
just
should
do
really.
Well,
the
cases
where
you
have
you
know
maybe
slightly
more
complex,
key
structures,
and
you
want
to
be
able
to
have
essentially
an
alternate
clustering
order.
You
know
you
want
an
alternate
clustering
key
where
right
now,
once
you
sort
of
set
that
your
you
know,
you're
you're
locked
into
that.
B
Unless
you
want
to
create
another
table,
you
know
and
be
able
to
do
that
without
the
storage
overhead
of
creating
another
table,
you
know
and
and
then
just
you're
also
going
to
have
this
expansion
of
General
query
capabilities,
the
the
Legacy
secondary
index,
you
know
supports
equality,
queries
at
the
end
of
the
day.
You
know
the
American
text,
equality,
queries,
there's
you
know,
support
for
simple,
simple
text
filtering
or
you
know,
tokenization.
There's
no
support
for
you
know
things
like
light
queries
which
you
know
we'll
have
shortly
with
us.
B
Ai
no
support
for
numeric
ranges,
they're
just
a
lot
of
things.
You
can't
do
and
yeah
we'll
do
all
those
things
we'll
be
a
feature.
Parity.
We
are
at
feature
priority.
Now
we
want
the
Legacy
secondary
index,
but
being
able
to
do
all
these
additional
things.
You
know
opening
up
different
kinds
of
queries.
B
C
B
Years
I
sent
her
away,
she's
she's
exiled
from
from
the
office,
but
yeah
I'm,
trying
to
think
of
anything.
Oh
so
in
terms
of
General
project
updates.
So
half
of
you
are
probably
on
the
the
mailing
list,
the
dev
mailing
list
and
all
that.
But
after
you
know
starting
man,
it
was
like
a
year
and
a
half
ago
or
something
we.
The
cep
has
now
progressed
to
the
point
where
we
are
I
mean
literally
today,
I
will
be
I
will
be
starting
the
the
merge
process.
B
B
There
are
some
things:
I
think
that
we
will
land
after
we
merge
in
terms
of
you,
know,
performance
and,
and
nothing
really,
correctness
related,
but
you
know
some
things
in
terms
of
performance
and
resource
usage.
That
I
think
we
I'm
not
quite
happy
with
right
now,
but
I
think
that
our
those
things
are
attractable
tractable
problems
for
us
to
solve
before
before
merge
or
sorry
before,
before,
like
a
a
hard
freeze
for
5-0.
B
So
so
yeah
watch
for
that.
If
you,
if
you
are
looking
to
try,
try
SII
out
once
that
does
happen,
especially
once
it's
in
trunk.
There
is
a
a
readme
that
I'm
actually
going
to
link
here,
I'm
going
to
throw
this
in
the
chat,
so
you
can
sort
of
follow
along
afterwards
this
and
you
could
even
grab
this
right
now
in
the
cpp7
Sai
umbrella
feature
Branch
for
for
the
sap
for
the
CP
and
play
with
this.
But
it
really
is.
B
C
C
B
You
know
they
they
want
to
create
an
index
on
this
column,
and
you
know
maybe
maybe
use
a
particular
index
implementation.
You
know
people
are,
people
are
used
to
this
coming
from
other
databases
where
maybe
there's
a
default,
but
it's
like
yeah,
you
know
use
use
hash
index
on
this
column
use.
You
know
this
kind
of
index
on
this
column.
B
That
is
a
story
we
can
sell
in
terms
of
ddl.
You
know
usability
in
terms
of
syntax
usability.
What
will
happen
when
5o
rolls
out?
So
it's
in
terms
of
compatibility
in
terms
of
what
we
do
syntax
wise
is
that
there
are
two
things.
There
are
two
things
that
operators
will
have
some
control
over
in
in
yaml
space.
For
now,
because
you
know
we
don't
have
transactional
metadata
quite
yet
or
let's
not
write
this
second
one
is
operators
will
be
able
to
control
what
the
default
index
is.
B
So
when
fivo
rolls
out,
if
I
were
to
make
this
create
index
statement
here
and
I,
let
that
using
Clause
out
we
would.
We
would
default
to
continuing
to
use
the
the
Legacy.
You
know
default
secondary
index,
we're
not
going
to
break
that
behavior
in
in
5.0
and
then
the
second
thing
that
users
will
have
or
operators
will
have
control
over
is
whether
whether
an
index
has
to
be
specified.
B
So
people
will
actually
have
to
think
about
what
they
want,
and
you
know,
I
I
think
this.
This
is
probably
a
good
thing
to
have,
so
it
makes
it
a
little
bit
harder
for
people
to
shoot
themselves
on
the
foot,
but
compatibility
wise.
Any
ddl
that
you
use
in
4-0
will
have
the
same
exact,
extreme
exact
effect
in
terms
of
what
kind
of
index
it
creates
and
all
that
as
we
roll
out
fibo
and
people
can
change
those
two
options
as
they
see
fit.
B
Hopefully
we
can
get
to
the
point
where
SEI
usage
has
become
broad
enough
and
it's
you
know
proven
itself
where
we
can
just
switch
that
default.
I
think
my
I
would
hope
in
our
next
major
release
that
we'll
be
able
to
do
that
now.
I
think
the
one
thing
I
haven't
really
talked
about
that
I
want
to
get
to
really
quick
care.
B
B
This
chart
on
the
left
here.
This
is
Sassy
of
the
red
and
the
Legacy
secondary
index
in
green,
where
you
can
see
how
much
these
things
grow,
as
you
add
more
indexes
to
to
a
backing
table
more
index
columns,
whereas
you
know
the
blue
SEI
here
at
the
bottom.
Your
first
index
has
your
first
index
has
the
most
information
that
needs
to
be
built
not
related
to
the
specific
column,
you're
indexing.
B
But
then,
after
that,
you
do
none
of
that
and
so
all
of
the
additional
index
columns
just
add
some.
You
know
small
incremental
amount
of
additional
disk
usage,
so
that
was
like
one
of
our
one
of
our
big
design,
goals
and
and
I
think
we
did
pretty
well
with
that.
This
is
sort
of
just
another
representation
of
the
same
data
over
here,
like
the
last
data
point
actually
on
this
chart
on
the
left
is,
is
this
right
here?
B
B
The
index
is
going
to
be
fairly
small,
so
take
those
with
a
little
bit
of
a
grain
of
salt
and
I
think
this
is
also
an
area
where
we're
after
SEI
releases.
These
numbers
are
going
to
get
better
because
there's
some
things
we
do
right
now
that
are
not
optimal,
and
now
that,
like
the
s's
table,
format,
discussion
and
all
that
stuff
has
settled
for
five
five,
oh
I
think
there's
some
fairly
fixed
things
that
we
are
going
to
be
able
to
take
advantage
of
to
de-duplicate
some
of
the
storage.
B
It
de-duplicate
some
things
and
you
know,
while
retaining
retaining
query,
query
performance,
but
I
wanted
to
go
down
to
the
very
bottom
of
this
thing.
When
I
talk
a
little
bit
about
challenges,
so
I
think
this
is
the
last
thing
I'm
going
to
talk
at
everybody
about
and
and
then
you
know,
just
any
remaining
questions.
I
guess
we
can
probably
wrap
up
so
so
I
I
alluded
to
this
a
little
bit
kind
of
in
the
sense
that
Sai
will
really
do
well
in
large
local
search
space.
B
You
know
sort
of
query
scenarios
and
one
of
the
things
that
being
sustable
attached,
and
so
this
is
kind
of
a
general
like
think
about
this.
One
of
the
things
about
being
accessable
attached
is
that
we
have
different
compaction
strategies
right.
So,
in
a
situation
where
your
secondary
index
on
disk
artifacts
are
directly
attached
to
SS
tables,
the
number
of
essence
tables
you
have
can
have
an
effect
on
query
performance
right
on
the
right
side.
We
don't
care.
B
Even
if
you
know
that's
a
fairly
large
partition,
whatever
LCS
is
going
to
do.
Great
LCS
is
going
to
be
fantastic
for
you
because
you
have
a
very
small
number
you're.
Just
you
know
you
have
you
have
the
that
slice
that
contains
that
partition
for
all
the
LCS
levels,
you're
gonna
you're
gonna
hit
a
very
small
number
of
ss
tables.
To
do
your
query,
it's
going
to
be
it's
going
to
be
super
awesome.
B
If
you
are,
you
know,
you
end
up
doing
Global
queries
on
a
table
that
uses
LCS.
It's
not
going
to
do
that.
Well
right!
That
is
a
case
where,
where
you
might
struggle
a
little
bit,
because
now
you
found
out
you're
going
to
hit,
you
know,
I,
don't
know
I'll
say
we're
going
to
hit
R3
and
we're
going
to
hit
a
third
of
the
nodes
in
our
our
cluster.
We
hit
300
something
nodes
and
a
thousand
node
clusters.
B
Well
that
that
scatter
gather
is
a
problem.
You
know
perhaps,
but
even
a
small
cluster.
Let's
just
say
it's
a
nine
node
cluster
and
we're
gonna
hit
three
notes
well
in
each
one
of
those
individual
nodes.
No
because
I
don't
have
any,
let's
say:
they're
pretty
dense
nodes
because
I
don't
have
any
token
or
partition
restrictions
there
and
I've
got
I,
don't
know.
Let's
say:
I've
got
a
couple
thousand
Essence
tables
with
LCS.
B
If
that
makes
sense,
so
so
that's
something
to
think
about
and
I
think
like
right
now,
you
know
as
we
as
fibo
releases
I,
don't
UCS
is
not
going
to
make
a
notifiable,
probably
from
what
I
can
see,
although
I'm
not
sure
it
rolling
out
into
5-0
I.
Think
if
you're
going
to
have
Global
scatter
gather
queries
as
a
primary
use
case
with
Sai
you're,
probably
going
to
want
to
use
size,
tier
compaction,
you're,
probably
going
to
use.
B
You
know
the
ccs
and,
and
the
reason
is
that
CTS
will
keep
the
overall
number
of
ss
tables
to
a
manageable
level
to
a
manageable.
You
know
number
so
when
you
actually
do
those
those
global
category
arrive
at
those
local
and
as
you
arrive
those
replicas,
you
won't
be
querying
3000,
s's
tables.
You
know
at
each
node,
so
I
to
me.
B
D
B
Francisco,
so
that's
I,
think
that
and
the
general
scatter
gather
conundrum
are
the
two
things
always
to
kind
of
keep
in
the
back
of
your
mind.
You
know
in
terms
of
how
this
this
rolls
out
into
a
real
real
use
case
and
production,
but
yeah
all
right.
So
that's,
that's
all
the
sort
of
the
material
that
I
have
the
discussion
that
I
have
and
what
I
wanted
to
get
out.
I'm
I'm
open
for
questions.
If,
if
we
want
to
hang
out.
D
B
Yeah
I
mean
I,
can't
I
can't
really
speak
too
much
to
what
data
data
sex's
plans
are
with
with
the
old
DSE
search
product
or
or
any
solar
integration,
I
I
think
I
think.
The
reason
why
the
reason
why
we
sort
of
had
at
least
as
part
of
the
of
the
cep
here
replacing
a
real
search
engine-
and
you
know
real
I
put
in
quotes
right,
replacing
real
search
engine
is
that
there
are
issues
when
you
get
into
things
like
relevance.
B
That's
a
whole
that
is
a
whole
problem
space
that
we
did
not
want
to
to
try
to
get
into
with.
With
this
first
cep
and
I
I
think
when
you're
in
relevant
space,
you
know
you
can
do
relevance
within
large
like
a
large
partition,
search
context.
I
guess
you
know
I
mean
that's,
that's
something
we
could
do,
but
all
of
the
things
that
you
know
solar
cloud
and
elasticsearch
have
worked
on
for
over
a
decade
to
perfect
relevant
search.
B
We
just
we
didn't
want
to
try
to
boil
the
ocean
with
cep7
now
I
know,
since
we've
done
this
there's.
Obviously
this
whole.
You
know,
there's
like
the
vector
the
vector
search
stuff
that
that
Jonathan
and
some
other
people
are
working
on
that
you
know,
has
its
own
cep
now
and
I've
followed
that
a
little
bit,
but
you
know
I
I,
think
that's
just
I,
don't
think
the
I.
Don't
think
that
having
relevance
capability
is
is
something
that
is
necessarily
wrong
for
Cassandra.
B
It's
just
that,
like
everything
else,
it's
going
to
have
the
same
basic
hurdles
to
overcome.
In
terms
of
like
the
query
patterns
and
and
the
scattered
gather
situation,
you
know
as
long
at
the
end
of
the
day
it
doesn't
matter
if
we're
doing
tokenization,
because
we,
you
know,
we
have
plans
to
do
tokenization
and
filtering
on
the
tech
side.
B
You
know
combined
with
light
queries
and
and
all
that
sort
of
stuff
you
know,
even
even
geolocation
search
at
some
point
is
something
we
could
do
once
we
once
we
have
this
out
of
one
once
we
have
the
framework
out,
and-
and
you
know
this
is
what
the
vector
search
stuff
is
based
on
in
once
we
have
the
framework
out.
We
can
do
a
lot
of
things.
It's
just
that
some
of
the
basic
architectural
constraints
don't
just
disappear.
B
B
B
D
B
Yeah,
the
big
thing
so
to
just
to
say
another
word
about
like
solar
right,
so
the
biggest
problem
at
the
end
of
the
day,
with
the
way
that
the
solar
integration
worked
at
like
in
in
DSC
and
if
you
try
to
integrate
something
like
elastic
or
solar
with
Cassandra
is
the
read
before
right
apparatus?
It's
it's
when
you
have
a
situation
where
solar
or
you
know,
if
leucine
underneath
both
of
them
wants
full
document
updates
and
you
are
constantly
having
to
build
full
document
updates
and
and
and
reading
on,
every
right.
B
B
B
B
C
A
A
A
The
sorry
come
along
to
that
same.
You
know
all
the
details,
Beyond
Confluence
as
normal
and
in
the
calendar
you
can
find
the
link
to
that
in
Confluence,
and
the
recording
of
This
call
will
be
up
in
Confluence
probably
later
today,
once
it's
once
it's
processed
and
published
So
yeah.
Thank
you
very
much.
Everyone,
and
especially
thanks
to
Caleb
and
yeah,
see
you
next
time
and
also
reminder
the
Cassandra
town
hall
is
coming
up
this
week.