diff --git a/src/main/asciidoc/_chapters/performance.adoc b/src/main/asciidoc/_chapters/performance.adoc index 48b647c..8b0b04a 100644 --- a/src/main/asciidoc/_chapters/performance.adoc +++ b/src/main/asciidoc/_chapters/performance.adoc @@ -100,6 +100,19 @@ Using 10Gbe links between racks will greatly increase performance, and assuming Are all the network interfaces functioning correctly? Are you sure? See the Troubleshooting Case Study in <>. +[[perf.network.call_me_maybe]] +=== Network Consistency and Partition Tolerance +The link:http://en.wikipedia.org/wiki/CAP_theorem[CAP Theorem] states that a distributed system can maintain two out of the following three charateristics: +- *C*onsistency -- all nodes see the same data. +- *A*vailability -- every request receives a response about whether it succeeded or failed. +- *P*artition tolerance -- the system continues to operate even if some of its components become unavailable to the others. + +HBase favors consistency and partition tolerance, where a decision has to be made. Coda Hale explains why partition tolerance is so important, in http://codahale.com/you-cant-sacrifice-partition-tolerance/. + +Robert Yokota used an automated testing framework called link:https://aphyr.com/tags/jepsen[Jepson] to test HBase's partition tolerance in the face of network partitions, using techniques modeled after Aphyr's link:https://aphyr.com/posts/281-call-me-maybe-carly-rae-jepsen-and-the-perils-of-network-partitions[Call Me Maybe] series. The results, available as a link:http://eng.yammer.com/call-me-maybe-hbase/[blog post] and an link:http://eng.yammer.com/call-me-maybe-hbase-addendum/[addendum], show that HBase performs correctly. In the tests, acknowledged writes are accounted for, and no unacknowledged writes are written. + +Partition-tolerance is not perfect. It is expected that if the client fails at the right time, the write will be in the WAL, but the RegionServer's acknowledgment will not reach the client, and then client would assume failure. + [[jvm]] == Java