►
Description
Speaker | Billy Bosworth (CEO, DataStax)
Date | Wednesday, September 26 @ 11AM PST
Why are customers choosing to replace or augment their tired, legacy RDBMS' with NoSQL big data platforms at record speed? This 101 level webinar will provide the answer. Join Billy Bosworth, CEO of DataStax, as he examines h ow to assess where NoSQL is right for your business, what factors to consider when selecting a big data platform, how to start planning which business priorities to address first, where you can find more information and why DataStax may be your best new partner to power the app that powers your business.
A
Good
morning,
good
afternoon
or
good
evening,
depending
upon
where
you
are
in
the
world
and
welcome
to
today's
webcast,
bridging
the
great
divide,
the
relationship
of
our
DBMS
and
no
sequel
brought
to
you
by
information
week,
datastax
and
broadcast
by
in
the
united
business
media,
limited
I'm
ever
Ferno
and
I'll
be
your
moderator.
Today
we
have
just
a
few
announcements.
A
Before
we
begin,
you
can
participate
in
a
Q&A
session
by
asking
questions
at
any
time
during
this
webcast
just
type
your
question
into
the
ask
a
question
text
area
below
the
video
window
and
then
click
the
submit
button.
At
this
time
we
recommend
you
disable
your
pop-up
blockers.
The
slides
will
advance
automatically
throughout
the
event,
you
may
also
download
a
copy
of
the
slides
by
clicking
on
the
download
slide
button
located
below
the
presentation
window.
A
If
you
are
experiencing
any
technical
problems,
please
visit
our
tech
webcast
help
guide
by
clicking
on
the
help
link
below
the
media
player.
In
addition,
you
can
contact
our
technical
support
helpline,
which
is
what
also
located
in
the
webcast
help
guide
now
on
to
the
presentation,
bridging
the
great
divide,
the
relationship
of
our
DBMS
and
no
sequel
discussing
today's
topic
is
Billy
Bosworth
CEO,
datastax
Billy
is
responsible
for
the
day-to-day
operations
of
datastax.
A
Under
his
leadership,
the
industry-leading
quest
database
business
grew
from
supporting
traditional
relational
databases
to
a
portfolio
that
now
includes
tools
for
cloud,
no
sequel,
collamer
and
Hadoop
databases,
as
well
as
business
intelligence
offerings
prior
to
quest
Billy,
led
product
teams
for
embarcadero
technologies,
database
productivity
solutions,
Billy
holds
a
bachelor
of
science
and
computer
science
from
the
University
of
Louisville
and
now
on
to
the
presentation.
We
thank.
B
You
Eric
and
that
intro
makes
me
sound
a
little
old,
but
the
truth
of
matter
is
I
have
been
around
databases
for
a
very
long
time,
whether
I've
been
developing
against
them
or
administering
them
or
writing
tools
for
them.
It's
been
in
my
blood
for
the
last
20
years,
so
I'm
very
excited
this
morning,
too,
get
the
chance
to
talk
to
you,
I'm,
calling
you
from
downtown
San
Francisco,
and
it's
my
pleasure
to
spend
a
little
bit
of
time
with
you
today
and
see
if
we
can
bring
some
clarity
to
the
challenges
of
understanding.
B
What
is
the
relationship
is
the
relationship
between
the
two
of
relational
and
no
sequel
technologies?
How
I
want
to
break
this
down
is
to
walk
you
through
a
little
bit
of
a
timeline,
because
it
gets
very
difficult
to
understand.
Some
of
the
things
are
happening
today
and
some
of
the
things
that
might
happen
tomorrow,
unless
you
do
have
a
bit
of
a
foundation
on
how
we
got
here
in
the
first
place.
So
we'll
look
at
this
in
time.
B
B
20-25
years
ago
we
ran
into
this
problem
where
we
had
certain
systems
designed
for
oltp.
We'll
talk
a
little
bit
about
what
that
means
and
what
that
looks
like,
but
it
was
transactional
systems.
It
was
real
time
systems
and
then
we
wanted
to
do
deep
analysis
of
that
data
and
to
do
that
in
the
same
database
didn't
make
sense.
B
That's
where
we
would
do
our
deep
analysis,
but
the
challenge
of
the
different
counties
of
data
and
the
different
demands
upon
the
data
has
been
with
us
for
for
quite
some
time.
So
in
a
sense,
big
data
isn't
necessarily
a
new
challenge.
That
said,
there
are
definitely
some
things
that
have
occurred
that
makes
a
modern
big
day
problem
quite
different
from
the
big
data
problems
of
the
past.
B
Characteristically,
the
big
names
that
you
would
see
in
this
space
were
the
names
like
teradata
and
it
he's
a
some
of
the
stuff
that
Tivoli
was
doing
and
we
used
to
call
this
DSS
and
it
stood
for
decision
support
system,
and
anybody
in
the
relational
world
15-20
years
ago
would
absolutely
know
what
you
were
talking
about.
If
you
said
put
this
over
in
my
DSS
system
or
my
data
warehouse,
it
was
optimized
for
a
lot
of
batch
reads
and
bulk
rights
and
what
that
means
is.
B
When
you
would
ask
a
question
of
the
data
in
a
data
warehouse,
you
could
do
it
in
kind
of
a
batch
mode
where
you
weren't
as
concerned
about
how
fast
that
query
was
going
to
come
back
because
the
questions
you
were
asking
were
very
deep
and
very
complicated.
So
what
you
would
do
is
you
would
go
ahead
and
submit
the
query
and
probably
not
expect
things
like
a
sub
second
response
time.
It
might
actually
take
hours
in
some
cases.
B
I
was
part
of
systems
that
took
over
night
before
you
would
get
your
answer
back
and
the
data
would
be
pushed
into
these
systems
kind
of
all
at
once
with
bulk
right
activity.
So
you
would
do
a
transformation
or
a
load
of
the
data
from
a
relational
system
or
a
flat
file
or
the
mainframe
even
into
one
of
these
data
warehouse
systems.
B
Everything
about
it
was
designed
for
these
complicated
queries.
So
I
wasn't
asking
a
simple
question:
I
was
asking
a
question
that
would
relate
to
a
very
complex
relationship
or
an
analysis
over
time
or
an
aggregation
of
data
rolled
up
into
summary
tables.
That
would
then
help
me
answer
or
ask
another
question.
So
everything
about
the
systems
were
optimized
for
that
type
of
analysis.
That's
just
the
nature
of
how
these
systems
work
and
that's
relevant,
it's
very
relevant
to
the
bridge
and
what
happened
today
with
the
first
movement
in
the
Big
Data
world.
B
B
What's
just
meant
you
bought
a
bigger
machine,
you
bought
a
machine
with
more
processors,
more
memory,
and
you
would
continue
to
push
more
and
more
and
more
on
to
a
bigger
and
more
powerful
box,
which
was
fine
for
quite
some
time
actually,
because
the
way
that
the
hardware
would
advance
so
quickly,
it
allowed
you
to
keep
up
with
a
lot
of
data
growth.
However,
it
was
never
accused
of
being
inexpensive.
B
This
always
was
a
process
where
you
start
to
realize
you're,
going
to
shell
out
some
significant
dollars
to
scale
these
solutions
into
a
very
big
answer
in
the
data
warehouse
side
of
the
world,
for
your
old
lab
systems,
and
that
was
the
prevailing
technology
for
a
long
time
a
couple
of
decades.
This
is
how
we
handled
the
big
data
problem
in
the
past,
but
then
a
new
kind
of
OLAP
problem
emerged.
There
was
this
little
company
out
there
called
Google
who
had
a
very
big
problem.
B
Even
data
warehouse
when
you
thought
about
something
like
a
log
or
even
now,
a
blog
as
time
went
by
and
the
emails
or
the
comments
that
would
happen
on
social
sites.
That
type
of
data
is
different
than
the
simple
row
column
data
that
you
would
put
into
a
relational
database,
and
this
caused
some
very
real
challenges.
It
cost
challenges
on
how
you
design
the
system
it
caused
challenges
on
how
the
system
performed.
B
We
would
try
and
force
fit
it
and
I
did
this,
for
a
big
part
of
my
career
was
trying
to
fit
data
types
that
were
not
really
around
or
designed
for
a
relational
model,
and
it
cost
a
lot
of
performance
challenges
and
a
lot
of
ongoing
maintenance
challenges
in
the
system
when
it
came
time
to
make
changes,
so
Google
had
a
real
problem.
What
do
we
do
about
this?
We
have
a
new
type
of
data.
We've
got
a
volume
that
really
is
kind
of
unmatched
in
in
the
world.
What
do
we
do
about?
B
B
This
isn't
really
a
foreign
concept
to
any
of
us,
although
we
may
not
understand
it,
but
when
you
turn
on
your
life
switches
in
your
homes,
that's
coming
from
a
utility
grid,
so
the
concept
of
grid
I
know
that
NASA
years
ago
did
a
lot
with
grid
computing
and
the
concept
of
it
wasn't
really
new.
But
the
challenge
of
how
do
we
bring
it
in
a
way
that
can
handle
all
this
new
type
of
data
as
well
and
also
give
us
the
ability
to
go
and
analyze
that
data?
B
That's
what
Google
solved
and
they
did
that
with
two
seminal
papers
that
they
published
and
gave
back
to
the
world
and
made
it
known
to
everybody
exactly
what
they
were
doing
and
it
was
called
Google,
Map,
Reduce
and
the
Google
file
system.
These
were
two
separate
papers
that
they
turned
over
to
everybody
else
in
the
world.
Those
google
papers
led
us
to
this
craze
today
that
we
call
Hadoop.
The
timeline
for
Hadoop
goes
back
quite
a
bit
further
than
most
people
realize
it
was
in
2003
when
Google
published
those
papers.
B
For
the
first
time,
then
in
2004
you
saw
the
manifestation
of
those
papers
in
something
called
HDFS
or
the
Hadoop
file
system,
the
Hadoop
distributed
file
system,
and
then
this
MapReduce
technology,
which
basically
said
how
do
I
now
go
and
ask
questions
of
my
data
that
is
distributed
all
over
these
commodity
servers.
How
do
I
do
that?
What
technology
do
I
use?
B
It's
what
map
produced
us
and
the
first
project
that
was
lunch
was
called
notch
and
that
started
in
2004,
but
then
in
2006
they
pulled
Hadoop
out
of
that
to
be
its
own
thing
and
then
by
2008
it
became
a
top-level
Apache
project
and
when
you
become
a
top-level
Apache
project,
that's
a
pretty
good
thing,
because
Apache
is
the
open
source
foundation
that
is
probably
the
most
widely
known
and
most
credible.
And
when
you
become
a
top-level
project
it
says
that
you've
got
clouds.
B
You
really
are
here
to
stay
and
it's
a
very
valuable
project
and
you
have
a
lot
of
activity
and
people
work
on
it.
So
Hadoop
came
from
that
from
that
evolution
from
google,
which
came
from
the
need
to
handle
a
different
kind
of
data
and
a
whole
lot
of
it,
but
in
a
much
more
cost-effective
way,
while
that
Hadoop
story
was
happening
in
evolving.
In
the
meantime,
a
few
years
later
after
the
Hadoop
wave
started
to
kick
off
another
challenge
to
merge
around
big
data,
but
now
we're
on
the
other
side
of
the
equation.
B
Now
we're
looking
at
those
OLTP
systems,
those
real-time
systems
and
it
turns
out
they
were
having
some
challenges
too.
Although
those
challenges
ended
up
being
a
little
bit
different,
so
let's
go
back
and
see
why
were
these
guys
created
in
the
first
place?
What
were
they
trying
to
solve
and
when
we
look
at
oltp
characteristics,
the
common
names
that
spring
to
almost
everybody's
mind,
are
the
Oracles
and
the
Microsoft
sequel
servers.
Mysql
S&D
be
tues
of
the
world.
B
We
called
these
systems
transactional
systems,
which
has
actually
led
to
some
confusion
today,
because
you'll
often
hear
real-time
systems
today
call
transactional
systems
which
is
actually
proper.
That's
the
exact
way
it
should
be
called,
but
sometimes
we
confuse
transactions
with
complicated
transactions
like
a
banking
transaction,
where
you
either
have
to
commit
everything
or
you
can
roll
back
all
those
characteristics.
B
Whether
it
was
me
writing
information
to
the
database
or
me
reading
information
from
the
database-
and
you
sometimes
hear
this
also
talked
about
as
random,
wheeze
and
rights,
which
just
means
that
there
was
an
unpaired
ability
of
which
type
of
data
was
going
to
be
accessed
at
any
given
time.
You
just
really
didn't
know
so
it
had
to
be
designed
and
optimized
around
those
kinds
of
things.
B
They
also
had
to
be
designed
around
something
called
durability,
and
what
durability
meant
was
that
if
something
were
to
go
wrong
in
the
middle
of
a
transaction
I
as
a
developer,
I
need
to
understand
whether
my
transaction
made
it
safely
to
the
database
or
it
did
not.
Let's
say
a
power
outage,
or
a
network
failure
if
I'm
handling
something
like
a
financial
transaction.
B
I
better
know
the
state
of
that
transaction
when
that
system
went
down-
and
this
was
a
lot
of
effort
and
time
and
energy
went
into
solving
this
problem
for
relational
technologies
to
make
it
safe
so
that
you
are
never
in
an
unknown
state
with
your
data
and
then
guys
like
me,
and
many
many
others
spent
lots
of
time.
Optimizing.
These
things
to
perform
well
entire
jobs
and
industries
and
even
ecosystems
of
tools
were
built
to
make
these
things
run
faster.
That's
what
we
were
after
great
that
they
were
durable
great.
B
They
handle
these
transactions,
but
now
we
have
to
get
faster
and
faster
and
faster
all
the
time.
Then
we
hit
another
challenge
with
these
systems.
If
you
think
back
to
how
an
application
used
to
look,
it
was
such
a
nice
simple
world.
Let's
say
we
were
building
a
web
app,
we
would
have
a
web
server
and
then
we
would
pick
a
database
on
the
back
end
and
it
was
great
life
was
easy.
Then
the
application
got
successful.
More
users
started
to
come.
B
B
B
Mysql
was
a
popular
choice,
a
very
popular
choice
for
this
type
of
architecture,
because
mysql
grew
up
and
became
popular
along
with
the
web
20
movement.
In
fact
many
would
say
it
was
absolutely
synonymous
with
the
web
to
da
movement.
The
problem
with
this
solution
was,
when
you
look
at
this,
that
this
sort
of
looks
like
a
database
on
a
bad
drug.
It
no
longer
can
function
and
have
all
those
characteristics
and
properties
that
make
a
relational
database
a
relational
database.
B
And
so
you
start
looking
and
fighting
the
complex
city
of
this
type
of
system
which
ultimately
can
lead
to
performance
problems.
And
what
you
started
to
see
was
only
the
most
elite
in
the
world
who
had
armies
of
the
highest
level
development.
Mind
could
make
this
stuff
work
in
scale
and
perform
all.
At
the
same
time,
so
you
saw
this
happening
in
kind
of
those
edge
case
companies,
but
it
became
very
complicated
and
very
hard
to
understand
for
a
traditional
relational
person,
and
so
what
we
said
was
well
hey.
B
We
want
to
get
some
of
that.
We
want
to
do
what
kind
of
Google
did
was
that
Hadoop
stuff?
We
would
love
to
do
that
with
the
relational
technology.
Why
can't
we
do
that?
Why
can't
we
scale
out
easily
and
make
this
thing
something?
That's
consumable
across
a
bunch
of
commodity
servers,
all
acting
together,
great
idea,
and
it
was
something
that
we
all
desperately
wanted,
but
turns
out.
You
don't
always
get
what
you
want.
B
Sometimes
you
get
smacked
in
the
face
by
reality
and
that's
what
happened
here
and
I'm
going
to
take
you
through
something
that
gets
thrown
around
a
lot,
but
unfortunately,
I
still
think
a
lot
of
people
don't
have
a
good
enough
understanding
of
this
mystical
thing
called
the
cap.
Theorem
I
want
to
try
and
demystify
that
a
little
bit
and
just
explain
about
what
it
is
and
why
it's
a
problem.
The
cap
theorem
was
created
by
some.
Some
very
smart
guys
came
out
of
a
project
at
MIT
where
they
tried
to
look
at.
B
What
does
everybody
want
out
of
this
relational
technology?
And
how
can
we
deliver
that?
How
can
we
make
it
work
together
and
the
first
thing
that
they
decided
was?
We
want
consistency
and
consistency
is
a
pretty
simple
concept.
It
can
be
misunderstood
greatly
because
of
some
of
the
other
ways
that
it's
described
in
relational
technology,
but
we're
not
going
to
get
into
the
that
level
of
nuance
at
the
moment.
B
We're
just
going
to
talk
about
consistency
as
the
view
into
the
data
and
the
ability
to
ensure
that
the
type
of
data
you
think
is
in
a
field
is
really
in
a
field.
That's
consistency.
So
let
me
give
you
a
couple
examples.
If
I
am
running
a
10,
ATM
transaction
and
I'm
here
in
San
Francisco
and
let's
say
my
wife
is
on
vacation
and
she's
in
dallas
texas
and
we're
both
trying
to
pull
money
out
of
our
account
at
the
same
time
and
we're
both
trying
to
take
eighty
dollars
out
of
our
account.
B
But
our
count
only
has
a
hundred
dollars.
Well,
we
better
be
sure
that
that
data
is
going
to
be
consistently
viewed
by
both
of
us
at
the
right
time,
so
that
we
don't
end
up
overdrafting
our
account.
That's
responsibility,
the
bank,
to
make
that
happen,
or
if
I
say
that
I'm
going
to
have
inside
of
a
field,
this
is
going
to
be
a
numeric
field
and
it's
always
going
to
be
a
numeric
field.
B
Well,
then,
that's
going
to
be
guaranteed
that
that's
going
to
consistently
be
a
numeric
field,
that's
part
of
what
consistency
means
and
we
all
love
this
and
needed
this
in
the
relational
world.
The
second
thing
we
all
wanted
was
availability.
When
I
put
my
ATM
card
in
I,
want
it
to
be
online
when
I
fire
up
my
web
app
I
want
it
to
be
online.
I
want
to
make
sure
that
the
system
is
always
there
and
ready
whenever
I
want
to
use
it.
So
availability
is
actually
a
very
simple
concept
to
understand.
B
It
means
just
what
it
says:
is
the
system
available
so
far
so
good?
We
understand
these
things,
but
now
this
is
where
the
new
demand
started
to
come
into
play
and
partition.
Tolerance
means,
if
you
remember
back
to
that
diagram
and
I
showed
you.
We
partitioned
our
data.
That's
what
partitioned
tolerance
means.
I
want
to
be
able
to
scale
horizontally
and
across
many
many
different
machines.
B
You
don't
get
all
three
based
on
the
technology
based
on
the
math,
based
on
the
physics
of
how
our
systems
work,
you
really
cannot
have
all
three
of
those
things
at
the
same
time,
in
the
same
way,
at
the
same
capacity,
it's
not
going
to
work
so
you're
going
to
have
to
give
up
some
constraints
to
solve
certain
problems
and,
as
I
said
earlier,
where
the
relational
technology
played
really
well
was
between
the
consistency
world
in
the
availability
world.
I
could
give
you
a
solid
view
of
your
data.
B
It
was
going
to
be
the
kind
of
data
you
expected
and
I
could
pretty
much
guarantee,
at
least
in
reasonable
terms,
that
it
was
going
to
be
available
for
you
with
clustering
or
fast
fail,
overs
or
those
kinds
of
things,
but
to
solve
the
problem
of
that
scale
and
making
sure
the
system
was
available
at
the
same
time.
This
is
where
the
no
sequel
movement
was
kind
of
born
and,
unlike
Hadoop,
that
really
didn't
have
the
concern
over
the
availability,
to
the
degree
that
a
real-time
system
has
availability
was
paramount.
B
It
was
even
pushed
beyond
the
limits
of
what
we
used
to
expect.
We
used
to
talk
about
the
five
nines
of
availability
you're
up
for
99.999%
of
the
time.
That's
not
good
enough
in
today's
world,
when
you
multiply
that
math
out
on
how
much
downtime
that
is
in
a
year,
it
starts
to
be
a
problem,
because
we
have
now
an
incredible
demand
from
our
users
on
our
systems
that
it
simply
always
be
available.
B
Think
about
how
frustrated
you
get
when
you
try
to
go
to
one
of
your
favorite
websites
or
when
you
need
to
access
something
on
the
web.
Forget
about
it
even
being
down,
even
if
it's
slow
you
go
out
of
your
mind,
everybody
gets
mad
and
starts
slamming
their
mouths.
So
why
isn't
this
thing
up
and
running-
and
we
are-
we
are
now
conditioned
to
have
things
available
all
the
time,
but
to
make
that
work
on
the
back
end
at
massive
scale
requires
the
ability
to
distribute
that
data.
B
Now
what
these
systems
don't
do
well
is
handle
that
consistency.
The
way
that
a
relational
mind
would
think
about
consistency,
and
so
you
have
to
handle
those
things
in
different
ways,
and
some
people
are
working
to
make
that
better
and
better
inside
their
systems,
but
for
the
most
part,
is
handled
at
the
application
layer.
The
developers
are
now
the
ones
who
take
the
responsibility
to
make
sure
that
those
transactions
aren't
going
to
step
on
each
other,
and
they
do
that
in
very
clever
ways.
So
when
this
no
sequel
was
born,
what
did
it
look
like?
B
Because
the
challenge
today
is
everybody
wants
to
throw
all
these
technologies
into
a
bucket
with
a
very
large
brush
and
just
say:
well,
it's
all
big
data.
It's
actually
quite
nuanced,
and
if
you
think
about
how
some
of
this
stuff
started,
the
basic
concept
was
this
thing
called
key-value
store
that
led
to
an
architecture
by
amazon
called
dynamo.
B
That
was
a
fully
distributed
architecture,
but
then
you
had
google
come
out
with
with
yet
another
paper
on
BigTable,
which
was
another
way
to
store
the
data
as
a
data
model
inside
the
database,
and
in
parallel
of
that
you
had
these
things
called
document
databases
which
are
not
documents
like
Word
documents,
common
misconception.
A
document
database
is
really
for
for
those
of
us
that
have
been
around
a
while.
You
may
remember
back
in
the
90s.
These
things
called
object.
B
Databases,
that's
probably
the
closest
analogy
that
you
would
have
to
a
document
database,
so
very
easy
to
access
model
through
scripting
languages
and
things
like
that.
And
then
you
had
these
things
called
graph
databases
which
helped
you
understand,
complex
relationships,
network
relationships,
connections
on
on
very
complicated
path
was
connected
to
what
and
how
often,
then,
these
things
emerged,
and
then
there
was
this
sort
of
Cambrian
explosion
of
all
these
technologies
that
started
to
emerge
and
evolved
off
of
this
stuff,
and
it
happened
very,
very
fast
in
my
last
job
at
qwest.
B
We
subtract
this
stuff
and
a
matter
of
fact
a
guy
on
the
bottom
of
the
screen
there.
If
you
want
to
follow
a
great
resource,
if
you're
a
relational
person
and
you're
trying
to
understand
kind
of
a
bit
about
this
new
world,
I
highly
recommend
you
follow
guy
Harrison,
good,
good
friend
of
mine,
former
coworker,
and
he
would
bring
these
lists
to
me
every
week
and
say
we
got
five
new
ones.
We
got
five
new
ones
and
what
I've
showed
you
here
is
not
exhaustive.
B
There
truly
was
an
explosion
of
this
technology
around
the
no
sequel
world
and
for
me
in
my
world
and
my
company,
the
the
one
that
I've
chosen
after
a
lot
of
time,
being
able
to
look
at
all
these
different
technologies,
I'm
here
at
datastax,
where
we
do
a
lot
with
this.
One
here
called
cassandra
which
is
off
to
the
far
right
about
halfway
down
the
page,
which
was
a
blending
of
really
two
technologies
that
the
distributed
architecture
of
dynamo
and
the
data
model
of
google
big
table.
B
B
It
becomes
difficult
to
talk
about
well,
I
still
really
appreciate
the
way
that
gartner
defined
it
and
they
really
defined
it
through
attributes,
and
they
said
that
if
you
have
one
or
more
of
these
challenges,
velocity,
which
is
high
throughput
in
your
system,
variety
logs,
blogs
social
site
comments,
in
addition
to
regular
data.
If
you
have
a
volume,
a
lot
of
it,
that's
not
really
hard
to
understand.
We
all
get
that
one
or
if
you
have
a
complexity
in
the
way
that
your
data
has
to
be
handled
or
captured
or
analyzed.
B
If
you
have
any
or
all
or
some
of
these
four
problems,
and
it's
not
handled
well
with
the
relational
technology,
then
you
do
have
a
big
data
problem
of
some
sort
and
by
way
of
recap,
remember
Hadoop
was
it
was
initially
built
to
solve
that
variety
problem,
the
logs
and
the
blog's
becometh,
and
then
there
was
a
lot
of
it
and
they
wanted
to
do
that.
Analysis
of
that
data,
but
the
real
key
here
was
beyond
the
technology
low
cost,
because
I
could
now
use
commodity
servers
to
do
this
stuff.
B
It
started
to
greatly
impact
my
ability
to
now
keep
all
of
my
data
as
opposed
to
putting
it
in
that
very,
very
expensive,
tier
1
or
tier
two
storage,
and
then
on
the
flip
side
of
that
coin,
you
had
the
emergence
of
different
technologies
like
Cassandra.
Around
use
cases
involving
velocity
I've
got
a
lot
of
throughput
coming
through
my
system.
Very
very
fast
I
have
to
keep
up
with
it.
I
want
to
distribute
that
load
across
many
many
servers.
B
B
I
get
very
frustrated
when
this
happens
and
living
at
it
from
the
inside
I
can
only
imagine
how
complicated
and
hard
it
is
to
grass
from
the
outside,
so
I'm
going
to
continue
to
try
and
give
you
some
stuff
that
helps
you
cut
through
this
and
helps.
You
understand
the
reality
of
the
world
today.
One
of
the
first
questions
is
who
is
really
using.
This
is
this,
for
me:
should
I
care
I
mean
I'm,
not
Google.
Do
I
really
have
that
problem
or
can
I
handle
this
easily
with
my
relational
systems?
B
That's
a
whole
webinar
all
by
itself,
but
I'm
going
to
try
and
walk
you
through
kind
of
the
evolution
as
I
see
it
of
what's
happened
in
the
space
and
by
the
way
these
are
not
datastax
customers
in
any
way.
This
is
publicly
available
information.
A
lot
of
it
from
the
analysis
actually
did
when
I
was
still
a
quest
a
little
over
a
year
ago,
but
as
I
said,
it
started
with
Google
and
then
the
next
stage
was
still
these.
B
The
next
stage
down
was,
we
saw
a
whole
new
set
of
companies
emerged
that
were
a
blend
of
kind
of
newer
startup,
be
kind
of
companies
who
are
looking
at
the
new
technology
because
sometimes
frankly,
it
was
cool
and
we
shouldn't
eliminate
that
as
one
of
the
factors
of
adoption
of
big
data.
Some
of
it
is
definitely
psychological.
B
I
can
tell
you
when
I
came
out
of
school
at
a
college
back
in
92
I
had
every
piece
of
skill
set,
I
needed
to
write,
COBOL
programs
and
right
JCL
and
write
all
the
four
train
of
stuff
I
could
have
done.
All
of
that,
it
was
very
well
prepared
to
do
that.
I
was
not
going
to
do
any
of
that
ever
I
was
going
to
say.
That
is
not
my
future.
B
My
future
I
want
to
be
in
client-server,
I
want
to
be
in
the
new
cool
stuff,
and
some
of
that
absolutely
is
going
on
today.
But
even
though
it's
a
psychological
reason,
you
really
shouldn't
dismiss
it
because
a
lot
of
times
markets
get
changed
by
exactly
that
kind
of
mentality.
Now
that
said,
they
were
also
still
struggling
with
this
scale
problem,
because
these
all
core
companies
who
said
we
can
be
big.
We
can
see
this
thing
exploding.
We
don't
want
to
get
caught
off
guard
later
and
not
future-proof
our
system.
B
B
You
would
think
really
they're
big
data
company,
but
they
are
because
people
are
now
seeing
the
advantages
of
how
they
can
use
big
data
in
new
and
different
ways,
even
in
very
traditional
companies,
so
the
use
cases
start
to
emerge
once
you
start
to
realize
the
power
of
the
technology
and
what
the
technology
can
do
for
you.
So
if
you're
wondering
really
how
widespread
this
is,
I
can
tell
you
from
observation
and
a
lot
of
customer
names
that
unfortunately
I'm
not
at
liberty
to
share
with
you.
B
It
is
absolutely
moving
into
the
mainstream
type
of
companies.
Now
it's
not
coming
in
at
the
let's
replace
everything
and
start
from
scratch
with
this
new
stuff
is
starting
on
smaller
projects,
sometimes
sometimes
bigger
projects,
but
it
absolutely
is
making
its
way
into
that
world.
Well,
what
caused
this?
Why
did
it
happen?
B
As
I
mentioned
earlier,
you
had
the
problem
of
web
applications
and
mobile
devices
and
all
of
this,
along
with
increased
user
expectations,
where
again
I
simply
need
to
be
available
all
the
time,
and
you
better
be
fast,
don't
make
me
wait
milliseconds
translate
into
millions
of
dollars
from
some
for
some
companies,
even
some
companies
with
web
properties,
where
they
need
to
do
transactions
or
selling
online.
So
it's
still
a
big
problem,
and
if
these
were
the
causes,
what
were
the
effects?
B
The
effects
on
the
architecture
were
I
got
to
be
able
to
scale
out
I
can't
keep
scaling.
This
thing
up.
I
have
to
handle
now
an
incredible
amount
of
velocity
that
I
never
had
to
deal
with.
In
the
past,
I
mean
you
got
to
understand
a
lot
of
times
when
we're
talking
to
customers.
It
is
not
at
all
an
uncommon
conversation
to
be
talking
about
how
many
millions
of
transactions
a
second,
are
you
going
to
need
on
this
system?
B
That's
common,
so
hundreds
of
thousands
of
transactions,
common,
that's
tough
in
the
relational
world
and
again
you'll
hire
people
say
that's
not
true.
I
can
do
that.
I
can
make
this
happen.
I
can
make
that
happen.
You
probably
can,
but
the
challenge
becomes
with
how
far
can
you
really
go
with
that
without
torturing
it
to
a
point
where
it's
simply
no
longer
a
relational
system,
and
you
have
to
start
thinking
about
the
new
technologies
and
what
make
these
beneficial
for
kind
of
the
right
tool
for
the
right
job
now.
B
The
this
part
about
rapidly
changing
apps
is
worth
pausing
on
for
a
moment,
because
when
you
used
to
change
an
app
it
was,
it
was
painful.
You
had
to
go
through
change
management.
You
had
to
go
kind
of
kiss
the
ring
of
the
DBA
and
get
all
those
processes
done
well
in
this
world.
You
have
these
things
called
flexible
schemas,
which
again
is
another
webinar
in
and
of
itself,
but
you
can
just
think
about
it
like
you
are
now
no
longer
bound
to
the
definition
of
your
data
model.
B
But
I
tell
you
watching
an
open-source
technology
go
through
those
types
of
folks.
The
innovators
in
the
early
adopters
is
astounding.
How
fast
it
will
travel
through
that
community
when
its
proprietary
software,
often
you
still
have
to
slow
down
and
wait
for
that,
but
in
this
world
it
goes
very
very
quickly.
But
how
do
we
get
across
that
chasm?
B
Well,
this
is
where
you
look
to
companies
like
a
red
hat
or
like
a
MySQL
or
in
our
case,
like
a
data
stack
to
help
you
get
over
that
into
the
mainstream,
because
it
gets
tough
when
you're
dealing
with
open
source
and
you
move
into
that
meat
of
that
curve.
There
are
just
some
things
you
expect
you
want
things
to
work
and
feel
a
certain
way,
and
you
don't
want
to
fight
every
single
little
problem
and
challenge
and
that's
why
companies
like
us
actually
exist.
So
a
couple
of
points
and
we'll
wrap
up
on
these.
B
Where
do
you
go
next?
Where
should
you
go
well?
The
first
thing
I
would
recommend
is
think
hard
about
what
you
want
with
a
given
problem
or
a
given
application,
because
this
really
is
about
the
right
tool
for
the
right
job
and
from
our
perspective,
I
can
tell
you
where
we
see
a
lot
of
demand
for
Cassandra
comes
around
this
notion
of
striving
for
a
continuously
available
architecture,
but
at
the
same
time,
I'm
fighting
against
three
problems
that
I
have
to
work
in
conjunction
with
each
other.
B
I
want
it
to
be
massively
scalable,
so
that
performs
well
at
ed
huge
scale,
but
I
have
to
keep
it
operationally
simple,
because
if
I
don't
I
blow
my
cost
model
out
of
the
water
and
for
something
that's
continuously
available,
I
also
want
to
access
it
from
anywhere.
This
is
where
you'll
see
Cassandra,
which,
by
the
way
in
the
developer
community
you'll,
often
see
abbreviated
with
a
with
a
sea
star,
which
is,
when
I
put
that
in
there.
This
is
where
I
live.
This
is
my
world,
so
I
won't
speak
on
behalf
of
other
technologies.
B
I
can
tell
you.
This
is
where
we
play,
and
this
is
a
very
real
demand
and
in
this
world
one
thing
you
have
to
get
over
is
that
it's
no
longer
a
world
of
either/or.
The
way
that
we
use
to
write
systems.
Look
like
this.
You
pick
the
database
and
you
wrote
your
app
against
that
database
done.
Then,
if
you
wanted
to
move
it
to
a
different
system,
you
did
that
etl
stuff
and
you
would
extracted
transform
it
loaded
somewhere
else,
and
everything
was
a
one-to-one
ratio
is
very
simple.
B
In
fact,
I'll
say
this
is
the
absolute
norm
with
all
of
our
customers
when
I
go
in
and
when
I
look
at
what
they're
architecting,
how
they're
architecting
it
through
a
services
layer
that
sits
between
the
app
and
the
data
stores,
you'll
have
a
roar,
achill
database
doing
its
thing,
but
Oracle's
put
in
its
proper
place
and
then
you'll
have
a
no
sequel
database
that
maybe
isn't
meant
to
scale.
Maybe
it's
going
to
handle
some
metadata
or
some
login
information.
B
B
The
next
thing
would
be
to
think
ahead.
Think,
through
the
use
cases,
the
challenge
was
when
we
looked
at
that
world
of
how
we
used
to
handle
real
time
and
data
warehousing.
This
had
problems,
it
really
did
d
couple
the
development
process
and
the
business
suffered
for
it,
because
the
business
would
then
lag
behind
because
we
had
to
wait
too
long
for
stuff
to
happen
from
the
OLAP
world
from
the
data
warehouse
world,
and
we
would.
B
So
we
take
Cassandra
as
our
foundation
with
it's
fully
distributed,
architecture
and
ability
to
do
great
massive
scale
and
key
performance
and
operational
simplicity,
and
we
bring
some
of
these
other
technologies
into
that
same
platform
and
we
call
it
datastax
enterprise.
So
if
you
need
to
look
at
Hadoop
for
batch
analytics
or
if
you
need
to
do
real-time
search
with
something
like
solar,
we
want
to
have
that
ready
for
you,
so
that
you
don't
have
to
fight
with
your
infrastructure
and
you
can
focus
instead
on
the
application.
B
That's
one
thing
we're
trying
to
bring
to
community
into
the
table
as
a
commercial
company.
The
next
thing
is
really
think
through
your
architecture,
choice.
This
is
the
number
one
regret
that
I
hear
from
customers
who
come
to
us
who
may
be
tried
a
different
technology
and
didn't
think
through
the
architecture.
So
this
can
bite
you
if
you
prototype
too
quickly,
and
then
suddenly
you
realize,
when
you
go
to
scale,
I've
got
a
problem,
and
so
what
you
need
to
think
about
in
this
world,
when
you
think
about
your
architectures,
you
really
have
two
choices.
B
You
have
what's
called
master
slave
and
you
have
fully
distributed
now,
there's
nuances
beyond
this,
but
but
in
general
these
are
the
two
and
you
can
think
about
a
master
slave
architecture
like
like
a
traffic
cop
managing
traffic.
Somebody
has
real
teeth:
real
authority
to
stop
the
flow
of
traffic
to
make
sure
that
a
certain
car
goes
in
at
a
certain
time
in
a
certain
way,
whereas
a
fully
distributed
architecture
looks
more
like
a
roundabout,
which
is
a
tough
concept
for
a
lot
of
us
in
America.
B
We
struggle
with
these
when
we
encounter
them,
but
they're,
very
common
in
the
rest
of
the
world
in
this
system
is
it's
a
self-governing
kind
of
come
on
when
you
need
to
come
on
and
exit
when
you
need
to
exit-
and
you
don't
have
that
traffic
cop,
that
has
the
authority
to
simply
stop
traffic.
It's
designed
to
let
traffic
flow
in
and
out
at
all
access
points,
and
that
has
consequences.
So,
if
you
think
about
setting
up
what
does
a
master-slave
architecture
tend
to
look
like?
B
What,
if
I
want
to
do
something
across
data
centers
or
in
the
cloud?
You
just
have
to
think
and
understand
about
how
these
things
work.
The
fully
distributed
architecture
is
a
little
different
in
this
architecture.
We
have
a
situation
where
you've
got
a
fully
distributed
environment
where
every
node
works,
the
same
home,
I
think
Alissa
groveling
our
slides
a
little
bit.
B
You
have
a
situation
where
every
node
works
the
same.
Every
node
is
of
the
same
type
and
these
nodes
all
communicate
directly
with
each
other
in
a
way
that
you
don't
have
this
concept
of
a
master.
Just
like
the
roundabout,
where
you
have
a
situation
where
every
node
typed
is
the
same
well,
what
are
the
implications
of
this?
The
implications
are
that
now,
with
a
system
like
that,
you
can
start
spreading
and
distributing
your
workload
across
multiple
data
centers.
B
This
is
now
becoming
a
very
common
type
of
architecture
where
you
have
a
physical
data
center
that
is
replicating
to
another
physical
data
center
and
then
you're
in
the
cloud,
and
these
are
all
working
together,
but
it's
not
just
replicating
from
one
central
point.
You
are
literally
having
everybody
access
all
the
system,
all
at
once
from
anywhere,
so
they
can
hit
it
from
the
cloud
they
can
hit
it
from
a
regional
data
center.
Why
would
you
want
to
do
that?
Well,
one
reason
might
be
disaster
avoidance.
B
You
simply
don't
even
want
to
deal
with
the
situation
where
the
data
center
is
no
longer
available
because
of
a
storm
or
an
outage,
or
something
like
that.
Another
reason
is
performance.
You
want
to
push
the
data
closer
to
where
your
users
are,
but
you
want
it
to
be
the
same
database
and
in
this
model
here
you're
looking
at
a
single
database
that
spans
multiple
things,
and
in
this
case
we
have
like
a
Davis
tax
enterprise
scenario,
where
some
of
the
work
load
might
be
cassandra.
B
Some
of
the
work
load
could
be
Hadoop,
some
could
be
searched
and
you
can
spread
that
workload
in
different
data
centers
becoming
very,
very
common
in
modern
real-time
applications
and
the
last
piece
that
I'll
leave
you
with
is
just
to
educate
yourself,
learn
as
much
as
you
can
and
we're
trying
to
help
you
with
this
kind
of
thing.
So
you
can
come
and
find
a
lot
of
great
resources
at
our
websites
that
are
case
studies
and
interviews
with
real
customers.
B
Customers,
as
you
guys
probably
know,
are
very
difficult,
sometimes
to
make
referenceable,
because
they
don't
want
to
tell
the
world
what
they're
doing
and
what
they're
working
on
that
said,
we
work
hard
to
try
and
give
you
as
many
real-world
use
cases
and
interviews
as
we
can.
So,
if
you
go
to
our
site,
you'll
see
I
think
we
have
20
or
25
of
them
up
there
right
now,
because
I
don't
think,
there's
any
better
way
to
learn.
B
When
then,
there
is
to
just
look
at
what
other
people
are
doing
and
understand
what
they're
doing
and
and
hear
it
from
them,
rather
than
hearing
it
from
us
in
our
marketing
next
thing
is:
we
just
had
a
great
conference
we
had
about
830
people,
I,
think
show
up
and
all
those
presentations
and
videos
are
online.
Here
again,
you
get
to
hear
it
right
from
the
people
who
are
living
and
breathing
it.
We
got
white
papers
to
cover
everything
from
relational
people
trying
to
grasp
this
stuff
to
where
do
I
even
begin?
B
Why
do
I
care
we've
got
existing
webinars
that
are
up
there?
We've
got
trains
that
we
do
around
the
country,
but
one
thing
I
would
really
encourage
you
to
do
is
if
you're
interested
in
this,
and
you
want
to
kind
of
get
up
to
speed,
we're
introducing
a
new
webinar
series.
That
is
a
very
systematic
approach
to
educating
you
through
the
process
and
over
the
next
couple
of
months.
B
You
can
actually
work
your
way
up
from
what
the
heck
is
no
SQL
and
why
do
I
care
to,
by
the
end
of
the
time
you'll
be
actually
doing
a
sample
app
or
you
can
have
some
folks
in
your
company
going
sample,
apps
and
learning
and
understanding
about
how
to
do
even
some
deeper
integration
with
some
other
technologies.
This
is
the
kind
of
stuff
we
want
to
make
sure
that
we're
educating
you
to
keep
you
up
to
speed.
All
this
stuff
is
free.
B
You
can
come
on
and
and
sign
up
for
all
these
absolutely
no
strings
attached.
We
just
want
to
help
educate
the
community
on
what
and
why
is
going
on
so
with
that
I'm
going
to
wrap
up
the
main
presentation,
part
and
bounce
over
here
and
see
if
we
have
any
any
questions
that
I
can
that
I
can
take
Thank.
A
You
Billy,
that
was
an
excellent
presentation
before
we
begin
with
today's
QA,
please
fill
out
the
feedback
form
that
has
opened
on
your
computer
to
complete
the
form.
Please
press
the
submit
answer
button
at
the
bottom
of
the
page.
Thank
you
in
advance
are
filling
out
the
feedback
form.
Your
participation
in
this
survey
allows
us
to
better
serve
you
and
now
to
the
question
and
answer
portion
of
the
event
as
a
reminder
to
participate
in
the
Q&A
just
type.
Your
question
into
the
text
box
located
below
the
media
player.
Then
click
the
submit
question
button.
A
B
Sure
I'll
keep
this
quick
because
it
can
be
complicated
again.
There
are.
There
are
different
types
of
consistency
when
you're
talking
about
a
database
technology.
One
of
the
biggest
problems
is,
is
what
we
call
data.
Consistency
is
if
I
update
a
field,
and
somebody
else
comes
into
the
system,
but
but
perhaps
they're
on
a
different
side
of
the
planet
they're
over
in
London
or
something,
and
they
want
to
look
at
that
same
data
information.
B
So
I
update
that
the
number
of
people
on
a
flight
is
is
130,
but
the
previous
number
was
50
well
now
that
person
in
London
was
to
look
at
that
and
what
are
they
going
to
see?
Are
they
going
to
see
hundred
thirty?
Are
they
going
to
see
50
well
by
default?
One
of
the
ways
we
handle
that
is
called
eventual
consistency,
which
means
eventually,
when
the
system
gets
around
to
it,
that
guy
in
London
will
c
130.
B
B
Unfortunately,
many
of
us
who
come
from
the
relational
world,
our
minds
always
go
to
the
need
for
absolute
consistency,
but
when
you
really
think
about
it
in
many
many
many
parts
of
your
application,
you
don't
need
that,
and
so,
but
we
try
and
give
you
the
choice.
Now
there
are
different
types
of
consistency
that
frankly,
no
sequel
solutions
near
as
I
can
tell,
are
never
going
to
solve
like
referential
integrity.
Things
like
that,
so
because
that
just
doesn't
exist
in
a
relational
model.
B
Yeah
well,
I
think
that's
even
a
question
for
local
data
centers
as
well
as
Amazon,
certainly,
and
we
have
customers
doing
both.
We
have
very
large
implementations
on
amazon.
Netflix
is
one
of
our
public
ones
that
talks
a
lot
about
what
they
do
and
they
are.
They
are,
in
fact
an
SSD
user,
but
then
we
have
people
who
asked
that
exact
same
question
and
data
centers.
B
Here's
the
thing
again,
which
one
of
the
things
about
Cassandra
that
I
love
just
the
kind
of
geek
in
me-
is
that
you
do
get
a
lot
of
flexibility
and
one
of
the
things
that
they
added
in
the
last
release
of
cassandra
is
the
ability
to
segment
workloads
to
certain
deck
types.
So
suppose
you
have
a
certain
table
for
people
with
relational
mugs.
Think
about
it
like
that,
you
have
a
table
that
is
very
performance,
intensive
and
demanding.
B
Well,
perhaps
you
want
to
route
the
workload
for
that
table
to
an
SSD
bank,
but
for
another
part
of
your
application,
where
it's
not
as
important
you'd
like
that
to
route
to
lower
costs
magnetic
disks
or
spinning
disks.
You
can
absolutely
separate
that
workload.
You
can
change
that
over
time,
so
you
have
a
lot
of
flexibility
and
really
it
depends
on
your
budget.
Cassandra
is
absolutely
optimized
for
SSD
performance
and
some
of
the
things
that
it
does
is
pretty
phenomenal,
actually
that
we
have
some
great
resources
on
this.
B
If
anybody
wants
to
email
me
directly
or
send
a
note
to
us
at
datastax,
we'll
get
you
a
great
white
paper
on
that.
But
yeah
at
these
I
think
are
a
big,
big,
big
part
of
our
future
and
I.
Think
for
a
long
time
to
come,
it's
going
to
be
a
mixed
workload.
Environment
of
some
workloads
going
to
be
on
the
very,
very,
very
cheap,
spinning
disks
and
other
workloads
are
going
to
be
on
the
more
affordable
nowadays
as
as
these
thank.
A
B
Yeah
I
would
say
absolutely
because
the
thing
about
the
Hadoop
systems
are
when
you
have
a
Hadoop
type
problem,
you're,
typically
looking
at
some
sort
of
deep
analysis,
we
wanted
to
analyze
something.
Well,
what
are
you
wanting
to
analyze?
Typically,
the
data
that
you're
willing
to
analyze
comes
from
some
real
time
system.
I
mean
this,
isn't
quantum
mechanics
things
just
don't
pop
into
existence
right,
so
the
data
comes
from
somewhere
when
you
start
thinking
about
that
real
time
system
that
you're
building
with
cassandra.
B
This
is
again
where
datastax
comes
in
and
says:
let
us
bring
the
other
technologies
to
that
data,
so
we
can
come
in
and
absolutely
configure
that
Hadoop
workload
right
on
top
of
that
same
data
and
what
we
do
when
we
do.
That
is
separate
the
workloads
and
anybody.
That's
lived
through
the
past
on
well
wait
a
minute.
Why
do
we
have
data
warehouses?
Well
because
the
workloads
killed
each
other?
B
The
cool
thing
about
Cassandra's
architecture
is
that
because
it
is
fully
distributed
because
it
is
not
master
slave,
we
can
partition
out
different
workloads
in
datastax
enterprise
on
a
Cassandra
ring
and
say
we
want
these
10
nodes
or
20
nodes
to
be
operating
as
Hadoop
nodes.
We
want
these
30
notes
as
Cassandra
nodes.
We
want
these
five
nodes,
the
search
notes
whatever
and
you
can
add
to
that
capacity
in
each
one
without
stepping
on
top
of
each
other.
B
So
sure
absolutely
you
can
look
at
us
for
for
that
kind
of
use
case,
I
would
say,
probably
once
you
start
doing,
that
you
will
probably
start
looking
at
it
a
little
more
holistically
and
instead
of
looking
at
just
hadoop
for
this
and
then
I'm
going
to
go.
Look
at
cassandra
for
that.
This
is
where
you
probably
take
a
step
back
and
say:
do
I
want
to
fight
all
that?
B
Do
I
want
to
fight
the
integration
of
all
those
systems
or
would
I
like
to
have
all
that
nicely
packaged
together
and
integrated
certified
tested,
thats
datastax
enterprise.
So
it
really
depends
on
where
you
are
on
that
curve.
Think
about
that
chasm
crossing
the
chasm
curb
if
you're
to
the
left.
You
might
well
want
to
do
that
fight
with
all
the
because
it's
fun
you
enjoy
it.
B
Yeah,
so
there
are
a
couple
things.
First
of
all,
what
we
provide
with
their
sex
enterprise
is
a
tool
called
off
center
and
with
op
center
you
have
a
web-based
application.
That's
completely
graphical
that
lets
you
from
there.
You
can
go
in
and
do
all
your
management
and
your
monitoring
all
the
stuff.
You
would
expect
to
do
when
you're,
when
you're
running
a
system,
because
it
is
web-based,
is
great,
it's
easily
accessible
anywhere,
but
it
also
handles
the
mixed
type.
B
So
you've
got
not
just
your
Cassandra
environment,
but
your
solar
environment,
your
Hadoop
environment,
all
in
a
single
pane
of
glass.
So
that's
one
thing
second
thing
a
little
little
plug
for
my
former
company,
just
because
it
was
one
of
my
products
that
that
I
launched
when
I
was.
There
is
called
total
cloud
databases.
B
So
you
can
do
all
that
from
a
single
product
inquest
going
through
the
process
of
being
acquired
by
by
Del
right
now,
but
they're
they're
going
to
be
very
true
to
their
software
pioneering
in
the
database
space
and
give
a
little
plug
to
my
friends
there.
You
should
should
go
check
them
out
as
well.
Thank.
B
Just
that
you
know,
there's
one
thing
I
want
to
leave
you
with
is:
please
don't
be
afraid
to
ask
questions.
I,
see
this
all
the
time,
I
go
to
a
room
and
I'm
doing
a
presentation.
There
might
be
a
couple
hundred
people
in
the
room
and
I
can
just
tell
that
there
are
really
good
questions
there.
That
people
are
afraid
to
ask
because
they
feel,
like
everybody
else
around
them,
that
they've
got
it
and
they
feel
like
wool.
I,
don't
want
to
ask
that
question
that
seems
so
simple
and
so
obvious
like.
B
Why
did
these
things
they
created
in
the
first
place?
Why
can't
I
do
that
with
relational
whip?
What
do
you
mean
by
fully
distributed?
I?
Understand
that,
like
what
isn't
isn't
all
this
stuff
distributed
now,
just
ask
if
you
can't,
if
you
don't
want
to
do
in
a
public
setting
come
to
us
call
us
email
us
go
to
our
website,
will
try
and
help
you
out.
We
got
great
community
resources
to
help
you
out.
We
want
to
be
the
company
that
helps
you
get
through
this
curve.
B
You
got
again
20
years,
I've
been
around
relational
databases.
It's
in
my
blood
I
understand
how
hard
it
is.
We
start
talking
about
data
models.
Oh
my
goodness!
That's
where
you're
going
to
go
through
a
trippy,
mind
experience
you've,
gotta!
You
really
got
to
reset
how
you
think
about
these
things,
but
put
in
a
little
bit
of
time
doing
that
when
you
do
the
benefits
that
are
going
to
come
out
of
it,
the
other
side
are
going
to
be
fantastic.
You
is
a
relational
person
for
those
on
the
call.
B
You
are
incredibly
valuable
for
the
next
five
to
ten
years,
because
developers
love
building
stuff,
not
so
great,
at
maintaining
it
over
time
and
dbas
can
bring
so
much
institutional
knowledge
from
the
company
and
in
this
world,
of
both
and
and
and
where
you're
going
to
have
all
these
technologies.
Wouldn't
it
be
great
if
you
could
sit
down
at
the
table
as
a
voice
of
reason
to
say:
hey,
you
know
what
we
need
to
use
relational
for
this
piece.
I
want
to
use
Cassandra
for
this
piece.
I
want
to
use
this
for
this
piece.
B
You
can
become
a
trusted
advisor
and
a
true
administer
of
the
data,
not
just
a
database,
because
you
know
what
we're
just
a
database.
Don't
you
know,
don't
let
that
freak
you
out,
we
are
still
a
database,
and
people
are
with
relational
knowledge.
Have
a
lot
of
great
knowledge,
so
don't
be
afraid
to
ask
questions.
Educate
yourself,
ask
them
in
a
safe
place.
A
Thank
You
Billy
excellent,
closing
comments
for
more
information
related
to
today's
webcast.
Please
visit
any
of
the
resource
links
open
before
you
within
the
next
24
hours.
You
will
receive
a
personalized
follow-up
email
with
details
and
a
link
to
today's
presentation
on
demand.
Additionally,
you
can
do
today's
event
on
demand
by
visiting
WWNN
seminar.
Calm.
Thank
you
for
attending
today's
webcast,
bridging
the
great
divide,
the
relationship
of
our
DBMS
and
no
sequel
brought
to
you
by
information
week
and
datastax.
This
webcast
is
copyright.
A
2012
by
united
business
media
LLC,
the
presentation
materials
are
owned
by
or
copyrighted
if
that
is
the
case
by
information
week
and
datastax,
who
are
solely
responsible
for
its
content
and
the
individual
speakers
are
solely
responsible
for
their
content
and
their
opinions
on
behalf
of
our
guest
Philly
Bosworth
I'm
Eric
Bruno.
Thank
you
for
your
time
and
have
a
great
day.