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

当今国际国内广泛使用的实时数据库只有三个产品:
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。

评论列表
USER
re: 实时数据库的简介(初稿)
谢谢周星星的文章,非常好且非常有用。

我想问一个问题:
现在OPC接口可谓来势汹汹,并且PI也提供OPC接口,如果PI对其不提供技术支持话,是否还选择这个接口?
能客观平均一下其OPC接口和专用接口之间的区别吗?
周星星
to USER:
:)我的评论很难客观,但我尽量做到客观吧
1. 仅仅对于实时数据库,那么使用OPC并没有太多的优势,因为实时数据库就这么几种,而且价格昂贵,更换的可能性并不大;对于众多的DCS而言,使用OPC的优势不言而喻。
2. 专用接口的缺点是不统一,这种不统一反映在编码上的复杂度是指数级增长的。比如写一个从A DCS到B DCS的程序,如果DCS有10种,那么就需要写10*10种不同的代码。
3. OPC的缺点有下几个
a. OPC 发展的过于离谱,现在的OPC是什么,很难说;这是任何一个做大了的技术免不了的通病,什么都想囊括进来,最终腹胀而死。
b. OPC 服务器开发困难,因为COM要支持以前的荒废了的COM接口。
c. 客户部署困难,需要安装太多的COM
d. OPC的安全机制使用的是DCOM的安全机制
user
re: 实时数据库的简介(初稿)
谢谢您的点评!
周星星
to PI:
有什么问题就说嘛,俺欢迎不同意见!^_^
周星星
to ggg:
:)欢迎不同意见!
不过本文确实肤浅,这只是一个实时数据的简介,不得不肤浅呀。
判断一个数据库的好坏无法就是
a. 性能
b. 价格
c. 提供的操控接口
您还希望能有什么其他信息?
快乐浪子
re: 实时数据库的简介(初稿)
现在国内有些行业用的是配置oracle等大型商用磁盘数据库来实现将部分或者全部数据cache到内存来满足实时要求,比如广东网通;还有的是自行开发的实时数据库,采用的是自行开发前端的实时数据库同时配合后端的商用数据库来实现的,比如我接触的这个厂家的调度自动化系统,说是自行开发的具有c/s结构的分布式实时数据库系统。以前接触的一个公司的产品据说也是自己开发的实时数据库;我查了一些资料,对自己开发实时数据库还是一头雾水,大部分都推崇的是内存数据库来实现,不过我还是一窍不通,不知星星有没有这方面的研究或实践?
周星星
to 快乐浪子:
我对实时数据库的原理不清楚,PI采用旋转门等有损压缩技术来实现数据的存储,当然不仅仅如此;内存是肯定需要最大限度的利用的,但PI的吞吐量非常的大,仅仅依靠内存肯定不行,一定有自己的独门算法。
PI数据库的平均价格是1,500,000元,可见实时数据的利润很大,但既然能买到这么高的价格,肯定技术含量一定很大。
topgrass所在公司也有自己的实时数据库,名RealMIs.
物以希为贵
re: 实时数据库的简介(初稿)
你用过分布式实时数据库系统么,中科软件所的Agilor2.81
阿昌
re: 实时数据库的简介(初稿)
我正在做这方面的研究
不知道各位对实时事务在windows nt下的调度了解不
有兴趣跟我联系
lwc348@163.com
周星星
re: 实时数据库的简介(初稿)
看来大家对实时数据库比较关心,我现所在公司考虑到PI过于昂贵准备换另一家美国公司的实时数据库,我现在还不知道是哪一家公司,到时候再一起讨论。
物以希为贵
re: 实时数据库的简介(初稿)
你们有没有考虑过中科软件所的Agilor,便宜又使用
吴孟达
re: 实时数据库的简介(初稿)
我用过,的确不错。
mm
re: 实时数据库的简介(初稿)
我也是因为工作机会刚接触PI, 的确不错。美国的wonderware公司是否也有这种实时数据库产品呢,有谁了解,请多多指教。
周林
re: 实时数据库的简介(初稿)
楼主对INFOPLUS.21的认识的确有问题,我从事IP.21的项目4年多了,使用的IP.21从V2.5到V6.0,我还没有发现楼主所说的一些问题。可能是安装技巧的问题吧!

