Influxdb数据压缩

环境: 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 int64
func 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    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

欢迎补充

时间: 2024-10-09 11:04:46

Influxdb数据压缩的相关文章

InfluxDB引擎原理

引言 InfluxDB是一款Go语言写的时序数据库.时序数据库主要用于存储基于时间序列的指标数据,例如一个Web页面的PV.UV等指标,将其定期采集,并打上时间戳,就是一份基于时间序列的指标.时序数据库通常用来配合前端页面来展示一段时间的指标曲线. 为什么需要时序数据库 时序数据库较传统的关系型数据库以及NoSQL究竟有什么优势,下面会结合相关模型的特性进行分析 LSM Tree LSM tree是基于Google的BigTable架构,数据以K-V方式存储. 写数据首先会插入到内存中的树.当内

Influxdb的存储引擎

创建Influxdb数据库时,我们可以看到下面选项,每个选项的含义就是本文要描述的: Influxdb内部数据的存储可以使用不同的存储引擎.当前0.8.7版本支持的是LevelDB, RocksDB, HyperLevelDB, 和 LMDB. 这几个数据库都是kv类型的数据库,相关信息如下: LevelDB 是一个google实现的非常高效的kv数据库,目前的版本1.2能够支持billion级别的数据量了. LevelDB 是单进程的服务,性能非常之高,在一台4核Q6600的CPU机器上,每秒

时间序列数据库(TSDB)初识与选择(InfluxDB、OpenTSDB、Druid、Elastic

背景 这两年互联网行业掀着一股新风,总是听着各种高大上的新名词.大数据.人工智能.物联网.机器学习.商业智能.智能预警啊等等. 以前的系统,做数据可视化,信息管理,流程控制.现在业务已经不仅仅满足于这种简单的管理和控制了.数据可视化分析,大数据信息挖掘,统计预测,建模仿真,智能控制成了各种业务的追求. "所有一切如泪水般消失在时间之中,时间正在死去",以前我们利用互联网解决现实的问题.现在我们已经不满足于现实,数据将连接成时间序列,可以往前可以观其历史,揭示其规律性,往后可以把握其趋势

时间序列数据库(TSDB)初识与选择(InfluxDB,OpenTSDB,Druid)

背景 这两年互联网行业掀着一股新风,总是听着各种高大上的新名词.大数据.人工智能.物联网.机器学习.商业智能.智能预警啊等等. 以前的系统,做数据可视化,信息管理,流程控制.现在业务已经不仅仅满足于这种简单的管理和控制了.数据可视化分析,大数据信息挖掘,统计预测,建模仿真,智能控制成了各种业务的追求. "所有一切如泪水般消失在时间之中,时间正在死去",以前我们利用互联网解决现实的问题.现在我们已经不满足于现实,数据将连接成时间序列,可以往前可以观其历史,揭示其规律性,往后可以把握其趋势

试用时间序列数据库InfluxDB

Hadoop集群监控需要使用时间序列数据库,今天花了半天时间调研使用了一下最近比较火的InfluxDB,发现还真是不错,记录一下学习心得. Influx是用Go语言写的,专为时间序列数据持久化所开发的,由于使用Go语言,所以各平台基本都支持.类似的时间序列数据库还有OpenTSDB,Prometheus等. OpenTSDB很有名,性能也不错,但是基于HBase,要用那个还得先搭一套HBase,有点为了吃红烧肉自己得先去杀猪,烫皮,拔毛的感觉.Prometheus相关文档和讨论太少,而Influ

influxdb用户权限篇

设置TS的authorized,提高安全性,针对指定用户拥有权限才能访问数据库的数据,TS默认用户分为普通用户和管理员用户,权限分为read,write,all privileges三种权限 添加用户可以通过终端或者WEB方式2种方式: 开启一个用户权限的过程: 1.在安装好数据库后,通过默认方式登陆数据库:[[email protected] ~]# influx 2.添加用户 CREATE USER "influxdb" WITH PASSWORD 'root123' WITH A

Web---HTTP请求、重定向、转发和数据压缩

HTTP常用的请求方式包括: GET-最为常见,但发送的数据量很小,发送的数据直接包含到url的后面. POST-可以包含大量数据,数据在请求正文中通过表单进行提交. HEAD,PUT,DELETE. 后面三种Tomcat服务器默认都不支持.常用的只有前两种. GET: 发送到服务器的数据出现在URL的后面.最多不能超过1K.如: http://localhost:8080/index.jsp?name=itcast&sex=man&.. POST: 发送到服务器的数据会出现有请求的正文部

数据压缩简要

1. 决定压缩哪些对象 通过sp_estimate_data_compression_savings 评估在ROW和PAGE压缩时分别节省的空间量. 表包含如下数据模式时,会有较好的压缩效果: 数字类型的列和固定长度的字符类型数据,但两者的大多数值都不会用到此类型的所有字节.如INT列的值大多数少于1000. 允许为NULL的列有很多NULL值 列值中有很多一样的值或者相同的前缀. 表包含如下数据模式时,压缩效果较差: 数字类型的列和固定长度的字符类型数据,但是两者的大多数值都会用尽此类型的所有

influxdb基本操作

进入CLI界面InfluxDB Shell (CLI) /opt/influxdb/influx 数据库 显示所有数据库 SHOW DATABASES 添加数据库 CREATE DATABASE mydb 删除数据库 DROP DATABASE mydb 用户 显示所有用户 SHOW USERS 创建用户 CREATE USER leo WITH PASSWORD 'admin' 修改用户(密码) SET PASSWORD FOR leo = 'admin' 删除用户 DROP USER leo