consistent storage or scalable storage why not both
play

Consistent Storage or Scalable Storage Why Not Both? CONSISTENCY - PowerPoint PPT Presentation

Consistent Storage or Scalable Storage Why Not Both? CONSISTENCY Strong Consistency Eventual Consistency "Consistency in database systems refers to the requirement that any given database transaction must change affected data only in


  1. Consistent Storage or Scalable Storage – Why Not Both?

  2. CONSISTENCY

  3. Strong Consistency

  4. Eventual Consistency

  5. "Consistency in database systems refers to the requirement that any given database transaction must change affected data only in allowed ways ." Wikipedia Consistency (database systems)

  6. PickTix Concert Tickets schema » User » Concert id id ⋄ ⋄ name name ⋄ ⋄ tickets_left ⋄ » TicketOrder id ⋄ user_id ⋄ concert_id ⋄ num_tickets ⋄

  7. Transactional Consistency Begin transaction » Read concert.tickets_left » Create new invoice for 10 tickets » Write tickets_left minus 10 from previous value End transaction

  8. Strong Consistency If I write X, then read X (from anywhere), it'll include that write. Eventual Consistency If I write X, then read X, it might not have the update now, but eventually it'll have it. Transactional Consistency Write and read-write transactions across the database are atomic and isolated.

  9. CASE STUDIES Apache Cassandra Spanner Built by Facebook Built by Google Open sourced 2008 Paper published 2012 Arguably 2nd most popular Recently released as beta Has schemas and SQL-like Schemas and SQL-like query language query language

  10. 1. Cassandra Representative non-relational storage system

  11. Client Client Client Client Client Database

  12. Client Client Client Client Client Client Client Client Client Client Client Client Node Node Node Node Node Node

  13. PickTix Concert Tickets schema » User » Concert id id ⋄ ⋄ name name ⋄ ⋄ tickets_left ⋄ » TicketOrder id ⋄ user_id ⋄ concert_id ⋄ num_tickets ⋄

  14. Partition: Ticket Orders Primary key concert_ id ticket_order_id user_id num_tickets (Partition key) 'adele' 1 'alice' 4 'adele' 2 'bob' 5 'gaga' 3 'alice' 1 'gaga' 4 'fred' 43

  15. Partition: Ticket Orders Primary key concert_ id ticket_order_id user_id num_tickets (Partition key) 'adele' 1 'alice' 4 'adele' 2 'bob' 5 'gaga' 3 'alice' 1 'gaga' 4 'fred' 43

  16. Node Node Node Node Node

  17. Node Node Node Node Node

  18. Node Node Node Node Node Node � � � Write Consistency Level: All

  19. Node Node Node Node Node Node � ? ? Write Consistency Level: One

  20. Node Node Node Node Node Node � ? � Write Consistency Level: Quorum

  21. N W + N R > N

  22. Global Replication

  23. Node Node Node Node Node Node Node Node Node Node Node Node Global replication Node

  24. Eventual Consistency Yes. Strong Consistency Yes, iff (W + R > N) is satisfied. Transactional Consistency Limited operations within partitions.

  25. Bob Alice Add pending friend request to Alice Add pending friend request from Bob Check pending friend request Add Alice to friends Add Bob to friends Delete pending friend request Delete pending friend request

  26. Bob Alice Add pending friend request to Alice Add pending friend request from Bob Check pending friend request Cancel pending friend request Add Alice to friends Add Bob to friends Delete pending friend request Delete pending friend request

  27. Development Costs » Choose partition keys wisely Include any data which must be kept consistent with it ⋄ Don't let it get too big ⋄ » Duplicate (denormalise) data » Background cleanup tasks

  28. 2. Spanner Representative scalable relational storage system

  29. Can I use Spanner now? It works! It Scales! It's battle-tested! It's ready to be used, except: » Google Cloud Platform only » Beta (no SLA) » Single region only » Expensive

  30. @jlawrence124 /r/wallpaper/

  31. Read-write/write-write consistency Alice wants to accept a pending friend request from Bob 1. Check that the friend request is still valid 2. Add Alice as a friend to Bob 3. Add Bob as a friend to Alice No risk of Bob cancelling the friend reqest between step 1 and 2/3

  32. The consistency guarantees we want Write, write-write and read-write transactions » Atomic » Isolated Read and Read-read transactions » Never see partial writes » If writes depend on each other, never see them out of order

  33. Linearizabilty T 1 T 2 T 1 < T 2

  34. Cassandra Write Timestamps Client A Client B T 1 T 2 T 2 T 1 T 2 T 1 T 2 T 1 Node Node Node

  35. Clock drift A's clock is slightly ahead B's clock is slightly behind A writes with timestamp T 1 (Client A generated timestamp) B reads at timestamp T 1 B writes at timestamp T 2 (Client B generated timestamp) T 2 < T 1 so B's write is before A's

  36. Atomic Clock Atomic Clock GPS Master GPS Master GPS Master Master Master Current time t Uncertainty ϵ Synchronise to time t Node Uncertainty ϵ = ϵ + network latency Increase ϵ over time TrueTime

  37. TrueTime TT.now() = [earliest, latest]

  38. Linearizabilty with TrueTime T 1 T 2 1. Transaction starts 2. Assign transaction timestamp T 1 to be TT.latest 3. Prepare transaction 4. Wait for T 1 to be earlier than TT.earliest 5. Commit transaction 6. Return success

  39. Linearizabilty T 1 T 2 T 1 ? T 2

  40. Spanner Partitions (tablets)

  41. Node Node Node Node Node Cassandra partition replication

  42. Spanserver Spanserver Spanserver Spanserver Spanserver Colossus

  43. Zone Master Zone Master Zone Master Location Location Location Location Location Location Proxy Proxy Proxy Proxy Proxy Proxy Spanserver Spanserver Spanserver Spanserver Spanserver Spanserver Spanserver Spanserver Spanserver Spanserver Spanserver Spanserver Colossus Colossus Colossus Zone Zone Zone

  44. Spanserver Spanserver Spanserver Spanserver Spanserver

  45. The consistency guarantees we want Write and read-write transactions » Atomic » Isolated Read-read transactions » Never see partial writes » If writes depend on each other, never see them out of order

  46. Transactions that conflict T 1 T 2

  47. � Spanserver Spanserver Spanserver Spanserver Spanserver

  48. Transactions that conflict T 1 T 2

  49. � � Spanserver � � Spanserver Spanserver Transactions across paxos groups (tablets)

  50. The consistency guarantees we want Write and read-write transactions » Atomic » Isolated Read and Read-read transactions » Never see partial writes » If writes depend on each other, never see them out of order

  51. Reads » Consistent reads at a timestamp » Strongly consistent reads » Time-bounded staleness reads

  52. Conclusions » Consistency guarantees make happy developers. » Transactional consistency at scale is feasible. » Perfect for high-read, low-write, consistency-sensitive data. » Consider using Spanner, if it works for you. » Keep a look out for the next generation! Or build it!

  53. THANKS! Any questions? I have copies of the Spanner, Cassandra and related papers here. You can find me at » katiebell.net » @notsolonecoder

Download Presentation
Download Policy: The content available on the website is offered to you 'AS IS' for your personal information and use only. It cannot be commercialized, licensed, or distributed on other websites without prior consent from the author. To download a presentation, simply click this link. If you encounter any difficulties during the download process, it's possible that the publisher has removed the file from their server.

Recommend


More recommend