Don t Give Up on Serializability Just Yet. Neha Narula

Similar documents
Distributed Systems. Lec 12: Consistency Models Sequential, Causal, and Eventual Consistency. Slide acks: Jinyang Li

Consistency. CS 475, Spring 2018 Concurrent & Distributed Systems

Large-Scale Key-Value Stores Eventual Consistency Marco Serafini

CS October 2017

Consistency: Relaxed. SWE 622, Spring 2017 Distributed Software Engineering

CISC 7610 Lecture 2b The beginnings of NoSQL

Distributed Systems. Characteristics of Distributed Systems. Lecture Notes 1 Basic Concepts. Operating Systems. Anand Tripathi

Distributed Systems. Characteristics of Distributed Systems. Characteristics of Distributed Systems. Goals in Distributed System Designs

Megastore: Providing Scalable, Highly Available Storage for Interactive Services & Spanner: Google s Globally- Distributed Database.

Replication and Consistency

Causal Consistency and Two-Phase Commit

Cloud Computing. DB Special Topics Lecture (10/5/2012) Kyle Hale Maciej Swiech

Integrity in Distributed Databases

CS6450: Distributed Systems Lecture 11. Ryan Stutsman

Distributed Systems COMP 212. Revision 2 Othon Michail

Lecture 6 Consistency and Replication

DrRobert N. M. Watson

Performance and Forgiveness. June 23, 2008 Margo Seltzer Harvard University School of Engineering and Applied Sciences

EECS 498 Introduction to Distributed Systems

FIT: A Distributed Database Performance Tradeoff. Faleiro and Abadi CS590-BDS Thamir Qadah

Distributed Data Management Transactions

Transactions Between Distributed Ledgers

CSE 530A ACID. Washington University Fall 2013

SCALABLE CONSISTENCY AND TRANSACTION MODELS

Building Consistent Transactions with Inconsistent Replication

10. Replication. Motivation

CS6450: Distributed Systems Lecture 15. Ryan Stutsman

Migrating Oracle Databases To Cassandra

Replications and Consensus

Strong Consistency & CAP Theorem

Consistency in Distributed Storage Systems. Mihir Nanavati March 4 th, 2016

Choosing a MySQL HA Solution Today. Choosing the best solution among a myriad of options

Distributed Systems (5DV147)

CMU SCS CMU SCS Who: What: When: Where: Why: CMU SCS

CockroachDB on DC/OS. Ben Darnell, CTO, Cockroach Labs

Distributed Transaction Management 2003

Distributed systems. Lecture 6: distributed transactions, elections, consensus and replication. Malte Schwarzkopf

Transactions and ACID

Replication in Distributed Systems

Eventual Consistency Today: Limitations, Extensions and Beyond

Data Modeling and Databases Ch 14: Data Replication. Gustavo Alonso, Ce Zhang Systems Group Department of Computer Science ETH Zürich

Jargons, Concepts, Scope and Systems. Key Value Stores, Document Stores, Extensible Record Stores. Overview of different scalable relational systems

Introduction to NoSQL

Introduction to NoSQL Databases

Exam in Distributed Systems

Distributed Systems Principles and Paradigms. Chapter 07: Consistency & Replication

Lecture X: Transactions

Spanner: Google's Globally-Distributed Database. Presented by Maciej Swiech

Parallel and Distributed Systems. Programming Models. Why Parallel or Distributed Computing? What is a parallel computer?

Exam 2 Review. Fall 2011

Database Management System

Data Consistency Now and Then

Basic vs. Reliable Multicast

CSE 544 Principles of Database Management Systems. Alvin Cheung Fall 2015 Lecture 14 Distributed Transactions

The CAP theorem. The bad, the good and the ugly. Michael Pfeiffer Advanced Networking Technologies FG Telematik/Rechnernetze TU Ilmenau

Defining properties of transactions

Distributed Systems. Day 13: Distributed Transaction. To Be or Not to Be Distributed.. Transactions

Spanner: Google's Globally-Distributed Database* Huu-Phuc Vo August 03, 2013

Introduction to Distributed Systems Seif Haridi

DISTRIBUTED SYSTEMS Principles and Paradigms Second Edition ANDREW S. TANENBAUM MAARTEN VAN STEEN. Chapter 1. Introduction

