实时数据库介绍

1、实时数据库介绍拖太久了，最终我还是要将这篇文章写出来，希望能够对同仁们有所帮助。在此文章中，我计划主要介绍如下主题：注：图其实都很清晰，如看不清，纯属CEC博客功能问 看大图。谈到实时数据库，有些同仁还颇感神秘，我写此文结合我05年开始做的MES RTDBE实时数据库工程师培训教材来开展，逐渐解开面纱，给大家展示一个真 实的实时数据库世界。题，用鼠标点一下图，中程SUPCON虹）J实时数据犀概念先了解概念，再深入原理。中理 5UPCON实时数据犀概念.历史:会起，美国8WR中期【工业监控)PI, UnifonnarKe(PHD), InfoPlus, InSql Eagle Speed RTD

2、BMS 硬卖时裁据库推广应用：世界范围内90任代(工业监控、控笔、公用工程)PI, Uniformartce(PHD), InfoPlus. InSql国内广证应用：网0今(工业监控、控制.经用工程.环境.应. 智能交通.智能整.通阻PI, ESP-iSYS , InfbPlus. Agilor大型分布式网堵卖时裁据库Uniform a rkcef PHD, ConRTDB, 5 叩 er Into CJS 分布式史时敦 据库InSql中小行口 S分布式数据库说道实时数据库，当时诞生于美国，随着流程工业和航天工业的发展，大量的测 量数据需要集成和存储，采用关系数据库难以满足速度和容量的要求，而

3、且接口 访问复杂，不适合科研和监控的需要，因此80年代中期，开始诞生了以工业监 控为目的的实时数据库。今天大家看到的一些实时数据库，如PI、Uniformance、Infoplus、InSql等工业 监控类实时数据库均先后诞生于此阶段。而当时还有另外一个分支，即所谓硬实 时数据库，它的采集速度和响应速度均是毫秒级的，而大家知道，今天大量应用 实时数据库，主动采集速度均是秒级的，响应速度也不严格，在Windows平台 下，小于40ms的响应均不准确，但当时却有这类产品，目前多用于军事和科研 了。到了上世纪90年代，实时数据库在流程工业全世界范围内大行其道，源于 以太网的逐步普及；主要应用于工业监

4、控、控制和公用工程。国内的实时数据库 发展较为缓慢，这和技术封锁和政治风气都有关系，到了 2000年之后，国内的 实时数据库逐渐展露头角，如ESP-iSYS、Agilor等与国外的PI、InfoPlus均属 于大型分布式网络实时数据库。规模相对较小的，如PHD、ConRTDB、Super Info,在国内开始应用。由于应用场景的不同，好多企业开始还只是解决现场监 控的问题，分不清RTDB与SCADA的概念，结果InSql获得了一个发展的机会。中 1受-SUPCON实时数据库概念实时数库是对实时性要求言的时标型信息的数库管理 系绕实时数据库主要购能包括：集成各神昇枸通讯协诙的数据毫，形成蕴一的妨

5、问实时数据接口完成对实时救据的集中海最存储支持实时数据该写揉作和历史数据的高效查询提供实时计算、实时分析处理等功能实时数据的组纠和访问权限管理那么，什么是实时数据库呢，过去国人老将其与SCADA搞混，倒也给SCADA 一个发展的机会。实际上实时数据库是“对实时性要求高的时标型信息的数据库 管理系统”，注意，这里特别提醒，是管理系统，而非单独一个数据库。实时数 据库虽是系统软件，但更多是一个应用平台软件，原因是实时数据库还没有一个 像SQL 一样的标准，而且其功能太过综合，各厂商推出的产品功能各有侧重。 但以上的膜片中至少总结了实时数据库的主要功能。目前实时数据库已经应用到众多领域，它的应用范围

6、还在不断扩展，业界的同仁 在不断创造出实时数据库的应用模式。只要有时标型数据，实时数据库就可以在 一定程度上发挥威力。中壬空-SUPCON实时数据库概念时标型数据（案时性数据）Vai ue + Umestanip + QualityVai ue + Timestamp + Quality + FrequencyCnmeSpan）说到这里，渐渐要讲原理了。与一般认识不同，时标型数据并非仅仅指时间戳、 值和质量码，还有一个很重要的属性，那就是及时性，及时性有两重含义，采样 间隔和数据的新鲜度。时标型数据的价值随新鲜度降低而递减。1秒钟内的数据 可以用来流程工业中的控制，5秒钟之内可以用来监视，半小

7、时内的数据可以用 来分析和优化，一天内的数据可以用来日报表，如果是半年前的数据，则只能做 对比和追溯了。而得到数据的新鲜程度往往取决于采样频率，这就是为什么如此 重视实时数据库的采样快速性。同时采样的频率还进一步决定了实时数据库保存 信息的丰富程度。请看下一张膜片：中段SUPCON实时数据库概念.玲一诚采祥定理：采祥转率心颈高于信号中最高有效独率的两倍Z-3 TOC o 1-5 h z n_大J I-IM . 一 一卜L f 一 _ F 7 W2 、入 卜- L槌J P $V j7 、jTrISjO一|:72. S.3. S/li Ai St 3. = A 3. jMi A 3. Mi S.

8、Mi ? S.IX -V A HiT _q fA u_Ai-f 、广、/、l %Ix/、p、/气/、:、阿n A n 片色 /i成 A, fl A.X项一一?.U比羊土口7_/_区虻宴车1;二此企KU翌直号!H I?二，二三二二三家三w:二二午二丑辛三二：1 d亍:壬二mw1:二二：于二壬-产-二三二二f二:=?：:二：:行:二三:-nn：x：二V：,1 , 1 1 1 = 1 =, 31 3 A1 1 * 1 , 7 1 T* X 2. ，, 1 ,二 、. F 一_/ 尸X二 1-313.4 B T X 9 Z.Z 二 - =%= X L - T MH MH =大家都知道采样定理，根据拉普

9、拉斯变换，任何信号都可以被分解为频率不同、 幅值不同的正弦波叠加，而如果要让采到的数据中包含一个频率的信息，则采样 频率至少为此频率的2倍。所以大家不要过分关心实时数据库宣称的无损压缩， 更重要的是要明白，信息的最大损失就在于采样。更简单的例子，当你以10秒 钟的周期去采样，可能装置运行过程中出现了异常的超调，在5秒内又恢复了， 而你的实时数据库中却根本不存在这些信息。从另一个方面讲，实时数据库中存 储的数据永远是滤波后数据，实时数据库就像一个低通滤波器。中1受SUPCON枝*技术原理接下去，要讲到实时数据库的核心技术原理了，理解了这些原理，在设定实时数 据库运行参数的时候，才能得到更好的效果

10、。也就会明白，一个RTDBA(RTD B Administrator)的存在价值。中手空-SUPCON 核心技术原理整体架构分析接口技术数据存储技术数据压缩技术数据实时处理技术数据安全技术看看这些标题，就知道，我下面会讲很多关键的东西，之前很多Q友在群里面 抱怨我不提供完整的实时数据库原理知识材料，抱歉，太忙了。不是吝惜什么或 技术保密，今天，只要你努力，都可以做出一个实时数据库的核来，但从一个内 核到产品的质变，是需要公司正规研发投入的，因此，原理实在不需要保密，讲 个明白，大家能更好地使用实时数据库。中至-SUPCON核*技术原理.整体架构分析应用接口适配层磁盘历史存储实时核心现场接口适配

11、层首先看看，任何复杂的大型实时数据库，其基本体系架构，也不外乎如图所示， 通过现场适配层适配现场的各种接口，做工控的都知道，这是一个复杂的工作。 然后通过实时核心，完成数据的采集、实时计算、报警计算、其它处理，实时数 据被不断泵入磁盘历时存储，形成可追溯的历时信息，同时通过向应用层提供各 种适配接口，支持各种开发语言和各种应用需求的访问。认识好这个基础架构， 下面看核心原理，就思路清晰了。中理-5UPCON_核心技术原理平台相关性通用协谀OPC DDE平台无关性通讯协谀ModBus、PiofiBus平台无关专有协谀大部分DCS陆谀、工业以未阿协谀特殊俗谀：编程口、打印口等特殊方式取得的俗谀 T

12、CP U DP事口并口其他上层逸用装体：HTTP SOAP等总的来说，目前工业通讯、传输的协议种类繁多，主要有两方面原因：1、历史 遗留；2、人为垄断；二者的合力就是上边这张膜片的内容，搭建看看，难啊， 很多时候，为了不付出厂商提出的巨额接口或接口板卡费用，广大的业界同仁采 取编程口、打印口等极端方式，以获得可以接受的性价比。在协议载体上，主要 是串行和以太两种，当然在串行通讯中又有很多专用总线分支，例如Profibus 等。未来在载体上是相当的清晰，请大家看我的另一篇文章工业以太网技术有 望统一现场总线，以太网通讯技术已经势如破竹，所以，前途光明，但另一 个困扰更大，就是封闭的协议，目前大部

13、分厂商都宣称自己开放了，但开放的是 上层，而非底层。虽然，至少可以做到采用OPC访问实时数据库，但要想简单 地将For InSql的接口用于Agilor，则很难，这就是底层没有协议的问题。前两 天在接收今日自动化采访的时候，我也提出，如果底层协议不统一，实时数 据库的市场将继续存在混乱和低速发展。中玲 SUPCON核心技术原理接口一般框架DDEOPCModBusProfiBus谈到接口，小型实时数据库（许多是号称自己是实时数据库的组态软件）均采用 了以上的架构，即将核心和接口做在一起，用户使用起来较为简单，但如果出现 任何一个不稳定的接口或局部异常，那整个实时数据库就崩溃了。另外对于大型 应用

14、，这种结构也较难扩展。对于大型分布式实时数据库，基本按照如下的配置:supcon核心技术原理接口一般框架接口软件被独立出来，即可以与实时数据库核心集中部署在1台计算机上，也可 以与部署在接口机上，在大规模应用的时候，接口的负载不会影响核心的稳定， 同时任意一个接口出现Crash，都不会导致实时数据库整体宕机。从而提供了更 好的可扩展性和稳定性。谈到影响接口效率的因素，主要如下：中垣 SUPCON核心技术原理影响接口效能的因素:协议网络状况设备效率工作站负载底层软件质量首先协议如果慢，那是没招了，这主要可以看看DDE协议，在OPC出现前， 也曾经红火了一段时间，DDE使计算机上跨进程数据可以方便

15、通讯，但这种通 讯协议本身效率很低。计算机再快，容量不能大幅度上升，几百个位号就很不错 了。就这一点，就决定了其退出了历史舞台。第二在于网络状况。没有有效地组 网，以太网也会十分缓慢。有效的带宽变低，使得快速协议也变得缓慢而不稳定。 网络状况有两方面：1、物理结构合理性，多少次经验告诉我们，没有合理组织 的以太网，往往导致数据的阻塞，梳理以太网就像控制交通流量，任何地方出现 瓶颈，都会导致数据缓慢；2、病毒，尤其是占用大量带宽的蠕虫，一旦感染了 这个，接口中断就很有可能了。设备效率也一样关键，经常出现DCS工作压力 很大了，这时再看其通讯，就很难了。针对这种情况往往应该增加通讯卡件来提 高效率

16、；工作站负载也是影响大型系统接口效率的关键，很多大型系统的OPC 都在工作站上，这时，如果工作站负载很重，OPC能分到的运行时间不足，又 会影响效率，最终数据传输还是很缓慢，而且不稳定。谈到这里，大家可以看看 我的另一篇文章OPC资本和崇洋豢养的病态协议，OPC并非什么好协 议，只不过因是中立国出的协议而如此广泛被使用罢了。如果这些都没有问题， 那么最终协议总归协议，实现协议交互的软件质量还十分关键，在实施中，我们 也经常会碰到因为质量不好的OPC，效率低、稳定性差导致整个系统不稳定的。 知道了以上内容，现场遇到问题，应逐个排除，不要一开始就责怪实时数据库不 好，只有对症下药地解决问题，才能获

17、得高效的系统。接下去的内容将更加精彩，我们将探寻接口内部的奥秘，先给大家一张预览图：中 I空, SUPCON核心技术原理接口内部结构谈到这里，就要谈到实时数据库为做到实时的考虑了。为了做到实时，实时数据 库采取了“实时”的反面-“缓存”，缓存是为了提高交互效率，从而使整体更加实 时，这点后面将详细介绍。那么一个接口程序内部有什么呢？主要有两部分：现 场接口协议栈和位号分组。当然，对于小型的接口，位号分组被省略了。位号分 组是按照实时数据库组态的要求，按不同的频率采集实时数据。分组的优势在于 降低了位号采集的工作量。要知道很多协议是慢速的（如串口协议）。如果实时 数据库中仅要求5秒钟的采样频率，

18、而下端却不作区分，按最快的频率采集，则 往往效率就会降低，甚至影响到配置为高速采集的其它位号。因此，分组往往是 必须的。协议栈则不用解释，大家都知道必须实现的。实现的好，则效率高、稳 定性好。实时数据库接口中有定时器，在Windows平台上能获得的最高定时精 度为40ms，因此采样周期高于40ms，没有意义。一般主动采集的频率都是1 赫兹以下的（慢于1秒/次），更加快速的时候，均采用主动通知的方法，即当 数据变化的时候，主动向实时数据库内核发送变化的数据，以达到更高效率。接 口就简单介绍到这里，要明确的是，对于主动采集方式下，接口相当于多了一层 缓存，在今后的讲解中，大家会发现，实时数据库的效

19、率和缓存的层次多少很有 关系。中 1空 SUPCON 核心技术原理分时技术特点：COM/DCOM一言敛、璋定，但缺乏畴平台能力， Windows集成的权限住往难于H任复杂的工网络环 境J2EE 一平台无关，效率低 不适合实时系统专用TCP/IP协设效率与协诙的设计相关，不开故， 但住住提供API简单谈谈分布式技术，大型分布式实时数据库都采用了一定的分布式技术，采用 的技术不同，局限性也不同。COM/DCOM被熟知，被业界认同，是微软主要分 布式技术，因此被广泛应用。但逃不出DCOM安全性的魔障，与Windows权 限捆绑紧密。而且对于连接效率低的时候容易出错。跨平台能力则更是彻底不具 备了。J

20、2EE很好，但效率有些低，最近JAVA6出现后，效率已经有了显著提 升。甚至比.Net快，但作为底层研发来说，采用J2EE很不合适，原因是其对硬 件的访问能力较弱。随着以太网和工业通讯标准的提升，J2EE平台也许在工业 应用上有后劲。目前多数实时数据库厂商采用了专用TCP/IP协议，优势是易跨 平台，部署方便，稳定性容易掌控。但增加了掌控能力的同时也降低了对已有框 架的集成，开发工作量大。从实时数据库所面向的应用场景来说，专用TCP/IP 协议更加适合一些。下面给出实时数据库的简化模型，后面的原理将结合这张图来讲解。EP1S-SUPCON核心技术原理简化实时数据库核心构架应用接口实时数据库被简

21、化成由多个接口、一个接口管理模块、一个组态模块、一个实时 模块、一个高速缓存和一个历史模块组成，上面覆以应用接口。这个结构基本适 合大部分实时数据库，各模块运行需要的组态信息往往从组态模块中获取，高速 缓存往往和历史模块、实时模块都发生关系。接下去将讲解实时数据库的核心IO策略。中 I空 SUPCON前面已经讲过了，实时数据库一般采用缓存来增加读实时数据的及时性，因此实 时数据库核心中都有高速缓存，如上图所示，通过接口的采集，高速缓存的数据 得到不断的更新，而当上层读位号的时候，实时数据库通过返回缓存的值来快速 响应。因此，读一般是异步的。但写则一般是同步的，写意味着控制，控制意味 着严格的时

22、序性，同时，写也可能失败的，如果写是异步的，则可能以为成功了， 但实际失败了，后果不堪设想。写的效率严重依赖于接口通讯效率和执行机构。 如果只是修改设定值，则可以较快返回，如果直接写阀位等需要机械执行的值， 那就慢了。由于缓存，则必然会产生时滞。实时数据库的采集手段使时滞不止存 在于一处。假设实时数据库从OPC中采集数据，而OPC从设备上采集数据， 如果OPC1秒采集一次，实时数据库5秒采集一次，实时数据库上有一个应用 软件，也5秒采集一次，则此应用软件读到的数据的最大时滞为11秒（各时滞 的相加和），最小时滞为5秒（几个时滞中最大的一个），在一般的情况下，时 滞符合正态分布。时滞频域的角度上

23、来分析，实际上是波的相变。或称之为相移。相移在低速变化 数据上显现的问题不是很明显，比如温度最快每分钟上升2度，影响并不明显， 但对于快速开关量，则十分致命，这个很容易理解，如果时滞1秒，而开关的变 化周期也接近1秒，则会出现一个现象，数据采集上来是关，实际现场则是开的， 现场与采集值总是相反，如果这时进行控制，就会发现控制实效，关闭已经关闭 的开关或打开已经打开的开关，没有意义。因此，实时数据库不适宜对快速开关 量的控制。这是一种极端的情况，另一种则是波动较快的窄带控制，意味着必须 将被控量控制在一个较窄的区域内，这时必须考虑时滞问题，如果时滞稳定，则 可以按照控制理论采用抵消时滞或者前馈的

24、方式获得较好的控制效果。而如果时 滞变化很大，则通过实时数据库之上进行的控制则效果不明显了，很容易失控。 讲这些不是说实时数据库不能用于有控制的场合，知道哪些不适合，才能更加正 确地使用实时数据库，应用好各种适合的场景。谈到核心调度策略，就得讲讲多线程的核心，很少有实时数据库是单线程的，大 型实时数据库中往往都有线程池，对于需要实时处理读、写、采集等任务的实时 数据库核心，其调度策略必须慎重考虑。首先，为难的是往往很难判断那些任务 的优先级更高。所以实时数据库内部往往通过判断位号的更新周期来间接揣测任 务的优先级。虽然往往可以让多个现成自己竞争，但如果某个位号的更新周期位 1秒，而另一个的更新

25、周期为10秒，那么，可想而知，应用对1秒更新的实时 数据的实时性要求高于10秒的。因此，如果有1秒的为好读任务没有完成，则 不执行10秒的，对于CPU数量小于等待线程数量的时候，特别适用。另外， 读即时值的任务优先级应该高于读历时值的任务，这个也可想而知的，读一段历 时数据，往往不在乎晚响应几十微秒，而读实时值，则是越实时越好。这样，在 实时数据库中就形成了一个内核级的读队列，任务可以被线程顺序执行，而如果 低优先级的现成得以执行的时候，会检查一下是否还有更高优先级的队列中需要 执行，如果有，则让出时间片。孔融让梨，保证更需要实时的任务先完成。对于 写任务，往往可以和读任务并行，但CPU是昂贵

26、资源，如果当前CPU被读占 用而耽误了写，则不应该，因此，写更重要，排在更高的优先级。那么采集的优 先级和读的优先级谁高呢？如果采集被滞后，那么多个可能读同一个位号的任务 都将读到老的数据，因此，采集往往是一个与读优先级的最高优先级相当的任务。 具体到不同的实现者，以上的理论未必被完全的实现，有的小型和中型实时数据 库甚至根本没有这些策略的实现，因为运行在其上的应用也不严格，因此也可以 避繁就简。呵呵，是不是对自己实现一个实时数据库更加有信心了？其实不那么容易，看这 些原理，最重要的是帮助理解，不在于模仿，实现一个商用的实时数据库是公司 的事情，个人没有必要将时间浪费到自己实现上，还是选一个合

27、适的产品来使用。 使用时通过原理来加深理解。中I空 5UPCON 核心技术原理核心压缩策略接下去，将讲到很多人想研究的实时数据库压缩算法，这个好像挺神秘的，我将 结合PI的专利技术，旋转门压缩算法给予详细的讲解，拨开云雾见太阳，世上 没有神秘的事情，只有不耐心的观众和不尽心的讲师。呵呵。虽然今天很疲惫了，但是还是继续写吧，linkman已经开始对我不满了，呵呵。 的确十分忙，但当一件事情开始做了以后，就放不下来。这里小跑一下题，（一）， 关于实时数据库行业协会，网站在年底之前肯定预上线，这是我把它当作中心工 作之一的。我十分期望等到网站一有，国内实时数据库行业的同仁有个平等交流 的场所。（二）

28、Linkman 一直关心标准的事情，我指的标准是数据采集接口的标 准，这个标准比上层API更加重要，预计2007年底2008年初，SUPCON将 向协会成员发出第一个讨论稿。言归正传了。说到数据压缩，无非有损和无损。无损的一般通过各类近似霍夫曼 编码的方法压缩数据，二有损则是采用线性拟合的方法。实时数据是如此海量， 大家真的能用的方法都用上了。无损压缩不是我讲的重点，我自己也编写过这类 压缩工具，zip、rar等等，基本上是这一思路，大家另行搜索来学习。这里讲的 是实时数据库中最常用的有损线性拟合算法。拟合方式很多，最著名的无过于O SI的“旋转门”，这个太著名了，以至于很多用户都知道。到底旋

29、转门是怎么回 事呢？娓娓道来如下：首先讲当前采集的一个数据位门轴，看着上面的膜片哦，最左下角的就是门轴， 然后每新采一个点，就将这个点和门轴画一条线，就是所谓的门，当再采下一个 点的时候，就从门轴向新点画一条线，作为新的门位置，看看，门就“旋转”了一 定角度，然后看看从门轴到门边中所有的点是否都距离门在一个阈值内，如果是， 也就是说可以用两点一线的门拟合中间若干点，显然压缩掉了大量数据。如果不 行了，则将原来与门轴组成门的那个点记录下来（此点将写入历时数据库），然 后将此点作为新的门轴，以此门轴与最新的点构成新的门。这显然是一个迭代算法，而且好处是明显的，这样计算，涉及到的乘除法很少， 效率应

30、该较高。所以PI 一直用这个算法作为其核心压缩算法。SUPCON采取了 最小二次拟合的方法，原因是现在的计算机浮点能力大大增强，同时发现最小二 次线性拟合的方法的迭代算法运算量也很小。效果和效率都很好。因此申请了专 利。国内很多实时数据库迄今没有自己的算法，仍然侵犯着PI的专利，呵呵。不过这也没有什么，OSI不计较，它在国内没有申请旋转门的专利，因此“旋转 门”是一个很好的教材。所有的有损压缩算法基本类似，有的数据库还将无损和有损两种结合起来，即先 有损压缩，然后再无损压缩，最终保存压缩结果，这样查询历时数据的时候多了 解压过程，速度会进一步降低，但空间也进一步节省。压缩是双刃剑。我特别告 诉大家，千万不要相信某些产品宣扬自己的压缩比如何高，通过以上原理知道， 压缩比高的原因就是因为阈值大，阈值大，损失就多，得到的趋势反应的细节就 少。一般实际应用，流程工业采用10： 1的压缩很合适，超过此数据，会发现 大量有用的细节都不见了。这样方法也是一种低通滤波，低通滤波伴随着时滞增 大，因此不要迷信。呵呵。掌握原理，合理设定压缩阈值，才是最好的方法。实际上，实时数据库中也使用了大量的索引技术，绝对不是关系数据库的专利， 因此，接下去将讲讲索引技术