時序列數據庫武鬥大會之什麼是 TSDB ？

本文選自 OneAPM Cloud Insight 高級工程師劉斌博客 。

• 劉斌，一個才思敏捷的程序員，《第一本 Docker 書》、《GitHub 入門與實踐》等書籍譯者，Docker入門與實踐課程主講人。

• 時間序列數據庫，Cloud Insight 實現對性能指標進行聚合、分組、過濾所採起的解決方案。

因爲工做上的關係，最近看了一些關於時序列數據庫的東西，固然，我所看的也都是以開源方案爲主。趁着這股熱勁還沒退，但願能整理一些資料出來。若是正好你也有這方面的需求，那麼但願這一系列的介紹可以幫助到你。

1. 什麼是時序列數據庫（Time series database）？

一聽到時序列數據庫，若是隻是稍有耳聞的人，可能馬上會聯想到運維和監控系統。

沒錯，確實是不少運維、監控系統都採用了 TSDB 做爲數據庫系統來存儲海量的、嚴格按時間遞增的、在必定程度來講結構很是簡單的各類指標（英文可能爲 metric、measurement 或者相似的其餘單詞）數據。

1.1 給TSDB一個定義

這是維基百科上的解釋：

A time series database (TSDB) is a software system that is optimized for handling time series data, arrays of numbers indexed by time (a datetime or a datetime range).

翻譯過來就是「時序列數據庫用來存儲時序列（time-series）數據並以時間（點或區間）創建索引的軟件。」

其中，時序列數據能夠定義以下：

• 能夠惟一標識的序列名/ID（好比 cpu.load.1）及 meta-data；

• 一組數據點{timestamp, value}。timestamp 是一個 Unix 時間戳，通常精度會比較高，好比 influxdb 裏面是 nano 秒。通常來講這個精度都會在秒以上。

通常時序列數據都具有以下兩個特色：

• 數據結構簡單

• 數據量大

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

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

2. TSDB數據庫特色

TSDB 做爲一種專爲時序列數據優化而設計的數據庫，在不少方面都和傳統的 RDBMS 和 NoSQL 數據庫不太同樣，好比它不關心範式和事務。

其餘方面 TSDB 的特色主要有如下幾點，這裏簡單羅列了一下。

2.1 數據寫入

TSDB 在數據寫入方面，具備以下特色：

• 寫多於讀：95%-99%的操做都是寫操做

• 順序寫：因爲是時間序列數據，所以數據多爲追加式寫入，並且幾乎都是實時寫入，不多會寫入幾天前的數據。

• 不多更新：數據寫入以後，不會更新

• 區塊（bulk）刪除：基本沒有隨機刪除，多數是從一個時間點開始到某一時間點結束的整段數據刪除。好比刪除上個月，或者7天前的數據。不多出現刪除單獨某個指標的數據，或者跳躍時間段的數據。

區塊刪除很容易進行優化，好比能夠按區塊來分開存儲到不一樣的文件，這樣刪除一個區塊只須要刪除一個文件就能夠了，成本會比較低。

2.2 數據讀取（查詢）

相對於寫入操做，TSDB 的讀取操做特色以下：

• 順序讀：基本都是按照時間順序讀取一段時間內的數據。

• 基數大：基本數據大，超過內存大小，要選取的只是其一小部分，且沒有規律，緩存幾乎不起任何做用。

即便讀取操做相對寫來講較少，可是讀操做的響應時間要求很高，除非你是隻作後臺報表生成，不然一旦有交互性操做，必需要求快速響應。

爲了提升讀取的響應時間，有兩種策略：

• 一是以寫性能優先，不爲讀取作存儲優化，可是經過分佈式和併發讀，來提升讀取的速度。

• 二就是在寫入的時候就考慮到讀的性能問題，將統一指標、時間段的數據寫入到同一數據塊中，爲讀取進行寫入優化。

2.3 分佈式（集羣）

TSDB 應該天生就要考慮到分佈式和分區等特性，將存儲和查詢分發到不一樣的服務器，以支撐大規模的數據採集和查詢請求。

