前陣子有朋友留言希望我寫篇關(guān)于時序數(shù)據(jù)庫的文章，以前我討論的數(shù)據(jù)庫大多數(shù)是RDBMS，其他數(shù)據(jù)庫討論的不多。說實在的對于時序數(shù)據(jù)庫，我也只是一個小學(xué)生，我的客戶使用時序數(shù)據(jù)庫在一個應(yīng)用系統(tǒng)中只是一部分很小的功能，大部分的應(yīng)用系統(tǒng)的主要數(shù)據(jù)還是使用關(guān)系型數(shù)據(jù)庫。

隨著工業(yè)互聯(lián)網(wǎng)的發(fā)展，以及物聯(lián)網(wǎng)技術(shù)與應(yīng)用的發(fā)展，時序數(shù)據(jù)庫變得越來越熱了。時序數(shù)據(jù)庫是一種特殊的數(shù)據(jù)庫管理系統(tǒng)，針對時間序列數(shù)據(jù)的處理進行了優(yōu)化，每條記錄都有時間戳。時序數(shù)據(jù)可能由物聯(lián)網(wǎng)中的傳感器、智能儀表或 RFID 產(chǎn)生，也可以由電網(wǎng)運行的各個采集點中產(chǎn)生，也可以從股票交易記錄中產(chǎn)生。

時序數(shù)據(jù)的處理與關(guān)系型數(shù)據(jù)庫的處理事不同的，時序數(shù)據(jù)庫旨在有效地收集、存儲和查詢高頻產(chǎn)生的各種時間序列數(shù)據(jù)。并在數(shù)據(jù)庫的入庫、批量查詢、時序數(shù)據(jù)分析和過期數(shù)據(jù)自動處理等方面有著獨特的方式。盡管可以使用傳統(tǒng)的關(guān)系型數(shù)據(jù)庫或者鍵值數(shù)據(jù)庫來管理時序數(shù)據(jù)。其特點是大批量的寫入帶有時間戳的數(shù)據(jù)，可能高達每秒幾百萬甚至幾千萬個。同時數(shù)據(jù)被一次寫入后不再修改，會被多次讀取使用。這些數(shù)據(jù)要么被用于實時分析，要么被用于事后研究。一般應(yīng)用軟件會按照某種規(guī)則按照時間區(qū)間來裝載一批數(shù)據(jù)，或者通過內(nèi)建的統(tǒng)計函數(shù)去分析這些數(shù)據(jù)。這種應(yīng)用往往不太關(guān)注單點的數(shù)據(jù)或者幾個數(shù)據(jù)之間的關(guān)系。

因為有一部分數(shù)據(jù)量并不是很大的時序數(shù)據(jù)庫應(yīng)用可以采用關(guān)系型數(shù)據(jù)庫、HBASE、REDIS這樣的KV數(shù)據(jù)庫來存儲，因此在日常應(yīng)用中純時序數(shù)據(jù)庫使用的相對較少。因此時序數(shù)據(jù)庫這些年發(fā)展的不溫不火。從DB-ENGINES上看，純粹的時序數(shù)據(jù)庫的流行度得分并不高。

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

在這里我們看到了一些大佬的身影，特別是現(xiàn)在大火的MongDB，作為文檔數(shù)據(jù)庫，MongoDB實際上是一種多模數(shù)據(jù)庫，也支持時序數(shù)據(jù)。在國內(nèi)MongoDB僅僅被作為文檔數(shù)據(jù)庫使用，僅僅存儲一些目錄與日志信息，不過MongoDB是一個十分全能的數(shù)據(jù)庫產(chǎn)品，支持強一致性交易，甚至在時序數(shù)據(jù)庫模式上也十分強大。西門子、博世等世界五百強企業(yè)用MongoDB來處理時序數(shù)據(jù)。在目前XC替代方面，實際上MongoDB是十分難以替代的，特別是你真正用了MongDB的事務(wù)、時序特性等，沒有第二個數(shù)據(jù)庫產(chǎn)品擁有MongoDB如此強大的功能。而MongoDB從商業(yè)利益上考慮將開源協(xié)議轉(zhuǎn)為SSPL后，開始收割云服務(wù)廠商，而這種接近于商用協(xié)議的開源協(xié)議極容易受到美國政府出口管制措施的影響，因此對于有XC要求的企業(yè)來說，還是要十分小心的。

