時序資料庫破局開放探討

近幾年IoT、IIoT、AIoT和智慧城市快速發展，時序/時空資料庫成為資料架構技術棧的標配。根據國際知名網站DB-Engines資料，時序資料庫在過去24個月內排名高居榜首，且遠高於其他型別的資料庫，可見業內對時序資料庫的需求迫切。

相應的時序資料庫產品近年來也快速發展，出現了多款新的時序資料庫產品，一些老牌時序資料庫也推出下一代產品。本文將介紹現有的主流時序資料庫技術架構，以及開放探討時序資料庫的終局形態。

▲四維縱橫CEO 姚延棟

嘉賓介紹： 北京四維縱橫資料有限公司()創始人、原Greenplum北京研發中心總經理、Greenplum中國開源社群創始人、PostgreSQL中文社群常委、壹零貳肆數字基金會(非營利組織)聯合發起人。2005年畢業於中科院軟體所, 擁有多項國內外雲端計算和大資料專利，並著有《Greenplum：從大資料戰略到實現》。

以下是姚延棟老師在DTCC2021大會現場的演講實錄：

資料處理平臺60年

站在更長遠的角度來看，整個資料處理平臺發展的歷程。我這裡做了一個簡單的回顧，在資料庫出現之前，主要用的是檔案系統。當時，主要的資料是放在主檔案裡面，格式採用flat檔案格式，其實就是固定長度的行，固定個數的列。

後面出現了IDS和IMS，這種層狀和網狀的資料模型。再往後出現了關係型資料庫(OLTP)，以及XML/物件資料庫。到2009年，為了解決網際網路大資料挑戰，比如：擴充套件性、高效能、高併發等問題，出現了NoSQL資料庫。

在整個過程中，大約在上世紀80年代，有一個叫分析型資料庫(OLAP)的分支，也叫MPP資料庫，對分析場景複雜查詢優化。在2010年以後出現了很多新名詞，像NewSQL、HTAP、Lakehouse、多模等。

這些名詞我們就不做詳細介紹了，但是它們的核心點在於跨界融合。從2010年，我們開始嘗試不同的產品之間進行融合，來解決過去需要多個產品解決的問題。到2020年，出現了超融合資料庫，也就是多層次、多角度地進行深度融合。

縱觀過去60年，我們不難發現，大約每隔10年，就會出現一次技術PK。第一次是檔案系統和資料庫，第二次是CODSAL和關聯式資料庫，第三次是XML資料庫和關聯式資料庫，第四次是NoSQL和分散式關聯式資料庫。

當時，很難去辯證哪一個技術在未來會變成更有優勢的技術路線。現如今，基本就明確了關係型資料庫、分散式資料庫的生命力更旺盛。技術的碰撞最終目的是互相學習，然後衍生出適應技術發展的產品形態。

我們講到資料處理平臺時，不可避免會涉及到三個產品。第一個產品是Hadoop，它的演進邏輯是從儲存到計算。它起源於Apache Nutch專案(一個網頁爬取工具和搜尋引擎系統，後來遇到大資料量的網頁儲存問題)。

Apache Nutch需要一個儲存引擎，所以做了HDFS，然後出現平行計算MapReduce和互動查詢Hive，繼而又出現了效率較高的Impala。到目前為止，Hadoop有點遠離大資料的C位，這和它的底層演進邏輯有一定的關係。

第二個產品是Spark，它的演進邏輯是從計算到儲存。Spark RDD是純粹計算的介面，後面出現了Spark SQL和DataFrames，以及Spark Streaming、Spark Graph、Spark ML等。

所以我們能夠看出，Spark的前幾年都在做計算，為了適應不同的場景。但後面，Spark面臨著資料儲存和效能優化的問題，開始做DeltaLake。同時提出了一個詞，叫做Lakehouse，它是一種結合了資料湖和資料倉儲優勢的新正規化。

Snowflake的演進邏輯為從雪花到雪球，然後到更大的雪球。它背後的關鍵設計是存算分離、存算同時演進，開始就是一個完整的資料庫，儲存層和計算層都不斷變化更新。

回顧過去60年，資料處理平臺的發展有規律可循，可以分為圖示四個階段。資料庫演進過程是一個處理複雜度的遊戲，其核心是在需求推動之下，選擇解決哪些複雜度問題，留哪些複雜度問題給使用者，解決的效果如何。

主流時序資料庫架構簡析

