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

时间:2022-08-27 15:07:25

转载:http://blog.csdn.net/kalaamong/article/details/7290192

接上文啊:

测试机性能
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。

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

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

第二组:(配置项修改)

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

<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%)。

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

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

第三组:(代码修改)

最后来治标治本吧。后面的实验中配置参数与上一组相同,同时服务端修改代码,为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。

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

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

第四组:(代码修改加压缩)

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

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

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

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

第五组:(第五组大家自己研究吧)

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

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

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

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