180726-InfluxDB基本概念小結

時間 2019-11-16

標籤 influxdb 基本概念小結简体版

原文原文鏈接

InfluxDB基本概念小結

InfluxDB做爲時序數據庫，與傳統的關係型數據庫相比而言，仍是有一些區別的，下面儘可能以簡單明瞭的方式介紹下相關的術語概念mysql

I. 基本概念

mysql	influxdb	說明
database	database	數據庫
table	measurement	相似mysql中表的概念
record	tag + field + timestamp	傳統表中的一行數據，映射到influxdb中，能夠劃分爲三個

1. database

數據庫，和mysql的數據庫相比，沒有太大的歧義git

2. measurement

對比的是mysql中的table，從實際體驗來看，兩個之間最明顯的區別在於沒有單獨的建立measurement的方法，直接新增一條數據時，若measurement不存在，則直接建立並插入一條數據github

3. Point

這個對比的是mysql中的record，在influxDB中，表示每一個表中，某個時刻，知足某個條件的filed數據（簡單來講就是 timestamp + tag + filed)的組成一個pointsql

timestamp : 時間戳，ns單位，每一個記錄都必然有這個屬性，沒有顯示添加時，默認給一個
tag: 標籤，kv結構，在database中， tag + measurement 一塊兒構建索引
- 參與索引建立，所以適合做爲查詢的過濾條件
- tag的數據量不要太多，最好能有典型的辨別性（和mysql的創建索引的原則差很少）
- value爲String類型
- tag是可選的，在measurement不設置tag也是ok的
field：存儲數據，kv結構
- 數據類型爲: long, String, boolean, float

4. Series

Series: tag key 與tag value的惟一組合數據庫

II. 實例分析

上面幾個爲基本的概念，單獨的看起來印象不夠深入，下面結合實例進行說明：app

創建一個measurement,保存某個應用的性能情況，包含如下指標, 每秒寫一次數據到influxDB中性能

服務機器: host=127.0.0.1
服務接口: service=app.service.index
qps: qps=1340
rt: 1313
cpu: 45.23
mem: 4154m
load: 1.21

1. measurement建立

上面有7個指標參數，第一步就是區分tag和field，前面說到tag會建索引，推薦用於能夠區分類型，取值能夠預估的字段，因此對上面進行以下區分學習

tag大數據

host
servie

field編碼

qps
rt
cpu
mem
load

一條實際的插入數據如

> insert myapp,host=127.0.0.1,service=app.service.index qps=1340,rt=1313,cpu=45.23,mem="4145m",load=1.21
> select * from myapp
name: myapp
time                cpu   host      load mem   qps  rt   service
----                ---   ----      ---- ---   ---  --   -------
1532597158613778583 45.23 127.0.0.1 1.21 4145m 1340 1313 app.service.index
複製代碼

a. 小結說明

在insert執行語句中，tag與tag、field與field之間用都好進行分割，tag與field之間用空格分割
tag的value都是，String類型，不須要加雙引號
field的String類型數據，須要放在雙引號中，不然會報錯
若是須要顯示添加時間戳，在filed後添加空格，再添加時間戳

b. 是否能夠沒有field

實測不行，輸出以下

> insert myabb,host=123,service=index
ERR: {"error":"unable to parse 'myabb,host=123,service=index ': invalid field format"}
複製代碼

是否能夠沒有tag

根據前面的說明已經實測，能夠

> insert myabb qps=123,rt=1231
> select * from myabb
name: myabb
time                qps rt
----                --- --
1532597385053030634 123 1231
複製代碼

2. 數據分析

新插入幾條數據，目前的數據爲

> select * from myapp
name: myapp
time                cpu   host      load mem   qps  rt   service
----                ---   ----      ---- ---   ---  --   -------
1532597158613778583 45.23 127.0.0.1 1.21 4145m 1340 1313 app.service.index
1532597501578551929 45.23 127.0.0.1 1.21 4145m 1341 1312 app.service.index
1532597510225918132 45.23 127.0.0.1 1.21 4145m 1341 1312 app.service.about
1532597552421996033 45.23 127.0.0.2 1.21 4145m 1341 1312 app.service.about
複製代碼

