時序列資料庫選型

標籤：讀取   content   blog   事務   div   class   也有   title   number   

時序列資料庫武鬥大會之什麼是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應該天生就要考慮到分布式和分區等特性，將儲存和查詢分發到不同的伺服器，以支撐大規模的資料擷取和查詢請求。

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來讀寫資料，而且查詢模式非常固定、數量不多。

但是很多經常出報表的人，可能更喜歡這一特點了，因為老闆、運營可能會定期或者隨時找他們出統計資料。

DB-Engines中時序列資料庫排名

我們先來看一下DB-Engines中關於時序列資料庫的排名

這是當前（2016年2月的）排名情況：

摘自：http://liubin.org/blog/2016/02/18/tsdb-intro/

時序列資料庫選型