相對(duì)于寫入操作，TSDB 的讀取操作特點(diǎn)如下：

?

順序讀：基本都是按照時(shí)間順序讀取一段時(shí)間內(nèi)的數(shù)據(jù)。

?

?

基數(shù)大：基本數(shù)據(jù)大，超過(guò)內(nèi)存大小，要選取的只是其一小部分，且沒(méi)有規(guī)律，緩存幾乎不起任何作用。

?

即使讀取操作相對(duì)寫來(lái)說(shuō)較少，但是讀操作的響應(yīng)時(shí)間要求很高，除非你是只做后臺(tái)報(bào)表生成，否則一旦有交互性操作，必須要求快速響應(yīng)。

為了提高讀取的響應(yīng)時(shí)間，有兩種策略：

?

一是以寫性能優(yōu)先，不為讀取做存儲(chǔ)優(yōu)化，但是通過(guò)分布式和并發(fā)讀，來(lái)提高讀取的速度。

?

?

二就是在寫入的時(shí)候就考慮到讀的性能問(wèn)題，將統(tǒng)一指標(biāo)、時(shí)間段的數(shù)據(jù)寫入到同一數(shù)據(jù)塊中，為讀取進(jìn)行寫入優(yōu)化。

?

TSDB 應(yīng)該天生就要考慮到分布式和分區(qū)等特性，將存儲(chǔ)和查詢分發(fā)到不同的服務(wù)器，以支撐大規(guī)模的數(shù)據(jù)采集和查詢請(qǐng)求。

同時(shí)，它也應(yīng)該是能擴(kuò)展和自動(dòng)失敗切換（Fault-tolerant）的。隨著數(shù)據(jù)量的增長(zhǎng)，所需服務(wù)器的臺(tái)數(shù)也會(huì)增加，能動(dòng)態(tài)的增減服務(wù)器則是一個(gè)基本要求。同時(shí)，隨著服務(wù)器的增多，各種服務(wù)器軟件或者網(wǎng)絡(luò)故障發(fā)生的概率也會(huì)增大，這時(shí)候失敗切換也顯得很重要，不能因?yàn)橐慌_(tái)機(jī)器的失效而導(dǎo)致整個(gè)集群不可工作。

TSDB 的數(shù)據(jù)是用來(lái)分析的，所以 TSDB 還會(huì)提供做數(shù)據(jù)分析所必須的各種運(yùn)算、變換函數(shù)。比如可以方便的對(duì)時(shí)序列數(shù)據(jù)進(jìn)行求和、求平均值等操作，就像傳統(tǒng)的 RDBMS 一樣。

雖然每個(gè)人的場(chǎng)景不太一樣，不過(guò)我覺(jué)得以下的大部分因素，都值得大家好好考量一下。除了功能上能滿足、性能上撐得住，運(yùn)（售）維（后）等也是我們準(zhǔn)備長(zhǎng)期使用所必須面臨的問(wèn)題。

我自己總結(jié)的評(píng)價(jià)因素主要有如下幾點(diǎn)：

主要就是讀和寫的性能，在前面 TSDB 的特點(diǎn)中我們已經(jīng)講過(guò)了。

通過(guò)前面的說(shuō)明，我們也知道 TSDB 99.9% 都是讀少寫多，因此寫入性能必須能跟得上、無(wú)延時(shí)，并且不能阻塞讀操作，且讀操作能快速返回最新的數(shù)據(jù)。

還有一點(diǎn)必須注意的是，現(xiàn)在很多用戶的數(shù)據(jù)都跑在云主機(jī)上，那么 IOPS 則是一個(gè)你必須要注意的因素，超了 Plan 限制的話很難找出問(wèn)題原因。

存儲(chǔ)方案主要會(huì)影響到讀寫性能、集群擴(kuò)展容易程度、以及運(yùn)維的復(fù)雜度。典型的存儲(chǔ)方案有 HDFS、HBase、Cassandra、LevelDB等。

一般來(lái)說(shuō)，集群主要集中為存儲(chǔ)和查詢的集群功能，也代表其可擴(kuò)展性，因?yàn)闀r(shí)序列數(shù)據(jù)庫(kù)的數(shù)據(jù)量很可能很大，并且增長(zhǎng)趨勢(shì)不可預(yù)測(cè)，尤其是隨著大數(shù)據(jù)和物聯(lián)網(wǎng)的興起，GB 已經(jīng)算入門，TB 也是剛起步。