a. series

上面四條數據，對應幾個series呢？

根據前面的說法，tagKey + tagValue 肯定給一個series （其實是 measurement + retention policy + tags來肯定)，所以上表總共有三個series

127.0.0.1 | app.service.index
127.0.0.1 | app.service.about
127.0.0.2 | app.service.about

那麼這個series究竟是什麼東西呢？

若是將上面的數據圖表化的方式顯示出來，咱們能夠怎麼辦？

首先咱們肯定好應用及其和服務名，而後查看這個服務在這臺機器上，在時間線上的服務性能
翻譯過來就是，將cpu/service做爲檢索條件，以time爲時間軸，將value(cpu,load,mem,qps,rt)映射到二維座標上做爲一個點（point），而後將全部的point鏈接成線，最終獲得連續的圖表

因此series就是上面的檢索條件，同時point的概念也容易理解了

III. 保留策略

前面是表數據的相關基礎概念，這裏還有一個就是數據保存的策略 retention policy, 用於決定數據保存多久（意思是數據能夠刪除），保存幾個備份，集羣的處理等

1. 基本說明

influxdb面向大數據的時序數據庫，因此數據量能夠很大很大，若是所有存儲，估計硬盤的費用都不小，並且有些數據可能並不須要永久存儲，所以就有了這個rentention policy

InfluxDB自己不提供數據的刪除操做，所以用來控制數據量的方式就是定義數據保留策略。

所以定義數據保留策略的目的是讓InfluxDB可以知道能夠丟棄哪些數據，從而更高效的處理數據。

2. 基本操做

a. 查詢策略

> show retention policies on hh_test
name    duration shardGroupDuration replicaN default
----    -------- ------------------ -------- -------
autogen 0s       168h0m0s           1        true
複製代碼

name: 名稱
duration: 保留時間, 0表示永久保存
shardGroupDuration: shardGroup的存儲時間，shardGroup是InfluxDB的一個基本儲存結構，應該大於這個時間的數據在查詢效率上應該有所下降。
replicaN: 全稱是REPLICATION，副本個數
default: 是不是默認策略

b. 新建策略

> create retention policy "2_hour" on hh_test duration 2h replication 1 default
> show retention policies on hh_test
name    duration shardGroupDuration replicaN default
----    -------- ------------------ -------- -------
autogen 0s       168h0m0s           1        false
2_hour  2h0m0s   1h0m0s             1        true
複製代碼

c. 修改策略

> alter retention policy "2_hour" on hh_test duration 4h default
> show retention policies on hh_test
name    duration shardGroupDuration replicaN default
----    -------- ------------------ -------- -------
autogen 0s       168h0m0s           1        false
2_hour  4h0m0s   1h0m0s             1        true
複製代碼

d. 刪除策略

> drop retention policy "2_hour" on hh_test
> show retention policies on hh_test
name    duration shardGroupDuration replicaN default
----    -------- ------------------ -------- -------
autogen 0s       168h0m0s           1        false
複製代碼

刪除默認策略以後，就沒有默認策略了，是否會有問題呢？

3. RP理解

設置這個策略以後，會自動刪除過時的數據，那麼數據時怎麼保存的呢？

好比默認的永久保存策略中，有個 shardGroupDuration 參數，爲7天，也就是說7天的數據放在一個Shard中，過了以後，新加一個Shard

shard包含實際的編碼和壓縮數據，並由磁盤上的TSM文件表示。每一個shard都屬於惟一的一個shard group。多個shard可能存在於單個shard group中。每一個shard包含一組特定的series。給定shard group中的給定series上的全部點將存儲在磁盤上的相同shard（TSM文件）中。