InfluxDB使用总结与性能优化

如果项目的功能模块中用到对时间特性比较敏感的数据，例如性能监控，趋势走向等需求时，InfluxDB将会是一个不错的选择，虽然其很强很彪悍，但只有在使用的过程中遵循一定规范与原则，才能发挥其良好的特性。

本文会先介绍一些InfluxDB的基本概念，然后列出一些在设计Schema时应该注意的问题，最后列出一些常见的优化方式。

基本介绍
概念
Database: 数据库名，在 InfluxDB 中可以创建多个数据库，不同数据库中的数据文件是隔离存放的，存放在磁盘上的不同目录。
Retention Policy: 存储策略，用于设置数据保留的时间，每个数据库刚开始会自动创建一个默认的存储策略 autogen，数据保留时间为永久，之后用户可以自己设置，例如保留最近2小时的数据。插入和查询数据时如果不指定存储策略，则使用默认存储策略，且默认存储策略可以修改。InfluxDB 会定期清除过期的数据。
Measurement: 对于传统数据库的表，例如 cpu_usage 表示 cpu 的使用率。
Tag sets: tags 在 InfluxDB 中会被建立索引，且放在内存中。如果某种数据经常用来被作为查询条件，可以考虑设为Tag
Field: 记录值，是查询的主要对象，例如value值等
Point:代表一条记录
Series:tag key 与tag value的唯一组合
Timestamp: 每一条数据都需要指定一个时间戳，在 TSM 存储引擎中会特殊对待，以为了优化后续的查询操作。
操作
由于Tag与Field的不同特性，在编写SQL进行查询时，Tag与Field支持不同的操作，总结如下:

Tag
只能使用Tag进行Group
只能使用Tag进行正则表达式操作
Field
只能使用Field进行函数操作，例如sum()
只能使用Field进行比较操作
如果需要使用int,float,boolean类型进行存储,只能使用Field
Schema 设计总结
不要把数据放到measurement名称中。
例如 不要让measurement名称看起来是这样的：
cpu.server1.us_west
1
应该改成

cpu,host=server1,region=us_west
1
不要把数据放到Tag value中
例如 不要让measurement名称看起来是这样的：
cpu,host=server1.us_west
1
应该改成

cpu,host=server1,region=us_west
1
不要使用取值范围很广的数据作为tag,例如uuid,hash等等
如果实在有这方面的需求，考虑一下几点建议
切成多个shard,并分到多个实例上
使用tag 前缀进行区分
使用field
使用集群
Tag Key不要与Field的名称相同
Tags的数量不要太少
database的数量不要太多
当database的数量达到千万级别时，会出现打开文件过多，占用内存过多等问题。
优化
常见的优化方式如下

控制series的数量
Series会被索引且存在内存中，如果量太大会对资源造成过多损耗，且查询效率也得不到保障。
可以通过以下方式查询series的数量：

influx -database 'cloudportal' -execute 'show series' -format 'csv'|wc -l
1
通过以下方式查询tag values的数量：

influx -database 'cloudportal' -execute 'SHOW TAG VALUES FROM six_months.collapsar_flow WITH KEY = dip' -format 'csv'|wc -l
1
数量是否合适可以参考以下标准：

• 机器配置

类型 CPU RAM IOPS
Low 2-4 cores 2-4G 500
Moderate 4-6 cores 8-32G 500-1000
High 8+ cores 32+G 1000+

• 配置对应的Series数量

机器配置 每秒写Field 每秒查询数量 Series数量
Low <5 K <5 <100k
Moderate < 250 K <25 <1million
High >250 K >25 >1million

2. 控制Tag Key,与Tag Value值的大小
3. 使用批量写
   如果使用HTTP一次写一条记录，或许还没有太大的负担，但是如果用HTTPS的进行一条一条的写，在加密/解密上的资源损耗会非常的大。如果不能使用HTTP,则推荐使用UDP协议
4. 使用Continuous Queries 进行数据汇聚
   对于查询时间范围较大且数据粒度要求不是非常高的数据，可以考虑使用CQ进行数据汇总，并对汇总结果进行查询
5. 使用恰当的时间粒度
   在数据存储的时候默认使用纳秒。而对于很多业务操作而言，可能只需要精确到秒级别。这种情况对于存储资源以及查询性能都会有一定的影响。想法如果业务需要毫秒级别的精确程度，而存的时候使用了秒级别的数据，此时查询又会出现数据的丢失
6. 存储的时候尽量对Tag进行排序
7. 无关的数据写不同的database
8. 根据数据情况，调整shard的duration
   默认7天创建一个，如果查询的时间范围较大，会打开多个shard文件，对于数据量不大，且查询范围可能较大的数据，可以将shard duration时间设置的长一点
9. 存储分离
   将WAL目录与data目录分别映射到不同的磁盘上，以减少读写操作的相互影响

---

作者：小Alpha
来源：CSDN
原文：https://blog.csdn.net/eric_sunah/article/details/76274188
版权声明：本文为博主原创文章，转载请附上博文链接！