【開發筆記】那些關於開箱 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 多次寫入的結果，資料庫中只會存在一筆（唯一性）。

簡單暫時想到的新手提醒大致如上。若有疏漏或是更進階運用，留待未來再繼續補充吧😉