来源：大数据技术标准推进委员会正文约4800字，建议阅读9分钟正文，介绍了时序数据库和实时数据库的产生背景、具体区别和一些小趋势。 进入正题之前，先说个故事吧
在2018年接触工业互联网之前，我完全不知道时间序列数据库(以下简称TSDB )，但为了标准化，我开始慢慢接触国内制作TSDB的制造商。 其中既有干劲十足的创业公司，也有经验丰富的老字号信息化厂商，实力雄厚的BATH天团也在TSDB布局，忽而各种TSDB产品如雨后春笋般涌现。
它是什么时候开始火的？
其实从2016年开始就有这种倾向。 引用一下DB-Engines上刊登的图吧。 2016年12个月，TSDB的人气上升了26%，是第二名图表数据库的两倍多。
DB-Engines :
3359 d B- engines.com/en/blog _ post/62
2016年度各种数据库人气上升
选择其中排名第一的InfluxDB用Google Trends调查一下热度吧。 该数据库是2013年7月左右发布的第一个版本，自那以来人气高涨。
2013-2019年InfluxDB数据库搜索热度变化
所以，我们希望加快学习步伐，尽快理顺标准，让企业伙伴在进行技术选型时有一点参考价值。
“这个数据库我们十几年前就开始做了，但是叫另一个名字——实时数据库”。
很多开始工业信息化的兄弟和我们都提到了“实时数据库”的概念，表示“我们的功能其实是一样的”。 这让我有点困惑。 我想理解这两个数据库的关系，可以算一类吗？ 但是，在当时网络上关于这两种数据库的比较，只找到了CSDN的《工业大数据漫谈12：实时数据库与时序数据库》 (https://blog.csdn.net/guanhui 1997/article/details/72840769 ) 话说得很清楚，如果你也有同样的困惑的话可以进去看看
因此，本文是一些学习心得，尽量包括这两个数据库的产生背景、具体差异和一些小趋势。
先引申一下概念吧~
时间序列数据time series data
基于稳定频率或非固定周期频率持续发生的一系列时间维度的指标监视数据。 由时间戳、标签、指标三要素构成。
时间序列数据库time series数据库
用于存储大量时间序列数据的数据库。
我们可能是异父异母的亲兄妹？
实时数据库产生于传统工业，早在几十年前就开始发展，技术已经成熟，主要是实时反馈制，以支持工业场景中大量测量数据的快速写入、存储和查询
而时序数据库产生于互联网，兴起于物联网，主要是为了支持海量网络监测和传感器数据快速写入和分析的需要。
让我们看看为什么要在工业场景中特别设计实时数据库。 工业场景80%以上的数据都有这样的特征。 以都带有时间戳，且是按时间顺序生成的；大多为结构化数据；采集频率高，数据量大。中型工业企业为例，作为过程监控的一部分，可能涉及5-10万个传感器测量点，每天生产数百GB的数据。 工业企业通常要求数据很长。这种简单的需求表明了传统实时数据库所需的功能，可以归纳为以下几点
高速写入的能力：工业实时数据库通常要求写入速度。 以流程工业场景为例，由于各个环节都设有传感器，且各个传感器的采集频率较高，写入并发量特别大，有时每秒需要几百万个测量点。 因此，除了对软件的要求外，还选择了高性能的服务。
快速查询的能力：查询需求分为两块，一块是为了响应实时查询请求，及时反映系统状态； 二是确保历史数据也能快速查阅。 由于历史数据量非常大，所以在调查时需要汇总特定时间段的数据。 即使调查了一年的数据状况，也需要确保能马上做出反应。
超强数据压缩能力：上述监视数据将长期保存。 5年到10年是常有的事。 如果存储容量有限，则需要对数据进行一定的压缩。 通常，压缩方式分为有损压缩和有损压缩。 有损压缩的压缩比可能高达1:30-40。
积累丰富的工具：传统的实时数据库解决方案一般是从开始收集到直接可视化的一系列系统
，有多年积累形成的丰富的工具包，比如会积攒上百种的协议，或者各种场景的数据模型，这些都是工业软件的重要竞争力。追求极致稳定：工业上对软件的稳定性要求特别高，除了用主备来保证高可用外，完全由软件的质量来保证程序的持续运行，工程师会自豪地拍胸脯保证软件跑十年也不会出错。
我们再来看一下时序数据库的诞生环境，在进入互联网飞速发展的时期之后，随着通信技术的革新，数据通信成本的下降，掀起了一波又一波万物互联的热潮。不仅是互联网监控需要采集数据，人们每天接触的手机、智能手环、共享自行车、汽车，都在源源不断地产生数据。人们实时地收集这些数据并发送到云端，用大数据技术进行分析，对业务进行监控和预测，以数据驱动企业降本增效，提高服务质量。
仔细观察一下互联网场景中的数据特征，其实和工业领域大部分的实时数据类似：
1. 单条数据不会很长，但是数据量很大
2. 它们都带有时间戳，且按顺序生成
3. 数据大部分都是结构化的，用于描述某个参数在某个时间点的特征
4. 写入的频率会比查询的频率高很多
5. 已存储的数据很少有更新的需求
6. 用户会更关心一段时间的数据特征，而不是某一个时间点
7. 数据的查询分析大多基于某一个时间段或者某个数值范围
8. 需要进行统计和可视化的展示
从上面这些数据特征，可以很明显的看出来，虽然两种数据库产生的环境不同，但是面对的问题是相同的，解决的需求是类似的，所以两种数据库设计出的功能有很多重合的部分。
功能要求可参考CCSA大数据技术标准推进委员会（TC601）关于时序数据库的评估体系（http://databench.cn/evaluate?standard_id=5c07aec44b079）
这就好像两个从未谋过面的兄妹，确认过眼神就知道是一家人。
你想替代我吗？没那么容易随着IoT和工业互联网带来的新一波风口，一系列新的生产方式、组织方式和商业模式开始涌现。物联网技术逐步渗透工业，不断增长的传感器、飙升的数据量，以及更高的大数据分析需求对实时数据库传统的技术架构提出了挑战。有些问题是需要直面的：
扩展性遇到瓶颈。传统的技术架构虽然能保证单机具备极高的性能，也可以通过增加机器使性能线性扩展，但是不能像分布式系统那样实现动态灵活的扩容和缩容，需要提前进行规划。当业务升级需要系统扩容时，老架构的扩展性就很难满足需求了。
无法和大数据生态对接。数据采集的最终目的是被理解和使用，大数据产业中对于海量数据的存储分析已经有很成熟的方案，不论是hadoop还是spark的生态圈，都面临着新老技术的对接。很多工业企业因为想使用新的大数据分析技术，不得不对现有的系统进行升级或是替换。
价格高昂。传统的工业实时数据库解决方案价格都十分昂贵，一般只有大型企业能忍痛接受。但是随着新技术新理念的普及，更多的中小企业也意识到数据的重要性，但考虑到资金投入，会倾向于寻找价格更低廉的方案。
这时候来自互联网大家庭的时序数据库方案就展现出了一些先天优势，比如：
分布式架构的天然优势：传统的实时数据库多是主备的部署架构，通常要求有较高配置的机器，来追求单机极致的性能；同时，在稳定性方面，会对运行软件的稳定性做极高的要求，完全由高质量的代码来保证运行的稳定；由于存储容量有限，也会要求超高的数据压缩比。但是时序数据库的分布式架构，使得系统能够轻松的进行水平扩展，让数据库不再依赖昂贵的硬件和存储设备，以集群天然的优势来实现高可用，不会出现单点的瓶颈或故障，在普通的x86服务器甚至是虚拟机上都可以运行，大大降低了使用成本。
更灵活的数据模型：传统的实时数据库由于工业场景的特殊性，常使用的是单值模型，一个被监控的参数称为一个测点，在写入时会对每一个测点建一个模型，比如一个风机的温度指标算一个测点，十个风机的十个指标就是100个测点，每个测点会附带描述信息（名称、精度、数据类型、开关量/模拟量等）查询的时候就会针对每个测点去查询数值。单值模型的写入效率会很高。
单值模型示例
而时序数据库，开始采用多值模型，类似面向对象的处理方式，例如风机是一种数据模型，可以包括温度、压力等多个测量维度，还包括经纬度、编号等tag信息，这样对外提供服务时会更适合分析的场景。当然单值模型和多值模型是可以互相转换的。很多数据库对外提供的服务为多值模型，但是底层存储还是单值模型。
多值模型示例
现在大部分的时序数据库都选择了扩展性较好的NoSQL数据库，相比于关系型数据库，数据模型更灵活，非常适合时序数据的多值模型；更易扩展，在资源受限或者需要提升性能的时候，可以轻易的增加机器；查询效率高；开源软件成本低；可以与大数据生态无缝对接。看下使用NoSQL数据库作为底层存储的TSDB：
开源TSDB的底层存储模型
但是使用NoSQL数据库也会丢失一些特性，比如不支持事务，需要通过其他手段来保证数据一致性；比如不支持SQL，SQL作为一种标准查询语句，已经被人们所习惯，是一种学习成本极低的操作，所以现在做时序数据库的厂家也在尝试去集成SQL引擎，降低使用的门槛。
时序数据库被描述得这么优秀，那它会接班传统的实时数据库吗？不是这么容易的事。
首先，工业中的实时数据库经受过多年客户需求的打磨，性能上绝对一流，甚至可以进行一定的反馈控制。产品的配套也非常齐全，通常自带采集工具、适配各种接口协议、具备计算能力及定制化的可视化能力（实时数据库在这一块的设计投入了很大精力，以使图表能展示出监控数据的一些特征和细节），是一套完整的解决方案。而时序数据库的设计在这些领域知识的积累方面是很欠缺的，而且大多数只用于监控分析的场景；部署依赖过多，配套工具不完善也是一方面的问题；性能和可靠性离实时的反馈控制也还有一定距离。
再者，近几年做实时数据库的厂家也在积极行动中，陆续都为产品增加了分布式版本甚至是云服务版本，通常会以实时数据库为核心反向建立起一套数据管理和分析的生态体系，势头一点都不输互联网玩家。
跑道上枪声响起，这场比赛没有人弃权。
那我们共同进步吧不管技术架构如何变化，解决用户的需求才是最终目的，以需求为导向的设计，永远不会过时。那接下来我们来看看还出现了哪些新需求：
对查询的要求逐渐超过了写入要求：在互联网时代，查询的要求已经不仅仅是满足于一些基础的条件查询或是插值查询，随着物联网场景的丰富以及人们对信息全面掌控的需求，基于地图的应用越来越多，查询会由时间的维度逐步扩展到空间的维度，除了保证实时性之外，更丰富的可视化的展现也是一大趋势。
逐步转向云服务：传统的工业场景处理实时数据出于安全和性能等原因都会使用私有化部署。机器、软件以及后续的服务是一笔十分高昂的开销，还需要配备专业的技术人员进行系统的维护。当服务逐步上云后，一方面省去了购置机器的成本，也不需要特别安排维护机器和软件系统的工程师，只需要懂得如何开发和维护业务就可以。另外服务使用多少就购买多少，避免一次性购买服务造成的资源浪费或者资源不足再进行二次建设，可以为企业减少很大一笔开销。随着网络和云计算技术的成熟，相关的性能和安全性也会不断的升级，最终趋近于私有化部署的效果，服务上云已经成为了一个不可阻挡的趋势。
计算分摊到边缘：工业领域其实是IoT的重要实验田，工业互联网的发展势必会带来更多传感器的使用以及更多数据的采集，当数据过于庞大，集中化的处理方式就很难响应实时的数据分析需求，这就带来了数据计算向边缘的发展，需要实时响应的监控就通过边缘设备及时的处理并反馈，需要用于大规模分析的数据再进行集中存储，这种分级的处理方式能够有效的提升时效性数据的价值，同时减轻存储系统的负担，所以许多时序数据库正在研发边缘计算版本，并会配合流计算的能力使功能更加丰富。融合了边缘计算的时序数据解决方案会更适合工业互联网的处理场景。
总结一下上文，其实在技术发展的过程中，两种数据库都在为发展变化的业务需求不断打磨自己的功能，各取所长、互为补充、甚至做出一些妥协，这是保持长久活力的必经之路——停滞造成焦虑，变化带来生机。
在新的风口谁都想抢得先机。
而踏实做事的人能走到最后。
本文由坚定的方盒首发于简书
https://www.jianshu.com/p/abe1ec1855ad
声明：本文仅代表作者个人观点，不代表作者所在机构和大数据技术标准推进委员会的观点
编辑：xxdzjy
校对：知性的康乃馨