聊聊時序資料庫發展情況

前陣子有朋友留言希望我寫篇關於時序資料庫的文章，以前我討論的資料庫大多數是RDBMS，其他資料庫討論的不多。說實在的對於時序資料庫，我也只是一個小學生，我的客戶使用時序資料庫在一個應用系統中只是一部分很小的功能，大部分的應用系統的主要資料還是使用關係型資料庫。

隨著工業網際網路的發展，以及物聯網技術與應用的發展，時序資料庫變得越來越熱了。時序資料庫是一種特殊的資料庫管理系統，針對時間序列資料的處理進行了最佳化，每條記錄都有時間戳。時序資料可能由物聯網中的感測器、智慧儀表或 RFID 產生，也可以由電網執行的各個採集點中產生，也可以從股票交易記錄中產生。

時序資料的處理與關係型資料庫的處理事不同的，時序資料庫旨在有效地收集、儲存和查詢高頻產生的各種時間序列資料。並在資料庫的入庫、批次查詢、時序資料分析和過期資料自動處理等方面有著獨特的方式。儘管可以使用傳統的關係型資料庫或者鍵值資料庫來管理時序資料。其特點是大批次的寫入帶有時間戳的資料，可能高達每秒幾百萬甚至幾千萬個。同時資料被一次寫入後不再修改，會被多次讀取使用。這些資料要麼被用於實時分析，要麼被用於事後研究。一般應用軟體會按照某種規則按照時間區間來裝載一批資料，或者透過內建的統計函式去分析這些資料。這種應用往往不太關注單點的資料或者幾個資料之間的關係。

因為有一部分資料量並不是很大的時序資料庫應用可以採用關係型資料庫、HBASE、REDIS這樣的KV資料庫來儲存，因此在日常應用中純時序資料庫使用的相對較少。因此時序資料庫這些年發展的不溫不火。從DB-ENGINES上看，純粹的時序資料庫的流行度得分並不高。

以第一模式為時序資料庫型別的資料庫排名看，排名最高的InfluxDB也僅僅29.15分，在資料庫流行度排名中十分靠後。如果我們把主要資料庫模式是其他型別，第二模式帶有時序資料庫模式的資料庫加上，看到的是一個完全不同的情況。

在這裡我們看到了一些大佬的身影，特別是現在大火的MongDB，作為文件資料庫，MongoDB實際上是一種多模資料庫，也支援時序資料。在國內MongoDB僅僅被作為文件資料庫使用，僅僅儲存一些目錄與日誌資訊，不過MongoDB是一個十分全能的資料庫產品，支援強一致性交易，甚至在時序資料庫模式上也十分強大。西門子、博世等世界五百強企業用MongoDB來處理時序資料。在目前XC替代方面，實際上MongoDB是十分難以替代的，特別是你真正用了MongDB的事務、時序特性等，沒有第二個資料庫產品擁有MongoDB如此強大的功能。而MongoDB從商業利益上考慮將開源協議轉為SSPL後，開始收割雲服務廠商，而這種接近於商用協議的開源協議極容易受到美國政府出口管制措施的影響，因此對於有XC要求的企業來說，還是要十分小心的。

令人意外的事Redis這種我們經常用來做緩衝的，十分簡單的記憶體KV資料庫，也是多模的，也支援時序資料。Redis支援SortedSets資料結構，支援按權重儲存資料並支援按照權重的範圍查詢。如果把時間戳作為權重值，key儲存具體的度量維度，那麼Redis就可以支援時序資料了。不過這種模式過於簡單粗暴，十分消耗記憶體，而且併發寫入效能也不好，只適合最為簡單的模式。從Redis 5.0開始，Redis開始支援訊息佇列Stream，流式資料也是時序資料處理中的一種常見場景。而真正讓Redis具有真正的流式資料庫能力的是Redis TimeSeries擴充套件模組的引入。這是專門面向時間序列資料提供了資料型別和訪問介面，並且支援在Redis端上直接對資料進行時間範圍的聚合計算(min、max、avg、sum、range、count、first、last)。

在這個列表裡我們還看到了最近比較火的ClickHose。Clickhouse是俄羅斯yandex公司於2016年開源的一個列式資料庫管理系統，近些年像一匹黑馬一樣迅速在具有時序處理需求的OLAP場景中收割使用者。其向量化引擎SIMD讓一些大資料量的簡單分析查詢效能得到了極大的釋放。只不過ClickHose簡單粗暴的向量引擎限制了應用的併發，不過在OLAP場景中，高併發並不總是剛需。

大多數時序資料庫的應用場景可以將時序資料庫獨立開來儲存與訪問，而應用中的較為複雜的業務資料可以放在關係型資料庫裡。而時序資料的讀寫場景相對簡單，因此時序資料庫在資料庫領域的熱度較低。

