当前位置:文档之家› 深入浅出实时数据库

深入浅出实时数据库

深入浅出实时数据库12.8日版主要介绍如下主题:谈到实时数据库,暂时大家还颇感神秘,后面我们将逐渐解开面纱,给大家展示一个真实的实时数据库世界。

先了解概念,再深入原理。

说道实时数据库,当时诞生于美国,随着流程工业和航天工业的发展,大量的测量数据需要集成和存储,采用关系数据库难以满足速度和容量的要求,而且接口访问复杂,不适合科研和监控的需要,因此80年代中期,开始诞生了以工业监控为目的的实时数据库。

今天大家看到的一些实时数据库,如PI、Uniformance、Infoplus、InSql等工业监控类实时数据库均先后诞生于此阶段。

而当时还有另外一个分支,即所谓硬实时数据库,它的采集速度和响应速度均是毫秒级的,而大家知道,今天大量应用实时数据库,主动采集速度均是秒级的,响应速度也不严格,在Windows平台下,小于40ms的响应均不准确,但当时却有这类产品,目前多用于军事和科研了。

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

国内的实时数据库发展较为缓慢,这和技术封锁和政治风气都有关系,到了2000年之后,国内的实时数据库逐渐展露头角,如ESP-iSYS、Agilor等与国外的PI、InfoPlus均属于大型分布式网络实时数据库。

规模相对较小的,如PHD、ConRTDB、SuperInfo,在国内开始应用。

由于应用场景的不同,好多企业开始还只是解决现场监控的问题,分不清RTDB与SCADA的概念,结果InSql获得了一个发展的机会。

那么,什么是实时数据库呢,过去国人老将其与SCADA搞混,倒也给SCADA 一个发展的机会。

实际上实时数据库是“对实时性要求高的时标型信息的数据库管理系统”,在这里特别提醒,是管理系统,而非单独一个数据库。

实时数据库虽是系统软件,但更多是一个应用平台软件,原因是实时数据库还没有一个像SQL一样的标准,而且其功能太过综合,各厂商推出的产品功能各有侧重。

但以上的膜片中至少总结了实时数据库的主要功能。

目前实时数据库已经应用到众多领域,它的应用范围还在不断扩展,业界的工程师在不断创造出实时数据库的应用模式。

只要有时标型数据(时标表示每隔几个记录间隔显示一点),实时数据库就可以在一定程度上发挥威力。

说到这里,渐渐要讲原理了。

与一般认识不同,时标型数据并非仅仅指时间戳、值和质量码,还有一个很重要的属性,那就是及时性,及时性有两重含义,采样间隔和数据的新鲜度。

时标型数据的价值随新鲜度降低而递减。

1秒钟内的数据可以用来流程工业中的控制,5秒钟之内可以用来监视,半小时内的数据可以用来分析和优化,一天内的数据可以用来日报表,如果是半年前的数据,则只能做对比和追溯了。

而得到数据的新鲜程度往往取决于采样频率,这就是为什么如此重视实时数据库的采样快速性。

同时采样的频率还进一步决定了实时数据库保存信息的丰富程度。

请看下一张膜片:大家都知道采样定理,根据拉普拉斯变换,任何信号都可以被分解为频率不同、幅值不同的正弦波叠加,而如果要让采到的数据中包含一个频率的信息,则采样频率至少为此频率的2倍。

所以大家不要过分关心实时数据库宣称的无损压缩,更重要的是要明白,信息的最大损失就在于采样。

更简单的例子,当你以10秒钟的周期去采样,可能装置运行过程中出现了异常的超调,在5秒内又恢复了,而你的实时数据库中却根本不存在这些信息。

从另一个方面讲,实时数据库中存储的数据永远是滤波后数据,实时数据库就像一个低通滤波器。

接下去,要讲到实时数据库的核心技术原理了,理解了这些原理,在设定实时数据库运行参数的时候,才能得到更好的效果。

