本文選自 OneAPM Cloud Insight 高級工程師劉斌博客 。
- 劉斌俗他，一個才思敏捷的程序員浑彰，《第一本 Docker 書》、《GitHub 入門與實踐》等書籍譯者拯辙，Docker入門與實踐課程主講人郭变。
- 時間序列數據庫颜价，Cloud Insight 實現對性能指標進行聚合、分組诉濒、過濾所采取的解決方案周伦。
由于工作上的關系，最近看了一些關于時序列數據庫的東西未荒，當然专挪，我所看的也都是以開源方案為主。趁著這股熱勁還沒退片排，希望能整理一些資料出來寨腔。如果正好你也有這方面的需求，那么希望這一系列的介紹能夠幫助到你率寡。
1. 什么是時序列數據庫（Time series database）迫卢？
一聽到時序列數據庫，如果只是稍有耳聞的人冶共，可能立刻會聯想到運維和監(jiān)控系統(tǒng)乾蛤。
沒錯，確實是很多運維捅僵、監(jiān)控系統(tǒng)都采用了 TSDB 作為數據庫系統(tǒng)來存儲海量的家卖、嚴格按時間遞增的、在一定程度來說結構非常簡單的各種指標（英文可能為 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）數據并以時間（點或區(qū)間）建立索引的軟件÷疲”
其中榛臼，時序列數據可以定義如下：
- 可以唯一標識的序列名/ID（比如 cpu.load.1）及 meta-data；
- 一組數據點{timestamp, value}窜司。timestamp 是一個 Unix 時間戳沛善，一般精度會比較高，比如 influxdb 里面是 nano 秒塞祈。一般來說這個精度都會在秒以上金刁。
一般時序列數據都具備如下兩個特點：
- 數據結構簡單
- 數據量大
所謂的結構簡單，可以理解為某一度量指標在某一時間點只會有一個值议薪，沒有復雜的結構（嵌套尤蛮、層次等）和關系（關聯、主外鍵等）斯议。
數據量大則是另一個重要特點产捞，這是由于時序列數據由所監(jiān)控的大量數據源來產生、收集和發(fā)送哼御，比如主機坯临、IoT設備焊唬、終端或App等。
2. TSDB數據庫特點
TSDB 作為一種專為時序列數據優(yōu)化而設計的數據庫看靠，在很多方面都和傳統(tǒng)的 RDBMS 和 NoSQL 數據庫不太一樣赶促，比如它不關心范式和事務。
其他方面 TSDB 的特點主要有以下幾點挟炬，這里簡單羅列了一下鸥滨。
2.1 數據寫入
TSDB 在數據寫入方面，具有如下特點：
- 寫多于讀：95%-99%的操作都是寫操作
- 順序寫：由于是時間序列數據谤祖，因此數據多為追加式寫入婿滓，而且?guī)缀醵际菍崟r寫入，很少會寫入幾天前的數據粥喜。
- 很少更新：數據寫入之后凸主，不會更新
- 區(qū)塊（bulk）刪除：基本沒有隨機刪除，多數是從一個時間點開始到某一時間點結束的整段數據刪除容客。比如刪除上個月，或者7天前的數據约郁。很少出現刪除單獨某個指標的數據缩挑，或者跳躍時間段的數據。
區(qū)塊刪除很容易進行優(yōu)化鬓梅，比如可以按區(qū)塊來分開存儲到不同的文件供置，這樣刪除一個區(qū)塊只需要刪除一個文件就可以了，成本會比較低绽快。
2.2 數據讀冉嫔ァ（查詢）
相對于寫入操作，TSDB 的讀取操作特點如下：
- 順序讀：基本都是按照時間順序讀取一段時間內的數據坊罢。
- 基數大：基本數據大续担，超過內存大小，要選取的只是其一小部分活孩，且沒有規(guī)律物遇，緩存幾乎不起任何作用。
即使讀取操作相對寫來說較少憾儒，但是讀操作的響應時間要求很高询兴，除非你是只做后臺報表生成，否則一旦有交互性操作起趾，必須要求快速響應诗舰。
為了提高讀取的響應時間，有兩種策略：
- 一是以寫性能優(yōu)先训裆，不為讀取做存儲優(yōu)化眶根，但是通過分布式和并發(fā)讀蜀铲，來提高讀取的速度。
- 二就是在寫入的時候就考慮到讀的性能問題汛闸，將統(tǒng)一指標蝙茶、時間段的數據寫入到同一數據塊中，為讀取進行寫入優(yōu)化诸老。
2.3 分布式（集群）
TSDB 應該天生就要考慮到分布式和分區(qū)等特性隆夯，將存儲和查詢分發(fā)到不同的服務器，以支撐大規(guī)模的數據采集和查詢請求别伏。
同時蹄衷，它也應該是能擴展和自動失敗切換（Fault-tolerant）的。隨著數據量的增長厘肮，所需服務器的臺數也會增加愧口，能動態(tài)的增減服務器則是一個基本要求。同時类茂，隨著服務器的增多耍属，各種服務器軟件或者網絡故障發(fā)生的概率也會增大，這時候失敗切換也顯得很重要巩检，不能因為一臺機器的失效而導致整個集群不可工作厚骗。
2.4 基本數據分析支持
TSDB 的數據是用來分析的，所以 TSDB 還會提供做數據分析所必須的各種運算兢哭、變換函數领舰。比如可以方便的對時序列數據進行求和、求平均值等操作迟螺，就像傳統(tǒng)的 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包的話應該會更方便你做開發(fā)阶捆。
3.5 SQL-like Query Language
如果能通過類似傳統(tǒng) SQL 的 來查詢 metric 的話凌节，是不是剛接觸到 TSDB 的人更容易上手和理解呢？
select mean(value) from metric where role='user' and time >= xxx and time <= yyy group by dc
可能這看起來比較酷洒试，不過對我來說這只能算是個加分項而已倍奢。因為我們只會通過 API 來讀寫數據，而且查詢模式非常固定垒棋、數量不多卒煞。
但是很多經常出報表的人义钉，可能更喜歡這一特點了咙好，因為老板、運營可能會定期或者隨時找他們出統(tǒng)計數據。
3.6 部署體驗
即是否容易部署税灌，特別是作為產品的話，很多企業(yè)級產品在安裝部署或者升級所耗費的時間絕對是占了大頭的逗鸣。所以是否容易部署就成了一個重要的指標贞让，比如是否能一鍵部署、單機部署甜无？是否有額外依賴組件等扛点。
同時，部署的容易程度也幾乎等于以后運維的復雜程度毫蚓。
3.7 成熟度
成熟度包括軟件本身的成熟度和生態(tài)系統(tǒng)的成熟度占键。
3.7.1 生態(tài)系統(tǒng)
生態(tài)系統(tǒng)主要是指圍繞該軟件的周邊工具、插件的豐富程度元潘，以及相應的社區(qū)的活躍程度畔乙。
一個軟件的生態(tài)系統(tǒng)，跟它的開放機制翩概、插件（擴展）機制關系很大牲距，直接決定第三方是否能很方便的對系統(tǒng)進行擴展。
3.7.2 開發(fā)活躍度
這個可以從 TSDB 項目的提交記錄（比如從 GitHub 上能看到開發(fā)狀況）钥庇、ISSUE 的解決情況牍鞠，Pull Request的merge 情況、以及 Release 的頻率來確認评姨。
有一些 TSDB 項目甚至提供了 ROADMAP难述，我們還可以通過路線圖來了解該軟件未來發(fā)展方向、特性支持吐句。
3.7.3 社區(qū)包活躍度
主要是文檔的豐富性等胁后，可以在 Google 搜索一下，看看相關的 Blog 是否足夠多嗦枢，也可以在 StackOverFlow 上看一下相關討論內容攀芯。
最重要的評論觀點就是在專業(yè)社區(qū)（比如在 Ops 相關討論組或社區(qū)）中該 TSDB 出現的頻次、大家的關注程度等文虏。
3.7.4 應用案例
是否有大規(guī)模侣诺、大公司真正的生產環(huán)境的部署案例？規(guī)模有多大氧秘，性能如何年鸳，有無問題等，都是重要考察因素丸相。有大公司的信任背書搔确，你在選擇上也就多了份安心，少了些糾結。
比如妥箕，Druid 就在主頁列出了很多使用了 Druid 的公司： http://druid.io/druid-powered.html
3.8 可視化和報警功能
說到 TSDB滥酥，容易聯想到的兩個功能就是可視化和報警。如果 TSDB 自帶了功能強大的可視化組件和報警支持畦幢，則可能會省去很多開發(fā)的成本坎吻，更容易吸引用戶。即使開發(fā)宇葱，也能方便開發(fā)過程中進行調試和驗證瘦真。
ELK 這么流行，跟其一攬子方案關系很大黍瞧。除了強大的功能之外诸尽，部署簡單、功能齊全是其吸引人的地方印颤。
3.9 所采用技術棧
主要是該方案采用了什么編程語言您机，有哪些第三方模塊。比如有的用 Java 編寫年局，有的用 Golang际看；有的用 HBase，有的用自己的存儲方案矢否；有的自帶豐富的 UI仲闽，有的則只提供了簡單的調試界面。
技術棧為什么也是一個選型時需要考慮的因素呢僵朗，這是因為 TSDB 所采用的技術赖欣，會影響你們開發(fā)和運維的復雜程度，此外還會受到既有資產的影響验庙。比如你們沒有人熟悉 HBase顶吮，又不熟悉 Java 語言，那么可能 Influxdb 就更適合你們了壶谒。
3.10 保留策略（Retention Policies云矫，或自動刪除膳沽、壓縮）
自動刪除就是為數據設置 TTL汗菜，過了指定的 TTL 則自動刪除相關數據，以節(jié)省存儲空間同時提高查詢性能挑社。
如果不刪除數據陨界，也可以對數據進行壓縮，或者再采樣（Resampling）痛阻，比如對最近 1 天的數據我們可能需要精確到秒菌瘪，而查詢 1 年的數據時，我們只需要精確到天，這時候俏扩，海量的數據一年只需要 365 個點來存儲糜工，大大節(jié)省了存儲空間。
3.11 背后主導公司
有商業(yè)公司專職開發(fā)录淡，可能是個雙刃劍捌木。
好處是其持續(xù)性可期，不用擔心過兩天項目沒有人維護了嫉戚，有了 bug 也有人會專門解決刨裆。
敝處就是你可能上了賊船下來需要成本較高。比如 ElasticSearch彬檀，搭建起 ELK 比較簡單帆啃，但是一涉及到具體的生產環(huán)境部署時需要考慮的權限等問題，要么自己去 hack窍帝，要么就得買他們的產品努潘，這是成本上需要考慮的。
3.12 License
這可能是影響最弱的一個因素了坤学，但是如果你想拿來商業(yè)化的話慈俯，則又是一個非常重要甚至致命的因素。
3.13 多租戶支持
這部分需求可能會比較少拥峦，但是如果想基于 TSDB 為用戶提供服務贴膘，比如 SaaS 類應用，能從物理上隔離當然是最理想的了略号，不過很遺憾目前好像還沒有這方面的方案刑峡。要想支持多租戶，只能從應用自身來設計玄柠，類似傳統(tǒng) 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)
請期待本系列文章的其他部分：
Cloud Insight 集監(jiān)控、管理渐白、計算尊浓、協作、可視化于一身纯衍，幫助所有 IT 公司眠砾，減少在系統(tǒng)監(jiān)控上的人力和時間成本投入，讓運維工作更加高效托酸、簡單褒颈。
本文轉自 OneAPM 官方博客
