共计 1076 个字符，预计需要花费 3 分钟才能阅读完成。
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…
正文完