時序型數據庫InfluxDB前世此生

InfluxDB是一個由InfluxData開發的開源時序型數據庫。它由Go寫成，着力於高性能地查詢與存儲時序型數據。InfluxDB被普遍應用於存儲系統的監控數據，

它仍是沒有額外依賴的開源時序數據庫，用於記錄 metrics、events，進行數據分析。 何謂時間序列數據庫？

什麼是時間序列數據庫，最簡單的定義就是數據格式裏包含Timestamp字段的數據，好比某一時間環境的溫度，CPU的使用率等。 可是，有什麼數據不包含Timestamp呢？幾乎全部的數據其實均可以打上一個Timestamp字段。時間序列數據的更重要的一個屬性是如何去查詢它，包括數據的過濾，計算等等。 通常時間序列數據都具有以下兩個特色：

數據結構簡單 數據量大 所謂的結構簡單，能夠理解爲某一度量指標在某一時間點只會有一個值，沒有複雜的結構（嵌套、層次等）和關係（關聯、主外鍵等）。

數據量大則是另外一個重要特色，這是因爲時間序列數據由所監控的大量數據源來產生、收集和發送，好比主機、物聯網設備、終端或App等。

1、InfluxDB 簡介

InfluxDB主要特點功能 1.基於時間序列，支持與時間有關的相關函數（如最大，最小，求和等）

2.可度量性：你能夠實時對大量數據進行計算

3.基於事件：它支持任意的事件數據

InfluxDB的主要特色 1.無結構（無模式）：能夠是任意數量的列

2.可拓展的

3.支持min, max, sum, count, mean, median 等一系列函數，方便統計

4.原生的HTTP支持，內置HTTP API

5.強大的類SQL語法

6.自帶管理界面，方便使用

官網文檔：docs.influxdata.com/influxdb/v1…

2、InfluxDB安裝

本文以操做系統RedHat & CentOS爲例，介紹下InfluxDB最新版本的安裝。RedHat和CentOS用戶能夠直接用yum包管理來安裝最新版本的InfluxDB。

cat <<EOF | sudo tee /etc/yum.repos.d/influxdb.repo
[influxdb]
name = InfluxDB Repository - RHEL \$releasever
baseurl = https://repos.influxdata.com/rhel/\$releasever/\$basearch/stable
enabled = 1
gpgcheck = 1
gpgkey = https://repos.influxdata.com/influxdb.key
EOF
複製代碼

一旦加到了yum源裏面，就能夠運行下面的命令來安裝和啓動InfluxDB服務：

sudo yum install influxdb

目前最新版本爲1.7.3-1

3、InfluxDB啓動

1.服務端啓動 若是是經過包安裝的，可使用以下語句啓動：

sudo service influxdb start 這樣就啓動了服務端

2.客戶端 在usr/bin裏使用influx便可登入Influx服務器。也能夠將路徑加入環境變量中，這樣既可在任意地方使用influx。

命令啓動客戶端，以下圖：

早期版本的InfluxDB自帶web管理界面，在瀏覽器中輸入 http://服務器IP:8083 便可進入web管理頁面。

不過從版本1.3開始，Web管理界面在InfluxDB中再也不可用。而官方給出使用Chronograf用於查詢數據，寫入數據和數據庫管理的改進工具取代了Web管理界面。

後面咱們詳細介紹一下Chronograf

4、InfluxDB相關操做

1.開啓認證

建立管理員

修改配置文件，開啓認證

重啓InfluxDB：

systemctl restart influxdb

再次登陸

客戶端工具鏈接數據庫：

注：這裏的-precision參數指定了時間戳的格式爲rfc3339，也能夠不使用該參數。

2.相關概念 influxDB相關名詞

database：數據庫。

measurement：數據庫中的表。它就是tag，field，time的容器；對於influxDB的measurement來講，field是必須的，而且不能根據field來排序；

Tag是可選的，tag能夠用來作索引，tag是以字符串的形式存放的。

points：表裏面的一行數據。

influxDB中獨有的概念

（1）Point由時間戳（time）、數據（field）和標籤（tags）組成。

time：每條數據記錄的時間，也是數據庫自動生成的主索引；

fields：各類記錄的值；

tags：各類有索引的屬性。

InfluxDB不須要作schema定義，這意味着你能夠隨意的添加measurements, tags, and fields at any time。

（2）series

全部在數據庫中的數據，都須要經過圖表來展現，而這個series表示這個表裏面的數據，能夠在圖表上畫成幾條線：經過tags排列組合算出來。

