CAP Twelve Years Later: How the Rules Have Changed Presenters: - - - PowerPoint PPT Presentation

▶
cap twelve years later
SMART_READER_LITE
LIVE PREVIEW

CAP Twelve Years Later: How the Rules Have Changed Presenters: - - - PowerPoint PPT Presentation

May 21, 2023 269 likes •535 views

CAP Twelve Years Later: How the Rules Have Changed Presenters: - Ayushi Bansal - Krithiga Murugavel Brewer, Eric. (2012). CAP Twelve years later: How the "Rules" have Changed. Computer. 45. 23-29. 10.1109/MC.2012.37. Outline

slide-1
SLIDE 1

CAP Twelve Years Later:

How the “Rules” Have Changed

Presenters:

  • Ayushi Bansal
  • Krithiga Murugavel

Brewer, Eric. (2012). CAP Twelve years later: How the "Rules" have Changed. Computer. 45. 23-29. 10.1109/MC.2012.37.

slide-2
SLIDE 2

Outline

  • CAP Theorem
  • ACID vs CAP
  • Why 2 of 3 misleading?
  • CAP confusion
  • Managing Partition
  • Partition Recovery
slide-3
SLIDE 3

CAP

Consistency

Every read receives the most recent write or an error.

Availability

A guarantee that every request receives a response.

Partition Tolerance

The system continues to

  • perate

despite an arbitrary number

  • f

messages being dropped (or delayed) by the network between nodes

slide-4
SLIDE 4

Writing to a Server

https://mwhittaker.github.io/blog/an_illustrated_proof_of_the_cap_theorem/

slide-5
SLIDE 5

Reading from a Server

slide-6
SLIDE 6

An Inconsistent System

1 4 3 2 5

slide-7
SLIDE 7

A Consistent System

1 2 5 4 3 6 7 8

slide-8
SLIDE 8

Partition

slide-9
SLIDE 9

CAP THEOREM

Any networked shared-data system can have at most two of three desirable properties.

https://www.easttexassoftware.com/post/cap-theorem-and-distributed-systems

slide-10
SLIDE 10

Choosing A over C

slide-11
SLIDE 11

Hence proved that we cannot have both Consistency, Availability and Partition Tolerance .

slide-12
SLIDE 12

ACID

Alice 150 Bob 50 Alice 150 Bob 50 100 Revert Transaction Alice 150 50 Bob 50 150 Alice 150 50 Bob 50 100 Mac 100 150 100 50

Atomicity Consistent Isolation

100

slide-13
SLIDE 13

ACID VS CAP

  • Consistency in CAP refers to Single copy consistency and Consistency in ACID means the

transaction preserves all the database rules

  • A stands for Atomicity in ACID and Availability in CAP.

Alice Bob 10 40 5 40 ACID CAP

Integrity constraint: A+B = 50

ACID Inconsistency A 5 5 A 5 10 CAP Inconsistency

slide-14
SLIDE 14

Why is 2 of 3 misleading?

  • Partition are Rare
  • Granularity in making choice between C and A based on:

❏ Applications ❏ Users Involved ❏ Data

  • All three properties are more continuous than binary
slide-15
SLIDE 15
  • Hidden cost of forfeiting consistency.
  • Can a designer choose not to have partitions?
  • When User cannot reach the service at all there is no choice

between C and A except when part of the service runs on the client.

CAP Confusion

slide-16
SLIDE 16

CAP-LATENCY CONNECTION

High Availability Data Replication Consistency vs Latency Yahoo PNUTS

  • Higher inconsistency
  • Low latency

A

A

A

A

B

B B

B

Facebook

  • Low inconsistency
  • High latency

Latency: The delay from input into the system to desired outcome

slide-17
SLIDE 17

PARTITION MODE

  • Detect Partition
  • Enter partition Mode, and decide between Consistency and Availability
  • Recover process to restore consistency and compensate for mistake
slide-18
SLIDE 18

THE PARTITION DECISION

After Entering Partition Mode Limit operations that leads to reduced availability Record Extra information on

  • perations and use

later for recovery

  • Decision made based on the invariants.
  • For invariants that needs to be maintained,

the system prohibits or modifies the

  • peration. Eg: Credit Card transaction.
  • Suggests to build a Crosstable of
  • perations and invariants.
slide-19
SLIDE 19

Two goals

  • State on both sides must become consistent
  • Handle the mistakes done during partition mode

○ Undo the mistakes ○ Compensate for mistakes

Partition Recovery

slide-20
SLIDE 20

Version Vectors

  • Best way to track history on both sides of partitions.
  • Captures causal dependencies among operations

Vector A Vector B Vector A Vector B

(1,12) (2,14) (3,16) (1,12) (2,14) (3,15) Vector A is newer than Vector B (1,12) (2,14) (3,15) (1,12) (2,14) (3,15) Cannot determine order, updates concurrent , possibly inconsistent

slide-21
SLIDE 21

Partition Recovery

  • Concurrent Version System (CVS) - uses version vector
  • Merge conflicts

○ Manual merging - offline wiki system ○ Automatic merging - Google Docs

  • Commutative Replicated Data types (CRDTs)

○ Merge concurrent modifications, always, in any order. ○ Rearrange operations into a preferred consistent global order

slide-22
SLIDE 22

Partition Recovery - AMAZON Carts

2 3 1 2 3 1 1 4 5 3 2 3 4 1 2 5 Before Partition During Partition After Partition Recovery 3,2 1 4 5

slide-23
SLIDE 23

Compensation in an ATM

  • Key invariant: Balance should be zero or

higher

  • Essential operations: Deposit, Withdraw

(violate invariant) and Check balance

  • Availability preferred over Consistency

○ Withdraw limit - bounds risk ○ Compensation - Extra fee and repayment of money

  • Check Kiting
slide-24
SLIDE 24

$1000 $0 $-4000 $5000 $-4000 $2000 $1000 $-3000

Check Kiting

Check of $5000 Withdraw $3000 Check of $5000 Repeat cycle

slide-25
SLIDE 25
slide-26
SLIDE 26

THANK YOU !!