|
xuan19900414 发表于 2014-9-16 14:58 ![]()
“以我三甲医院运行CACHE6年的经历来说,CACHE确实不太适合中国大规模三甲医院使用。数据复杂度高,标准多 ...
1. 性能问题:
现在不到4000万条记录,1.5T的信息量,CACHE都会速度超慢。查询3个月以上的数据就会死掉。别相信那些CAHCE市场材料宣传的东西。医院系统的复杂性不在绝对记录数量,而在高度的复杂度。
Z:下面也是一个测试基于Caché设计的HIS系统,测试时间地点:2009年7月13-24日 英国。使用IBM HS22,每一个是two quad-core Intel Xeon 5570处理器,一共8核。操作系统64位RedHat LINUX 5.3, Caché2009.1.
使用单服务器配置:8核数据库服务器,数据库平均1,190,000次访问/秒,高峰2,021,000次访问/秒
使用多服务器配置(使用ECP技术): 1个服务器:数据库平均992,000次访问/秒,高峰1,690,000次访问/秒
4服务器:数据库平均4,100,000次访问/秒,高峰6,165,000次访问/秒
8服务器:数据库平均8,900,000次访问/秒,高峰16,900,000次访问/秒
2. 一旦上线,分库困难。
数据库越来越膨胀,速度越来越慢,最后小型机用了四年后都不够用了,还得升级小型机。我们医院当年购买ibm小型机可是很快的,可是都赶不上膨胀的速度
Z:分库可以使用global mapping, 方便把数据拆分到不同的物理/逻辑服务器,完全不需要对应用做修改
3. 死数据。
由于OO架构限制,如果对象做了修改,而且又已经有了实例数据,那么这个对象不能进行删除(我是指业务上),时间长了之后,导致垃圾逐渐增多,不少已经定义的实例,导致速度慢,错误多。如果曾经做过OO编程的人,考虑一下定义n多对象并且有两大数据之后,突然要你修改某层对象架构(很多时候还是翻天覆地的变化)的时候,那种感觉和心情。
Z: OO数据库的优势也体现在对后期数据的修改上:随时根据需要删除修改添加字段,我可以很负责说上面提到的有了实例数据造成对象不能删除是完全不可能的。
4. 锁定:Cache的数据库锁机制及其弱智,懒得说。
好在医院的数据多是增加,很少有删除的情况,要不早出现很多乱子了。问了几家大型his公司总工级别的人物,对于锁都答非所问。让人心寒。
Z:Caché是基于Global节点的保存数据,其中的锁机制更是可以方便的定义只锁其中的某个节点,对比与其他的锁住整个表,带来更大的灵活性和性能优势。
5. 基于OO的数据库并不成熟。
在我多年使用中,感觉不如 RDB + XML的混合方式解决方便。OO非常适合抽象,但是如果这个对象经常都在改,那简直就是生不如死了。有人会说,对象会经常改吗?——那到医院来看看吧。随着医疗信息化的深入,需要改的地方只会增多,不会减少。我们从基于cache信息化厂商那里得到的“不能”已经越来越多了。
Z:OO编程OO存储为什么不能随便更改呢,带来的只能是更加快捷吧。
6. 资料匮乏:
使用的人少,资料奇缺,人材很少。自带的CSP界面极差,功能很弱。编程语言晦涩难看,一点都不优雅(这点是个人意见),上网能找到的文章都是枪文,我从来没有在中文网上找到什么非常深入的cache数据库分析文章;公司实力有限(相对于ms,oracle),一个CSP溢出漏洞都要改半天。没有大量的人使用,金子也会变成垃圾。
Z:确实只有英文资料,不过公司正在努力汉化中,2014.2版本界面基本上都是中文化了。
7. 不知道那些枪文里边写的安全性很高是什么意思?我看了半天DOD TCSEC的档案,抱歉,没有发现CACHE的影子
Z: February 15, 2007, Caché received certification according to the Common Criteria standard (EAL 3).
8. 数据迁移问题。
现在很多系统,基于RDBMS的,例如oracle、ms sql server 都很容易切换,但是如果转入cache,就像上了贼船,上去容易,下来难了。想后悔都没有机会。不是说绝对不能转换出来,而是很多困难。你没有失败的backup.
Z:这个是设计的问题吧,同样的编程数据层、逻辑层看怎么设计了。
9.互联问题。
现在健康档案互联,区域医疗信息化等,都是时代发展需要。懂行的人自己考虑一下其中难度,不懂行的人说了也是白说”
Z:互联可以参考另一款产品:Ensemble |
|