InfluxDB使用

一、安裝要求：

1. 需要Linux的root許可權進行安裝。
2. 由於會預設使用到8083和8086兩個埠，所以要保證這兩個埠沒有被佔用。
   

   Once installation is complete you can change those ports and other options in the configuration file, which is located by default in /etc/influxdb.
   

二、安裝：

這裡使用的Centos作業系統。 1. 首先在命令列執行下面的指令碼，生成所需的yum源： - cat

三、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 語言編寫。個人認為幾個外在的優點在於：

1. 無特殊依賴，幾乎開箱即用（如ES需要Java）；
2. 自帶HTTP管理介面，免外掛配置（如ES的kopf或者head）；
3. 自帶資料過期功能；
4. 類SQL查詢語句（再提ES，查詢使用自己的DSL，雖然也可以通過sql外掛來使用類SQL進行查詢）；
5. 自帶許可權管理，精細到“表”級別；

關鍵概念

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 可以看做是資料清理策略。基礎應用個人認為應該關注如下的一些引數：

1. DURATION，即儲存時間，有 m h d w
   INF幾種，即分，小時，天，周以及無限（Infinity）；
2. REPLICATION，即副本數，即會有多少份副本保留在叢集之中。

point

Point 即同一時間戳產生的資料的集合。

series

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

基本操作

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

CURD

CREATE

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

1. CLI
2. InfluxDB HTTP API

CLI

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

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

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

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

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

Line Protocol

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

1. 第一個欄位是表名
2. 如果有tag，表名之後使用英文逗號分隔，以k=v的方式逐個列出
3. field在前兩部分之後，用空格分隔開，之後所有的field，也使用英文逗號分隔，以k=v的方式逐個列出
4. 如果要指定時間戳，那麼在field之後，通過空格分隔，將納秒級別的時間戳寫入
5. 在 tag 的鍵，值，以及 field 的鍵中包含, 、= 以及空格的，需要進行轉義（變為, \= \），field 的值可以通過 英文雙引號 包裹起來（但是雙引號決定了這個值必然是一個字串）
6. 資料分為 string int64 float64 boolean 幾種型別
7. string 最大儲存的長度為64KB
8. float64 是預設的的型別，如果整數值要存成整數，需要在數字後通過字母 i 標明

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 即支援的時間片，支援的範圍有：

時間片單位	範圍
u	微秒
ms	毫秒
s	秒
m	分鐘
h	小時
d	天
ｗ	周

比如 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期望通過犧牲了資料的靈活性，換取了更好的寫入與查詢效能。==