数据库常用压缩算法比较

比较不同压缩算法trade off

压缩的本质是减少IO操作，从而带来更快的读写操作。需要用CPU周期来对IO性能进行tradeoff。

但是同时还要考虑到实际应用的性能需求，如实时性、吞吐等。不同压缩算法的cost不同，因此需要综合考虑。

评估压缩算法的指标

• 压缩比 compression ratio
• 吞吐 throughput
• 压缩速度 compression speed
• 解压速度 decompression speed
• 内存 memory

图中给出的是java-based benchmarking，重点比较gzip和snappy两种最通用的算法。

绿色的指标是compression ratio，越小越好；黄色的指标是throughput，越大越好。

gzip的压缩比例优于snappy，但snappy的吞吐高于gzip。

如何选择适合的压缩算法

• 选择的压缩算法需要能够支持配置的big data environment（Spark、HIVE、presto、parquet、hadoop、S3、kafka等）
• 能够支持serialization format
• 考虑数据的生命周期以及访问模式！
  （对于声明周期长但访问不频繁的cold data可以选择gzip压缩算法，频繁访问的hot data可以选择snappy压缩算法）
• key wordload&split-ability
  （比如gzip就是不能支持split的数据，所以如果使用hadoop这种map reduce的应用，不选用gzip压缩算法）

Snappy压缩算法原理

snappy（又称zippy）是google开源的压缩算法，目标不是最大化压缩比例或者与其他压缩库的兼容性，而是压缩速度和合理的压缩比例。例如与zlib的最快模式相比，Snappy对于大多数输入都会快一个量级，但生成的压缩文件会大20%到100%。

snappy算法基于LZ77进行优化，因为LZ77的匹配过程时间复杂度太高。

具体可以参考 https://zzjw.cc/post/snappy/#snappy

Gzip压缩算法原理