Influxdb数据压缩

simple8b算法

该算法是64位算法，实现将多个整型数据压缩到一个64位的存储结构中， 存储结构中的前4位用于标识Selector的值，后60位用于存储数据，可以压缩0到(1<<60)-1的数字。

使用下表进行编码：

┌──────────────┬─────────────────────────────────────────────────────────────┐
│   Selector   │       0    1   2   3   4   5   6   7  8  9  0 11 12 13 14 15│
├──────────────┼─────────────────────────────────────────────────────────────┤
│     Bits     │       0    0   1   2   3   4   5   6  7  8 10 12 15 20 30 60│
├──────────────┼─────────────────────────────────────────────────────────────┤
│      N       │     240  120  60  30  20  15  12  10  8  7  6  5  4  3  2  1│
├──────────────┼─────────────────────────────────────────────────────────────┤
│   Wasted Bits│      60   60   0   0   0   0  12   0  4  4  0  0  0  0  0  0│
└──────────────┴─────────────────────────────────────────────────────────────┘

Fackbook Gorilla XOR算法

第一个值不压缩； 后面的值是跟第一个值XOR的结果来的，如果结果相同，仅存储一个0； 如果结果不同，存储XOR后的结果。

snappy算法

以下是Google几年前发布的一组测试数据（《HBase: The Definitive Guide》）：

Algorithm   % remaining Encoding    Decoding
GZIP            13.4%   21 MB/s     118 MB/s
LZO             20.5%   135 MB/s    410 MB/s
Zippy/Snappy    22.2%   172 MB/s    409 MB/s

其中：

1）GZIP的压缩率最高，但是它是CPU密集型的，对CPU的消耗比其他算法要多，压缩和解压速度也慢；

2）LZO的压缩率居中，比GZIP要低一些，但是压缩和解压速度明显要比GZIP快很多，其中解压速度快的更多；

3）Zippy/Snappy的压缩率最低，而压缩和解压速度要稍微比LZO要快一些。

好，就这些了，希望对你有帮助。

本文github地址：

https://github.com/mike-zhang/mikeBlogEssays/blob/master/2017/20170423_Influxdb数据压缩描述.rst

欢迎补充 

Influxdb数据压缩

标签：return   存储   guide   排序   select   centos   init   ase   标识