最早，在上世紀80年出現的是PI System工業資料庫，主要用於監控分析工業資料。1998年，出現了Kdb+，在證券極速交易場景使用較為廣泛。此後，相繼出現了RRDTool、Graphite，用於伺服器和應用監控。

2011年，出現了首款分散式時序資料庫——OpenTSDB。2013年，起步於伺服器監控現，併發力於IoT的InfluxDB出現。2017年之後，相繼出現了Timescale關係時序資料庫和Timestream時序資料庫。2020年，為時序大資料分析、IoT/IIoT/車聯網而設計MatrixDB面世。

關於經典時序資料庫架構，具體而言，OSISoft PI System擁有兩個元件，PI archiver(自研時序引擎)和微軟SQLServer(內部整合了關聯式資料庫，說明關係資料在時序場景的必要性)。RRDTool以固定時間間隔採集資料、round-robin方式儲存資料，最新資料覆蓋老資料。

Graphite有個資料引擎Whisper，類似RRD，資料庫大小固定，支援降取樣。OpenTSDB基於HBase，是第一款分散式時序資料庫，針對時序KV做了優化，譬如，一小時時間點雜湊為列族的不同列。

比較有意思的是，InfluxDB不斷迭代儲存引擎，從最早的LevelDB/RocksDB到TSM+TSI，再到Parquet+Arrow。下一代產品是IOx，主打分析能力和擴充套件性。TimescaleDB基於PostgreSQL，hack了儲存層，使得1000+行資料可以自動轉為1行，這樣提升壓縮比，降低儲存空間。

MatrixDB是一款基於Greenplum及PostgreSQL開發的超融合時序資料庫，在關聯式資料庫內部實現了全新的儲存引擎，並專為時序資料場景中的高速資料插入和多樣性查詢進行了優化，支援關係資料、時序資料、GIS資料，支援監控類小查詢和大 OLAP 分析，支援JOIN及完善SQL標準。

上圖為行業流行度排名第一的時序資料庫InfluxDB的下一代時序資料庫IOx要實現的目標，我們可以關注兩點。一個是擴充套件性，第二個是分析效能。這也表明了行業老大InfluxDB在時序領域摸爬滾打了多年後對未來時序場景的認知和判斷。

時序資料庫破局探討

當前時序架構具備“DIY技術棧，慢、複雜”三大特徵。其中，慢是指使用專用產品，看似很快，但端到端組合在一起會慢;複雜意味著技術棧複雜，穩定性差，開發運維成本高，軟硬體成本高，效能低，人才稀缺，把複雜度留給了使用者。

那麼，時序資料庫應該是怎樣的呢?它應該是快且簡單的。奧卡姆剃刀原理中指出，“如無必要，勿增實體。”本質上要考慮是誰簡單，誰複雜，能否成熟這種複雜?

未來，如何做一個更適合時序資料庫場景的產品?既然要判斷一個產品，肯定要回歸到場景。和其他資料庫一樣，時序資料庫具備讀和寫兩個場景，但是它的讀和寫都非常有特色，寫的場景需要平穩高效，並且大部分資料是實時資料，讀的場景有點查/最新值、查詢、峰值檢測，高階分析模型等。

整個場景是多種多樣的，為了匹配這種需求，如何去設計產品?時序場景95-99%為寫操作，所以大多數時序資料庫使用類LSM樹方式，基於B+樹的MatrixDB寫入效能是基於LSM/TSM的InfluxDB的幾十倍，是國內友商的十幾倍。

這一點在PG中文社群第三方評測中得到驗證：在400列數的場景下，MatrixDB比InfluxDB快48.6倍，仍然非常強悍，是國產資料庫的一個新亮點。

值得一提的是，理論上講B+樹為讀而優化，LSM樹為寫而優化。原因是B+樹隨機io比較高，但是實際工程實現的時候，有很多手段來降低隨機io，最大限度地平衡儲存和計算，為了提升寫的效能，譬如採用WAL、通過Buffer儘量避免隨機IO，通過分割槽避免B+樹太大等。而LSM引擎為了提升讀的效能，需要內建B+樹加速讀效能，內建Bloomfilter加速讀，建立倒排索引加速查詢，使用WAL避免丟資料。所以最終效果如何還要看實際工程優化的情況。當然我們對比B+樹和LSM的主要目的是說明企業產品優化有很多需要關注的點，而不是說MatrixDB只支援B+樹。實際上MatrixDB支援多種儲存引擎，包括基於B+樹的Heap引擎，也有基於LSM變種的mars儲存引擎。

