1.基本概念
時序數據庫（Time Series Database）是用於存儲和管理時間序列數據的專業化數據庫。時序數據庫特別適用於物聯網設備監控和互聯網業務監控場景。
下面介紹下時序數據庫的一些基本概念（不同的時序數據庫稱呼略有不同）。
1.1 度量（metric）
監測數據的指標，例如風力和溫度。相當於關系型數據庫中的table。
1.2 標簽（tag）
指標項監測針對的具體對象，屬於指定度量下的數據子類別。一個標簽（Tag）由一個標簽鍵（TagKey）和一個對應的標簽值（TagValue）組成。
例如在監測數據的時候，指定度量（Metric）是“氣溫”，“城市（TagKey）= 杭州（TagValue）”就是一個標簽（Tag），則監測的就是杭州市的氣溫。更多標簽示例：機房 = A 、IP = 172.220.110.1。
1.3 域（field）
在指定度量下數據的子類別，一般情況下存放的是會隨着時間戳的變化而變化的數據。一個metric可支持多個field，如metric為風力，該度量可以有兩個field：direction和speed。
1.4 度量值（value）
度量對應的數值，如56°C、1000r/s等（實際中不帶單位）。如果有多個field，每個field都有相應的value。不同的field支持不同的數據類型寫入。對於同一個field，如果寫入了某個數據類型的value之后，相同的field不允許寫入其他數據類型。
1.5 時間戳（Timestamp）
數據（度量值）產生的時間點。
1.6 數據點 (Data Point)
針對監測對象的某項指標（由度量和標簽定義）按特定時間間隔（連續的時間戳）采集的每個度量值就是一個數據點。1個metric+1個field（可選）+1個timestamp+1個value + n個tag（n>=1）”唯一定義了一個數據點。相當於關系型數據庫中的row。
1.7 時間序列（Time Series）
1個metric+1個field（可選） +n個tag（n>=1）”定義了一個時間序列。主要是針對某個監測對象的某項指標（由度量和標簽定義）的描述。某個時間序列上產生的數據值的增加，不會導致時間序列的增加。
例1（單域）：對溫度的時間序列監測值
溫度（temperature）作為一個度量（metric），共4個數據點，每個數據點由如下組成：
timestamp：時間戳
三個tag：每個tag都是一個key-value對，tag的key分別是deivceID、floor、room。
一個field：溫度值
其中4個數據點使用的metric、tag是相同的，所以是同一個時間序列。如圖所示：
例2（多域，單一數據源采集）：記錄一段時間內的某個集群里各機器上各端口的出入流量，每半小時記錄一個觀測值。
網絡（Network）作為一個度量（metric），總共7個數據點。每個數據點由以下部分組成：
timestamp：時間戳
兩個tag：host、port，代表每個point歸屬於哪台機器的哪個端口
兩個field：bytes_in、bytes_out，代表piont的測量值，半小時內出入流量的平均值
同一個host、同一個port，每半小時產生一個point，隨着時間的增長，field（bytes_in、bytes_out）不斷變化。
如host：host4，port：51514，timestamp從02:00 到02:30的時間段內，bytes_in 從 37.937上漲到38.089，bytes_out從2897.26上漲到3009.86，說明這一段時間內該端口服務壓力升高。
例3（多域，多個數據源采集）：監測風力的兩個域(speed和direction)的監測數據，監測數據來自不同的傳感器
風力（wind）作為一個度量（metric），總共2個時間序列，8個數據點。每個數據點由以下部分組成：
3個tag：key分別是sensor、city、province。為了表示在廣東省深圳市傳感器編號95D8-7913上傳風向（direction）數據，可以將這個數據點的tag為標記為sensor=95D8-7913、city=深圳、province=廣東。
兩個域：風向（direction）和速度（speed），分別來自不同的傳感器。
如圖，當使用的是metric、field和tag是相同的時，是同一個時間序列。
將數據采用metric+field的方式存儲的優勢在於，可以在同一個時間序列下聯合查詢。以上圖為例，要查詢1467627246000-1467627249000時間內風力(wind)的情況，可以聯合查詢多個field的值，得到下圖的數據。
1.8 時間精度
時間線數據的寫入時間精度——毫秒、秒、分鍾、小時或者其他穩定時間頻度。例如，每秒一個溫度數據的采集頻度，每 5 分鍾一個負載數據的采集頻度。
1.9-1 數據組（Data Group）
可以按標簽這些數據分成不同的數據組。用來對比不同監測對象（由標簽定義）的同一指標（由度量定義）的數據。
例如，將溫度指標數據按照不同城市進行分組查詢，操作類似於該 SQL 語句：select temperature from xxx group by city where city in （shanghai, hangzhou)。
1.9-2 聚合（ Aggregation）
可以對一段時間的數據點做聚合，如每10分鍾的和值、平均值、最大值、最小值等。
例如，當選定了某個城市某個城區的污染指數時，通常將各個環境監測點的指標數據平均值作為最終區域的指標數據，這個計算過程就是空間聚合。
2.應用場景
2.1系統運維和業務實時監控
在業務服務器上部署各種腳本客戶端，實時采集服務器指標數據（IO指標、CPU指標、帶寬內存指標等等），業務相關數據（方法調用異常次數、響應延遲、JVM GC相關數據等等）、數據庫相關數據（讀取延遲、寫入延遲等等），很顯然，這些數據都是時間序列相關的。客戶端采集和實時計算之后會發送給哨兵服務器，哨兵服務器會將這些數據進行存儲，並實現實現監控和分析的展現，供用戶查詢。
如下圖所示，用戶可以登錄哨兵系統查看某台服務器的負載，負載曲線就是按照時間進行繪制的，帶有明顯的時序特征：
2.2 物聯網設備狀態監控存儲分析
在可預知的未來3~5年，隨着物聯網以及工業4.0的到來，所有設備都會攜帶傳感器並聯網，傳感器收集的時序數據將嚴重依賴TSDB的實時分析能力、存儲能力以及查詢統計能力。
上圖是一個智慧工廠示意圖，工廠中所有設備都會攜帶傳感設備，這些傳感設備會實時采集設備溫度、壓力等基本信息，並發送給服務器端進行實時分析、存儲以及后期的查詢統計。除此之外，比如現在比較流行的各種穿戴設備，以后都可以聯網，穿戴設備上采集的心跳信息、血流信息、體感信息等等也都會實時傳輸給服務器進行實時分析、存儲以及查詢統計。
PS：阿里雲擁有自主研發的時序數據庫產品 TSDB ，此產品在阿里內部磨練多年， 歷經多次雙十一高嚴苛場景的功能和性能驗證， 在應用監控，服務器資源監控，數據庫監控， 智慧園區設備監控，以及盒馬新零售邊緣設備監控都有豐富的落地使用場景 ，覆蓋了阿里集團80%以上的時序監控業務。
3.基本特點
時序業務和普通業務在很多方面都有巨大的區別，歸納起來主要有如下幾個方面：
3.1 持續產生海量數據，沒有波峰波谷
舉幾個簡單的例子，比如類似哨兵的監控系統，假如現在系統監控1w台服務器的各類指標，每台服務器每秒采集100種metrics，這樣每秒鍾將會有100w的TPS。再比如說，現在比較流行的運動手環，假如當前有100w人佩戴，每個手環一秒只采集3種metrcis（心跳、脈搏、步數），這樣每秒鍾也會產生300w的TPS。
3.2 數據都是插入操作，基本沒有更新刪除操作
時序業務產生的數據很少有更新刪除的操作，基於這樣的事實，在時序數據庫架構設計上會有很大的簡化。
3.3 近期數據關注度更高，未來會更關注流式處理這個環節，時間久遠的數據極少被訪問，甚至可以丟棄
這個很容易理解，哨兵系統我們通常最關心最近一小時的數據，最多看看最近3天的數據，很少去看3天以前的數據。隨着流式計算的到來，時序數據在以后的發展中必然會更關注即時數據的價值，這部分數據的價值毫無疑問也是最大的。數據產生之后就可以根據某些規則進行報警是一個非常常見並重要的場景，報警時效性越高，對業務越有利。
3.4 數據存在多個維度的標簽，往往需要多維度聯合查詢以及統計查詢。
時序數據另一個非常重要的功能是多維度聚合統計查詢，比如業務需要統計最近一小時廣告主google發布在USA地區的廣告點擊率和總收入分別是多少，這是一個典型的多維度聚合統計查詢需求。這個需求通常對實效性要求不高，但對查詢聚合性能有比較高的要求。
4.TSDB核心特性
總結起來TSDB需要關注的技術點主要有這么幾個：
4.1 高吞吐量寫入能力
這是針對時序業務持續產生海量數據這么一個特點量身定做的，當前要實現系統高吞吐量寫入，必須要滿足兩個基本技術點要求：系統具有水平擴展性和單機LSM體系結構。系統具有水平擴展性很容易理解，單機肯定是扛不住的，系統必須是集群式的，而且要容易加節點擴展，說到底，就是擴容的時候對業務無感知，目前Hadoop生態系統基本上都可以做到這一點；而LSM體系結構是用來保證單台機器的高吞吐量寫入，LSM結構下數據寫入只需要寫入內存以及追加寫入日志，這樣就不再需要隨機將數據寫入磁盤，HBase、Kudu以及Druid等對寫入性能有要求的系統目前都采用的這種結構。
4.2 數據分級存儲/TTL
這是針對時序數據冷熱性質定制的技術特性。數據分級存儲要求能夠將最近小時級別的數據放到內存中，將最近天級別的數據放到SSD，更久遠的數據放到更加廉價的HDD或者直接使用TTL過期淘汰掉。
4.3 高壓縮率
提供高壓縮率有兩個方面的考慮，一方面是節省成本，這很容易理解，將1T數據壓縮到100G就可以減少900G的硬盤開銷，這對業務來說是有很大的誘惑的。另一個方面是壓縮后的數據可以更容易保證存儲到內存中，比如最近3小時的數據是1T，我現在只有100G的內存，如果不壓縮，就會有900G的數據被迫放到硬盤上，這樣的話查詢開銷會非常之大，而使用壓縮會將這1T數據都放入內存，查詢性能會非常之好。
4.4 多維度查詢能力
時序數據通常會有多個維度的標簽來刻畫一條數據，就是上文中提到的維度列。如何根據隨機幾個維度進行高效查詢就是必須要解決的一個問題，這個問題通常需要考慮位圖索引或者倒排索引技術。
4.5 高效聚合能力
時序業務一個通用的需求是聚合統計報表查詢，比如哨兵系統中需要查看最近一天某個接口出現異常的總次數，或者某個接口執行的最大耗時時間。這樣的聚合實際上就是簡單的count以及max，問題是如何能高效的在那么大的數據量的基礎上將滿足條件的原始數據查詢出來並聚合，要知道統計的原始值可能因為時間比較久遠而不在內存中哈，因此這可能是一個非常耗時的操作。目前業界比較成熟的方案是使用預聚合，就是在數據寫進來的時候就完成基本的聚合操作。
未來技術點：異常實時檢測、未來預測等等。
5.傳統關系型數據庫存儲時序數據的問題
很多人可能認為在傳統關系型數據庫上加上時間戳一列就能作為時序數據庫。數據量少的時候確實也沒問題。但時序數據往往是由百萬級甚至千萬級終端設備產生的，寫入並發量比較高，屬於海量數據場景。
5.1 MySQL在海量的時序數據場景下存在如下問題：
存儲成本大：對於時序數據壓縮不佳，需占用大量機器資源；
維護成本高：單機系統，需要在上層人工的分庫分表，維護成本高；
寫入吞吐低：單機寫入吞吐低，很難滿足時序數據千萬級的寫入壓力；
查詢性能差：適用於交易處理，海量數據的聚合分析性能差。
5.2 使用Hadoop生態（Hadoop、Spark等）存儲時序數據會有以下問題：
數據延遲高：離線批處理系統，數據從產生到可分析，耗時數小時、甚至天級；
查詢性能差：不能很好的利用索引，依賴MapReduce任務，查詢耗時一般在分鍾級。
5.3 時序數據庫需要解決以下幾個問題：
時序數據的寫入：如何支持每秒鍾上千萬上億數據點的寫入。
時序數據的讀取：如何支持在秒級對上億數據的分組聚合運算。
成本敏感：由海量數據存儲帶來的是成本問題。如何更低成本的存儲這些數據，將成為時序數據庫需要解決的重中之重。
6.時序數據庫發展簡史與現狀
目前，DB-Engines把時間序列數據庫作為獨立的目錄來分類統計，下圖就是2018年業內流行的時序數據庫的關注度排名和最近5年的變化趨勢。
參考文檔：