FoundationDB - NoSQL and ACID
-
Upload
insidehpc -
Category
Technology
-
view
703 -
download
6
description
Transcript of FoundationDB - NoSQL and ACID
![Page 2: FoundationDB - NoSQL and ACID](https://reader033.fdocuments.in/reader033/viewer/2022061218/54b763234a7959b0558b4636/html5/thumbnails/2.jpg)
NoSQL’s Motivation
Make it easy to build and deploy applications.
Ease of scaling and operation
Fault tolerance Many data models Good price/performanceX ACID transactions
![Page 3: FoundationDB - NoSQL and ACID](https://reader033.fdocuments.in/reader033/viewer/2022061218/54b763234a7959b0558b4636/html5/thumbnails/3.jpg)
The case for ACID in NoSQL
![Page 4: FoundationDB - NoSQL and ACID](https://reader033.fdocuments.in/reader033/viewer/2022061218/54b763234a7959b0558b4636/html5/thumbnails/4.jpg)
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.
![Page 5: FoundationDB - NoSQL and ACID](https://reader033.fdocuments.in/reader033/viewer/2022061218/54b763234a7959b0558b4636/html5/thumbnails/5.jpg)
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.
![Page 6: FoundationDB - NoSQL and ACID](https://reader033.fdocuments.in/reader033/viewer/2022061218/54b763234a7959b0558b4636/html5/thumbnails/6.jpg)
Abstractions
Abstractions built on a scalable, fault tolerant, transactional foundation inherit those properties.
And are easy to build…
![Page 7: FoundationDB - NoSQL and ACID](https://reader033.fdocuments.in/reader033/viewer/2022061218/54b763234a7959b0558b4636/html5/thumbnails/7.jpg)
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.
![Page 8: FoundationDB - NoSQL and ACID](https://reader033.fdocuments.in/reader033/viewer/2022061218/54b763234a7959b0558b4636/html5/thumbnails/8.jpg)
So why no ACID NoSQL?
![Page 9: FoundationDB - NoSQL and ACID](https://reader033.fdocuments.in/reader033/viewer/2022061218/54b763234a7959b0558b4636/html5/thumbnails/9.jpg)
Historical Perspective: 2008
In 2008, NoSQL doesn’t really exist yet.
2008
![Page 10: FoundationDB - NoSQL and ACID](https://reader033.fdocuments.in/reader033/viewer/2022061218/54b763234a7959b0558b4636/html5/thumbnails/10.jpg)
Databases in 2008
NoSQL emerges to replace scalable sharding/caching solutions that had already thrown out consistency.
• BigTable
• Dynamo
• Voldemort
• Cassandra
![Page 11: FoundationDB - NoSQL and ACID](https://reader033.fdocuments.in/reader033/viewer/2022061218/54b763234a7959b0558b4636/html5/thumbnails/11.jpg)
The CAP2008 theorem
“Pick 2 out of 3”
- Eric Brewer
![Page 12: FoundationDB - NoSQL and ACID](https://reader033.fdocuments.in/reader033/viewer/2022061218/54b763234a7959b0558b4636/html5/thumbnails/12.jpg)
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)
![Page 13: FoundationDB - NoSQL and ACID](https://reader033.fdocuments.in/reader033/viewer/2022061218/54b763234a7959b0558b4636/html5/thumbnails/13.jpg)
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
![Page 14: FoundationDB - NoSQL and ACID](https://reader033.fdocuments.in/reader033/viewer/2022061218/54b763234a7959b0558b4636/html5/thumbnails/14.jpg)
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?
![Page 15: FoundationDB - NoSQL and ACID](https://reader033.fdocuments.in/reader033/viewer/2022061218/54b763234a7959b0558b4636/html5/thumbnails/15.jpg)
Thinking about CAP2008
CAP availability != High availability
![Page 16: FoundationDB - NoSQL and ACID](https://reader033.fdocuments.in/reader033/viewer/2022061218/54b763234a7959b0558b4636/html5/thumbnails/16.jpg)
Fast forward to CAP2013
“Why ’2 out of 3’ is misleading”
“CAP prohibits… perfect availability”
- Eric Brewer
![Page 17: FoundationDB - NoSQL and ACID](https://reader033.fdocuments.in/reader033/viewer/2022061218/54b763234a7959b0558b4636/html5/thumbnails/17.jpg)
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)
![Page 18: FoundationDB - NoSQL and ACID](https://reader033.fdocuments.in/reader033/viewer/2022061218/54b763234a7959b0558b4636/html5/thumbnails/18.jpg)
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)
![Page 19: FoundationDB - NoSQL and ACID](https://reader033.fdocuments.in/reader033/viewer/2022061218/54b763234a7959b0558b4636/html5/thumbnails/19.jpg)
ACID + NoSQL!
![Page 20: FoundationDB - NoSQL and ACID](https://reader033.fdocuments.in/reader033/viewer/2022061218/54b763234a7959b0558b4636/html5/thumbnails/20.jpg)
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
![Page 21: FoundationDB - NoSQL and ACID](https://reader033.fdocuments.in/reader033/viewer/2022061218/54b763234a7959b0558b4636/html5/thumbnails/21.jpg)
Decomposition approach
Decompose the processing pipeline of a traditional ACID DB
into individual stages.
![Page 22: FoundationDB - NoSQL and ACID](https://reader033.fdocuments.in/reader033/viewer/2022061218/54b763234a7959b0558b4636/html5/thumbnails/22.jpg)
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
![Page 23: FoundationDB - NoSQL and ACID](https://reader033.fdocuments.in/reader033/viewer/2022061218/54b763234a7959b0558b4636/html5/thumbnails/23.jpg)
The performance surprise
ACID:10% of work
NoSQL:90% of work
![Page 24: FoundationDB - NoSQL and ACID](https://reader033.fdocuments.in/reader033/viewer/2022061218/54b763234a7959b0558b4636/html5/thumbnails/24.jpg)
FoundationDB
Database software:
• Scalable
• Fault tolerant
• Transactional
• Ordered key-value API
• Layers
ACID Key-value API
Graph SQL Doc Event
![Page 25: FoundationDB - NoSQL and ACID](https://reader033.fdocuments.in/reader033/viewer/2022061218/54b763234a7959b0558b4636/html5/thumbnails/25.jpg)
A vision for NoSQL
• The next generation should maintain– Scalability and fault tolerance
– High performance
• While adding– ACID transactions
– Data model flexibility