Influxdb資料壓縮

標籤：return   儲存   guide   排序   select   centos   init   ase   標識   

環境： CentOS6.5_x64
InfluxDB版本：1.1.0

 

資料壓縮可以參考：

https://docs.influxdata.com/influxdb/v1.1/concepts/storage_engine/#compression

 

influxdb根據不同的資料類型會採用不同的壓縮演算法。

• int

　　首先使用ZigZag演算法進行編碼，如果編碼後的值小於 (1 << 60 ) - 1，使用simple8b演算法；

　　如果大於該值，不壓縮；

• timestamp

　　排序後使用差分編碼演算法進行編碼，然後使用simple8b演算法壓縮。

• float

　　使用 Facebook Gorilla paper提供的浮點數壓縮演算法

• bool

　　只有1位元據，採用簡單的位元據打包策略

• string

　　採用snappy演算法

壓縮演算法介紹ZigZag演算法

這個演算法使用的基礎就是認為在大多數情況下，我們使用的數字都是不大的數字。 小整數對應的ZigZag碼字短，大整數對應的ZigZag碼字長。 但是，在特定的情境下，比如，要傳輸的整數為大整數居多，ZigZag編碼的壓縮效率就不理想了。

實現代碼如下：

// ZigZagEncode converts a int64 to a uint64 by zig zagging negative and positive values// across even and odd numbers.  Eg. [0,-1,1,-2] becomes [0, 1, 2, 3]func ZigZagEncode(x int64) uint64 {    return uint64(uint64(x<<1) ^ uint64((int64(x) >> 63)))}// ZigZagDecode converts a previously zigzag encoded uint64 back to a int64func ZigZagDecode(v uint64) int64 {    return int64((v >> 1) ^ uint64((int64(v&1)<<63)>>63))}

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    DecodingGZIP            13.4%   21 MB/s     118 MB/sLZO             20.5%   135 MB/s    410 MB/sZippy/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資料壓縮