InfluxDB -- 存储引擎的演化

a朋

InfluxDB的存储引擎,经过3次的演化,最终使用基于LSM-Tree的TSM Tree方案:

LSM Tree(LevelDB)-->mmap B+Tree(BoltDB)-->TSM Tree(tsm)

LSM-Tree

LSM-Tree:Log Structured Merge Tree
常见的业务场景分两类:

  • 读多写少:比如MySQL/ETCD等存储系统,底层大都采用B-Tree及其变种;
  • 写多读少:比如时序数据库;

LSM-Tree的核心思想是充分利用磁盘的顺序写性能远高于随机写这一特性,将批量的随机写转化为一次性的顺序写。LevelDB是LSM-Tree的一种实现。

由于写多读少并且是按时间顺序写的特性,使得InfluxDB非常适合LSM-Tree;但是InfluxDB在集成LevelDB中遇到了一些问题:

  • 不支持热备份:需要停机备份;
  • 过期数据的批量删除支持不好:因为LSM-Tree的删除操作代价较高

    • 为了解决这个问题,InfluxDB根据时间将数据分为多个shard,每个shard作为一个LevelDB存储,过期时可直接删除Shard;
    • 随机数据量的增加,InfluxDB创建了越来越多的LevelDB数据库,产生大量的SSTable file,占用了大量的文件句柄,经常报错;

mmap B+Tree

BoltDB是mmap B+Tree的一种实现,它将每个数据库存储为1个文件,解决了LevelDB文件句柄不足的问题。

使用mmap B+Tree获得了较好的读性能,但是写性能经常出现高IOPS:

  • 写入时序数据时,若key设置的不合理,容易变成随机写;(B+Tree的特性,参考MySQL)
  • 更新索引数据时,由于索引没有天然的排序字段,很容易随机写,导致性能不足;

TSM-Tree

TSM-Tree: Time Structured Merge Tree
InfluxDB最终回归LSM-Tree,对其进行优化,转化为自己的数据引擎TSM-Tree:

  • TSM-Tree本质还是LSM-Tree,InfluxDB对数据查询、数据合并压缩、数据清除做了优化;
  • 对数据查询:增加了数据索引和布隆过滤器以加快查询速度;

    • 数据索引:包括元数据索引、TSM File索引;
    • 布隆过滤器:快速判断TSM File中是否包含特定的seriesKey;
  • 对数据压缩:根据不同的数据类型,采用不同压缩算法;
  • 对数据清除:由shard存储一段时间内的数据,过期直接删除shard;

参考:
1.https://wingsxdu.com/post/dat...
2.https://docs.influxdata.com/i...

阅读 463
10 声望
5 粉丝
0 条评论
10 声望
5 粉丝
文章目录
宣传栏