找回密码
 欢迎注册
搜索
热搜: 活动 交友 discuz
楼主: sbf2000

Cache系统数据类型剖析

[复制链接]
发表于 2004-7-21 12:27:13 | 显示全部楼层

Cache系统数据类型剖析

http://media.ccidnet.com/media/swm/188/09101.htm
王继中教授:中国医药信息学会M技术专题委员会主任委员

造成HIS系统脆弱的瓶颈问题主要有三点,其中最根本的就是数据库的选择不恰当。HIS初级产品的响应速度比较慢,而且还会随着使用时间的增加而逐渐衰减;另一方面数据库里的数据量增长得却非常快,曾经有医院惊呼自己的数据库信息每天在“海量增加”,三个月硬盘就满了,最后不得不清除数据,好不容易积累下来的医学信息也就随着垃圾数据一起清掉了。系统内积累的信息从医学统计学来看是非常宝贵的,如果能积累几年或更长的一段时间,就可以对这些数据进行医学统计研究,还可分析医院各个部门和环节的运行状态,研究如何提高工作效益、提升医疗质量和降低医药费用。

  目前国内HIS使用的关系数据库适用于如航空业等数据量巨大,但关系简单的行业,一旦应用于数据结构复杂的医疗行业就有点“捉襟见肘”。医院信息系统的复杂程度是外行人难以想像的,医院就像一个小社会,除了人、财、物,还有各种医疗信息,包括文字、图片、影像信息和许多的医疗设备接口,因此HIS被称为“最复杂的MIS”。一个医院信息系统一般可以拆分成几百张表,稍大一点的HIS系统有五、六百张的表甚至更多是很正常的。医疗环境中的数据关系异常复杂,要把这些复杂数据硬拆成那么多的表来塞进关系数据库就更不容易了。怎么设计关系表和索引?如何优化就成了设计中难以解决的问题,往往关系表的数量大到一定程度的时候,设计人员就失去了控制能力。

  事实上数据存到关系数据库里边基本上是个“黑箱子”,也就是说数据实际存储到哪个位置设计者并不清楚,也没法控制。当系统操作员从一个拥有五六百张关系表的HIS系统里检索数据时,就相当于把这几百张表“连接”起来,因此检索的速度很慢,而且取数据的时候还要对这些表加锁,这样就很容易造成死锁。

  王教授给记者讲了一个“闹鬼”的故事:天津一家医院的HIS系统每到下午五点就会很准时地出现性能问题,医院的医护人员称之为“闹鬼”。王教授去看了以后发现是系统软件总是试图去解开一个地方的“锁”,而这个地方实际上是没加过锁的,这样一来就形成了一个解不开的死循环,出错的原因就是所用的关系数据库软件本身出错,影响了HIS系统的正常运行。

  所以选用数据库不当是造成HIS脆弱的很重要原因,许多基于关系数据库设计的HIS系统初期响应速度还算正常,后来用户数越来越多,响应速度就会慢得令人难以忍受。有时用户在终端等待一个小时系统也不响应,检查原因时发现只是财务科在读一张大一点的报表。过慢的响应速度使医院方面怨声载道,而技术支持人员的日子也并不好过,某软件公司的HIS总工就对记者形容自己的状态是“战战兢兢,如履薄冰”。

  美国在HIS的建设初期中就了解到医疗行业数据关系特别复杂的问题,所以美国大量的HIS系统放弃了两维关系数据库,而多选用多维的基于M技术的树型结构数据库。因为这种数据库引擎用的是稀疏数组,事先不需要声明定义数据库结构,数据库的大小可以按需要自动增长,而且只有存放实际数据的节点时才会占用空间,不会像用关系数据库那样出现数据库数据无谓增加得很快的问题。

  根据国外医院所做的对比试验,采用多维数据库可比使用关系数据库节省硬盘存储空间三分之二以上,而且它的响应速度不会随用户数加大和运行期间的长短而出现明显的衰减。哈佛大学的Brigham & Women's医院拥有目前世界上最大规模的医院信息系统,所采用的就是基于M技术的多维数据库,该系统可支持6000用户同时在线,一年365天24小时不停机运行,系统照样可以快速响应。相比起来,我国医院里安装的HIS系统往往有一两百个用户同时在线就吃不消了。

 
您需要登录后才可以回帖 登录 | 欢迎注册

本版积分规则

快速回复 返回顶部 返回列表