有些關係型資料庫使用者開始的時候都把時序資料儲存在關係型資料庫裡，不過因為時序資料的資料量太大了。會導致關係型資料庫的容量變得超大，我以前做過一個最佳化專案，業務資料庫的庫容高達上百TB，而實際上裡面的關係型的業務資料只有幾百GB，大多數都是寫入後只讀的時序資料。後來我建議他們吧時序資料獨立出去了，這樣資料庫備份，運維就簡單多了。

而把超大規模的時序資料寫入關係型資料庫，很可能就會到達關係型資料庫的天花板，讓資料庫的效能無法跟上。如果把這類資料儲存到純粹的時序資料庫裡，那麼就很容易利用其分散式特性很好的橫向擴充套件了。時序資料庫儲存這些資料的時候，會佔用更小的空間，也很容易實現自動的資料壓縮。另外利用專用的API訪問時間，對資料做複雜的彙總統計，也比SQL介面要快捷的多。因此很多企業都陸續將時序資料從傳統的關係型資料庫中分離出來，儲存到專業的時序資料庫中。

不過還有另外一種思路，那就是在關係型資料庫中增加時序資料庫的能力。最為典型的就是TimeScaleDB。當時序資料的量還不算太大的時候，有些使用者選擇了將時序資料儲存到關係型資料庫中。在PostgreSQL資料庫中安裝TimeScaleDB外掛，建立時序表來儲存時序資料。同事利用PG的SQL引擎來訪問和處理這些時序資料。利用TimeScaleDB的歷史資料自動壓縮功能壓縮歷史資料，可以大大減少海量歷史資料的儲存量。我們的D-SMART中需要採集大量的資料庫的監控資料，大概每2分鐘採集一次，每次有上千個例項，每個例項有數百條記錄。這樣的話，一個納管了2000個資料庫的D-SMART，每隔兩分鐘，就會有100萬條資料被寫入TimeScaleDB，並且這些資料還需要按照時間區間，透過SQL查詢出來，進行分析處理。從這些年的使用來看，TimeScaleDB是可以輕鬆應對這樣的場景的，每個SQL查詢也都是幾十毫秒就可以完成。我們最初是使用PG的普通表儲存這些監控資料的，換成TimeScaleDB後，寫入效能與查詢效能都有了多倍的提升。最令我們喜歡的是歷史資料的自動壓縮功能，作為運維自動化系統，7天前的監控資料被訪問的比例很低，因此我們設定了7天資料自動壓縮，大大節約了儲存資源。

使用TimeScaleDB最大的好處是保留了我們團隊在SQL上的所有研發經驗，只要不亂寫SQL，大部分SQL不需要特殊的最佳化改寫，就可以達到效能要求。實現這種開發自由來自於TimeScaleDB優秀的設計，因為時間問題，我們在這裡就展開討論了。如果是千萬到數億級別的時序資料處理，使用TimeScaleDB是沒有任何壓力的。

國產的時序資料庫產品也很多，在墨天輪上目前有32種國產時序資料庫，已經和DB-ENGINES上35種純時序資料庫的列表差不多長了。其中排名靠前的濤思資料的TDengine和智叟科技的DolphinDB。在DB-ENGINES的時序資料庫排行中，這兩種時序資料庫也比較靠前。也有一些國產時序資料庫基於openTSDB，或者與之相容。

時序資料庫與時序應用的發展呈現出三種模式，大家也都在爭論哪種模式更好。

第一種模式是放棄關係型資料庫，轉向時序資料庫或者用帶有時序資料庫模式的多模資料庫替代關係型資料庫。利用原生分散式架構，帶有向量處理能力的資料庫引擎來支撐特別大資料量寫入，大資料量輸出需求的場景。這些人認為NOSQL才是時序資料處理的最終解決方案。

第二種模式正好相反，他們從NOSQL的時序資料庫轉向了具有時序資料處理能力的關係型資料庫，充分利用SQL的能力來解決應用的問題。最典型的就是我今天介紹的D-SMART裡使用的TimeScaleDB。對於更大資料量的需求，可以使用CrateDB、TDengine這樣的分散式資料庫。

第三種模式是使用HBASE這樣的KV資料庫來儲存時序資料，而不專門使用時序資料庫。對於僅僅把海量時序資料找個地方存起來，滿足大併發寫入，大吞吐量輸出的場景要求就行了，大量的資料處理都是應用程式自己來幹，那麼這樣的用法也沒啥問題。

實際上也無需爭論，因為不同的應用場景就會選擇不同的模式。到底你選擇什麼樣的時序資料庫方案，往往取決於下面幾個因素：1)你的時序資料的量級是什麼樣的，每秒幾萬，幾十萬，還是幾百萬，幾千萬;2)你的時序資料如何被使用，每次讀取的批次是多少;3)你需要資料庫的內建功能來處理和分析時序資料，還是有自己的資料分析應用模組;4)你如何處理過期的資料;5)你的歷史資料的訪問模式;6)你的查詢併發QPS是多少……

我想你把這幾個問題考慮清楚了，再根據目前主流的時序資料庫或者帶有時序功能的多模資料庫的特徵去找尋，那麼就不難做出相對靠譜的選擇了。