Merge pull request #20 from mychaow/master

complete review 11-13 chapter

docs/11.md

 # 内存压缩
 
-## 77.概述
+## 77\. 概况
 
-内存压缩（A.K.A Accordion）是 hbase-2.0.0 中的一项新功能。它首先在 [Accordion 的 Apache HBase 博客上推出：HBase 通过内存压缩进行呼吸](https://blogs.apache.org/hbase/entry/accordion-hbase-breathes-with-in)。引用博客：
+内存压缩（A.K.A Accordion）是hbase-2.0.0中的一项新功能。它首先在[Accordion：HBase Breathes with In-Memory Compaction]的Apache HBase博客上引入（https://blogs.apache.org/hbase/entry/accordion-hbase-breathes-with-in）。引用博客：
 
-> Accordion 将 LSM 主体[ _Log-Structured-Merge Tree_ ，HBase 所基于的设计模式]重新应用于 MemStore，以便在数据仍在 RAM 中时消除冗余和其他开销。这样做可以降低冲洗到 HDFS 的频率，从而减少写入放大和整个磁盘占用空间。由于刷新次数较少，因此 MemStore 溢出时写入操作停止的频率降低，因此写入性能得到改善。磁盘上的数据越少，对块缓存的压力越小，命中率越高，最终读取响应时间越长。最后，具有较少的磁盘写入也意味着在后台发生较少的压缩，即，从生产（读取和写入）工作中窃取的循环较少。总而言之，内存压缩的效果可以被设想为催化剂，使系统整体上移动得更快。
+> Accordion将LSM原理[_Log-Structured-Merge Tree_，HBase所基于的设计模式]重新应用于MemStore，以便在数据仍在RAM中时消除冗余和其他开销。这样做可以降低flush到HDFS的频率，从而减少写入放大和整个磁盘占用空间。由于刷新次数较少，因此MemStore溢出时写入操作停顿的频率降低，因此写入性能得到改善。磁盘上的数据越少，对块缓存的压力越小，命中率越高，最终读取响应时间越短。最后，具有较少的磁盘写入也意味着在后台发生较少的compaction，即，从生产（读取和写入）工作中分割的资源较少。总而言之，内存压缩的效果可以被看作是一个催化剂，使系统整体上运行速度更快。
 
-开发人员视图可在 [Accordion：内存压缩的开发人员视图](https://blogs.apache.org/hbase/entry/accordion-developer-view-of-in)中找到。
+可在以下链接中了解开发者视图[Accordion: Developer View of In-Memory Compaction](https://blogs.apache.org/hbase/entry/accordion-developer-view-of-in).
 
-内存压缩在高数据流失时效果最佳;当数据仍在内存中时，可以消除覆盖或过度版本。如果写入都是唯一的，则可能会拖动写入吞吐量（内存中压缩成本 CPU）。我们建议您在部署到生产之前进行测试和比较。
+内存压缩在高数据流应用中效果最佳;当数据仍在内存中时，可以消除重写或过期版本。如果写入都是唯一的，则可能会拖慢写入吞吐量（内存压缩有CPU成本）。我们建议您在部署到生产之前进行测试和比较。
 
-在本节中，我们将介绍如何启用 Accordion 和可用的配置。
+在本节中，我们将介绍如何启用Accordion和可用的配置。
 
-## 78.启用
 
-要启用内存中压缩，请在您希望行为的每个列族上设置 _IN_MEMORY _COMPACTION_ 属性。 _IN_MEMORY _COMPACTION_ 属性可以具有四个值之一。
+## 78\. 启用
 
-*   _ 无 _：无内存压缩。
+要启用内存压缩，则对每个你想要启用内存压缩的列簇设置 _IN_MEMORY_COMPACTION_配置项。_IN\_MEMORY\_COMPACTION_ 配置项的值可以为下面四个中任意一个。
 
-*   _BASIC_ ：基本策略启用刷新并保持刷新管道，直到我们跳过管道最大阈值，然后我们刷新到磁盘。没有内存中的压缩，但可以帮助提高吞吐量，因为数据从挥霍的原生 ConcurrentSkipListMap 数据类型转移到更紧凑（和高效）的数据类型。
+*   _NONE_: 不启用内存压缩.
 
-*   _EAGER_ ：这是 _BASIC_ 政策加上内存压缩的冲洗（很像是对 hfiles 进行的盘上压缩）;在压缩方面，我们应用磁盘规则来消除版本，重复，ttl'd 单元格等。
+*   _BASIC_: 基本策略开启后，会在内存中一直保持一个flush管道，直到我们超过管道最大阈值，然后我们就会flush到磁盘。虽然没有内存压缩操作，但仍然可以帮助提高吞吐，因为数据从空间效率不高的原生ConcurrentSkipListMap数据类型转移到更紧凑（和高效）的数据类型。
 
-*   _ADAPTIVE_ ：自适应压缩适应工作负载。它根据数据中重复单元格的比例应用索引压缩或数据压缩。实验。
+*   _EAGER_: 这是 _BASIC_策略加上对flush操作的内存压缩组合（非常像磁盘上hfile的compaction）；当执行内存压缩时，使用的与磁盘上释放过期版本，冗余数据，超时数据等规则一样。
 
-要在表 _ 萝卜 _ 中的 _info_ 列系列上启用 _BASIC_ ，请禁用该表并将该属性添加到 _info_ 列族，然后重新启用：
+*   _ADAPTIVE_: 对负载进行自适应压缩操作。它会根据数据中重复单元格的比例来判断是否需要执行索引压缩或者数据压缩。
+
+想要在表格 _radish_的 _info_列簇中应用 _BASIC_策略，需要先禁用表，然后给 _info_列簇增加属性，操作如下：
 
 ```
 hbase(main):002:0> disable 'radish'
@@ -43,24 +44,26 @@ COLUMN FAMILIES DESCRIPTION
 1 row(s)
 Took 0.0239 seconds
 hbase(main):005:0> enable 'radish'
-Took 0.7537 seconds 
+Took 0.7537 seconds
 ```
 
-请注意 IN_MEMORY_COMPACTION 属性如何显示为 _METADATA_ 映射的一部分。
+注意 _IN_MEMORY_COMPACTION属性是作为 _METADATA_映射里的一部分。
+
+还有一个全局配置 _hbase.hregion.compacting.memstore.type_，可以在 _hbase-site.xml_文件里设置。可以用这个来设置新创建表的默认策略（在创建列簇存储时，我们首先看列簇配置中 _IN_MEMORY_COMPACTION_配置，如果没有，我们将查询 _hbase.hregion.compacting.memstore.type_的值作为配置值，其默认是 _BASIC_策略）。
 
-还有一个全局配置， _hbase.hregion.compacting.memstore.type_ ，您可以在 _hbase-site.xml_ 文件中设置。使用它来设置创建新表时的默认值（在创建列族存储时，我们首先查看列族配置，查找 _IN_MEMORY _COMPACTION_ 设置，如果没有，我们再咨询 _hbase.hregion.compacting.memstore.type_ 值使用其内容;默认为 _BASIC_ ）。
+默认情况下，新的hbase系统表将会被设置为 _BASIC_内存压缩策略。要另外指定，则在新表创建时，将 _hbase.hregion.compacting.memstore.type_设置为 _NONE_（注意，设置此值后之前创建的系统表不会改变;您将必须更改表以设置内存中属性为 _NONE_。）
 
-默认情况下，新的 hbase 系统表将具有 _BASIC_ 内存中压缩集。为了另外指定，在新的表创建时，将 _hbase.hregion.compacting.memstore.type_ 设置为 _NONE_ （注意，设置此值后创建系统表将不具有追溯效果;您必须更改表格以将内存中属性设置为 _NONE_ ）。
+内存flush发生的条件是通过将配置的Region flush大小（在表描述符中设置或从 _hbase.hregion.memstore.flush.size_ 中读取）除以列簇数，然后乘以 _hbase.memstore.inmemoryflush.threshold.factor_ 来计算，其默认值为0.014。
 
-当内存中的刷新发生时，通过将配置的区域刷新大小（在表描述符中设置或从 _hbase.hregion.memstore.flush.size_ 中读取）除以列族的数量然后相乘来计算 _hbase.memstore.inmemoryflush.threshold.factor_ 。默认值为 0.014。
+管道承载的flush次数会被控制在memstore的大小范围内，当然你也可以设置 _hbase.hregion.compacting.pipeline.segments.limit_ 参数指定一个最大flush次数值，默认值是2。
 
-监视管道所承载的刷新次数，以便符合 memstore 大小调整的范围，但您也可以通过设置 _hbase.hregion.compacting.pipeline.segments.limit 来设置总刷新次数的最大值 _。默认值为 2。
 
-创建列族 Store 时，它会说明哪些 memstore 类型有效。在撰写本文时，有一个老派 _DefaultMemStore_ 填充 _ConcurrentSkipListMap_ ，然后刷新到磁盘或新的 _CompactingMemStore_ ，它是提供这个新功能的实现内存中压缩设施。以下是来自 RegionServer 的日志行，该日志行显示了一个名为 _ 系列 _ 的列族存储配置为使用 _CompactingMemStore_ ：
+创建列簇存储时，需要指定哪种memstore类型。在撰写本文时，有两种memstore类型，分别是旧式的使用 _ConcurrentSkipListMap_ 来存放数据，然后flush到磁盘上的 _DefaultMemStore_ ，新式的提供上述内存压缩机制的 _CompactingMemStore_。下面是一个配置 _family_ 属性为 _CompactingMemStore_ 类型的列簇存储日志行：
 
 ```
 Note how the IN_MEMORY_COMPACTION attribute shows as part of the _METADATA_ map.
-2018-03-30 11:02:24,466 INFO  [Time-limited test] regionserver.HStore(325): Store=family,  memstore type=CompactingMemStore, storagePolicy=HOT, verifyBulkLoads=false, parallelPutCountPrintThreshold=10 
+2018-03-30 11:02:24,466 INFO  [Time-limited test] regionserver.HStore(325): Store=family,  memstore type=CompactingMemStore, storagePolicy=HOT, verifyBulkLoads=false, parallelPutCountPrintThreshold=10
 ```
 
-在 CompactingMemStore 类（ _org.apache.hadoop.hbase.regionserver.CompactingMemStore_ ）上启用 TRACE 级别日志记录，以查看其操作的详细信息。
\ No newline at end of file
+可以为CompactingMemStore类（_org.apache.hadoop.hbase.regionserver.CompactingMemStore_）打开TRACE级别日志来查看运行细节。
+

docs/13.md

 # 同步复制
 
-## 93.背景
+## 93\. 背景
 
-HBase 中的当前[复制](#_cluster_replication)异步。因此，如果主集群崩溃，则从集群可能没有最新数据。如果用户想要强一致性，那么他们就无法切换到从属群集。
+HBase中当前的[复制](#_cluster_replication)是异步的。因此，如果主集群崩溃，则从集群可能没有最新数据。如果用户想要强一致性，那么他们就无法切换到从属集群。
 
-## 94.设计
+## 94\. 设计
 
 请参阅 [HBASE-19064](https://issues.apache.org/jira/browse/HBASE-19064) 上的设计文档
 
-## 95.运行和维护
+## 95\. 运行和维护
 
 Case.1 设置两个同步复制集群
 
 *   在源集群和对等集群中添加同步对等体。
 
-对于源群集：
+对于源群集:
 
 ```
-hbase> add_peer  '1', CLUSTER_KEY => 'lg-hadoop-tst-st01.bj:10010,lg-hadoop-tst-st02.bj:10010,lg-hadoop-tst-st03.bj:10010:/hbase/test-hbase-slave', REMOTE_WAL_DIR=>'hdfs://lg-hadoop-tst-st01.bj:20100/hbase/test-hbase-slave/remoteWALs', TABLE_CFS => {"ycsb-test"=>[]} 
+hbase> add_peer  '1', CLUSTER_KEY => 'lg-hadoop-tst-st01.bj:10010,lg-hadoop-tst-st02.bj:10010,lg-hadoop-tst-st03.bj:10010:/hbase/test-hbase-slave', REMOTE_WAL_DIR=>'hdfs://lg-hadoop-tst-st01.bj:20100/hbase/test-hbase-slave/remoteWALs', TABLE_CFS => {"ycsb-test"=>[]}
 ```
 
-对于对等集群：
+对于对等集群:
 
 ```
-hbase> add_peer  '1', CLUSTER_KEY => 'lg-hadoop-tst-st01.bj:10010,lg-hadoop-tst-st02.bj:10010,lg-hadoop-tst-st03.bj:10010:/hbase/test-hbase', REMOTE_WAL_DIR=>'hdfs://lg-hadoop-tst-st01.bj:20100/hbase/test-hbase/remoteWALs', TABLE_CFS => {"ycsb-test"=>[]} 
+hbase> add_peer  '1', CLUSTER_KEY => 'lg-hadoop-tst-st01.bj:10010,lg-hadoop-tst-st02.bj:10010,lg-hadoop-tst-st03.bj:10010:/hbase/test-hbase', REMOTE_WAL_DIR=>'hdfs://lg-hadoop-tst-st01.bj:20100/hbase/test-hbase/remoteWALs', TABLE_CFS => {"ycsb-test"=>[]}
 ```
 
-> 对于同步复制，当前实现要求源和对等集群具有相同的对等 ID。另一件需要注意的事情是：peer 不支持集群级，命名空间级或 cf-level 复制，现在只支持表级复制。
+> 对于同步复制，当前实现要求源和对等集群具有相同的对等ID。另一件需要注意的事情是：peer不支持集群级，命名空间级或cf-level复制，现在只支持表级复制。
 
-*   将对等集群转换为 STANDBY 状态
+*   将对等集群转换为STANDBY状态
 
 ```
-hbase> transit_peer_sync_replication_state '1', 'STANDBY' 
+hbase> transit_peer_sync_replication_state '1', 'STANDBY'
 ```
 
-*   将源群集转换为 ACTIVE 状态
+*   将源群集转换为ACTIVE状态
 
 ```
-hbase> transit_peer_sync_replication_state '1', 'ACTIVE' 
+hbase> transit_peer_sync_replication_state '1', 'ACTIVE'
 ```
 
-现在，已成功设置同步复制。 HBase 客户端只能请求源集群，如果请求到对等集群，现在处于 STANDBY 状态的对等集群将拒绝读/写请求。
+现在，已成功设置同步复制。 HBase客户端只能请求源集群，如果请求到对等集群，现在处于STANDBY状态的对等集群将拒绝读/写请求。
 
 Case.2 备用集群崩溃时的操作方法
 
-如果备用群集已崩溃，则无法为活动群集写入远程 WAL。因此我们需要将源集群转移到 DOWNGRANDE_ACTIVE 状态，这意味着源集群将不再编写任何远程 WAL，但正常复制（异步复制）仍然可以正常工作，它会对新写入的 WAL 进行排队，但复制块直到对等集群回来。
+如果备用群集已崩溃，则无法为活动群集写入远程WAL。因此我们需要将源集群转移为DOWNGRANDE_ACTIVE状态，这意味着源集群将不再同步任何远程WAL，但正常复制（异步复制）仍然可以正常工作，它会对新写入的WAL进行排队，但复制会阻塞直到对等集群恢复。
 
 ```
-hbase> transit_peer_sync_replication_state '1', 'DOWNGRADE_ACTIVE' 
+hbase> transit_peer_sync_replication_state '1', 'DOWNGRADE_ACTIVE'
 ```
 
-一旦对等集群返回，我们就可以将源集群转移到 ACTIVE，以确保复制是同步的。
+一旦对等集群恢复，我们就可以将源集群转移为ACTIVE，以确保复制是同步的。
 
 ```
-hbase> transit_peer_sync_replication_state '1', 'ACTIVE' 
+hbase> transit_peer_sync_replication_state '1', 'ACTIVE'
 ```
 
 Case.3 当活动集群崩溃时如何操作
 
-如果活动集群已崩溃（现在可能无法访问），那么让我们将备用集群转移到 DOWNGRANDE_ACTIVE 状态，之后，我们应该将所有请求从客户端重定向到 DOWNGRADE_ACTIVE 集群。
+如果活动集群已崩溃（现在可能无法访问），那么我们需要将备用集群转移为DOWNGRANDE_ACTIVE状态，之后，将客户端的所有请求重定向到DOWNGRADE_ACTIVE集群。
 
 ```
-hbase> transit_peer_sync_replication_state '1', 'DOWNGRADE_ACTIVE' 
+hbase> transit_peer_sync_replication_state '1', 'DOWNGRADE_ACTIVE'
 ```
 
-如果崩溃的集群再次返回，我们只需要将其直接转移到 STANDBY。否则，如果将群集传输到 DOWNGRADE_ACTIVE，则原始 ACTIVE 群集可能具有与当前 ACTIVE 群集相比的冗余数据。因为我们设计同时编写源群集 WAL 和远程群集 WAL，所以源群集 WALs 可能比远程群集具有更多数据，这导致数据不一致。将 ACTIVE 转换为 STANDBY 的过程没有问题，因为我们将跳过重放原始的 WAL。
+如果崩溃的集群再次恢复，我们只需要将其直接转移为STANDBY状态。否则，如果将集群转移为DOWNGRADE_ACTIVE状态，则原始ACTIVE集群可能具有比当前ACTIVE集群更多的冗余数据。因为我们的设计是会将源集群WAL和远程集群WAL一起写，所以源集群WALs可能比远程集群具有更多数据，这会导致数据不一致。将ACTIVE转换为STANDBY状态是没有问题的，因为我们将跳过重放原始的WAL。
 
 ```
-hbase> transit_peer_sync_replication_state '1', 'STANDBY' 
+hbase> transit_peer_sync_replication_state '1', 'STANDBY'
 ```
 
-之后，我们现在可以将 DOWNGRADE_ACTIVE 集群提升为 ACTIVE，以确保复制是同步的。
+之后，我们可以将DOWNGRADE_ACTIVE集群提升为ACTIVE，以确保复制是同步的。
 
 ```
-hbase> transit_peer_sync_replication_state '1', 'ACTIVE' 
-```
\ No newline at end of file
+hbase> transit_peer_sync_replication_state '1', 'ACTIVE'
+```
+