项目中遇到的压缩/解压缩需求应该是很多的,比如典型的考虑网络传输延时而对数据进行压缩传输,又或者其他各种省空间存储需求等。这次同样是遇到了类似需求,在做一个爬虫时,因为抓取项目还未确定,所以考虑将整个html页面压缩存储于数据库,于是又是各种google,最后不出意外的google到了google家的Snappy :-)
简介
Snappy:Google开发的一个非常流行的压缩算法,它旨在提供速度与压缩比都相对较优的压缩算法。虽然只是一个数据压缩库,它却被Google用于许多内部项目,其中就包括BigTable,MapReduce和RPC。Google宣称它在这个库本身及其算法做了数据处理速度上的优化,作为代价,并没有考虑输出大小以及和其他类似工具的兼容性问题。Snappy特地为64位x86处理器做了优化,在单个Intel Core i7处理器内核上能够达到至少每秒250MB的压缩速率和每秒500MB的解压速率。
总结copy过来的这一堆:Snappy不是压缩率最高的,但是速度和性能表现很优秀,over!
使用
其实可用的压缩算法很多,而且压缩率与速度比Snappy高的也大有人在,典型的如:lz4,常用的压缩解压缩算法对比参见这儿。
至于我为什么选择了Snappy,就两个字:简单。哈哈!!
相比已经很简单的lz4,Snappy的API更简单,而且关键在解压缩环节,Snappy使用直观,不需要考虑压缩包大小或是压缩前大小,在某些环节更省心一些,当然细处并未评估,所以也就不做过多引导性的描述,还是应该根据具体项目需求选择。
具体使用:
public static byte[] compressHtml(String html){
try {
return Snappy.compress(html.getBytes("UTF-8"));
} catch (IOException e) {
e.printStackTrace();
return null;
}
}
public static String decompressHtml(byte[] bytes){
try {
return new String(Snappy.uncompress(bytes));
} catch (IOException e) {
e.printStackTrace();
return null;
}
}
丫的好像太简单扼,都是一行,罢了罢了,大家还是到这儿来自己看API吧,尤其是file stream相关操作都有,又是一篇水文,谢谢点击!
补充:实测Snappy与lz4:
- 待压缩字符串长度约50000
- 压缩后:
- Snappy 约19000
- lz4 约16000
- lz4 fast 约19000
The end!