1 / 54

Logic and Lattices for Distributed Programming Neil Conway UC Berkeley

Logic and Lattices for Distributed Programming Neil Conway UC Berkeley Joint work with: Peter Alvaro, Peter Bailis , David Maier, Bill Marczak, Joe Hellerstein, Sriram Srinivasan Basho Chats #004 June 27, 2012. Programming. Distributed Programming. Dealing with Disorder. Introduce order

dana
Télécharger la présentation

Logic and Lattices for Distributed Programming Neil Conway UC Berkeley

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Logic and Lattices for Distributed Programming Neil ConwayUC Berkeley Joint work with:Peter Alvaro, Peter Bailis,David Maier, Bill Marczak,Joe Hellerstein, SriramSrinivasan Basho Chats #004June 27, 2012

  2. Programming

  3. Distributed Programming

  4. Dealing with Disorder Introduce order • Paxos, Zookeeper, Two-Phase Commit, … • “Strong Consistency” Tolerate disorder • Correct behavior in the face of many possible network orders • Typical goal: replicas converge to same final state • “Eventual Consistency”

  5. Eventual Consistency Popular Hard toprogram

  6. Help developers buildreliable programs on top ofeventual consistency

  7. This Talk • Theory • CRDTs, Lattices, and CALM • Practice • Programming with Lattices • Case Study: KVS

  8. Write: {Alice, Bob, Carol} Read: {Alice, Bob} Students{Alice, Bob, Carol} Students{Alice, Bob} Client0 How to resolve? Write: {Alice, Bob, Dave} Read: {Alice, Bob} Students{Alice, Bob, Dave} Students{Alice, Bob} Client1

  9. Students{Alice, Bob, Carol, Dave} Client0 Merge = Set Union Students{Alice, Bob, Carol, Dave} Client1

  10. Commutative Operations • Used by Dynamo, Riak, Bayou, etc. • Formalized as CRDTs: Convergent and Commutative Replicated Data Types • Shapiro et al., INRIA (2009-2012) • Based on join semilattices • Commutative, associative, idempotent • Practical libraries: Statebox, Knockbox

  11. Time “Growth”: Larger Sets “Growth”: Larger Numbers “Growth”: false  true Set (Union) Integer(Max) Boolean(Or)

  12. Students{Alice, Bob, Carol} Students{Alice, Bob, Carol, Dave} Read: {Alice, Bob, Carol, Dave} Client0 Teams{<Alice, Bob>} Teams{<Alice, Bob>,<Carol, Dave>} Teams{<Alice, Bob>,<Carol, Dave>} Read: {<Alice,Bob>} Write: {<Alice,Bob>, <Carol,Dave>} Replica Synchronization Students{Alice, Bob, Carol} Students{Alice, Bob, Carol, Dave} Remove: {Dave} Client1 Teams{<Alice, Bob>,<Carol, Dave>} Teams{<Alice, Bob>} Teams{<Alice, Bob>,<Carol, Dave>}

  13. Students{Alice, Bob, Carol, Dave} Students{Alice, Bob, Carol} Read: {Alice, Bob, Carol} Client0 Teams{<Alice, Bob>} Teams{<Alice, Bob>} Read: {<Alice,Bob>} Replica Synchronization Nondeterministic Outcome! Students{Alice, Bob, Carol} Students{Alice, Bob, Carol, Dave} Remove: {Dave} Client1 Teams{<Alice, Bob>} Teams{<Alice, Bob>}

  14. Possible Solution:Wrap both replicated valuesina single complex CRDT

  15. Goal:Compose larger applicationusing “safe” mappingsbetween simple lattices

  16. Time Monotone functionfrom set  max Monotone functionfrom max boolean size() >= 5 Set(merge = Union) Integer(merge = Max) Boolean(merge = Or)

  17. Monotonicity in Practice “The more you know, the more you know” Never retractprevious outputs(“mistake-free”) • Typical patterns: • immutable data • accumulate knowledge over time • threshold tests (“if” w/o “else”)

  18. Monotonicity and Determinism Agents strictly learn more knowledge over time Monotone: different learning order, same final outcome Result:Program is deterministic!

  19. A program is confluentif it produces the same results regardless of network nondeterminism

  20. A program is confluentif it produces the same results regardless of network nondeterminism

  21. CALM Analysis All monotone programs are confluent Simple syntactic test for monotonicity Result: Simple static analysis for eventual consistency ConsistencyAs LogicalMonotonicity

  22. Handling Non-Monotonicity … is not the focus of this talk  Basic choices: • Nodes agree on an event order using a coordination protocol (e.g., Paxos) • Allow non-deterministic outcomes • If needed, compensate and apologize

  23. Putting It Into Practice What we’d like: • Collection of agents • No shared state( message passing) • Computation over arbitrary lattices

  24. Quorum Vote in BloomL QUORUM_SIZE=5 RESULT_ADDR="example.org" classQuorumVote includeBud state do channel :vote_chn, [:@addr, :voter_id] channel :result_chn, [:@addr] lset:votes lmax:vote_cnt lbool:got_quorum end bloom do votes <=vote_chn {|v|v.voter_id} vote_cnt<=votes.size got_quorum<=vote_cnt.gt_eq(QUORUM_SIZE) result_chn<~got_quorum.when_true { [RESULT_ADDR] } end end Annotated Ruby class Communication interfaces Program state Lattice state declarations Accumulate votesinto set Map set ! max Map max !bool Program logic Merge function for set lattice Threshold test on bool

  25. Builtin Lattices

  26. Case Study

  27. Goal:Provably eventually consistentkey-value store (KVS) Assumption:Map keys to lattice values (i.e., values do not decrease) Solution:Use a map lattice

  28. Time Nested lattice value Replica 2 Replica 1

  29. Time Add new K/V pair Replica 2 Replica 1

  30. Time “Grow” value in extant K/V pair Replica 2 Replica 1

  31. Time Replica Synchronization Replica 2 Replica 1

  32. Goal:Provably eventually consistent KVS that stores arbitrary values Solution:Assign a version to eachkey-value pair Each replica stores increasingversions, not increasing values

  33. Object Versions in Dynamo/Riak • Each KV pair has a vector clock version • Given two versions of a KV pair, prefer the one with the strictly greater version • If versions are incomparable, invoke user-defined merge function

  34. Vector Clock:Map from node IDs  logical clocks Solution:Use a map lattice Logical Clock:Increasing counter Solution:Use an increasing-int lattice

  35. Version-Value Pairs Pair = <fst, snd> Pair merge(Pair o) { if self.fst > o.fst: self elsifself.fst < o.fst: o else new Pair(self.fst.merge(o.fst), self.snd.merge(o.snd)) }

  36. Time Replica 2 Replica 1

  37. Time Version increase;NOT value increase Replica 2 Replica 1

  38. Time R1’s version replaces R2’s version Replica 2 Replica 1

  39. Time New version @ R2 Replica 2 Replica 1

  40. Time Concurrent writes! Replica 2 Replica 1

  41. Merge VC (automatically),value merge via user’s lattice(as in Dynamo) Time Replica 2 Replica 1

  42. Lattice Composition in KVS

  43. Conclusion

  44. Questions Welcome Please try Bloom! http://www.bloom-lang.org Or: gem install bud

  45. Backup Slides

  46. Lattices hS,t,?iis a bounded join semi-latticeiff: • S is a partially ordered set • t is a binary operator (“least upper bound”) • For all x,y2 S, xty = z where x·Sz, y·Sz, and there is no z’ z2S such that z’ ·Sz. • Associative, commutative, and idempotent • ? is the “least” element in S(8x2S: ?t x= x) Example: increasing integers • S = Z, t = max, ? = -∞

  47. Monotone Functions f : ST is a monotone function iff 8a,b2S : a·Sb) f(a)·Tf(b) Example: size(Set) !Increasing-Intsize({A, B}) = 2size({A, B, C}) = 3

More Related