常见的压缩方法基本都是支持单模式,或者有限的偏static的模式进行数据的压缩。很多为了提高压缩率,都用了 bit-packing (甚至有损压缩),但对越来越广泛使用的并行计算不太友好。具体方法如下:
a) Snappy:对整数或字符串进行压缩,主要用了长距离预测和游程编码(RLE),广泛的应用包括 Infuxdb。
b) Simple8b:先对数据进行前后 delta 处理,如果相同用RLE编码;否则根据一张有 16 个 entry 的码表把 1 到 240 个数(每个数的 bits 根据码表)pack 到 8B 为单位的数据中,有广泛的应用包括 Infuxdb。
c) Compression planner:引入了一些 general 的压缩 tool 如 scale, delta, dictionary, huffman, run length 和 patched constant 等,然后提出了用静态的或动态办法组合尝试这些工具来进行压缩;想法挺新颖但实际性能会是个问题。
d) ModelarDB:侧重在有损压缩,基于用户给定的可容忍损失进行压缩。基本思想是把维护一个小 buff,探测单前数据是否符合某种模式(斜率的直线拟合),如果不成功,切换模式重新开始buff等;对支持有损的 IoT 领域比较合适。
e) Sprintz:也是在 IoT 领域效果会比较好,侧重在 8/16 bit 的整数处理;主要用了 scale 进行预测然后用 RLC 进行差值编码并做 bit-level 的 packing。
f) Gorilla:应用在 Facebook 高吞吐实时系统中的当时 sofa 的压缩算法,进行无损压缩,广泛适用于 IoT 和云端服务等各个领域。它引入 delta-of-delta 对时间戳进行处理,用 xor 对数据进行变换然后用 Huffman 编码及 bit-packing。示例图如下所示。
g) MO:类似 Gorilla,但去掉了 bit-packing,所有的数据操作基本都是字节对齐,降低了压缩率但提供了处理性能。
版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。