Ce diaporama a bien été signalé.
Le téléchargement de votre SlideShare est en cours. ×

La Duck Conf 2018 : "Life after the CAP Theorem"

Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Publicité
Chargement dans…3
×

Consultez-les par la suite

1 sur 45 Publicité

La Duck Conf 2018 : "Life after the CAP Theorem"

Télécharger pour lire hors ligne

Présentation du talk de Boremi Toch et Stéphane Lundy à La Duck Conf 2018.
Ma base est-elle CA, AP ou CP ? la question n'est pas toujours pertinente.
Depuis qu'il est devenu branché, voire courant d'écrire sa donnée dans une base non relationnelle, il y a un théorème qui revient souvent, le théorème CAP.
Mais tout rigoureux qu'il soit, ne le laissez plus parasiter vos décisions d'architecture et venez l'attaquer sous l'angle pragmatique, celui qui vous aide à concevoir vos architectures pour répondre à des besoins et enjeux métier.
Commençons par un peu d'historique pour mieux appréhender le problème sous-jacent, pour ensuite mieux réfléchir aux questions pragmatiques à se poser.

Présentation du talk de Boremi Toch et Stéphane Lundy à La Duck Conf 2018.
Ma base est-elle CA, AP ou CP ? la question n'est pas toujours pertinente.
Depuis qu'il est devenu branché, voire courant d'écrire sa donnée dans une base non relationnelle, il y a un théorème qui revient souvent, le théorème CAP.
Mais tout rigoureux qu'il soit, ne le laissez plus parasiter vos décisions d'architecture et venez l'attaquer sous l'angle pragmatique, celui qui vous aide à concevoir vos architectures pour répondre à des besoins et enjeux métier.
Commençons par un peu d'historique pour mieux appréhender le problème sous-jacent, pour ensuite mieux réfléchir aux questions pragmatiques à se poser.

Publicité
Publicité

Plus De Contenu Connexe

Plus par OCTO Technology (20)

Plus récents (20)

Publicité

