HBase——查询延迟的时间分布，hbase延迟分布

查询时间

对于HBase的查询而言，大体时间分为

• zookeeper检查时间
• WAL Split时间
• Region重新分布时间
• WAL Replay时间

zookeeper检查时间

 影响要素：

       zookeeper跟regionserver之间session的timeout时间

 关联设置：

     1. zookeeper.session.timeout     默认值：90000ms

     2. hbase.zookeeper.property.tickTime    默认值：2000ms

备考：

    范围：tickTime ×2～tickTime ×20

     1 timeout＜tickTime ×2的场合 ，tickTime ×2

     2. timeout>tickTime ×20的场合，tickTime ×20

WALSplit

影响要素：

  1. WAL的数据量

       关联设置：

           1. hbase.hregion.memstore.flush.size  默认值：134217728bytes

           2. hbase.regionserver.global.memstore.size.lower.limit 默认值：none(95%)

  2. 处理线程数

        管理设置：hbase.regionserver.hlog.splitlog.writer.threads   默认：3

  3. Region Server数

  4.宕掉的region数

Region重新分布时间

影响要素：

  1. Region Server数

  2.宕掉的region数

WAL Replay时间

影响要素：

  1. WAL 的数据量

        关联设置：

           1. hbase.hregion.memstore.flush.size  默认值：134217728bytes

           2. hbase.regionserver.global.memstore.size.lower.limit  默认值：none(95%)

  2. Region Server数

  3.宕掉的region数

      以上就是整个延迟所涉及到的各个时间分布。从实验测试拿到的log数据进行初步分析来看，宕机的region移动前，数据花费的时间比较多，约占据整个花费时间的一半多。更详细的时间分布，由于当时分析的重点不在此处，没有细究，有兴趣的可以调查一下，大家共勉。

本次测试时，kill 掉regionserver的进程后，测试scan 1000行数据时花费的时间。且这1000行数据就是分布在被kill掉的regionserver上。

具体信息如下所示：

1.正常响应时间

+------------------+----------------+----------------+
|  regionserver数  | 3个regionserver| 2个regionserver|
+------------------+----------------+----------------+
|   平均响应时间   |    0.768s      |      0.737s    |
+------------------+----------------+----------------+

2. region再分布中延迟响应时间

+------------------+---------------------------------+
|  regionserver数  | 3个regionserver->2个regionserver|
+------------------+---------------------------------+
|   延迟响应时间   |              9.542s             |
+------------------+---------------------------------+