令人意外的事Redis這種我們經(jīng)常用來做緩沖的，十分簡單的內(nèi)存KV數(shù)據(jù)庫，也是多模的，也支持時序數(shù)據(jù)。Redis支持SortedSets數(shù)據(jù)結(jié)構(gòu)，支持按權(quán)重存儲數(shù)據(jù)并支持按照權(quán)重的范圍查詢。如果把時間戳作為權(quán)重值，key存儲具體的度量維度，那么Redis就可以支持時序數(shù)據(jù)了。不過這種模式過于簡單粗暴，十分消耗內(nèi)存，而且并發(fā)寫入性能也不好，只適合最為簡單的模式。從Redis 5.0開始，Redis開始支持消息隊列Stream，流式數(shù)據(jù)也是時序數(shù)據(jù)處理中的一種常見場景。而真正讓Redis具有真正的流式數(shù)據(jù)庫能力的是Redis TimeSeries擴展模塊的引入。這是

在這個列表里我們還看到了最近比較火的ClickHose。Clickhouse是俄羅斯yandex公司于2016年開源的一個列式數(shù)據(jù)庫管理系統(tǒng)，近些年像一匹黑馬一樣迅速在具有時序處理需求的OLAP場景中收割用戶。其向量化引擎SIMD讓一些大數(shù)據(jù)量的簡單分析查詢性能得到了極大的釋放。只不過ClickHose簡單粗暴的向量引擎限制了應(yīng)用的并發(fā)，不過在OLAP場景中，高并發(fā)并不總是剛需。

大多數(shù)時序數(shù)據(jù)庫的應(yīng)用場景可以將時序數(shù)據(jù)庫獨立開來存儲與訪問，而應(yīng)用中的較為復(fù)雜的業(yè)務(wù)數(shù)據(jù)可以放在關(guān)系型數(shù)據(jù)庫里。而時序數(shù)據(jù)的讀寫場景相對簡單，因此時序數(shù)據(jù)庫在數(shù)據(jù)庫領(lǐng)域的熱度較低。

有些關(guān)系型數(shù)據(jù)庫用戶開始的時候都把時序數(shù)據(jù)存儲在關(guān)系型數(shù)據(jù)庫里，不過因為時序數(shù)據(jù)的數(shù)據(jù)量太大了。會導(dǎo)致關(guān)系型數(shù)據(jù)庫的容量變得超大，我以前做過一個優(yōu)化項目，業(yè)務(wù)數(shù)據(jù)庫的庫容高達上百TB，而實際上里面的關(guān)系型的業(yè)務(wù)數(shù)據(jù)只有幾百GB，大多數(shù)都是寫入后只讀的時序數(shù)據(jù)。后來我建議他們吧時序數(shù)據(jù)獨立出去了，這樣數(shù)據(jù)庫備份，運維就簡單多了。

而把超大規(guī)模的時序數(shù)據(jù)寫入關(guān)系型數(shù)據(jù)庫，很可能就會到達關(guān)系型數(shù)據(jù)庫的天花板，讓數(shù)據(jù)庫的性能無法跟上。如果把這類數(shù)據(jù)存儲到純粹的時序數(shù)據(jù)庫里，那么就很容易利用其分布式特性很好的橫向擴展了。時序數(shù)據(jù)庫存儲這些數(shù)據(jù)的時候，會占用更小的空間，也很容易實現(xiàn)自動的數(shù)據(jù)壓縮。另外利用專用的API訪問時間，對數(shù)據(jù)做復(fù)雜的匯總統(tǒng)計，也比SQL接口要快捷的多。因此很多企業(yè)都陸續(xù)將時序數(shù)據(jù)從傳統(tǒng)的關(guān)系型數(shù)據(jù)庫中分離出來，存儲到專業(yè)的時序數(shù)據(jù)庫中。

不過還有另外一種思路，那就是在關(guān)系型數(shù)據(jù)庫中增加時序數(shù)據(jù)庫的能力。最為典型的就是TimeScaleDB。當時序數(shù)據(jù)的量還不算太大的時候，有些用戶選擇了將時序數(shù)據(jù)存儲到關(guān)系型數(shù)據(jù)庫中。在PostgreSQL數(shù)據(jù)庫中安裝TimeScaleDB插件，創(chuàng)建時序表來存儲時序數(shù)據(jù)。同事利用PG的SQL引擎來訪問和處理這些時序數(shù)據(jù)。利用TimeScaleDB的歷史數(shù)據(jù)自動壓縮功能壓縮歷史數(shù)據(jù)，可以大大減少海量歷史數(shù)據(jù)的存儲量。我們的D-SMART中需要采集大量的數(shù)據(jù)庫的監(jiān)控數(shù)據(jù)，大概每2分鐘采集一次，每次有上千個實例，每個實例有數(shù)百條記錄。這樣的話，一個納管了2000個數(shù)據(jù)庫的D-SMART，每隔兩分鐘，就會有100萬條數(shù)據(jù)被寫入TimeScaleDB，并且這些數(shù)據(jù)還需要按照時間區(qū)間，通過SQL查詢出來，進行分析處理。從這些年的使用來看，TimeScaleDB是可以輕松應(yīng)對這樣的場景的，每個SQL查詢也都是幾十毫秒就可以完成。我們最初是使用PG的普通表存儲這些監(jiān)控數(shù)據(jù)的，換成TimeScaleDB后，寫入性能與查詢性能都有了多倍的提升。最令我們喜歡的是歷史數(shù)據(jù)的自動壓縮功能，作為運維自動化系統(tǒng)，7天前的監(jiān)控數(shù)據(jù)被訪問的比例很低，因此我們設(shè)置了7天數(shù)據(jù)自動壓縮，大大節(jié)約了存儲資源。

