Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Papers We Love: Managing Update Conflicts in Bayou

pbailis
December 17, 2014

Papers We Love: Managing Update Conflicts in Bayou

pbailis

December 17, 2014
Tweet

More Decks by pbailis

Other Decks in Technology

Transcript

  1. Papers We Love SF:
    Bayou
    Peter Bailis @pbailis
    UC Berkeley
    17 December 2014

    View full-size slide

  2. Who am I?
    Ph.D. candidate, 4th year student at Berkeley
    Study high performance distributed databases
    » When do we need coordination?
    » What happens if we don’t coordinate?
    Graduating 2015!
    http://bailis.org/

    View full-size slide

  3. Why Bayou?
    “NoSQL” before “NoSQL”
    Learn from our predecessors
    Rethink application, system boundaries
    Lucid discussion of systems challenges

    View full-size slide

  4. Talk Outline
    Background and system architecture
    Conflict detection and resolution APIs
    “Correctness” and ordering
    Lessons for all of us

    View full-size slide

  5. Talk Outline
    Background and system architecture
    Conflict detection and resolution APIs
    “Correctness” and ordering
    Lessons for all of us

    View full-size slide

  6. Bayou Goals
    Storage system for mobile devices:

    View full-size slide

  7. Bayou Goals
    Storage system for mobile devices:
    Handle frequent disconnections

    View full-size slide

  8. Bayou Goals
    Storage system for mobile devices:
    Handle frequent disconnections

    View full-size slide

  9. Bayou Goals
    Storage system for mobile devices:
    Handle frequent disconnections
    Reason about distribution explicitly

    View full-size slide

  10. Bayou Goals
    Storage system for mobile devices:
    Handle frequent disconnections
    Reason about distribution explicitly

    View full-size slide

  11. Bayou Goals
    Storage system for mobile devices:
    Handle frequent disconnections
    Reason about distribution explicitly
    Facilitate conflict detection and resolution

    View full-size slide

  12. How do we build a system
    that allows update-
    anywhere but allows users
    to easily build correct
    applications?

    View full-size slide

  13. Basic Architecture

    View full-size slide

  14. Basic Architecture
    Optimistically replicated
    distributed database

    View full-size slide

  15. Basic Architecture
    Optimistically replicated
    distributed database
    Update-anywhere; CAP “AP”
    » Guarantees availability
    » Low latency and scalability!
    Use anti-entropy to exchange
    updates
    » Pick your favorite

    View full-size slide

  16. Talk Outline
    Background and system architecture
    Conflict detection and resolution APIs
    “Correctness” and ordering
    Lessons for all of us

    View full-size slide

  17. Talk Outline
    Background and system architecture
    Conflict detection and resolution APIs
    “Correctness” and ordering
    Lessons for all of us

    View full-size slide

  18. Main problem: “conflicts”
    What happens if two clients simultaneously update the
    same piece of data?

    View full-size slide

  19. Example:
    Peter wants to book Fastly HQ on 12/17 at 7PM
    Ines wants to book Fastly HQ on 12/17 at 7PM

    View full-size slide

  20. Example:
    Peter wants to book Fastly HQ on 12/17 at 7PM
    Ines wants to book Fastly HQ on 12/17 at 7PM
    Peter and Ines are connected to different servers

    View full-size slide

  21. Example:
    Peter wants to book Fastly HQ on 12/17 at 7PM
    Ines wants to book Fastly HQ on 12/17 at 7PM
    Peter and Ines are connected to different servers
    What will happen?

    View full-size slide

  22. Example:
    Peter wants to book Fastly HQ on 12/17 at 7PM
    Ines wants to book Fastly HQ on 12/17 at 7PM
    Peter and Ines are connected to different servers
    What will happen?
    Example:

    View full-size slide

  23. Example:
    Peter wants to book Fastly HQ on 12/17 at 7PM
    Ines wants to book Fastly HQ on 12/17 at 7PM
    Peter and Ines are connected to different servers
    What will happen?
    Example:
    Mike wants to give Peter $100
    Carol wants to give Peter $100

    View full-size slide

  24. Example:
    Peter wants to book Fastly HQ on 12/17 at 7PM
    Ines wants to book Fastly HQ on 12/17 at 7PM
    Peter and Ines are connected to different servers
    What will happen?
    Example:
    Mike wants to give Peter $100
    Carol wants to give Peter $100
    Mike and Carol are connected to different servers

    View full-size slide

  25. Example:
    Peter wants to book Fastly HQ on 12/17 at 7PM
    Ines wants to book Fastly HQ on 12/17 at 7PM
    Peter and Ines are connected to different servers
    What will happen?
    Example:
    Mike wants to give Peter $100
    Carol wants to give Peter $100
    Mike and Carol are connected to different servers
    What will happen?

    View full-size slide

  26. Main problem: “conflicts”
    What happens if two clients simultaneously update the
    same piece of data?

    View full-size slide

  27. Main problem: “conflicts”
    It depends on the application!
    What happens if two clients simultaneously update the
    same piece of data?

    View full-size slide

  28. Main problem: “conflicts”
    It depends on the application!
    Traditional DB (“serializability”): always* matters!
    What happens if two clients simultaneously update the
    same piece of data?

    View full-size slide

  29. Main problem: “conflicts”
    It depends on the application!
    Traditional DB (“serializability”): always* matters!
    Bayou: let the application help us out!
    What happens if two clients simultaneously update the
    same piece of data?

    View full-size slide

  30. Main problem: “conflicts”
    Bayou writes have three components:

    View full-size slide

  31. Main problem: “conflicts”
    Bayou writes have three components:
    » An update function: the actual write

    View full-size slide

  32. Main problem: “conflicts”
    Bayou writes have three components:
    » An update function: the actual write
    » A dependency check: conflict detection

    View full-size slide

  33. Main problem: “conflicts”
    Bayou writes have three components:
    » An update function: the actual write
    » A dependency check: conflict detection
    » A merge function: conflict compensation

    View full-size slide

  34. Main problem: “conflicts”
    Bayou writes have three components:
    » An update function: the actual write
    » A dependency check: conflict detection
    » A merge function: conflict compensation
    If dependency check passes:
    apply update function
    Else:
    apply merge function

    View full-size slide

  35. Example:
    Booking tonight’s meetup:

    View full-size slide

  36. Example:
    Booking tonight’s meetup:
    » Update function: insert 12/17/14, “Fastly HQ”, Ines

    View full-size slide

  37. Example:
    Booking tonight’s meetup:
    » Update function: insert 12/17/14, “Fastly HQ”, Ines
    » Dependency check: Is the requested time and location
    available?

    View full-size slide

  38. Example:
    Booking tonight’s meetup:
    » Update function: insert 12/17/14, “Fastly HQ”, Ines
    » Dependency check: Is the requested time and location
    available?
    » Merge function: try to find another time based on
    provided alternates

    View full-size slide

  39. Inside the server:
    Date Location User Time
    12/16 Fastly HQ Fred 2:30-5PM
    12/18 Fastly HQ Artur 10AM-12PM
    12/17 FastlyHQ Inez 6:30-9PM

    View full-size slide

  40. Inside the server:
    Date Location User Time
    12/16 Fastly HQ Fred 2:30-5PM
    12/18 Fastly HQ Artur 10AM-12PM
    12/17 FastlyHQ Inez 6:30-9PM

    View full-size slide

  41. Inside the server:
    Date Location User Time
    12/16 Fastly HQ Fred 2:30-5PM
    12/18 Fastly HQ Artur 10AM-12PM
    12/17 FastlyHQ Inez 6:30-9PM
    Update function: insert 12/17/14, “Fastly HQ”, Ines

    View full-size slide

  42. Inside the server:
    Date Location User Time
    12/16 Fastly HQ Fred 2:30-5PM
    12/18 Fastly HQ Artur 10AM-12PM
    12/17 FastlyHQ Inez 6:30-9PM
    Update function: insert 12/17/14, “Fastly HQ”, Ines
    Dependency check: Is the requested time and location
    available?

    View full-size slide

  43. Inside the server:
    Date Location User Time
    12/16 Fastly HQ Fred 2:30-5PM
    12/18 Fastly HQ Artur 10AM-12PM
    12/17 FastlyHQ Inez 6:30-9PM
    Update function: insert 12/17/14, “Fastly HQ”, Ines
    Dependency check: Is the requested time and location
    available?

    View full-size slide

  44. Another example:
    Money transfer:

    View full-size slide

  45. Another example:
    Money transfer:
    » Update function: transfer $100 from Jan to Mary

    View full-size slide

  46. Another example:
    Money transfer:
    » Update function: transfer $100 from Jan to Mary
    » Dependency check: does Jan have $100 in her account?

    View full-size slide

  47. Another example:
    Money transfer:
    » Update function: transfer $100 from Jan to Mary
    » Dependency check: does Jan have $100 in her account?
    » Merge function: log an error

    View full-size slide

  48. User Balance
    Jan $110
    Marsha $10
    Peter $42
    » Update function: transfer $100 from Jan to Marsha
    » Dependency check: does Jan have $100 in her account?
    » Merge function: log an error
    Errors

    View full-size slide

  49. » Update function: transfer $100 from Jan to Marsha
    » Dependency check: does Jan have $100 in her account?
    » Merge function: log an error
    » Update function: transfer $100 from Jan to Peter
    » Dependency check: does Jan have $100 in her account?
    » Merge function: log an error
    User Balance
    Jan $10
    Marsha $110
    Peter $42
    Errors

    View full-size slide

  50. » Update function: transfer $100 from Jan to Marsha
    » Dependency check: does Jan have $100 in her account?
    » Merge function: log an error
    » Update function: transfer $100 from Jan to Peter
    » Dependency check: does Jan have $100 in her account?
    » Merge function: log an error
    Errors
    Jan->Peter failed!
    User Balance
    Jan $10
    Marsha $110
    Peter $42

    View full-size slide

  51. Write stability
    How do we ensure that all servers eventually agree?

    View full-size slide

  52. Write stability
    How do we ensure that all servers eventually agree?
    Decide on a “stable” prefix of writes:

    View full-size slide

  53. Write stability
    How do we ensure that all servers eventually agree?
    Decide on a “stable” prefix of writes:
    » Strawman: order writes by timestamp

    View full-size slide

  54. Write stability
    How do we ensure that all servers eventually agree?
    Decide on a “stable” prefix of writes:
    » Strawman: order writes by timestamp
    • Drawbacks?

    View full-size slide

  55. » Update function: transfer $100 from Jan to Marsha
    » Dependency check: does Jan have $100 in her account?
    » Merge function: log an error
    User Balance
    Jan $10
    Marsha $110
    Peter $42
    Errors
    Timestamp 10

    View full-size slide

  56. » Update function: transfer $100 from Jan to Marsha
    » Dependency check: does Jan have $100 in her account?
    » Merge function: log an error
    » Update function: transfer $100 from Jan to Peter
    » Dependency check: does Jan have $100 in her account?
    » Merge function: log an error
    User Balance
    Jan $10
    Marsha $110
    Peter $42
    Errors
    Timestamp 10

    View full-size slide

  57. » Update function: transfer $100 from Jan to Marsha
    » Dependency check: does Jan have $100 in her account?
    » Merge function: log an error
    » Update function: transfer $100 from Jan to Peter
    » Dependency check: does Jan have $100 in her account?
    » Merge function: log an error
    User Balance
    Jan $10
    Marsha $110
    Peter $42
    Errors
    Timestamp 10
    Timestamp 2

    View full-size slide

  58. User Balance
    Jan $110
    Marsha $10
    Peter $42
    Errors

    View full-size slide

  59. User Balance
    Jan $110
    Marsha $10
    Peter $42
    Errors
    » Update function: transfer $100 from Jan to Peter
    » Dependency check: does Jan have $100 in her account?
    » Merge function: log an error
    Timestamp 2

    View full-size slide

  60. User Balance
    Jan $10
    Marsha $10
    Peter $142
    » Update function: transfer $100 from Jan to Peter
    » Dependency check: does Jan have $100 in her account?
    » Merge function: log an error
    Timestamp 2
    Errors
    Jan->Marsha failed!

    View full-size slide

  61. User Balance
    Jan $10
    Marsha $10
    Peter $142
    » Update function: transfer $100 from Jan to Peter
    » Dependency check: does Jan have $100 in her account?
    » Merge function: log an error
    Timestamp 2
    » Update function: transfer $100 from Jan to Marsha
    » Dependency check: does Jan have $100 in her account?
    » Merge function: log an error
    Timestamp 10
    Errors
    Jan->Marsha failed!

    View full-size slide

  62. 11 22 28 34
    13

    View full-size slide

  63. 11 22 28 34
    13

    View full-size slide

  64. 11 22 28 34
    13

    View full-size slide

  65. 11 22 28 34
    13
    NEED TO RE-EXECUTE!

    View full-size slide

  66. 11 22 28 34
    13
    NEED TO RE-EXECUTE!
    Also, makes GC hard

    View full-size slide

  67. Write stability
    How do we ensure that all servers eventually agree?
    Decide on a “stable” prefix of writes:
    » Strawman: order writes by timestamp
    » Bayou: uses master to determine ordering

    View full-size slide

  68. MASTER
    TENTATIVE COMMITTED
    T C
    T C T C

    View full-size slide

  69. MASTER
    TENTATIVE COMMITTED
    T C
    T C T C

    View full-size slide

  70. MASTER
    TENTATIVE COMMITTED
    T C
    T C T C

    View full-size slide

  71. MASTER
    TENTATIVE COMMITTED
    T C
    T C T C

    View full-size slide

  72. MASTER
    TENTATIVE COMMITTED
    T C
    T C T C

    View full-size slide

  73. MASTER
    TENTATIVE COMMITTED
    T C
    T C T C

    View full-size slide

  74. MASTER
    TENTATIVE COMMITTED
    T C
    T C T C

    View full-size slide

  75. MASTER
    TENTATIVE COMMITTED
    T C
    T C T C

    View full-size slide

  76. MASTER
    TENTATIVE COMMITTED
    T C
    T C T C

    View full-size slide

  77. MASTER
    TENTATIVE COMMITTED
    T C
    T C T C

    View full-size slide

  78. MASTER
    TENTATIVE COMMITTED
    T C
    T C T C

    View full-size slide

  79. MASTER
    TENTATIVE COMMITTED
    T C
    T C T C

    View full-size slide

  80. MASTER
    TENTATIVE COMMITTED
    T C
    T C T C

    View full-size slide

  81. Write stability
    How do we ensure that all servers eventually agree?
    Decide on a “stable” prefix of writes:
    » Strawman: order writes by timestamp
    • Drawbacks?
    » Bayou: uses master to determine ordering
    • Benefits?
    Note: don’t require commutative updates!

    View full-size slide

  82. Read API
    Can read from:
    » Stable storage: only committed writes
    » Tentative storage: all writes seen so far

    View full-size slide

  83. Read API
    Can read from:
    » Stable storage: only committed writes
    » Tentative storage: all writes seen so far
    Why read from tentative storage at all?

    View full-size slide

  84. Talk Outline
    Background and system architecture
    Conflict detection and resolution APIs
    “Correctness” and ordering
    Lessons for all of us

    View full-size slide

  85. Talk Outline
    Background and system architecture
    Conflict detection and resolution APIs
    “Correctness” and ordering
    Lessons for all of us

    View full-size slide

  86. Bayou’s Secret Sauce
    Push app logic into updates:

    View full-size slide

  87. Bayou’s Secret Sauce
    Push app logic into updates:
    » Read and write are insufficiently expressive!

    View full-size slide

  88. » Update function: transfer $100 from Jan to Peter
    » Dependency check: does Jan have $100 in her account?
    » Merge function: log an error
    » Update function: transfer $100 from Jan to Mary
    » Dependency check: does Jan have $100 in her account?
    » Merge function: log an error

    View full-size slide

  89. » Update function: transfer $100 from Jan to Peter
    » Dependency check: does Jan have $100 in her account?
    » Merge function: log an error
    » Update function: transfer $100 from Jan to Mary
    » Dependency check: does Jan have $100 in her account?
    » Merge function: log an error
    WRITE: Jan = 10; Peter = 42
    WRITE: Jan = 10; Mary = 110

    View full-size slide

  90. » Update function: transfer $100 from Jan to Peter
    » Dependency check: does Jan have $100 in her account?
    » Merge function: log an error
    » Update function: transfer $100 from Jan to Mary
    » Dependency check: does Jan have $100 in her account?
    » Merge function: log an error
    WRITE: Jan = 10; Peter = 42
    WRITE: Jan = 10; Mary = 110
    » decrement Jan by $100; increment Peter by 100
    » decrement Jan by $100; increment Mary by 100

    View full-size slide

  91. Bayou’s Secret Sauce
    Push app logic into updates:
    » Read and write are insufficiently expressive!

    View full-size slide

  92. Bayou’s Secret Sauce
    Push app logic into updates:
    » Read and write are insufficiently expressive!
    Capture transaction intent:

    View full-size slide

  93. Bayou’s Secret Sauce
    Push app logic into updates:
    » Read and write are insufficiently expressive!
    Capture transaction intent:
    » Dependency checks encode preconditions
    » e.g., guarded atomic actions

    View full-size slide

  94. What does Bayou guarantee?
    Eventually all updates are applied in the same
    order on all servers

    View full-size slide

  95. What does Bayou guarantee?
    Eventually all updates are applied in the same
    order on all servers
    » Kind of like serializable/ACID transactions!

    View full-size slide

  96. What does Bayou guarantee?
    Eventually all updates are applied in the same
    order on all servers
    » Kind of like serializable/ACID transactions!
    » Dependency checks enforce invariants

    View full-size slide

  97. What does Bayou guarantee?
    Eventually all updates are applied in the same
    order on all servers
    » Kind of like serializable/ACID transactions!
    » Dependency checks enforce invariants
    » Did we just “beat CAP”?

    View full-size slide

  98. What does Bayou guarantee?
    Eventually all updates are applied in the same
    order on all servers
    » Kind of like serializable/ACID transactions!
    » Dependency checks enforce invariants
    » Did we just “beat CAP”?
    Key: eventually means we have to wait

    View full-size slide

  99. H-Store, VoltDB, Granola,
    Calvin, Atomic Broadcast
    Idea sketch: pre-schedule transactions, then
    execute them sequentially on respective servers

    View full-size slide

  100. H-Store, VoltDB, Granola,
    Calvin, Atomic Broadcast
    Idea sketch: pre-schedule transactions, then
    execute them sequentially on respective servers
    Totally ordered outcomes on each replica

    View full-size slide

  101. H-Store, VoltDB, Granola,
    Calvin, Atomic Broadcast
    Idea sketch: pre-schedule transactions, then
    execute them sequentially on respective servers
    Totally ordered outcomes on each replica
    …but ordering determined up front!

    View full-size slide

  102. Bayou 㱺 “ACID”

    View full-size slide

  103. Bayou 㱺 “ACID”
    1.) Given transaction T, issue write W:

    View full-size slide

  104. Bayou 㱺 “ACID”
    1.) Given transaction T, issue write W:
    » Update function: // do nothing

    View full-size slide

  105. Bayou 㱺 “ACID”
    1.) Given transaction T, issue write W:
    » Update function: // do nothing
    » Dependency check: false

    View full-size slide

  106. Bayou 㱺 “ACID”
    1.) Given transaction T, issue write W:
    » Update function: // do nothing
    » Dependency check: false
    » Merge function: execute T

    View full-size slide

  107. Bayou 㱺 “ACID”
    1.) Given transaction T, issue write W:
    » Update function: // do nothing
    » Dependency check: false
    » Merge function: execute T
    2.) Wait for write W to commit.

    View full-size slide

  108. Bayou 㱺 “ACID”
    1.) Given transaction T, issue write W:
    » Update function: // do nothing
    » Dependency check: false
    » Merge function: execute T
    2.) Wait for write W to commit.
    3.) Notify success.

    View full-size slide

  109. What does Bayou guarantee?
    Eventually all writes are applied in the same order
    on all servers
    » Kind of like serializable/ACID transactions!
    » Dependency checks enforce invariants
    » Did we just “beat CAP”?
    Key: eventually means we have to wait

    View full-size slide

  110. “#is meeting room scheduling program is
    intended for use after a group of people have
    already decided that they want to meet in a
    certain room and have determined a set of
    acceptable times for the meeting. It does not
    help them to determine a mutually agreeable
    place and time for the meeting, it only allows
    them to reserve the room.”

    View full-size slide

  111. “#is meeting room scheduling program is
    intended for use after a group of people have
    already decided that they want to meet in a
    certain room and have determined a set of
    acceptable times for the meeting. It does not
    help them to determine a mutually agreeable
    place and time for the meeting, it only allows
    them to reserve the room.”

    View full-size slide

  112. “#is meeting room scheduling program is
    intended for use after a group of people have
    already decided that they want to meet in a
    certain room and have determined a set of
    acceptable times for the meeting. It does not
    help them to determine a mutually agreeable
    place and time for the meeting, it only allows
    them to reserve the room.”

    View full-size slide

  113. When can we avoid “waiting”?

    View full-size slide

  114. When can we avoid “waiting”?
    Commutative logic need not be re-executed in the
    log! (Paper discusses this.)

    View full-size slide

  115. A note on commutativity
    Commutative logic: decisions made in application
    logic are insensitive to ordering

    View full-size slide

  116. A note on commutativity
    Commutative logic: decisions made in application
    logic are insensitive to ordering
    Commutative datatypes: operations on datatypes are
    insensitive to ordering
    #e latter are useful, but won’t ensure correctness!
    http://www.bailis.org/blog/data-integrity-and-problems-of-scope/

    View full-size slide

  117. » Update function: transfer $100 from Jan to Peter
    » Dependency check: does Jan have $100 in her account?
    » Merge function: log an error
    » Update function: transfer $100 from Jan to Marsha
    » Dependency check: does Jan have $100 in her account?
    » Merge function: log an error
    » decrement Jan by $100; increment Peter by 100
    » decrement Jan by $100; increment Marsha by 100
    WRITE: Jan = 10; Peter = 42
    WRITE: Jan = 10; Marsha = 110

    View full-size slide

  118. A note on commutativity
    Commutative logic: decisions made in application
    logic are insensitive to ordering
    Commutative datatypes: operations on datatypes are
    insensitive to ordering
    #e latter are useful, but won’t ensure correctness!
    http://www.bailis.org/blog/data-integrity-and-problems-of-scope/

    View full-size slide

  119. When can we avoid “waiting”?
    Commutative logic need not be re-executed in the
    log! (Paper discusses this.)

    View full-size slide

  120. When can we avoid “waiting”?
    CALM !eorem: monotonic logic <=> determinism
    despite different orders [CIDR 2011] See also Kuper’s LVars
    Commutative logic need not be re-executed in the
    log! (Paper discusses this.)

    View full-size slide

  121. When can we avoid “waiting”?
    CALM !eorem: monotonic logic <=> determinism
    despite different orders [CIDR 2011] See also Kuper’s LVars
    I-confluence: guarantees “safe” tentative reads with
    convergent and safe outcomes [VLDB 2015]
    Commutative logic need not be re-executed in the
    log! (Paper discusses this.)

    View full-size slide

  122. A note on immutability

    View full-size slide

  123. A note on immutability
    Bayou’s stable log is “immutable”
    » e.g., event sourcing, Lambda architecture

    View full-size slide

  124. A note on immutability
    Bayou’s stable log is “immutable”
    » e.g., event sourcing, Lambda architecture
    But what guarantees can we make about the
    outcomes in the log?

    View full-size slide

  125. A note on immutability
    Bayou’s stable log is “immutable”
    » e.g., event sourcing, Lambda architecture
    But what guarantees can we make about the
    outcomes in the log?
    » “Immutable” writes are the easy part!
    » Reasoning about outcomes is the challenge

    View full-size slide

  126. Why have “merge” at all?

    View full-size slide

  127. Why have “merge” at all?
    Why not just ship the stored procedures and
    re-execute them instead?

    View full-size slide

  128. Why have “merge” at all?
    Why not just ship the stored procedures and
    re-execute them instead?
    » Update function: transfer $100 from Jan to Peter
    » Dependency check: does Jan have $100 in her account?
    » Merge function: log an error

    View full-size slide

  129. Why have “merge” at all?
    Why not just ship the stored procedures and
    re-execute them instead?
    » Update function: transfer $100 from Jan to Peter
    » Dependency check: does Jan have $100 in her account?
    » Merge function: log an error
    If Jan has $100:
    transfer $100 from Jan to Peter
    Else:
    Log an error

    View full-size slide

  130. ELE Edelweiss

    View full-size slide

  131. Durability?
    In this context, durability and consistency are
    effectively orthogonal
    » Durability: “survive F faults, need F+1 servers”
    » Strong consistency: usually requires “majority”

    View full-size slide

  132. Durability?
    In this context, durability and consistency are
    effectively orthogonal
    » Durability: “survive F faults, need F+1 servers”
    » Strong consistency: usually requires “majority”
    Bayou: local updates may not survive faults
    » But the (arguably) more fundamental part of the
    system is maintaining updates

    View full-size slide

  133. Bayou vs. Dynamo
    Fully replicated
    Update-one
    In-order per-server
    sequenced anti-entropy
    Server-side merge
    Global stability
    detection
    No “strong” consistency
    Partially replicated
    Update-N
    Merkle tree-based anti-
    entropy
    Client-side merge
    No notion of, API for
    stability
    Regular registers via
    majority quorum

    View full-size slide

  134. Talk Outline
    Background and system architecture
    Conflict detection and resolution APIs
    “Correctness” and ordering
    Lessons for all of us

    View full-size slide

  135. Talk Outline
    Background and system architecture
    Conflict detection and resolution APIs
    “Correctness” and ordering
    Lessons for all of us

    View full-size slide

  136. Why Bayou?
    “NoSQL” before “NoSQL”
    Learn from smart predecessors
    Rethink application, system boundaries
    Lucid discussion of systems challenges

    View full-size slide

  137. Bayou Goals
    Handle frequent disconnections
    » Embrace replication, update-anywhere

    View full-size slide

  138. Bayou Goals
    Handle frequent disconnections
    » Embrace replication, update-anywhere
    Reason about distribution explicitly
    » Require application semantics

    View full-size slide

  139. Bayou Goals
    Handle frequent disconnections
    » Embrace replication, update-anywhere
    Reason about distribution explicitly
    » Require application semantics
    Facilitate conflict detection and resolution
    » Use merge and dependency APIs

    View full-size slide

  140. “Weakly consistent replication
    has been used previously for
    availability, simplicity, and
    scalability in a variety of systems
    [3, 7, 10, 12, 15, 19].”

    View full-size slide

  141. “Weakly consistent replication
    has been used previously for
    availability, simplicity, and
    scalability in a variety of systems
    [3, 7, 10, 12, 15, 19].”

    View full-size slide

  142. Simplicity for whom?

    View full-size slide

  143. Simplicity for whom?
    Architects
    Systems programmers
    Operators

    View full-size slide

  144. Simplicity for whom?
    Architects
    Systems programmers
    Operators
    Application writers?
    Users?

    View full-size slide

  145. Simplicity for whom?
    Architects
    Systems programmers
    Operators
    Application writers?
    Users?
    Analogous issues in RDBMS design!
    http://www.bailis.org/blog/understanding-weak-
    isolation-is-a-serious-problem/

    View full-size slide

  146. Unfortunately, not always a choice!

    View full-size slide

  147. THOSE LIGHT CONES_

    View full-size slide

  148. 2.6 Billion Internet users in 2013
    7.1 Billion humans on planet Earth
    Who cares about scale? Coordination?
    [Mary Meeker]

    View full-size slide

  149. 2.6 Billion Internet users in 2013
    7.1 Billion humans on planet Earth
    Who cares about scale? Coordination?
    Will data keep increasing? Why?
    Hint: not humans.
    [Mary Meeker]

    View full-size slide

  150. Xerox PARC
    Laser printers
    Computer-generated bitmap graphics
    #e Graphical user interface, featuring windows and icons, operated
    with a mouse
    #e WYSIWYG text editor
    #e precursor to PostScript
    Ethernet as a local-area computer network
    Fully formed object-oriented programming in the Smalltalk
    programming language and integrated development environment.
    Model–view–controller software architecture
    Bayou!
    [Wikipedia]

    View full-size slide

  151. Xerox PARC
    DEC SRC
    MSR SVC
    ???

    View full-size slide

  152. What can we learn?
    1.) Integrating application logic is key to “correct”
    execution of “AP” distributed systems. R/W is bad.
    2.) Lack of app-specific mechanisms in a coordination-
    free system is a recipe for data corruption.
    3.) Merge/repair is a narrow API for developers to
    express their application conflicts.
    4.) Alternatives like commutativity, I-confluence, and
    research tools like Bloom can help limit overhead.

    View full-size slide

  153. !anks Fastly & Ines!

    View full-size slide