schema设计

每个InfluxDB用例都可能是不一样的,schema将反映出这种独特性。 但是,在设计schema时,有一些遵循的一般准和可以避免的陷阱。

一般建议

推崇的schema设计

没有特定的顺序,我们有如下建议:

哪些情况下使用tag

一般来说,你的查询可以指引你哪些数据放在tag中,哪些放在field中。

  • 把你经常查询的字段作为tag
  • 如果你要对其使用GROUP BY(),也要放在tag中
  • 如果你要对其使用InfluxQL函数,则将其放到field中
  • 如果你需要存储的值不是字符串,则需要放到field中,因为tag value只能是字符串

避免InfluxQL中关键字作为标识符名称

这不是必需的,但它简化了写查询; 您不必将这些标识符包装在双引号中。 标识符有database名称,retention policy名称,user名,measurement名称,tag key和field key。请参阅InfluxQL关键词看下哪些单词需要被避免。

请注意,如果查询中包含除[A-z,_]以外的字符,则还需要将它们用双引号括起来。

避免的schema设计

没有特定的顺序,我们有如下建议:

不要有太多的series

tags包含高度可变的信息,如UUID,哈希值和随机字符串,这将导致数据库中的大量measurement,通俗地说是高series cardinality。series cardinality高是许多数据库高内存使用的主要原因。

请参阅硬件指南中基于你的硬件的series cardinality的建议。如果系统有内存限制,请考虑将高cardinality数据存储为field而不是tag。

如何设计measurement

一般来说,谈论这一步可以简化你的查询。InfluxDB的查询会合并属于同一measurement范围内的数据; 用tag区分数据比使用详细的measurement名字更好。

例如:考虑如下的schema:

  1. Schema 1 - Data encoded in the measurement name
  2. -------------
  3. blueberries.plot-1.north temp=50.1 1472515200000000000
  4. blueberries.plot-2.midwest temp=49.8 1472515200000000000

这个没有tag的长长的measurement名字(blueberries.plot-1.north)有些类似于Graphite的metric。像plot``region这样的信息放在measurement名字里面将会使数据很难去查询。

例如,使用schema 1计算两个图1和2的平均temp是不可能的。将其与如下schema进行比较:

  1. Schema 2 - Data encoded in tags
  2. -------------
  3. weather_sensor,crop=blueberries,plot=1,region=north temp=50.1 1472515200000000000
  4. weather_sensor,crop=blueberries,plot=2,region=midwest temp=49.8 1472515200000000000

以下查询计算了落在北部地区的蓝莓的平均temp。 虽然这两个查询都比较简单,但使用正则表达式使得某些查询更加复杂或根本不可能实现。

  1. # Schema 1 - Query for data encoded in the measurement name
  2. > SELECT mean("temp") FROM /\.north$/
  3. # Schema 2 - Query for data encoded in tags
  4. > SELECT mean("temp") FROM "weather_sensor" WHERE "region" = 'north'

不要把多条信息放到一个tag里面

与上述相似,将具有多条信息的单个tag拆分为多个单独的tag将简化查询并减少对正则表达式的需求。

例如,考虑如下的schema:

  1. Schema 1 - Multiple data encoded in a single tag
  2. -------------
  3. weather_sensor,crop=blueberries,location=plot-1.north temp=50.1 1472515200000000000
  4. weather_sensor,crop=blueberries,location=plot-2.midwest temp=49.8 1472515200000000000

上述数据将多个单独的参数plot``region放到了一个长tag value里面(plot-1.north)。 将其与如下schema进行比较:

  1. Schema 2 - Data encoded in multiple tags
  2. -------------
  3. weather_sensor,crop=blueberries,plot=1,region=north temp=50.1 1472515200000000000
  4. weather_sensor,crop=blueberries,plot=2,region=midwest temp=49.8 1472515200000000000

以下查询计算了落在north地区的蓝莓的平均temp。 虽然这两个查询都是相似的,但在Schema 2中使用多个tag避免了使用正则表达式。

  1. # Schema 1 - Query for multiple data encoded in a single tag
  2. > SELECT mean("temp") FROM "weather_sensor" WHERE location =~ /\.north$/
  3. # Schema 2 - Query for data encoded in multiple tags
  4. > SELECT mean("temp") FROM "weather_sensor" WHERE region = 'north'

shard group的保留时间(duration)的管理

shard group的保留时间(duration)预览

InfluxDB将数据存储在shard group中。shard group由存储策略(RP)管理,并存储具有特定时间间隔内的时间戳的数据。 该时间间隔的长度称为shard group的duration。

默认情况下,shard group的duration是由RP的duration决定:

RP duration shard group duration
< 2 days a hour
>= 2 days and <= 6 months 1 day
> 6 months 7 days

在每个RP上shard group的duration也是可以配置的,可以看Retention Policy管理看如何配置shard group的duration。

shard group的duration的建议

通常,较短的shard group的duration允许系统有效地丢弃数据。 当InfluxDB强制执行RP时,它会丢弃整个shard group,而不是单个数据点。 例如,如果您的RP有一天的持续时间,一个shard group持续时间为一小时; 则InfluxDB每小时将丢弃一小时的数据。

如果您的RP的持续时间大于6个月,则不需要具有较短的shard group持续时间。 事实上,将shard group的持续时间提高到默认的七天值以上可以改善压缩,提高写入速度,并减少每个shard group的固定迭代器开销。 例如,50年及以上的shard group持续时间是可接受的配置。

说明:当配置shard group的duration的时候,INF(infinite)是一个不合理的配置。在实际工作中,特定的duration1000w就足够达到非常长的shard group持续时间。

我们建议shard group的配置如下:

  • 是你一般查询时间范围的两倍
  • 每个shard group里至少有100000个数据点
  • 每个shard group里面的每个series至少有1000个数据点