InfluxDB使用

一、安裝要求：

二、安裝：

三、InfluxDB 配置文件：

位于/etc/influxdb/目錄下。

運行下面的命令即可：

influxd config > /etc/influxdb/influxdb.generated.conf

有一個與上面命令相似的：

influxd -config /etc/influxdb/influxdb.generated.conf

這2個命令其實是不同的，第一個只是生成一個config文件，不會啟動influxd進程。 下面的命令則會根據指定的配置文件，啟動influxd進程。

概述

InfluxDB是 InfluxData 公司發布的一款開源時序數據庫產品。

關于時序數據庫，除了常用的ElasticSearch之外，InfluxDB也是一個選擇。

InfluxDB 使用 go 語言編寫。個人認為幾個外在的優點在于：

關鍵概念

time

Time 在 InfluxDB 中的每一行數據中都會存在。

Time 即數據生成時的時間戳。

類比更為熟悉的 MySQL 來說，InfluxDB 中的 Time 幾乎可以看做是主鍵的代名詞了。

field

Field 在 InfluxDB 中是必須的數據的組成部分。

Field 未被索引。這意味著如果查詢field的話將會掃描所有數據，找出匹配項；手冊上也建議不要在field中存儲將會頻繁查詢的數據（存儲區分度更高的數據）。

類比 MySQL，Field 可以看做沒有索引的列。

tag

Tag 在 InfluxDB 中是可選的數據組成部分。

不同于 Filed，Tag 的數據會被索引。

類比 MySQL，Tag就是有索引的列。

measurement

InfluxDB 是時序數據庫，時間數據 time 與 Tag 以及 Field 組合成了 Measurement。

類比 MySQL，Measurement可以看做的是表。

retention policy

應用程序記錄日志的情況下，如果沒有關注，很有可能會出現打爆硬盤的情況出現。運維同學一般會在服務器上部署自動清理腳本。

在InfluxDB中，合理的設置了 Measurement 的 Retention Policy 的情況下，無需太過擔心磁盤被打爆的情況。

Retention Policy 可以看做是數據清理策略。基礎應用個人認為應該關注如下的一些參數：

point

Point 即同一時間戳產生的數據的集合。

series

Series 表示Measurement、Retention Policy、Tag都相同（tag的名稱與值）的一組數據，Field不在考慮衡量范圍之內。

基本操作

基本操作簡單提及數據的 CURD 以及數據庫管理方面的一些使用方式。

CURD

CREATE

在已創建數據庫的前提下，新增數據，可以通過兩種基本的方式進行數據的寫入：

CLI

CLI 自然與 MySQL 類似，通過 InfluxDB 提供的 CLI 工具，使用類 SQL 語句進行寫入。

但是 CLI 畢竟不是使用 InfluxDB 作為后端存儲的好方式，InfluxDB 也提供了非常方便的HTTP API 供開發者們使用。

InfluxDB 的特點是無結構的，即文檔中提到的 schemaless，可以隨時的動態增添數據域和表，所以使用時直接寫入，無需考慮關系型數據庫中類似建表等過程。

不過，CLI 雖然不能做到隨時隨地的的使用，但是類 SQL 語句還是在特定場景下還是有應用空間的（例如使用默認的Web管理端）。

CLI 寫入數據時，語法相當簡單，只需要使用：INSERT 數據 這樣的語句即可。但是數據部分有InfluxDB自己的一些協議，目前在使用的規則叫做 Line PRotocol。

Line Protocol

總結一下，簡單來說，可以關注如下的特點：

InfluxDB HTTP API

InfluxDB 啟動后，會默認監聽 8086 端口，在這一端口上可以通過 HTTP POST 的方式，請求 /write ，寫入數據。

寫入方式手冊已很清楚，即將 Line Protocol 格式的的數據提交到 InfluxDB 之上。

需要注意的是，InfluxDB 在通過HTTP方式操作時，需要注意下HTTP的狀態碼，尤其要注意204這一狀態碼，InfluxDB在返回這一狀態碼時認為請求合理但是并未完成，當返回這一個數值是需要注意HTTP的body段中附加的錯誤信息。至于4xx與5xx則是真的存在錯誤的情況。

時序相關

既然是時序數據庫，那么時間作為重要的維度需要單獨一提。

