據研究機構Forrester預測，物聯網所帶來的產業價值要比互聯網高30倍，到2020年，中國物聯網產業將成長為一個超過五萬億規模的巨大市場。

5G、AI、區塊鏈等新一代信息技術與物聯網加速融合。在智能互聯的愿景中，物聯網系統的機器、設備和傳感器收集的數據，通過人工智能技術進行分析與關聯，以更有意義的方式服務用戶。然而，隨著物聯網數據量的增長，“時序數據庫”成為企業面臨的“必答題”。

高性能時序數據庫，是物聯網的數據存儲底座

時序數據庫是一種針對時序數據進行垂直優化的數據庫，專門用于存儲和管理時序數據。向宇舉例到，某個酒店在晚上8：00有200個房間被入住，那個8：00時間點上存儲的200的數字就是時序數據。

在物聯網和運維監控場景下，如服務器CPU和內存使用量、電動汽車的工況數據、或是應用服務的業務指標等等，各種被采集的數據指標項多達千萬甚至上億，甚至一次采集的指標數據就可能超過數10GB，這些數據都必須要在規定時間內全部寫入數據庫。并且，指標數據通常間隔幾秒就會被采集一次，如此海量的時序數據必然要求數據庫要具備大并發寫入能力和很高的數據壓縮效率。

此外，時序業務通常還需要將數據從數據庫中檢索出來，以近乎實時的可視化方式展現，方便分析和決策，這對數據庫的查詢性能也有著嚴格的要求。在這種場景下，傳統的關系型數據庫最大的問題在于數據缺少壓縮，查詢效率低下，時序數據庫一開始就被設計為高吞吐、低時延、高數據壓縮率，以滿足物聯網和運維監控場景下對性能和儲存成本的訴求。也正是因為時序數據庫的這些特點，在制造業、銀行金融、社交媒體、能源、智慧家居等行業領域都有大量的應用場景。

凝結10多年軟硬件技術經驗，未來挑戰重重

根據IDC的一份白皮書預測，到2025年全球數據總量將達到175ZB，這其中30%為時序數據。時序數據庫是在最近10年才真正發展起來，這期間出現了許許多多的時序數據庫，光DBEngines網站收錄的全球時序數據庫就多達有30多種。

向宇談到，相比關系型數據庫，時序數據庫略微簡單一些，沒有復雜的事務支持，也沒有針對單條數據的更新和刪除操作。但要做好一個時序數據庫并非易事，就像造車一樣，要造好一輛車，單純購買零件組裝測試是遠遠不夠的，還需要考慮質量、性能、舒適性、功能性、安全性等等，一輛車凝結著人類智慧與文化的結晶。

打造一款時序數據庫，需要凝結數十年數據庫領域發展的硬件和軟件技術和經驗，如存儲、安全、分布式系統、編譯、算法、數據結構、架構設計等等，更要做到系統安全、可靠、穩定、高效和多場景通用。“未來會有越來越多的企業希望利用時序數據庫挖掘出更多有價值的信息，時序數據庫在海量時間線管理、數據壓縮、讀寫性能等方面正面臨著巨大的技術挑戰。”向宇講到。

云原生存算分離架構，華為云數據創新Lab實踐

時序數據庫，作為整個物聯網的數據存儲底座，同時也是云廠商基礎設施的重要部分。作為全球云服務提供商，華為云的迅速發展，其背后是大量基礎設施的擴張，如何能把所有的基礎設施和云服務完全監控起來，是擺在運維團隊面前不得不去解決的技術問題。現有的開源時序數據庫已經不能滿足華為云監控數據日益增長的訴求，監控指標數量從數百萬迅速增加到數十億，每秒數據寫入量從數億條迅速增長到數十億條，迫切需要一款自研的時序數據庫可以支撐運維團隊的監控系統。

在2018年開始，向宇所在的華為云數據創新Lab開始著眼于未來物聯網和運維監控場景下的時序數據存儲與管理，自研時序數據庫GaussDB（for Influx）。在經過內部場景的驗證后，GaussDB（for Influx）于2020年正式上線對外商用。

GaussDB（for Influx）采用云原生存儲與計算分離架構，支持分鐘級彈性節點擴縮容，做到不遷移數據的同時還把事情給做了；支持億級時間線，每天萬億條數據寫入不是問題；支持數據無損壓縮，采用自適應數據壓縮算法，將數據壓縮比提高到1:20；運用MPP架構、向量化、預聚合等相關技術，相比開源的OpenTSDB、InfluxDB等時序數據庫，對于像單時間線條件查詢和多維聚合查詢這類在時序數據庫中較為常見的查詢，性能上有很大幅度的提升。

向宇介紹到，華為云的一個業務從Cassandra切換到GaussDB（for Influx）后，計算節點從總共39個（熱集群18個，冷集群9個，大數據分析集群 12個）降低到了9個節點，縮減4倍計算節點。存儲空間消耗從每天1TB降低到100GB以內，縮減10倍存儲空間消耗。

目前華為云時序數據庫GaussDB（for Influx）已經服務15+內部和外部客戶，已成為華為云基礎設施重要組成部分。

研發之路沒有現成的參考答案，迎難而上正面“剛”

回想時序數據庫GaussDB（for Influx）研發過程的時候，向宇說道，一個系統從誕生到成熟，往往伴隨著長期的Bug修復和結合場景的持續優化。因為任何人都無法提前把所有的應用場景都想到并且測試覆蓋到，GaussDB（for Influx） 也不例外。

當初研發GaussDB（for Influx）時，向宇團隊遇到的第一個問題就是“進程OOM（內存耗盡觸發操作系統保護機制）退出”。大家都知道，出現OOM只可能有兩個原因，一是內存泄漏，二是內存真實使用過多。

眾所周知，數據庫里面的數據是存放到磁盤文件，高效率的數據檢索往往需要在內存中建立文件索引，方便快速定位數據在文件中的位置。在時序數據庫中，當數據在數據庫中保留的時間越長，數據文件就會越大，文件數量也就越多。程序重啟過程中，需要將每個數據文件的元數據讀取到內存組織為索引，這里的元數據主要包括當前文件存放有多少時間線，每個時間線的數據在文件中的偏移量等等。在運維監控的場景下，時間線的數量是呈指數增長，當時序數據庫的時間線超過億級，虛擬機規格不變的情況下，問題出現了，元數據無法全部存放內存再轉化為索引，于是程序出現OOM無法重啟。

向宇進一步闡述道，時序數據庫難就難在這里，因為絕大部分用戶或者場景不會達到出現問題的時間線和數據量，面對計算資源有限，而數據量太大的情況，行業中并無行之有效的現成方法，解決這樣的問題，往往需要結合技術和經驗。舉個例子，程序重啟過程中加載元數據，為避免在內存積壓太多數據，可以選擇限流的方式，那么每次處理的數據量閾值應當如何設置就依賴長期的系統開發經驗，太大可能問題還會存在，太小又耗時過長。

“有問題不可怕，可怕的是沒有問題。當問題發生時，我們的選擇是正面‘硬剛’，出現一個消滅一個！”向宇談到。不難看出，也正是他們的這種不畏艱難，用“匠人”精神開發出華為云基礎設施重要組成部分，并且已經服務15+內部和外部客戶的華為云時序數據庫GaussDB（for Influx）。

原文標題：爆文速遞| 華為云專家向宇：工欲善其事必先利其器，才能做數據的“管家”

文章出處：【微信公眾號：華為開發者社區】歡迎添加關注！文章轉載請注明出處。
責任編輯:pj