InfluxDB与传统数据库在概念上有许多的不同，本文主要介绍InfluxDB中数据结构的基本概念，以及使用中要注意问题。
一、与传统数据库中的名词做比较
| influxDB中的名词 | 传统数据库中的概念 | 解释 |
|---|---|---|
| database | database | 数据库 |
| measurement | table | 数据库中的表 |
| points | record | 表里面的一行数据 |
| retention policy | partition policy | 数据保留策略：InfluxDB不提供删除操作，通过设置数据保留策略批量删除过期的数据 |
二、InfluxDB中独有的概念
时间戳是时序数据库的灵魂，其他数据库对时间戳非常不友好，具体表现在如下几点：
- 数据记录：必须带时间戳
- 数据存储：按照时间排列
- 数据查询：必须带时间条件
2.1 Point
Point相当于传统数据库里的一行数据，它由时间（time）、维度（tags）、以及指标（field）、组成。如下表所示：
| 英文名称 | 中文名称 | 含义 |
|---|---|---|
| time | 时间列 | 每个数据记录时间，是数据库中的主索引(会自动生成) |
| tags | 维度列 | 各种有索引的属性：地区，海拔 |
| fields | 指标列 | 各种记录值（没有索引的属性）也就是记录的值：温度， 湿度 |
时序数据存储
2.2 series
series的概念稍微有点复杂，它表示的是所有tags值得排列组合。
下面举一个具体一点的案例。假设现有measurement表cpu有两个tag，分别是cpu和host，前者表示cpu的核编号，后者表示机器名。加入有两台机器ResourcePool-0246-billing07和billing07，他们都有两个核cpu1和cpu2，那么这两个tag的排列组合就有4个，因此使用show series from cpu查询出来的结果就有四条记录。如果将它们各自关联的数据点按照时间序列描绘在一张图上，那么可以画出四条折线。因为它们代表着四个实例，每个实例都需要cpu和host两个tag组合起来才能唯一描述。
> show series from cpu
key
cpu,cpu=cpu1,host=ResourcePool-0246-billing07
cpu,cpu=cpu1,host=billing07
cpu,cpu=cpu2,host=ResourcePool-0246-billing07
cpu,cpu=cpu2,host=billing07
三、使用注意
3.1 坑点
- influxdb只有插入(insert)和查询(select)语句，没有更新(update)和删除(delete)语句。
- time 相当于表的主键，当一条数据的time和tags完全相同时候，新数据会替换掉旧数据，旧数据则丢失（线上环境尤其要注意）。
- tags 和time可以作为排序字段，field则不可以。如：
ORDER BY time DESC. - 设置了保存策略后，若此保存策略为设置成默认保存策略（一个库可以有多个保存策略），则在查询时，表名（measurement）前，要加上保存策略。
举例：
保留策略为two-hour不是默认保存策略，则查询时候，需要指定其保存策略。例如查询表cpu中使用非默认策略two-hour保存的数据：
select * from two-hour.cpu where time > now() -10
- fields和tags的字段类型是由存入的第一条记录值决定，一旦确定，后序不得变更，否则数据插入将失败。
举例：
- 如第一条记录fieldA的值为2，想插入一条记录，fieldA字段值为3.14的值，就会报错。因为该字段已经被初始化为整型了。
- 如第一条记录fieldB存储的是3,想插入一条记录，fieldB字段值为hello,则也会报错，该字段已被初始化成整型，不能再写入字符串了。
避坑提示：建议只使用字符串类型和浮点类型，把所有的整型，长整型，浮点型，双精度型统一转为小数格式的浮点类型，再写入数据库，字符串类型的不用做转换，这样就不会出现插入数据失败和丢失数据了。
