180726-InfluxDB基本概念小結

InfluxDB基本概念小結

InfluxDB作為時序數據庫，與傳統的關系型數據庫相比而言，還是有一些區別的，下面盡量以簡單明了的方式介紹下相關的術語概念

I. 基本概念

mysql	influxdb	說明
database	database	數據庫
table	measurement	類似mysql中表的概念
record	tag + field + timestamp	傳統表中的一行數據，映射到influxdb中，可以划分為三個

1. database

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

2. measurement

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

3. Point

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

• 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. 實例分析

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

建立一個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文件）中。

IV. 其他

1. 一灰灰Blog： https://liuyueyi.github.io/hexblog

一灰灰的個人博客，記錄所有學習和工作中的博文，歡迎大家前去逛逛

2. 聲明

盡信書則不如，已上內容，純屬一家之言，因個人能力有限，難免有疏漏和錯誤之處，如發現bug或者有更好的建議，歡迎批評指正，不吝感激

• 微博地址: 小灰灰Blog
• QQ： 一灰灰/3302797840

3. 掃描關注

小灰灰Blog&公眾號

知識星球