schema设计
Last updated
Was this helpful?
Last updated
Was this helpful?
每个InfluxDB用例都可能是不一样的，schema将反映出这种独特性。 但是，在设计schema时，有一些遵循的一般准和可以避免的陷阱。
没有特定的顺序，我们有如下建议：
一般来说，你的查询可以指引你哪些数据放在tag中，哪些放在field中。
把你经常查询的字段作为tag
如果你要对其使用GROUP BY()，也要放在tag中
如果你要对其使用InfluxQL函数，则将其放到field中
如果你需要存储的值不是字符串，则需要放到field中，因为tag value只能是字符串
这不是必需的，但它简化了写查询; 您不必将这些标识符包装在双引号中。 标识符有database名称，retention policy名称，user名，measurement名称，tag key和field key。请参阅看下哪些单词需要被避免。
请注意，如果查询中包含除[A-z，_]以外的字符，则还需要将它们用双引号括起来。
没有特定的顺序，我们有如下建议：
tags包含高度可变的信息，如UUID，哈希值和随机字符串，这将导致数据库中的大量measurement，通俗地说是高series cardinality。series cardinality高是许多数据库高内存使用的主要原因。
一般来说，谈论这一步可以简化你的查询。InfluxDB的查询会合并属于同一measurement范围内的数据; 用tag区分数据比使用详细的measurement名字更好。
例如：考虑如下的schema：
这个没有tag的长长的measurement名字(blueberries.plot-1.north)有些类似于Graphite的metric。像plot``region这样的信息放在measurement名字里面将会使数据很难去查询。
例如，使用schema 1计算两个图1和2的平均temp是不可能的。将其与如下schema进行比较：
以下查询计算了落在北部地区的蓝莓的平均temp。 虽然这两个查询都比较简单，但使用正则表达式使得某些查询更加复杂或根本不可能实现。
与上述相似，将具有多条信息的单个tag拆分为多个单独的tag将简化查询并减少对正则表达式的需求。
例如，考虑如下的schema：
上述数据将多个单独的参数plot``region放到了一个长tag value里面（plot-1.north）。 将其与如下schema进行比较：
以下查询计算了落在north地区的蓝莓的平均temp。 虽然这两个查询都是相似的，但在Schema 2中使用多个tag避免了使用正则表达式。
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
通常，较短的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个数据点
请参阅中基于你的硬件的series cardinality的建议。如果系统有内存限制，请考虑将高cardinality数据存储为field而不是tag。
在每个RP上shard group的duration也是可以配置的，可以看看如何配置shard group的duration。