我們認為最好的時序架構是超融合架構，這種架構把極簡、極速留給客戶。超融合架構的核心是在資料庫中，通過極致的可插拔，實現不同的儲存引擎，可以是行存引擎、列存引擎、記憶體引擎、LSM引擎等。它們之間是互相隔離，互相不會影響。

在未來的資料庫裡面，比較有生命力的是關係模型。關係模型不再是上世紀70年代純粹的只支援簡單資料型別的關係模型，現在的關係資料模型的欄位可以支援複雜資料型別。做一個資料庫極具挑戰，不單單是做引擎，還要做周邊大量的元件。而超融合資料庫基於關係資料模型，通過可插拔儲存實現一個資料庫同時支援關係資料、時序資料、GIS資料、半結構化資料和非結構化資料的All-in-One。

什麼叫超融合資料庫，從開發運維角度來看，它就相當於是關係庫+時序庫+分析庫。以MatrixDB為例，不同的表可以使用不同的儲存引擎，譬如總共200張表，180張表使用heap儲存，用以處理關係資料的讀寫，20張表為時序表，用以儲存時序資料的讀寫，他們之間還可以直接JOIN。

行列混存是在Partition內分資料塊，在塊內按照裝置id、時間戳、溫度和溼度維度以列式方式儲存資料。

MatrixDB具有以下特性：

• 關於時序資料的寫入，支援順序上報、亂序上報、延遲上報、異頻上報、上報訊號/指標動態增減、更新或刪除、自動降取樣、持續聚集等多種方式。

• 寫入的場景具備高效能、平穩持續、實時寫入、資料正確性等特色。其中，95%以上操作是插入，且對效能敏感。平穩持續方面，沒有明顯的高低峰。實時寫入方面，要求秒級寫入。資料正確性方面，保證不錯、不重、不丟，讓開發人員聚焦業務，而不是資料處理。

• 時序資料儲存方面，儲存效率/壓縮比十分重要，好的時序資料庫可以做到10：1左右，針對某些正規化資料壓縮比高達幾十倍。支援針對資料型別進行優化，支援多種編碼壓縮演算法，包括delta-delta、gorilla、RLE、lz4、zstd等，以達到壓縮比和壓縮速度的平衡。

• 支援冷熱資料分級儲存，熱資料、溫資料、冷資料分層，最小化儲存開銷，具備自動分割槽管理功能，到了時間自動會執行相應的操作，無需人工干預。

• 支援多樣性資料型別，比如，字串、數字、日期/時間、布林型別等基本資料型別，以及陣列、IP地址等複合資料型別，兼顧效率和schemaless的靈活性的KV資料型別，點、線、多邊形等空間資料型別(和函式)，XML/JSON 等半結構化型別，文字等非結構化資料型別。

• 支援多樣化的查詢，包括單表的點查、明細、聚集、多維查詢，多表的JOIN，支援10+表關聯，以及子查詢、視窗函式、Cube、CTE等高階分析。

• 支援資料庫內機器學習能力，在資料庫內部，實現了60多種機器學習的演算法，包括監督學習、無監督學習、統計分析、圖計算等。

• 支援資料庫內建分析，比Spark快10倍以上。通過在資料庫內執行Python/R/Java程式碼，避免移動海量資料，實現高效率靈活的資料分析。

• 一個產品本身有很長的路要走，不僅是技術層面，還需要具備完善的開發工具和生態，實現開箱即用。MatrixDB支援各種流行IDE，包括IntelliJ、DataGrip、Dbeaver、Navicat等，可以和BI和視覺化的產品進行對接，支援ETL/CDC，支援MQTT、OPC-UA、OPC-DA、MODBUS等IoT協議。

• 作為一款企業級產品，MatrixDB具備穩定性、完備性，具備圖形化部署，線性擴充套件，可以單機部署，也可以叢集化部署，監控、報警以及視覺化，線上擴容，不停機，不停業務，分散式備份恢復，資源管理，分鐘級升級等功能。

總的來看，時序形態不是資料庫，而是一種看待資料的視角，可以認為是一種時間維度的資料型別，終局是超融合時序資料庫。

第一代是influxDB這樣的僅支援時序的資料庫。

第二代，TimescaleDB同時支援時序和關係資料。

第三代，MatrixDB超融合時序資料庫，支援多模態資料，支援全場景查詢，服務物聯網海量資料監控、分析及儲存的超融合時序資料庫，解決過去關係型、時序型、分析型等不同型別資料庫孤島化問題。幫助企業解決當前技術棧複雜，開發運維及軟硬體成本高，效能低等痛點。