High-Performance ACID via Modular Concurrency Control

Cassandra, MongoDB, and HBase. Cassandra, MongoDB, and HBase. I have chosen these three due to their recent

Transactions. 1. Transactions. Goals for this lecture. Today s Lecture

Fundamentals Large-Scale Distributed System Design. (a.k.a. Distributed Systems 1)

CS5412: TRANSACTIONS (I)

Lecture 12. Lecture 12: The IO Model & External Sorting

Distributed Systems. 19. Spanner. Paul Krzyzanowski. Rutgers University. Fall 2017

Apache Cassandra - A Decentralized Structured Storage System

Atomicity. Bailu Ding. Oct 18, Bailu Ding Atomicity Oct 18, / 38

CSE 344 MARCH 21 ST TRANSACTIONS

CSE 190D Database System Implementation

Distributed Data Store

Indirect Communication

SCALARIS. Irina Calciu Alex Gillmor

EECS 498 Introduction to Distributed Systems

DISTRIBUTED COMPUTER SYSTEMS

Lecture 21. Lecture 21: Concurrency & Locking

Database Management System Prof. D. Janakiram Department of Computer Science & Engineering Indian Institute of Technology, Madras Lecture No.

CS5412: ANATOMY OF A CLOUD

Mobile and Heterogeneous databases Distributed Database System Transaction Management. A.R. Hurson Computer Science Missouri Science & Technology

CS Amazon Dynamo

Transaction Management & Concurrency Control. CS 377: Database Systems

CS555: Distributed Systems [Fall 2017] Dept. Of Computer Science, Colorado State University

Distributed Systems. Fall 2017 Exam 3 Review. Paul Krzyzanowski. Rutgers University. Fall 2017

Important Lessons. A Distributed Algorithm (2) Today's Lecture - Replication

CSE 530A. Non-Relational Databases. Washington University Fall 2013

Data-Intensive Distributed Computing

CAP and the Architectural Consequences

NewSQL Databases. The reference Big Data stack

Transactions. CS 475, Spring 2018 Concurrent & Distributed Systems

CSE 344 MARCH 5 TH TRANSACTIONS

TRANSACTION MANAGEMENT

Distributed Systems. replication Johan Montelius ID2201. Distributed Systems ID2201

Exam in Distributed Systems

Scaling Without Sharding. Baron Schwartz Percona Inc Surge 2010

Dynamo: Amazon s Highly Available Key-value Store. ID2210-VT13 Slides by Tallat M. Shafaat

Consensus in Distributed Systems. Jeff Chase Duke University

Spanner : Google's Globally-Distributed Database. James Sedgwick and Kayhan Dursun

Database Usage (and Construction)

NoSQL systems: sharding, replication and consistency. Riccardo Torlone Università Roma Tre

Transcription:

Don t Give Up on Serializability Just Yet Neha Narula

Don t Give Up on Serializability Just Yet A journey into serializable systems Neha Narula MIT CSAIL GOTO Chicago May 2015 2

@neha PhD candidate at MIT Formerly at Google Research in fast transactions for multi-core databases and distributed systems 3

However, the most important person in my gang will be a systems programmer. A person who can debug a device driver or a distributed system is a person who can be trusted in a Hobbesian nightmare of breathtaking scope; a systems programmer has seen the terrors of the world and understood the intrinsic horror of existence. 4

A journey into serializable systems

6

1M messages/sec 1/5 of all page views in the US 1M messages/sec from mobile devices

Databases are difficult to scale Application servers are stateless; add more for more traffic Database is stateful 8

Distributed databases Partition data on multiple servers for more performance 9

Example partitioned database widgets table Database 0-99! widget_id! Webservers Database 100-199! Database?! Database 200-299!

2007 Mapreduce Google File System Bigtable 11

Pros/Cons In-memory HIGHLY scalable Transparently fault tolerant Geo replication No schema Require complex key/row/document design No query language No indexes No transactions No guarantees 12

13

14

mysql> BEGIN TRANSACTION UPDATE COMMIT 15

Problem with dropping transactions Difficult to reason about concurrent interleavings Might result in incorrect, unrecoverable state 16

The hacker discovered that multiple simultaneous withdrawals are processed essentially at the same time and that the system's software doesn't check quickly enough for a negative balance h1p://arstechnica.com/security/2014/03/yet- another- exchange- hacked- poloniex- loses- around- 50000- in- bitcoin/

