Eventual	
  Consistency	
  !=	
  Hopeful	
  
Consistency	
  
Embracing	
  Op:mis:c	
  Design	
  in	
  the	
  
Persistence	...
Who	
  am	
  I?	
  
Christos	
  Kalantzis	
  
Ne0lix	
  Inc.	
  
Engineering	
  Manager	
  –	
  Cloud	
  Database	
  Engin...
C*	
  Replica:on	
  &	
  Consistency	
  
Recap	
  
•  C*	
  is	
  eventually	
  Consistent	
  
–  That	
  means	
  it	
  W...
•  C*	
  has	
  tunable	
  consistency	
  
– All	
  
– Quorum	
  
– One	
  
C*	
  Replica:on	
  &	
  Consistency	
  
Recap...
Remember	
  When...?	
  
•  In	
  early	
  2000s,	
  Read	
  was	
  scaled	
  out	
  by	
  adding	
  
replica:on	
  Slaves...
Remember	
  When…?	
  
•  Slaves	
  could	
  lose	
  transac:ons	
  
Remember	
  When…?	
  
•  No	
  “Repair”	
  func:on	
  
Remember	
  When…?	
  
•  We	
  trusted	
  it	
  
•  We	
  s:ll	
  trust	
  it	
  
C*	
  Consistency	
  Concerns	
  
•  “I	
  want	
  high	
  consistency	
  in	
  my	
  Reads/Writes	
  just	
  like	
  I	
 ...
NeHlix	
  Experiment	
  
•  Created	
  a	
  mul:-­‐datacenter	
  C*	
  1.1.7	
  cluster	
  of	
  48	
  nodes	
  in	
  
eac...
NeHlix	
  Experiment	
  
Op:mis:c	
  vs.	
  Pessimis:c	
  Design	
  
•  Pessimis:c	
  Design	
  
– Design	
  with	
  high	
  consistency,	
  you	
 ...
Op:mis:c	
  vs.	
  Pessimis:c	
  Design	
  
•  Op:mis:c	
  Design	
  
– Trust	
  your	
  data	
  store	
  
•  Know	
  your...
Low	
  Consistency	
  Example	
  1	
  
Low	
  Consistency	
  Example	
  2	
  
Hurdles	
  Faced	
  
•  Engineers	
  are	
  stubborn!	
  
–  1+1=2	
  ..	
  not	
  eventually	
  2	
  
•  Middle	
  manage...
How	
  to	
  Overcome	
  those	
  Hurdles	
  
•  Prove	
  it	
  through	
  a	
  POC	
  
•  Show	
  them	
  the	
  benefits	...
Q&A	
  
Thank	
  you!	
  
Upcoming SlideShare
Loading in...5
×

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

434

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
434
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
11
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!  
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×