Cassandra Day SV 2014: A Netflix Experiment Eventual Consistency != Hopeful Consistency with Apache Cassandra

944 views

Published on

“Eventually consistent does not mean a day, minute or even second from now… in most cases, it is milliseconds!”

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

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
944
On SlideShare
0
From Embeds
0
Number of Embeds
6
Actions
Shares
0
Downloads
16
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Cassandra Day SV 2014: A Netflix Experiment Eventual Consistency != Hopeful Consistency with Apache Cassandra

  1. 1. Eventual  Consistency  !=  Hopeful   Consistency   Embracing  Op:mis:c  Design  in  the   Persistence  Layer  
  2. 2. Who  am  I?   Christos  Kalantzis   Ne0lix  Inc.   Engineering  Manager  –  Cloud  Database  Engineering     @chriskalan   ckalantzis@neHlix.com   www.linkedin.com/in/christoskalantzis    
  3. 3. C*  Replica:on  &  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  
  4. 4. •  C*  has  tunable  consistency   – All   – Quorum   – One   C*  Replica:on  &  Consistency   Recap  
  5. 5. Remember  When...?   •  In  early  2000s,  Read  was  scaled  out  by  adding   replica:on  Slaves  to  a  Master  DB.   •  Writes  went  to  a  single  Master,  Reads  went  to   Slaves          
  6. 6. Remember  When…?   •  Slaves  could  lose  transac:ons  
  7. 7. Remember  When…?   •  No  “Repair”  func:on  
  8. 8. Remember  When…?   •  We  trusted  it   •  We  s:ll  trust  it  
  9. 9. C*  Consistency  Concerns   •  “I  want  high  consistency  in  my  Reads/Writes  just  like  I   had  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  wri:ng   at  CL  1”  
  10. 10. NeHlix  Experiment   •  Created  a  mul:-­‐datacenter  C*  1.1.7  cluster  of  48  nodes  in   each  DC   •  Put  load  on  C*  Cluster   –  100K  total  opera:ons  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!  
  11. 11. NeHlix  Experiment  
  12. 12. Op:mis:c  vs.  Pessimis:c  Design   •  Pessimis:c  Design   – Design  with  high  consistency,  you  punish  your   users  99.9%  of  the  :me   •  Higher  consistency  =  higher  latency   •  Diminished  user  experience  
  13. 13. Op:mis:c  vs.  Pessimis:c  Design   •  Op:mis:c  Design   – Trust  your  data  store   •  Know  your  business  and  your  applica:on   – Always  ask  yourself,  is  it  really  that  important?   •  Handle  edge  cases  through  con:ngency  plans  
  14. 14. Low  Consistency  Example  1  
  15. 15. Low  Consistency  Example  2  
  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  of   con:ngency  plans  
  17. 17. How  to  Overcome  those  Hurdles   •  Prove  it  through  a  POC   •  Show  them  the  benefits  of  an  improved  user   experience   –  Its  all  about  the  user   •  You  may  be  working  for  the  wrong  company   –  We’re  hiring!   –  jobs.neHlix.com  
  18. 18. Q&A  
  19. 19. Thank  you!  

×