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

在物聯網實際部署中，消息中間件（kafka，emq等）和時序數據庫通常是上下游的關系。

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

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

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

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

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

延伸閱讀：

二、時間序列數據庫TSDB

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

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

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