►
Description
Speakers: Derek Bromenshenkel and Jeff Smoley, Infrastructure Architects at NativeX
Slides: http://www.slideshare.net/planetcassandra/native-x
NativeX (formerly W3i) recently transitioned a large portion of their backend infrastructure from Microsoft SQL Server to Apache Cassandra. Today, its Cassandra cluster backs its mobile advertising network supporting over 10 million daily active users that produce over 10,000 transactions per second with an average database request latency of under 2 milliseconds. Come hear our story about how we were successful at getting our .NET web apps to reliably connect to Cassandra. Come learn about FluentCassandra, Snowflake, Hector, and IKVM. It's a story of struggle and perseverance, where everyone lives happily ever after.
A
So
what
we
plan
to
go
over
today
is
a
little
bit
about
native
x
and
what
we
do
on
why
we
chose
cassandra.
Some
of
the
challenges
that
that
that
brought
up
things
like
auto
ID
generation,
a
little
bit
about
flu
and
Cassandra
some
stuff
about
Hector,
which
is
the
Java
client,
I,
kvm
net
Hector
net,
and
then
our
reporting
infrastructure,
how
we
sort
of
tied
that
into
Cassandra.
A
A
A
A
We
have
over
a
hundred
million
monthly
active
users
and
over
200
gigabytes
of
data
that
we
ingest
per
week,
just
a
little
bit
of
backstory,
of
sort
of
where
we
came
from
and
why
we
needed
to
have
a
scalable
solution.
So
we
went
from
doing
about
a
hundred
million
sessions
per
quarter
in
the
mobile
business
to
up
to
five
billion
a
quarter,
and
we
anticipate
by
the
end
of
quarter.
Two
will
have
over
seven
billion
sessions
that
we've
produced.
A
A
So
our
original
architecture
was
built
all
on
top
of
Microsoft
sequel
server.
You
know
again
we're
using
dot
net
as
the
web
application
code,
but
the
backend
really
uses
you
know
was
using
a
Microsoft
sequel
server,
which
is
just
a
two
node
cluster,
an
active/passive
setup.
So
it's
really
one
node
serving
all
of
the
the
requests
to
the
database
and
the
second
node.
A
But
again,
this
is
a
very
horizontal,
just
gonna
be
vertical
monolithic
approach,
the
only
way
to
really
scale.
This
was
by
adding
more
hardware
to
this
one
machine,
and
we
eventually
got
to
the
point
where
you
just
couldn't
add
any
more
to
it,
without
going
into
something
like
a
super
computer
or
whatever,
and
so
it
just
wasn't
really
scaling
with
the
growth
of
our
business.
A
So
we
set
out
to
achieve
a
couple
of
objectives.
We
need
to
do
it
to
have
that
horizontal
scale
where
we
add
more
of
the
same,
adding
additional
nodes
of
like
hardware
so
that
we
could
spread
out
that
load
and
that
also
would
give
us
an
incremental
cost
structure.
So
not
only
you
know,
can
we
add
more
machines,
but
we
know
exactly
how
much
that's
going
to
cost
with
a
vertical
scale.
It's
a
different
amount
of
money.
A
A
The
other
thing
that
we're
sort
of
after
as
a
side
benefit,
was
resiliency
so
that
we
had
a
no
single
point
of
failure
with
not
just
in
a
single
data
center
but
across
multiple
datacenters,
so
that
we
could
be
geographically
distributed
so
that
if
at
some
point
we
wanted
to
be
in
a
second
data
center
and
have
the
ability
for
one
of
those
data
centers
to
go
down
and
still
run
the
business
we
could
achieve
that.
So
we
were
looking
for
a
product
that
would
provide
that
flexibility.
A
So
that
really
led
us
into
looking
at
no
sequel
solutions
and
at
the
time
we
really
didn't
understand
what
that
meant.
So
we
did
some
research
and
found
out
that
you
know
it.
The
the
term
actually
stands
for
not
only
sequel,
so
SQL
being
a
declarative.
Language
is
really
agnostic
of
Technology.
It's
just
a
way
to
express
you
know
some
some
set
of
requirements
and
then
get
some
result
back
from
that,
and
so
the
SQL
language
itself
isn't
is
still
valid
in
the
no
sequel
world.
A
So
really
no
sequel
is
about
understanding
problems
and
and
focusing
on
solutions.
Each
product
really
solves
a
very
specific
problem,
so
you
know
it's
not
about
silver
bullets
and
black
boxes
and
what
I
mean
by
black
boxes?
Is
you
don't
just
stand
these
things
up
and
they
magically
work,
that's
sort
of
where
the
relational
mindset
came
from
was.
Is
you
just
stand
up
the
relational
database?
You
know,
maybe
some
DBA
does
a
few
things
here
and
there
and
it
just
works.
You
don't
care
about
the
underlying
architecture.
A
You
don't
care
how
it
reads
and
writes
from
the
disk.
You
don't
care
about
how
it
caches
memory
things
into
memory.
You
might
know
a
little
bit
about
those
things,
but
in
most
cases,
you're
not
really
worried
about
that
stuff.
No
sequel
is
really
about
understanding
those
things
and
really,
you
know,
learning
about
how
they
actually
achieve
those,
because
it
helps
you
design.
Your
systems
to
you
know,
exploit
those
those
features.
A
So
in
our
research
of
different
products,
so
we
decided
we
wanted
to
choose
an
existing
product.
We
didn't
really
want
to
build
out
a
system
by
hand,
and
so
we
did
a
bunch
of
research
and
the
things
we
were
looking
for
were
things
like
distributed
and
shared
nothing
again.
We
wanted
multi
cluster
support
for
things
we
may
do
in
the
future
to
be
in
multiple
data
centers.
We
wanted
something
that
was
mature
but
also
popular.
A
A
We
ran
across
some
products
that
there
just
wasn't
any
documentation
or
very
sparse
documentation
and
then
the
the
last
thing,
because
we're
built
had
all
of
our
code
built-in
dotnet
we
needed
something
that
actually
supported
net
from
a
driver
standpoint,
so
this
led
us
into
Cassandra.
Ultimately,
we
we
chose
Cassandra
and
the
reason
we
chose
cassandra
is
because
it
is
multi-node
again
each
one
of
these
little
blue
circles
on
the
graph
on
the
around
the
diagram
on
the
left
side,
where
it
says
DC
one.
Each
one
of
those
blue
circles
represents
an
independent
node.
A
It
has
all
of
its
own
Hardware,
its
own
memory,
CPU
and
disk,
none
of
its
shared
between
between
each
node.
We
also
wanted
multi
cluster,
which
is
provided
in
Cassandra.
So
you
see
here
you
have
two
data
centers
data
center,
one
and
two
in
the
blue
and
the
green,
and
so
it
allows
you
to
you
offload
work
across
multiple
data
centers,
it's
also
highly
available.
So
you
you
use
replica
sets
which
you
see
here
with
the
white
boxes
that
say
r1,
r2
and
r3.
A
You
can
replicate
data
around
the
ring
so
that
if
a
node
goes
down,
you
still
have
the
ability
to
get
data
off
that
and
put
data
on
to
to
those
other
nodes.
And
you
can
choose
your
replication
factor.
A
typical
standard
you
uses
is
3
and
up
I'll
explain
a
little
bit
why
you
would
want
to
use
3
in
a
minute
here.
A
It's
also
durable,
so
data
is
written
to
each
of
the
nodes
and
it's
actually
written
to
a
commit
log
so
that
if
one
of
the
nodes
goes
down,
you
still
have
that
data,
and
you
can
replay
that
those
transactions
there's
also
coordinator
nodes
that
you
actually
communicate
with,
which
can
be
any
note
in
the
ring.
That
will
also
do
some
things
like
hinted:
handoffs
and
whatnot,
so
that
one
nodes
go
down
and
come
back
up,
they
can
get
the
data
that
they
missed,
and
so
the
other
thing
like
I
mentioned
is
shared
nothing
again.
A
None
of
the
hardware
is
actually
shared
between
each
of
these
nodes.
You
know
if
you're
running
this
in
Amazon,
then
you
have
other
other
situations
that
where
there
might
be
some
shared
hardware,
but
you
know,
the
idea
here
is
to
minimize
sharing
that
hardware,
and
even
the
software
part
of
it
to
each
node
is
running
the
code
independently,
and
so
the
last
thing
that
really
struck
us
with
cassandra
is
that
it
has
tunable
consistency.
A
So,
like
Jonathan
Allison
Allison
mentioned
this
morning,
is
you
know
it's
eventually
consistent,
but
it
has
the
ability
to
sort
of
tune
that
based
off
of
your
your
needs,
and
so
the
idea
here
is
that
let's
say
I
have
something
I
want
to
write
to
the
node.
I
can
choose
a
consistency
level
of
one
and
that
data
will
come
from
the
client.
The
client
will
choose
one
of
the
nodes
as
a
coordinator
and
is
and
send
that
data
over
to
all
the
replicas.
A
A
A
If
you
do
need
a
little
bit
more
consistent
where
you
want
to
make
sure
what's
written,
when
it
comes
back
that
you
actually
get
the
right
answer,
you
can
do
what's
called
the
local
quorum
or
quorum
in
general,
and
so
what
you're
after
there
is
you're
trying
to
make
sure
that
the
majority
of
the
node
nodes
are
responding
so
again
in
a
replication
factor
of
three.
You
would
want
two
of
those
nodes
to
respond
with
the
answer.
A
Majority
of
the
nodes
have
this
data
move
on
and
let's
say
immediately
after
that,
or
you
have
another
competing
thread:
that's
coming
in
and
needs
to
read
that
data,
and
it
sends
that
over
which
is
going
to
again
ask
all
three
notes
for
the
data
as
soon
as
it
gets
two
of
the
nodes
to
respond.
It
will
then
compare
those
results
from
the
two
nodes
and
if
they
don't
match,
it'll
have
to
wait
for
the
third
node
and
then
from
there
it
can
decide
what
the
real
answer
is
so
using
quorum.
A
You
can
get
that
consistency.
You
want
it's
still
eventually
consistent.
You
could
still
have
situation
where
a
reed
is
coming
in
and
you
haven't
quite
even
written
to
the
data
to
any
of
the
nodes
yet,
but
you
can
have
that
sort
of
you
know
if
you
know
that
a
particular
record
has
been
written.
You
can
immediately
ask
for
the
data
back
and
know
that
you're
going
to
get
the
right
answer
back,
so
it
allows
you
to
choose
sort
of
your
workload.
A
A
So
again,
at
native
x,
what
are
we
using
Cassandra
for
it
wasn't
a
replacement
database
system.
We
didn't
get
rid
of
microsoft,
sequel
server.
It
actually
sits
alongside
of
cassandra.
What
we
use
the
microsoft
sequel
server
for
is
storing
our
configuration
data.
If
you
want
to
call
it
master
data
whatever
it.
Basically,
the
you
know
the
nouns
of
the
application
things
like
offers
and
applications-
and
you
know,
budget
rates
and
things
of
those
things
of
that
nature.
A
But
Cassandra
did
solve
a
very
specific
problem
for
us,
which
is
more
on
the
transactional
side.
So
we're
writing
large
volumes
of
data
quickly.
We
have
all
this
activity,
data
or
event
tracking
data
that
we
need
to
capture
so
that
we
can
report
off
of
it
later.
This
product
is
very
good
for
capturing
that
data
quickly,
but
also
we
have
very
specific
data
sets
that
we
very
specific
data
that
we
want
to
pull
out
of.
Large
data
sets.
A
So
we
talked
about
having
700
million
devices
before
and
we
need
to
be
able
to
pinpoint
a
very
specific
device
and
pull
up
its
history.
We
need
to
know
what
that
device
is
done
in
the
past
so
that
we
can
target
the
right
offers
to
that
device
and
Cassandra
allows
for
that
very
specific
targeting
of
data.
If
you
model
your
data
correctly,
so
Derek
will
now
go
over
some
of
the
challenges
that
we
had
and
how
we
overcame
some
of
those.
B
So
it's
just
mentioned,
you
know
this
is
just
not
a
drop
in
system
for
us,
and
you
can
imagine
this
all
kinds
of
things
we
had
to
overcome
so
hopefully
be
able
to
answer.
Probably
a
lot
of
the
questions
that
you
have
and
one
of
the
big
things
that
were
starting
off
with
is
you
know:
Cassandra
doesn't
have
an
auto
ID
generation
system,
nor
should
it-
and
so
you
really
might
be
asking-
why
are
we
even
talking
about
this
all
for
us?
It
was
a
pre-existing
requirement
of
our
external
web
api's.
B
So
we're
kind
of
locked
into
this
know
if
having
a
unique,
64-bit,
positive
integer
to
identify
devices
and
other
things
like
that,
and
you
know
having
something
an
identifier,
that's
increasing,
which
makes
it
sortable
was
a
plus
for
us
and
that's
really
around
in
our
data
warehouse
having
you
know,
clustered
index
is
based
on
these
IDs,
so
of
course,
in
the
old
way.
This
was
done
with
a
sequel,
server,
identity,
column,
and
that
worked
great.
But
in
this
new
approach
we
won't
be
using
that
anymore,
so
had
to
find
something
else.
B
So
cassandra
has
a
notion
or
just
general
notion
of
time-based
you
80s
that
are
sortable
and
unique
and
they're
really
great.
We
actually
changed
a
lot
of
what
we
were
using
to
support
time-based
you
you
at
ease,
because
they're
sortable
their
unique.
You
can
generate
them
from
any
any
client.
It's
not
a
single
point
of
failure,
and
so
it's
definitely
the
future
for
us.
You
know
we
change
our
API
to
be
backward
compatible.
So
then,
as
time
goes
by
we'll
be
able
to
get
away
from
having
to
generate
the
64-bit
integers.
B
So
what
are
the
options
that
we
have?
Well,
you
could
really
take.
The
notion
that
we
had
before,
which
is
just
a
dummy
table,
has
one
column
in
it:
it's
an
identity,
column
and
it
just
increment
that
every
time
you
need
a
new
ID
that'd
be
really
easy,
beery
familiar
for
us
familiar
for
anybody
that
uses
a
SQL
server
functionality.
B
But
of
course
it's
limited
just
got
done
talking
about
how
we
didn't
want
a
single
point
of
failure,
how
we
wanted
to
be
able
to
increase
load
over
time
so
decided
against
that
we
worked
with
datastax
a
lot
on
this
project
and
specifically
Matt
Dennis
proposed
the
solution
where
we
pre
generate
a
range
of
keys
and
assign
them
to
various
nodes
inside
the
cluster,
and
so
that
makes
it
distributed
right.
Cassandra
could
hold
those
those
keys
but
a
little
more
complicated
to
implement,
and
there
was
an
old
guaranteed
ordering
when
you
did
that.
B
Another
thing
we
found
while
doing
a
research
was
Instagram,
came
up
with
a
sharding
mechanism.
I
got
a
link
up
there.
You
can
visit
after
the
presentation
and
it's
actually
really
slick
I
wish.
We
could
have
used
it,
we
actually
end
up
discovering
it
too
late
and
in
reality
we
weren't
familiar
with
postgres
and
it's
built
on
that.
So
you
know
I,
don't
think
we'd
have
been
comfortable
doing
it
anyway,
but
I
just
thought
I'd
throw
it
out
there
so
that
you
guys
all
know
that
it.
It
is
something
that
you
know.
B
So
what
we
ultimately
do
is
chose
snowflake,
it's
a
service
built
by
Twitter.
It's
got
an
Apache
License.
They
got
it
out
on
github.
You
can
take
a
look
at
it.
They
define
it
as
a
network
service
for
generating
unique
ID
numbers
at
high
scale,
exactly
what
we're
looking
for
right,
the
distributed
nature
and
the
way
we
need
to
generate
a
lot
of
these
numbers
and
something
that
really
dived
with
us
is
they
had
the
same
motivation.
B
They
were
going
from
a
relational
system
to
Cassandra
and
they
needed
a
way
to
solve
the
same
problem
so
just
felt.
You
know
we
connected
with
that.
There's
a
few
tweaks
you
to
make
for
our
windows
environment,
namely
different
java
runtime.
We
had
to
figure
out
how
to
make
it
run
with
the
patchy
demon
and
we
removed
some
of
the
internal
scribe
logging,
but
in
general
I
mean
it's
like
out-of-the-box
solution.
B
So
few
more
of
the
technical
reasons
around
what
snowflake
does
for
us
so
met
all
the
requirements
that
I
mentioned
before,
with
being
unique:
positive,
64-bit
integers
that
are
roughly
time
sortable,
because
they're
generated
with
a
time
component
and
they're
fast
and
distributed,
and
so
those
are
all
the
requirements
that
we
needed
and
we
are
felt
really
comfortable
using
this
because,
of
course
Twitter.
You
already
use
it
in
their
high
transaction
system.
B
It
is
a
java
based
implementation,
so
you
might
be
thinking
okay,
your
Microsoft
shop.
Why
would
you
go
down
the
Java
road
and
the
truth
is
you
know,
while
we
do
use
a
lot
of
the
Microsoft
stack,
we're
not
really
scared
of
using
Java.
So
we
were
pretty
comfortable
in
that
using
that
technology
also
snowflake
uses
a
thrift
server
to
actually
do
the
communication,
and
while
it's
maybe
not
perfect,
it's
a
very
familiar
thing
with
the
way
Cassandra
does
its.
B
It
uses
a
thrift
protocol
also
and
so
yeah.
All
we
do
is
run
that
through
server
as
a
Windows
service
with
Apache
demon,
so
one
con
that
Instagram
also
mentioned
while
doing
their
research
for
single
flake
is
well.
It
requires
Apache
zookeeper.
So
it's
another
moving
piece
right
and
that
can
be
scary,
but
it
didn't
scare
us
and
only
reason
is-
is
because
it's
not
required
on
every
transaction.
B
It's
only
required
its
startup
and
it
basically
just
coordinates
when
each
snowflake
instance
starts
up,
it
coordinates
which
node
ID
that
is
assigned
to
each
individual
process,
and
then
it
stays
out
of
the
out
of
the
workflow
from
there.
So
it's
it's.
Yes,
it's
a
dependency,
but
it's
very
limited.
It's
it
doesn't
have
to
scale
and
all
those
things.
B
So
you
might
be
wondering:
okay,
now
you
have
snowflake.
How
are
you
going
to
connect
to
that
thing?
Well,
basically,
we
did.
Is
you
built
their
own
snowflake
line
and
to
eliminate
web
hops?
You
know
the
network
latency.
We
put
a
snowflake
server
on
each
node
of
our
web
servers
and
then
we
connect
to
that
locally
from
each
web
app
and
that's
the
primary
snowflake
instance
for
each
one
of
those
web
apps.
They
don't
connect
to
the
other
ones
unless
they
need
to
which
is
I'll.
Get
you
right
now.
B
So
what
happens,
if
say
snowflake
instance
on
server
3
fails
well.
What
we
did
was
implemented
around
Robin
fail
over
to
the
other
nodes,
so
it
temporarily
can
ask
another
node
for
an
ID
and
that
works
really
great,
but
the
key
to
it
really
is
the
last
point
there.
It
automatically
fails
over
like
this,
but
it
also
automatically
recovers.
So
if
that
snowflake
instance
on
server
3
comes
back
up,
the
app
knows
about
that
and
we'll
start
using
that
local
node
again
and
eliminate
that
Network
Lindsay,
and
we
did
that
using.
B
What's
called
the
circuit
breaker
pattern,
you
can
research
it,
but
it
basically
you
know
one
when
the
circuit
gets
hot,
so
having
a
lot
of
failures.
It
trips,
the
breaker,
starts
failing
over
to
the
other
nodes
and
it
periodically
can
go
in
like
a
test
mode
where
it
says:
okay
did
snowflake
instance.
3
come
back
up
and
if
it
says
yes,
it
trips,
the
breaker
back
on
and
you're
back
in
business.
B
B
As
you're
probably
aware
you
thrift
has,
you
know
some
AP
is
that
have
generated
c-sharp
code
and
you
could
just
use
that,
but
for
us
in
our
development
team
it
was
too
too
low
level.
We
needed
something
with
cql
support
and
we
wanted
something
that
had
that
a
do,
danette
or
link
feel
and
I
also
mentioned
in
need
is
hey.
B
We
need
something,
that's
actively
being
developed
to
support
the
up-and-coming
features,
as
you
notice
this
morning,
there's
just
a
lot
of
stuff
going
on
with
Cassandra,
and
we
want
to
be
able
to
keep
up
with
that
over
time
as
far
as
other
than
that,
we
didn't
really
know
what
we
needed
or
wanted.
Besides
that,
so
through
our
research,
we
basically
started
with
this
project
called
fluent
Cassandra.
B
And
so
we
started
the
process
of
vetting
this,
like
is
this
going
to
work
for
us
in
our
in
our
environment
and
there's
a
lot
of
great
things
about
it.
It's
open
source,
you
can
go,
take
a
look
at
any
time.
You
can
contribute.
You
can
see.
What's
going
on
in
the
guts,
if
you're
wondering
how
something
works
or
if
you're,
having
a
problem
Nick
the
project
owner
is
excellent.
We
I've
had
pretty
good
relationship
with
them.
He's
always
been
very
reliable
and
responsive
to
our
questions
and
because
of
his
intelligence.
B
B
Of
course,
once
we
started
using
it,
that's
you
know
when,
when
you
start
noticing
some
of
the
drawbacks
to
it,
so
really
what
we
found
out
is
it's
relatively
immature.
There
aren't
a
lot
of
users
with
our
use
case,
which
is
a
very
high
transaction
system
and
at
the
time
we
started
using
it
had
a
pretty
bad
problem,
which
was,
it
would
permanently
black,
will
blacklist
a
node
if
it
went
down-
and
you
know
we
couldn't
deal
with
that
it
over
time.
B
We
help
them
fix
that
and
others
have
contributed,
and
that's
no
longer
the
case,
but
that
was
a
pretty
big
black
eye
for
us.
Another
thing
is:
if
you
had
a
request
that
failed,
you
know
what
happened
to
that.
Well,
it
didn't
doesn't
have
a
retry
mechanism
thing
like
that.
So
basically,
what
would
happen
is
just
all
back
up
to
your
client
and
you
would
have
to
deal
with
it.
B
So
what
that
really
boils
down
to
is
we
didn't
want
to
live
at
those
limitations,
and
so
that
really
left
us
in
a
spot.
Where
way
to
do
something
about
that,
but
we're
still
committed
to
fluent,
because
it
like
I,
said
it.
We
had
a
great
experience
in
our
research
and
our
initial
use
of
it.
So
we
tried
doing
was
adding
resources
dedicated
to
maturing
in,
but
what
that
ultimately
didn't
work
out.
It
just
was
taking
too
long.
You
know,
especially
how
r
this
project
had
a
timeline
dedicated
to
it.
B
B
Hector,
that's
what
it
boiled
down
to
it's
very
popular
Cassandra
connector
in
the
java
community.
Tons
of
use
cases
matching
ours
with
high
transactions,
and
you
know
wanting
consistent
data
and
multi-node
many
node
clusters,
and
things
like
that,
and
you
know,
after
doing
a
lot
of
this
research,
we
just
realized.
B
It
had
really
good
mature
you
compared
to
some
of
the
other
stuff
we
were
looking
at,
so
it
can
autodiscover
nodes,
it
can
retry
failed
the
requests
and
it
can
recover
from
failure
similar
to
what
we
implemented
in
our
snowflake
net
client,
where
it
can
recognize
a
notice,
come
back
online
and
start
using
it
again.
You
don't
have
to
recycle
app
pools.
You
don't
have
to
tell
it
that
hey
this
server
is
okay
again,
but
of
course
you
know
it's
written
in
Java,
that's
a
major
roadblock
for
us.
B
B
A
So,
as
Derrick
said,
we
still
needed
some
help
with
this.
We
realized
that
you
know
based
off
our
timelines
and
stuff,
that
we
weren't
going
to
necessarily
have
the
time
to
focus
on
that.
You
know
wasn't
that
we
weren't
capable
of
figuring
this
problem
out
it
just
we
just
needed
somebody
else
to
sort
of
tackle
that,
while
we
were
still
moving
the
project
forward,
so
we
ended
up
running
into
a
company
named
Concord
they're
based
out
of
the
twin
cities,
and
they
specialize
in
system
process
and
data
integration.
A
So
we
went
to
them
basically
told
them
our
problem,
and
you
know
we
asked
them
if
they
could
help
us
mature
flu
and
Cassandra,
and
they
came
back
and
said.
Well,
we
have
a
different
approach.
We've
used
this
product
called
I
kvm
net
and
we'd
like
to
actually
take
the
hectare
assembly,
the
the
java
jar
and
actually
port,
that
over
to
a.net
assembly,
they
actually
had
previous
experience
using
I
kvm.
To
do
this
with
other
java
jar
files
and
libraries
and
port
them
over
to
net.
A
A
So
what
is
I
kvm
net
or
you
know
a
little
bit
about
the
project?
I
guess
so
it's
an
open
source
project.
It
has
a
main
contributor
who
actively
contributes
to
the
project.
There
were
even
contribute
seconds
to
the
project
in
the
last
couple
of
weeks,
and
so
it's
being
actively
worked
on,
and
it
also
has
a
license
that
allows
for
corporate
use
so
that
our
commercial
applications,
corporate
use,
that
kind
of
thing.
So
it
definitely
was
something
that
we
were
willing
to
adopt
or
try
out
at
least
so.
A
A
So
some
use
cases
for
this.
You
can
actually
take
any
old
jar
file
and
get
it
up
and
running
inside
of
net
using
the
Java
Virtual
Machine
that
was
implemented
in
net,
so
it
just
you
know,
out
of
the
box,
you
can
just
take
you
know
in
theory,
you
can
take
any
jar
file
and
run
that
inside
of
this
virtual
machine.
A
Again,
another
use
case
is
that
you
can
take
your
Java
libraries
and
actually
port
them
over
to
net,
which
is
the
route
that
we
ended
up
going
using
the
ik
vmc
tool.
You
you
actually
take
that
and
compile
your
java
bytecode
straight
to
annette
intermediate
language
as
an
assembly
file
and
then
sort
of
the
final
scenario,
which
is
a
I'm
not
exactly
sure.
A
If
anyone
would
want
to
do
this,
but
you
could
write
your
code
in
java,
compile
it
to
the
JVM
bytecode
and
then
using
the
ik
vmc
produce
a
dotnet
executable
out
of
that
or
in
a.net
assembly.
So
you
can
literally
write
your
application
in
Java.
If
you
didn't
want
to
write
it
in
net
and
then
run
it
on
top
of
the
dotnet
stack.
In
addition
to
that,
you
can
actually
take
dotnet
api's,
build
stubs
that
you
can
actually
access
through
your
Java
code
and
that
way
you
can
actually
use
the
dotnet
framework
from
Java.
A
A
In
addition
to
doing
this,
we
also
wanted
to
still
have
another
abstraction
layer
in
between
there,
so
we
wanted
to
be
able
to
use
Hector
in
a
more
dotnet
like
way
we
wanted
to
have
you
know,
dotnet
data
types
and
dotnet
collections
and
that
kind
of
stuff-
and
you
know
thing
and
connection
strings,
and
so
we
built
a
wrapper
with
working
with
Concord
to
basically
abstract
some
of
those
complexities
or
the
sum
of
those
details
away
so
that
we
didn't
have
to
deal
with.
You
know
java
stuff.
A
We
could
deal
with
what
felt
more
like
dotnet.
The
other
thing
that's
allowed
us
to
do.
Is
we
built
an
interface
that
that
took
the
fluent
cassandra
objects
and
it's
sort
of
exposed
those
through
an
interface
so
that
we
could
switch
between
hector
and
fluent
because
again,
we
weren't
really
sure
if
this
I
kvm
thing
was
going
to
work
out
and
we
weren't
willing
to
just
completely
switch
over
to
it
and
find
out
it
didn't
work
and
then
have
to
switch
back
to
fluent
or
do
something
completely
different.
A
So
we
we
built
that
interface,
so
we
could
toggle
between
the
two
and
that
actually
helped
us
out
quite
a
bit
because
we
could
run
it
on
fluent
and
then
switch
over
to
the
Hector
version
and
find
out
that
oh
there's,
some
things
that
we
still
need
to
weed
out.
There's
some
things
that
aren't
mapping
right
to
the
data
types
or
certain
behaviors
that
Hector
had
implemented.
That
fluent
didn't
have
that
we
needed
to
sort
of
abstract
in
this
Hector
net
layer
that
we'd
built.
A
So
it
allowed
us
to
switch
back
and
forth
and
it
also
allowed
us
to
compare
performance.
We
could
see
that
hey
when
we
switch
to
you
know
when
running
fluent,
we
had
a
certain
level
of
performance.
We
switch
to
Hector,
didn't
really
see
any
performance
changes,
so
that
was
really
comforting
to
know
that
you
know
this
Java
code,
that's
essentially
running
as
dotnet
didn't
perform
any
worse
than
the
fluent
stuff,
the
native
netcode.
A
A
That's
a
data
warehouse,
so
it's
a
star
schema
and
then
we
pump
that
into
a
cube
using
sequel,
server,
analysis
services
again,
another
Microsoft
product,
so
we
didn't
need
to
modify
between
OLAP
and
the
cube.
What
we
needed
to
be
able
to
do
is
get
the
data
out
of
Cassandra
into
our
data
warehouse,
and
so
the
point
where
we
needed
to
solve
the
problem
was
in
that
extract
process.
A
So
again
you
using
ssis,
which
is
stands
for
sequel
server
integration
services.
It's
just
a
way
to
move
data
from
one
location
to
another
and
in
the
process
of
doing
that,
you
can
manipulate
that
data
structures
and
what
not
to
conform
to
wherever
you're
trying
to
load.
The
data
to
you
know,
transform
that
data,
and
so
ssis
has
what
are
called
script
tasks
and
script.
Task
is
just
a
component
that
you
put
into
your
data
flow
and
it
allows
you
to
write
any
c-sharp
code.
A
We
could
plug
this
in
directly
into
our
ssis
package,
so
we
can
take
those
script
tasks
and
write
very
similar-looking
code
to
get
the
data
back
out
and
so
the
script
task
sash
I,
have
to
end
up
referencing
our
Hector
net
wrapper,
along
with
the
Hector
version
of
our
the.net
version
of
Hector,
that
we
poured
it
over
and
then
all
of
those
dependencies
that
those
projects
have
so
when
you're
working
with
ssis
and
script
tasks
they
have
to.
You
can't
directly
directly
reference
things
inside
the
script
task.
A
You
actually
have
to
use
that
through
the
GAC
and
when
you
put
stuff
into
the
GAC,
that
means
things
have
to
be
signed
well,
all
of
the
I
kvm
stuff
and
the
porting
over
of
the
Hector
jar
file.
All
that
we
could
easily
sign,
but
we
had
a
lot
of
our
own
code.
That
was
also
incorporated
into
this
other
libraries.
We
had
that
weren't
signed,
and
so
we
had
to
go
sign
those,
and
then
we
find
out
that
something
underneath
there
wasn't
signed
and
it
became
this
big
dependency
tree
of
all
sorts
of
DLLs.
A
We
had
to
go
sign
and
it
was
a
little
bit
of
a
challenge,
but
we
all
you
know
we
ultimately
figured
it
out.
It
was
just
a
lot
of
work
to
find
where
all
of
these
things
were
used
and
update
the
the
references
to
these
signed
versions,
and
so
there's
some
challenges
there,
just
something
to
be
aware
of.
If
you're
going
to
go
down
this
path.
A
So
one
of
the
questions
you
might
be
asking-
and
you
know-
Jonathan
talked
about
this
today-
is
well
there's
a
c-sharp
driver
being
released.
It's
in
beta,
you
know
soon
to
be
going
general
availability.
Why
didn't
we
adopt
that?
Well,
one
of
the
big
things
was
is
when
we
started
this,
it
wasn't
available.
We
actually
sort
of,
I
think,
help
them
move
that
along
and
said,
hey.
We
really
need
a
way
to
be
able
to
connect
to
cassandra
from
net.
A
You
know
what
can
you
guys
do
to
help
us
and
I
think
that
can
kicked
off
their
their
push
to
get
something
out
there?
The
other
thing,
though,
is,
is
that
we're
using
cql
2
point
0,
and
our
understanding
is
that
this
driver
requires
you
to
use
cql
3,
which
means
changing
a
bunch
of
code
and
potentially
even
changing
some
of
the
data
structures
underneath
remodel
some
of
our
data
to
support
some
of
those
things
and
then
finally,
they
just
wanted
to
give
a
shout
out
to
datastax.
We
actually
use
datastax
enterprise.
A
Specifically,
we
just
use
the
support
right
now.
We
don't
use
the
Hadoop
and
solar
integration
stuff,
but
this
has
helped
us
out
a
ton
being
a
Microsoft
shop.
We're
used
to
just
stuff
working,
not
to
say
that
you
know
that
Cassandra
is
a
poor
built
product,
but
it's
it's
in
development.
There's
things
that
come
up,
there's
use
cases
that
haven't
been
tested.
A
There's
also,
you
know
a
lot
of
moving
parts
when
you're
working
with
the
distributed
system,
so
there's
stuff
that's
going
to
come
up
and
things
that
are
going
to
fail
and
so
having
datastax
available
to
have
that
support.
It's
just
been
a
necessity
for
us
to
be
able
to
run
this
so
with
that
we'd
like
to
say
thanks
for
stopping
by
and
listen
to
what
we
have
to
say
we're
hiring.
So,
if
you're
interested
in
joining
our
team,
you
can
check
that
out.
We
do
have
a
cassandra
meetup
user
group
in
the
Minneapolis
area.
A
If
you
would
like,
if
you're
from
that
area
and
you'd
like
to
attend,
you
can
hit
up
hit
up
that
group
on
that
link
there.
If
you
have
any
questions
afterwards
of
Derek
or
myself,
you
can
hit
us
up
on
these
email
addresses
and
then
also,
if
you'd,
like
a
copy
the
slide
deck.
You
can
get
that
with
this
link
at
the
bottom
here
and
I
think
now
we
actually
have
it
will
open
it
up
to
just
any
sort
of
general
questions.
Anyone
has
at
this
point.
D
A
It's
sounds
like
the
fluent
project.
Nick
has
some
other
obligations
and
so
he's
sort
of
not
contributing
to
it
as
much
he's
still
the
main
contributor,
but
he's
actually
asked
us
if
we
would
help
contribute
to
that.
But
because
we've
been
using
the
Hector
net
port,
we
just
don't
feel
like.
We
need
to
go
back
and
make
that
work.
The
java
community
is
actively
working
on
Hector,
and
so
all
new
features
are
being
added
to
that.
A
It's
still
a
lot
of
work
to
keep
fluent
up-to-date,
and
so
we
personally
just
don't
feel
like
it's
a
benefit
for
us
to
go
back
to
that.
At
this
point,
and
ultimately,
we'd
like
to
move
to
the
C
sharp
driver
that
datastax
is
building
I
mean
that's
where
the
future
is
going
to
be.
That's
really
where
you
know,
that's
why
we
chose
to
use
the
c
ql
language
is
because
we
wanted
to
be
as
much
as
possible
bound
of
that,
even
though
it's
a
different
version
with
three
point.
A
B
C
B
Yeah,
so
we
don't
have
it
on
every
single
one
of
those
web
nodes,
but
we
don't
need
it
because
I
couldn't
mentioned
earlier
in
the
talk,
it's
not
for
every
single
transaction.
It's
only
for
one
snowflake
starts
up,
so
it
honestly
serves
10
requests
a
month.
You
know
or
something
like
that,
so
it's
just
on
you
know
say
four
or
five
web
nodes
and
yes,
it's
set
up
in
a
distributed
nature,
but
it's
not
serving
massive
amount
of
load.
Yeah.
A
A
E
A
We
started
research
last
January
2012.
We
probably
spend
four
to
six
months
doing
just
research.
Just
you,
though
you
know
just
looking
at
different
products
and
then
also
starting
our
data
modeling,
because
that's
really,
where
you
got
to
start
with
cassandra,
is
data
modeling.
It
I
mean
you
yeah.
You
need
to
know
how
to
set
this
stuff
up,
but
setting
this
up
is
really
not
that
difficult.
You
know
eventually
have
to
tweak
a
bunch
of
settings
and
whatnot,
but
it's
really
understanding
how
you're
going
to
Mario
Mario
model.
A
Your
data,
which
really
comes
back
to
you,
need
to
know
your
data
access
patterns.
You
need
to
know
how
your
application
is
consuming,
that
data
and
start
at
that
point.
So
you
know
probably
took
us
six
months
to
get
to
that
point,
and
then
we
started
implementation
which
took
another
six
to
seven
months
to
actually
do,
but
that's
because
we
stumbled
into
a
lot
of
these
problems
with
the.net
stack
where
we
didn't
have
all
of
the
things
we
needed.
A
B
To
add
to
that
I
mean
there's.
Other
challenge
is
not
listed
here
right
operationally,
as
you
mentioned,
data
modeling
training,
those
things,
but
we
intentionally
left
that
out
of
this
presentation,
because
those
are
things
that
apply
to
anybody.
That's
trying
to
use
Cassandra.
So
if
you
need
help
with
that
data,
saxes
actually
you
know,
has
a
lot
of
training
classes,
and
I
know
ben
is
in
the
audience
here
and
he's
the
one
that
actually
trained
Jeff
and
I
on.
B
E
What
are
your
reasons
to
keep
reporting
side
still
in
the
Microsoft
environment?
Because
that's
where
most
of
the
companies
struggle
while
processing
the
data
doing
some
analysis
running
some
analytic
functions
because
Microsoft
is
slow?
Definitely
in
running
some
analytic
functions
and
specially
processing,
the
SSC
is
yeah.
A
We're
actually
starting
on
that
project,
as
we
speak
just
last
week,
we
sort
of
kicked
that
project
off
to
start
doing
research
on
what
are
we
going
to
do?
It
is
sort
of
make
a
distributed
reporting
system
and
scale
that
out
so
I
mean
if
anyone
has
ideas
that
they'd
like
to
share
with
us
afterwards.
Please
come
see
us
to.