1. Introduction to NewSQL
Xintao Wu
Oct 20, 2015

2. 451 Group’s Definition
A DBMS that delivers the scalability and flexibility promised by NoSQL while retaining the support for SQL queries and/or ACID, or to improve performance for appropriate workloads

3. Stonebraker’s Definition
SQL as the primary interface
ACID support for transactions
Non-locking concurrency control
High per-node performance
Parallel, shared-nothing architecture

4. NoSQL vs. NewSQL NoSQL NewSQL
New breed of non-relational database products
Rejections of fixed table schema and join operations
Designed to meet scalability requirements of distributed architectures
And/or schema-less data management requirements
NewSQL
New breed of relational database products
Retain SQL and ACID
Designed to meet scalability requirements of distributed architectures

7. CAP Theorem A distributed system can satisfy two but not three out of:
Consistency – all nodes see the same data at the same time
Availability – every request receives a response whether it succeeded or failed
Partition tolerance – operates despite of message loss or failure of part of the system

8. Scale To achieve high performance and consistency we should:
Scale in – execute all transactions in RAM (performance) on the same computer (consistency)
Scale up – get a powerful multi-core server with a lot of RAM (performance)

10. Transaction Bottlenecks
Disk Reads/Writes
Persistent Data, Undo/Redo Logs
Network Communication
Intra-Node, Client-Server
Concurrency Control
Locking, Latching
A OLTP transaction is often fast, repetitive and small.

11. An Ideal OLTP System Main memory only No multi-processor overhead
High scalability
High availability
Autonomic configuration

12. NewSQL Needs (from Stonebraker)
Needs something other than traditional record level locking
Timestamp order, MVCC
Needs a solution to buffer pool overhead
Main memory, other ways to reduce buffer pool cost
Needs a solution to latching for shared data structures
Innovative use of B-trees, Single-threading
Needs a solution to write-ahead logging
Built-in replication and failover

13. Multiversion concurrency control
Scenario
A is reading at the same time B is writing
A may see a half-written or inconsistent piece of data
Lock/timestamp could be slow
MVCC
Each user sees a snapshot at a particular time.
Any changes made by a writer will not be seen by others until the transaction has been committed.
When database updates an item, it marks the old data as obsolete and adds the newer version elsewhere.
Hence multiple versions are stored, but only one is the latest.

14. /