時序數據庫 InfluxDB（一）

相關文章：
時序數據庫 InfluxDB（一）
時序數據庫 InfluxDB（二）
時序數據庫 InfluxDB（三）
時序數據庫 InfluxDB（四）
時序數據庫 InfluxDB（五）

---

數據庫種類有不少，好比傳統的關係型數據庫 RDBMS（ 如 MySQL ），NoSQL 數據庫（ 如 MongoDB ），Key-Value 類型（ 如 redis ），Wide column 類型（ 如 HBase ）等等等等，固然還有本系列文章將會介紹的時序數據庫 TSDB（ 如 InfluxDB ）。

---

時序數據庫 TSDB

---

不一樣的數據庫針對的應用場景有不一樣的偏重。TSDB（ time series database ）時序數據庫是專門以時間維度進行設計和優化的。
TSDB 一般具備如下的特色：

• 時間是不可或缺的絕對主角（就像 MySQL 中的主鍵同樣），數據按照時間順序組織管理
• 高併發高吞吐量的數據寫入
• 數據的更新不多發生
• 過時的數據能夠批量刪除

InfluxDB 就是一款很是優秀的時序數據庫，高居 DB-Engines TSDB rank 榜首。

InfluxDB 分爲免費的社區開源版本，以及須要收費的閉源商業版本，目前只有商業版本支持集羣。

InfluxDB 的底層數據結構從 LSM 樹到 B+ 樹折騰了一通，最後自創了一個 TSM 樹（ Time-Structured Merge Tree ），這也是它性能高且資源佔用少的重要緣由。

InfluxDB 由 go 語言編寫而成，沒有額外的依賴，它的查詢語言 InfluxQL 與 SQL 極其類似，使用特別簡單。

---

InfluxDB 基本概念

---

InfluxDB 有如下幾個核心概念：
一、database ：
數據庫。

二、measurement
相似於表。

三、retention policy（ 簡稱 RP ）
保留策略，由如下三個部分構成：

• DURATION：數據的保留時長。
• REPLICATION：集羣模式下數據的副本數，單節點無效。
• SHARD DURATION：可選項，shard group 劃分的時間範圍。

四、timestamp
時間戳，就像是全部數據的主鍵同樣。

五、tag
tag key = tag value 鍵值對存儲具體的數據，會構建索引有利於查詢。tag set 就是 tag key-value 鍵值對的不一樣組合。

六、field
field key = field value 鍵值對也是存儲具體的數據，但不會被索引。相似的 field set 就是 field key-value 的組合。

七、series
一個 series 序列是由同一個 RP 策略下的同一個 measurement 裏的同一個 tag set 構成的數據集合。

八、point
一個 point 點表明了一條數據，由 measurement、tag set、field set、timestamp 組成。一個 series 上的某個 timestamp 時間對應惟一一個 point 。

Line protocol 行協議

行協議指定了寫入數據的格式：

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

符號 [] 表明可選項，符號 ... 表明能夠有多個，符號 ，用來分隔相同 tag 或者 field 下的多個數據，符號空格分隔 tag、field、timestamp 。

示例：

怎麼去理解 series 和 point ？先看下圖：

這張圖選取了三種時序數據庫的歷年排名得分狀況。首先，整個圖表能夠當作是一個 measurement ，它包含了許多數據；而後咱們根據 db 名稱構建 tag ，把 score 排名得分做爲 field ，那麼全部數據行就相似於：

measurement,db=InfluxDB score=5 timestamp
measurement,db=Kdb+ score=1 timestamp
measurement,db=Prometheus score=0.2 timestamp
...

上文說過 tag set 就是 tag key = tag value 的不一樣組合，所以這裏的 tag set 有如下三種：

db=InfluxDB
db=Kdb+
db=Prometheus

三個 tag set 構成了三個 series ，每一個 series 就能夠當作是圖中的一條線（一個維度），而每一個 point 點就是 series 上具體某個 timestamp 對應的點。

---

與傳統數據庫的不一樣

---

InfluxDB 就是被設計用於處理時間序列的數據。傳統SQL數據庫雖然也能夠處理時間序列數據，但並非專門以此爲目標的。InfluxDB 能夠更加高效快速的存儲大量時間序列數據並對這些數據進行實時分析。

在 InfluxDB 中，時間是絕對的主角，就像是SQL數據庫中的主鍵同樣，若是你不指定則會默認爲系統當前時間，時間必須是 UNIX epoch ( GMT ) 或者 RFC3339 格式。

InfluxDB 不須要預先定義好數據的結構，你能夠隨時改變你的數據結構。InfluxDB 支持 continuous queries（連續查詢，就是以時間劃分範圍自動按期執行某個查詢）和 retention policies（保留策略）。InfluxDB 不支持跨 measurement 的 JOIN 查詢。

InfluxDB 中的查詢語言叫 InfluxQL ，語法與 SQL 極其類似，就是 select from where 那一套。

InfluxDB 並非 CRUD，更像是 CR-ud ，意思就是更新和刪除數據跟傳統SQL數據庫明顯不同：

• 更新某個 point 數據，只需向原來的 measurement，tag set，timestamp 重寫數據便可。
• 你能夠刪除 series ，可是不能基於 field 值去刪除獨立的 points ，解決方法是，你須要先查詢 field 值的時間戳，而後根據時間戳去刪除。
• 沒法更新或重命名 tags ，由於 tags 會構建索引，你只能建立新的 tags 並導入數據而後刪除老的。
• 沒法經過 tag key 或者 tag value 去刪除 tags 。

---

設計與權衡之道

---

InfluxDB 爲了更高的性能作了一些設計與權衡之道：
一、對於時間序列用例，即便相同的數據被髮送屢次也會被認爲是同一筆數據。

• 優勢：簡化了衝突，提升了寫入性能。
• 缺點：不能存儲重複數據，可能會在極少數狀況下覆蓋數據。

二、刪除是罕見的，當它們發生時確定是針對大量的舊數據。

• 優勢：提升了讀寫性能。
• 缺點：刪除功能受到了很大限制。

三、更新是罕見的，持續或者大批量的更新不會發生。時間序列的數據主要是永遠也不會更新的新數據。

• 優勢：提升了讀寫性能。
• 缺點：更新功能受到了很大限制。

四、絕大多數寫入都是接近當前時間戳的數據，而且是按時間遞增順序添加。

• 優勢：按時間遞增的順序寫入數據更高效。
• 缺點：隨機時間寫入的性能要低不少。

五、數據規模相當重要，數據庫必須可以處理大量的讀寫。

• 優勢：數據庫能夠處理大批量數據的讀寫。
• 缺點：被迫作出的一些權衡去提升性能。

六、可以寫入和查詢數據比具備強一致性更重要。

• 優勢：多個客戶端能夠在高負載的狀況下完成查詢和寫入操做。
• 缺點：若是負載太高，查詢結果可能不包含最近的點。

七、許多時間序列都是短暫的。時間序列可能只有幾個小時而後就沒了，好比一臺新的主機開機，監控數據寫入一段時間，而後關機了。

• 優勢：InfluxDB 善於管理不連續的數據。
• 缺點：無模式設計意味着不支持某些數據庫功能，例如沒有 join 交叉錶鏈接。

八、No one point is too important 。

• 優勢：InfluxDB 具備很是強大的工具去處理聚合數據和大數據集。
• 缺點：Points 數據點沒有傳統意義上的 ID ，它們被時間戳和 series 區分。

未完待續。。。

我的公衆號持續輸出原創文章，有興趣的能夠關注下。