HBase(Hadoop Database)是一个高可靠性、高性能、面向列、可伸缩的分布式存储系统,利用HBase技术可在廉价PC Server上搭建起大规模结构化存储集群,Hypertable则是搜索引擎公司Zvents以Google发布的BigTable为基础,推出的一款开源分布式数据存储系统。这两类分布式存储系统通常被用于新兴互联网架构或者云计算、云存储架构中。
两者都是模仿谷歌BigTable数据库设计而成,主要区别是Hypertable依靠C++语言实现,而HBase则基于Java编写。我们最近做了一项实验,比较0.9.5.5版本的Hypertable和0.90.4版本的HBase运行zookeeper时的性能,结论是:Hypertable在吞吐量测试中的成绩是HBase的2倍。而且HBase在410亿和1670亿数据测试中存在数据溢出问题。不过在随机读取测试中这两个系统的测试结果基本相同。
测试环境介绍
本次测试的环境是通过千兆网络连在一起的16台服务器。
本机的配置是:
OS:CentOS 6.1
CPU:两颗AMD C32六核心2.1GHz
内存:24GB 1333 MHz DDR3
磁盘:四块 西部数据RE4-GP WD2002FYPS(2TB SATA )
服务器test 01上运行分布式文件系统、分布式存储系统Hypertable和HBase的主节点,在test04-test15上运行数据节点和机器配置的有效RAM, ZooKeeper和Hyperspace的副本运行在test01-test03上,测试中表配置使用快速压缩,并且使用Bloom过滤器按一定规则进行过滤。我们查阅了介绍如何设置并完成此次测试的整个Hypertable VS HBase II测试报告,尽可能调整HBase实现最佳性能和配置细节。
随机写入测试
在随机写入测试中,Hypertable和HBase分别测试写入4个不同的5TB数据。使用值大小分别为10000、1000、100和10。其中关键一步是将20字节作为随机写入的零填充来格式化。
以下图表为测试结果
|
|
从图中我们可以看出HBase在410亿以及1670亿的关键测试中由于HBase的RegionServers并发模式失败而写入异常。无论如何配置,当RegionServer产生垃圾数据的速度超过Java垃圾收集器回收垃圾数据的速度就会发生上面的异常情况。虽然我们可以设计一个垃圾数据回收计划来克服这些问题,不过这样的话会在运行时给性能带来沉重的代价。
随机读取测试
此次测试利用一组随机读取请求通过查询吞吐量的方法来测试。每个系统跑两个不同的测试,一个测试采用Zipfian分布,另一个测试采用均匀分布。同时,对插入的键大小固定为20字节,值大小则固定为1KB。键取值范围来自ASCII中的整数,每次查询测试返回一对键值。在每个系统上分别跑两次测试,一次加载5TB的数据,另一次加载0.5TB的数据。这样能够测量出每个系统下内存到磁盘性能系数的高低。在加载5TB测试中共载入4,901,960,784的键值,而加载0.5TB测试中共载入490,196,078的键值。测试客户端跑了128个进程(总共为512进程),每个进程都可以在任何时间得到512次查询,这意味着每个测试都发出1亿次查询。
Zipfian分布式环境测试
在这个测试中,我们布置了一个Zipfian分布环境,发现当指数的值为0.8时,20%的键利用了80%的时间来实现。所以我们在测试中将Hypertable查询缓存配置为2GB,同时为了使HBase保持良好性能,将HBase的block cache和memstore限制使用默认值。测试结果见下图
|
导致性能差异主要原因是Hypertable提供了查询缓存。当然用HBase也可以实现查询缓存,但它是HBase的子系统而且这个子系统生成了很多垃圾。虽然用HBase查询缓存会提高HBase测试性能,但同时也带来了一些弊端,尤其是在超大规模写入以及超大单元计算的混合工作负载下。
在测试中出现了一个有趣的现象,在我们增加了两个系统缓存块的大小后对性能产生了不利影响。事实上系统内有大量闲置CPU计算能力以维持减轻压力需求,通过消除高速缓存块来存储未压缩块,同时依靠操作系统的文件缓存可获取更好的性能,因为这样可以在内存中容纳更多的数据集。
均匀分布测试环境
查询用的键都遵循均匀分布的原则,下图为测试结果
|
在均匀分布测试中HBase的性能接近Hypertable,这应该是磁盘IO瓶颈以及测试中产生一些垃圾数据导致。
结论
在过去5年,Hypertable社区一直在致力于努力完善产品。得到这些结果我们很开心,我们可以继续进行效能改善项目,目标是将Hypertable构建成为大数据领域高性能、高扩展性的数据库解决方案。