下次有机会与大家交流PI和PHD,我对PI和PHD不是很了解,但IP21还是熟悉。欢迎大家交流。我的E-MAIL:FETCH2008@VIP.SINA.COM
周星星
to 周林:
在上次那个项目中用的是6.01版本,它对中文支持有很多问题;这些IP21是AspenTech为了打开中国市场而先期赠送给中石化集团的;安装数据库的人也是AspenTech自己的员工,个人觉得他有点猪头。
阿刚
实时数据库
不知大家的系统为何要用实时数据库,用到了那些实时特性呢,总该不只是速度较普通数据库快吧,有关事物的实时调度,事物截止期,过期数据处理等不知是否也用到了。我正在做实时嵌入式数据库方面的研究,希望收集一些需求,与大家一起探讨这方面的问题。
周星星
to 阿刚:
在生产制造行业中,数据的实时存取很重要,正如你所说,实时数据库就是一个字“快”,比如PI,快到每秒可以有百万的数据流量;高压缩,一只普通容量的硬盘可以保存8年的数据,当然要配置正确。这种高速度高容量不是普通数据库可以胜任的,如果用Orcal的话,这样的流量只需要几秒钟就使之崩溃。

生产制造行业为什么需要“实时”我就不多说了吧,比如电厂,如果一个重要的阀门的状态很久都不传过来,可以就会紧急制闸,损失是巨大的;还有,这种行业的生产过程计算机程度化比较高,如果慢吞吞的从数据中取得数据再去分析的话,就没办法指导机器的下一步行动。

实时数据库与关系数据库相比,从名字上可以看得出,实时数据库重在数据的实时,关系数据库重在数据的关系,对于实时数据库中的数据,它们的关系是很复杂的,需要用到很多的科学计算和公式翻译,这是SQL查询语句做不到的,因此实时数据库基本上也不提供这种关系的查询。

嵌入式系统上也有实时数据库,我是第一次听说,因为实时数据库对机器的性能要求非常的高,所以一般都运行在小型机上。
flybear
re: 实时数据库的简介(初稿)
请问您有详细一些的PI数据库介绍吗,包括系统规模,部署时间和代价等等
gu
re: 实时数据库的简介(初稿)
能仔细讲讲旋转门压缩算法吗?或者能否提供相关文档?
物以希为贵
re: 实时数据库的简介(初稿)
请问如何跟你联系呢

偶的信箱june1105@vip.sina.com ^_^
Tiger - Beijing
re: 实时数据库的简介(初稿)
Tiger_1999777@msn.com

1. OSIsoft正在淡化PI的概念,严格来说2000年后PI就不叫实时数据库了,现在OSIsoft推出的是实时企业智能化解决方案RtPM,PI实时历史数据引擎是RtPM中RtBaseline的一小部分。只是国内现在看来还没到那个阶段:) 国内电力行业用PI作为企业实时数据库的比较多,石化用的不多,其他行业就更少了,主要还是一些合资企业带进来的。PI的价格其实一直比较稳定,面向的是高端客户群,若比较性能价格比的话,PI明显优于PHD和IP.21,变来变去的是OSIsoft在中国的政策。OSIsoft是OPC基金会的成员,主要在OPC内部制定HDA的标准,没有听说过OSIsoft不支持OPC接口,OSIsoft的OPC接口是其版本更新速度最快的一个接口。

2. Honeywell曾经是OSIsoft公司最大的集成商,80年代至90年代初期,通过Honeywell销售的PI比OSIsoft自己销售的PI还多。Honeywell现在卖PHD的目的不是帮助DCS的销售,而是Honeywell在石化行业的信息解决方案,如APC等需要一个实时数据平台的支撑,靠卖PHD,Honeywell是不能存活的,事实上用户如果买Honeywell的APC等应用,PHD可以免费,不过羊毛出在羊身上,再说要是用了PHD,最好就一直买Honeywell的高级应用了。

3. Aspentech的IP.21和Honeywell的PHD定位一样,靠卖IP.21,Aspentech也活不了。Aspentech产品线很长,几乎都是靠收购来的产品,买来后整合难度很大。IP.21也是Aspentech买来的产品,原来是SetPoint公司的产品,现在IP.21维护更新的开发队伍也就几个人,没准哪天IP.21赔的太多,这个部门就砍了。

