导读：众所周知，2006年Google公布了自己的BigTable论文，作为Google继GFS和MapReduce两项创新之后的又一项创新，其在设计用来针对海量数据处理情形下的管理结构型数据方面具有着巨大的技术优势。而Hypertable和HBase是最知名的两款基于BigTable为蓝本设计的数据库，他们的不同之处在于Hypertable基于C++实现，而HBase则基于Java。两种数据库的性能也一直是人们争论的热点话题。在最近的一次性能测试中Hypertable在吞吐率测试中以2倍的性能优势完全压倒HBase。
近日，Hypertable和HBase进行了类似随机读取统一的测试， 结果表明Hypertable在吞吐量测试中以2倍的性能优势压倒HBase。HBase在410亿和1670亿的数据插入测试中不堪重负（垃圾数据收集）。在此次测试中Hypertable选用了0.9.5.5版，而HBase版本为0.90.4（CDH3u2运行于Zookeeper）。
Hypertable高可用改进架构示意图
| Hypertable系统主要包括Hyperspace、Master和Range Server三大组件。Hyperspace是一个锁服务，地位相当于Google的Chubby，主要用于同步、检测节点是否发生故障和存放顶层位置信息；Master主要用于完成任务分配，未来会有负载均衡以及灾后重建（Range Server失效后自动恢复服务）等其他作用；Range Server是Hypertable的实际工作者，主要负责对一个Range中的数据提供服务，此外它还肩负起灾后重建的责任，即重放本地日志恢复自身故障前状态；另外，还有访问Hypertable的客户端Client等组件。 |
Hypertable和HBase都是开源的可扩展的数据库产品，它们的设计蓝本同时基于Google BigTable。两者的主要区别是Hypertable依靠C++语言实现，而HBase则基于Java编写。 本次测试的环境为16台服务器，这16台服务器通过千兆网络连接在一起。
测试环境如下
操作系统：CentOS 6.1
CPU：2X AMD C32 Six Core Model 4170 HE 2.1Ghz
内存：24GB 1333MHz DDR3
硬盘：4X 2TB SATA Western Digital RE4-GP WD2002FYPS
Hypertable和HBase在HDFS的NameNode运行在1号测试机之上。而DataNodes则运行在4号测试机到15测试机之上。与此同时RangeServer和RegionServers运行在同一组计算机之中，并且配置使之可用所有的内存资源。三个Zookeeper和Hyperspace副本运行在1号测试机在3号测试机。在测试中，表被配置使用Snappy压缩，同时使用Bloom filters加载Row Key。
在随机写入测试中，Hypertable和HBase分别测试写入4个不同的5TB数据。 使用的值大小分别为10000、1000、100和10。同时固定为20字节并将范围内的随机整数（随机值的数据段取自英文Wiki百科XML页面的200MB样本）格式化为零填充（0..number_of_keys_submitted*10）。
以下图表为测试结果
下表提供了详细的性能测试结果
从图中我们可以看出HBase在410亿以及1670亿的键测试中由于HBase的RegionServers并发模式失败而抛出异常。无论如何配置当RegionServer产生无用数据的速度超过Java垃圾收集器就会发生如上的故障。为了解决这一问题，建造新的垃圾回收计划以克服问题，但这也会为运行时的性能带来沉重的代价。
在2005年的OOPSLA会议上Matthew Hertz和Emery D. Berger公布了《Garbage Collection vs. Explicit Memory Management》的研究文档，这为相关研究提供坚实的信念。
此次测试主要利用一组随机读取请求测试查询吞吐量。每个系统运行两个测试，一个测试采用Zipfian分布，另一个测试采用均匀分布。同时插入的键/值固定了大小，键采用固定的20字节，值的大小则固定1KB。键取值范围来自ASCII中的整数，每次查询测试返回一对键值。在每个系统上分别做两次测试。一个加载5TB的数据，而另一个加载0.5TB数据。这使得实验能够测量每个系统内存到磁盘性能系数的高低。在加载5TB测试中共载入4,901,960,784的键值，而加载0.5TB测试中共载入490,196,078的键值。测试客户端运行128个进程（总共为512进程），同时在测试的整个过程中都保持最大的512查询。这意味着每个测试共发出1亿次查询。
在测试中将Hypertable查询缓存配置为2GB，同时为了HBase保持良好的性能，将HBase的block cache和memstore限制使用默认值。测试结果见下图
下表提供了详细的性能测试结果
导致性能的差异主要是因为Hypertable提供了查询缓存，HBase也可以实现查询缓存，但它是HBase的子系统。这个子系统生成了很多垃圾。虽然这会提高HBase的性能，但同时也带来了一些弊端。尤其是在超大规模写入以及超大的单元计算的混合工作负载。
在测试中出现了一个有趣的现象，当我们增加两个系统的缓存块的大小后对性能产生了不利的影响。事实上系统内有大量闲置CPU计算能力以维持减轻压力的需求。通过消除高速缓存块用于存储未压缩的块，同时依靠操作系统的文件缓存存储压缩的块可获取更好的性能，因为更多的数据集可以容纳在内存之中。
查询的键集遵循均匀分布的原则，下图为测试结果
下表提供了详细的性能测试结果
在均匀分布测试中HBase的性能接近Hypertable，这应该是磁盘IO瓶颈导致的，同时在测试期间产生一些垃圾数据。
在过去5年，Hypertable社区一直在致力于努力完善产品。旨在将Hypertable构建成为大数据领域高性能、高扩展性数据库解决方案。