其實一個series就是一個測點，或者說一條曲線，那麼retention policy, measurement, tagset就共同組成了一個定位測點序列的惟一標識。

point，就是某個series的同一個時刻的多個field的value，就組成了一個point；其實就是一條曲線上的一個點。

influxDB與傳統數據庫中的名詞作比較

（3）retention policy

保留策略，用於決定要保留多久的數據，保存幾個備份，以及集羣的策略等。

3.相關操做

查看數據庫：

建立數據庫：

使用數據庫：

插入數據：

influxDB存儲數據採用的是Line Protocol格式。

Line Protocol格式：寫入數據庫的Point的固定格式。格式以下：

<measurement>[,<tag-key>=<tag-value>...] <field-key>=<field-value>[,<field2-key>=<field2-value>...] [unix-nano-timestamp]
複製代碼

好比：

> INSERT cpu,host=serverA,region=us_west value=0.64
複製代碼

其中：

cpu是表名

host=serverA,region=us_west 是tag

value=0.64是field

查詢數據：

influxDB是支持類sql語句的，具體的查詢語法都差很少。

好比：select * from cpu

注：InfluxDB集羣功能已經再也不開源。要想使用集羣服務須要購買企業版。

開源版和企業版的主要區別就是企業版的InfluxDB支持集羣，而開源版不支持，此外企業版提供了先進的備份/恢復功能，而開源版本沒有。

但InfluxDB單機版性能也足夠支撐中小公司的業務了。

4.數據保存策略

InfluxDB每秒能夠處理成千上萬條數據，要將這些數據所有保存下來會佔用大量的存儲空間，有時咱們可能並不須要將全部歷史數據進行存儲。

所以，InfluxDB推出了數據保留策略（Retention Policies），用來讓咱們自定義數據的保留時間。InfluxDB的數據保留策略用來定義數據在InfluxDB中存放的時間，或者定義保存某個期間的數據。

一個數據庫能夠有多個保留策略，但每一個策略必須是獨一無二的。

查詢策略

能夠經過以下語句查看數據庫的現有策略：

數據庫telegraf只有一個策略，各字段的含義以下：

name：名稱，此示例名稱爲 autogen。當你建立一個數據庫的時候，InfluxDB會自動爲數據庫建立一個名叫 autogen 的策略，這個策略會永久保存數據。你能夠重命名這個策略，而且在InfluxDB的配置文件中禁止掉自動建立策略。

duration：數據保存時間，0表明無限制 shardGroupDuration：shardGroup的存儲時間，shardGroup是InfluxDB的一個基本儲存結構。 replicaN：全稱是REPLICATION，副本個數 default：是不是默認策略。 這裏有兩個概念：

shard：

shard 在 InfluxDB 中是一個比較重要的概念，它和 retention policy（數據保留策略） 相關聯。每個存儲策略下會存在許多 shard，每個 shard 存儲一個指定時間段內的數據，

而且不重複，例如 7點-8點 的數據落入 shard0 中，8點-9點的數據則落入 shard1 中。每個 shard 都對應一個底層的 TSM 存儲引擎，有獨立的 cache、wal、tsm file。

建立數據庫時會自動建立一個默認存儲策略，永久保存數據，對應的在此存儲策略下的 shard 所保存的數據的時間段爲 7 天，也就是上面查詢時看到的168h。

若是建立一個新的 retention policy 設置數據的保留時間爲 1 天，則單個 shard 所存儲數據的時間間隔爲 1 小時，超過1個小時的數據會被存放到下一個 shard 中。

shard group：

shard group是shards的邏輯容器。

建立策略

語法：

CREATE RETENTION POLICY <retention_policy_name> ON <database_name> DURATION <duration> REPLICATION <n> [SHARD DURATION <duration>] [DEFAULT]
複製代碼

：SHARD DURATION子句決定了每一個shard group存儲的時間間隔，在永久存儲的策略裏這個子句是無效的。這個子句是可選的。shard group duration默認由策略的 duration 決定。

示例1：爲數據庫telegraf建立一個策略

CREATE RETENTION POLICY "one_day_only" ON "telegraf" DURATION 1d REPLICATION 1
複製代碼

示例2：爲數據庫telegraf建立一個默認策略

CREATE RETENTION POLICY "one_day_only" ON "telegraf" DURATION 24h REPLICATION 1 DEFAULT
複製代碼

修改策略

語法：

ALTER RETENTION POLICY <retention_policy_name> ON <database_name> DURATION <duration> REPLICATION <n> SHARD DURATION <duration> DEFAULT
複製代碼

刪除策略

語法：

DROP RETENTION POLICY <retention_policy_name> ON <database_name>
複製代碼

