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

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

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

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

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

注：来自《 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 压缩算法特点的概括比较，以及一些实践上的方法。如有不对之处，欢迎大家指正，讨论。