C* Summit 2013: Eventual Consistency != Hopeful Consistency by Christos Kalantzis

12,909 views

Published on

This session will address Cassandra's tunable consistency model and cover how developers and companies should adopt a more Optimistic Software Design model.

Published in: Technology

C* Summit 2013: Eventual Consistency != Hopeful Consistency by Christos Kalantzis

  1. 1. Eventual Consistency != HopefulConsistencyEmbracing Optimistic Design in thePersistence Layer#Cassandra13
  2. 2. Who am I?Christos KalantzisNetflix Inc.Manager – Cloud Persistence Engineering@chriskalanckalantzis@netflix.comwww.linkedin.com/in/christoskalantzis#Cassandra13
  3. 3. C* Replication & Consistency Recap• C* is eventually Consistent– That means it WILL get there…eventually• Eventually is not:– A day from now– A minute from now– A second from now• In most cases it is milliseconds#Cassandra13
  4. 4. • C* has tunable consistency– All– Quorum– OneC* Replication & Consistency Recap#Cassandra13
  5. 5. Remember When...?• In early 2000s, Read was scaled out by addingreplication Slaves to a Master DB.• Writes went to a single Master, Reads went toSlaves#Cassandra13
  6. 6. Remember When…?• Slaves could lose transactions#Cassandra13
  7. 7. Remember When…?• No “Repair” function#Cassandra13
  8. 8. Remember When…?• We trusted it• We still trust it#Cassandra13
  9. 9. C* Consistency Concerns• “I want high consistency in my Reads/Writes just like Ihad in my RDBMS setup”– You never really had it.• “I want my DB to catch integrity issues”– We’ve been turning FK off for years!• See Rails, Grails & other MVC frameworks• Can I trust that C* will replicate my data when writingat CL 1”#Cassandra13
  10. 10. Netflix Experiment• Created a multi-datacenter C* 1.1.7 cluster of 48 nodes ineach DC• Put load on C* Cluster– 100K total operations per second (50 K in each DC)• Wrote 1,000,000 records at CL1 in one DC• Read same 1,000,000 records at CL1 in other DC• ALL records were read successfully• You can trust it!#Cassandra13
  11. 11. Netflix Experiment#Cassandra13
  12. 12. Optimistic vs. Pessimistic Design• Pessimistic Design– Design with high consistency, you punish yourusers 99.9% of the time• Higher consistency = higher latency• Diminished user experience#Cassandra13
  13. 13. Optimistic vs. Pessimistic Design• Optimistic Design– Trust your data store• Know your business and your application– Always ask yourself, is it really that important?• Handle edge cases through contingency plans#Cassandra13
  14. 14. Low Consistency Example 1Amazon• Inventory system sometimes sells items notavailable• Cancel the order• They offer credit of 10% towards futurepurchase#Cassandra13
  15. 15. Low Consistency Example 2Banks• The most eventual consistent system• Write a check, which may or may not be covered• Bank will “bounce” the check• Recoup funds if possible and charge a handsomefee#Cassandra13
  16. 16. Hurdles Faced• Engineers are stubborn!– 1+1=2 .. not eventually 2• Middle management is scared– It’s a feat you convinced them to use C*– Now you got to convince them to accept low consistency?• Engaging Product team to implement some type ofcontingency plans#Cassandra13
  17. 17. How to Overcome those Hurdles• Prove it through a POC• Show them the benefits of an improved userexperience– Its all about the user• You may be working for the wrong company– We’re hiring!– jobs.netflix.com#Cassandra13
  18. 18. Q&A#Cassandra13
  19. 19. Thank you!#Cassandra13

×