Influxdb的存储引擎

创建Influxdb数据库时,我们可以看到下面选项,每个选项的含义就是本文要描述的:

Influxdb内部数据的存储可以使用不同的存储引擎。当前0.8.7版本支持的是LevelDB, RocksDB, HyperLevelDB, 和 LMDB。

这几个数据库都是kv类型的数据库,相关信息如下:

LevelDB 是一个google实现的非常高效的kv数据库,目前的版本1.2能够支持billion级别的数据量了。
LevelDB 是单进程的服务,性能非常之高,在一台4核Q6600的CPU机器上,每秒钟写数据超过40w,而随机读的性能每秒钟超过10w。
此处随机读是完全命中内存的速度,如果是不命中 速度大大下降
LevelDB 只是一个 C/C++ 编程语言的库, 不包含网络服务封装, 所以无法像一般意义的存储服务器(如 MySQL)那样, 用客户端来连接它. LevelDB 自己也声明, 使用者应该封装自己的网络服务器.

RocksDB 是一个来自 facebook 的可嵌入式的支持持久化的 key-value 存储系统,也可作为 C/S 模式下的存储数据库,但主要目的还是嵌入式。RocksDB 基于 LevelDB 构建。

HyperLevelDB 是 HyperDex 开发的一个数据存储引擎,改进自 Google 的 LevelDB 以满足 HyperDex 的业务需要。
HyperLevelDB 主要在 LevelDB 上改进了:
1. 改进并行机制,使用更细粒度的内部锁控制来提供多 writer 线程的高吞吐量
2. 改进数据压缩

LMDB 是一个快而小的 key-value 数据存储服务,是由 OpenLDAP 项目的 Symas 开发的。使用内存映射文件,因此读取的性能跟内存数据库一样。其大小受限于虚拟地址空间的大小。

Influxdb 官方试验了这三个引擎,发现RocksDB性能好,所以Influxdb的默认存储引擎是RocksDB。

 

Influxdb 的数据存储可以支持多碎片存储,每个碎片可以是一种存储引擎,如下图,一个数据库可以有多个碎片。

 

每个碎片存储都有下面属性,跟上面图的内容项对应:

{
  "name": "high_precision",
  "database": "pauls_db",
  "retentionPolicy": "7d",
  "shardDuration": "1d",
  "regex": "/^[a-z].*/",
  "replicationFactor": 1,
  "split": 1
}

在配置参数中, 我们可以看到 "database": "pauls_db" 标示 每个碎片存储都只能属于一个特定的数据库,一个数据库可以有多个 Shard Space。

"retentionPolicy": "7d" 表示数据被保存的时间(最少保存时间), 图中的 Retention 就是这个, 下图是系统界面中,对这个时间的设置, inf 标示永久。

 

"shardDuration": "1d",    表示 多长时间做次清理。

shardDuration 的值应该小于 retentionPolicy, 大于我们查询时的group by time() 的值。

上面配置的例子中 "retentionPolicy": "7d", "shardDuration": "1d",   会导致我们保存 7-8 天的数据, 每天都会清理,把7天前的数据清理掉一次。

"replicationFactor": 1,  每个存储碎片保存到几台服务器的设置;
"split": 1 给定的时间间隔内,有多少个存储碎片。
注意,这里有下面一个隐含的关系: replicationFactor * split == 服务器的数量。
数据被分配到那个碎片空间是基于下面的算法:
  • Look up the shard spaces for the InfluxDB database
  • Loop through the spaces and use the first one that matches the series name
  • Lookup the shards for the given time interval
  • If no shards exist, create N shards for the interval based on split
  • Assign the data to a given shard in the interval using the algorithm  hash(series_name) % N

使用 shard spaces 的最佳实践是把高精度,大数据的数据 每个时间段写一个 shard spaces 。在使用时把他们再合成一起。

 

参考资料:

Influxdb Storage Engines

http://influxdb.com/docs/v0.8/advanced_topics/sharding_and_storage.html

时间: 2024-07-30 05:55:37

Influxdb的存储引擎的相关文章

时序数据库连载系列: 时序数据库一哥InfluxDB之存储机制解析

InfluxDB 的存储机制解析 本文介绍了InfluxDB对于时序数据的存储/索引的设计.由于InfluxDB的集群版已在0.12版就不再开源,因此如无特殊说明,本文的介绍对象都是指 InfluxDB 单机版 1. InfluxDB 的存储引擎演进 尽管InfluxDB自发布以来历时三年多,其存储引擎的技术架构已经做过几次重大的改动, 以下将简要介绍一下InfluxDB的存储引擎演进的过程. 1.1 演进简史 版本0.9.0之前 **基于 LevelDB的LSMTree方案** 版本0.9.0

Influxdb数据存储

