influxdb无法查询tag_InfluxDB 学习笔记

InfluxDB 是什么

InfluxDB 是用Go语言编写的一个开源分布式时序、事件和指标数据库，无需外部依赖。

InfluxDB在DB-Engines的时序数据库类别里排名第一。

重要特性

• 极简架构：单机版的InfluxDB只需要安装一个binary，即可运行使用，完全没有任何的外部依赖。
• 极强的写入能力： 底层采用自研的TSM存储引擎，TSM也是基于LSM的思想，提供极强的写能力以及高压缩率。
• 高效查询：对Tags会进行索引，提供高效的检索。
• InfluxQL：提供SQL-Like的查询语言，极大的方便了使用，数据库在易用性上演进的终极目标都是提供Query Language。
• Continuous Queries: 通过CQ能够支持auto-rollup和pre-aggregation，对常见的查询操作可以通过CQ来预计算加速查询。

---

存储引擎: 从LSM 到 TSM

InfluxDB 采用自研的TSM (Time-Structured Merge Tree) 作为存储引擎， 其核心思想是通过牺牲掉一些功能来对性能达到极致优化，其官方文档上有项目存储引擎经历了从LevelDB到BlotDB，再到选择自研TSM的过程，整个选择转变的思考。

时序数据库的需求

• 数十亿个单独的数据点
• 高写入吞吐量
• 高读取吞吐量
• 大型删除（数据过期）
• 主要是插入/追加工作负载，很少更新

LSM 的局限性

在官方文档上有写， 为了解决高写入吞吐量的问题， Influxdb 一开始选择了LevelDB 作为其存储引擎。 然而，随着更多地了解人们对时间序列数据的需求，influxdb遇到了一些无法克服的挑战。

LSM （日志结构合并树）为 LevelDB的引擎原理， 具体细节可以参考。 LSM 树原理详解

1. levelDB 不支持热备份。 对数据库进行安全备份必须关闭后才能复制。LevelDB的RocksDB和HyperLevelDB变体可以解决此问题。
2. 时序数据库需要提供一种自动管理数据保存的方式。 即删除过期数据， 而在levelDB 中，删除的代价过高。（通过添加墓碑的方式， 段结构合并的时候才会真正物理性的删除）。

InfluxDB 的解决方案 - TSM

按不同的时间范围划分为不同的分区（Shard），因为时序数据写入都是按时间线性产生的，所以分区的产生也是按时间线性增长的，写入通常是在最新的分区，而不会散列到多个分区。分区的优点是数据回收的物理删除非常简单，直接把整个分区删除即可。

• 在最开始的时候， influxdb 采用的方案每个shard都是一个独立的数据库实例，底层都是一套独立的LevelDB存储引擎。 这时带来的问题是，LevelDB底层采用level compaction策略，每个存储引擎都会打开比较多的文件，随着shard的增多，最终进程打开的文件句柄会很快触及到上限。
• 由于遇到大量的客户反