1.概述

        時序列資料庫（Time series database）：用來儲存時序列（time-series）資料並以時間（點或區間）建立索引的軟體一般時序列資料都具備

        資料結構簡單：某一度量指標在某一時間點只會有一個值，沒有複雜的結構（巢狀、層次等）和關係（關聯、主外來鍵等）

        資料量大：由於時序列資料由所監控的大量資料來源來產生、收集和傳送，比如主機、IoT裝置、終端或App等

2.時序資料的幾個特點

（1）基本上都是插入，沒有更新的需求。

（2）資料基本上都有時間屬性，隨著時間的推移不斷產生新的資料。

（3）資料量大，每秒鐘需要寫入成千萬上億條資料

3.業務方常見需求

（1）獲取最新狀態，查詢最近的資料(例如感測器最新的狀態)

（2）展示區間統計，指定時間範圍，查詢統計資訊，例如平均值，最大值，最小值，計數等。。。

（3）獲取異常資料，根據指定條件，篩選異常資料

4.常見業務場景監控軟體系統： 

（1）虛擬機器、容器、服務、應用監

（2）控物理系統： 水文監控、工廠的裝置監控、國家安全相關的資料監控、通訊監控、感測器資料、血糖儀、血壓變化、心率等

（3）資產跟蹤應用： 汽車、卡車、物理容器、運貨托盤

（4）金融交易系統： 傳統證券、新興的加密數字貨幣

（5）事件應用程式： 跟蹤使用者、客戶的互動資料

（6）商業智慧工具： 跟蹤關鍵指標和業務的總體健康情況

        在網際網路行業中，也有著非常多的時序資料，例如使用者訪問網站的行為軌跡，應用程式產生的日誌資料等等。

5.一些基本概念(不同的時序資料庫稱呼略有不同)

（1）Metric:  度量，相當於關係型資料庫中的 table。

（2）Data point:  資料點，相當於關係型資料庫中的 row。

（3）Timestamp：時間戳，代表資料點產生的時間。

（4）Field:  度量下的不同欄位。比如位置這個度量具有經度和緯度兩個 field。一般情況下存放的是隨時間戳而變化的資料。

（5）Tag:  標籤。一般存放的是不隨時間戳變化的資訊。timestamp 加上所有的 tags 可以視為 table 的 primary key。

        例如採集有關風的資料，度量為 Wind，每條資料都有時間戳timestamp，兩個欄位 field：direction(風向)、speed(風速)，兩個tag：sensor(感測器編號)、city(城市)。第一行和第三行，存放的都是 sensor 編號為86F-2RT8的裝置，城市是深圳。隨著時間的變化，風向和風速發生了改變，風向從56.4變為45.6，風速從2.9變為3.6。

6.時序資料庫遇到的挑戰

　　很多人可能認為在傳統關係型資料庫上加上時間戳一列就能作為時序資料庫。資料量少的時候確實也沒問題，但少量資料是展現的緯度有限，細節少，可置信低，更加不能用來做大資料分析。很明顯時序資料庫是為了解決海量資料場景而設計的。

　　可以看到時序資料庫需要解決以下幾個問題

　　l 時序資料的寫入：如何支援每秒鐘上千萬上億資料點的寫入。

　　l 時序資料的讀取：又如何支援在秒級對上億資料的分組聚合運算。

　　l 成本敏感：由海量資料儲存帶來的是成本問題。如何更低成本的儲存這些資料，將成為時序資料庫需要解決的重中之重。

　　這些問題不是用一篇文章就能含蓋的，同時每個問題都可以從多個角度去優化解決。在這裡只從資料儲存這個角度來嘗試回答如何解決大資料量的寫入和讀取。

7.常見時序資料庫

    時序資料庫出現的時間較晚，目前較成熟的時序資料庫都僅有1、2年的歷史。

    InfluxDB(單機版免費，叢集版收費)最成熟，Kairosdb(底層使用Cassandra)，OpenTsdb(底層使用Hbase)，beringei(FB開源)，TimeScaleDB(底層基於PostgreSQL)，TSDB(百度開源)，HiTSDB(阿里開源，底層是PostgreSQL)。

8.如何去選擇時序列資料庫

    時序資料庫有很多 請檢視：https://db-engines.com/en/ranking/time+series+dbms

    選擇時可以從以下方面綜合考慮

    效能、儲存方案、叢集功能、API（HTTP API和Client Library）、SQL-like Query Language、部署體驗、成熟度、視覺化和報警功能、所採用技術棧、保留策略（Retention Policies，或自動刪除、壓縮）、背後主導公司、License、安全性等等。