我们为什么需要实时数据库?

第一章 导语

1.1场景切入

世界正在朝着信息化飞速前进,科学技术的蓬勃发展,预示着我们的世界正以指数级变化,我们捕获和解析的数据比以往更多,速度比以往更快。

试想一下这些场景:身边的智能家居、路上的无人汽车、山上的巨型风机、股市的自动交易算法、工厂中的自动化生产线,它们都有哪些共同点?

如果仔细观察你会发现,这些应用场景的系统都需要一种特殊的数据:

  • 智能家居系统持续监控房屋内的变化,调整温度,识别侵入者,对于使用者总是有求必应;
  • 无人驾驶汽车持续收集所处环境中的变化数据,指挥汽车安全行驶;
  • 风场无人化值守,持续收集设备运行状况、气象数据、电气数据,做出综合诊断;
  • 自动交易系统持续收集市场的变化数据,支持交易算法运算;
  • 生产系统持续收集各个机器人的变化数据,指挥生产线高速运转。

这些应用程序均依赖一种衡量事物随时间的变化的数据形式,这里的时间不只是一个度量标准,而是一个坐标的主坐标轴。同时,其输出信息、分析结果也要求及时,越及时则价值越大,随着时间延迟其价值会衰减。

1.2发现本质

这些数据,本质上是大量的传感器,通过不断的观察、感知物理世界,用采集到的离散数据,构建还原出一个数字世界,在这个数字世界我们可以自由地做任何实验,并在恰当的时间窗口内获得满意的结果,再作用于物理世界。物理世界的一大规律就是:万事万物随着时间推移而状态不断发生变化。

1.3归纳概念

传感器的存在和发展,让物体有了触觉、味觉和嗅觉等感官,让物体慢慢变得活了起来。人通过五官来感知外部世界,设备通过传感器来感知外部世界。

传感器对物理世界的观察所产生的数据,就是时间序列数据,简称时序数据。然后还要参考其是否具备及时性,进一步分为实时数据和历史数据,前者具备及时性,有高价值,能实时反馈于物理世界;后者不具备及时性,但仍然有价值,海量历史数据的分析挖掘可以发现更多有价值信息。

1.4发展趋势

随着技术水平的提高,我们有了更强大的吞吐能力、计算能力、存储能力、分析能力,时序数据渐渐在我们的世界中发挥更大的作用。

截止到当前(2019年1月),在过去的 24 个月中,专门处理时间序列数据的数据库已经成为增长最快的类别:

数据来源:DB-Engines,2019年1月. https://db-engines.com/en/ranking_categories

应用方面,有以下几个趋势:

1、对实时性要求越来越高。用户对需求响应速度要求越来越高,部分离线分析业务转为实时业务;

2、监控系统的数据采集密度越来越大。从局部采集发展到全量采集,从小时级、分钟及发展到秒级、毫秒级。

第二章  分析

几乎所有了解IT的人都知道数据库,而且是关系数据库,因为它是大学里的必修课程,那我们做的实时数据库又是什么,发展前景如何,人们通常会问以下问题:

1、实时数据库是什么?

2、何时需要使用实时数据库?

3、实时数据库能带来什么价值?

2.1定义概念

下面,让我们由浅入深,逐个解答。先看几个基础定义:

  • 数据是什么?

科学地,数据是事实或观察的结果,是对客观事物的逻辑归纳,是用于表示客观事物的未经加工的原始素材。

通俗地,有一条数据是“庚顿实时数据库管理系统”。

  • 数据库是什么?

科学地,数据库可视为电子化的文件柜——存储电子文件的处所,用户可以对文件中的数据进行新增、截取、更新、删除等操作。

通俗地,把数据“庚顿实时数据库管理系统”写入文件DataBase.dat,这个文件就叫数据库。

  • 数据库管理系统是什么?

科学地,数据库管理系统(Database Management System)是一种操纵和管理数据库的大型软件,用于建立、使用和维护数据库,简称DBMS。它对数据库进行统一的管理和控制,以保证数据库的安全性和完整性。