总结:OSIsoft卖PI赢利,在实时数据处理方面是越来越专,越来越深。Honeywell和Aspentech卖PHD和IP.21赔本,现在在实时数据库技术上吃老本,商务上是能黑就黑一把,最好是买他们的一体化解决方案,永远上他们的贼船。
Tiger - Beijing
re: 实时数据库的简介(初稿)
Tiger_1999777@msn.com

PI的价格

从50万左右起~200多万都有
周星星
to Tiger_1999777:
谢谢 Tiger - Beijing 精彩的回复,我现所在公司又尝试了 Matrikon 公司的 Desktop Historian 实时数据库,正在尝试中。
tempusno1@hotmai
re: 实时数据库的简介(初稿)
我是了解周星星的,其对COM技术很反感,
不过其对各个数据的评论确实我也很同意,用过的几个中比较PI确实很简单,而且其各个方面的技术都比较全面,其一,ACTIVEX的WEB支持中可以发现其技术已经很完善,而且整个软件系统之间的规划很好,让人用的很舒服,
但PI还是有些缺陷,其WEB都是机器直接通过本地的API与服务器连接,这样过多的用户浏览时候会造成服务器负担,
还有用户访问大量历史数据时候对服务器也是一种负担,
当然这些方面OSI已经解决了一部分并使这些缺陷不影响PI的使用
顺便提一下,PI对数据压缩确实强,其算法压缩数据量很大,有一套完整的数据压缩算法,从其累加点的计算上就可以看出,
不过PI确实贵
周林
to 周星星
周星星提到:
在上次那个项目中用的是6.01版本,它对中文支持有很多问题;这些IP21是AspenTech为了打开中国市场而先期赠送给中石化集团的;安装数据库的人也是AspenTech自己的员工,个人觉得他有点猪头。
-------------------
回答:
1、IP.21的确对中文支持不是太好,V6.0还是英文的,打上V6.0.1的补丁后才是中文界面。
2、其WEB使用效果也不是太好,V6.0存在严重的内存泄漏和WEB21服务挂起等问题
3、IP21一直也在走上层路线,呵呵,从中石化集团公司入手,这我有些了解。
4、我所知道,ASPEN原来在北京是代表处,一些圈内的人士我认识,主要是销售其产品,IP.21 在国内没有真正的技术。目前ASPENTECH刚刚在北京成立公司,所有即使你提到的‘AspenTech自己的员工’来安装,我也对其实际的IP21新版本的工作经验不敢妄加评论。我所知道的IP.21的实施主要是国内几家公司在做:上海申迪、北京华创、北京三维,中石化盈科,其他我就不是太了解了。所以这些单位实施的最终用户和上述公司的技术人员比较熟悉IP.21。由于不了解你提到的项目,所有我不敢评论。
5、顺便说一句,我原来在扬子石化工作,后来辞职到北京工作。一直做IP21项目的实施,所有从V2.5到V6.01的版本一直在用,目前还在做IP21项目。

希望有机会与你交流我不熟悉的PI和PHD!
周林
to 周星星
你所提到的项目可能是 中石化的‘沪宁甬’项目,果真如此,那我就知道‘AspenTech自己的员工’是怎么回事了!呵呵
周星星
to 周林:
^_^ 是沪宁甬项目,看来你是前辈了,失敬!
沪宁甬项目有很多公司参与,而我现所在公司有不少猪头,……,为了避免被人耻笑,所以我没参加沪宁甬项目。

我觉得安装IP21需要硬件狗实在没必要,它有三个缺点:
1。使得安装变得特别麻烦。
2。使用IP21都是些大公司,即使有盗版,他们也不会要,因为盗版没有售后服务。
3。假如有公司想使用IP21应该怎么办?如果他花费巨资买了IP21发现不是他想的那样,他就亏大了,为了不吃亏,只要不要买。所以要不提供演示版,要不闭一眼,让程序员可以拷贝使用,假如没有其他公司的程序员会使用IP21,那么只有AspenTech只能自己孤单的推销IP21。
周林
to 周星星
前辈谈不上,过奖了!
希望能有机会与你交流IP21并向你请教PI与PHD的知识。

