InfluxDb中的关键概念
在深入InfluxDB之前,我们需要了解数据库的一些关键概念。本文档简要介绍了这些常用的InfluxDB术语。
下面是一些中文术语,有些好翻译,有些不好翻译,边学边解释吧。
database | field key | field set |
---|---|---|
field value | measurement | point |
retention policy | series | tag key |
tag set | tag value | timestamp |
示例数据
讲解概念前,我们将用下面的数据结合概念一起解释。虽然数据是伪造的,但在InfluxDB中这些数据是非常典型的。
数据展示了在2015年8月18日0点至2015年8月18日上午6时12分在两个地点location
(地点1
和地点2
),显示两名科学家scientists
(科学家的名字是langstroth
和perpetua
)计数的蝴蝶(butterflies
)和蜜蜂(honeybees
)数量。 假设数据存在名为my_database
的数据库中,而且存储策略是autogen
。
表名(动物普查表): census
time | butterflies | honeybees | location | scientist |
---|---|---|---|---|
2015-08-18T00:00:00Z | 12 | 23 | 1 | langstroth |
2015-08-18T00:00:00Z | 1 | 30 | 1 | perpetua |
2015-08-18T00:06:00Z | 11 | 28 | 1 | langstroth |
2015-08-18T00:06:00Z | 3 | 28 | 1 | perpetua |
2015-08-18T05:54:00Z | 2 | 11 | 2 | langstroth |
2015-08-18T06:00:00Z | 1 | 10 | 2 | langstroth |
2015-08-18T06:06:00Z | 8 | 23 | 2 | perpetua |
2015-08-18T06:12:00Z | 7 | 22 | 2 | perpetua |
census是人口普查的意思,这里是指普查动物数据。
其中census是measurement
,butterflies和honeybees是field key
,location和scientist是tag key
。
measurement表示翻译为 测量、度量的意思。真的不好理解,如果你学习过mysql,那么它就相当于table表的意思。为什么叫measurement,测量,度量呢?老师认识,因为measurement表中存放了时序数据,这些数据都是不断统计出来的,所以有测量的意思。
mysql中用表,因为mysql中,例如用户数据,是系统录入的,不是设备测量出来的,所以在MySQL中用表更准确。
influxdb中tag和field的区别
好了,我们来解释一下tab和filed吧,翻译为表情和字段。妈妈的,又是一个难以理解的概念,不对,是2个。
现在您已经在InfluxDB中看到了一些示例数据,本节将详细分析这些数据。
InfluxDB是一个时间序列数据库,因此我们开始一切的根源就是——时间。时间是数据库表中最重要的组成部分,没有时间,就不叫时序数据库了。
在上面的数据中第一列是time
,在InfluxDB中所有的数据都有这一列。time
存着时间戳,这个时间戳以RFC3339格式展示了与特定数据相关联的UTC日期和时间。这篇文章读起来,有点难懂,热心的同学,可以找一下是否有中文文档,发给我,我们弄出来共享给大家哦。加老师微信吧:daimajimu
接下来两个列叫作butterflies
和honeybees
,称为字段(fields)。fields由field key和field value组成。field key(butterflies
和honeybees
)都是字符串,他们存储元数据;field key butterflies
告诉我们蝴蝶的计数是7到12只;field key honeybees
告诉我们蜜蜂的计数从22变到30只。
field我翻译为字段,可以理解成mysql中的字段。
field value就是你的数据,它们可以是字符串、浮点数、整数、布尔值。
在示例中,field value如下:
12 23 1 30 11 28 3 28 2 11 1 10 8 23 7 22
字段集field set
在上面的数据中,每组field key和field value的集合组成了field set
,在示例数据中,有八个field set
,每一行是一个字段集合。
butterflies = 12 honeybees = 23 butterflies = 1 honeybees = 30 butterflies = 11 honeybees = 28 butterflies = 3 honeybees = 28 butterflies = 2 honeybees = 11 butterflies = 1 honeybees = 10 butterflies = 8 honeybees = 23 butterflies = 7 honeybees = 22
其实很简单,就是key和值组成的集合,感觉都不需要怎么解释,越解释越乱。
反正你记住,一行数据,就一个field set集合就可以了。
不要使用field作为查询条件
字段field是InfluxDB数据结构所必需的一部分, 在InfluxDB中不能没有field。需要注意的是,field是没有索引的。如果使用field value作为过滤条件来查询,这样的查询非常慢,请不要使用field value作为查询条件。重要的说3次:
- 请不要使用field value作为查询条件
- 请不要使用field value作为查询条件
- 请不要使用field value作为查询条件
虽然说了3次,但是不要被误导了,用field作为查询条件语法不会有错的。
样本数据中的最后两列(location
和scientist
)就是标签(tag)。tag由tag key和tag value组成。 tag key和tag value都作为字符串存储,并记录在元数据中。示例数据中的tag key是location
和scientist
。 location
有两个tag value:1
和2
。scientist
还有两个tag value:langstroth
和perpetua
。
在上面的数据中,tag set是不同的每组tag key和tag value的集合,示例数据里有四个tag set:
location = 1, scientist = langstroth location = 2, scientist = langstroth location = 1, scientist = perpetua location = 2, scientist = perpetua
tag设计的原因
tag不是必需的字段,但是在你的数据应该尽量使用tag,因为field是没有索引的, tag是有索引的。这意味着对tag的查询更快,tag是存储常用元数据的最佳选择。
有无索引,是tag和field最主要的区别,另外是类型,tag只可以是字符串。
为什么要设计一个tag呢,其实还是为了查询效率,influxdb对tag做了特殊处理,tag有索引,所以tag会查询快,但是索引也会增加数据写入Influxdb的时间,所以tag也不能太多。
总之,存在即是合理,不要纠结。
不同场景下的数据结构设计
如果你说你的大部分的查询集中在字段honeybees
和butterflies
上:
下面第一句是查询蝴蝶的数量为1 的记录。第2句是查询蜜蜂的数量为23的记录。
SELECT * FROM "census" WHERE "butterflies" = 1 SELECT * FROM "census" WHERE "honeybees" = 23
因为field是没有索引的,在第一个查询里面InfluxDB会扫描所有的butterflies
的值,第二个查询会扫描所有honeybees
的值。这样会使请求时间很长,特别在规模很大时。为了优化你的查询,你应该重新设计你的数据结果,把field(butterflies
和honeybees
)改为tag。
name: census
time | location | scientist | butterflies | honeybees |
---|---|---|---|---|
2015-08-18T00:00:00Z | 1 | langstroth | 12 | 23 |
2015-08-18T00:00:00Z | 1 | perpetua | 1 | 30 |
2015-08-18T00:06:00Z | 1 | langstroth | 11 | 28 |
2015-08-18T00:06:00Z | 1 | perpetua | 3 | 28 |
2015-08-18T05:54:00Z | 2 | langstroth | 2 | 11 |
2015-08-18T06:00:00Z | 2 | langstroth | 1 | 10 |
2015-08-18T06:06:00Z | 2 | perpetua | 8 | 23 |
2015-08-18T06:12:00Z | 2 | perpetua | 7 | 22 |
现在butterflies
和honeybees
是tag了,当你再用上面的查询语句时,就不会扫描所有的值了,这也意味着查询更快了。
最后,我在重复一次measurement的概念, measurement是一个表,是作为tag,fields和time列的容器,或者说measurement包含tag,fields和time。measurement的名字是字符串,对于一些SQL用户,measurement在概念上类似于表。
如果你还是不懂,那么只能加我微信了:daimajimu。
保留策略retention policy
保留策略retention policy这个概念很难,后面还会讲解,这里先预热一下。retention是保留的意思。
单个measurement可以有不同的保留策略(retention policy)。 retention policy描述了InfluxDB保存数据的时间(DURATION)以及这些存储在集群中数据的副本数量(REPLICATION)。
注意:在单节点的实例下,副本Replication系数不管用,因为单机下一份数据只能存储一份。
在样本数据中,measurement census
中的所有内容都属于autogen
的retention policy。 InfluxDB自动创建该存储策略; autogen表示数据无限存储,不会过期,副本数是1。
哈哈,看了这些,你肯定什么都不懂,没关系,后面仔细讲这个的时候,再说吧。
什么是序列series
现在你已经熟悉了measurement,tag set和retention policy,那么现在是讨论series的时候了。在InfluxDB中,series是retention policy,measurement和tag set的集合。
靠,是不是更难理解。
以上数据由四个series组成:
任意series编号 | retention policy | measurement | tag set |
---|---|---|---|
series 1 | autogen |
census |
location = 1,scientist = langstroth |
series 2 | autogen |
census |
location = 2,scientist = langstroth |
series 3 | autogen |
census |
location = 1,scientist = perpetua |
series 4 | autogen |
census |
location = 2,scientist = perpetua |
理解series对于设计数据schema以及对于处理InfluxDB里面的数据都是很有必要的。
我相信到这里,你还是不理解什么是序列,没关系,后面会更详细介绍,现在只要记住serie这个名词就可以了
什么是point
最后,point就是一行数据,为什么叫点,是因为在物联网中,从设备中上来一行数据,我们叫做一个点,而InfluxDb主要用在物联网中,所以这样命名就没问题了。例如,这就是一个point:
time | butterflies | honeybees | location | scientist |
---|---|---|---|---|
2015-08-18T00:00:00Z | 1 | 30 | 1 | perpetua |
例子里的series的保留策略retention policy为autogen
,measurement为census
,tag set为location = 1, scientist = perpetua
。point的timestamp为2015-08-18T00:00:00Z
。