Consistency Tradeoffs in Modern

Distributed Database System Design Article by Daniel J. Abadi, Yale University

Presentation by Arinto Murdopo

Outline

• CAP Theorem

• What’s wrong with CAP?

• Consistency/Latency Tradeoff

• Type of Replication

• PACELC

• DDBS in PACELC metrics

• Conclusion

CAP theorem

Consistency Availability

Partition Tolerance

CP

CA

AP

What’s wrong with CAP?

Consistency Availability

Partition Tolerance

CP

CA

AP

Reduced Consistency, let’s justify it!

(?)Tolerant to network partition

High availability Sacrifice consistency

What’s wrong with CAP?

The P in CAP is combination of: • Partition tolerance ~ commonly used as justification

• Existence of a network partition itself ~ often forgotten

Consistency/Latency Tradeoff

Modern Database Design • Dynamo ~ Amazon • Cassandra ~ Facebook • Voldemort ~ LinkedIn • PNUTS ~ Yahoo

Availability & Latency are critical!

High Availability -> Replication is needed

Replication is used -> Consistency/Latency Tradeoff occurs

Type of Replication

1. Data updates sent to all replicas at same time

a. Without preprocessing layer ~ latency

b. With preprocessing layer ~ consistency

2. Data updates sent to agreed-upon location first

a. Synchronous ~ consistency

b. Asynchronous ~ latency. Used by PNUTS.

c. Combination ~ configurable

Type of Replication

3. Data updates sent to an arbitrary location

• Location for data item is not always same

a. Synchronous ~ consistency

b. Asynchronous ~ latency

• Used by Dynamo, Cassandra, and Riak -> combined with 2c

PACELC

P ~ when there is partitioning • Trade off between AC E ~ else (which is no partitioning) • Trade off between LC

DDBS in PACELC metrics

DBSS A C L C

Dynamo v v

Cassandra v v

Riak v v

VoltDB/H-Store v v

Megastore v v

MongoDB v v

PNUTS v v

Dynamo, Cassandra and Riak have user-adjustable settings in LC tradeoff!

Conclusion

• CAP is still important

• Exploring new metrics is good

• PACELC metrics are worth to consider