实时数据库：一夜之间，我感受到了时序数据库的威胁
作者介绍
王妙琼，中国信息通信研究院云大所工程师，CCSA TC601 大数据行业应用工作组组长。主要研究方向为大数据基础平台架构、工业大数据应用等。牵头流计算、时序数据库等多项行业标准及研究报告的编写工作。
在2018年接触到工业互联网之前，我完全没了解过时序数据库（下面就简称TSDB了），因为做标准的原因开始慢慢接触起国内一些做TSDB的厂家，其中不乏充满干劲的创业公司和经验丰厚的老牌信息化厂商，实力雄厚的BATH天团在TSDB上也都有布局，突然间各种TSDB产品就像雨后春笋一般涌现了。
它是什么时候开始火的？
其实从2016年开始就有了这个趋势，引用一下DB-Engines上发布的一张图，在2016年12个月里，TSDB的人气上涨了26%，是排名第二的图数据库的两倍还多。
再挑其中排名第一的InfluxDB在Google Trends里查一下热度，这个数据库是2013年7月左右发布的第一个版本，自此以后人气涨势是一发不可收拾。
所以我们加紧了学习步伐，希望能尽快的把标准梳理出来，好让企业伙伴在做技术选型的时候能有些参考。
“这个数据库我们十几年前就开始做了，但是叫另一个名字——实时数据库”。
很多做工业信息化起家的兄弟和我们提到了“实时数据库”这个概念，并表示“我们功能其实是一样的”。
这让我有些困惑，很是想搞明白这两个数据库之间的关系，能算成一类吗？
但当时网上对于这两种数据库的对比，大概只能找到CSDN的一篇《工业大数据漫谈12：实时数据库与时序数据库》，讲的很清晰，如果你也有同样的困惑可以点进去看一看~
参考链接：
https://blog.csdn.net/guanhui1997/article/details/72840769
但也可以看我接下去要写的，因为我们拉着做实时/时序数据库的伙伴们针对这个问题讨论了好几回。所以这一篇文章是一些学习心得，会尽量包括：这两个数据库的产生背景、具体区别和一些小趋势。
先来点概念做铺垫~
时序数据 time series data
基于稳定频率或非固定周期频率持续产生的一系列基于时间维度的指标监测数据。由时间戳、标签和指标三要素组成。
时序数据库 time series database
用于保存海量时序数据的数据库。
异父异母的亲兄妹？
实时数据库诞生于传统工业，早在几十年前就已经开始发展，技术已经很成熟，主要为了支持工业场景中大量测量数据的快速写入、存储和查询，有时会涉及到实时的反馈控制。
而时序数据库诞生于互联网，兴起于物联网，主要为了支持海量网络监控及传感器数据的快速写入和分析需求。
1、实时数据库
我们来看下为什么工业场景中要专门设计实时数据库。
工业场景中超过80%的数据都有这样的一些特征：都带有时间戳，且是按时间顺序生成的；大多为结构化数据；采集频率高，数据量大。
以一个中等规模的工业企业为例，在流程监控的环节中，可能会涉及到5-10万个传感器测点，每天产出的数据量能达到上百GB，通常情况下，工业企业都会要求数据能够长时间被存储，这样可以随时查询到历史趋势。
这个简单的需求已经显示出了传统的实时数据库需要具备的一些能力，可以总结为以下几点：
高速写入的能力：工业实时数据库通常会对写入的速度有很高的要求。以流程工业的场景为例，每个环节都会设置传感器，每个传感器的采集频率都很高，所以写入的并发量会特别大，有时甚至会要求每秒上百万的测点。所以除了对软件的要求之外，也会选用一些高性能的服务器。
快速查询的能力：查询的需求分为两块，一是要响应实时的查询请求，用于及时反映系统的状态；二是历史数据也要能快速被查询，由于历史数据的量非常大，在查询时需要对特定时间段的数据做聚合，需要做到即使是查一整年的数据情况，也能很快的反应出来。
超强数据压缩能力：上面提到监控数据会被存储很长时间，5年甚至是10年都是常有的事，在存储容量有限的情况下，就需要对数据做一定的压缩，通常压缩方式会分成无损压缩和有损压缩，相比而言，有损压缩的压缩比会更大一些，有时甚至会达到1:30-40，这就需要设计合理的算法来保留数据中的细节，使数据在还原后仍能保留重要的特征。
积累丰富的工具：传统的实时数据库的解决方案一般是从采集开始到直可视化的一整套系统，有多年积累形成的丰富的工具包，比如会积攒上百种的协议，或者各种场景的数据模型，这些都是工业软件的重要竞争力。
追求极致稳定：工业上对软件的稳定性要求特别高，除了用主备来保证高可用外，完全由软件的质量来保证程序的持续运行，工程师会自豪地拍胸脯保证软件跑十年也不会出错。
2、时序数据库
我们再来看一下时序数据库的诞生环境。
在进入互联网飞速发展的时期之后，随着通信技术的革新，数据通信成本的下降，掀起了一波又一波万物互联的热潮。
不仅是互联网监控需要采集数据，人们每天接触的手机、智能手环、共享自行车、汽车，都在源源不断地产生数据。
人们实时地收集这些数据并发送到云端，用大数据技术进行分析，对业务进行监控和预测，以数据驱动企业降本增效，提高服务质量。
仔细观察一下互联网场景中的数据特征，其实和工业领域大部分的实时数据类似：
单条数据不会很长，但是数据量很大
它们都带有时间戳，且按顺序生成
数据大部分都是结构化的，用于描述某个参数在某个时间点的特征
写入的频率会比查询的频率高很多
已存储的数据很少有更新的需求
用户会更关心一段时间的数据特征，而不是某一个时间点
数据的查询分析大多基于某一个时间段或者某个数值范围
需要进行统计和可视化的展示
从上面这些数据特征，可以很明显的看出来，虽然两种数据库产生的环境不同，但是面对的问题是相同的，解决的需求是类似的，所以两种数据库设计出的功能有很多重合的部分。
这就好像两个从未谋过面的兄妹，确认过眼神就知道是一家人。
想替代我吗？没那么容易
随着IoT和工业互联网带来的新一波风口，一系列新的生产方式、组织方式和商业模式开始涌现。
物联网技术逐步渗透工业，不断增长的传感器、飙升的数据量，以及更高的大数据分析需求对实时数据库传统的技术架构提出了挑战。
有些问题是需要直面的：
扩展性遇到瓶颈。传统的技术架构虽然能保证单机具备极高的性能，也可以通过增加机器使性能线性扩展，但是不能像分布式系统那样实现动态灵活的扩容和缩容，需要提前进行规划。当业务升级需要系统扩容时，老架构的扩展性就很难满足需求了。
无法和大数据生态对接。数据采集的最终目的是被理解和使用，大数据产业中对于海量数据的存储分析已经有很成熟的方案，不论是hadoop还是spark的生态圈，都面临着新老技术的对接。很多工业企业因为想使用新的大数据分析技术，不得不对现有的系统进行升级或是替换。
价格高昂。传统的工业实时数据库解决方案价格都十分昂贵，一般只有大型企业能忍痛接受。但是随着新技术新理念的普及，更多的中小企业也意识到数据的重要性，但考虑到资金投入，会倾向于寻找价格更低廉的方案。
这时候来自互联网大家庭的时序数据库方案就展现出了一些先天优势，比如：
分布式架构的天然优势：传统的实时数据库多是主备的部署架构，通常要求有较高配置的机器，来追求单机极致的性能；同时，在稳定性方面，会对运行软件的稳定性做极高的要求，完全由高质量的代码来保证运行的稳定；由于存储容量有限，也会要求超高的数据压缩比。但是时序数据库的分布式架构，使得系统能够轻松的进行水平扩展，让数据库不再依赖昂贵的硬件和存储设备，以集群天然的优势来实现高可用，不会出现单点的瓶颈或故障，在普通的x86服务器甚至是虚拟机上都可以运行，大大降低了使用成本。
更灵活的数据模型：传统的实时数据库由于工业场景的特殊性，常使用的是单值模型，一个被监控的参数称为一个测点，在写入时会对每一个测点建一个模型，比如一个风机的温度指标算一个测点，十个风机的十个指标就是100个测点，每个测点会附带描述信息（名称、精度、数据类型、开关量/模拟量等）查询的时候就会针对每个测点去查询数值。单值模型的写入效率会很高。
而时序数据库，开始采用多值模型，类似面向对象的处理方式，例如风机是一种数据模型，可以包括温度、压力等多个测量维度，还包括经纬度、编号等tag信息，这样对外提供服务时会更适合分析的场景。
当然单值模型和多值模型是可以互相转换的。很多数据库对外提供的服务为多值模型，但是底层存储还是单值模型。
现在大部分的时序数据库都选择了扩展性较好的NoSQL数据库，相比于关系型数据库，数据模型更灵活，非常适合时序数据的多值模型；更易扩展，在资源受限或者需要提升性能的时候，可以轻易的增加机器；查询效率高；开源软件成本低；可以与大数据生态无缝对接。
看下使用NoSQL数据库作为底层存储的TSDB：