美文网首页
InfluxDB使用总结与性能优化[转]

InfluxDB使用总结与性能优化[转]

作者: 小王同学123321 | 来源:发表于2019-04-29 17:50 被阅读0次

如果项目的功能模块中用到对时间特性比较敏感的数据,例如性能监控,趋势走向等需求时,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进行正则表达式操作
SHOW TAG VALUES WITH KEY = qual_data;    #qual_data只能是tag,填写field无输出

Field 
只能使用Field进行函数操作,例如sum()
只能使用Field进行比较操作
如果需要使用int,float,boolean类型进行存储,只能使用Field
select qual_data from mangguo_data where domain='value';    #value只能是field,填写tag无输出

Schema 设计总结
不要把数据放到measurement名称中。
例如 不要让measurement名称看起来是这样的:

cpu.server1.us_west
应该改成
cpu,host=server1,region=us_west

不要把数据放到Tag value中 
例如 不要让measurement名称看起来是这样的:
cpu,host=server1.us_west
应该改成
cpu,host=server1,region=us_west
  • 不要使用取值范围很广的数据作为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

通过以下方式查询tag values的数量:
influx -database 'cloudportal' -execute 'SHOW TAG VALUES FROM six_months.collapsar_flow WITH KEY = dip' -format 'csv'|wc -l

数量是否合适可以参考以下标准:

  • 机器配置


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

相关文章

  • InfluxDB使用总结与性能优化[转]

    如果项目的功能模块中用到对时间特性比较敏感的数据,例如性能监控,趋势走向等需求时,InfluxDB将会是一个不错的...

  • 2016/12/21前端性能优化

    体验与性能优化 1. 体验优化 使用lazyload实现懒加载,优化体验与性能。 使用连续的jpg与交错的png。...

  • InfluxDB与Grafana相关资料

    时序数据库InfluxDB使用详解 使用Glances、InfluxDB和Grafana监视性能数据 (开源测试工...

  • iOS 性能优化总结

    iOS 性能优化总结 iOS 性能优化总结

  • IOS的性能优化包括哪几点

    iOS性能优化总结 iOS性能优化总结。关于 iOS 性能优化梳理: 基本工具、业务优化、内存优化、卡顿优化、布局...

  • App瘦身、性能优化总结

    App瘦身、性能优化总结 App瘦身、性能优化总结

  • 前端性能优化

    js性能小贴士——优化循环 前端网页与js性能优化 我总结的js性能优化的小知识 提高 web 应用性能之 Jav...

  • 前端性能 优化 大全

    js性能小贴士——优化循环 前端网页与js性能优化 我总结的js性能优化的小知识 提高 web 应用性能之 Jav...

  • Awesome Extra

    性能优化 性能优化模式 常见性能优化策略的总结 Spark 性能优化指南——基础篇 Spark 性能优化指南——高...

  • iOS UIWebView 与WKWebView集锦

    使用WKWebView进行性能调优 WebView性能、体验分析与优化 UIWebView、WKWebView使用...

网友评论

      本文标题:InfluxDB使用总结与性能优化[转]

      本文链接:https://www.haomeiwen.com/subject/nydunqtx.html