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(科学家的名字是langstrothperpetua)计数的蝴蝶(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

接下来两个列叫作butterflieshoneybees,称为字段(fields)。fields由field key和field value组成。field key(butterflieshoneybees)都是字符串,他们存储元数据;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作为查询条件语法不会有错的。

样本数据中的最后两列(locationscientist)就是标签(tag)。tag由tag key和tag value组成。 tag key和tag value都作为字符串存储,并记录在元数据中。示例数据中的tag key是locationscientistlocation有两个tag value:12scientist还有两个tag value:langstrothperpetua

在上面的数据中,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也不能太多。

总之,存在即是合理,不要纠结。


不同场景下的数据结构设计

如果你说你的大部分的查询集中在字段honeybeesbutterflies上:

下面第一句是查询蝴蝶的数量为1 的记录。第2句是查询蜜蜂的数量为23的记录。

SELECT * FROM "census" WHERE "butterflies" = 1
SELECT * FROM "census" WHERE "honeybees" = 23

因为field是没有索引的,在第一个查询里面InfluxDB会扫描所有的butterflies的值,第二个查询会扫描所有honeybees的值。这样会使请求时间很长,特别在规模很大时。为了优化你的查询,你应该重新设计你的数据结果,把field(butterflieshoneybees)改为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

现在butterflieshoneybees是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