Merge pull request #47 from lentzi90/master

Fixed two typos in chapter 5; Rebuild

input/5_eventual.md

@@ -13,7 +13,7 @@ As I stated in the introduction, I think that much of distributed programming is
 
 The implication that follows from the limitation on the speed at which information travels is that nodes experience the world in different, unique ways. Computation on a single node is easy, because everything happens in a predictable global total order. Computation on a distributed system is difficult, because there is no global total order.
 
-For the longest while (e.g. decades of research), we've solved this problem by introducing a global total order. I've discussed the many methods for achieving strong consistency by creating order (in a fault-tolerant manner) where there is no naturally occurring total order.
+For the longest while (i.e. decades of research), we've solved this problem by introducing a global total order. I've discussed the many methods for achieving strong consistency by creating order (in a fault-tolerant manner) where there is no naturally occurring total order.
 
 Of course, the problem is that enforcing order is expensive. This breaks down in particular with large scale internet systems, where a system needs to remain available. A system enforcing strong consistency doesn't behave like a distributed system: it behaves like a single system, which is bad for availability during a partition.
 
@@ -90,7 +90,7 @@ Keeping these two examples in mind, let's look at Amazon's Dynamo first to estab
 
 Amazon's Dynamo system design (2007) is probably the best-known system that offers weak consistency guarantees but high availability. It is the basis for many other real world systems, including LinkedIn's Voldemort, Facebook's Cassandra and Basho's Riak.
 
-Dynamo is an eventually consistent, highly available key-value store. A key value store is like a large hash table: a client can set values via `set(key, value)` and retrieve them by key using `get(key)`. A Dynamo cluster consists of N peer nodes; each node has a set of keys which is it responsible for storing.
+Dynamo is an eventually consistent, highly available key-value store. A key value store is like a large hash table: a client can set values via `set(key, value)` and retrieve them by key using `get(key)`. A Dynamo cluster consists of N peer nodes; each node has a set of keys which it is responsible for storing.
 
 Dynamo prioritizes availability over consistency; it does not guarantee single-copy consistency. Instead, replicas may diverge from each other when values are written; when a key is read, there is a read reconciliation phase that attempts to reconcile differences between replicas before returning the value back to the client.
 