注：當一個表使用的策略不是默認策略時，在進行操做時必定要顯式的指定策略名稱，不然會出現錯誤。

InfluxDB命令集合：

SHOW MEASUREMENTS --查詢當前數據庫中含有的表

SHOW FIELD KEYS --查看當前數據庫全部表的字段

SHOW series from pay --查看key數據

SHOW TAG KEYS FROM "pay" --查看key中tag key值

SHOW TAG VALUES FROM "pay" WITH KEY = "merId" --查看key中tag 指定key值對應的值

SHOW TAG VALUES FROM cpu WITH KEY IN ("region", "host") WHERE service = 'redis'

DROP SERIES FROM <measurement_name[,measurement_name]> WHERE <tag_key>='<tag_value>' --刪除key

SHOW CONTINUOUS QUERIES --查看連續執行命令

SHOW QUERIES --查看最後執行命令

KILL QUERY --結束命令

SHOW RETENTION POLICIES ON mydb --查看保留數據

查詢數據

SELECT * FROM /.*/ LIMIT 1 --查詢當前數據庫下全部表的第一行記錄

select * from pay order by time desc limit 2

select * from db_name."POLICIES name".measurement_name --指定查詢數據庫下數據保留中的表數據 POLICIES name數據保留

刪除數據

delete from "query" --刪除表全部數據，則表就不存在了

drop MEASUREMENT "query" --刪除表（注意會把數據保留刪除使用delete不會）

DELETE FROM cpu

DELETE FROM cpu WHERE time < '2000-01-01T00:00:00Z'

DELETE WHERE time < '2000-01-01T00:00:00Z'

DROP DATABASE 「testDB」 --刪除數據庫

DROP RETENTION POLICY "dbbak" ON mydb --刪除保留數據爲dbbak數據

DROP SERIES from pay where tag_key='' --刪除key中的tag

SHOW SHARDS --查看數據存儲文件

DROP SHARD 1

SHOW SHARD GROUPS

SHOW SUBSCRIPTIONS

5.Chronograf

Influxdb在1.3之後版本已經關閉了內置的8086的web管理功能，須要單獨的工具來管理。而這個工具就是Chronograf。

其實Chronograf是TICK技術棧的一個組成部分。TICK是InfluxdDB公司推出的監控套件，承包指標採集、分析、畫圖等時序數據庫上下游的工做，有點模仿日誌分析系統ELK套件的意思。TICK包含：

Telegraf：數據採集

InfluxDB：數據接收和存儲

Chronograf：數據彙總展現，報警等

Kapacitor：數據處理，好比監控策略等

下載Chronograf

下載地址 ：portal.influxdata.com/downloads

安裝Chronograf

啓動Chronograf

systemctl start chronograf

訪問Chronograf

瀏覽器輸入http://IP:8888

查詢：

豐富的界面操做，易於查詢、查看、統計分析等，使用起來很是方便。

5、數據備份與恢復

備份數據的命令格式

influxd backup -database [name] [path-to-backup]
複製代碼

遠程備份：

influxd backup -database myinfo -host 0.0.0.0:8088 /home/gooagoo/influxDB/backup
複製代碼

0.0.0.0替換爲ip地址

恢復數據的命令格式

influxd restore [ -metadir | -datadir ] <path-to-meta-or-data-directory> <path-to-backup>
複製代碼

6、綜合案例：Telegraf + InfluxDB + Grafana

1.Telegraf

Telegraf 是用Go寫的代理程序，能夠用於收集系統和服務的統計數據，是TICK技術棧的一部分。它具有輸入插件，能夠直接從系統獲取指標數據，從第三方API獲取指標數據， 甚至能夠經過Kafka獲取指標數據。它還具有輸出插件，能夠將採集的指標發送到各類數據存儲，服務和消息隊列。好比InfluxDB，Graphite，OpenTSDB，Datadog，Librato，Kafka，MQTT等等。

下載安裝Telegraf

wget https://dl.influxdata.com/telegraf/releases/telegraf-1.9.3-1.x86_64.rpm
複製代碼

sudo yum install telegraf-1.9.3-1.x86_64.rpm

telegraf -version
複製代碼

若是你的telegraf是安裝的，其配置文件位置爲：

/etc/telegraf/telegraf.conf

編輯配置文件，將咱們配置好的Influxdb數據庫指定爲指望的輸出源：

[[outputs.influxdb]]

urls=["http://localhost:8086"]

啓動服務、添加開機啓動：

sudo systemctl start telegraf.service

sudo service telegraf status