通俗地,有一个软件程序,它在计算机上运行起来之后,就是一个管理系统,这个系统可以管理DataBase.dat文件,用户通过这个软件来操作文件中的数据。

2.2 结合需求

江湖上流传着“天下武功,唯快不破”真理,同样,社会生产力也追求着无止境的高效率,对软件系统来说要“分秒必争”,对用户来说要“多快好省”。

“快”的同义词是“实时”,于是就有了“实时数据”、“实时数据库”、“实时数据库管理系统”,其对应的意义分别是:

1、实时数据:

在某事发生、发展过程中的同一时间中所得信息的载体,是用于表示客观事物的未经加工的原始素材。即传感器刚刚观察物理世界时所产生的数据,这个数据是真实的、代表事物当前状态的。

2、实时数据库与实时数据库管理系统:

在日常交流中,这两个名词都指“实时数据库管理系统”,前者为简称。但是,在书面中,如说明文档、法律文书、合同规范等,务必使用“实时数据库管理系统”,不要使用简称,如“庚顿实时数据库管理系统”(参考软著里面的名字)。

严格意义上,实时数据库指存储数据的处所,比如0001.rdf文件;实时数据库管理系统是指这一套程序运行起来的系统,比如goldenserver等在后台运行的系统服务及管理客户端。

2.3 关于实时数据库

2.3.1实时数据库是什么?

实时数据库(RTDB-Real Time DataBase)是数据库管理系统发展的一个分支,它适用于处理不断更新快速变化的数据及具有时间限制的事务处理。实时数据库技术是实时系统数据库技术相结合的产物。实时数据库最起初是基于先进控制和优化控制而出现的,对数据的实时性要求比较高,因而实时、高效、稳定是实时数据库关键的指标。

2.3.2何时需要使用实时数据库?

纵观实时数据库的发展历史,可以了解到何时需要使用实时数据库。

实时数据库的研究设计始于20世纪80年代中期。当时的美国随着流程工业和航天工业的发展,大量的测量数据需要集成和存储,采用关系数据库难以满足速度和容量的要求,而且接口访问复杂,不适合科研和监控的需要,因此诞生了以工业监控为目的的实时数据库。实时数据库系统一般是商业企业信息化建设和工业控制智能化的基础,在商业化的实时数据库产品开发上,国外有不少著名公司在原有自营业务的基础上推出了相应的实时数据库产品。

到了90年代,实时数据库在流程工业全世界范围内大行其道,源于以太网的逐步普及;主要应用于工业监控、控制和公用工程。

国内的实时数据库研究开始得晚一些。随着国内工业界对分布式控制系统(Distributed Control System,DCS)的广泛引进和应用,教育科技界率先进行研究实时数据库理论的研究。当时对实时数据库系统(Real Time Database System,RTDBS)的研究主要来解决实时系统中的数据管理问题或为RTDBS提供时间驱动调度和资源分配算法。

现在大数据有很多处理工具,最流行的当属Hadoop、Spark。其生态包括HDFS, HBase, Hive, YARN, Storm, Spark, Zookeeper等系列工具。整个大数据平台中往往还有Kafka, Redis等类似的消息队列、缓存库等。这些软件较好的解决了互联网通用大数据问题,但是物联网、车联网、工业互联网等场景中的海量传感器数据有其独特性,这就是实时数据库所擅长的领域,一个专业数据库与通用大数据平台有机融合,使成本大幅降低、综合能力大幅提升。

现如今,随着第四次工业革命、互联网+、物联网(IoT)、信息物理系统(CPS)的浪潮席卷全球,中国准确把握住这次机遇并走到了技术和应用的前沿。在国家层面,“实时数据库”被看作是与操作系统同一级别的基础软件。2015年12月14日,工业和信息化部发布贯彻落实《国务院关于积极推进“互联网+”行动的指导意见》行动计划(2015-2018年),明确了2018年“互联网+”总体目标。文中关于实时数据库有如下内容:

