[轉]時序列數據庫武鬥大會之什麼是TSDB

因爲工做上的關係，最近看了一些關於時序列數據庫的東西，固然，我所看的也都是以開源方案爲主。

趁着這股熱勁還沒退，但願能整理一些資料出來。若是正好你也有這方面的需求，那麼但願這一系列的介紹可以幫助到你。

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的select mean(value) from metric where role='user' and time >= xxx and time <= yyy group by dc來查詢metric的話，是否是剛接觸到TSDB的人更容易上手和理解呢？

可能這看起來比較酷，不過對我來講這隻能算是個加分項而已。由於咱們只會經過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)

5. 相關閱讀

這是本系列文章的其餘部分：

• 時序列數據庫武鬥大會之什麼是TSDB
• 時序列數據庫武鬥大會之TSDB名錄 Part 1
• 時序列數據庫武鬥大會之TSDB名錄 Part 2
• 時序列數據庫武鬥大會之OpenTSDB篇
• 時序列數據庫武鬥大會之KairosDB篇

原文:http://liubin.org/blog/2016/02/18/tsdb-intro/