同時，它也應該是能擴展和自動失敗切換（Fault-tolerant）的。隨着數據量的增加，所需服務器的臺數也會增長，能動態的增減服務器則是一個基本要求。同時，隨着服務器的增多，各類服務器軟件或者網絡故障發生的機率也會增大，這時候失敗切換也顯得很重要，不能由於一臺機器的失效而致使整個集羣不可工做。

2.4 基本數據分析支持

TSDB 的數據是用來分析的，因此 TSDB 還會提供作數據分析所必須的各類運算、變換函數。好比能夠方便的對時序列數據進行求和、求平均值等操做，就像傳統的 RDBMS 同樣。

3. 如何去選擇開源時序列數據庫

雖然每一個人的場景不太同樣，不過我以爲如下的大部分因素，都值得你們好好考量一下。除了功能上能知足、性能上撐得住，運（售）維（後）等也是咱們準備長期使用所必須面臨的問題。

我本身總結的評價因素主要有以下幾點：

3.1 性能

主要就是讀和寫的性能，在前面 TSDB 的特色中咱們已經講過了。

經過前面的說明，咱們也知道 TSDB 99.9% 都是讀少寫多，所以寫入性能必須能跟得上、無延時，而且不能阻塞讀操做，且讀操做能快速返回最新的數據。

還有一點必須注意的是，如今不少用戶的數據都跑在雲主機上，那麼 IOPS 則是一個你必需要注意的因素，超了 Plan 限制的話很難找出問題緣由。

3.2 存儲方案（或引擎）

存儲方案主要會影響到讀寫性能、集羣擴展容易程度、以及運維的複雜度。典型的存儲方案有 HDFS、HBase、Cassandra、LevelDB等。

3.3 集羣功能

通常來講，集羣主要集中爲存儲和查詢的集羣功能，也表明其可擴展性，由於時序列數據庫的數據量極可能很大，而且增加趨勢不可預測，尤爲是隨着大數據和物聯網的興起，GB 已經算入門，TB 也是剛起步。

3.4 API（HTTP API 和 Client Library）

若是你須要定製，或者只是使用 TSDB 作存儲，本身寫入數據並經過查詢接口進行數據展現，那麼 API 的完善程度將是一個很重要的評判因素。

還好大部分 TSDB 都提供了 HTTP API，除了簡單的文本格式，有不少還支持 JSON 格式的輸入、輸出。

Client Library 也是一個加分項，有一個好用的、你熟悉的語言的SDK包的話應該會更方便你作開發。

3.5 SQL-like Query Language

若是能經過相似傳統 SQL 的 來查詢 metric 的話，是否是剛接觸到 TSDB 的人更容易上手和理解呢？

select mean(value) from metric where role='user' and time >= xxx and time <= yyy group by dc

可能這看起來比較酷，不過對我來講這隻能算是個加分項而已。由於咱們只會經過 API 來讀寫數據，並且查詢模式很是固定、數量很少。

可是不少常常出報表的人，可能更喜歡這一特色了，由於老闆、運營可能會按期或者隨時找他們出統計數據。

3.6 部署體驗

便是否容易部署，特別是做爲產品的話，不少企業級產品在安裝部署或者升級所耗費的時間絕對是佔了大頭的。因此是否容易部署就成了一個重要的指標，好比是否能一鍵部署、單機部署？是否有額外依賴組件等。

同時，部署的容易程度也幾乎等於之後運維的複雜程度。

3.7 成熟度

成熟度包括軟件自己的成熟度和生態系統的成熟度。

3.7.1 生態系統

生態系統主要是指圍繞該軟件的周邊工具、插件的豐富程度，以及相應的社區的活躍程度。

一個軟件的生態系統，跟它的開放機制、插件（擴展）機制關係很大，直接決定第三方是否能很方便的對系統進行擴展。

3.7.2 開發活躍度

這個能夠從 TSDB 項目的提交記錄（好比從 GitHub 上能看到開發情況）、ISSUE 的解決狀況，Pull Request的merge 狀況、以及 Release 的頻率來確認。

有一些 TSDB 項目甚至提供了 ROADMAP，咱們還能夠經過路線圖來了解該軟件將來發展方向、特性支持。

3.7.3 社區包活躍度

主要是文檔的豐富性等，能夠在 Google 搜索一下，看看相關的 Blog 是否足夠多，也能夠在 StackOverFlow 上看一下相關討論內容。

