GZIP、LZO、Zippy Snappy压缩算法应用场景小结

这是我一个交流群里的群主共享的,放在这里是为了让自己备忘,当然,也希望能对需要的朋友有所帮助,感谢这位群主 @㊣『锋』㊣ 

我这里还有一篇:zip4j加密压缩、解压缩文件、文件夹



GZIP、LZO、Zippy Snappy压缩算法应用场景小结

GZIP 、 LZO 、 Zippy/Snappy 是常用的几种压缩算法,各自有其特点,因此适用的应用场景也不尽相同。这里结合相关工程实践的情
况,做一次小结。
压缩算法的比较
以下是 Google 几年前发布的一组测试数据(数据有些老了,有人近期做过测试的话希望能共享出来):

GZIP、LZO、Zippy Snappy压缩算法应用场景小结_第1张图片

注:来自《 HBase: The Definitive Guide 》
其中:
1 ) GZIP 的压缩率最高,但是其实 CPU 密集型的,对 CPU 的消耗比其他算法要多,压缩和解压速度也慢;
2 ) LZO 的压缩率居中,比 GZIP 要低一些,但是压缩和解压速度明显要比 GZIP 快很多,其中解压速度快的更多;
3 ) Zippy/Snappy 的压缩率最低,而压缩和解压速度要稍微比 LZO 要快一些。

BigTable 和 HBase 中压缩算法的选择
BigTable 中采用的是 Zippy 算法,目标是达到尽可能快的压缩和解压速度,同时减少对 CPU 的消耗。
HBase 中,在 Snappy 发布之前( Google 2011 年对外发布 Snappy ),采用的 LZO 算法,目标和 BigTable 类似;在 Snappy 发布之后,
建议采用 Snappy 算法(参考《 HBase: The Definitive Guide 》),具体可以根据实际情况对 LZO 和 Snappy 做过更详细的对比测试后
再做选择。
实际项目中的实践经验
项目中使用 clearspring 公司开源的基数估计的概率算法: stream-lib ,用于解决去重计算问题,如 UV 计算等,它的特点在于:
1 )一个 UV 的计算,可以限制在一个固定大小的位图空间内完成(不同大小,对应不同的误差率),如 8K , 64K ;
2 )不同的位图可以进行合并操作,得到合并后的 UV 。
当系统中维护的位图越多的时候,不管是在内存中,还是在存储系统( MySQL 、 HBase 等)中,都会占用相当大的存储空间。因此,需
要考虑采取合适的算法来压缩位图。这里分为以下两类情况:
1 )当位图在内存中时,此时压缩算法的选择,必须有尽可能快的压缩和解压速度,同时不能消耗过多 CPU 资源,因此,适合使用 LZO 或
Snappy 这样的压缩算法,做到快速的压缩和解压;
2 )当位图存储到 DB 中时,更关注的是存储空间的节省,要有尽可能高的压缩率,因此,适合使用 GZIP 这样的压缩算法,同时在从内存
Dump 到 DB 的过程也可以减少网络 IO 的传输开销。
总结的话
以上是对 GZIP 、 LZO 、 Zippy/Snappy 压缩算法特点的概括比较,以及一些实践上的方法。如有不对之处,欢迎大家指正,讨论。

你可能感兴趣的:(java)