2017年時序數據庫突然火了起來。開年2月Facebook開源了beringei時序數據庫；到了4月基于PostgreSQL打造的時序數據庫TimeScaleDB也開源了，而早在2016年7月，百度云在其天工物聯網平臺上宣布了海內首個多租戶的漫衍式時序數據庫產物TSDB，成為支持其成長制造，交通，能源，伶俐都市等財富規模的焦點產物，同時也成為百度計謀成長財富物聯網的符號性事件。時序數據庫作為物聯網偏向一個很是重要的處事，業界的幾回發聲，正說明各家企業已經火燒眉毛的擁抱物聯網時代的到來。
本文會從時序數據庫的根基觀念、利用場景、辦理的問題一一展開，最后會從如何辦理時序數據存儲這一技能問題入手舉辦深入闡明。
1. 配景
百度無人車在運行時需要監控各類狀態，包羅坐標，速度，偏向，溫度，濕度等等，而且需要把時時刻刻監控的數據記錄下來，用來做大數據闡明。每輛車天天就會收羅快要8T的數據。假如只是存儲下來不查詢也還好（固然已經是不小的本錢），但假如需要快速查詢"本日下午兩點在后廠村路，速度高出60km/h的無人車有哪些"這樣的多緯度分組聚合查詢，那么時序數據庫會是一個很好的選擇。
2. 什么是時序數據庫
先來先容什么是時序數據。時序數據是基于時間的一系列的數據。在有時間的坐標中將這些數據點連成線，往已往看可以做成多緯度報表，展現其趨勢性、紀律性、異常性；往將來看可以做大數據闡明，呆板進修，實現預測和預警。
時序數據庫就是存放時序數據的數據庫，而且需要支持時序數據的快速寫入、耐久化、多緯度的聚合查詢等根基成果。
比擬傳統數據庫僅僅記錄了數據的當前值，時序數據庫則記錄了所有的汗青數據。同時時序數據的查詢也老是會帶上時間作為過濾條件。
時序數據示例
下面先容下時序數據庫的一些根基觀念（差異的時序數據庫稱號略有差異）。
metric： 懷抱，相當于干系型數據庫中的table.
data point： 數據點，相當于干系型數據庫中的row.
timestamp：時間戳，代表數據點發生的時間。
field： 懷抱下的差異字段。好比位置這個懷抱具有經度和緯度兩個field.一般環境下存放的是會跟著時間戳的變革而變革的數據。
tag： 標簽，可能附加信息。一般存放的是并不跟著時間戳變革的屬性信息。timestamp加上所有的tags可以認為是table的primary key.
如下圖，懷抱為Wind，每一個數據點都具有一個timestamp，兩個field：direction和speed，兩個tag：sensor、city.它的第一行和第三行，存放的都是sensor號碼為95D8-7913的設備，屬性都市是上海。跟著時間的變革，風向和風速都產生了改變，風向從23.4釀成23.2；而風速從3.4釀成了3.3.
p3-時序數據庫根基觀念圖
3. 時序數據庫的場景
所有有時序數據發生，而且需要揭示其汗青趨勢、周期紀律、異常性的，進一步對將來做出預測闡明的，都是時序數據庫適合的場景。
在家產物聯網情況監控偏向，百度天工的客戶就碰著了這么一個困難，由于家產上面的要求，需要將工況數據存儲起來。客戶每個廠區具有20000個監測點，500毫秒一個收羅周期，一共20個廠區。這樣算起來一年將發生驚人的26萬億個數據點。假設每個點50Byte，數據總量將達1P（假如每臺處事器10T的硬盤，那么總共需要100多臺處事器）。這些數據不可是要及時生成，寫入存儲；還要支持快速查詢，做可視化的展示，輔佐打點者闡明決定；而且也可以或許用來做大數據闡明，發明深條理的問題，輔佐企業節能減排，增加效益。最終客戶回收了百度天工的時序數據庫方案，輔佐他辦理了困難。
在互聯網場景中，也有大量的時序數據發生。百度內部有大量處事利用天工物聯網平臺的時序數據庫。舉個例子，百度內部處事為了保障用戶的利用體驗，將用戶的每次網絡卡頓、網絡延遲城市記錄到百度天工的時序數據庫。由時序數據庫直接生成報表以供技能產物做闡明，盡早的發明、辦理問題，擔保用戶的利用體驗。
4. 時序數據庫碰著的挑戰
許多人大概認為在傳統干系型數據庫上加上時間戳一列就能作為時序數據庫。數據量少的時候確實也沒問題，但少量數據是揭示的緯度有限，細節少，可置信低，越發不能用來做大數據闡明。很明明時序數據庫是為了辦理海量數據場景而設計的。
可以看到時序數據庫需要辦理以下幾個問題
時序數據的寫入：如何支持每秒鐘上千萬上億數據點的寫入。
時序數據的讀取：又如何支持在秒級對上億數據的分組聚合運算。
