乐趣区

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

jiezi

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…

退出移动版