【开发笔记】那些关于开箱 InfluxDB 的起手式
从几年前，只要是涉及 IoT 方面数据的储存与计算，数据库 InfluxDB 一直是个人心目中的首选
虽然说是类似 SQL 的查询语言
从几年前，只要是涉及 IoT 方面数据的储存与计算，数据库 InfluxDB 一直是个人心目中的首选。除了数据库容易部署以外，易学易用是其最大的原因。不过 InfluxDB 虽然提供了一个类似 SQL 的查询语言。不过在基本概念的理解上，还是有些相当不同的地方需要注意。
数据库就是要关心索引
InfluxDB 数据的逻辑结构，是由 measurement, tag, field, timestamp 组成。不消分说timestamp 是最基本必然会有的部分，也是索引的基础元素之一。而 tag 虽然和 field 都是由键值对组成，但是 tag 数据在存入的同时，总是会被索引处理。field 的话，虽然无法被索引，但是聚合的计算元素则是来自于 field。 最后 measurement 比较容易理解，其实相当于表的概念。
上手范例
其实理论说得再多也没用，实际先操练一遍会比较容易有概念。
# 显示数据库
SHOW DATABASES
# 选择数据库
USE my_db
# 显示 measurement
SHOW MEASUREMENTS
# 降幂排列显示 my_measurement 最新的数据，上限 10 笔（无限制选取特定时间段的数据，所以速度较慢）
SELECT * FROM "my_measurement" ORDER BY time DESC LIMIT 10
# 将 timestamp 以 rfc3339 格式显示有利于阅读
precision rfc3339
# 降幂排列显示 my_measurement 10 分钟内的数据，上限 10 笔（限制仅选取 10 分钟内的数据，所以速度较快）
SELECT * FROM "my_measurement" WHERE time < now() AND time > now() - 10m ORDER BY time DESC LIMIT 10
# 降幂排列显示 my_measurement 10 分钟内的数据，加上 tag 条件与上限 10 笔
SELECT * FROM "my_measurement" WHERE "my_condition"='my_condition_value' AND time < now() AND time > now() - 10m ORDER BY time DESC LIMIT 10
# 显示 my_measurement 所有 tag 名称
SHOW TAG KEYS FROM my_measurement
# 显示 my_measurement 所有 field 名称
SHOW FIELD KEYS FROM my_measurement
# 三天内以 10 分钟为间距，计算 my_value 的平均值，并且在数据为空的时间间距填上 0
SELECT MEAN("my_value") FROM "my_measurement" WHERE time < now() AND time > now() - 3d GROUP BY time(10m) FILL(0) ORDER BY time DESC LIMIT 10
慎选 tag
新手常犯的错误，就是不管三七二十一，所有的数据都往 tag 里堆。也有人相同的数据内容，tag 和 field 都各存上了一份。首先是 tag 的部分，因为 tag 会不断地建立索引，而过多的索引对数据库带来的立即结果，就会短时间不断地膨胀数据。因此一般来说，不是很关键的查找依据，例如：设备序号。其实不建议当作 tag 来储存。多数的情况下，能够被计算或是大小比较的整数（或是浮点数），摆在 field 会是优先建议的考虑）。
数据写入后
同个 timestamp 下，写入过的 tag 是无法被编辑的。所以经过编辑的 tag ，在相同 timestamp 下储存，其实会产生两笔纪录。相对的，相同的 tag 与 timestamp 多次写入的结果，数据库中只会存在一笔（唯一性）。
简单暂时想到的新手提醒大致如上。若有疏漏或是更进阶运用，留待未来再继续补充吧😉