也就会明白,一个RTDBA(RTDB Administrator 实时数据库管理)的存在价值。

看看这些标题,就知道,下面将会讲很多关键的东西。

首先看看,任何复杂的大型实时数据库,其基本体系架构,也不外乎如图所示,通过现场适配层适配现场的各种接口,在工业控制中这是一个复杂的工作。

然后通过实时核心,完成数据的采集、实时计算、报警计算、其它处理,实时数据被不断泵入磁盘历时存储,形成可追溯的历时信息,同时通过向应用层提供各种适配接口,支持各种开发语言和各种应用需求的访问。

认识好这个基础架构,下面看核心原理,就思路清晰了。

总的来说,目前工业通讯、传输的协议种类繁多,主要有两方面原因:1、历史遗留;2、人为垄断;二者的合力就是上边这张膜片的内容,很多时候,为了不付出厂商提出的巨额接口或接口板卡费用,广大的业界工程师采取编程口、打印口等极端方式,以获得可以接受的性价比。

在协议载体上,主要是串行和以太两种,当然在串行通讯中又有很多专用总线分支,例如Profibus等。

未来在载体上是相当的清晰,以太网通讯技术已经势如破竹,所以,前途光明,但另一个困扰更大,就是封闭的协议,目前大部分厂商都宣称自己开放了,但开放的是上层,而非底层。

虽然,至少可以做到采用OPC访问实时数据库,但要想简单地将For InSql的接口用于Agilor,则很难,这就是底层没有协议的问题。

有些工程师提出,如果底层协议不统一,实时数据库的市场将继续存在混乱和低速发展。

谈到接口,小型实时数据库(许多是号称自己是实时数据库的组态软件)均采用了以上的架构,即将核心和接口做在一起,用户使用起来较为简单,但如果出现任何一个不稳定的接口或局部异常,那整个实时数据库就崩溃了。

另外对于大型应用,这种结构也较难扩展。

对于大型分布式实时数据库,基本按照如下的配置:接口软件被独立出来,即可以与实时数据库核心集中部署在1台计算机上,也可以与部署在接口机上,在大规模应用的时候,接口的负载不会影响核心的稳定,同时任意一个接口出现Crash,都不会导致实时数据库整体宕机。

从而提供了更好的可扩展性和稳定性。

谈到影响接口效率的因素,主要如下:首先协议如果慢,那没什么好的方法,这主要可以看看DDE协议,在OPC出现前,也曾经红火了一段时间,DDE使计算机上跨进程数据可以方便通讯,但这种通讯协议本身效率很低。

计算机再快,容量不能大幅度上升,几百个位号就很不错了。

就这一点,就决定了其退出了历史舞台。

第二在于网络状况。

没有有效地组网,以太网也会十分缓慢。

有效的带宽变低,使得快速协议也变得缓慢而不稳定。

网络状况有两方面:1、物理结构合理性,多少次经验告诉我们,没有合理组织的以太网,往往导致数据的阻塞,梳理以太网就像控制交通流量,任何地方出现瓶颈,都会导致数据缓慢;2、病毒,尤其是占用大量带宽的蠕虫,一旦感染了这个,接口中断就很有可能了。

设备效率也一样关键,经常出现DCS 工作压力很大了,这时再看其通讯,就很难了。

针对这种情况往往应该增加通讯卡件来提高效率;工作站负载也是影响大型系统接口效率的关键,很多大型系统的OPC都在工作站上,这时,如果工作站负载很重,OPC能分到的运行时间不足,又会影响效率,最终数据传输还是很缓慢,而且不稳定。

OPC并非什么好协议,只不过因为是中立国出的协议而如此广泛被使用。

如果这些都没有问题,那么最终协议总归协议,实现协议交互的软件质量还十分关键,在实施中,我们也经常会碰到因为质量不好的OPC,效率低、稳定性差导致整个系统不稳定的。