如果你需要定制，或者只是使用 TSDB 做存儲(chǔ)，自己寫入數(shù)據(jù)并通過(guò)查詢接口進(jìn)行數(shù)據(jù)展示，那么 API 的完善程度將是一個(gè)很重要的評(píng)判因素。

還好大部分 TSDB 都提供了 HTTP API，除了簡(jiǎn)單的文本格式，有很多還支持 JSON 格式的輸入、輸出。

Client Library 也是一個(gè)加分項(xiàng)，有一個(gè)好用的、你熟悉的語(yǔ)言的SDK包的話應(yīng)該會(huì)更方便你做開發(fā)。

如果能通過(guò)類似傳統(tǒng) SQL 的 來(lái)查詢 metric 的話，是不是剛接觸到 TSDB 的人更容易上手和理解呢？

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

可能這看起來(lái)比較酷，不過(guò)對(duì)我來(lái)說(shuō)這只能算是個(gè)加分項(xiàng)而已。因?yàn)槲覀冎粫?huì)通過(guò) API 來(lái)讀寫數(shù)據(jù)，而且查詢模式非常固定、數(shù)量不多。

但是很多經(jīng)常出報(bào)表的人，可能更喜歡這一特點(diǎn)了，因?yàn)槔习濉⑦\(yùn)營(yíng)可能會(huì)定期或者隨時(shí)找他們出統(tǒng)計(jì)數(shù)據(jù)。

即是否容易部署，特別是作為產(chǎn)品的話，很多企業(yè)級(jí)產(chǎn)品在安裝部署或者升級(jí)所耗費(fèi)的時(shí)間絕對(duì)是占了大頭的。所以是否容易部署就成了一個(gè)重要的指標(biāo)，比如是否能一鍵部署、單機(jī)部署？是否有額外依賴組件等。

同時(shí)，部署的容易程度也幾乎等于以后運(yùn)維的復(fù)雜程度。

成熟度包括軟件本身的成熟度和生態(tài)系統(tǒng)的成熟度。

3.7.1 生態(tài)系統(tǒng)

生態(tài)系統(tǒng)主要是指圍繞該軟件的周邊工具、插件的豐富程度，以及相應(yīng)的社區(qū)的活躍程度。

一個(gè)軟件的生態(tài)系統(tǒng)，跟它的開放機(jī)制、插件（擴(kuò)展）機(jī)制關(guān)系很大，直接決定第三方是否能很方便的對(duì)系統(tǒng)進(jìn)行擴(kuò)展。

3.7.2 開發(fā)活躍度

這個(gè)可以從 TSDB 項(xiàng)目的提交記錄（比如從 GitHub 上能看到開發(fā)狀況）、ISSUE 的解決情況，Pull Request的merge 情況、以及 Release 的頻率來(lái)確認(rèn)。

有一些 TSDB 項(xiàng)目甚至提供了 ROADMAP，我們還可以通過(guò)路線圖來(lái)了解該軟件未來(lái)發(fā)展方向、特性支持。

3.7.3 社區(qū)包活躍度

主要是文檔的豐富性等，可以在 Google 搜索一下，看看相關(guān)的 Blog 是否足夠多，也可以在 StackOverFlow 上看一下相關(guān)討論內(nèi)容。

最重要的評(píng)論觀點(diǎn)就是在專業(yè)社區(qū)（比如在 Ops 相關(guān)討論組或社區(qū)）中該 TSDB 出現(xiàn)的頻次、大家的關(guān)注程度等。

3.7.4 應(yīng)用案例

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

比如，Druid 就在主頁(yè)列出了很多使用了 Druid 的公司： http://druid.io/druid-powered.html

說(shuō)到 TSDB，容易聯(lián)想到的兩個(gè)功能就是可視化和報(bào)警。如果 TSDB 自帶了功能強(qiáng)大的可視化組件和報(bào)警支持，則可能會(huì)省去很多開發(fā)的成本，更容易吸引用戶。即使開發(fā)，也能方便開發(fā)過(guò)程中進(jìn)行調(diào)試和驗(yàn)證。

ELK 這么流行，跟其一攬子方案關(guān)系很大。除了強(qiáng)大的功能之外，部署簡(jiǎn)單、功能齊全是其吸引人的地方。