通過 Line Protocol 寫入數據時，如果沒有指定時間，將會根據系統時間指定時間，所以手冊中提到：

If you do not specify a timestamp for your data point InfluxDB uses the server’s local nanosecond timestamp in UTC.

這個和 ES 的默認行為不太相同，所以這里需要注意。

如果要人工指定時間，需要按照 RFC3389 里提及的格式指定，即指定一個ns級別的時間戳，形如1465839830100400200。

RETRIEVE

與 CREATE 這一動作相同，數據的獲取同樣可以通過在 CLI 中執行InfluxQL（即InfluxDB中定義的類 SQL 語言），或者通過 HTTP API 提交查詢語句的方式進行。通過 HTTP API 訪問的話，InfluxDB會返回JSON格式的數據。

InfluxDB使用類 SQL 語言進行查詢，確實是降低了使用的門檻，類似 SQL 的 SELECT GROUP BY LIMIT ORDER BY 操作的用法參見手冊。

GROUP BY

值得一提的是，作為時序數據庫，InfluxDB在查詢上有一些時間相關的操作，例如 GROUP BY 操作可以按照時間戳進行聚合，獲得每個時間片級別上的聚合數據。即通過 GROUP BY time(interval) 方法進行聚合，interval 即支持的時間片，支持的范圍有：

比如 time(3d) 表示按照3天作為周期進行聚合。

同時 fill() 方法也是一個有意思的功能，使用 GROUP BY 之后，如果某個聚合的結果內沒有值，可以通過 fill() 設定為自己需要的值。更詳細的用法參見手冊。

INTO

如果說上述的的一些操作看起來和平常使用的關系型數據庫沒有特別大的區別的話，我想從 INTO 開始，InfluxQL就體現出時序數據庫的一些特點了。

比如機器性能數據的采集，數據點多了之后，很可能我們期望能夠看到的不是單一時間點上的數據，而是機器階段性的表現和趨勢，這樣的數據自然可以通過聚合具體的采集數據獲得，但是為什么不直接讀取已經聚合完成的數據并展現呢？重復的計算是對機器性能的巨大浪費。

通常情況下，我們可能需要編寫程序完成這樣的工作，但是在InfluxDB中，可以通過內置的 INTO 語句來完成，無需額外的工作。

SELECT MEAN(“water_level”) INTO “average” FROM “h2o_feet” WHERE “location” = ‘santa_monica’ AND time >= ‘2015-08-18T00:00:00Z’ AND time <= ‘2015-08-18T00:30:00Z’ GROUP BY time(12m)

即在2015-08-18T00:00:00Z到2015-08-18T00:30:00Z的時間范圍內，將每12分鐘在santa_monica區域的水位的平均值存入average表中。

如是，如果要了解平均值，無需重復計算原始數值。

對于實際業務來說，統計接口PV/UV的場景很適合使用這一個子句，因為階段統計中，并不關心具體的訪問用戶，而是期望了解趨勢（對于UV的定義需要結合實際的業務場景）。

LIMIT & SLIMIT

LIMIT 限制的是數據的行數，而 SLIMIT 限制的則是返回的 Series 的個數，如果二者都要限制，則先設定 LIMIT，之后再設定 SLIMIT。

OFFSET & SOFFSET

分頁是查詢數據的一個基本方式，InfluxQL中通過 OFFSET 以及 SOFFSET 進行。

類似 LIMIT & SLIMIT， OFFSET 是針對數據行的翻頁，SOFFSET 是針對 Series 的翻頁。

時序相關

時序數據庫，自然查詢的數據經常會與時間有關。前面提及的時間單位，在選定時間范圍時，可以通過組合簡化時間區間的確定。

例如選出當前時間前3天到5小時前的數據，那么只需要指定條件為time >= now() - 3d AND time < now() - 5h即可。

UPDATE & DELETE

InfluxDB不存在常規意義上的 UPDATE 和 DELETE 這些動作！需要注意！

InfluxDB的設計初衷是為了記錄時序相關的數據，這些數據被認為是不常變的，并且是僅僅有一次寫入操作的（瞬時應當是唯一的）。

==綜上，InfluxDB期望通過犧牲了數據的靈活性，換取了更好的寫入與查詢性能。==