实时数据库：一夜之间，我感受到了时序数据库的威胁

进入正题之前，咱们先讲个故事

在2018年接触到工业互联网之前，我完全没了解过时序数据库(下面简称为TSDB)，因为做标准的原因开始慢慢接触起国内一些做TSDB的厂家，其中不乏充满干劲的创业公司和经验丰厚的老牌信息化厂商，实力雄厚的BATH天团在TSDB上也都有布局，突然间各种TSDB产品就像雨后春笋一般涌现了。

它是什么时候开始火的?

其实从2016年开始就有了这个趋势，引用一下DB-Engines上发布的一张图，在2016年12个月里，TSDB的人气上涨了26%，是排名第二的图数据库的两倍还多。

DB-Engines：https://db-engines.com/en/blog_post/62

2016年度各类数据库人气涨势

再挑其中排名第一的InfluxDB在Google Trends里查一下热度，这个数据库是2013年7月左右发布的第一个版本，自此以后人气涨势是一发不可收拾。

2013-2019年InfluxDB的搜索热度变化

所以我们加紧了学习步伐，希望能尽快的把标准梳理出来，好让企业伙伴在做技术选型的时候能有些参考。

“这个数据库我们十几年前就开始做了，但是叫另一个名字——实时数据库”。

很多做工业信息化起家的兄弟和我们提到了“实时数据库”这个概念，并表示“我们功能其实是一样的”。这让我有些困惑，很是想搞明白这两个数据库之间的关系，能算成一类吗?但当时网上对于这两种数据库的对比，大概只能找到CSDN的一篇《工业大数据漫谈12：实时数据库与时序数据库》(https://blog.csdn.net/guanhui1997/article/details/72840769)，讲的很清晰，如果你也有同样的困惑可以点进去看一看~但也可以看我接下去要写的，因为我们拉着做实时/时序数据库的伙伴们针对这个问题讨论了好几回。

所以这一篇文章是一些学习心得，会尽量包括：这两个数据库的产生背景、具体区别和一些小趋势。

先来点概念做铺垫~

时序数据 time series data

基于稳定频率或非固定周期频率持续产生的一系列基于时间维度的指标监测数据。由时间戳、标签和指标三要素组成。

时序数据库 time series database

用于保存海量时序数据的数据库。

我们可能是异父异母的亲兄妹?

实时数据库诞生于传统工业，早在几十年前就已经开始发展，技术已经很成熟，主要为了支持工业场景中大量测量数据的快速写入、存储和查询，有时会涉及到实时的反馈控制。

而时序数据库诞生于互联网，兴起于物联网，主要为了支持海量网络监控及传感器数据的快速写入和分析需求。

我们来看下为什么工业场景中要专门设计实时数据库，工业场景中超过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的重要实验田，工业互联网的发展势必会带来更多传感器的使用以及更多数据的采集，当数据过于庞大，集中化的处理方式就很难响应实时的数据分析需求，这就带来了数据计算向边缘的发展，需要实时响应的监控就通过边缘设备及时的处理并反馈，需要用于大规模分析的数据再进行集中存储，这种分级的处理方式能够有效的提升时效性数据的价值，同时减轻存储系统的负担，所以许多时序数据库正在研发边缘计算版本，并会配合流计算的能力使功能更加丰富。融合了边缘计算的时序数据解决方案会更适合工业互联网的处理场景。

总结一下上文，其实在技术发展的过程中，两种数据库都在为发展变化的业务需求不断打磨自己的功能，各取所长、互为补充、甚至做出一些妥协，这是保持长久活力的必经之路——停滞造成焦虑，变化带来生机。

在新的风口谁都想抢得先机。

而踏实做事的人能走到最后。

王妙琼，中国信息通信研究院云大所工程师，CCSA TC601 大数据行业应用工作组组长。主要研究方向为大数据基础平台架构、工业大数据应用等。牵头流计算、时序数据库等多项行业标准及研究报告的编写工作。