the
NewSQL
database
youll
never
outgrow
OldSQL
vs.
NoSQL
vs.
NewSQL
on
New
OLTP
Michael
Stonebraker,
CTO
VoltDB,
Inc.
Old
OLTP
Remember
how
we
used
to
buy
airplane
Hckets
in
the
1980s
+By
telephone
+Through
an
intermediary
(professional
terminal
operator)
Commerce
at
the
speed
of
the
intermediary
In
1985,
1,000
transacHons
per
second
was
considered
an
incredible
stretch
goal!!!!
+HPTS
(1985)
VoltDB
How
has
OLTP
Changed
in
25
Years?
The
internet
+Client
is
no
longer
a
professional
terminal
operator
+Instead
Aunt
Martha
is
using
the
web
herself
+Sends
volume
through
the
roof
VoltDB
How
has
OLTP
Changed
in
25
Years?
PDAs
and
sensors
+Your
cell
phone
is
a
transacHon
originator
+Everything
is
being
geo-posiHoned
by
sensors
(marathon
runners,
your
car,
.)
+Sends
volume
through
the
roof
VoltDB
How
has
OLTP
Changed
in
25
Years?
The
deniHons
+Online
no
longer
exclusively
means
a
human
operator
The
oncoming
data
tsunami
is
o_en
device
and
system-generated
+TransacHon
now
transcends
the
tradiHonal
business
transacHon
High-throughput
ACID
write
operaHons
are
a
new
requirement
+HA
and
durability
are
now
core
database
requirements
VoltDB
Examples
Maintain
the
state
of
mulH-player
internet
games
Real
Hme
ad
placement
Fraud/intrusion
detecHon
Risk
management
on
Wall
Street
VoltDB
New
OLTP
Challenges
New
OLTP
and
You
You
need
to
ingest
the
rehose
in
real
Hme
You
need
to
process,
validate,
enrich
and
respond
in
real-Hme
You
o_en
need
real-Hme
analyHcs
VoltDBVoltDB
7
7
SoluHon
Choices
OldSQL
+Legacy
RDBMS
vendors
NoSQL
+Give
up
SQL
and
ACID
for
performance
NewSQL
+Preserve
SQL
and
ACID
+Get
performance
from
a
new
architecture
VoltDB
OldSQL
TradiHonal
SQL
vendors
(the
elephants)
+Code
lines
daHng
from
the
1980s
+bloatware
+Not
very
good
at
anything
Can
be
beaten
by
at
least
an
order
of
magnitude
in
every
verHcal
market
I
know
of
+Mediocre
performance
on
New
OLTP
At
low
velocity
it
doesnt
maeer
Otherwise
you
get
to
tear
your
hair
out
VoltDB
DBMS
Landscape
Other apps
DBMS
apps
Data Warehouse
VoltDB
OLTP
10
DBMS
Landscape
Performance
Needs
Other apps
high
low
high
Data Warehouse
VoltDB
high
OLTP
11
One
Size
Does
Not
Fit
All
--
Pictorially
Elephants only get
the crevices
NoSQL
Array
DBMSs
Open
source
VoltDB
Column stores
Low-overhead
Hadoop
Main memory DBs
12
Reality
Check
TPC-C
CPU
cycles
On
the
Shore
DBMS
prototype
Elephants
should
be
similar
VoltDB
13
The
Elephants
Are
slow
because
they
spend
all
of
their
Hme
on
overhead!!!
+Not
on
useful
work
Would
have
to
re-architect
their
legacy
code
to
do
beeer
VoltDB
14
To
Go
a
Lot
Faster
You
Have
to
Focus
on
overhead
+Beeer
B-trees
aects
only
4%
of
the
path
length
Get
rid
of
ALL
major
sources
of
overhead
+Main
memory
deployment
gets
rid
of
buer
pool
Leaving
other
75%
of
overhead
intact
i.e.
win
is
25%
VoltDB
15
Long
Term
Elephant
Outlook
Up
against
The
Innovators
Dilemma
+Steam
shovel
example
+Disk
drive
example
+See
the
book
by
Clayton
Christenson
for
more
details
Long
term
dri_
into
the
sunset
+The
most
likely
scenario
+Unless
they
can
solve
the
dilemma
VoltDB
16
NoSQL
Give
up
SQL
Give
up
ACID
VoltDB
17
Give
Up
SQL?
Compiler
translates
SQL
at
compile
Hme
into
a
sequence
of
low
level
operaHons
Similar
to
what
the
NoSQL
products
make
you
program
in
your
applicaHon
30
years
of
RDBMS
experience
+Hard
to
beat
the
compiler
+High
level
languages
are
good
(data
independence,
less
code,
)
+Stored
procedures
are
good!
One
round
trip
from
app
to
DBMS
rather
than
one
one
round
trip
per
record
Move
the
code
to
the
data,
not
the
other
way
around
VoltDB
18
Give
Up
ACID
If
you
need
data
accuracy,
giving
up
ACID
is
a
decision
to
tear
your
hair
out
by
doing
database
heavy
li_ing
in
user
code
Can
you
guarantee
you
wont
need
ACID
tomorrow?
ACID = goodness, in spite of what these guys say
VoltDB
19
Who
Needs
ACID?
Funds
transfer
+Or
anybody
moving
something
from
X
to
Y
Anybody
with
integrity
constraints
+Back
out
if
fails
+Anybody
for
whom
usually
ships
in
24
hours
is
not
an
acceptable
outcome
Anybody
with
a
mulH-record
state
+E.g.
move
and
shoot
VoltDB
20
Who
needs
ACID
in
replicaHon
Anybody
with
non-commutaHve
updates
+For
example,
+
and
*
dont
commute
Anybody
with
integrity
constraints
+Cant
sell
the
last
item
twice.
Eventual
consistency
means
creates
garbage
VoltDB
21
NoSQL
Summary
Appropriate
for
non-transacHonal
systems
Appropriate
for
single
record
transacHons
that
are
commutaHve
Not
a
good
t
for
New
OLTP
Use
the
right
tool
for
the
job
Interes5ng
Two
recently-proposed
NoSQL
language
standards
CQL
and
UnQL
are
amazingly
similar
to
(you
guessed
it!)
SQL
VoltDB
22
NewSQL
SQL
ACID
Performance
and
scalability
through
modern
innovaHve
so_ware
architecture
VoltDB
23
NewSQL
Needs
something
other
than
tradiHonal
record
level
locking
(1st
big
source
of
overhead)
+Hmestamp
order
+MVCC
+Your
good
idea
goes
here
VoltDB
24
NewSQL
Needs
a
soluHon
to
buer
pool
overhead
(2nd
big
source
of
overhead)
+Main
memory
(at
least
for
data
that
is
not
cold)
+Some
other
way
to
reduce
buer
pool
cost
VoltDB
25
NewSQL
Needs
a
soluHon
to
latching
for
shared
data
structures
(3rd
big
source
of
overhead)
+Some
innovaHve
use
of
B-trees
+Single-threading
+Your
good
idea
goes
here
VoltDB
26
NewSQL
Needs
a
soluHon
to
write-ahead
logging
(4th
big
source
of
overhead)
+Obvious
answer
is
built-in
replicaHon
and
failover
+New
OLTP
views
this
as
a
requirement
anyway
Some
details
+On-line
failover?
+On-line
failback?
+LAN
network
parHHoning?
+WAN
network
parHHoning?
VoltDB
27
A
NewSQL
Example
VoltDB
Main-memory
storage
Single
threaded,
run
Xacts
to
compleHon
+No
locking
+No
latching
Built-in
HA
and
durability
+No
log
(in
the
tradiHonal
sense)
VoltDB
28
Yabut:
What
About
MulHcore?
For
A
K-core
CPU,
divide
memory
into
K
(non
overlapping)
buckets
i.e.
convert
mulH-core
to
K
single
cores
VoltDB
29
Where
all
the
Hme
goes
revisited
Before
VoltDB
VoltDB
30
Current
VoltDB
Status
Runs
a
subset
of
SQL
(which
is
getng
larger)
On
VoltDB
clusters
(in
memory
on
commodity
gear)
No
WAN
support
yet
+Working
on
it
right
now
50X
a
popular
OldSQL
DBMS
on
TPC-C
5-7X
Cassandra
on
VoltDB
K-V
layer
Scales
to
384
cores
(biggest
iron
we
could
get
our
hands
on)
Clearly
note
this
is
an
open
source
system!
VoltDB
31
Summary
Old
OLTP
New
OLTP
OldSQL
for
New
OLTP
Too
slow
Does
not
scale
NoSQL
for
New
OLTP
Lacks
consistency
guarantees
Low-level
interface
NewSQL
for
New
OLTP
Fast,
scalable
and
consistent
Supports
SQL
VoltDB
32
the
NewSQL
database
youll
never
outgrow
Thank
You
