在物联网实际部署中，消息中间件（kafka，emq等）和时序数据库通常是上下游的关系。消息中间件有非常高的并发能力，能够同时接受百万级的网络连接。一个数据库创建一个会话（客户端连接）的成本比较高。
一、有了Kafka+流处理框架，为什么还需要时序数据库
在物联网实际部署中，消息中间件（kafka，emq等）和时序数据库通常是上下游的关系。
消息中间件有非常高的并发能力，能够同时接受百万级的网络连接。一个数据库（包括关系数据库和时序数据库）创建一个会话（客户端连接）的成本比较高，能接受的连接数量也就在几百和几千这样的级别（分布式数据库可以按节点数增加，但数量远远小于消息中间件）。当面对大量的物联网传感器，消息中间件架设在中间，接受传感器的数据，然后再批量写入到时序数据库中。时序数据库的写入吞吐量远远高于关系数据库，每秒写入百万级和千万级的数据点都不是问题。以分布式时序数据库DolphinDB为例，6个服务器构成的集群，每秒能达到千万测点的三副本写入。可以这么说，消息中间件的高并发能力和时序数据库的高吞吐量联合起来，解决了物联网海量数据的实时处理和存储问题。
至于时序数据库的用途，参考其它回答，包括：提供永久的数据存储和管理能力，数据查询和分析等。
抽象来看，消息队列与时序数据库没有本质的区别，都是对时间序列数据的处理。但功能上，时序数据库要有查询、计算，而消息队列只是简单的生产、消费，先进先出。由于要有计算、分析，无论是结构化写入还是schemaless写入，时序数据库内部一定要把数据结构化处理，否则没法进行计算和分析的。而消息队列完全不用考虑这个，完全做非结构化数据处理就行。从存储设计的角度来看，两者是没有区别的，都需要有数据的保留策略，都需要对数据进行分区分片。一个时间线的ID可以作为kafka来的key, 对数据指定partition.
两者正在融合，开源的TDengine就是这样的，它不仅是时序数据库，但同时又具备消息队列的功能。这样在大数据框架下，就能减少一个环节，降低系统复杂度，降低运维成本。Kafka的企业版也在做类似的事情，除消息队列功能外，对外还提供SQL查询，提供各种分析计算功能。
更进一步，流式计算也可以融合进来。流式计算也是基于时序数据的，因此TDengine从设计的名列前茅天起，就考虑了流式计算，但目前还仅仅提供时间驱动的流式计算，后续版本会提供基于事件驱动的流式计算。这样对于物联网、车联网、IT运维等场景，系统架构将更进一步简化，运维成本进一步降低。
延伸阅读：
二、时间序列数据库TSDB
TSDB（Time Series Database）：一系列数据点按照时间顺序排列；时间序列数据就是历史烙印，具有不变性、时间排序性。
（基于时间的一系列数据，在有时间的坐标中将这些数据点连成线，往过去看可以做成多维度报表，揭示其趋势性、规律性、异常性；往未来看可以做大数据分析、机器学校、实现预测和预警。
时序数据库就是存放时序数据的数据库，并且需要支持时序数据的快速写入、持久化、多维度的聚合查询等基本功能）。
