時序列數(shù)據(jù)庫是什么及TSDB的定義

　　由于工作上的關(guān)系，筆者最近看了一些關(guān)于時序列數(shù)據(jù)庫的東西，當(dāng)然所看的也都是以開源方案為主。趁著這股熱勁還沒退，希望能整理一些資料出來。如果正好你也有這方面的需求，那么希望這一系列的介紹能夠幫助到你。
　　1.什么是時序列數(shù)據(jù)庫（Time series database）
　　一聽到時序列數(shù)據(jù)庫，如果只是稍有耳聞的人，可能立刻會聯(lián)想到運維和監(jiān)控系統(tǒng)。
　　沒錯，確實是很多運維、監(jiān)控系統(tǒng)都采用了 TSDB 作為數(shù)據(jù)庫系統(tǒng)來存儲海量的、嚴(yán)格按時間遞增的、在一定程度來說結(jié)構(gòu)非常簡單的各種指標(biāo)（英文可能為 metric、measurement 或者類似的其他單詞）數(shù)據(jù)。
　　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）。
　　翻譯過來就是“時序列數(shù)據(jù)庫用來存儲時序列（time-series）數(shù)據(jù)并以時間（點或區(qū)間）建立索引的軟件?！逼渲?，時序列數(shù)據(jù)可以定義如下：
　　*可以唯一標(biāo)識的序列名/ID（比如 cpu.load.1）及 meta-data；
　　一組數(shù)據(jù)點{timestamp， value}。timestamp 是一個 Unix 時間戳，一般精度會比較高，比如 influxdb 里面是 nano 秒。一般來說這個精度都會在秒以上。*
　　一般時序列數(shù)據(jù)都具備如下兩個特點：
　　數(shù)據(jù)結(jié)構(gòu)簡單數(shù)據(jù)量大
　　所謂的結(jié)構(gòu)簡單，可以理解為某一度量指標(biāo)在某一時間點只會有一個值，沒有復(fù)雜的結(jié)構(gòu)（嵌套、層次等）和關(guān)系（關(guān)聯(lián)、主外鍵等）。
　　數(shù)據(jù)量大則是另一個重要特點，這是由于時序列數(shù)據(jù)由所監(jiān)控的大量數(shù)據(jù)源來產(chǎn)生、收集和發(fā)送，比如主機、IoT設(shè)備、終端或App等。
　　2.TSDB數(shù)據(jù)庫特點
　　TSDB 作為一種專為時序列數(shù)據(jù)優(yōu)化而設(shè)計的數(shù)據(jù)庫，在很多方面都和傳統(tǒng)的 RDBMS 和 NoSQL 數(shù)據(jù)庫不太一樣，比如它不關(guān)心范式和事務(wù)。其他方面 TSDB 的特點主要有以下幾點，這里簡單羅列了一下。
　　2.1 數(shù)據(jù)寫入
　　TSDB 在數(shù)據(jù)寫入方面，具有如下特點：
　　寫多于讀：95%-99%的操作都是寫操作順序?qū)懀河捎谑菚r間序列數(shù)據(jù)，因此數(shù)據(jù)多為追加式寫入，而且?guī)缀醵际菍崟r寫入，很少會寫入幾天前的數(shù)據(jù)。很少更新：數(shù)據(jù)寫入之后，不會更新區(qū)塊（bulk）刪除：基本沒有隨機刪除，多數(shù)是從一個時間點開始到某一時間點結(jié)束的整段數(shù)據(jù)刪除。比如刪除上個月，或者7天前的數(shù)據(jù)。很少出現(xiàn)刪除單獨某個指標(biāo)的數(shù)據(jù)，或者跳躍時間段的數(shù)據(jù)。
　　區(qū)塊刪除很容易進行優(yōu)化，比如可以按區(qū)塊來分開存儲到不同的文件，這樣刪除一個區(qū)塊只需要刪除一個文件就可以了，成本會比較低。
　　2.2 數(shù)據(jù)讀取（查詢）
　　相對于寫入操作，TSDB 的讀取操作特點如下：
　　順序讀：基本都是按照時間順序讀取一段時間內(nèi)的數(shù)據(jù)。基數(shù)大：基本數(shù)據(jù)大，超過內(nèi)存大小，要選取的只是其一小部分，且沒有規(guī)律，緩存幾乎不起任何作用。
　　即使讀取操作相對寫來說較少，但是讀操作的響應(yīng)時間要求很高，除非你是只做后臺報表生成，否則一旦有交互性操作，必須要求快速響應(yīng)。為了提高讀取的響應(yīng)時間，有兩種策略：
　　一是以寫性能優(yōu)先，不為讀取做存儲優(yōu)化，但是通過分布式和并發(fā)讀，來提高讀取的速度。二就是在寫入的時候就考慮到讀的性能問題，將統(tǒng)一指標(biāo)、時間段的數(shù)據(jù)寫入到同一數(shù)據(jù)塊中，為讀取進行寫入優(yōu)化。
　　2.3 分布式（集群）
　　TSDB 應(yīng)該天生就要考慮到分布式和分區(qū)等特性，將存儲和查詢分發(fā)到不同的服務(wù)器，以支撐大規(guī)模的數(shù)據(jù)采集和查詢請求。
　　同時，它也應(yīng)該是能擴展和自動失敗切換（Fault-tolerant）的。隨著數(shù)據(jù)量的增長，所需服務(wù)器的臺數(shù)也會增加，能動態(tài)的增減服務(wù)器則是一個基本要求。同時，隨著服務(wù)器的增多，各種服務(wù)器軟件或者網(wǎng)絡(luò)故障發(fā)生的概率也會增大，這時候失敗切換也顯得很重要，不能因為一臺機器的失效而導(dǎo)致整個集群不可工作。
　　2.4 基本數(shù)據(jù)分析支持
　　TSDB 的數(shù)據(jù)是用來分析的，所以 TSDB 還會提供做數(shù)據(jù)分析所必須的各種運算、變換函數(shù)。比如可以方便的對時序列數(shù)據(jù)進行求和、求平均值等操作，就像傳統(tǒng)的 RDBMS 一樣。
　　3.如何去選擇開源時序列數(shù)據(jù)庫
　　雖然每個人的場景不太一樣，不過我覺得以下的大部分因素，都值得大家好好考量一下。除了功能上能滿足、性能上撐得住，運（售）維（后）等也是我們準(zhǔn)備長期使用所必須面臨的問題。我自己總結(jié)的評價因素主要有如下幾點：
　　3.1 性能
　　主要就是讀和寫的性能，在前面 TSDB 的特點中我們已經(jīng)講過了。
　　通過前面的說明，我們也知道 TSDB 99.9% 都是讀少寫多，因此寫入性能必須能跟得上、無延時，并且不能阻塞讀操作，且讀操作能快速返回最新的數(shù)據(jù)。
　　還有一點必須注意的是，現(xiàn)在很多用戶的數(shù)據(jù)都跑在云主機上，那么 IOPS 則是一個你必須要注意的因素，超了 Plan 限制的話很難找出問題原因。
　　3.2 存儲方案（或引擎）
　　存儲方案主要會影響到讀寫性能、集群擴展容易程度、以及運維的復(fù)雜度。典型的存儲方案有 HDFS、HBase、Cassandra、LevelDB等。
　　3.3 集群功能
　　一般來說，集群主要集中為存儲和查詢的集群功能，也代表其可擴展性，因為時序列數(shù)據(jù)庫的數(shù)據(jù)量很可能很大，并且增長趨勢不可預(yù)測，尤其是隨著大數(shù)據(jù)和物聯(lián)網(wǎng)的興起，GB 已經(jīng)算入門，TB 也是剛起步。
　　3.4 API（HTTP API 和 Client Library）
　　如果你需要定制，或者只是使用 TSDB 做存儲，自己寫入數(shù)據(jù)并通過查詢接口進行數(shù)據(jù)展示，那么 API 的完善程度將是一個很重要的評判因素。
　　還好大部分 TSDB 都提供了 HTTP API，除了簡單的文本格式，有很多還支持 JSON 格式的輸入、輸出。
　　Client Library 也是一個加分項，有一個好用的、你熟悉的語言的SDK包的話應(yīng)該會更方便你做開發(fā)。
　　3.5 SQL-like Query Language
　　如果能通過類似傳統(tǒng) SQL 的 來查詢 metric 的話，是不是剛接觸到 TSDB 的人更容易上手和理解呢？
　　selectmean（value） frommetric whererole=‘user’andtime》= xxx andtime《= yyy groupbydc
　　可能這看起來比較酷，不過對我來說這只能算是個加分項而已。因為我們只會通過 API 來讀寫數(shù)據(jù)，而且查詢模式非常固定、數(shù)量不多。
　　但是很多經(jīng)常出報表的人，可能更喜歡這一特點了，因為老板、運營可能會定期或者隨時找他們出統(tǒng)計數(shù)據(jù)。
　　3.6 部署體驗
　　即是否容易部署，特別是作為產(chǎn)品的話，很多企業(yè)級產(chǎn)品在安裝部署或者升級所耗費的時間絕對是占了大頭的。所以是否容易部署就成了一個重要的指標(biāo)，比如是否能一鍵部署、單機部署？是否有額外依賴組件等。
　　同時，部署的容易程度也幾乎等于以后運維的復(fù)雜程度。
　　3.7 成熟度
　　成熟度包括軟件本身的成熟度和生態(tài)系統(tǒng)的成熟度。
　　3.7.1 生態(tài)系統(tǒng)
　　生態(tài)系統(tǒng)主要是指圍繞該軟件的周邊工具、插件的豐富程度，以及相應(yīng)的社區(qū)的活躍程度。
　　一個軟件的生態(tài)系統(tǒng)，跟它的開放機制、插件（擴展）機制關(guān)系很大，直接決定第三方是否能很方便的對系統(tǒng)進行擴展。
　　3.7.2 開發(fā)活躍度
　　這個可以從 TSDB 項目的提交記錄（比如從 GitHub 上能看到開發(fā)狀況）、ISSUE 的解決情況，Pull Request的merge 情況、以及 Release 的頻率來確認(rèn)。
　　有一些 TSDB 項目甚至提供了 ROADMAP，我們還可以通過路線圖來了解該軟件未來發(fā)展方向、特性支持。
　　3.7.3 社區(qū)包活躍度
　　主要是文檔的豐富性等，可以在 Google 搜索一下，看看相關(guān)的 Blog 是否足夠多，也可以在 StackOverFlow 上看一下相關(guān)討論內(nèi)容。
　　最重要的評論觀點就是在專業(yè)社區(qū)（比如在 Ops 相關(guān)討論組或社區(qū)）中該 TSDB 出現(xiàn)的頻次、大家的關(guān)注程度等。
　　3.7.4 應(yīng)用案例
　　是否有大規(guī)模、大公司真正的生產(chǎn)環(huán)境的部署案例？規(guī)模有多大，性能如何，有無問題等，都是重要考察因素。有大公司的信任背書，你在選擇上也就多了份安心，少了些糾結(jié)。
　　比如，Druid 就在主頁列出了很多使用了 Druid 的公司： http://druid.io/druid-powered.html
　　3.8 可視化和報警功能
　　說到 TSDB，容易聯(lián)想到的兩個功能就是可視化和報警。如果 TSDB 自帶了功能強大的可視化組件和報警支持，則可能會省去很多開發(fā)的成本，更容易吸引用戶。即使開發(fā)，也能方便開發(fā)過程中進行調(diào)試和驗證。
　　ELK 這么流行，跟其一攬子方案關(guān)系很大。除了強大的功能之外，部署簡單、功能齊全是其吸引人的地方。
　　3.9 所采用技術(shù)棧
　　主要是該方案采用了什么編程語言，有哪些第三方模塊。比如有的用 Java 編寫，有的用 Golang；有的用 HBase，有的用自己的存儲方案；有的自帶豐富的 UI，有的則只提供了簡單的調(diào)試界面。
　　技術(shù)棧為什么也是一個選型時需要考慮的因素呢，這是因為 TSDB 所采用的技術(shù)，會影響你們開發(fā)和運維的復(fù)雜程度，此外還會受到既有資產(chǎn)的影響。比如你們沒有人熟悉 HBase，又不熟悉 Java 語言，那么可能 Influxdb 就更適合你們了。
　　3.10 保留策略（Retention Policies，或自動刪除、壓縮）
　　自動刪除就是為數(shù)據(jù)設(shè)置 TTL，過了指定的 TTL 則自動刪除相關(guān)數(shù)據(jù)，以節(jié)省存儲空間同時提高查詢性能。
　　如果不刪除數(shù)據(jù)，也可以對數(shù)據(jù)進行壓縮，或者再采樣（Resampling），比如對最近 1 天的數(shù)據(jù)我們可能需要精確到秒，而查詢 1 年的數(shù)據(jù)時，我們只需要精確到天，這時候，海量的數(shù)據(jù)一年只需要 365 個點來存儲，大大節(jié)省了存儲空間。
　　3.11 背后主導(dǎo)公司
　　有商業(yè)公司專職開發(fā)，可能是個雙刃劍。
　　好處是其持續(xù)性可期，不用擔(dān)心過兩天項目沒有人維護了，有了 bug 也有人會專門解決。
　　敝處就是你可能上了賊船下來需要成本較高。比如 ElasticSearch，搭建起 ELK 比較簡單，但是一涉及到具體的生產(chǎn)環(huán)境部署時需要考慮的權(quán)限等問題，要么自己去 hack，要么就得買他們的產(chǎn)品，這是成本上需要考慮的。
　　3.12 License
　　這可能是影響最弱的一個因素了，但是如果你想拿來商業(yè)化的話，則又是一個非常重要甚至致命的因素。
　　3.13 多租戶支持
　　這部分需求可能會比較少，但是如果想基于 TSDB 為用戶提供服務(wù)，比如 SaaS 類應(yīng)用，能從物理上隔離當(dāng)然是最理想的了，不過很遺憾目前好像還沒有這方面的方案。要想支持多租戶，只能從應(yīng)用自身來設(shè)計，類似傳統(tǒng) RDBMS 那樣，為每個實體加入 user_id=xxx 類似的屬性。
　　3.14 安全性
　　比如：權(quán)限管理、訪問控制等。
　　關(guān)于安全性最基本的需求就是不要像 ELK 那樣，暴露在公網(wǎng)上如果不設(shè)防火墻的話，誰都能使用，這就帶來了很大的安全隱患。
　　所以說，安全上的最小實現(xiàn)就是支持基本的用戶密碼認(rèn)證功能，而且是在兩個層次支持，一是 UI 層，即管理界面或者控制面板等，另一方面就是 API 級別的用戶認(rèn)證。