InfluxDB数据建模和最佳实践_influxdb实战-CSDN博客

文章目录

参考官方文档 1.8 版本

指标分为事件指标和聚合指标

事件指标常用于关键事件的告警和索引故障排查用。
聚合指标常用于统计数据和趋势分析用。

事件指标

基于事件的指标会在事件发生时立即发布。例如：当用户登录失败时，要立即发送事件告警。

示例

name: event.error
fields:
  # 用于跟ELK关联款速索引查询
  trackingId: "trackingId"
  # 耗时单位ms
  duration: 10000
  description: "描述"
  userId: "用户id"
  orgId: "组织id"
  success: 成功 失败
  status: 状态
tag:
    module: "login"
    region: "hefei"
    service: "CI"
    instanceindex: "机器的索引 1,2,3"

聚合指标

聚合指标会汇总数据并按时间间隔发布，在客户端收集、汇总然后发出指标。例如，如果在 30 秒的窗口期间，给定的 HTTP 端点接收到 10,000 个 API 调用，而不是发出 10,000 个指标，则聚合指标将发出 1 个具有 4 个字段的指标。这将节省 9999 个指标。

示例

// timer类型
name: http.request
fields:
  # 在报告间隔内所有数据点的 毫秒平均值
  mean: 100
  # 在报告期间看到的 记录总数
  count: 1000
  # 在报告间隔内看到的 所有记录的毫秒和
  sum: 10000
  # 在该间隔内看到的 最大时间
  upper: 250
tag:
    region: "hefei"
    service: "CI"
    instanceindex: "机器的索引 1,2,3"

对比分析

事件指标和聚合指标的优缺点

事件指标

优点：

能附加更多的字段。
能更实时的发送。
能进行更多维度的统计，因为原始数据粒度更细。

缺点：

指标记录数太大了。

聚合指标

优点：

指标的记录数大大降低。例如，一天的事件指标数原来为100W，假设1分钟聚合一次，聚合后的指标为每分钟一条 * tag * tagvalue = 1440 * 系列基数。
也大大降低指标写入频率。
可以提前预估数据规模问题。

缺点：

无法添加其他附件字段。
注意客户端基数爆炸问题，因为是在每个客户端内存统计，基数过大会导致内存溢出。
无法做更多维度的统计，因为原始数据已经在客户端处理了一轮，粒度变粗了。

举例分析事件指标和聚合指标记录数的差异

如果有n个事件，其有m个具有k个不同标签值的标签，则生成的记录数为：

事件指标 ： n个记录
聚合指标 ： 时间间隔 * m * k个记录

假设一天有 10w个 http 请求，请求实体有2个标签HttpMethod和success，有4个标签值GET,POST和true,false

n = 10W
m = 2, k = 4

则一天有
事件指标 = 10w points
聚合指标 = 1440 * 2 * 4 = 11520 = 1w多 （1天有1440分钟,聚合步长为1分钟）

客户端和服务端基数计算

name: laker
tags:
    module: "login"           # 一个客户端内存可能3个值 服务端:3个值    
        - login
        - user
        - order
    region: "hefei"          #  一个客户端内存只可能1个 服务端:2个值
         - hefei
         - hangzhou
    service: "CI"            #  一个客户端内存只可能1个 服务端:20个值 假设20个服务
    instanceindex: "1"       #  一个客户端内存只可能1个 服务端:3 
         - 1
         - 2
         - 3

基数只跟tag数和tagvalue数量有关

客户端内存基数: 3 * 1 * 1 * 1 = 3

服务端基数: 3* 2* 20 * 3 = 360

最佳实践

事件指标和聚合指标的选择问题

以下情况可以选择事件指标

事件的确切时间是必要的并且频率低。
需要通过事件实时告警的。
需要添加较多指端排查问题的。
高基数事件UserIds 需要与指标一起发出。注意后端数据存储的基数。

注意所有搞不定的都建议通过日志记录或其他后端来完成，毕竟都是在日志系统上做的升华。

Field和Tag的选择问题

