NoSQL and ACID
david.rosenthal@foundationdb.com
Twitter: @foundationdb
NoSQL‘s Motivation
Make it easy to build and deploy
applications.
 Ease of scaling and operation
 Fault tolerance
 Many...
What if we had ACID?
Good for financial applications?
Big performance hit?
Sacrifice availability?
Nope… When NoSQL has AC...
The case for ACID in NoSQL
Bugs don‘t appear under concurrency
• ACID means isolation.
• Reason locally rather than globally.
– If every transaction ...
Isolation means strong abstractions
• Example interface:
– storeUser(name, SSN)
– getName(SSN)
– getSSN(name)
• Invariant:...
Abstractions
Abstractions built on a scalable, fault
tolerant, transactional foundation
inherit those properties.
And are ...
Examples of ―easy‖
 SQL database in one day
 Indexed table layer (3 days * 1 intern)
 Fractal spatial index in 200 line...
Remove/decouple features from the DB
With strong abstractions, features can be
moved from the DB to more flexible code.
Ex...
Remove/decouple data models
• A NoSQL database with ACID can
provide polyglot data models and APIs.
– Key-value, graph, co...
So, why don't we have ACID?
• It‘s hard.
• History.
History
Historical Perspective: 2008
In 2008, NoSQL doesn’t really exist yet.
2008
Databases in 2008
NoSQL emerges to replace scalable
sharding/caching solutions that had already
thrown out consistency.
• ...
The CAP2008 theorem
―Pick 2 out of 3‖
- Eric Brewer
The CAP2008 theorem
―Data inconsistency in large-scale
reliable distributed systems has to be
tolerated … [for performance...
The CAP2008 theorem
―The availability property means that
the system is ‗online‘ and the client of
the system can expect t...
CAP2008 Conclusions?
• Scaling requires distributed design
• Distributed requires high availability
• Availability require...
Thinking about CAP2008
CAP availability != High availability
Fast forward to CAP2013
―Why ’2 out of 3’ is misleading‖
―CAP prohibits… perfect
availability‖
- Eric Brewer
Fast forward to CAP2013
―Achieving strict consistency can come
at a cost in update or read latency,
and may result in lowe...
Fast forward to CAP2013
―…it is better to have application
programmers deal with performance
problems due to overuse of tr...
The ACID NoSQL plan
• Maintain both scalability and fault tolerance
• Leverage CAP2013 and deliver a CP system
with true g...
Approaches
NoSQL
TRANSACTIONS / LOCKING
Bolt-on approach
Bolt transactions on top of a
database without transactions.
Bolt-on approach
Bolt transactions on top of a database
without transactions.
• Upside: Elegance.
• Downsides:
– Nerd trap...
Transactional building block approach
Use non-scalable transactional DBs
as components of a cluster.
•
Transactional building block approach
Use non-scalable transactional DBs as
components of a cluster.
• Upside: Local trans...
Decomposition approach
Decompose the processing pipeline of a
traditional ACID DB into individual
stages.
Decomposition approach
Decompose the processing pipeline of a
traditional ACID DB into individual stages.
• Stages:
– Acce...
Challenges with ACID
Disconnected operation challenge
• Offline sync is a real application need
Solution:
• Doing it in the DB layer is terribl...
Split brain challenge
• Any consistent database need a fault-tolerance
source of ―ground truth‖
• Must prevent database fr...
Latency challenge
• Durability costs latency
• Causal consistency costs latency
Solution:
• Bundling ops reduces overhead
...
Correctness challenge
• MaybeDB:
– Set(key, value) – Might set key to value
– Get(key) – Get a value that key was set to
S...
Implementation language challenge
We need new tools!
Goal Language
Many asynchronous
communicating processes
Erlang?
Engin...
Tools for achieving ACID
Flow
• A new programming language
• Adds actor-model concurrency to C++11
• New keywords: ACTOR, future, promise,
wait, ch...
Flow allows…
• Easier ACTOR-model coding
• Testability by enabling simulation
• Performance by compiling to native
Flow eases development
Flow eases development
Flow output
Flow performance
―Write a ring benchmark. Create N processes in a
ring. Send a message round the ring M times so that
a to...
Flow performance
(N=1000, M=1000)
• Ruby (using threads): 1990 seconds
• Ruby (queues): 360 seconds
• Objective C (using t...
Flow enables testability
• ―Lithium‖ testing framework
• Simulate all physical interfaces
• Simulate failures modes
• Dete...
Testability: Quicksand
FoundationDB is
NoSQL with ACID
FoundationDB
Database software:
• Scalable
• Fault tolerant
• Transactional
• Ordered key-value API
• Layers
Layers
Key-va...
Layers
• An open-source ecosystem
• Common NoSQL data models
• Graph database (implements BluePrints
2.4 standard)
• Zooke...
SQL Layer
• A full SQL database in a layer!
• Akiban acquisition
• Unique ―table group‖ concept can
physically store relat...
Performance results
• Reads of cacheable data are ½ the
speed of memcached—with full
consistency!
• Random uncacheable rea...
The big performance result
• Vogels: “Achieving strict consistency can
come at a cost in update or read
latency, and may r...
A vision for NoSQL
• The next generation should maintain
– Scalability and fault tolerance
– High performance
• While addi...
Thank you
david.rosenthal@foundationdb.com
Twitter: @foundationdb
Upcoming SlideShare
Loading in …5
×

NoSQL and ACID

3,434 views

Published on

This presentation, given by Dave Rosenthal at NoSQL Now! 2013, presents the case for why he believes NoSQL databases will need to support ACID transactions in order for developers to more easily build, deploy, and scale applications in the future.

Published in: Technology
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
3,434
On SlideShare
0
From Embeds
0
Number of Embeds
1,897
Actions
Shares
0
Downloads
50
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide

NoSQL and ACID

  1. 1. NoSQL and ACID david.rosenthal@foundationdb.com Twitter: @foundationdb
  2. 2. NoSQL‘s Motivation Make it easy to build and deploy applications.  Ease of scaling and operation  Fault tolerance  Many data models  Good price/performance X ACID transactions
  3. 3. What if we had ACID? Good for financial applications? Big performance hit? Sacrifice availability? Nope… When NoSQL has ACID, it opens up a very different path.
  4. 4. The case for ACID in NoSQL
  5. 5. Bugs don‘t appear under concurrency • ACID means isolation. • Reason locally rather than globally. – If every transaction maintains an invariant, then multiple clients running any combination of concurrent transactions also maintain that invariant. • The impact of each client is isolated.
  6. 6. Isolation means strong abstractions • Example interface: – storeUser(name, SSN) – getName(SSN) – getSSN(name) • Invariant: N == getName(getSSN(N)) – Always works with single client. – Without ACID: Fails with concurrent clients. – With ACID: Works with concurrent clients.
  7. 7. Abstractions Abstractions built on a scalable, fault tolerant, transactional foundation inherit those properties. And are easy to build…
  8. 8. Examples of ―easy‖  SQL database in one day  Indexed table layer (3 days * 1 intern)  Fractal spatial index in 200 lines:
  9. 9. Remove/decouple features from the DB With strong abstractions, features can be moved from the DB to more flexible code. Examples: – Indexing – More efficient data structures (e.g. using pointers/indirection) – Query language
  10. 10. Remove/decouple data models • A NoSQL database with ACID can provide polyglot data models and APIs. – Key-value, graph, column-oriented, document, relational, publish-subscribe, spatial, blobs, ORMs, analytics, etc… • Without requiring separate physical databases. This is a huge ops win.
  11. 11. So, why don't we have ACID? • It‘s hard. • History.
  12. 12. History
  13. 13. Historical Perspective: 2008 In 2008, NoSQL doesn’t really exist yet. 2008
  14. 14. Databases in 2008 NoSQL emerges to replace scalable sharding/caching solutions that had already thrown out consistency. • BigTable • Dynamo • Voldemort • Cassandra
  15. 15. The CAP2008 theorem ―Pick 2 out of 3‖ - Eric Brewer
  16. 16. The CAP2008 theorem ―Data inconsistency in large-scale reliable distributed systems has to be tolerated … [for performance and to handle faults]‖ - Werner Vogles (CTO Amazon.com)
  17. 17. The CAP2008 theorem ―The availability property means that the system is ‗online‘ and the client of the system can expect to receive a response for its request.‖ - Wrong descriptions all over the web
  18. 18. CAP2008 Conclusions? • Scaling requires distributed design • Distributed requires high availability • Availability requires no C So, if we want scalability we have to give up C, a cornerstone of ACID, right?
  19. 19. Thinking about CAP2008 CAP availability != High availability
  20. 20. Fast forward to CAP2013 ―Why ’2 out of 3’ is misleading‖ ―CAP prohibits… perfect availability‖ - Eric Brewer
  21. 21. Fast forward to CAP2013 ―Achieving strict consistency can come at a cost in update or read latency, and may result in lower throughput…‖ - Werner Vogles (Amazon CTO)
  22. 22. Fast forward to CAP2013 ―…it is better to have application programmers deal with performance problems due to overuse of transactions as bottlenecks arise, rather than always coding around the lack of transactions.― - Google (Spanner)
  23. 23. The ACID NoSQL plan • Maintain both scalability and fault tolerance • Leverage CAP2013 and deliver a CP system with true global ACID transactions • Enable abstractions and many data models • Deliver high per-node performance
  24. 24. Approaches
  25. 25. NoSQL TRANSACTIONS / LOCKING Bolt-on approach Bolt transactions on top of a database without transactions.
  26. 26. Bolt-on approach Bolt transactions on top of a database without transactions. • Upside: Elegance. • Downsides: – Nerd trap – Performance. ―…integrating multiple layers has its advantages: integrating concurrency control with replication reduces the cost of commit wait in Spanner, for example‖ -Google NoSQL TRANSACTIONS / LOCKING
  27. 27. Transactional building block approach Use non-scalable transactional DBs as components of a cluster. •
  28. 28. Transactional building block approach Use non-scalable transactional DBs as components of a cluster. • Upside: Local transactions are fast • Downside: Distributed transactions across machines are hard to make fast, and are messy (timeouts required)
  29. 29. Decomposition approach Decompose the processing pipeline of a traditional ACID DB into individual stages.
  30. 30. Decomposition approach Decompose the processing pipeline of a traditional ACID DB into individual stages. • Stages: – Accept client transactions – Apply concurrency control – Write to transaction logs – Update persistent data representation • Upside: Performance • Downside: ―Ugly‖ and complex architecture needs to solve tough problems for each stage
  31. 31. Challenges with ACID
  32. 32. Disconnected operation challenge • Offline sync is a real application need Solution: • Doing it in the DB layer is terrible • Can (and should) be solved by the app, E.g. by buffering mutations, sync‘ing when connected
  33. 33. Split brain challenge • Any consistent database need a fault-tolerance source of ―ground truth‖ • Must prevent database from splitting into two independent parts Solution : • Using thoughtfully chosen Paxos nodes can yield high availability, even for drastic failure scenarios • Paxos is not required for each transaction
  34. 34. Latency challenge • Durability costs latency • Causal consistency costs latency Solution: • Bundling ops reduces overhead • ACID costs only needed for ACID guarantees
  35. 35. Correctness challenge • MaybeDB: – Set(key, value) – Might set key to value – Get(key) – Get a value that key was set to Solution: • The much stronger ACID contract requires vastly more powerful tools for testing
  36. 36. Implementation language challenge We need new tools! Goal Language Many asynchronous communicating processes Erlang? Engineering for reliability and fault tolerance of large clusters while maintaining correctness Simulation Fast algorithms; efficient I/O C++
  37. 37. Tools for achieving ACID
  38. 38. Flow • A new programming language • Adds actor-model concurrency to C++11 • New keywords: ACTOR, future, promise, wait, choose, when, streams • Transcompilation: – Flow code -> C++11 code -> native Seriously?
  39. 39. Flow allows… • Easier ACTOR-model coding • Testability by enabling simulation • Performance by compiling to native
  40. 40. Flow eases development
  41. 41. Flow eases development
  42. 42. Flow output
  43. 43. Flow performance ―Write a ring benchmark. Create N processes in a ring. Send a message round the ring M times so that a total of N * M messages get sent. Time how long this takes for different values of N and M. Write a similar program in some other programming language you are familiar with. Compare the results. Write a blog, and publish the results on the internet!‖ - Joe Armstrong (author of ―Programming Erlang‖)
  44. 44. Flow performance (N=1000, M=1000) • Ruby (using threads): 1990 seconds • Ruby (queues): 360 seconds • Objective C (using threads): 26 seconds • Java (threads): 12 seconds • Stackless Python: 1.68 seconds • Erlang: 1.09 seconds • Google Go: 0.87 seconds • Flow: 0.075 seconds
  45. 45. Flow enables testability • ―Lithium‖ testing framework • Simulate all physical interfaces • Simulate failures modes • Deterministic (!) simulation of entire system Simulation is the key for correctness.
  46. 46. Testability: Quicksand
  47. 47. FoundationDB is NoSQL with ACID
  48. 48. FoundationDB Database software: • Scalable • Fault tolerant • Transactional • Ordered key-value API • Layers Layers Key-value API
  49. 49. Layers • An open-source ecosystem • Common NoSQL data models • Graph database (implements BluePrints 2.4 standard) • Zookeeper-like coordination layer • Celery (distributed task queue) layer • Many others…
  50. 50. SQL Layer • A full SQL database in a layer! • Akiban acquisition • Unique ―table group‖ concept can physically store related tables in an efficient ―object structure‖ • Architecture: stateless, local server
  51. 51. Performance results • Reads of cacheable data are ½ the speed of memcached—with full consistency! • Random uncacheable reads of 4k ranges saturate network bandwidth • A 24-machine cluster processing 100% cross-node transactions saturates its SSDs at 890,000 op/s
  52. 52. The big performance result • Vogels: “Achieving strict consistency can come at a cost in update or read latency, and may result in lower throughput…” • Ok, so, how much? – Only ~10%! – Transaction isolation—the ―intuitive bottleneck‖ is accomplished in less than one core.
  53. 53. A vision for NoSQL • The next generation should maintain – Scalability and fault tolerance – High performance • While adding – ACID transactions – Data model flexibility
  54. 54. Thank you david.rosenthal@foundationdb.com Twitter: @foundationdb

×