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

InfluxDB 的存储机制解析

本文介绍了InfluxDB对于时序数据的存储/索引的设计。由于InfluxDB的集群版已在0.12版就不再开源,因此如无特殊说明,本文的介绍对象都是指 InfluxDB 单机版

1. InfluxDB 的存储引擎演进

尽管InfluxDB自发布以来历时三年多,其存储引擎的技术架构已经做过几次重大的改动, 以下将简要介绍一下InfluxDB的存储引擎演进的过程。

1.1 演进简史

  • 版本0.9.0之前

    **基于 LevelDB的LSMTree方案**
    
  • 版本0.9.0~0.9.4
    **基于BoltDB的mmap COW B+tree方案**
    
  • 版本0.9.5~1.2
    **基于自研的 WAL + TSMFile 方案**(TSMFile方案是0.9.6版本正式启用,0.9.5只是提供了原型)
    
  • 版本1.3~至今
    **基于自研的 WAL + TSMFile + TSIFile 方案**
    

1.2 演进的考量

InfluxDB的存储引擎先后尝试过包括LevelDB, BoltDB在内的多种方案。但是对于InfluxDB的下述诉求终不能完美地支持:

  • 时序数据在降采样后会存在大批量的数据删除

    => *LevelDB的LSMTree删除代价过高*
  • 单机环境存放大量数据时不能占用过多文件句柄
    => *LevelDB会随着时间增长产生大量小文件*
  • 数据存储需要热备份
    => *LevelDB只能冷备*
  • 大数据场景下写吞吐量要跟得上
    => *BoltDB的B+tree写操作吞吐量成瓶颈*
  • 存储需具备良好的压缩性能
    => *BoltDB不支持压缩*
    

此外,出于技术栈的一致性以及部署的简易性考虑(面向容器部署),InfluxDB团队希望存储引擎 与 其上层的TSDB引擎一样都是用GO编写,因此潜在的RocksDB选项被排除

基于上述痛点,InfluxDB团队决定自己做一个存储引擎的实现。

2 InfluxDB的数据模型

在解析InfluxDB的存储引擎之前,先回顾一下InfluxDB中的数据模型。

在InfluxDB中,时序数据支持多值模型,它的一条典型的时间点数据如下所示:

图 1

  • measurement:

    指标对象,也即一个数据源对象。每个measurement可以拥有一个或多个指标值,也即下文所述的**field**。在实际运用中,可以把一个现实中被检测的对象(如:“cpu”)定义为一个measurement
  • tags:
    概念等同于大多数时序数据库中的tags, 通常通过tags可以唯一标示数据源。每个tag的key和value必须都是字符串。
  • field:
    数据源记录的具体指标值。每一种指标被称作一个“field”,指标值就是 “field”对应的“value”
  • timestamp:
    数据的时间戳。在InfluxDB中,理论上时间戳可以精确到 **纳秒**(ns)级别
    

此外,在InfluxDB中,measurement的概念之上还有一个对标传统DBMS的 Database 的概念,逻辑上每个Database下面可以有多个measurement。在单机版的InfluxDB实现中,每个Database实际对应了一个文件系统的 目录。

2.1 Serieskey的概念