La Duck Conf 2018 : "Life after the CAP Theorem"

  1. 1. Life After the CAP Theorem Borémi Toch & Stéphane Lundy
  2. 2. 2 Who’s Who ? @LSrandomBorémi Toch
  3. 3. 3 Why are we talking about a theorem ?
  4. 4. 4 From Pets to Cattle: Distributed is Becoming The Norm
  5. 5. 5 So what’s the goal ? ☉ Understand why the CAP Theorem is not that practical, but still useful ☉ Give you practical guidelines when dealing with distributed persistence ☉ Match the system design with the business stakes
  6. 6. 6 From Start...
  7. 7. 7 ...To Finish
  8. 8. >01 Brewer’s Conjecture
  9. 9. 9 What is distributed system ? A distributed systemNot a distributed system
  10. 10. 10 Your guide for the hike: Mr. Eric Brewer
  11. 11. 11 You can’t have the whole pie and eat it, Eric Brewer 2000
  12. 12. 12 Getting equipped: a tiny bit of theory
  13. 13. 13 Consistency (Linearizability) There must exist a total order on all operations such that each operation looks as if it were completed at a single instant. Gilbert, Lynch, 2002 v1 v2 v3 Read ReadWrite(v2) Read=> v3Write(v3)=> v1 => v3
  14. 14. 14 Availability Every request received by a non-failing node in the system must result in a response. Gilbert, Lynch, 2002 Client Request Response
  15. 15. 15 Partition Tolerance When a network is partitioned, all messages sent from nodes in one component of the partition to nodes in another component are lost. Gilbert, Lynch, 2002 Distributed System
  16. 16. 16 Partition Tolerance When a network is partitioned, all messages sent from nodes in one component of the partition to nodes in another component are lost. Gilbert, Lynch, 2002 Blue Partition Green Partition
  17. 17. 17 The Completely Asynchronous Network Assumption
  18. 18. >02 Brewer’s Refresh
  19. 19. 19 2012: Second Take, by Brewer himself ☉ Must read article (available on infoQ) ☉ 12 years of insight into what his original conjecture meant ☉ Easy read with practical examples
  20. 20. 20 2015: A Critique of the CAP Theorem, by Martin Kleppmann ☉ Excellent in-depth analysis ☉ Must read to understand the in-depth limitations of the CAP Theorem ☉ Extensive bibliography to dig deeper in the current state of the art
  21. 21. CAP Theorem Dismisses Latency ☉ CAP Theorem ignores latency, even though in practice communications rely on it ☉ Availability and partition state cannot be detected instantaneously Blue Partition Green Partition
  22. 22. 22 No one can actually forfeit Partitions
  23. 23. Consistency and Availability Need Not Be Perfect ☉ The CAP impossibility result holds only for perfect properties ☉ C & A actually range on a spectrum, where tradeoff rules the land Always return v0 Return latest consistent version Return stale version (vN, N>0) Eventual Consistency Super Fragile High Availability 99.999999... availability Useless Holy GrailPragmatic Architecture Consistency Availability
  24. 24. >03 How To Use It In Practice
  25. 25. 25 Easy Peasy Practical Guide
  26. 26. 26 Guideline #1: Ask The Partition Question ☉ That’s a system designer question > Should the system restrict operations ? > Should the system proceed ? ☉ And a designer question is actually a business decision What should the system do when a partition occurs ?
  27. 27. 27 Guideline #2: Ask The Recovery Question ☉ A system designer has tools to do that, for instance > Last Writer Wins > Linearisation > Compensation > Human escalation ☉ But in the end that is again a business decision How should we resolve the partition conflict ?
  28. 28. 28 Guideline #0: Don’t Forget That’s Part Of A Risk Analysis ☉ Overdesign lurks on the dark side ☉ System Designers have tools > KISS: Keep It Simple & Stupid > Measure, Don’t guess (aka. empiricism, test & learn, short feedback loop…) ☉ What are the risks and impacts ? ask the business people Is the likelihood worth the complexity ?
  29. 29. 29 A nice drawing to clear things up Time
  30. 30. 30 A nice drawing to clear things up Time Partition recovery Partition
  31. 31. 31 Hey but it’s just like ☉ Partition is by design ☉ Merge cannot always be completely automated Time Merge Local modifications
  32. 32. >04 Other IT Examples And Patterns
  33. 33. File Synchronization ☉ Partition is by design ☉ Last Writer Wins strategy (LWW) most of the time ☉ Conflicts are escalated to the user with file names suffixed with (2), (3)... Time Back to base Offline work
  34. 34. Document Edition ☉ Edition in the browser, with varying update frequency ☉ Strategies: LWW for whole document or finer text modifications updates Time Merge Local modifications
  35. 35. Optimistic Locking Pessimistic Locking Relational Databases Management Systems ☉ Pessimistic Locking is about preventing partitions ☉ Optimistic Locking is about concurrent editing with a First Writer Wins strategy Time
  36. 36. Blockchain Mandatory Mention ☉ Blockchains are decentralised systems ☉ In proof of work systems, the longest chain, ie. the most powerful alternative wins Time Merge Uncertainty
  37. 37. >05 Business Already Knows It All
  38. 38. E-commerce: Stock Management ☉ What do you want : > To check your stock before selling ? > To sell items as fast as possible ? ☉ What do you need ? > It depends !
  39. 39. ☉ What do you want : > To check the disponibility of assets ? > To encourage the cash flow ? ☉ What do you need ? > It depends ! ATM: Withdrawal or no Withdrawal
  40. 40. ☉ What do you want : > To check users permission ? > To show the up to date content ? ☉ What do you need ? > It depends ! Social Media: Timeline Consistency
  41. 41. >06 Wrap-Up
  42. 42. 42
  43. 43. So What to Think about the CAP Theorem ? All models are wrong, but some are useful George E. P. Box
  44. 44. 44 Take Away ☉ Though not practical, the CAP Theorem is not useless > It helps raise questions about the Consistency-Availability trade-off > It has fueled many distributed system designs since 2000 ☉ Think about Network Partitions when you design systems > What are the risks ? > What to do when a partition occurs ? > What are the rules to recover from a partition ? ☉ You may actually be more familiar with it than you think > Don’t bicker about being CA, AP, or CP > You already use some distributed IT tools ☉ Never forget : answers come from the business
  45. 45. 45 Initiatives To Keep An Eye On ☉ Conflict-free Replicated Data Types aka. CRDT > Started with a paper published by Shapiro & al. 2011 > CRDT ensure worry-free partition recovery > Some products leverage CRDT: Riak, Redis… ☉ Spanner: closing on the CAP impossibility > Cloud Spanner is a fully managed consistent database with high availability > Eric Brewer, now VP of infrastructure at Google has analysed Spanner in the CAP Theorem perspective > Leverages Google infrastructure: highly reliable network & high precision clocks

×