使用TimeScaleDB最大的好處是保留了我們團隊在SQL上的所有研發(fā)經(jīng)驗，只要不亂寫SQL，大部分SQL不需要特殊的優(yōu)化改寫，就可以達到性能要求。實現(xiàn)這種開發(fā)自由來自于TimeScaleDB優(yōu)秀的設(shè)計，因為時間問題，我們在這里就展開討論了。如果是千萬到數(shù)億級別的時序數(shù)據(jù)處理，使用TimeScaleDB是沒有任何壓力的。

國產(chǎn)的時序數(shù)據(jù)庫產(chǎn)品也很多，在墨天輪上目前有32種國產(chǎn)時序數(shù)據(jù)庫，已經(jīng)和DB-ENGINES上35種純時序數(shù)據(jù)庫的列表差不多長了。其中排名靠前的濤思數(shù)據(jù)的TDengine和智叟科技的DolphinDB。在DB-ENGINES的時序數(shù)據(jù)庫排行中，這兩種時序數(shù)據(jù)庫也比較靠前。也有一些國產(chǎn)時序數(shù)據(jù)庫基于openTSDB，或者與之兼容。

時序數(shù)據(jù)庫與時序應(yīng)用的發(fā)展呈現(xiàn)出三種模式，大家也都在爭論哪種模式更好。

第一種模式是放棄關(guān)系型數(shù)據(jù)庫，轉(zhuǎn)向時序數(shù)據(jù)庫或者用帶有時序數(shù)據(jù)庫模式的多模數(shù)據(jù)庫替代關(guān)系型數(shù)據(jù)庫。利用原生分布式架構(gòu)，帶有向量處理能力的數(shù)據(jù)庫引擎來支撐特別大數(shù)據(jù)量寫入，大數(shù)據(jù)量輸出需求的場景。這些人認為NOSQL才是時序數(shù)據(jù)處理的最終解決方案。

第二種模式正好相反，他們從NOSQL的時序數(shù)據(jù)庫轉(zhuǎn)向了具有時序數(shù)據(jù)處理能力的關(guān)系型數(shù)據(jù)庫，充分利用SQL的能力來解決應(yīng)用的問題。最典型的就是我今天介紹的D-SMART里使用的TimeScaleDB。對于更大數(shù)據(jù)量的需求，可以使用CrateDB、TDengine這樣的分布式數(shù)據(jù)庫。

第三種模式是使用HBASE這樣的KV數(shù)據(jù)庫來存儲時序數(shù)據(jù)，而不專門使用時序數(shù)據(jù)庫。對于僅僅把海量時序數(shù)據(jù)找個地方存起來，滿足大并發(fā)寫入，大吞吐量輸出的場景要求就行了，大量的數(shù)據(jù)處理都是應(yīng)用程序自己來干，那么這樣的用法也沒啥問題。

實際上也無需爭論，因為不同的應(yīng)用場景就會選擇不同的模式。到底你選擇什么樣的時序數(shù)據(jù)庫方案，往往取決于下面幾個因素：1）你的時序數(shù)據(jù)的量級是什么樣的，每秒幾萬，幾十萬，還是幾百萬，幾千萬；2）你的時序數(shù)據(jù)如何被使用，每次讀取的批次是多少;3）你需要數(shù)據(jù)庫的內(nèi)置功能來處理和分析時序數(shù)據(jù)，還是有自己的數(shù)據(jù)分析應(yīng)用模塊；4）你如何處理過期的數(shù)據(jù)；5）你的歷史數(shù)據(jù)的訪問模式；6）你的查詢并發(fā)QPS是多少；……。

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