知道了以上内容,现场遇到问题,应逐个排除,不要一开始就责怪实时数据库不好,只有对症下药地解决问题,才能获得高效的系统。

接下去将探寻接口内部的奥秘,先给大家一张预览图:谈到这里,就要谈到实时数据库为做到实时的考虑了。

为了做到实时,实时数据库采取了“实时”的反面-》“缓存”,缓存是为了提高交互效率,从而使整体更加实时,这点后面将详细介绍。

那么一个接口程序内部有什么呢?主要有两部分:现场接口协议栈和位号分组。

当然,对于小型的接口,位号分组被省略了。

位号分组是按照实时数据库组态的要求,按不同的频率采集实时数据。

分组的优势在于降低了位号采集的工作量。

要知道很多协议是慢速的(如串口协议)。

如果实时数据库中仅要求5秒钟的采样频率,而下端却不作区分,按最快的频率采集,则往往效率就会降低,甚至影响到配置为高速采集的其它位号。

因此,分组往往是必须的。

协议栈则不用解释,大家都知道必须实现的。

实现的好,则效率高、稳定性好。

实时数据库接口中有定时器,在Windows平台上能获得的最高定时精度为40ms,因此采样周期高于40ms,没有意义。

一般主动采集的频率都是1赫兹以下的(也就是慢于1秒/次),更加快速的时候,均采用主动通知的方法,即当数据变化的时候,主动向实时数据库内核发送变化的数据,以达到更高效率。

接口就简单介绍到这里,要明确的是,对于主动采集方式下,接口相当于多了一层缓存,在今后的讲解中,大家会发现,实时数据库的效率和缓存的层次多少很有关系。

简单谈谈分布式技术,大型分布式实时数据库都采用了一定的分布式技术,采用的技术不同,局限性也不同。

COM/DCOM被熟知,被业界认同,是微软主要分布式技术,因此被广泛应用。

但逃不出DCOM安全性的魔障,与Windows权限捆绑紧密。

而且对于连接效率低的时候容易出错。

跨平台能力则更是彻底不具备了。

J2EE很好,但效率有些低,最近JAVA6出现后,效率已经有了显著提升。

甚至比.Net快,但作为底层研发来说,采用J2EE很不合适,原因是其对硬件的访问能力较弱。

随着以太网和工业通讯标准的提升,J2EE平台也许在工业应用上有后劲。

目前多数实时数据库厂商采用了专用TCP/IP协议,优势是易跨平台,部署方便,稳定性容易掌控。

但增加了掌控能力的同时也降低了对已有框架的集成,开发工作量大。

从实时数据库所面向的应用场景来说,专用TCP/IP 协议更加适合一些。

下面给出实时数据库的简化模型,后面的原理将结合这张图来讲解。

实时数据库被简化成由多个接口、一个接口管理模块、一个组态模块、一个实时模块、一个高速缓存和一个历史模块组成,上面覆以应用接口。

这个结构基本适合大部分实时数据库,各模块运行需要的组态信息往往从组态模块中获取,高速缓存往往和历史模块、实时模块都发生关系。

接下去将讲解实时数据库的核心IO策略。

前面已经讲过了,实时数据库一般采用缓存来增加读实时数据的及时性,因此实时数据库核心中都有高速缓存,如上图所示,通过接口的采集,高速缓存的数据得到不断的更新,而当上层读位号的时候,实时数据库通过返回缓存的值来快速响应。

因此,读一般是异步的。

但写则一般是同步的,写意味着控制,控制意味着严格的时序性,同时,写也可能失败的,如果写是异步的,则可能以为成功了,但实际失败了,后果不堪设想。

写的效率严重依赖于接口通讯效率和执行机构。

如果只是修改设定值,则可以较快返回,如果直接写阀位等需要机械执行的值,那就慢了。

由于缓存,则必然会产生时滞。

相关主题