lz4という圧縮形式があることを知った。
なんでも、なかなかの圧縮効率を誇るわりには、圧縮伸長が速いとのこと。
公式サイト通りにいえば、圧縮では1.5倍程度、身長では1.8倍程度速い、と（>50% faster on compression, >80% faster on decompression）。
速いアーカイバはなぜ嬉しいか。
速いアーカイバはなぜ嬉しいか。
端的に言えば圧縮されたバックアップからの書き戻し時間の短縮化であり、言ってみればMTTRというか、何らかの障害からの復旧速度に効いてくるからである。
というのも。
いくらHDDが安くなったとはいうものの、あればあるだけ使ってしまうせいで、バックアップにはいつまで経っても追いつかない。
そこでディスク容量をかせぐために、古いデータはしかたなく圧縮して保存するのだが、そうするといざ必要になったときには伸長待ちでえらく待たされる。
で、そういう古いデータが必要になるときというのは、高確率で緊急復旧が必要な時なんである。
みなさん、いつまで経っても終わらない伸長をジリジリしながら待ったことはあるだろうか。
ユーザが今か今かと待ってるプレッシャーを背中に感じて作業した事があるだろうか。
何年も前の私はほとほと痛い目を見たので、持っておける世代数は減るものの、原則として圧縮しないでtarで固めるだけにした（高い授業料であった）。
むろんディスクもっと買えとか、速いディスクにしろよとか、ディスク構成考えろとかあるけど、この世の中、インフラエリアにはなかなかお金を使ってもらえないよね。
というわけで、そこそこの圧縮効率があり、しかし速度がめっぽう速いとなれば気にならないわけがないのだ。
なお、速いアーカイバを活かせる道はもうひとつあって、それは圧縮ファイルシステム。
じっさい、lz4を知ったのも、ZFSに入れるよーという話から。
各種ポインタ
lz4のソース置き場はこちら。
lz4については以下のslideshareを。ほー。ドラクエですか。
http://www.slideshare.net/komiyaatsushi/dsirnlp-3-lz4
入れてみよう！
FreeBSDのportsには入ってないのでsvnでgooglecodeからダウンロード。
コンパイルにはcmakeが必要なので注意。
cmakeディレクトリを引数にcmakeを実行し、さらにmakeを実行する。
$ svn checkout http://lz4.googlecode.com/svn/trunk/ lz4<br /> （略）<br /> Checked out revision 88.<br /> $ cd ./lz4<br /> $ cmake ./cmake/<br /> $ make<br /> Scanning dependencies of target lz4demo32<br /> [ 12%] Building C object CMakeFiles/lz4demo32.dir/lz4.c.o<br /> [ 25%] Building C object CMakeFiles/lz4demo32.dir/lz4hc.c.o<br /> [ 37%] Building C object CMakeFiles/lz4demo32.dir/bench.c.o<br /> [ 50%] Building C object CMakeFiles/lz4demo32.dir/lz4demo.c.o<br /> Linking C executable lz4demo32<br /> [ 50%] Built target lz4demo32<br /> Scanning dependencies of target lz4demo64<br /> [ 62%] Building C object CMakeFiles/lz4demo64.dir/lz4.c.o<br /> [ 75%] Building C object CMakeFiles/lz4demo64.dir/lz4hc.c.o<br /> [ 87%] Building C object CMakeFiles/lz4demo64.dir/bench.c.o<br /> [100%] Building C object CMakeFiles/lz4demo64.dir/lz4demo.c.o<br /> Linking C executable lz4demo64<br /> [100%] Built target lz4demo64
すると同じディレクトリにlz4demo64, lz4demo32という実行ファイルができる。
このあとinstallとかするんだろうが、システムに入れたくはないので、自分の/binフォルダに入れる。64bitアーキテクチャなのでlz4demo64のほうを。
$ cp ./lz4demo64 ~/bin/lz4
helpを与えてみるとこんな感じ。
$ lz4 -h<br /> *** Compression CLI using LZ4 algorithm , by Yann Collet (Feb 11 2013) ***<br /> Usage :<br /> ./lz4demo64 [arg] input output<br /> Arguments :<br /> -c0: Fast compression (default)<br /> -c1: High compression<br /> -d : decompression<br /> -b#: Benchmark files, using # compression level<br /> -t : check compressed file<br /> -h : help (this text)<br /> input : can be -stdin' (pipe) or a filename<br /> output : can be -stdout'(pipe) or a filename or -null'
試してみよう！
手元にあった685MBytesのFreeBSDインストールディスクイメージをgzip, bzip2, lz4の三種で圧縮、伸長し、その速度と圧縮効率をグラフにしてみた。
青が圧縮時、緑が伸張時にかかった秒数を左軸で示す。
圧縮後、どれくらいのサイズに縮んだかを黄色、右の軸で示す。
gzip, bzip2で6割程度のサイズにまで圧縮したのに対し、lz4は75%に留まる。
そして気になる圧縮伸長では。
lz4が圧縮ではほぼぶっちぎりである。
しかし一方の伸張ではgzipと同じくらいで公式サイトの額面通りには行かなかった。
ただ、圧縮したものがインストールディスク、つまり中身は圧縮済みデータが多かろう点には注意が必要かもしれない。
仮想マシンのディスクイメージだったらまた面白い結果が出たかもしれないけど時間切れである。
え？lzmaですか？試したけど明らかに遅くて途中でやめた。
それからマシン負荷も気になって三種アーカイバのload averageも記録したけどグラフにするの面倒でやめた。
まとめ
伸張の方はまだまだ使わないと分からないけど、圧縮は本当に速い。
あっという間に終わってリアルで「えっ？」と言ったほど。
ただ、弱点があって、それはoutputのファイル名を指定しないといけないこと。
zcatのようなもので、これは弱点というよりそういう仕様なんで何とも言えない。
本記事のマクラに出したバックアップへの利用にもちょっと。
でも速いぞ。おまえらも一度使ってみろ。