主要是該方案采用了什么編程語(yǔ)言，有哪些第三方模塊。比如有的用 Java 編寫，有的用 Golang；有的用 HBase，有的用自己的存儲(chǔ)方案；有的自帶豐富的 UI，有的則只提供了簡(jiǎn)單的調(diào)試界面。

技術(shù)棧為什么也是一個(gè)選型時(shí)需要考慮的因素呢，這是因?yàn)?TSDB 所采用的技術(shù)，會(huì)影響你們開發(fā)和運(yùn)維的復(fù)雜程度，此外還會(huì)受到既有資產(chǎn)的影響。比如你們沒(méi)有人熟悉 HBase，又不熟悉 Java 語(yǔ)言，那么可能 Influxdb 就更適合你們了。

自動(dòng)刪除就是為數(shù)據(jù)設(shè)置 TTL，過(guò)了指定的 TTL 則自動(dòng)刪除相關(guān)數(shù)據(jù)，以節(jié)省存儲(chǔ)空間同時(shí)提高查詢性能。

如果不刪除數(shù)據(jù)，也可以對(duì)數(shù)據(jù)進(jìn)行壓縮，或者再采樣（Resampling），比如對(duì)最近 1 天的數(shù)據(jù)我們可能需要精確到秒，而查詢 1 年的數(shù)據(jù)時(shí)，我們只需要精確到天，這時(shí)候，海量的數(shù)據(jù)一年只需要 365 個(gè)點(diǎn)來(lái)存儲(chǔ)，大大節(jié)省了存儲(chǔ)空間。

有商業(yè)公司專職開發(fā)，可能是個(gè)雙刃劍。

好處是其持續(xù)性可期，不用擔(dān)心過(guò)兩天項(xiàng)目沒(méi)有人維護(hù)了，有了 bug 也有人會(huì)專門解決。

敝處就是你可能上了賊船下來(lái)需要成本較高。比如 ElasticSearch，搭建起 ELK 比較簡(jiǎn)單，但是一涉及到具體的生產(chǎn)環(huán)境部署時(shí)需要考慮的權(quán)限等問(wèn)題，要么自己去 hack，要么就得買他們的產(chǎn)品，這是成本上需要考慮的。

這可能是影響最弱的一個(gè)因素了，但是如果你想拿來(lái)商業(yè)化的話，則又是一個(gè)非常重要甚至致命的因素。

這部分需求可能會(huì)比較少，但是如果想基于 TSDB 為用戶提供服務(wù)，比如 SaaS 類應(yīng)用，能從物理上隔離當(dāng)然是最理想的了，不過(guò)很遺憾目前好像還沒(méi)有這方面的方案。要想支持多租戶，只能從應(yīng)用自身來(lái)設(shè)計(jì)，類似傳統(tǒng) RDBMS 那樣，為每個(gè)實(shí)體加入 user_id=xxx 類似的屬性。

比如：權(quán)限管理、訪問(wèn)控制等。

關(guān)于安全性最基本的需求就是不要像 ELK 那樣，暴露在公網(wǎng)上如果不設(shè)防火墻的話，誰(shuí)都能使用，這就帶來(lái)了很大的安全隱患。

所以說(shuō)，安全上的最小實(shí)現(xiàn)就是支持基本的用戶密碼認(rèn)證功能，而且是在兩個(gè)層次支持，一是 UI 層，即管理界面或者控制面板等，另一方面就是 API 級(jí)別的用戶認(rèn)證。

?

Time-Series Database Requirements

?

?

Thoughts on Time-series Databases

?

?

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

?

請(qǐng)期待本系列文章的其他部分：

?

時(shí)序列數(shù)據(jù)庫(kù)武斗大會(huì)之TSDB名錄 Part 1

?

?

時(shí)序列數(shù)據(jù)庫(kù)武斗大會(huì)之TSDB名錄 Part 2

?

?

時(shí)序列數(shù)據(jù)庫(kù)武斗大會(huì)之 OpenTSDB 篇

?

Cloud Insight 集監(jiān)控、管理、計(jì)算、協(xié)作、可視化于一身，幫助所有 IT 公司，減少在系統(tǒng)監(jiān)控上的人力和時(shí)間成本投入，讓運(yùn)維工作更加高效、簡(jiǎn)單。
本文轉(zhuǎn)自 OneAPM 官方博客