本文引用自： http://hbasefly.com/2017/11/19/timeseries-database-1/
作者對時序數據庫有很多的研究，其博客發表有多篇相關文章。
本人最近在學習時序數據庫相關，因此此處摘抄時序數據庫文檔。
時序數據庫（TSDB）是一種特定類型的數據庫，主要用來存儲時序數據。隨着5G技術的不斷成熟（十九大上工信部部長透露在2020年爭取實現5G的全球首發），物聯網技術將會使得萬物互聯。物聯網時代之前只有手機、電腦可以聯網，以后所有設備都會聯網，這些設備每時每刻都會吐出大量的按照時間組織的數據，需要存儲下來進行查詢、統計和分析。時序數據和普通的業務數據在各個方面都有很大的不同，本文將會試圖帶大家進入TSDB的世界。
TSDB應用場景：哪些場景會用到TSDB？
TSDB目前最大的應用場景是監控業務（哨兵），以哨兵為例，哨兵會在業務服務器上部署各種腳本客戶端用來采集服務器指標數據（IO指標、CPU指標、帶寬內存指標等等），業務相關數據（方法調用異常次數、響應延遲、JVM GC相關數據等等）、數據庫相關數據（讀取延遲、寫入延遲等等），很顯然，這些數據都是時間序列相關的，客戶端采集之后會發送給哨兵服務器，哨兵服務器會將這些數據進行存儲，並提供頁面給用戶進行查詢。如下圖所示，用戶可以登錄哨兵系統查看某台服務器的負載，負載曲線就是按照時間進行繪制的，帶有明顯的時序特征：
實際上，TSDB的潛力還沒有爆發，至少在現在還沒有。在可預知的未來3~5年，隨着物聯網以及工業4.0的到來，所有設備都會攜帶傳感器並聯網，傳感器收集的時序數據將嚴重依賴TSDB的實時分析能力、存儲能力以及查詢統計能力。
上圖是一個智慧工廠示意圖，工廠中所有設備都會攜帶傳感設備，這些傳感設備會實時采集設備溫度、壓力等基本信息，並發送給服務器端進行實時分析、存儲以及后期的查詢統計。除此之外，比如現在比較流行的各種穿戴設備，以后都可以聯網，穿戴設備上采集的心跳信息、血流信息、體感信息等等也都會實時傳輸給服務器進行實時分析、存儲以及查詢統計。
TSDB數據示例：什么是時序數據？
介紹了TSDB的主要應用場景，再來看看時序數據到底是什么樣的數據。下圖是一份典型的時序數據：
整個圖表征廣告業務實時行為數據，包括廣告實時瀏覽量、實時點擊量以及實時利潤收入等。圖中分了三個區域，表示時序數據由3個部分構成，分別為維度列、數值列以及時間列。維度列是最左邊的部分，表征廣告的基本信息，類似於物體標簽，比如廣告平台、廣告主、廣告面向對象以及廣告面向國家等。數值列是中間的部分，表示采集的數值有廣告瀏覽量（impressions）、點擊量（clicks）以及利潤（revenue）。時間列就是一系列的時間點信息。將上圖翻譯成表結構等價於：
| Timestamp |
publisher |
advertiser |
gender |
country |
impressions |
clicks |
revenue |
| 2017-01-01T00:00:00 |
ultrarimfast.com |
google.com |
male |
USA |
1800 |
23 |
11.24 |
| 2017-01-01T00:00:00 |
bieberfever.com |
google.com |
male |
USA |
2074 |
72 |
31.22 |
| 2017-01-01T00:00:00 |
ultrarimfast.com |
google.com |
male |
UK |
1079 |
54 |
9.72 |
| 2017-01-01T00:00:01 |
ultrarimfast.com |
google.com |
male |
USA |
1912 |
11 |
3.74 |
| 2017-01-01T00:00:01 |
bieberfever.com |
google.com |
male |
USA |
897 |
17 |
5.48 |
| 2017-01-01T00:00:01 |
ultrarimfast.com |
google.com |
male |
UK |
1120 |
73 |
6.48
|
TSDB基本特點：時序業務有哪些特點？
時序業務和普通業務在很多方面都有巨大的區別，歸納起來主要有如下幾個方面：
1. 持續產生海量數據，沒有波峰波谷。舉幾個簡單的例子，比如類似哨兵的監控系統，假如現在系統監控1w台服務器的各類指標，每台服務器每秒采集100種metrics，這樣每秒鍾將會有100w的TPS。再比如說，現在比較流行的運動手環，假如當前有100w人佩戴，每個手環一秒只采集3種metrcis（心跳、脈搏、步數），這樣每秒鍾也會產生300w的TPS。
2. 數據都是插入操作，基本沒有更新刪除操作。時序業務產生的數據很少有更新刪除的操作，基於這樣的事實，在時序數據庫架構設計上會有很大的簡化。
3. 近期數據關注度更高，未來會更關注流式處理這個環節，時間久遠的數據極少被訪問，甚至可以丟棄。這個很容易理解，哨兵系統我們通常最關心最近一小時的數據，最多看看最近3天的數據，很少去看3天以前的數據。隨着流式計算的到來，時序數據在以后的發展中必然會更關注即時數據的價值，這部分數據的價值毫無疑問也是最大的。數據產生之后就可以根據某些規則進行報警是一個非常常見並重要的場景，報警時效性越高，對業務越有利。
4. 數據存在多個維度的標簽，往往需要多維度聯合查詢以及統計查詢。時序數據另一個非常重要的功能是多維度聚合統計查詢，比如業務需要統計最近一小時廣告主google發布在USA地區的廣告點擊率和總收入分別是多少，這是一個典型的多維度聚合統計查詢需求。這個需求通常對實效性要求不高，但對查詢聚合性能有比較高的要求。
TSDB市場發展：現在都有哪些TSDB產品？
在最近的一年時間里，隨着物聯網技術的不斷成熟，很多創業者都希望能借助這個風口得到更多創業機會。試想當年移動互聯網剛興起的時候，也是誕生了一批規模龐大的創業者，而現在，要想在移動互聯網創業，難度已經非常之大，基本可以認為現在移動互聯網創業都是在玩資本，玩干爹。而物聯網這個市場的競爭力還是非常之小，非常純潔，創業的機會也非常之多。看清楚這樣的事實，很多廠商尤其是公有雲提供商都不約而同的將目光投到這個領域，他們的目標就是籠絡這些小的創業公司，包括百度雲、Facebook、阿里雲以及華為雲都開發提供了TSDB服務，希望能夠借着后面這么一股創業熱將雲計算普及到這些小公司（雲計算的最大客戶就是小的創業公司，因此對於雲計算來講，得小公司多者得天下）。下圖是最近一年各個廠商在TSDB的動作，可見搞個大動作是可以預見的了：
TSDB核心特性：TSDB關注的核心技術點在哪里？
說了這么多，是應該看看TSDB到底在技術層面關注哪些核心點了，基於時序業務的基本特點，總結起來TSDB需要關注的技術點主要有這么幾個：
1. 高吞吐量寫入能力。這是針對時序業務持續產生海量數據這么一個特點量身定做的，當前要實現系統高吞吐量寫入，必須要滿足兩個基本技術點要求：系統具有水平擴展性和單機LSM體系結構。系統具有水平擴展性很容易理解，單機肯定是扛不住的，系統必須是集群式的，而且要容易加節點擴展，說到底，就是擴容的時候對業務無感知，目前Hadoop生態系統基本上都可以做到這一點；而LSM體系結構是用來保證單台機器的高吞吐量寫入，LSM結構下數據寫入只需要寫入內存以及追加寫入日志，這樣就不再需要隨機將數據寫入磁盤，HBase、Kudu以及Druid等對寫入性能有要求的系統目前都采用的這種結構。
2. 數據分級存儲/TTL。這是針對時序數據冷熱性質定制的技術特性。數據分級存儲要求能夠將最近小時級別的數據放到內存中，將最近天級別的數據放到SSD，更久遠的數據放到更加廉價的HDD或者直接使用TTL過期淘汰掉。
3. 高壓縮率。提供高壓縮率有兩個方面的考慮，一方面是節省成本，這很容易理解，將1T數據壓縮到100G就可以減少900G的硬盤開銷，這對業務來說是有很大的誘惑的。另一個方面是壓縮后的數據可以更容易保證存儲到內存中，比如最近3小時的數據是1T，我現在只有100G的內存，如果不壓縮，就會有900G的數據被迫放到硬盤上，這樣的話查詢開銷會非常之大，而使用壓縮會將這1T數據都放入內存，查詢性能會非常之好。
4. 多維度查詢能力。時序數據通常會有多個維度的標簽來刻畫一條數據，就是上文中提到的維度列。如何根據隨機幾個維度進行高效查詢就是必須要解決的一個問題，這個問題通常需要考慮位圖索引或者倒排索引技術。
5. 高效聚合能力。時序業務一個通用的需求是聚合統計報表查詢，比如哨兵系統中需要查看最近一天某個接口出現異常的總次數，或者某個接口執行的最大耗時時間。這樣的聚合實際上就是簡單的count以及max，問題是如何能高效的在那么大的數據量的基礎上將滿足條件的原始數據查詢出來並聚合，要知道統計的原始值可能因為時間比較久遠而不在內存中哈，因此這可能是一個非常耗時的操作。目前業界比較成熟的方案是使用預聚合，就是在數據寫進來的時候就完成基本的聚合操作。
6. 未來技術點：異常實時檢測、未來預測等等
TSDB總結
TSDB將是未來一個非常具有市場性、挑戰性的數據庫，現在雖然已經有這樣那樣的服務，但大多都有這樣那樣的問題，現在很難談得上成熟。為了在物聯網時代、工業4.0時代中占有一定地位，TSDB是必須要拓展的技術。本文從時序場景、時序業務特點、TSDB市場以及TSDB核心技術點這幾個方面對TSDB進行了介紹，希望看官能基本了解TSDB。后續筆者將會推出針對TSDB的系列專題文章，深入分析TSDB本身所要面對的各種技術問題以及解決方案。