Harvest, Yield, and Scalable Tolerant Systems

Harvest, Yield, and Scalable Tolerant Systems


Pedro Tavares

October 30, 2018


  1. 4.

    “We propose two strategies for improving overall availability using simple

    mechanisms that scale over large applications whose output behavior tolerates graceful degradation.”
  2. 8.

    “[…] originally proposed as a rule of thumb, without precise

    definitions, with the goal of starting a discussion about trade-offs in databases.”
  3. 11.
  4. 14.

    When a failure occurs, the system should keep going, switching

    over to a replica, if required. Availability (A)
  5. 16.

    The system should continue to operate despite arbitrary message loss

    or failure of part of the system. Partition resilience (P)
  6. 18.

    ⚡A network partition is a communication fault that splits the

    network into subsets of nodes that cannot communicate with each other.⚡
  7. 22.
  8. 29.

    ⚡ 1. set(‘x’,1) 2. send(‘x’) x=1 x=2 ⚡ 1. set(‘x’,2)

    2. send(‘x’) Both nodes are available, although there’s no consistency!
  9. 34.

    To achieve atomic reads and writes we must wait for

    a response from the partitioned node. CP without A
  10. 36.
  11. 37.

    “The stronger the guarantees made about any two, the weaker

    the guarantees that can be made about the third.”
  12. 41.

    “In the presence of faults there is typically a tradeoff

    between providing no answer and providing an imperfect answer.”
  13. 45.

    “Instead of CAP, you should think about your availability in

    terms of yield and harvest and which of these two your system will sacrifice when failures happen.” https://codahale.com/you-cant-sacrifice-partition-tolerance
  14. 50.

    Sacrifice consistency all the time, not just when there is

    a network partition. While an AP system…
  15. 54.

    “Systems that tend to give up consistency for availability when

    there is a partition also tend to give up consistency for latency when there is no partition.” http://dbmsmusings.blogspot.com/2010/04/problems-with-cap-and-yahoos-little.html
  16. 58.

    “The CAP theorem asserts that any networked shared-data system can

    have only two of three desirable properties.” https://www.infoq.com/articles/cap-twelve-years-later-how-the-rules-have-changed
  17. 59.

    ⚡Network faults: you don’t have a choice — they will

    happen whether you like it or not!⚡
  18. 61.
  19. 62.
  20. 63.

    “[…] by explicitly handling partitions, designers can optimize consistency and

    availability, thereby achieving some tradeoff of all three.” https://www.infoq.com/articles/cap-twelve-years-later-how-the-rules-have-changed
  21. 65.

    “Whatever way you choose to learn, I encourage you to

    be curious and patient – this stuff doesn’t come easy.” https://martin.kleppmann.com/2015/05/11/please-stop-calling-databases-cp-or-ap.html
  22. 66.

    “But whatever you do, please stop talking about CP and

    AP, because they just don’t make any sense.” https://martin.kleppmann.com/2015/05/11/please-stop-calling-databases-cp-or-ap.html