IP21在V3版本以前是不需要硬件狗安装的,只是使用一张LICENSE软盘,所谓的序列码,V3.0及以后的版本一直使用狗,不过很丑陋,只是安装时需要,实际运行就不需要了。当然很麻烦!
其实IP21有不需要狗的LICENSE,当然紧紧供内部人员使用了。

其实ASPEN的售后支持一直是新加坡的支持中心在实施,而且也只有最终用户有权利得到技术支持,实施单位是无法得到支持的。除非有合法的帐号,所以也很苦了这些实施单位了--发现BUG导致项目拖延......。

总体来说,只要你是合法的用户,同时购买了ASPEN的服务(一般软件含一年服务,一年后要另外购买),网上的技术支持还是很快的,2小时内一般有响应。当然,一般的技术问题很快老外就可以告诉你解决的方法。但重大缺陷的地方还是拖着。我有个项目,WEB21总挂起,同时存在严重的内存泄漏,半年多了,老外一直没有解决,TMD急呀!


tempusno1@hotmai
re: 实时数据库的简介(初稿)
破周星星,留点口德,别评论我们公司的其他人,呵呵。
恩,周林很厉害啊。另外我觉得老外的技术支持也挺麻烦的,搞不定就两边差开了,老外回答的不是你要的,一个来回一个工作日就没有了。
Tiger - Beijing
re: 实时数据库的简介(初稿)
Matrikon的产品比较尴尬哦,另外他们的Desktop Historian(原来叫OPC Historian)实在是太小了,,曾经Matrikon是PI在加拿大最大的系统集成商,2002年因为门户问题两家还打了场官司:(,现在两家是彻底掰了,Matrikon的数据库产品不适合和PI等产品进行比较,其实Matrikon现在卖IP.21和另外一家公司的产品。
周星星
to Tiger:
谢谢,原来 Matrikon 是这样呀!^_^,看来便宜没好货!
kkk
re: 实时数据库的简介(初稿)
全都是250,
你们除了会配标准接口外,还会什么?
会开发接口吗?一群蠢猪。
不要做半瓶醋,回家多看点书,好好学点。

AspenTech的猪头
kkk
re: 实时数据库的简介(初稿)
听说周林自己开公司了。是不是还想做Honeywell的Uniformance何OSI PI的代理开发?
周星星
to kkk:
啊!
“配标准接口”和“开发接口”是什么意思?我只写代码跟实时数据库交换数据,连数据库的安装都没做过;自己也想编写一个实时数据库,可没人出钱请我做,也没人买,嘿嘿!因此我既不是“会配标准接口”,也不是“会开发接口”,再说,我只对编程语言感兴趣,不对开发出来的产品感兴趣。
csun
re: 实时数据库的简介(初稿)
实时数据库要从dCs系统中取数据把,接口就是编程让实时数据库能从dcs中取得数据.
csun
re: 实时数据库的简介(初稿)
有人写过OPC-PI的接口程序么,想知道流程是怎么样的
好像设备的OPC服务器是由
OPC厂商提供的,客户端是不是需要自己开发?如果开发SDK到哪里找呢,有没有免费的API可以用那?
周星星
to csun:
我写过西屋的一个产品的OPC客户端,发现西屋OPC服务器有不少Bug,看来印度阿桑只能写写破MIS,技术要求一高就开始胡来;
PI的OPC客户端没写过,因为使用PI API操控PI比OPC方便很多,个人还是觉得OPC太烂,不用为妙;OPC其实是通用的,我用给西屋编写的OPC客户端一样可以去IFix中取数据。
CSUN
re: 实时数据库的简介(初稿)
你的API哪里来得??有免费的么
我只能找到收费的
如果可以不知道可不可以把你的程序给我看看
我得msn是gthr_8@hotmail.com
希望有机会和你交流
周星星
to csun:
说实话,我不太明白你的意思,PI API就是 PI 的应用程序接口,它怎么会有免费收费之说呢?
PI提供一个PIAPI32.DLL文件,通过它访问PI数据库,所以只需要拷贝它到客户端就行了,相关的文件如下:
piapi.h
piapix.h
piba.h
pidefs.h
pisql.h
PIAPI32.DLL
piapi32.lib
API全在这些.h文件中定义着。

程序是不能给你看的,不是我小气,而是怕公司某些人有意找我麻烦,这里告诉你一个最简单的流程:
piut_setservernode 设置PI服务器,参数计算机名称和端口号
piut_login 登陆PI,参数用户名、密码、权限[out]
pipt_findpoint 根据名称找点
pipt_pointtype 根据点找类型
pisn_putsnapshots 向PI写数据
csun
re: 实时数据库的简介(初稿)
我说的是OPC的API呵呵
csun
re: 实时数据库的简介(初稿)
用PI的api开发我也写了不少了,最近可能要做DCS到PI的接口不知道用OPC好还是用厂家自带的驱动,从DCS取数据的流程是什么样子的我也不太清楚,呵呵
周星星
re: 实时数据库的简介(初稿)
介绍 “工控论坛-OPC论坛” 给你:
http://www.gongkong.com/tech/forum/list38.asp
ALB
re: 实时数据库的简介(初稿)
哦,第一次找到讨论PI实时数据库的论坛。我在工作中要用到PI数据库,很想和各位交流和交换技术文档
beejoy
re: 实时数据库的简介(初稿)
今天是第一次认识了实时数据库(能不能称作RTDB?),原来我还以为Oracle已经很实时了,因为Oracle与SQLServer比较起来实时性能好多了。而且因为也是刚接触过BerkeleyDB,又觉得BerkeleyDB也是RTDB。

我想请问一下实时数据库的统计分析功能是如何实现的?这是利用用户的二次开发实现的,还是数据库内置的?
如果是内置的,那实施数据库的开发公司岂不是要针对很多不同的行业设计很多不同版本的数据库?
如果是二次开发的,那么二次开发后的应用软件效率如何保证?因为二次开发人员不一定是实时数据库的专家,那么二次开发的软件就可能成为RTDB的瓶颈?
周星星
to beejoy:
你问得真好,估计这就是关系数据库和实时数据库的差别了。
“我想请问一下实时数据库的统计分析功能是如何实现的?这是利用用户的二次开发实现的,还是数据库内置的?”
应该是两者皆有吧,PI数据库有对一段时候内数据求最大值,最小值,均值等的内置实现,不过实时数据库毕竟不是关系数据库,数据之间的关系还是需要自己去计算。
tempusno1@hotmai
re: csun
从DCS取数据,说的太含糊,你是从DCS中取,通过485接口读DCS内部数据,还是通过该DCS的组态软件获取组态中的数据,当然该组态软件的数据也是从DCS中取得
我想一般是从组态软件中取数据
然后再了解该组态软件有没有对外得接口,如西屋得WPDF是Socket,OVATION是OPC,IFIX有ODBC和DDE,高版本得IFIX是OPC等等
冰火仔
re: 实时数据库的简介(初稿)
不知周星星为何方神圣,哪位能给个介绍
周星星
to 冰火仔:
我知道 ^_^
周星星是南京一家无名公司的一个庸才,满腹牢骚,借Blog以发泄。
跟他谈ASM/C/C++可以,谈MIS/ERP就免了。
冰火仔
re: 实时数据库的简介(初稿)
我看你他对PI很有研究哦,能否交流交流。小弟我一直干着安装/卸载PI的工作。
周星星
to 冰火仔:
不明白的问,PI的安装/卸载是非常简单的事,难道还需要专业人士来做这项工作?估计是我孤陋寡闻,我觉得PI管理中最重要的事是确定标签点的Zero、SPAN和偏差,这是影响PI效率最大的部分,但这项工作又需要很强的行业知道,比如主气温度,对一个非电力专业的人而言,是不可能知道温度偏差多少是不重要的。

顺便问几个问题:
1。PI中有根据一组标签名称取一组标签id的API吗?
2。PI中根据标签名称取标签id的API的执行速度特别慢,为什么不建一个hashtable来加快索引速度?
3。PI内部的数据是big-endian,还是big-endian?她是怎样做快速转换的?因为我觉得PI for win比PI for Unix效率还高,自认为是byte order的原因造成的。
1 2 3 4 5 6 7 8 下一页共8页  到第

发表评论
切换编辑模式