乐趣区

关于influxdb:InfluxDB-存储引擎的演化

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…

退出移动版