zoukankan      html  css  js  c++  java
  • HBase写入性能及改造——multi-thread flush and compaction(续:详细测试数据)[转]

    转载: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。

    第二组:(配置项修改)

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

    <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也没到冒烟的状态,应当还能加压。关于这个组今后还将有更详细的测试结果放出。现在先不详细介绍了。

  • 相关阅读:
    再谈TextField
    IOS-TextField知多少
    leftBarButtonItems
    LeftBarButtonItems,定制导航栏返回按钮
    Apple Mach-O Linker (id) Error "_OBJC_CLASS...错误解决办法 Apple Mach-O Linker (id) Error "_OBJC_CLASS...错误解决办法
    Unrecognized Selector Sent to Instance问题之诱敌深入关门打狗解决办法
    UNRECOGNIZED SELECTOR SENT TO INSTANCE 问题快速定位的方法
    Present ViewController,模态详解
    UILABEL AUTOLAYOUT自动换行 版本区别
    iOS自动布局解决警告Automatic Preferred Max Layout Width is not available on iOS versions prior to 8.0
  • 原文地址:https://www.cnblogs.com/seaspring/p/7117842.html
Copyright © 2011-2022 走看看