由於工作上的關係，筆者最近看了一些關於時序列數據庫的東西，當然所看的也都是以開源方案爲主。趁着這股熱勁還沒退，希望能整理一些資料出來。如果正好你也有這方面的需求，那麼希望這一系列的介紹能夠幫助到你。
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 級別的用戶認證。
關於作者：劉斌，供職於OneAPM，《第一本 Docker 書》、《GitHub 入門與實踐》等書籍譯者。