HBase性能再度分析

前面的HBase性能深度分析，提出了一个猜想，是关于调整“hbase.hstore.compactionThreshold”值的假设。猜想的内容为：如果改变该值为n，那么耗时图形会在每两个高峰之间出现等间隔的(n-2)次较低的波峰，并且高峰将会更加突出，超过上述值较低时的波峰高度。

为了证明这个猜想，我将“hbase.hstore.compactionThreshold”值调整为5，并重新做了数据插入测试，一段时间后，得到下面所示的性能图形（Y轴还是耗时，X轴为插入次数，Sandy建议这里的Y轴应该改为插入速度，但是由于前次已经使用了耗时为Y轴，因此改变Y轴显示的工作只能放到下次测试中了）：

请注意，和前次的图形进行比较，两图的Y轴比例尺是不同的，前次Y轴最大为30秒，本次最大为50秒。可见假设中声称低峰会在两个高峰之间等间隔的出现3次的现象的确是成立的。当高峰出现第5次以后，可以从上图看到代表耗时的点的高峰段已经达到了25秒以上，而对于前次来说，高峰段基本上处于20秒左右，由此可以认为Compaction的压力的确是增加了。现在换一个角度来分析这一情况。我为前次耗时图制作了一张数据分布图，与本次的数据分布图进行比较。

前次数据分布图：

本次数据分布图：

虽说本次测试经历的时间不如前次，但是基于统计学的观点，分布图的外形是不会受样本容量大小影响的。因此两图可以进行外观上的比较。这两张分布图都是典型的正态分布图，但又不是标准正态分布，原因是在于，波峰段的数据影响了正态分布的标准性，表现之一在于右侧的长尾，表现之二在于众数所在位置右移，以至于左侧凸显了一个小波峰。

计算本次分布图与前次分布图中位于右侧长尾部分的数据的标准差（计算公式：

【1】），我们可以得到前次右侧标准差为4.10390692438，而本次右侧标准差为7.12068861446，说明高峰段影响的数据右偏更为严重了。从外观上表现在于右侧长尾在整图比例尺中的宽度和高度要大于前次分布图中的右侧长尾。这说明Compaction的压力增大了。推导到这里，我发现右侧标准差与Compaction的压力之间是存在显著关系的，今后对Compaction压力增减的估算，貌似可以转换为对右侧标准差的计算。压力增加的比率是否等于标准差的比值呢？这里先做一个标记，等我后面有空再仔细的思考一下这个问题。现在假设中的说法“高峰将会更加突出，超过上述值较低时的波峰高度”，应该算是被证明了。

以上论证结束之后，按照惯例还是要提出一些假设和推断。

HBase即将release的0.90版对Compaction和Split机制作了调整，将split过程提到Compaction之前，也就是说，当region目录下，HFiles数目超过“hbase.hstore.compactionThreshold”指定值之后，Regionserver会首先计算一下Compaction之后的文件大小是否会超过“hbase.hregion.max.filesize”确定的Split上限大小，如果超过了，那么HFiles会首先被切分，然后才会将切分好的文件转移到新的region中Compaction。这样将大大减小Compaction的压力，由此可以推断，HBase的性能调优必然与“hbase.hstore.compactionThreshold”和“hbase.hregion.max.filesize”这两个值的大小息息相关。理论上，可以将某次设定值的实验中获得的数据代入到一个特定公式中，上述两值作为该公式的自变量，其应变量，即性能数据，将可以轻易的计算出来。

是否真的如此，且待0.90的发布，至下回再分解。

参考：

【1】偏态分布资料均数两侧标准差计算方法的探讨，何发勤，蒋威，罗静

来自：HBase性能再度分析

hbase的更新对表的读取影响很大，可以用什么方式改善它呢？

其实“Split”过程对hbase的性能影响还算比较小，对于“Compaction”则影响巨大，我的想法是尽量增加数据插入的不均匀性，使得大规模Compaction尽量不要集中发生。例如假设有两张bigtable来服务于不同的应用，两张表交替进行大规模的数据插入，那么Compaction过程就可以交替进行。
还有一种办法，Compaction过程可以由hbase的api或者hbase shell命令来显式的强制执行，那么我们在实际环境中，不妨通过程序错开各region的compaction时机，或者尽量将compaction放到空闲时间强制执行。
一般说来，实际应用中，由于rowkey本身就可能不是随机分布的，因此Compaction的发生也不会如此集中。
这里顺便预告一下我下一步的一个猜想，是关于hadoop+hbase各模块分布对性能的影响。