“发展软件和信息技术服务业。推动基础软件核心关键技术突破,加快新兴领域基础控制及应用软件发展。支持高端工业软件、新型工业APP的研发和应用,发展自主可控工业操作系统及实时数据库等基础软件,提升设计、仿真、管理、控制类工业软件的国产化率和应用水平。”

所以,现在就是需要使用实时数据库的时候。

2.3.3 实时数据库能带来什么价值?

目前实时数据库已经应用到众多领域,它的应用范围还在不断扩展,业界的工程师在不断创造出实时数据库的应用模式。实时数据库还可用于会计、银行、法律、医疗记录、多媒体、过程控制、预定系统和科学数据分析等领域。

整体来看,以监控为目的的实时数据库只是狭义上的实时数据库,广义上讲,只要一个数据库具备实时处理过程,即以足够快的速度处理事务来返回结果并及时响应,且处理的工作事务的状态不断变化,那它就是实时数据库。而以监控为目的的实时数据库满足这些条件,它处理的是传感器或设备不断产生的时序数据,可以快速处理、及时响应。

工业监控领域的实时数据库其实并不单单只是一个数据库,而是一个系统,包括对各类工业接口的数据采集,海量监测数据的压缩、存储及检索,基于监测数据的反馈及控制功能等。它主要是为了解决当时关系型数据库不太擅长的领域,包括:

1、海量时序数据的实时读写操作

2、大容量时序数据的存储

3、集成了工业接口的生产数据采集

4、集成控制功能,可实现实时控制

5、集成计算功能,可实现实时计算

6、集成发布功能,可实现第三方系统的无缝对接

7、工业级,连续运行十年,真正实现免运维

而且,随着实时数据库与云计算、大数据、AI、5G、物联网等技术的融合,将互联网领域先进技术通过实时数据库这个桥梁引入工业、制造业等领域,助力实体经济企业在信息化、智能化方向快速发展,给企业赋能。

2.4 关于时序数据库

有些人将“时间序列数据”视为按时间顺序存储的一连串随时间推移测量相同事物的数据点,这样解释没错,但只描述了浅层信息。

其他人可能会认为是一连串与时间戳配对的数值,这些数值由一个名称和一组归类维度(或称“标签”)所定义。这也许是一种为时间序列数据建模的方式,却不是数据自身的定义。

2.4.1 应用示例

以下是一个基础示例,设想一些传感器从三个环境中收集数据:分别是城市、农场和工厂。在这里,每一个数据源定期发送新的读数,创建一系列随时间推移收集到的测量结果。

还有许多其他类型的时间序列数据,例如:DevOps监控数据、移动/Web应用程序事件流、工业机器数据、仪器仪表数据、科学测量结果。

这些数据集主要有以下三个共同点:

1、抵达的数据几乎总是作为新条目被记录

2、数据通常按照时间顺序抵达,但受传输影响,部分数据延迟抵达是常见现象

3、时间是一个主坐标轴(既可以是规则的时间间隔,也可以是不规则的,通常是不规则的)

换句话说,时序数据的处理过程通常是伴随数据的抵达而进行的。并且在事后需要纠正错误的数据,或处理延迟数据或无序数据,但这些都是例外情况,却也是应用系统建设时必须要解决的问题。

2.4.2 数据特征

要存储这些时序数据,你可能会问:

这与在数据库中添加字段有何区别?

这取决于:你的数据集如何跟踪变化?是更新当前条目,还是插入新的条目?

当你为传感器X收集新读数时,是覆盖以往的读数,还是在新的一行创建全新的读数?尽管这两种方法都能为你提供系统的当前状态,但只有第二种方法才能跟踪系统的所有状态。

简而言之:时间序列数据集跟踪整个系统的改动并不断插入新数据,而不是更新原有数据。

时间序列数据之所以如此强大,是因为将系统的每个变化都记录为新的一行,从而可以去衡量变化:分析过去的变化,监测现在的变化,以及预测未来将如何变化。

因此,我们这样定义时间序列数据:统一表示系统、过程或行为随时间变化的数据。

