1 / 47

Declarative Programming over Eventually Consistent Data Stores

Declarative Programming over Eventually Consistent Data Stores. Gowtham Kaki Suresh Jagannathan. KC Sivaramakrishnan. Http. Http. Http. Http. Stateless. AppServer. AppServer. AppServer. Cache. Cache. Cache. Cache. Consistency , Integrity, Durability, Availability, etc.

dawes
Télécharger la présentation

Declarative Programming over Eventually Consistent Data Stores

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. Declarative Programming over Eventually Consistent Data Stores Gowtham Kaki Suresh Jagannathan KC Sivaramakrishnan

  2. Http Http Http Http Stateless AppServer AppServer AppServer Cache Cache Cache Cache Consistency, Integrity, Durability, Availability, etc.

  3. Account balances should be non-negative Usernames should be unique Only bona fide bids are accepted in an auction. Application invariants Strong consistency Linearizability & Serializability

  4. INTERNET ☐ Strongly consistent, but not “always on” ☐ Be “always on”, but no strong consistency Eventual Consistency ∞ (convergence)

  5. Session 1 //init balance = 0 deposit(100) ? get_balance() Store Consistency Levels Basic eventual Read-my-writes Read-my-writes Causal Read committed Monotonic writes Parallel Snapshot Isolation Bounded staleness Eventually Consistent Data Stores INTERNET

  6. Session 1 Session 1 //init balance = 0 deposit(100) 0  get_balance() //init balance = 0 deposit(100) ??? get_balance() Replica 1 Replica 1 bal=0 bal=100 bal=100 bal=0 Replica 2 Eventual Consistency Read-my-writes consistency Replica 2 Store Consistency Levels Basic eventual Read-my-writes Read-my-writes Causal Read committed Monotonic writes Parallel Snapshot Isolation Bounded staleness Eventually Consistent Data Stores INTERNET

  7. Session 1 Session 1 //init balance = 0 deposit(100) 0  get_balance() //init balance = 0 deposit(100) 100 get_balance() Replica 1 Replica 1 bal=100 bal=100 bal=100 bal=0 Replica 2 Eventual Consistency Read-my-writes consistency Replica 2 Store Consistency Levels Basic eventual Read-my-writes Read-my-writes Causal Read committed Monotonic writes Parallel Snapshot Isolation Bounded staleness Eventually Consistent Data Stores INTERNET

  8. Application invariants deposit() withdraw() tweet() bid() Store Consistency Levels Basic eventual Read-my-writes Causal Read committed Monotonic writes Parallel Snapshot Isolation Bounded staleness Eventually Consistent Data Stores INTERNET

  9. Application invariants deposit() withdraw() tweet() bid() Can we automate the process of mapping application requirements to store consistency levels? Store Consistency Levels Basic eventual Read-my-writes Causal Read committed Monotonic writes Parallel Snapshot Isolation Bounded staleness Eventually Consistent Data Stores INTERNET

  10. Our solution … Classification Scheme An algorithm to … Application requirements Store consistency guarantees Map • Sound. • Optimal • Unique usernames. • Non-negative balance. • Bona fide bids. • Read-my-writes consistency • Causal consistency • Read committed isolation level • Repeatable read isolation level SpecificationLanguage A common medium to express both.

  11. Prelims - System Model Replicated Data Store Replica 1 Replica n Deposit(200) Withdraw(10) …… Deposit(200) Withdraw(20) Withdraw(10) …… Visibility (Vis) …… Vis getBalance getBalance Session 1 Session n v1 = getBalance(); …… v2 = getBalance(); …… Session Order (SO)

  12. Specification Language • Axiomatically capture set of valid executions • Associate with each operationa single abstract effect • Express relationshipbetween effects • Visibility (vis), Session order (so), Same object (sameobj) Primitive relations Happens-before

  13. Replicated Bank Account (1) balance >= 0 violated vis a b Session 2 Session 1 vis //init balance = 100 withdraw(70); //init balance = 100 withdraw(70);

  14. Bank Account Contracts (2) vis b a vis vis c getbalance () 50  getbalance () Session 1 Session 2 Session 3 deposit(100) withdraw(50) -50 A.getbalance ()

  15. Capturing Store Consistency Levels Eventual Consistency Causal Consistency Strong Consistency

  16. Classification Scheme Decidable Automatically discharged with the help of Z3 SMT solver. Eventual Consistency Causal Consistency • deposit  EC • withdraw  SC • getBalance CC Strong Consistency

  17. Classification Scheme (2)

  18. Transactions • Generalizing to transactions is easy. • Add single primitive relation - sametxn(a,b) • Derived relation: • Isolation guarantees of stores can now be specified. Read Committed oper2(…) oper3(…) Txn 1 (current) Txn 2 (committed) vis a b oper1(…) oper2(…) vis c

  19. Read Committed Monotonic atomic view Repeatable Read

  20. Haskell library for Eventually Consistent Data Stores (ECDS) • Definition language define operations and transactions on replicated data. • Specification language specify consistency and isolation requirements. GHC DEFS + Quelea Data Store

  21. Case Studies

  22. Evaluation • Correctness with classification vs without classification • How do they compare in terms of availability? • StrongRep: Strong Replication • NoRep: No Replication • Experimental Setup: • Amazon EC2; 5 replicas (StrongRep& Quelea); 1 replica (NoRep) • Gradually increased # of concurrent clients from 128 to 1024.

  23. Conclusion • Quelea Haskell-library for programming ECDS • Automatic classification of operation and transaction contracts through SMT solver • Leveraging off-the-shelf ECDS • Avoid re-engineering complex systems • Makes it practical! http://kcsrk.info/Quelea

  24. Thank you!

  25. State Summarization • Summarization is essential to check the unbounded growth of the log. • How is summarization done? • Ask developer for summarization semantics. • Replace (many) original effects with (few) summary effects.

  26. Monotonic Reads … like “monotonic reads” (roughly requiring that time doesn’t appear to go backward) . … So, if we want to build an available system providing the monotonic reads session guarantee, we can ensure that read operations only return writes when the writes are present on all servers.

  27. In the paper • Stronger eventual consistency • Highly available transaction support • Summarization

  28. System Model Quelea Data Store Effects R1 R2 Rn A  {d10,w2} B {d9} A  {d10,w2} B  {d9} A {d10,w2} B  {d9} Alice Bob …… Session 2 Session n Session 1 d5 …… B.deposit($5) B.withdraw($6) Session Order w6

  29. System Model Quelea Data Store R1 R2 Rn A  {d10,w2} B  {d9} A  {d10,w2} B  {d9} A  {d10,w2} B  {d9} Alice Bob …… Session n Session 1 Session 2 d5 …… B.deposit($5) B.withdraw($6) Session Order w6

  30. System Model Quelea Data Store R1 R2 Rn A  {d10,w2} B  {d9,d5} A  {d10,w2} B  {d9} A  {d10,w2} B  {d9,w6} Alice Bob …… w6 d5 Session 2 Session 1 Session n d5 …… B.deposit($5) B.withdraw($6) Session Order w6

  31. System Model Quelea Data Store R1 R2 Rn A  {d10,w2} B  {d3,d5,w6} A  {d10,w2} B  {d3,d5,w6} A  {d10,w2} B  {d3,d5,w6} Alice Bob …… Session 2 Session n Session 1 d5 …… B.deposit($5) B.withdraw($6) Session Order w6

  32. System Model Quelea Data Store A  {d10,w2} B  {d3,d5,w6} R1 …… Alice Bob gb vis Session 1 d5 …… B.deposit($5) B.withdraw($6) v1 = B.getBalance() w6 gb

  33. System Model Quelea Data Store A  {d10,w2} B  {d3,d5,w6} R1 …… Alice Bob gb vis Session 1 d5 …… B.deposit($5) B.withdraw($6) v1 = $3+$5–$6 = $2 w6 gb

  34. System Model Replicated Data Store Replica 1 Replica n Deposit(200) Withdraw(10) Deposit(10) …… Deposit(200) Withdraw(20) Withdraw(10) …… …… Session 1 Session n getBalance; …… withdraw(6); …… Session Order (SO)

  35. Replicated Bank Account (2) vis b a vis vis c 50  getbalance () getbalance () Session 1 Session 2 Session 3 deposit(100) withdraw(50) -50 getbalance ()

  36. Evaluation

  37. Replicated Bank Account (1) Session 1 Session 2 bal = A.getBalance(); If (bal ≥ 70) A.withdraw(70); A.withdraw(70);

  38. Replicated Bank Account (1) SO b a Session 1 c Session 2 Session 1 Session 2 100 = A.getBalance(); If (100 ≥ 70) A.withdraw(70); a A.withdraw(70); c b

  39. Replicated Bank Account (1) SO b a Session 1 VIS c Session 2 Session 2 Session 1 100 = A.getBalance(); If (100 ≥ 70) A.withdraw(70); a A.withdraw(70); c b

  40. Replicated Bank Account (1) Required invariant: balance >= 0 SO b a Session 1 VIS c Session 2

  41. Replicated Bank Account (1) Session 2 Session 1 //init balance = 100 withdraw(70); //init balance = 100 withdraw(70);

  42. Transactions • Allows compositionof operations. • Serializable transactions are unavailable • Highly available transactions (HAT) • Atomic, but relaxed Isolation. • Isolation levels: read committed, repeatable read, monotonic atomic view, etc. • Express foreign key constraints, secondary indexesetc. • Choosing the correct isolation guarantee is an error-prone process • Automate it through specifications and classification! • sametxn(a,b)

  43. Case Study - RUBiS • Application Invariants: • Canceling a bid must not violate data integrity • A bidder must see all bids placed in the current session • … • An “e-Bay”-like auction site

  44. INTERNET ☐ Strongly consistent, but not “always on” ☐ Be “always on”, but no strong consistency Eventual Consistency ∞ (convergence)

More Related