最重要的評論觀點就是在專業社區（好比在 Ops 相關討論組或社區）中該 TSDB 出現的頻次、你們的關注程度等。

3.7.4 應用案例

是否有大規模、大公司真正的生產環境的部署案例？規模有多大，性能如何，有無問題等，都是重要考察因素。有大公司的信任背書，你在選擇上也就多了份安心，少了些糾結。

好比，Druid 就在主頁列出了不少使用了 Druid 的公司： http://druid.io/druid-powered.html

3.8 可視化和報警功能

說到 TSDB，容易聯想到的兩個功能就是可視化和報警。若是 TSDB 自帶了功能強大的可視化組件和報警支持，則可能會省去不少開發的成本，更容易吸引用戶。即便開發，也能方便開發過程當中進行調試和驗證。

ELK 這麼流行，跟其一攬子方案關係很大。除了強大的功能以外，部署簡單、功能齊全是其吸引人的地方。

3.9 所採用技術棧

主要是該方案採用了什麼編程語言，有哪些第三方模塊。好比有的用 Java 編寫，有的用 Golang；有的用 HBase，有的用本身的存儲方案；有的自帶豐富的 UI，有的則只提供了簡單的調試界面。

技術棧爲何也是一個選型時須要考慮的因素呢，這是由於 TSDB 所採用的技術，會影響大家開發和運維的複雜程度，此外還會受到既有資產的影響。好比大家沒有人熟悉 HBase，又不熟悉 Java 語言，那麼可能 Influxdb 就更適合大家了。

3.10 保留策略（Retention Policies，或自動刪除、壓縮）

自動刪除就是爲數據設置 TTL，過了指定的 TTL 則自動刪除相關數據，以節省存儲空間同時提升查詢性能。

若是不刪除數據，也能夠對數據進行壓縮，或者再採樣（Resampling），好比對最近 1 天的數據咱們可能須要精確到秒，而查詢 1 年的數據時，咱們只須要精確到天，這時候，海量的數據一年只須要 365 個點來存儲，大大節省了存儲空間。

3.11 背後主導公司

有商業公司專職開發，多是個雙刃劍。

好處是其持續性可期，不用擔憂過兩天項目沒有人維護了，有了 bug 也有人會專門解決。

敝處就是你可能上了賊船下來須要成本較高。好比 ElasticSearch，搭建起 ELK 比較簡單，可是一涉及到具體的生產環境部署時須要考慮的權限等問題，要麼本身去 hack，要麼就得買他們的產品，這是成本上須要考慮的。

3.12 License

這多是影響最弱的一個因素了，可是若是你想拿來商業化的話，則又是一個很是重要甚至致命的因素。

3.13 多租戶支持

這部分需求可能會比較少，可是若是想基於 TSDB 爲用戶提供服務，好比 SaaS 類應用，能從物理上隔離固然是最理想的了，不過很遺憾目前好像尚未這方面的方案。要想支持多租戶，只能從應用自身來設計，相似傳統 RDBMS 那樣，爲每一個實體加入 user_id=xxx 相似的屬性。

3.14 安全性

好比：權限管理、訪問控制等。

關於安全性最基本的需求就是不要像 ELK 那樣，暴露在公網上若是不設防火牆的話，誰都能使用，這就帶來了很大的安全隱患。

因此說，安全上的最小實現就是支持基本的用戶密碼認證功能，並且是在兩個層次支持，一是 UI 層，即管理界面或者控制面板等，另外一方面就是 API 級別的用戶認證。

4. 參考文獻

• Time-Series Database Requirements

• Thoughts on Time-series Databases

• DB-Engines Ranking of Time Series DBMS(January 2016)

請期待本系列文章的其餘部分：

• 時序列數據庫武鬥大會之TSDB名錄 Part 1

• 時序列數據庫武鬥大會之TSDB名錄 Part 2

• 時序列數據庫武鬥大會之 OpenTSDB 篇

Cloud Insight 集監控、管理、計算、協做、可視化於一身，幫助全部 IT 公司，減小在系統監控上的人力和時間成本投入，讓運維工做更加高效、簡單。
本文轉自 OneAPM 官方博客