了解InfluxDB
1.1 InfluxDB 的使用场景InfluxDB 是一种时序数据库，时序数据库通常被用在监控场景，比如运维和 IOT（物联网）领域。这类数据库旨在存储时序数据并实时处理它们。 比如。我们可以写一个程序将服务器上 CPU 的使用情况每隔 10 秒钟向 InfluxDB 中写入一条数据。接着，我们写一个查询语句，查询过去 30 秒 CPU 的平均使用情况，然后让这个查询语句也每隔 10 秒钟执行一次。最终，我们配置一条报警规则，如果查询语句的执行结果>xxx，就立刻触发报警。 上述就是一个指标监控的场景，在 IOT 领域中，也有大量的指标需要我们监控。比如，机械设备的轴承震动频率，农田的湿度温度等等。1.2 为什么不用关系型数据库1.2.1 写入性能关系型数据库也是支持时间戳的，也能够基于时间戳进行查询。但是，从我们的使用场景出发，需要注意数据库的写入性能。通常，关系型数据库会采用 B+树数据结构，在数据写入时，有可能会触发叶裂变，从而产生了对磁盘的随机读写，降低写入速度。 当前市面上的时序数据库通常都是采用 LSM Tree 的变种，顺序写磁盘来增强数据的写入能力。网上有不少关于性能测试的文章，同学们可以自己去参考学习，通常时序数据库都会保证在单点每秒数十万的写入能力。 1.2.2 数据价值我们之前说，时序数据库一般用于指标监控场景。这个场景的数据有一个非常明显的特点就是冷热差别明显。通常，指标监控只会使用近期一段时间的数据，比如我只查询某个设备最近 10 分钟的记录，10 分钟前的数据我就不再用了。那么这 10 分钟前的数据，对我们来说就是冷数据，应该被压缩放到磁盘里去来节省空间。而热数据因为经常要用，数据库就应该让它留在内存里，等待查询。而市面上的时序数据库大都有类似的设计。1.2.3 时间不可倒流，数据只写不改时序数据是描述一个实体在不同时间所处的不同状态。
就像是我们打开任务管理器，查看 CPU 的使用情况。我发现 CPU 占用率太高了，于是杀死了一个进程，但 10 秒前的数据不会因为我关闭进程再发生改变了。 这是时序数据的一大特点。与之相应，时序数据库基本上是插入操作较多，而且还没有什么更新需求。1.3 InfluxDB生态简介根据上文的介绍，我们首先可以知道时序数据一般用在监控场景。大体上，数据的应用可以分为 4 步走。（1）数据采集
（2）存储
（3）查询（包括聚合操作）
（4）报警
这样一看，只给一个数据库其实只能完成数据的存储和查询功能，上游的采集和下游的报警都需要自己来实现。因此 InfluxData 在 InfluxDB1.X 的时候推出了 TICK 生态来推出 start 全套的解决方案。TICK4 个字母分别对应 4 个组件。
T : Telegraf - 数据采集组件，收集&发送数据到 InfluxDB。
I : InfluxDB - 存储数据&发送数据到 Chronograf。
C : Chronograf - 总的用户界面，起到总的管理功能。
K: Kapacitor - 后台处理报警信息
到了 2.x，TICK 进一步融合，ICK 的功能全部融入了 InfluxDB，仅需安装 InfluxDB 就能得到一个管理页面，而且附带了定时任务和报警功能。1.4 influxDB 版本比较与选型1.4.1 版本特性比较2023 年 InfluxDB 推出了 2.0 的正式版。2.x 同 1.x 相比，底层引擎原理相差不大，但会涉及一些概念的转变（例如 db/rp 换成了 org/bucket）。另外，对于 TICK 生态来说，1.x 需要自己配置各个组件。2.x 则是更加方便集成，有很棒的管理页面。 另外，在查询语言方面，1.x 是使用 InfluxQL 进行查询，它的风格近似 SQL。2.x 推出了 FLUX 查询语言，可以使用函数与管道符，是一种更符合时序数据特性的更具表现力的查询语言。 1.4.2 选型，