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