摘要：本文會從時序數據庫的基本概念、應用場景、需求與能力等方面一一展開，帶你瞭解時序數據庫的前世此生。
時序數據庫突然火了起來。Facebook開源了beringei時序數據庫，基於PostgreSQL打造的時序數據庫TimeScaleDB也開源了。時序數據庫做爲物聯網方向一個很是重要的服務，業界的頻頻發聲，正說明各家企業已經火燒眉毛的擁抱物聯網時代的到來。html
本文會從時序數據庫的基本概念、應用場景、需求與能力等方面一一展開，帶你瞭解時序數據庫的前世此生。算法
應用場景
時序數據庫是一種針對時序數據高度優化的垂直型數據庫。在製造業、銀行金融、DevOps、社交媒體、衛生保健、智慧家居、網絡等行業都有大量適合時序數據庫的應用場景：sql
- 製造業：好比輕量化的生產管理雲平臺，運用物聯網和大數據技術，採集、分析生產過程產生的各種時序數據，實時呈現生產現場的生產進度、目標達成情況，以及人、機、料的利用情況，讓生產現場徹底透明，提升生產效率。
- 銀行金融：傳統證券、新興的加密數字貨幣的交易系統，採集、分析交易過程當中產生的時序數據，實現金融量化交易。
- DevOps：IT基礎設施和應用的運維繫統，採集、分析設備運行和應用服務運行監控指標，實時掌握設備和應用的健康狀態。
- 社交媒體：社交APP大數據平臺，跟蹤用戶交互數據，分析用戶習慣、改善用戶體驗；直播系統，採集直播過程當中包括主播、觀衆以及中間各環節的監控指標數據，監控直播質量。
- 衛生保健：商業智能工具，採集智能手錶，智能手環中的健康數據，跟蹤關鍵指標和業務的整體健康狀況
- 智慧家居：居家物聯網平臺，採集家居智能設備數據，實現遠程監控。
- 網絡：網絡監控系統，實時呈現網絡延時、帶寬使用狀況。
時序數據的需求
在上述場景中，特別在IoT物聯網以及OPS運維監控領域，存在海量的監控數據須要存儲管理。以華爲雲Cloud Eye Service(CES)服務爲例，單個Region須要監控7000多萬個監控指標，每秒須要處理90萬個上報的監控指標項，假設每一個指標50個字節，一年的監控數據有1PB；自動駕駛的車輛一天各類傳感器監測數據就80G。數據庫
傳統關係型數據庫很難支撐這麼大的數據量以及這麼大的寫入壓力，Hadoop大數據解決方案以及現有的時序數據庫也會面臨很是大的挑戰。大規模IoT物聯網，以及公有云規模的運維監控場景，對時序數據庫的需求主要包括：網絡
- 持續高性能寫入：監控指標每每以固定的頻率採集，部分工業物聯網場景傳感器的採集頻率很是高，有的已經達到100ns，公有云運維監控場景基本也是秒級採集。時序數據庫須要支持7*24小時不中斷的持續高壓力寫入。
- 高性能查詢：時序數據庫的價值在於數據分析，並且有較高的實時性要求，典型分析任務如異常檢測及預測性維護，這類時序分析任務須要頻繁的從數據庫中獲取大量時序數據，爲了保證分析的實時性，時序數據庫須要能快速響應海量數據查詢請求。
- 低存儲成本：IoT物聯網及運維監控場景的數據量曾現指數級增加，數據量是典型的OLTP數據庫場景的千倍以上，而且對成本很是敏感，須要提供低成本的存儲方案。
- 支持海量時間線：在大規模IoT物聯網及公有云規模的運維場景，須要監控的指標一般在千萬級甚至億級，時序數據庫要能支持億級時間線的管理能力。
- 彈性：監控場景也存在業務突發增加的場景，例如：華爲Welink服務的運維監控數據在疫情期間暴增100倍，時序數據庫須要提供足夠靈敏的彈性伸縮能力，可以快速擴容以應對突發的業務增加。
開源時序數據庫能力
過去10年，隨着移動互聯網、大數據、人工智能、物聯網、機器學習等相關技術的快速應用和發展，涌現出許多時序數據庫，由於不一樣數據庫採用的技術和設計初衷不同，因此在解決上述時序數據需求上，他們之間也表現出現較大的差別，本文在下面內容將選擇使用最多的幾種開源時序數據庫爲分析對象進行討論。架構
- OpenTSDB
OpenTSDB基於Hbase數據庫做爲底層存儲，向上封裝本身的邏輯層和對外接口層。這種架構能夠充分利用Hbase的特性實現了數據的高可用和較好的寫入性能。但相比Influxdb，OpenTSDB數據棧較長，在讀寫性能和數據壓縮方面都還有進一步優化的空間。運維
- InfluxDB
Influxdb是業界比較流行的一個時間序列數據庫，它擁有自研的數據存儲引擎，引入倒排索引加強了多維條件查詢的功能，很是適合在時序業務場景中使用。因爲時序洞察報表和時序數據聚合分析，是時序數據庫主要的查詢應用場景，每次查詢可能須要處理上億數據的分組聚合運算，因此在這方面，InfluxDB採用的火山模型對聚合查詢性能影響較大。機器學習
- Timescale
TimeScale是一個基於傳統關係型數據庫postgresql改造的時間序列數據庫，繼承了postgresql許多優勢，好比支持SQL，支持軌跡數據存儲，支持join，可擴展等等，讀寫性能好。TimeScale採用固定schema，數據佔用空間大，對於時序業務長期相對固定且對數據存儲成本不敏感的業務來講，也是一種選擇。異步
GaussDB（For Influx）的出現
針對高性能寫入、海量時間線和高數據壓縮的需求，當前還未能有比較好的開源解決方案。GaussDB（For Influx）汲取了開源各家之長，設計了雲原生架構的時序數據庫。架構以下圖所示。數據庫設計
相比現有的開源時序數據庫，架構設計上有如下兩方面的考慮：
- 存儲與計算分離
存儲計算分離，一方面利用成熟的分佈式存儲系統提升系統的可靠性。監控數據一直持續高性能寫入，同時還有大量的查詢業務，任何系統故障致使業務中斷甚至數據丟失都會形成嚴重的業務影響，而利用通過驗證的成熟的分佈式存儲系統，可以顯著的提高系統可靠性，下降數據丟失風險，並明顯縮短構建本系統的時間。
另外一方面，解除在傳統Share Nothing架構下，數據和節點物理綁定的約束，數據只是邏輯上歸宿於某個計算節點，使得計算節點無狀態化。這樣在擴容計算節點時，能夠避免在計算節點間遷移大量的數據，只須要邏輯上將部分數據從一個節點移交給另一個節點便可，能夠將集羣擴容的耗時從以天爲單位縮短爲分鐘級別。
再一方面，經過將多副本複製從計算節點卸載到分佈式存儲節點，能夠避免用戶以Cloud Hosting形態在雲上自建數據庫時，分佈式數據庫和分佈式存儲分別作3副本複製致使總共9副本冗餘的問題，可以顯著下降存儲成本。
- Kernel Bypass
爲了不在用戶態內核態來回拷貝數據帶來的性能損失，GaussDB（for Influx）系統端到端考慮Kernel bypass設計，沒有選擇使用標準的分佈式塊或分佈式文件服務，而是定製的針對數據庫設計的分佈式存儲，對外暴露用戶態接口，計算節點採用容器化部署，經過專用存儲網絡直接和存儲節點通訊
除了架構以外，GaussDB（for Influx）還針對IoT物聯網及運維監控場景的其餘需求作了以下優化：
- 寫優化的LSM-Tree佈局和異步Logging方案，相比當前時序數據庫提高94%寫性能。
- 經過向量化查詢引擎，ARC Block Cache，以及Aggregation Result Cache提高聚合查詢性能，相比當前時序數據庫提高最高可達9倍
- 設計針對時序數據分佈特徵的壓縮算法，壓縮率相比Gorilla提高2倍，並自動將冷數據分級到對象存儲，下降60%存儲成本
- 優化海量時間線的索引算法，提高索引效率，在千萬時間線量級下，寫入性能是當前時序數據庫的5倍。
GaussDB（for Influx）成功保障了公司welink和雲監控CES兩大服務以後上線商用，接下來咱們還將探索如何在海量數據中尋找有價值數據的高效分析方法，爲用戶提供更加合適的分析和洞察能力。
參考文獻
https://zhuanlan.zhihu.com/p/32709932
https://www.cnblogs.com/jpfss/p/12183214.html