時序資料庫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. 聲明

• 微網誌位址: ​​小灰灰Blog​​