2.4.3 寻找场景

通过围绕“变化”的定义,我们可以开始找出当下我们应该收集却没有收集的时间序列数据集。

事实上,我们发现人们早已坐拥时间序列数据,但他们却没意识到这一点。

假设你正在维护一个新能源集中监控系统的应用,每次用户登录时,你可以在“users”表的某行中更新用户的“last_login”时间戳,但是如果将每次登录作为一个单独的事件处理,并随着时间推移收集这些数据又会有怎样的效果?届时你可以:跟踪历史登录活动,了解随时间推移用户使用的增减情况,根据访问应用的频率或更多指标区分用户。

这个示例说明了一个关键点:通过保留数据固有的时间序列性质,我们能够保留有关数据随时间变化的有用信息。

事实上,这个示例还说明了另一点:事件数据同样也是时间序列数据。

当然,按照这种方式存储数据会带来一个明显的问题:最终你会以相当快的速度得到大量的数据,时间序列数据很快会堆积起来。

数据量太大会给写入和查询操作带来严重的性能问题,数据的延迟和处理的低效已经严重制约生产力的发展,这也是人们正逐渐转向实时数据库的原因。

2.5为什么要用实时数据库?

那么为什么大部分调查对象使用实时数据库而不是常规数据库呢?

有两个原因:规模&性能、可用性。

1、规模&性能: 时间序列数据累计速度非常快,在数据累积过程中也要保持高性能。例如,一台风机上有1000个监测项,那么一天会产生8640万条数据,那1万台风机一年会产生315万亿条数据。常规数据库在设计之初并非处理这种规模的数据,关系型数据库处理大数据集的效果非常糟糕。相比之下,实时数据库将时间视作一等公民,通过提高效率来处理这种大规模数据,并带来性能的提升,包括:更高的容纳率、更快的大规模查询以及更好的数据压缩。

2、可用性:实时数据库不仅仅是一个数据存储查询软件,作为工业级的实时数据库管理系统,除了核心的数据存储查询组件,通常还包括支持各种设备和数据源的数据采集组件、支持各种系统和平台的数据输出组件、支持自定义算法的实时计算和数据分析组件、支持自定义图形组态的数据可视化组件、以及面向用户的报警组件、报表组件、趋势组件等。即使当下不考虑规模,这些功能仍可提供更好的用户体验,帮助用户使用“搭积木”的方式快速构建系统。

 

特别地,基于开源生态诞生的一些时序数据,那为什么要用实时数据库呢?

有两个原因:安全可控、稳定

1、自从中美贸易战以来,“安全可靠、自主可控”的呼声越来越强烈,政府、国企、央企以及一些自身数据价值较高、且拥有一手数据源的企业都在积极贯彻落实“安全可控”化转型,尤其是作为基础的操作系统、数据库、工业软件几乎被国外大厂所覆盖,开源软件更是以国外提供的开源组件为主,任何一个微小的变动,从软件应用角度讲,都无法保证其安全性。庚顿实时数据库也已经适配主流的国产操作系统和CPU,基于国内自主研发的庚顿实时数据库构建应用和解决方案,使用户不再有后顾之忧。

2、从应用角度看,监控系统和分析系统对底层软件的要求是完全不一样的。监控系统以安全生产、稳定运行为第一位,一旦投运就不允许随意操作,有一套非常严格的操作管理流程;分析系统则以人为核心,实时性要求不高,用户需求、市场环境时刻变化着,分析工具层出不穷,挖掘算法持续迭代,系统里面的数据就是拿来任意操纵的,不可避免会触发些未知问题,这时候就需要运维开发顶上了,或者用历史备份数据覆盖。庚顿实时数据库是在生产系统久经考验的产品,这种情况下还需要对比吗?

 

也可能有人说:实时数据库是落后的技术,现在开源的时序数据库才是先进的。这话对但也不对,抛开内容,绝对语气的话都不能算正确的。

原因也举两个:

