Chinaunix首页 | 论坛 | 博客
  • 博客访问: 988243
  • 博文数量: 158
  • 博客积分: 4380
  • 博客等级: 上校
  • 技术积分: 2367
  • 用 户 组: 普通用户
  • 注册时间: 2006-09-21 10:45
文章分类

全部博文(158)

文章存档

2012年(158)

我的朋友

分类: C/C++

2012-11-15 15:13:58

关系数据库使用得比较广,为大部分人所熟悉,以至于谈到数据库,缺省情况下指的就是关系数据库,但实际上还有一些其他种类的数据库在生产生活中被广泛使用,比如我将谈到的实时数据库,它们用在要求非常严格、数据量非常大的生产工控中。

当今国际国内广泛使用的实时数据库只有三个产品:
a. 美国OSI公司的 PI ( Plant Information System )
b. 美国HONEYWELL公司的 PHD ( Process History Database )
c. 美国AspenTech公司的 IP21 ( InfoPlus .21 )

这些实时数据库的价格是非常昂贵的,以百万人民币为单位,但是它们不全是以套也不全是以点(可容纳的数据点)为单位来出售,所以无法数字化的比较其价格。因为工作的关系,我有幸能接触到这三种数据库,在此对它们做一个比较。

1. PI
采用了旋转门压缩专利技术和独到的二次过滤技术,使进入到PI数据库的数据经过了最有效的压缩,极大地节省了硬盘空间。据计算,每秒1万点数据存储一年,仅需要4G的空间,即一只普通硬盘也可存贮五到十年的数据。是效率最高,使用最简单,使用最广泛的实时数据库,因为其杰出的性能,PI已经多次提高了它的价格,确实不坠OSI的名号,而且PI在其文档中公开了她的各种算法,比如上面提到的旋转门压缩和二次过滤。

2. PHD
HONEYWELL占据了DCS大部分份额,因此PHD使用得也比较广泛,PHD在内部其实使用了Oracle关系数据库,因此购买PHD就必须先购买Oracle。因为 PHD内部使用Oracle简化了开发量 和 Oracle的性能限制比较严重,所以 PHD 的价格在这三种数据库最低,算不上正宗的实时数据库。但不要以为PHD内部使用Oracle就认为Oracle很强,如果直接使用Oracle,只要两三秒的时间,巨大的数据量就会令它崩溃。HONEYWELL其志不在实时数据库这一块,而是她的DCS。

3. IP21
IP21基本上还未进入中国市场,它正在通过先期赠送的办法打开中国市场。
在评价IP21之前,我需要先申明“我对IP21的看法只是个人看法,不是任何产品的托儿”。
IP21是我见过的最差的关系数据库,也是我见过的最差的一个软件,
a. 其软件的安装程序的运行需要一个硬狗,这种小气的做法和PI公开算法的做法没法比,问题还在于它的这条狗经常会死翘翘。
b. 其软件的安装即使是其公司的专业员工也不能保证安装成功,10台计算机让它的专业员工来安装大约只能成功一两台。
c. 其软件的安装盘只有一张,但这一张盘需要安装四个小时以上,中途不停地看到在安装某个版本的Java解释器,其后它们又被删除。
d. 没有实现真正的自动安装,在安装之前它们的工程师需要在计算机上修改不少的文件。
e. 安装中途如果出现错误是不立即报告的,需要四个小时之后安装完毕才能看到安装失败的字样,但也仅仅只能知道安装失败,不知道在哪一步安装失败。
f. 管理维护软件非常的复杂,除非有人愿意牺牲以后的前途来学习它,否则就只能让它自己的员工来鼓弄。
g. 运行效率非常低下,而且占用系统资源非常严重,一台服务器只能给一个IP21使用。

