FOSDEM 2015 - NoSQL and SQL the best of both worlds

NoSQL and SQL: The Best of Both
Worlds
Andrew Morgan
@andrewmorgan
clusterdb.com
1st February 2015
1/2/2015 Copyright © 2015, Oracle and/or its affiliates. All rights reserved.

Graph Database

NoSQL
Simple access patterns
Compromise on consistency
for performance
Ad-hoc data format
Simple operation
SQL
Complex queries with joins
ACID transactions
Well defined schemas
Rich set of tools
Still a role for SQL (RDBMS)?
Scalability
Performance
HA
Ease of use
SQL/Joins
ACID Transactions

The Temptation to Jettison Relational Model
• Relational Model:
– Data stored in multiple tables
– Many lookups to retrieve a user’s
timeline
– Is it worth the effort in setting up
this complex data model?
• Simpler just to store as one
document?
The allure of document stores
Examples borrowed from @sarahmei https://speakerdeck.com/sarahmei/switching-data-stores-a-postmodern-comedy
user
friend
post
comment
like
liker
commenter
many
many
many
one
one
many

• Document Model:
– Entire timeline in a single
document (row)
– Single lookup to retrieve the
user’s timeline
– Brilliantly efficient model when
the document truly contains self-
contained information
• Like a real-world document!
{name: ‘Joe’,
url: ‘http://clusterdb.com’,
stream:[
{friend:{
name: ‘Jane’,
posts:[{content: ‘…’,
comments:[
{comment: ‘…’,
commenter: ‘Joe’},
{…}
],
likes: [‘Joe’, ‘Fred’, ‘Billy’]
},
{…},{…},…
]
}, {…},{…},…
}

• These are all people who have
their own data that users will
want to view or click through:
– Name
– url
– Timeline
• Easy to represent with FKs in a
relational model
But when the data isn’t self contained…
user
friend
post
comment
like
liker
commenter
many
many
many
one
one
many

• Do I store all data for all friends
and likers again at every point they
appear in the document?
• Massive amount of repeated data
– Wasted space
– Needs to be kept in sync (and you don’t
have transactions to provide
consistency)
{name: ‘Joe’,
url: ‘http://clusterdb.com’,
stream:[
{friend:{
name: ‘Jane’,
comments:[
commenter: ‘Joe’},
{…}
],
likes: [‘Joe’, ‘Fred’, ‘Billy’]
},
{…},{…},…
]
}, {…},{…},…
}

• The reality is that the developer
will store the user-ids instead
• Developer is responsible for
implementing ‘joins’ in the
application
– e.g. scanning all timelines for where a
user made a comment or liked a post
• No transactions to ensure
consistency between documents
{name: 83746251,
url: ‘…’
stream:[
{friend:{
name: 9384726153,
comments:[
commenter: 83746251},
{…}
],
likes: [83746251, 750730283,
2938493820]
},
{…},{…},…
]
}, {…},{…},…
}

• Each attribute’s labels are stored in
every document
– More wasted space
– Developers compensate by replacing
with short names
{n5: 83746251,
u2: ‘…’
s1:[
{f2:{
n5: 9384726153,
p4:[{c4: ‘…’,
c3:[
{c2: ‘…’,
c8: 83746251},
{…}
],
l5: [83746251, 750730283,
2938493820]
},
{…},{…},…
]
}, {…},{…},…
}

MySQL Cluster Overview
• In-Memory Optimization + Disk-Data
• Predictable Low-Latency, Bounded Access Time
REAL-TIME
• Auto-Sharding, Multi-Master
• ACID Compliant, OLTP + Real-Time Analytics
HIGH SCALE, READS +
WRITES
• Shared nothing, no Single Point of Failure
• Self Healing + On-Line Operations
99.999% AVAILABILITY
• Key/Value + Complex, Relational Queries
• SQL + Memcached + JavaScript + Java + HTTP/REST & C++
SQL + NoSQL
• Open Source + Commercial Editions
• Commodity hardware + Management, Monitoring Tools
LOW TCO

MySQL Cluster Architecture
MySQL Cluster Data Nodes
Clients
Application Layer
Data Layer

MySQL Cluster Scaling
Clients
Application Layer
Data Layer

MySQL Cluster HA
Clients
Application Layer
Data Layer

1.2 Billion UPDATEs per Minute
• Distributed Joins also
possible
0
5
10
15
20
25
2 4 6 8 10 12 14 16 18 20 22 24 26 28 30
MillionsofUPDATEsperSecond
Scalability a
Performance a
HA a
Ease of use
SQL/Joins a
ACID Transactions a

Scalability a
Performance a
HA a
Ease of use a
SQL/Joins a
ACID Transactions a

NoSQL Access to MySQL Cluster data
Apps Apps Apps Apps Apps Apps Apps Apps Apps Apps Apps Apps
JPA
Cluster JPA
PHP Perl Python Ruby JDBC Cluster J JS Apache Memcached
MySQL JNI Node.JS mod_ndb ndb_eng
NDB API (C++)

Cluster & Memcached – Schema-Free
<town:maidenhead,SL6>
key value
key value
Key Value
town:maidenhead SL6
generic table
Application view
SQL view

Cluster & Memcached - Configured Schema
prefix key value
key value
Prefix Table Key-col Val-col policy
town: map.zip town code cluster
Config tables
town ... code ...
maidenhead ... SL6 ...
map.zip
Application view
SQL view

NoSQL API for Node.js & FKs
FKs enforced on all APIs:
{ message: 'Error',
sqlstate: '23000',
ndb_error: null,
cause:
{message: 'Foreign key constraint violated: No parent row found [255]',
sqlstate: '23000',
ndb_error:
{ message: 'Foreign key constraint violated: No parent row found',
code: 255,
classification: 'ConstraintViolation',
handler_error_code: 151,
status: 'PermanentError' },
cause: null } }

Next Steps
Learn More
• www.mysql.com/cluster
• Authentic MySQL Curriculum: http://oracle.com/education/mysql
Try it Out
• dev.mysql.com/downloads/cluster/
Let us know what you think
• clusterdb.com
• @clusterdb
• forums.mysql.com/list.php?25

FOSDEM 2015 - NoSQL and SQL the best of both worlds

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (15)

Similar to FOSDEM 2015 - NoSQL and SQL the best of both worlds

Similar to FOSDEM 2015 - NoSQL and SQL the best of both worlds (20)

More from Andrew Morgan

More from Andrew Morgan (7)

Recently uploaded

Recently uploaded (20)

FOSDEM 2015 - NoSQL and SQL the best of both worlds