InfluxDb中的关键概念

在深入InfluxDB之前，我们需要了解数据库的一些关键概念。本文档简要介绍了这些常用的InfluxDB术语。

下面是一些中文术语，有些好翻译，有些不好翻译，边学边解释吧。

示例数据

讲解概念前，我们将用下面的数据结合概念一起解释。虽然数据是伪造的，但在InfluxDB中这些数据是非常典型的。

数据展示了在2015年8月18日0点至2015年8月18日上午6时12分在两个地点location（地点1和地点2），显示两名科学家scientists（科学家的名字是langstroth和perpetua）计数的蝴蝶(butterflies)和蜜蜂(honeybees)数量。 假设数据存在名为my_database的数据库中，而且存储策略是autogen。

表名（动物普查表）: census

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

现在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对于设计数据schema以及对于处理InfluxDB里面的数据都是很有必要的。

我相信到这里，你还是不理解什么是序列，没关系，后面会更详细介绍，现在只要记住serie这个名词就可以了

什么是point

最后，point就是一行数据，为什么叫点，是因为在物联网中，从设备中上来一行数据，我们叫做一个点，而InfluxDb主要用在物联网中，所以这样命名就没问题了。例如，这就是一个point：

例子里的series的保留策略retention policy为autogen，measurement为census，tag set为location = 1, scientist = perpetua。point的timestamp为2015-08-18T00:00:00Z。