Hypertable初体验之性能测试

        为了最大程度上测试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有极大的区别。