环境: CentOS6.5_x64 InfluxDB版本:1.1.0 InfluxDB存储引擎看起来很像一个LSM Tree,它包含预写日志和类似存储在LSM Tree中的SSTables只读数据. TSM文件包含已经排好序而且经过压缩的序列化数据. InfluxDB会为每个时间块创建一个分区.例如,如果你有一个没有时间限制的存储策略,会以7天为时间块来创建分区. 这些分区会映射到底层数据库存储引擎. 每个数据库会有自己的WAL文件和TSM文件. LSM Tree 如果要让写性能最优,最佳的实现

Innodb存储引擎

特点:支持事务.锁定机制的改进,Innodb改变了MylSAM的锁机制,实现了行锁.实现外键..frm文件来存放结构定义相关的元数据,但是表数据和索引数据是存在一起的,每个表单独存放还是表存放在一起,完全由用户来决定. 理论:Innodb的物理结构分为两大部分 数据文件(表数据和索引数据) 存放表中的数据和所有的索引数据,包括主键和其他普通索引.Innodb中,存在了表空间这样的概念,和oracle的表空间又有较大的不同.Innodb的表空间分为两种形式.一种是共享表空间,就是所有表和索引数据存

mysql存储引擎

mysql的物理文件组成包括错误日志,查询日志,慢查询日志,事务日志,二进制日志. 日志文件中记录mysql数据库运行期间发生的变化,记录mysql数据库的客户端连接状况,sql语句的执行情况和错误信息. mysql的逻辑结构可以看成是二层架构,第一层叫做SQL layes,数据库系统处理底层数据库之前的所有工作都在这一层完成,包括权限判断,sql解析,执行计划优化,query cache的处理等.第二层就是存储引擎层,叫做storage engine layes,也是底层数据存取操作实现部分,

MySQL存储引擎MyISAM与InnoDB的优劣

使用MySQL当然会接触到MySQL的存储引擎,在新建数据库和新建数据表的时候都会看到. MySQL默认的存储引擎是MyISAM,其他常用的就是InnoDB了. 至于到底用哪种存储引擎比较好?这个问题是没有定论的,需要根据你的需求和环境来衡量.所以对这两种引擎的概念.原理.异同和各自的优劣点有了详细的了解之后,再根据自己的情况选择起来就容易多了. MyISAM InnoDB 存储结构 每张表被存放在三个文件: frm-表格定义 MYD(MYData)-数据文件 MYI(MYIndex)-索引文件

Mysql各种存储引擎的特性以及如何选择存储引擎

几个常用存储引擎的特点 下面我们重点介绍几种常用的存储引擎并对比各个存储引擎之间的区别和推荐使用方式. 特点 Myisam BDB Memory InnoDB Archive 存储限制 没有 没有 有 64TB 没有 事务安全 支持 支持 锁机制 表锁 页锁 表锁 行锁 行锁 B树索引 支持 支持 支持 支持 哈希索引 支持 支持 全文索引 支持 集群索引 支持 数据缓存 支持 支持 索引缓存 支持 支持 支持 数据可压缩 支持 支持 空间使用 低 低 N/A 高 非常低 内存使用 低 低 中等

MySQL存储引擎与数据类型

1 数据存储引擎 存储引擎的概念是MySQL的一个特性,它指定了表的类型(诸如表如何存储与索引数据.是否支持事务.外键等),表在计算机中的存储方式. 1.1 MySql支持的数据存储引擎 查看引擎信息 通过命令来查看引擎信息 show engines; 默认存储引擎为InnoDB,如下列出: Engine Support Comment Transactions XA Savepoints InnoDB DEFAULT Supports transactions, row-level locki

Tair ldb(leveldb存储引擎)实现介绍

简介 tair 是淘宝自己开发的一个分布式 key/value 存储引擎. tair 分为持久化和非持久化两种使用方式. 非持久化的 tair 可以看成是一个分布式缓存. 持久化的 tair 将数据存放于磁盘中. 为了解决磁盘损坏导致数据丢失, tair 可以配置数据的备份数目, tair 自动将一份数据的不同备份放到不同的主机上, 当有主机发生异常, 无法正常提供服务的时候, 其于的备份会继续提供服务. tair 的总体结构 tair 作为一个分布式系统, 是由一个中心控制节点和一系列的服务节

如何选择mysql存储引擎

一.MySQL的存储引擎 完整的引擎说明还是看官方文档:http://dev.mysql.com/doc/refman/5.6/en/storage-engines.html 这里介绍一些主要的引擎 1.InnoDB存储引擎 InnoDB是MySQL的默认事务型引擎,它被设计用来处理大量的短期(short-lived)事务.除非有非常特别的原因需要使用其他的存储引擎,否则应该优先考虑InnoDB引擎. 建议使用MySQL5.5及以后的版本,因为这个版本及以后的版本的InnoDB引擎性能更好. M