测试环境:

Linux master 2.6.18-348.12.1.el5 #1 SMP Wed Jul 10 05:28:41 EDT 2013 x86_64 x86_64 x86_64 GNU/Linux

hadoop-1.0.3

hbase-0.94.2

Oracle JRockit(R) (build R28.1.5-20-146757-1.6.0_29-20111004-1750-linux-x86_64, compiled mode)

测试需求,就是将hbase里的表,按照不同的压缩方式(因不支持bz,所以没有bz的测试结果),进行保存,以下是对比结果:

原始数据大小 gz snappy lzo
938.15MB 174.37MB 253.35MB 563.09MB

压缩率:

gz snappy lzo
81.41% 72.99% 39.98%

总得来说,gz效果最好。snappy和lzo都不太适合在hbase里用压缩

后面进行了一个比较特殊的测试。就是原始数据有43个columns,如果了解其存储原理的话,那么占用的空间是很大的。

我采用了合并这个43个column变成一个(注:这里考虑合并是因为有业务的需要)

根据以上的测试结果,我将测试两种场景:

1、原始数据大小与合并column后数据量的大小

2、原始数据大小与合并column并增加压缩的大小(采用gz压缩方式)

原始数据大小 合并字段后数据大小 合并字段并压缩后数据大小
938.15MB 203.3MB 65.6MB

压缩率:

合并字段 合并字段并压缩
78.33% 93.01%

通过一系列的测试发现,采用合并字段并压缩,这样达到的压缩效率是非常高的。而且也非常适合我们的业务使用场景。

所以最终的方案我们也采用了合并字段并压缩的方式,来对hbase进行相关优化处理。

此测试主要集中在如何节约磁盘空间考虑,并没有对读/写进行测试。

GitHub 加速计划 / li / linux-dash
10.39 K
1.2 K
下载
A beautiful web dashboard for Linux
最近提交(Master分支:2 个月前 )
186a802e added ecosystem file for PM2 4 年前
5def40a3 Add host customization support for the NodeJS version 4 年前
Logo

旨在为数千万中国开发者提供一个无缝且高效的云端环境,以支持学习、使用和贡献开源项目。

更多推荐