为了最大程度上测试ht的性能,简单的选择了随机的写入测试,主要是采用了random_write_test的测试程序。该程序主要是随机的向一个cf中写入定长的数据,默认的cf写入数据是1K字节,rowkey约为24字节,具体可以看代码,采用自动mutor的方式来提交数据。( 为了进行一些基本的测试,重新拿源码包编译了一次,耗费了几乎两天的时间,遇见需要增加各种版本的依赖库的要求,貌似都还好说,唯一记得的boost库的版本要大于1.42,需要提供uuid特性,否则无法编译,另外cmake的检查脚本有各种bug,鄙人直接修改了几个文件,幸好还懂点cmake。可能你会问为什么不直接使用二进制包中的测试程序来修改再编译,这个就是hypertable的不成熟了,虽然有源码,有库文件,makefile也没有问题,但是在连接静态库的时候,会有各种问题,如果你好奇的话,可以试试。还好,源码包编译出来的静态库都没有这些问题,不枉费哥花了快两天的时间,不过,开发包只有静态的,没有动态的,所以,所以,简单的一个测试程序都有几百M,真是坑爹,看来这些急需完善)
为了对比性能,选择了几组对比的测试:一,自动提交的mutor和手动提交的mutor;二,自动mutor,写入的cf长度为1K字节对比2K字节;三,采用自动mutor方式提交数据,写入cf为2K字节,在两台机器上,分别写入200G数据。
测试的机器为8台rangeserver,为sas盘,16G内存,千兆网卡,hypertable为默认配置,region分裂的limit为256M,内存使用本机的60%
一,自动的提交对比手动提交,很明显,自动的mutor占据了优势:在1K的cf长度下,写入总过2G数据的情况下,自动的提交的速度为20M/s,而手动的提交速度为500字节每秒,相差了近40倍,这个和hbase自动flush是一个道理。显示出了批量提交时的高效传输。
二,采用自动mutor,写入cf长度分别为1K和2K,在单个机器上执行random_write_test,写入20G数据,速度分别为20M/s,和32M/s。
三,在两个机器上执行测试程序,采用自动提交,写入的cf长度为2K字节,写入数据量各为200G,总计400G。最终,统计得到的写入速度是单个测试程序为30M/S,总共60M/S的有效写入速度,相对来说,还是比较给力的,估计应该是强于hbase。但是,测试400G数据的过程中,从监控系统上可以看到有一定的性能的波动:
在插入了近70G数据之后,发生了较大的性能波动,写入速度从100M/s回落到了60M/S。很明显,每台rangserver可用内存为16×0.6G左右,8台共计16×0.6×8 = 75G内存,在除去其他数据结构使用后,留给插入数据的应该是70G,在内存写满后,应该是进行flush,压力主要在hdfs上。看来是主要瓶颈在hdfs上。
不过,从性能监控图上看,ht对region的split几乎并不敏感,中间并未因为split造成性能波动。从社区的讨论上看,貌似ht采用了较为聪明的softlimit的方式来控制split,避免像hbase那样的性能因为split而明显波动。所以,从另外一方面说,在建表的时候,ht根本不需要预先分片这样的优化措施,这个和hbase有极大的区别。