HBase的压缩算法或者编码类型的选择依赖于我们数据本身的特点,选择一个不合适的算法类型,可能会占用更多的空间,并且对我们系统本身性能有影响。

通常,我们需要在更小的空间占比与更快的压缩/解压缩速度之间权衡,可以参考下面的几点建议:

  • 如果我们有很长的keys(与values相比而言)或者很多列,可以使用prefix编码器。这里推荐FAST_DIFF,因为Prefix Tree编码还需要更多的测试。
  • 如果values非常大(没有经过预压缩,比如图像),可以使用数据块压缩(data block compressor)。
  • 对于冷数据(cold data),即那些访问比较少的数据,GZIP压缩相比Snappy和LZO占用更多的CPU资源,但是提供更高的压缩比。
  • 对于热数据(hot data),即那些访问很频繁的数据,Snappy和LZO相比GZIP压缩占用更少的CPU资源,但是压缩比较高。
  • 在大多数场景下,启用Snappy或者LZO压缩是一个好的选择,因为这可以占用较低的性能负载并且提供更少的空间占用。
  • 在2011年之前不支持Google Snappy,LZO是默认的,但是,Snappy提供与LZO相似的性能,并且已经被证明有更好的表现。

翻译自:http://hbase.apache.org/book.html#compression(Which Compressor or Data Block Encoder To Use)

下面是比较官方一些的压缩算法统计对比:

Comparison between compression algorithms

Algorithm % remaining Encoding Decoding
GZIP 13.4% 21 MB/s 118 MB/s
LZO 20.5% 135 MB/s 410 MB/s
Snappy 22.2% 172 MB/s 409 MB/s
HBase如何选择压缩算法
Tagged on:     

发表评论

电子邮件地址不会被公开。 必填项已用*标注

This site uses Akismet to reduce spam. Learn how your comment data is processed.