由于工作上的關(guān)系，筆者最近看了一些關(guān)于時(shí)序列數(shù)據(jù)庫(kù)的東西，當(dāng)然所看的也都是以開(kāi)源方案為主。趁著這股熱勁還沒(méi)退，希望能整理一些資料出來(lái)。如果正好你也有這方面的需求，那么希望這一系列的介紹能夠幫助到你。
　　1.什么是時(shí)序列數(shù)據(jù)庫(kù)（Time series database）
　　一聽(tīng)到時(shí)序列數(shù)據(jù)庫(kù)，如果只是稍有耳聞的人，可能立刻會(huì)聯(lián)想到運(yùn)維和監(jiān)控系統(tǒng)。
　　沒(méi)錯(cuò)，確實(shí)是很多運(yùn)維、監(jiān)控系統(tǒng)都采用了 TSDB 作為數(shù)據(jù)庫(kù)系統(tǒng)來(lái)存儲(chǔ)海量的、嚴(yán)格按時(shí)間遞增的、在一定程度來(lái)說(shuō)結(jié)構(gòu)非常簡(jiǎn)單的各種指標(biāo)（英文可能為 metric、measurement 或者類似的其他單詞）數(shù)據(jù)。
　　1.1 給TSDB一個(gè)定義
　　這是維基百科上的解釋：
　　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）。
　　翻譯過(guò)來(lái)就是“時(shí)序列數(shù)據(jù)庫(kù)用來(lái)存儲(chǔ)時(shí)序列（time-series）數(shù)據(jù)并以時(shí)間（點(diǎn)或區(qū)間）建立索引的軟件?！逼渲?，時(shí)序列數(shù)據(jù)可以定義如下：
　　*可以唯一標(biāo)識(shí)的序列名/ID（比如 cpu.load.1）及 meta-data；
　　一組數(shù)據(jù)點(diǎn){timestamp， value}。timestamp 是一個(gè) Unix 時(shí)間戳，一般精度會(huì)比較高，比如 influxdb 里面是 nano 秒。一般來(lái)說(shuō)這個(gè)精度都會(huì)在秒以上。*
　　一般時(shí)序列數(shù)據(jù)都具備如下兩個(gè)特點(diǎn)：
　　數(shù)據(jù)結(jié)構(gòu)簡(jiǎn)單數(shù)據(jù)量大
　　所謂的結(jié)構(gòu)簡(jiǎn)單，可以理解為某一度量指標(biāo)在某一時(shí)間點(diǎn)只會(huì)有一個(gè)值，沒(méi)有復(fù)雜的結(jié)構(gòu)（嵌套、層次等）和關(guān)系（關(guān)聯(lián)、主外鍵等）。
　　數(shù)據(jù)量大則是另一個(gè)重要特點(diǎn)，這是由于時(shí)序列數(shù)據(jù)由所監(jiān)控的大量數(shù)據(jù)源來(lái)產(chǎn)生、收集和發(fā)送，比如主機(jī)、IoT設(shè)備、終端或App等。
　　2.TSDB數(shù)據(jù)庫(kù)特點(diǎn)
　　TSDB 作為一種專為時(shí)序列數(shù)據(jù)優(yōu)化而設(shè)計(jì)的數(shù)據(jù)庫(kù)，在很多方面都和傳統(tǒng)的 RDBMS 和 NoSQL 數(shù)據(jù)庫(kù)不太一樣，比如它不關(guān)心范式和事務(wù)。其他方面 TSDB 的特點(diǎn)主要有以下幾點(diǎn)，這里簡(jiǎn)單羅列了一下。
　　2.1 數(shù)據(jù)寫入
　　TSDB 在數(shù)據(jù)寫入方面，具有如下特點(diǎn)：
　　寫多于讀：95%-99%的操作都是寫操作順序?qū)懀河捎谑菚r(shí)間序列數(shù)據(jù)，因此數(shù)據(jù)多為追加式寫入，而且?guī)缀醵际菍?shí)時(shí)寫入，很少會(huì)寫入幾天前的數(shù)據(jù)。很少更新：數(shù)據(jù)寫入之后，不會(huì)更新區(qū)塊（bulk）刪除：基本沒(méi)有隨機(jī)刪除，多數(shù)是從一個(gè)時(shí)間點(diǎn)開(kāi)始到某一時(shí)間點(diǎn)結(jié)束的整段數(shù)據(jù)刪除。比如刪除上個(gè)月，或者7天前的數(shù)據(jù)。很少出現(xiàn)刪除單獨(dú)某個(gè)指標(biāo)的數(shù)據(jù)，或者跳躍時(shí)間段的數(shù)據(jù)。
　　區(qū)塊刪除很容易進(jìn)行優(yōu)化，比如可以按區(qū)塊來(lái)分開(kāi)存儲(chǔ)到不同的文件，這樣刪除一個(gè)區(qū)塊只需要?jiǎng)h除一個(gè)文件就可以了，成本會(huì)比較低。
　　2.2 數(shù)據(jù)讀?。ú樵儯?br /> 　　相對(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)化。
　　2.3 分布式（集群）
　　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è)集群不可工作。
　　2.4 基本數(shù)據(jù)分析支持
　　TSDB 的數(shù)據(jù)是用來(lái)分析的，所以 TSDB 還會(huì)提供做數(shù)據(jù)分析所必須的各種運(yùn)算、變換函數(shù)。比如可以方便的對(duì)時(shí)序列數(shù)據(jù)進(jìn)行求和、求平均值等操作，就像傳統(tǒng)的 RDBMS 一樣。
　　3.如何去選擇開(kāi)源時(shí)序列數(shù)據(jù)庫(kù)
　　雖然每個(gè)人的場(chǎng)景不太一樣，不過(guò)我覺(jué)得以下的大部分因素，都值得大家好好考量一下。除了功能上能滿足、性能上撐得住，運(yùn)（售）維（后）等也是我們準(zhǔn)備長(zhǎng)期使用所必須面臨的問(wèn)題。我自己總結(jié)的評(píng)價(jià)因素主要有如下幾點(diǎn)：
　　3.1 性能
　　主要就是讀和寫的性能，在前面 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)題原因。
　　3.2 存儲(chǔ)方案（或引擎）
　　存儲(chǔ)方案主要會(huì)影響到讀寫性能、集群擴(kuò)展容易程度、以及運(yùn)維的復(fù)雜度。典型的存儲(chǔ)方案有 HDFS、HBase、Cassandra、LevelDB等。
　　3.3 集群功能
　　一般來(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 也是剛起步。
　　3.4 API（HTTP API 和 Client Library）
　　如果你需要定制，或者只是使用 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ì)更方便你做開(kāi)發(fā)。
　　3.5 SQL-like Query Language
　　如果能通過(guò)類似傳統(tǒng) SQL 的 來(lái)查詢 metric 的話，是不是剛接觸到 TSDB 的人更容易上手和理解呢？
　　selectmean（value） frommetric whererole=‘user’andtime》= xxx andtime《= yyy groupbydc
　　可能這看起來(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ù)。
　　3.6 部署體驗(yàn)
　　即是否容易部署，特別是作為產(chǎn)品的話，很多企業(yè)級(jí)產(chǎn)品在安裝部署或者升級(jí)所耗費(fèi)的時(shí)間絕對(duì)是占了大頭的。所以是否容易部署就成了一個(gè)重要的指標(biāo)，比如是否能一鍵部署、單機(jī)部署？是否有額外依賴組件等。
　　同時(shí)，部署的容易程度也幾乎等于以后運(yùn)維的復(fù)雜程度。
　　3.7 成熟度
　　成熟度包括軟件本身的成熟度和生態(tài)系統(tǒng)的成熟度。
　　3.7.1 生態(tài)系統(tǒng)
　　生態(tài)系統(tǒng)主要是指圍繞該軟件的周邊工具、插件的豐富程度，以及相應(yīng)的社區(qū)的活躍程度。
　　一個(gè)軟件的生態(tài)系統(tǒng)，跟它的開(kāi)放機(jī)制、插件（擴(kuò)展）機(jī)制關(guān)系很大，直接決定第三方是否能很方便的對(duì)系統(tǒng)進(jìn)行擴(kuò)展。
　　3.7.2 開(kāi)發(fā)活躍度
　　這個(gè)可以從 TSDB 項(xiàng)目的提交記錄（比如從 GitHub 上能看到開(kāi)發(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
　　3.8 可視化和報(bào)警功能
　　說(shuō)到 TSDB，容易聯(lián)想到的兩個(gè)功能就是可視化和報(bào)警。如果 TSDB 自帶了功能強(qiáng)大的可視化組件和報(bào)警支持，則可能會(huì)省去很多開(kāi)發(fā)的成本，更容易吸引用戶。即使開(kāi)發(fā)，也能方便開(kāi)發(fā)過(guò)程中進(jìn)行調(diào)試和驗(yàn)證。
　　ELK 這么流行，跟其一攬子方案關(guān)系很大。除了強(qiáng)大的功能之外，部署簡(jiǎn)單、功能齊全是其吸引人的地方。
　　3.9 所采用技術(shù)棧
　　主要是該方案采用了什么編程語(yǔ)言，有哪些第三方模塊。比如有的用 Java 編寫，有的用 Golang；有的用 HBase，有的用自己的存儲(chǔ)方案；有的自帶豐富的 UI，有的則只提供了簡(jiǎn)單的調(diào)試界面。
　　技術(shù)棧為什么也是一個(gè)選型時(shí)需要考慮的因素呢，這是因?yàn)?TSDB 所采用的技術(shù)，會(huì)影響你們開(kāi)發(fā)和運(yùn)維的復(fù)雜程度，此外還會(huì)受到既有資產(chǎn)的影響。比如你們沒(méi)有人熟悉 HBase，又不熟悉 Java 語(yǔ)言，那么可能 Influxdb 就更適合你們了。
　　3.10 保留策略（Retention Policies，或自動(dòng)刪除、壓縮）
　　自動(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ǔ)空間。
　　3.11 背后主導(dǎo)公司
　　有商業(yè)公司專職開(kāi)發(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)品，這是成本上需要考慮的。
　　3.12 License
　　這可能是影響最弱的一個(gè)因素了，但是如果你想拿來(lái)商業(yè)化的話，則又是一個(gè)非常重要甚至致命的因素。
　　3.13 多租戶支持
　　這部分需求可能會(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 類似的屬性。
　　3.14 安全性
　　比如：權(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)證。