Home > Linux, 杂七杂八, 源码分析 > lz4: Extremely Fast Compression algorithm

lz4: Extremely Fast Compression algorithm

March 15th, 2013

原创文章,转载请注明: 转载自系统技术非业余研究

本文链接地址: lz4: Extremely Fast Compression algorithm

最近在不少项目特别是存储相关的项目用到了lz4压缩算法,它有什么特点呢?

LZ4 is a very fast lossless compression algorithm, providing compression speed at 300 MB/s per core, scalable with multi-cores CPU. It also features an extremely fast decoder, with speeds up and beyond 1GB/s per core, typically reaching RAM speed limits on multi-core systems.

这个特性对于需要大吞吐量的压缩场合还是非常有用的,以很小的CPU代价换来更大的存储密度。

官方网站:https://code.google.com/p/lz4/, 摘抄下它的性能指标:

Name Ratio C.speed D.speed
LZ4 (r59) 2.084 330 915
LZO 2.05 1x_1 2.038 311 480
QuickLZ 1.5 -1 2.233 257 277
Snappy 1.0.5 2.024 227 729
LZF 2.076 197 465
FastLZ 2.030 190 420
zlib 1.2.5 -1 2.728 39 195
LZ4 HC (r66) 2.712 18 1020
zlib 1.2.5 -6 3.095 14 210

更多的测试可以看 这里 这里

它还有个高压缩率的版本:

LZ4 HC – High Compression Mode of LZ4

从源码lz4.c可以看到快的原因之一:
lz4

这个技术叫做 “The Blocking Technique”, 见图:
bt

考虑在项目中用起来。

祝玩得开心!

Post Footer automatically generated by wp-posturl plugin for wordpress.

Categories: Linux, 杂七杂八, 源码分析 Tags:
  1. shangqingyong
    March 16th, 2013 at 20:41 | #1

    确实是好东西啊,我已经把LZ4应用到我们的项目中了,直降了存储的性能,先是在CKPT上应用了LZ4,后来因为热双机一上,REDO日志狂增,又把日志传输和写文件都加上了LZ4,达到了我们2013年降成本的目标。
    不过遗憾的是LZ4仅仅支持Linux和AIX,我在HP上使用的时候,编译都不通过,帮助修改了下代码编译通过了,可惜会出现coredump。后来google了一把,发现是因为LZ4没有考虑访问非对齐地址的问题,链接了非对齐库之后性能直降,还不如zlib呢。于是在HP上放弃了LZ4,偷偷的替换了fastlz。:)。做过性能测试,fastlz仅仅比lz4差那么一点点,同样是遵循BSD2的,可以无忧使用。

    superlaser1912 Reply:

    老兄,能否介绍一下具体的案例啊,期待

    Yu Feng Reply:

    存储系统里面做数据的压缩用这个挺合适的。

    superlaser1912 Reply:

    确实是好东西啊,我已经把LZ4应用到我们的项目中了,直降了存储的性能,先是在CKPT上应用了LZ4,后来因为热双机一上,REDO日志狂增,又把日志传输和写文件都加上了LZ4,达到了我们2013年降成本的目标。
    //余兄,你的意思是作为一个简单的压缩工具来用吧?至于这个检查点和redo应用LZ4是怎么实现的呢?是Oracle数据库吗?

    Yu Feng Reply:

    压缩库和你的应用结合来用呀。

    shangqingyong Reply:

    CKPT中原来的设计师64k作为一个脏页持久化到硬盘中的,新的设计中引入了脏块的概念,一个脏块有512个页面,
    只要脏块中有一个页面改变就会把整个脏块压缩一下写到第一个页面为首地址的硬盘上,写入包括是否压缩标记。
    掉电恢复的时候根据512整数倍的页面地址判断是否压缩标记,有压缩标记则在读入内存后解压数据。
    对于REDO日志则是从CLB(Cyclic Log Buffer)中取出最多4M的日志压缩后写入日志文件,同样解析的时候根据标记是否解压做相应处理。

  2. March 16th, 2013 at 20:44 | #2

    确实是好东西啊,我已经把LZ4应用到我们的项目中了,直降了存储的性能,先是在CKPT上应用了LZ4,后来因为热双机一上,REDO日志狂增,又把日志传输和写文件都加上了LZ4,达到了我们2013年降成本的目标。
    不过遗憾的是LZ4仅仅支持Linux和AIX,我在HP上使用的时候,编译都不通过,帮助修改了下代码编译通过了,可惜会出现coredump。后来google了一把,发现是因为LZ4没有考虑访问非对齐地址的问题,链接了非对齐库之后性能直降,还不如zlib呢。于是在HP上放弃了LZ4,偷偷的替换了fastlz。:)。做过性能测试,fastlz仅仅比lz4差那么一点点,同样是遵循BSD2的,可以无忧使用。
    回复不了啊,幸亏拷贝了下,不然这么多字白敲了:)

    Yu Feng Reply:

    多谢这么多先进的经验。

    shangqingyong Reply:

    来而不往非礼也,从博主的文章学到了太多的东西。

Comments are closed.