Consistency guarantees help us reason about our code and avoid subtle bugs

Consistency A very misused word in systems! C as in ACID C as in CAP C as in sequential, causal, eventual, strict consistency

ACID Transactions Atomic Consistent Isolated Durable Whole thing happens or not Application-defined correctness Other transactions do not interfere Can recover correctly from a crash SET TRANSACTION ISOLATION LEVEL SERIALIZABLE BEGIN TRANSACTION... COMMIT 21

What is Serializability? Serializability!= Serial 22

What is Serializability? The result of executing a set of transactions is the same as if those transactions had executed one at a time, in some serial order. If each transaction preserves correctness, the DB will be in a correct state. We can pretend like there s no concurrency! 23

Database transactions should be serializable TXN1(k, j Key) (Value, Value) { a := GET(k) b := GET(j) return a, b } TXN2(k, j Key) { ADD(k,1) ADD(j,1) } k=0,j=0" To the programmer:" TXN1 TXN2 or" TXN2 TXN1 time Valid return values for TX1: (0,0)" or (1,1)" 24

Benefits of Serializability Do not have to reason about interleavings Do not have to express invariants separately from the code! 25

Serializability Costs On a multi-core database, serialization and cache line transfers On a distributed database, serialization and network calls Concurrency control: Locking and coordination 26

Eventual consistency If no new updates are made to the object, eventually all accesses will return the last updated value.

Eventual consistency If no new updates are made to the object, eventually all accesses will return the last updated value the same value. (What is last, really?) (And when do we stop writing?) (And what about multi-key transactions?)

Sequential consistency: cache coherence P1 P2 P3 RAM

P1: W(x)a P2: W(x)b P3: R(x)a R(x)b Lme P1: W(x)a P2: W(x)b P3: R(x)a R(x)b Lme

P1: W(x)a P2: W(x)b P3: R(x)b R(x)a Lme P1: W(x)a P2: W(x)b P3: R(x)b R(x)a Lme

External Consistency Everything that sequential consistency has Except results actually match time. An external observer

Not Externally Consistent The value of x is b! P1: W(x)a P2: W(x)b P3: R(x)b R(x)a Then I read x=a? Lme

CAP Theorem Brewer s PODC talk: Consistency, Availability, Partition-tolerance: choose two in 2000 Partition-tolerance is a failure model Choice: can you process reads and writes during a partition or not? FLP result Impossibility of Distributed Consensus with One Faulty Process in 1985 Asynchronous model; cannot tell the difference between message delay and failure

What does this mean? It s impossible to decide anything on the internet?

NP-hard

What does CAP mean? It s impossible to 100% of the time decide everything on the internet if we can t rely on synchronous messaging We can 100% of the time decide everything if partitions heal (we know the upper bound on message delays) We can still play Candy Crush

CAP" Consistency vs. Performance Consistency (like serializability) requires communication and blocking How do we reduce these costs while: Producing a correct ordering of reads and writes and Handling failures and (eventually) making progress?

Improving Serializability Performance Technique Atomic clocks to bound time skew Transaction chopping Commutative locking Systems Spanner Lynx, ROCOCO Escrow transactions, abstract data types, Doppel Deterministic ordering Granola, Calvin 39

Goal: parallel performance Different concurrency control schemes for popular, contended data Commutative locking Abstract datatypes Per-core (or per-server) data and constraints 40

Operation Model Developers write transactions as stored procedures which are composed of operations on keys and values: Traditional key/value operations Operations on numeric values which modify the existing value Ordered PUT, insert to an ordered list, user-defined functions value GET(k) void PUT(k,v) void INCR(k,n) void MAX(k,n) void MULT(k,n) void OPUT(k,v,o) void TOPK_INSERT(k,v,o) void UDF(k,v,a) Replicate for reads Save last write Replicate for commutative operations Log operations 41

Spanner/F1 We believe 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.

Takeaways Use well-tested, long-lived database systems Use SERIALIZABLE until it becomes a performance problem Think about what is changing when you move to systems with different models 43

Thanks!" narula@mit.edu http://nehanaru.la @neha The Stata Center via emax: h1p://hip.cat/emax/

Questions? Please remember to evaluate via the GOTO Guide App