一、有了Kafka+流處理框架，為什么還需要時序數(shù)據(jù)庫

在物聯(lián)網(wǎng)實際部署中，消息中間件（kafka，emq等）和時序數(shù)據(jù)庫通常是上下游的關系。

消息中間件有非常高的并發(fā)能力，能夠同時接受百萬級的網(wǎng)絡連接。一個數(shù)據(jù)庫（包括關系數(shù)據(jù)庫和時序數(shù)據(jù)庫）創(chuàng)建一個會話（客戶端連接）的成本比較高，能接受的連接數(shù)量也就在幾百和幾千這樣的級別（分布式數(shù)據(jù)庫可以按節(jié)點數(shù)增加，但數(shù)量遠遠小于消息中間件）。當面對大量的物聯(lián)網(wǎng)傳感器，消息中間件架設在中間，接受傳感器的數(shù)據(jù)，然后再批量寫入到時序數(shù)據(jù)庫中。時序數(shù)據(jù)庫的寫入吞吐量遠遠高于關系數(shù)據(jù)庫，每秒寫入百萬級和千萬級的數(shù)據(jù)點都不是問題。以分布式時序數(shù)據(jù)庫DolphinDB為例，6個服務器構(gòu)成的集群，每秒能達到千萬測點的三副本寫入。可以這么說，消息中間件的高并發(fā)能力和時序數(shù)據(jù)庫的高吞吐量聯(lián)合起來，解決了物聯(lián)網(wǎng)海量數(shù)據(jù)的實時處理和存儲問題。

至于時序數(shù)據(jù)庫的用途，參考其它回答，包括：提供永久的數(shù)據(jù)存儲和管理能力，數(shù)據(jù)查詢和分析等。

抽象來看，消息隊列與時序數(shù)據(jù)庫沒有本質(zhì)的區(qū)別，都是對時間序列數(shù)據(jù)的處理。但功能上，時序數(shù)據(jù)庫要有查詢、計算，而消息隊列只是簡單的生產(chǎn)、消費，先進先出。由于要有計算、分析，無論是結(jié)構(gòu)化寫入還是schemaless寫入，時序數(shù)據(jù)庫內(nèi)部一定要把數(shù)據(jù)結(jié)構(gòu)化處理，否則沒法進行計算和分析的。而消息隊列完全不用考慮這個，完全做非結(jié)構(gòu)化數(shù)據(jù)處理就行。從存儲設計的角度來看，兩者是沒有區(qū)別的，都需要有數(shù)據(jù)的保留策略，都需要對數(shù)據(jù)進行分區(qū)分片。一個時間線的ID可以作為kafka來的key, 對數(shù)據(jù)指定partition.

兩者正在融合，開源的TDengine就是這樣的，它不僅是時序數(shù)據(jù)庫，但同時又具備消息隊列的功能。這樣在大數(shù)據(jù)框架下，就能減少一個環(huán)節(jié)，降低系統(tǒng)復雜度，降低運維成本。Kafka的企業(yè)版也在做類似的事情，除消息隊列功能外，對外還提供SQL查詢，提供各種分析計算功能。

更進一步，流式計算也可以融合進來。流式計算也是基于時序數(shù)據(jù)的，因此TDengine從設計的名列前茅天起，就考慮了流式計算，但目前還僅僅提供時間驅(qū)動的流式計算，后續(xù)版本會提供基于事件驅(qū)動的流式計算。這樣對于物聯(lián)網(wǎng)、車聯(lián)網(wǎng)、IT運維等場景，系統(tǒng)架構(gòu)將更進一步簡化，運維成本進一步降低。

延伸閱讀：

二、時間序列數(shù)據(jù)庫TSDB

TSDB（Time Series Database）：一系列數(shù)據(jù)點按照時間順序排列；時間序列數(shù)據(jù)就是歷史烙印，具有不變性、時間排序性。

（基于時間的一系列數(shù)據(jù)，在有時間的坐標中將這些數(shù)據(jù)點連成線，往過去看可以做成多維度報表，揭示其趨勢性、規(guī)律性、異常性；往未來看可以做大數(shù)據(jù)分析、機器學校、實現(xiàn)預測和預警。

時序數(shù)據(jù)庫就是存放時序數(shù)據(jù)的數(shù)據(jù)庫，并且需要支持時序數(shù)據(jù)的快速寫入、持久化、多維度的聚合查詢等基本功能）。