@@ -241,7 +241,7 @@ For more details, have a look at the [PBS website](http://pbs.cs.berkeley.edu/)
 
 Let's look back at the examples of the kinds of situations that we'd like to resolve. The first scenario consisted of three different servers behind partitions; after the partitions healed, we wanted the servers to converge to the same value. Amazon's Dynamo made this possible by reading from `R` out of `N` nodes and then performing read reconciliation.
 
-In the second example, we considered a more specific operation: string concatenation. It turns out that there is no known technique for making string concatenation resolve to the same value without imposing an order on the operations (e.g. without expensive coordination). However, there are operations which can be applied safely in any order, where a simple register would not be able to do so. As Pat Helland wrote:
+In the second example, we considered a more specific operation: string concatenation. It turns out that there is no known technique for making string concatenation resolve to the same value without imposing an order on the operations (i.e. without expensive coordination). However, there are operations which can be applied safely in any order, where a simple register would not be able to do so. As Pat Helland wrote:
 
 > ... operation-centric work can be made commutative (with the right operations and the right semantics) where a simple READ/WRITE semantic does not lend itself to commutativity.
 
@@ -296,7 +296,7 @@ It turns out that these structures are already known in mathematics; they are kn
 
 A [lattice](http://en.wikipedia.org/wiki/Lattice_%28order%29) is a partially ordered set with a distinct top (least upper bound) and a distinct bottom (greatest lower bound). A semilattice is like a lattice, but one that only has a distinct top or bottom. A join semilattice is one with a distinct top (least upper bound) and a meet semilattice is one with a distinct bottom (greatest lower bound).
 
-Any data type that be expressed as a semilattice can be implemented as a data structure which guarantees convergence. For example, calculating the `max()` of a set of values will always return the same result regardless of the order in which the values were received, as long as all values are eventually received, because the `max()` operation is associative, commutative and idempotent.
+Any data type that can be expressed as a semilattice can be implemented as a data structure which guarantees convergence. For example, calculating the `max()` of a set of values will always return the same result regardless of the order in which the values were received, as long as all values are eventually received, because the `max()` operation is associative, commutative and idempotent.
 
 For example, here are two lattices: one drawn for a set, where the merge operator is `union(items)` and one drawn for a strictly increasing integer counter, where the merge operator is `max(values)`:
 

output/abstractions.html

@@ -60,7 +60,7 @@ <h1 style="color: white; background: #D82545; display: inline-block; padding: 6p
     <div id="main">
       <div id="content" class="post">
 <h1 id="-chapter_number-up-and-down-the-level-of-abstraction">2. Up and down the level of abstraction</h1>
-<p>In this chapter, we&#39;ll travel up and down the level of abstraction; look at some impossibility results (CAP and FLP) and then travel back down for the sake of performance.</p>
+<p>In this chapter, we&#39;ll travel up and down the level of abstraction, look at some impossibility results (CAP and FLP), and then travel back down for the sake of performance.</p>
 <p>If you&#39;ve done any programming, the idea of levels of abstraction is probably familiar to you. You&#39;ll always work at some level of abstraction, interface with a lower level layer through some API, and probably provide some higher-level API or user interface to your users. The seven-layer <a href="http://en.wikipedia.org/wiki/OSI_model">OSI model of computer networking</a> is a good example of this.</p>
 <p>Distributed programming is, I&#39;d assert, in large part dealing with consequences of distribution (duh!). That is, there is a tension between the reality that there are many nodes and with our desire for systems that &quot;work like a single system&quot;. That means finding a good abstraction that balances what is possible with what is understandable and performant.</p>
 <p>What do we mean when say X is more abstract than Y? First, that X does not introduce anything new or fundamentally different from Y. In fact, X may remove some aspects of Y or present them in a way that makes them more manageable.
@@ -191,7 +191,7 @@ <h2 id="the-cap-theorem">The CAP theorem</h2>
 <p>How can we work around this? By strengthening the assumptions (assume no partitions) or by weakening the guarantees. Consistency can be traded off against availability (and the related capabilities of offline accessibility and low latency). If &quot;consistency&quot; is defined as something less than &quot;all nodes see the same data at the same time&quot; then we can have both availability and some (weaker) consistency guarantee.</p>
 <p>Third, that <em>there is a tension between strong consistency and performance in normal operation</em>.</p>
 <p>Strong consistency / single-copy consistency requires that nodes communicate and agree on every operation. This results in high latency during normal operation.</p>
-<p>If you can live with a consistency model other than the classic one; a consistency model that allows replicas to lag or to diverge, then you can reduce latency during normal operation and maintain availability in the presence of partitions.</p>
+<p>If you can live with a consistency model other than the classic one, a consistency model that allows replicas to lag or to diverge, then you can reduce latency during normal operation and maintain availability in the presence of partitions.</p>
 <p>When fewer messages and fewer nodes are involved, an operation can complete faster. But the only way to accomplish that is to relax the guarantees: let some of the nodes be contacted less frequently, which means that nodes can contain old data.</p>
 <p>This also makes it possible for anomalies to occur. You are no longer guaranteed to get the most recent value. Depending on what kinds of guarantees are made, you might read a value that is older than expected, or even lose some updates.</p>
 <p>Fourth - and somewhat indirectly - that <em>if we do not want to give up availability during a network partition, then we need to explore whether consistency models other than strong consistency are workable for our purposes</em>.</p>

output/appendix.html

@@ -59,7 +59,7 @@ <h1 style="color: white; background: #D82545; display: inline-block; padding: 6p
 
     <div id="main">
       <div id="content" class="post">
-<h1 id="-chapter_number-further-reading-and-appendix">7. Further reading and appendix</h1>
+<h1 id="-chapter_number-further-reading-and-appendix">6. Further reading and appendix</h1>
 <p>If you&#39;ve made it this far, thank you.</p>
 <p>If you liked the book, follow me on <a href="https://github.com/mixu/">Github</a> (or <a href="http://twitter.com/mikitotakada">Twitter</a>). I love seeing that I&#39;ve had some kind of positive impact. &quot;Create more value than you capture&quot; and all that.</p>
 <p>Many many thanks to: logpath, alexras, globalcitizen, graue, frankshearar, roryokane, jpfuentes2, eeror, cmeiklejohn, stevenproctor eos2102 and steveloughran for their help! Of course, any mistakes and omissions that remain are my fault!</p>
@@ -99,7 +99,7 @@ <h3 id="systems">Systems</h3>
 <li><a href="http://scholar.google.com/scholar?q=Dynamo%3A+Amazon&#39;s+Highly+Available+Key-value+Store">Dynamo: Amazon’s Highly Available Key-value Store</a> - DeCandia et al.</li>
 <li><a href="http://research.google.com/archive/bigtable.html">Bigtable: A Distributed Storage System for Structured Data</a> - Chang et al.</li>
 <li><a href="http://research.google.com/archive/chubby.html">The Chubby Lock Service for Loosely-Coupled Distributed Systems</a> - Burrows</li>
-<li><a href="http://research.yahoo.com/pub/3280">ZooKeeper: Wait-free coordination for Internet-scale systems</a></li>
+<li><a href="http://www.usenix.org/event/usenix10/tech/full_papers/Hunt.pdf">ZooKeeper: Wait-free coordination for Internet-scale systems</a> - Hunt, Konar, Junqueira, Reed, 2010</li>
 </ul>
 
         </div>