标签Tag不要在标签值中使用高基数项，不要使用 UserId、OrgId、ClientIds、TrackingIds 等（建议放在Field）因为这些数据都是存储在内存里，会导致OOM。
对于influxdb而言，不支持根据field进行分组。特别强调，用来分组的必须是tag。
把你经常查询的字段作为tag。
如果你要对其使用GROUP BY()，也要放在tag中。
如果你要对其使用InfluxQL函数，则将其放到field中。
如果你需要存储的值不是字符串，则需要放到field中，因为tag value只能是字符串。
tag的名字和值不要太长，名字和值的长度越长，占用的内存越多。
数值的规模很大，那就是field
如果要作为where的条件，那应该作为tag。 field可以作为条件，但是效率很差。
如果要作为group by的条件，那需要作为tag, field不能进行group by。
如果需要做数学运算(如mean, percentile, stddev), 那必须是field。 tag的值不能进行数学运算。
如果需要存储数据的类型(int, float, string, boolean), 必须是filed. tag只能是字符串。
tag内存中有索引，field没有索引
不要在一个tag里存储多个信息。

其他问题

一个Point由measurement名称，tag set和timestamp唯一标识。如果提交具有相同measurement，tag set和timestamp，但具有不同field set的行协议，则field set将变为旧field set与新field set的合并，并且如果有任何冲突以新field set为准。
注意tag的设计，因为主键是由time + tag组成，是不可以重复的，如果重复，后面的将覆盖前面的。
- 增加新的tag来标识不同的点(例如：多加个tag - instanceid）
- 或者用不同的tag value区分记录
避免在influxdb中使用大量的字段，限制每张表中的字段数量，最好保持在一百个以内；
不可以更新和重命名tag
时间戳建议使用最粗糙的精度，因为这样可以显着提高压缩率。 Influxdb并不要求时间戳唯一，不同的tag, 相同的时间戳可以写入一条新的记录。也就是说对于普通的采集，以毫秒为单位完全可以满足需求。
批量写入建议每批写1000 point开始，然后根据机器配置和应用调整。

数据保留策略和连续查询

InfluxDB 每秒可以处理数十万个数据点。长时间处理如此多的数据可能会产生存储问题和查询性能问题。

一个通用的解决方案是对数据进行下采样进行数据冷热分离；仅在有限的时间内保留高精度的原始数据，而将较低精度的汇总数据存储更长时间或永久存储。

InfluxDB 提供了两个功能 - 连续查询 (CQ) 和保留策略 (RP) - 可自动执行下采样数据和使旧数据过期的过程。

大批量的热数据强烈建议保存24H，7d等。通过连续查询 (CQ) 和保留策略 (RP) - 可自动执行下采样数据和使旧数据过期的过程。

1.一个数据库可以有多个 RP，每个数据库的 RP 都是唯一的，建立2个保留策略，7d和1y。

2.指标直接写入7d的保留策略。

3.增加CQ从7d的保留策略下采样到1y的保留策略。

详情和具体步骤参见InfluxDB连续查询（通过下采样聚合原始数据降低数据样本数）和数据保留策略（过期删除）

建模示例

influxdb推荐使用tag，而不是创建很多measurement

但是最终的选择还是要结合自己的业务场景

问：我有10万个设备要上传数据，使用10万个measurement存储，还是一个measurement加上不同的tag存储

答：这个问题很大程度上取决于您的数据结构和使用方式。如果您的数据结构是相同的，那么使用一个measurement加上不同的tag存储比较优化，但如果您的数据字段和数据类型不同，那么使用10万个measurement存储可能更加合理。

原始数据结构

采集时间	设备ID	数据源	数据	类型
2018-11-15T05:40:46.3592112Z	CNC001	温度	10.5	float
2018-11-15T05:41:41.9896781Z	CNC001	设备状态	run	String
2018-11-15T05:42:02.8402281Z	CNC001	湿度	10	int
2018-11-15T05:42:02.8402281Z	CNC002	温度	-1.2	float
2018-11-15T05:42:04.8402281Z	CNC002	设备状态	run	String