InfluxDB中的SeriesKey的概念就是通常在时序数据库领域被称为 时间线 的概念, 一个SeriesKey在内存中的表示即为下述字符串(逗号和空格被转义)的 字节数组(github.com/influxdata/influxdb/model#MakeKey())

{measurement名}{tagK1}={tagV1},{tagK2}={tagV2},...

其中,SeriesKey的长度不能超过 65535 字节

2.2 支持的Field类型

InfluxDB的Field值支持以下数据类型:

Datatype Size in Mem Value Range
Float 8 bytes 1.797693134862315708145274237317043567981e+308 ~ 4.940656458412465441765687928682213723651e-324
Integer 8 bytes -9223372036854775808 ~ 9223372036854775807
String 0~64KB String with length less than 64KB
Boolean 1 byte true 或 false

在InfluxDB中,Field的数据类型在以下范围内必须保持不变,否则写数据时会报错 类型冲突。

同一Serieskey + 同一field + 同一shard

2.3 Shard的概念

在InfluxDB中, 能且只能 对一个Database指定一个 Retention Policy (简称:RP)。通过RP可以对指定的Database中保存的时序数据的留存时间(duration)进行设置。而 Shard 的概念就是由duration衍生而来。一旦一个Database的duration确定后, 那么在该Database的时序数据将会在这个duration范围内进一步按时间进行分片从而时数据分成以一个一个的shard为单位进行保存。

shard分片的时间 与 duration之间的关系如下

Duration of RP Shard Duration
< 2 Hours 1 Hour
>= 2 Hours 且 <= 6 Months 1 Day
> 6 Months 7 Days

新建的Database在未显式指定RC的情况下,默认的RC为 数据的Duration为永久,Shard分片时间为7天

注: 在闭源的集群版Influxdb中,用户可以通过RC规则指定数据在基于时间分片的基础上再按SeriesKey为单位进行进一步分片

3. InfluxDB的存储引擎分析

时序数据库的存储引擎主要需满足以下三个主要场景的性能需求

  1. 大批量的时序数据写入的高性能
  2. 直接根据时间线(即Influxdb中的 Serieskey )在指定时间戳范围内扫描数据的高性能
  3. 间接通过measurement和部分tag查询指定时间戳范围内所有满足条件的时序数据的高性能

InfluxDB在结合了1.2所述考量的基础上推出了他们的解决方案,即下面要介绍的 WAL + TSMFile + TSIFile的方案

3.1 WAL解析

InfluxDB写入时序数据时为了确保数据完整性和可用性,与大部分数据库产品一样,都是会先写WAL,再写入缓存,最后刷盘。对于InfluxDB而言,写入时序数据的主要流程如同下图所示:

图 2

InfluxDB对于时间线数据和时序数据本身分开,分别写入不同的WAL中,其结构如下所示:

索引数据的WAL

由于InfluxDB支持对Measurement,TagKey,TagValue的删除操作,当然随着时序数据的不断写入,自然也包括 增加新的时间线,因此索引数据的WAL会区分当前所做的操作具体是什么,它的WAL的结构如下图所示

图 3

时序数据的WAL

由于InfluxDB对于时序数据的写操作永远只有单纯写入,因此它的Entry不需要区分操作种类,直接记录写入的数据即可

图 4

3.2 TSMFile解析

TSMFile是InfluxDB对于时序数据的存储方案。在文件系统层面,每一个TSMFile对应了一个 Shard。

TSMFile的存储结构如下图所示:

图 5

其特点是在一个TSMFile中将 时序数据(i.e Timestamp + Field value)保存在数据区;将Serieskey 和 Field Name的信息保存在索引区,通过一个基于 Serieskey + Fieldkey构建的形似B+tree的文件内索引快速定位时序数据所在的 数据块

注: 在当前版本中,单个TSMFile的最大长度为2GB,超过时即使是同一个Shard,也会继续新开一个TSMFile保存数据。本文的介绍出于简单化考虑,以下内容不考虑同一个Shard的TSMFile分裂的场景

  • 索引块的构成

    上文的索引块的构成,如下所示:
    
    *图 6*

其中 **索引条目** 在InfluxDB的源码中被称为`directIndex`。在TSMFile中,索引块是按照 Serieskey + Fieldkey **排序** 后组织在一起的。

明白了TSMFile的索引区的构成,就可以很自然地理解InfluxDB如何高性能地在TSMFile扫描时序数据了:

1. 根据用户指定的时间线(Serieskey)以及Field名 在 **索引区** 利用二分查找找到指定的Serieskey+FieldKey所处的 **索引数据块**
2. 根据用户指定的时间戳范围在 **索引数据块** 中查找数据落在哪个(*或哪几个*)**索引条目**
3. 将找到的 **索引条目** 对应的 **时序数据块** 加载到内存中进行进一步的Scan

*注:上述的1,2,3只是简单化地介绍了查询机制,实际的实现中还有类似扫描的时间范围跨索引块等一系列复杂场景*

<br>
  • 时序数据的存储

    在图 2中介绍了时序数据块的结构:即同一个 Serieskey + Fieldkey 的 所有时间戳 - Field值对被拆分开,分成两个区:Timestamps区和Value区分别进行存储。它的目的是:实际存储时可以分别对时间戳和Field值按不同的压缩算法进行存储以减少时序数据块的大小

    采用的压缩算法如下所示:

    做查询时,当利用TSMFile的索引找到文件中的时序数据块时,将数据块载入内存并对Timestamp以及Field Value进行解压缩后以便继续后续的查询操作。

3.3 TSIFile解析

有了TSMFile,第3章开头所说的三个主要场景中的场景1和场景2都可以得到很好的解决。但是如果查询时用户并没有按预期按照Serieskey来指定查询条件,而是指定了更加复杂的条件,该如何确保它的查询性能?通常情况下,这个问题的解决方案是依赖倒排索引(Inverted Index)。

InfluxDB的倒排索引依赖于下述两个数据结构

  • map<SeriesID, SeriesKey>
  • map<tagkey, map<tagvalue, List<SeriesID>>>

它们在内存中展现如下:

图 7

图 8

但是在实际生产环境中,由于用户的时间线规模会变得很大,因此会造成倒排索引使用的内存过多,所以后来InfluxDB又引入了 TSIFile

TSIFile的整体存储机制与TSMFile相似,也是以 Shard 为单位生成一个TSIFile。具体的存储格式就在此不赘述了。

4. 总结

以上就是对InfluxDB的存储机制的粗浅解析,由于目前所见的只有单机版的InfluxDB,所以尚不知道集群版的InfluxDB在存储方面有哪些不同。但是,即便是这单机版的存储机制,也对我们设计时序数据库有着重要的参考意义。

原文链接
更多技术干货 请关注阿里云云栖社区微信号 :yunqiinsight

原文地址:https://www.cnblogs.com/zhaowei121/p/10438220.html

时间: 2024-10-10 12:31:46

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

时序数据库连载系列:时序数据库那些事

正如<银翼杀手>中那句在影史流传经典的台词:"I've seen things you people wouldn't believe... All those ... moments will be lost in time, like tears...in rain." 时间浩瀚的人类历史长河中总是一个耀眼的词汇,当科技的年轮划到数据时代,时间与数据库碰到一起,把数据库内建时间属性后,产生了时序数据库.时序数据库是一种带有时间戳业务属性的垂直型数据库.自从2014年开始

时序数据库连载系列:指标届的独角兽Prometheus

简介Prometheus是SoundCloud公司开发的一站式监控告警平台,依赖少,功能齐全.于2016年加入CNCF,广泛用于 Kubernetes集群的监控系统中,2018.8月成为继K8S之后第二个毕业的项目.Prometheus作为CNCF生态圈中的重要一员,其活跃度仅次于 Kubernetes. 关键功能包括:多维数据模型:metric,labels灵活的查询语言:PromQL, 在同一个查询语句,可以对多个 metrics 进行乘法.加法.连接.取分数位等操作.可独立部署,拆箱即用,

数据库改名系列(数据库名,逻辑名,物理文件名)

汇总篇:http://www.cnblogs.com/dunitian/p/4822808.html#tsql 某系统设计的不是很合理,库很多,图形化操作分离都得搞半天,各种改名也就更浪费时间了,于是引入了命令~(SQLServer现在已经在Linux里面跑了,咱们也得跟上时代) 1.数据库名修改前 alter database Test modify name=NewTest or exec sp_renamedb 'Test','NewTest' 2.数据库名修改后 3.物理文件名和逻辑名并

【巨杉数据库SequoiaDB】巨杉 Tech | 并发性与锁机制解析与实践

01 概述 数据库是一个多用户使用的共享资源.当多个用户并发地存取数据时,在数据库中就会产生多个事务同时存取同一数据的情况.若对并发操作不加控制就可能会读取和存储不正确的数据,破坏数据库的一致性.加锁是实现数据库并发控制的一个非常重要的技术.当事务在对某个数据对象进行操作前,先向系统发出请求,对其加锁.加锁后事务就对该数据对象有了一定的控制,在该事务释放锁之前,其他的事务不能对此数据对象进行更新操作. OLTP 场景下通常要求具有很高的并发性.并发事务实际上取决于资源的使用状况,原则上应尽量减少

Sql Server来龙去脉系列之四 数据库和文件

在讨论数据库之前我们先要明白一个问题:什么是数据库? 数据库是若干对象的集合,这些对象用来控制和维护数据.一个经典的数据库实例仅仅包含少量的数据库,但用户一般也不会在一个实例上创建太多的数据库.一个数据库实例最多能创建32767个数据库,但是按照实际情况,一般设计是不会达到这个限制值. 为了更明显地说明数据库,数据库包含了以下属性和功能: *. 它是很多对象的集合,比如表.视图.存储过程.约束.对象集合的最大值是2(31) - 1(超过2百亿).一般对象的数量在几百至一万. *. 它维持拥有的用

oracle学习入门系列之一 数据库发展与历史

oracle学习入门系列之一 数据库发展与历史 这个oracle学习入门系列是根据本人工作中的一些笔记.项目进行回忆.整理.一方面是自己知识积累,便于技能提升:另一方面是和小伙伴们共进退互通有无,做一个爱分享的好公民.当然最后也夹杂着自己的一个小心愿,改掉自己重理不重文的臭毛病.想想读书考试的时候,当时如果语文英语多个几分,现在可能就不会落到如此...(咳咳~~),做IT也挺好.那就这样开场白切入吧. 既然学习数据库,就不能不抛几个问题了. 1.        为什么需要数据库,什么是数据库 2

ASP.NET MVC+EF框架+EasyUI实现权限管理系列(2)-数据库访问层的设计Demo

原文:ASP.NET MVC+EF框架+EasyUI实现权限管理系列(2)-数据库访问层的设计Demo ASP.NET MVC+EF框架+EasyUI实现权限管系列 (开篇) (1)框架搭建 前言:这篇博客我们继续来实现我的权限系列,这个博客一段时间也没有写了,重点是我在想还写不写,最终我决定还是写下去,因为我们是为了学习,当别人提出意见的时候,我们可以参考和采纳,但是我们不一定非要采纳,上几篇博客大家都说用CodeFirst来实现,是啊,现在基本很少有人用我的这种方法来实现了,都是用CodeF

Flask系列:数据库

这个系列是学习<Flask Web开发:基于Python的Web应用开发实战>的部分笔记 对于用户提交的信息,包括 账号.文章 等,需要能够将这些数据保存下来 持久存储的三种方法: 文件:shelve(pickle 和 DBM 的结合)等,提供类似字典的对象接口 关系型数据库(SQL) 非关系型数据库(NoSQL) 其他 通常会使用数据库保存信息,并向数据库发起查询获取信息 SQL,关系型数据库 关系型数据库把数据存储在表中,表在程序中通过 Python 的类实现.例如,订单管理程序的数据库中

知识管理系列---2.数据库设计

系列引导: 知识管理系列----1.原型设计 知识管理系列----2.数据库设计 前言: 数据库的设计是整个数据架构最核心的部分. 详细设计部分: 此数据库设计为V1.0版本,后续开发过程中会进行版本迭代. 数据库创建SQL脚本:SQL脚本 原文地址:https://www.cnblogs.com/xiaowangzi1987/p/8456020.html