sudo systemctl enable telegraf.service
複製代碼

在InfluxDB上檢查默認配置下Telegraf採集了哪些數據：

> show databases
> use telegraf
> show measurements
> SHOW FIELD KEYS
複製代碼

如何進行配置：

# Read metrics about cpu usage
# 讀取有關CPU使用狀況的指標
[[inputs.cpu]]
## Whether to report per-cpu stats or not
percpu = true
## Whether to report total system cpu stats or not
totalcpu = true
## If true, collect raw CPU time metrics.
collect_cpu_time = false
## If true, compute and report the sum of all non-idle CPU states.
report_active = false

# Read metrics about disk usage by mount point
# 經過mount point讀取有關磁盤使用狀況的指標
[[inputs.disk]]
## Ignore mount points by filesystem type.
ignore_fs = ["tmpfs", "devtmpfs", "devfs", "overlay", "aufs", "squashfs"]

# Read metrics about disk IO by device
# 經過device讀取有關磁盤IO的指標
[[inputs.diskio]]

# Get kernel statistics from /proc/stat
# 經過/proc/stat獲取內核統計信息
[[inputs.kernel]]
# no configuration

# Read metrics about memory usage
# 讀取有關內存使用量的指標
[[inputs.mem]]
# no configuration

# Get the number of processes and group them by status
# 獲取進程的數量並按狀態分組
[[inputs.processes]]
# no configuration

# Read metrics about swap memory usage
# 讀取有關交換內存使用量的指標
[[inputs.swap]]
# no configuration

# Read metrics about system load & uptime
# 讀取有關係統負載和運行時間的指標
[[inputs.system]]
# no configuration
複製代碼

如何查找指標及其採集數據

telegraf主要分爲輸入插件和輸入插件，其源碼目錄分別對應plugins/inputs和plugins/outputs，你只要參考telegraf官檔找到你所須要的插件而後去到源碼對應的目錄找到相應的.md文件，按照提示獲取相關信息進行配置便可。

啓用telegraf服務後，你會發如今InfluxDB中多了一個telegraf的庫，其中有多個measurement，這說明咱們的數據採集已經成功了。有了數據之後，咱們須要關心的是如何把數據聚合而後進行展現。

2.Grafana展現

下載安裝基本配置請參考wiki：大數據圖表監控分析工具Grafana

這裏簡單講解一下如何使用Grafana展現Telegraf收集的相關數據。

啓動服務後訪問 http://ip:3000，默認端口爲3000，可在配置文件修改。登陸後按照提示配置數據源，咱們選擇InfluxDB做爲數據源：

根據配置信息填寫相關的InfluxDB的配置項

接着建立一個dashboard：

咱們先選擇導入模板的方式來預覽效果，再來了解grafana/dashboard的相關配置，這裏選擇官方提供的一套Telegraf: system dashboard，地址。 請你根據它的提示配置你的telegraf。而後在dashboards中選擇import->Upload.jsonFile，將下載的模板導入：

查看結果：

Grafana的功能很是豐富，在這裏不能詳細敘述，請您參考官檔瞭解更多：docs.grafana.org/

7、InfluxDB硬件規模指南

單節點仍是集羣？ InfluxDB單節點實例是徹底開源的。InfluxDB集羣須要咱們的閉源商業產品。單節點實例不提供冗餘。若是服務器不可用，則寫入和查詢將當即失敗。

羣集提供高可用性和冗餘。多個數據副本分佈在多個服務器上，任何一個服務器的丟失都不會對集羣產生重大影響。若是您的性能要求屬於中等或低負載範圍，

那麼您可能會使用InfluxDB的單個節點實例。若是您的性能要求中至少有一個屬於可能不可行的類別，那麼您可能須要使用羣集在多個服務器之間分配負載。

一、單節點

注：查詢對系統的影響差別很大。

簡單查詢：

幾乎沒有函數也沒有正則表達式

是時間限制在幾分鐘，幾小時或一天

一般在幾毫秒到幾十毫秒內執行

中等查詢：

有多個函數和一個或兩個正則表達式

也可能有複雜的GROUP BY條款或抽樣多個星期的時間範圍

一般在幾百或幾千毫秒內執行

複雜查詢：

具備多個聚合或轉換函數或多個正則表達式

能夠抽樣幾個月或幾年的很是大的時間範圍

一般須要多秒才能執行

低負荷建議：

CPU：2-4核心

RAM：2-4 GB

IOPS：500

適度的負載建議：

CPU：4-6核

RAM：8-32 GB

IOPS：500-1000

高負荷建議：

CPU：8+核心

