HBase写入性能及改造——multi-thread flush and compaction(续：详细测试数据)

接上文啊：

测试机性能

CPU	16* Intel(R) Xeon(R) CPU E5620 @ 2.40GHz
MEMORY	48GB
DISK	12*SATA 2TB
NET	4*1Gb Ethernet

测试数据:

类型	国内某视频网站近半年用户访问日志
结构	一行九列，包括用户访问页，关键词及其它用户信息。对应HBase一个family下9个column，一行120到180字节
数据量	每次测试写入10亿条数据，原始数据约110GB，写到HBase中一张不加压缩的表里HDFS中单副本约480GB （dus结果）

集群结构

RegionServer	1个 hostname: data2
DataNode	5个hostname: data12~data16

这样设设计的集群结构，主要目的就是要压测Region Server。以下所有测试客户端put关HLog，服务端不split。

第一组：（原始情况）

这是最初HBase的情况，没有对服务端代码做修改，在配置参数上稍稍改动了类似于MemStore up water level,low water level,以及handler数目和HFile的最大Size值。可以看出虽然是压测，HBase所有地方都很闲，内部的情况是就Multi写入数据了之后MemStore大了等flush，flush的store file多了就等compact。各种等也就各种闲。

最后写入10亿行数据用时6小时48分。整个表在HDFS dus出的大小约440GB。





第二组：（配置项修改）

下面的图是继上面情况之后修改了

<property>

<name>hbase.hstore.blockingStoreFiles</name>

<value>2000</value>

</property>

把block flush的storefile数从默认的7改到了2000，已经不让split了，还不许storefile数多一点，太没人性了。此时前段时间写入的性能有些改善，但毕竟还是单线程的flush和compact治标不治本。

最后写入10亿行数据用时5小时54分，比上一组实验缩短了1个小时。整个表在HDFS dus出的大小约480GB，原因应当是flush被阻塞的次数减少，flush得更频繁了，写入流量也稍增，但没来得及compact的store file更多，所以整个表大了40G( 约9%)。





第三组：（代码修改）

最后来治标治本吧。后面的实验中配置参数与上一组相同，同时服务端修改代码，为flush和compact添加了线程池。并新加入两个配置项：

25 <property>

26 <name>hbase.hstore.flush.thread</name>

27 <value>20</value>

28 </property>

29 <property>

30 <name>hbase.hstore.compaction.thread</name>

31 <value>15</value>

32 </property>

再看压测情况CPU基本满载。唉这才是压测啊！！

如此这般下来写入10亿行数据用时2小时58分，不到第一组一半的时间。表大小约410GB

由于compact做得及时，表大小比第一组小30GB，比第二组小70GB。





第四组：（代码修改加压缩）

接着按第三组的情况加上GZ的软压缩（为什么挑GZ请参第五组测试），这组估计CPU都要冒烟了。

写入10亿行数据耗时3小时5分，比上一组多了7分钟。但表的size为71GB !差不多是上一组的六分之一，尽然压缩到了原数据的17%大小。





第五组：（第五组大家自己研究吧）

这一组最强悍，采用了一些特殊的硬件改了改HDFS，HBase的修改与上两组相同。

写入10亿行数据耗时2小时24分钟。差不多是第一组时间的1/3。文件size为111GB，压到了第一组的1/4。且CPU也没到冒烟的状态，应当还能加压。关于这个组今后还将有更详细的测试结果放出。现在先不详细介绍了。