1、这个和实时数据库的行业有关,号称有实时数据库的公司有上百家,但是有专业团队或公司专门把实时数据库作为产品打造的不超过十家,能称得上持续进步、保持领先的再减一多半。大部分都是自用,满足其应用需求即可,而应用需求决定技术上限,所以,越往高端越少,这个道理同样是适用的。庚顿数据作为专业做数据处理的公司,十二年里做了很多很多研究,什么开源的、保密的都在研究和创新,我们一直在坚持预研一代、市场推广一代,现在民用市场应用的指标要求对我们没有什么挑战了,我们会在军工航天领域挑战极限指标。

2、对于开发人员来说,更愿意用知名度高的开源软件,因为自己可以积累相关经验、以后找工作更方便,至于成本嘛,反正是用开源软件不用花钱采购;对于做应用的企业来说,采购软件是成本,给员工发工资也是成本,社会化分工就是专业的人做专业的事,企业能够更高效率地赚钱,降低成本,给社会创造更多价值。一味追新对企业来说可能是不合适的,所以在选型时要做更多综合考量、客观评价,而不仅仅是从主观角度下定论。

 

 

这就是为什么架构师越来越多地采用实时数据库,并将它用于各种使用场景的原因:

  • 监控软件系统: 虚拟机、容器、服务、应用

  • 监控物理系统: 设备、机器、接入的设备、环境、我们的房屋、我们的身体

  • 资产跟踪应用: 汽车、卡车、物理容器、运货托盘

  • 金融交易系统: 传统证券、新兴的加密数字货币

  • 事件应用程序: 跟踪用户、客户的交互数据

  • 商业智能工具: 跟踪关键指标和业务的总体健康情况

  • 更多场景……

第三章 总结

3.1延展思考

3.1.1 是否所有数据都是时间序列数据?

我们先回归到时间序列数据话题本身。

过去十多年以来,我们生活在“大数据”时代,收集了大量有关我们所处世界的信息,并运用计算资源来理解它。

尽管这个时代始于适度计算技术,但由于存在摩尔定律(Moore’s Law)、克拉底定律(Kryder's Law)、云计算以及整个“大数据”技术产业这些主要的宏观趋势,我们捕获、存储和分析数据的能力已经以指数级的速度得到提高。

根据摩尔定律,计算能力(晶体管密度)每18个月翻一番,而克拉底定律则假定存储容量每12个月翻一番。

现在我们不再满足于观察世界状态,想要的更多,我们想度量世界随亚秒级别时间推移的变化。我们的“大数据”数据集现在正被另一种数据超越,这些数据在很大程度上依赖时间来保存正在发生的变化的信息。

3.1.2 是否所有数据一开始都是时间序列数据?

回顾我们早期的新能源集中监控系统的应用示例:我们其实已坐拥时间序列数据,只是当时没有意识到。

或者想一下任何“常规”数据集,例如主流零售银行活期账户和余额、软件项目的源代码或博客文章的文本。

通常我们选择存储系统的最新状态。但是如果我们反过来存储每个变化,并在查询时计算最新的状态又会如何?“常规”数据集是不是很像相应时间序列数据集的顶层视图,只是考虑到性能原因先被缓存了起来?

银行是不是有交易账本?(区块链是不是分布式、不可修改的时间序列记录?)

一个软件项目是不是要有版本控制(例如,Git Commit?)

博客文章是不是有修订历史?(撤销、重做。)

换句话说:是否所有数据集都有日志?

我们注意到许多应用程序可能永远不需要时间序列数据(而且使用“当前状态视图”效果更好)。但是随着技术进步的指数曲线的不断向前发展,似乎这些“当前状态视图”变得不是很必要了。只有以时间序列形式存储更多的数据,我们才能够更好地了解它。

3.1.3 下定决心

无论如何,有一件事情是清楚的:时间序列数据已经出现在我们周围,实时数据库的应用场景并不是它诞生时候就定义好的,我们知道为什么要用,也知道如何使用,但用在哪里要不断探索实践,所以现在是时候将其投入使用。

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值