hbase测试压缩效果报告
linux-dash
A beautiful web dashboard for Linux
项目地址:https://gitcode.com/gh_mirrors/li/linux-dash
免费下载资源
·
测试环境:
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 年前
更多推荐
已为社区贡献15条内容
所有评论(0)