一、簡介
InfluxDB(時序資料庫)influxdb是一個開源分布式時序、時間和名額資料庫,使用 Go 語言編寫,無需外部依賴。其設計目标是實作分布式和水準伸縮擴充,是 InfluxData 的核心産品。常用的一種使用場景:監控資料統計,物聯網傳感器資料和實
時分析等的後端存儲。每毫秒記錄一下電腦記憶體的使用情況,然後就可以根據統計的資料,利用圖形化界面(InfluxDB V1一般配合Grafana)制作記憶體使用情況的折線圖;可以了解為按時間記錄一些資料(常用的監控資料、埋點統計資料等),然
後制作圖表做統計。
時間序列資料:從定義上來說,就是一串按時間次元索引的資料。
時序資料庫(TSDB)特點:
持續高并發寫入、無更新;
資料壓縮存儲;
低查詢延時。
常見 TSDB:influxdb、opentsdb、timeScaladb、Druid 等。
influxdb 完整的上下遊産業還包括:Chronograf、Telegraf、Kapacitor,其具體作用及關系如下:

二、同常見關系型資料庫(MySQL)的基礎概念對比
概念
MySQL
InfluxDB
資料庫(同)
database
表(不同)
table
measurement
列(不同)
column
tag(帶索引的,非必須)、field(不帶索引)、timestemp(唯一主鍵)
tag set:不同的每組tag key和tag value的集合;
field set:每組field key和field value的集合;
retention policy:資料存儲政策(預設政策為autogen)InfluxDB沒有删除資料操作,規定資料的保留時間達到清除資料的目的;
series:共同retention policy,measurement和tag set的集合;
示例資料如下: 其中census是measurement,butterflies和honeybees是field key,location和scientist是tag key
point的資料結構由時間戳(time)、标簽(tags)、資料(fields)三部分組成,具體含義如下:
point 屬性
含義
time
資料記錄的時間,是主索引(自動生成)
tags
各種有索引的屬性
fields
各種value值(沒有索引的屬性)
此外,influxdb還有個特有的概念:series(一般由:retention policy, measurement, tagset就共同組成),其含義如下:
所有在資料庫中的資料,都需要通過圖表來展示,而這個series表示這個表裡面的資料,可以在圖表上畫成幾條線:通過tags排列組合算出來。
需要注意的是,influxdb不需要像傳統資料庫一樣建立各種表,其表的建立主要是通過第一次資料插入時自動建立,如下:
insert mytest, server=serverA count=1,name=5 //自動建立表
“mytest”,“server” 是 tags,“count”、“name” 是 fields
fields 中的 value 基本不用于索引
tag 隻能為字元串類型
field 類型無限制
不支援join
支援連續查詢操作(彙總統計資料):CONTINUOUS QUERY
配合Telegraf服務(Telegraf可以監控系統CPU、記憶體、網絡等資料)
配合Grafana服務(資料展現的圖像界面,将influxdb中的資料可視化)
三、常見sql
1) 基于時間序列,支援與時間有關的相關函數(如最大,最小,求和等);
2) 可度量性:你可以實時對大量資料進行計算;
3) 基于事件:它支援任意的事件資料;
4) 無結構(無模式):可以是任意數量的列;
5)支援min, max, sum, count, mean, median 等一系列函數;
6)内置http支援,使用http讀寫;
7)強大的類SQL文法;
8)自帶管理界面,友善使用(新版本需要通過Chronograf)
四、 存儲引擎
采用TSM存儲引擎,TSM是在LSM的基礎上優化改善的,引入了serieskey的概念,對資料實作了很好的分類組織。
TSM主要由四個部分組成: cache、wal、tsm file、compactor:
cache:插入資料時,先往 cache 中寫入再寫入wal中,可以認為 cache 是 wal 檔案中的資料在記憶體中的緩存,cache 中的資料并不是無限增長的,有一個 maxSize 參數用于控制當 cache 中的資料占用多少記憶體後就會将資料寫入 tsm 檔案。如果不配置的話,預設上限為 25MB
wal:預寫日志,對比MySQL的 binlog,其内容與記憶體中的 cache 相同,作用就是為了持久化資料,當系統崩潰後可以通過 wal 檔案恢複還沒有寫入到 tsm 檔案中的資料,當 InfluxDB 啟動時,會周遊所有的 wal 檔案,重新構造 cache。
tsm file:每個 tsm 檔案的大小上限是 2GB。當達到 cache-snapshot-memory-size,cache-max-memory-size 的限制時會觸發将 cache 寫入 tsm 檔案。
compactor:主要進行兩種操作,一種是 cache 資料達到閥值後,進行快照,生成一個新的 tsm 檔案。另外一種就是合并目前的 tsm 檔案,将多個小的 tsm 檔案合并成一個,減少檔案的數量,并且進行一些資料删除操作。 這些操作都在背景自動完成,一般每隔 1 秒會檢查一次是否有需要壓縮合并的資料。
InfluxDB資料保留政策:
每個資料庫剛開始會自動建立一個預設的存儲政策 autogen,資料保留時間為永久,在叢集中的副本個數為1,之後使用者可以自己設定(檢視、建立、修改、删除),例如保留最近2小時的資料。插入和查詢資料時如果不指定存儲政策,則使用預設存儲政策,且預設存儲政策可以修改。InfluxDB 會定期清除過期的資料。
每個資料庫可以有多個過期政策:
show retention policies on "db_name"
Shard 在 influxdb中是一個比較重要的概念,它和 retention policy 相關聯。每一個存儲政策下會存在許多 shard,每一個 shard 存儲一個指定時間段内的資料,并且不重複,例如 7點-8點 的資料落入 shard0 中,8點-9點的資料則落入 shard1 中。每一個 shard 都對應一個底層的 tsm 存儲引擎,有獨立的 cache、wal、tsm file。
這樣做的目的就是為了可以通過時間來快速定位到要查詢資料的相關資源,加速查詢的過程,并且也讓之後的批量删除資料的操作變得非常簡單且高效。
建議在資料庫建立的時候設定存儲政策,不建議設定過多且随意切換
create database testdb2 with duration 30d
influxdb的資料存儲有三個目錄,分别是meta、wal、data:
meta 用于存儲資料庫的一些中繼資料,meta 目錄下有一個 meta.db 檔案;
wal 目錄存放預寫日志檔案,以 .wal 結尾;
data 目錄存放實際存儲的資料檔案,以 .tsm 結尾。
五、 性能優化與go開發
控制 series 的數量;
使用批量寫;
使用恰當的時間粒度;
存儲的時候盡量對 Tag 進行排序;
根據資料情況,調整 shard 的 duration;
無關的資料寫不同的database;
控制 Tag Key, 與 Tag Value 值的大小;
存儲分離 ,将 wal 目錄與 data 目錄分别映射到不同的磁盤上,以減少讀寫操作的互相影響。
go語言開發隻需要一個依賴包:github.com/influxdata/influxdb/client/v2,需要注意是v1.8版本,直接clone會失敗,
可先到:github.com/influxdata/influxdb中選擇版本号V1.8,然後clone下載下傳
對influxdb的操作主要有連接配接、插入、查詢、關閉等幾個步驟,其中查詢的時候需要注意時間,要設定相應的時區,不然可能顯示的時間結果不同
作者的原創文章,轉載須注明出處。原創文章歸作者所有,歡迎轉載,但是保留版權。對于轉載了部落客的原創文章,不标注出處的,作者将依法追究版權,請尊重作者的成果。