实时数据库的访问方式
a. 使用自己的API,这种方式效率最高,其实也最简单。
b. 使用ODBC,这种方式其实没有多大作用,因为实时数据库不同于关系数据库,ODBC没有太大的用武之地,所以在使用ODBC时有非常多的限制,大部分功能并不支持ODBC方式。
c. 使用OPC方式(OLE for Process Control)
  因为太多的数据库和DCS使用自己的API方式存取数据,无法做到算法的通用,因为提出了一个标准的存取接口,这就是OPC,如今有超过两百家产商加入到OPC组织中,声势浩大,包括臭名昭著的M$,之所以讲M$臭名昭著是因为M$强制性的在这个标准的存取接口中使用了COM/DCOM,令OPC只能在windows下使用,且效率(因为是工控场合,所以效率非常重要)低下。M$在OPC组织中非常的积极,所以现在的OPC基本上也脱离了当初制定的目标,令很多产商不满,包括OSI在内,虽然OSI PI提供OPC接口,但OSI不建议客户使用它,也不对它进行技术支持。在OPC中的COM还有另外一个大问题,因为COM规定必须支持先前制定的接口,而工控要求又非常严格,开发测试的费用和时间都非常高,没有任何厂商愿意支持先前的COM接口,因此没有真正符合COM标准的OPC。
阅读(62082) | 评论(333) | 转发(0) |
给主人留下些什么吧!~~

网友评论2012-11-15 15:53:25

Lixeon
多文档的好处在于:
1> 使在线数据量仅与磁盘容量有关。
单文件的大小,受制于操作系统。Windows下好像一个文件最大为2G(记不清了,反正是有限),而2万点的规模一年4到5G左右的数据量,一个文件就不够了,多文件可以充分利用磁盘阵列。

2> 历史数据调整的灵活性。
就像你所说的,留再大空间都不能保证100%不溢出。因而只能从统计意义上,留出20%的空间,保证80%的情况下不溢出。还有20%的情况下,就需要用PI提供的工具创建一个足够大的Archive文件来替换益处的Archive文件,新文件的起始与结束时间与原文件一致,然后将原文件从PI系统中注销,用Archive数据复制工具将原文件中的数据复制到新文件中,然后再把新文件注册到PI系统中。整个过程中平滑进行,不会对数据实时采集产生影响,因为新数据都是写到Primary Archive文件中。如果需要替换PrimaryArchive,那就先把PrimaryArchive切换到其他文件上。所以多文档在历史数据编辑、

网友评论2012-11-15 15:53:07

周星星
听君一席话,胜读十年书。
俺最近在编写一个实时数据库(玩玩而已),就对多文件存档很不理解,听了您的讲解,才知道“并非完全写满,为新插入数据留有一定空间”,这样我就茅塞顿开了,但是空间留多大才能100%保证不溢出,想来是没有办法的,我决定还是用单文件(不一定真正是一个文件,而是说所有文件是有联系的,不能独立开来)存储。

网友评论2012-11-15 15:51:55

Lixeon
PI的整个数据模型和数据流模型总体上和其他的实时/历史数据库差不多,数据处理和存储系统也是有基于内存的实时数据库(称为Snapshot子系统)和基于文件的历史数据库(称为Archive子系统)组成。而整个系统的关键就是两道压缩过程,也是整个PI系统的精华所在。

PI数据流的第一道压缩由个接口实现,接口程序调用具有压缩算法的数据发送函数,将数据在发送到PI前进行取舍,其算法基于相邻数据点的时间和数值偏差。经过通过压缩(即没被舍去)的数据发送到Snapshot(中间可以有一道缓存机制)。第二道压缩在Snapshot将数据发送到Archive时进行,以前叫“平行四边形压缩法”,前两年改名叫“旋转门”,一种基于数据点之间斜率来确定数据点取舍的算法。

Archive系统的由多个称为Archive的数据文件组成,一般这些文件都是固定大小的。一个文件写满(并非完全写满,为新插入数据留有一定空间)切换到另外一个文件,如此轮流,当前写的那个文件称为Primary Archive。每个文件都标有数据的起始和结束时

网友评论2012-11-15 15:51:40

WJH
我觉得您没说清楚两者的关系?
DCS系统的实时数据库在分布处理器的内存中,且一般只保存即时数据,所以不存在数据量大小的问题。您所介绍的实时数据库实际应该称历史数据库吧,请问怎样保证在从DCS取历史数据时,不影响DCS的稳定呢?毕竟要获得实时的历史数据就要有不断的请求在DCS中;请问PI的数据模型是怎样?请专家不吝赐教!

网友评论2012-11-15 15:51:28

Lixeon
还不是因为eDNA便宜,要是PI降价30%,哪还有eDNA的份。
都怪OSI不会做生意,OSI在市场方面就简直就是个弱智。