RAM：32+ GB

IOPS：1000+

二、集羣

元節點

羣集必須至少具備三個獨立的元節點才能在丟失服務器後繼續存在。具備2n + 1元節點的集羣能夠容忍元節點的丟失n。羣集應該具備奇數個元節點。沒有理由擁有偶數個元節點，而且它可能致使某些配置出現問題。

元節點不須要很大的計算能力。不管羣集負載如何，咱們建議對元節點使用如下內容：

廣泛推薦

CPU：1-2核心

RAM：512 MB - 1 GB

IOPS：50

數據節點

只有一個數據節點的集羣有效，但沒有數據冗餘。冗餘由寫入數據的保留策略上的複製因子設置。羣集可能會丟失 n - 1數據節點並仍然返回完整的查詢結果，其中n是複製因子。

爲了在羣集內進行最佳數據分發，InfluxData建議使用偶數個數據節點。羣集數據節點的硬件建議相似於獨立實例建議。數據節點應始終至少有2個CPU內核，由於它們必須處理常規的讀寫流量以及集羣內讀寫流量。

因爲羣集通訊開銷，羣集中的數據節點處理的吞吐量低於同一硬件上的獨立實例。

注：查詢對系統的影響差別很大。

簡單查詢：

幾乎沒有函數也沒有正則表達式

是時間限制在幾分鐘，幾小時或一天

一般在幾毫秒到幾十毫秒內執行

中等查詢：

有多個函數和一個或兩個正則表達式

也可能有複雜的GROUP BY條款或抽樣多個星期的時間範圍

一般在幾百或幾千毫秒內執行

複雜查詢：

具備多個聚合或轉換函數或多個正則表達式

能夠抽樣幾個月或幾年的很是大的時間範圍

一般須要多秒才能執行

低負荷建議

CPU：2個核心

RAM：2-4 GB

IOPS：1000

適度的負載建議

CPU：4-6

內存：8-32GB

IOPS：1000+

高負荷建議

CPU：8+

RAM：32+ GB

IOPS：1000+

企業Web節點

Enterprise Web服務器主要是具備相似負載要求的HTTP服務器。對於大多數應用程序，它不須要很是強大。羣集只能使用一個Web服務器，但爲了實現冗餘，能夠將多個Web服務器鏈接到單個後端Postgres數據庫。

注：生產集羣不該使用SQLite數據庫，由於它不容許冗餘Web服務器，也不能像Postgres同樣優雅地處理高負載。

廣泛推薦

CPU：1-4核心

RAM：1-2 GB

IOPS：50

8、InfluxDB單機性能測試

官方給出的硬件參考配置是：

兩塊SSD。一塊存儲influxdb/wal，一塊存儲influxdb/data 最少8G內存

虛擬機InfluxDB性能測試，這裏記錄下結果，方便之後查閱。

操做系統： CentOS Linux release 7.5.1804

InfluxDB版本 ： V1.7.4

CPU ： Intel(R) Xeon(R) CPU E5-2403 0 @ 1.80GHz，4個4核CPU

內存 ：16G

硬盤：機械硬盤

批量寫入官方指導：

可使用對寫端點的單個HTTP請求將一批點提交到數據庫。這經過大幅減小HTTP開銷，使HTTP API的寫入更加高效。

InfluxData建議批量大小爲5,000-10,000點，但不一樣的用例能夠經過明顯更小或更大的批次來提供更好的服務。

優化前的結果（寫入）：單線程寫入數據超過1200W左右寫入失敗，內存不夠用

屢次優化後的結果（寫入）：

全表掃描性能

條件查詢性能

時間維度查詢

聚合查詢性能

同一個measurement，批量寫入大量數據，而後多線程讀取，隨着數據量的增大，讀取速度放慢。

若是是不一樣的measurement，讀寫分別不一樣的measurement，則讀和寫之間不受相互影響。

服務器應具備內存配置限制，以最大程度地下降內部進程觸發OOM的風險。

目前的行爲：

系統中有幾個地方能夠進行大量分配，這多是發生OOM的風險存在。

通常來講，這些都發生在：

查詢 - 一般使用過寬的過濾條件致使一次加載太多系列，好比select * 操做（確認存在）

內存索引 - 高基數（series）系列致使索引增加和OOM進程（確認存在）

寫入 - 許多正在進行的大批量和慢速磁盤寫入會致使在等待磁盤寫入/同步時構建大量內部緩衝區。（確認存在）

壓縮 - 在某些狀況下，能夠加載大型系列，以便更優化地對點進行重複數據刪除和分塊。（還沒有發現）