|
|
[这个贴子最后由danelchen在 2002/10/10 12:18pm 编辑]
医院信息系统海量数据存储策略研究
北京协和医院 李包罗 马琏 许燕
北京众邦慧智计算机系统集成有限公司 张蕾
[摘 要]
医院信息系统内积累数据及用户需求的无限性与计算机时空及技术资源的有限性是一对矛盾。一旦系统投入实际运行，系统的开发者和用户或迟或早总要直接面对这一矛盾并不得不解决它。本文从实际出发，分析了医院信息系统内数据增长的规律和构成特点，讨论了解决这一矛盾的几种策略，它们的优点，缺点和实现的方法。全文均以在北京协和医院成功地运行的CHIS为实际例证。
[关键词]
医院信息系统 数据库 存储 数据结构
--------------------------------------------------------------------------------
一、 引言
北京协和医院是中国医学科学院附属临床医院，是我国著名的、高水平的综合性医院。以西医为主。有900张床位，每年有近二万出院人次，平均住院日16天左右。日门诊病人3500人，产生门诊收费凭单5000张。是我国一家典型的大型三级甲等医院。
北京协和医院自1997年开始建立可覆盖全院的计算机网络，逐步地安装运行北京众邦慧智计算机系统集成有限公司开发的集成的全院级医院信息系统CHIS，用新系统替代该院已运行多年的基于Xbase的分散式的部门级管理信息系统。新系统是基于客户机/服务器体系结构设计的，服务器为一对HP LX3 型机，四个CPU，512M内存，RAID5 28G磁盘阵列，运行Windows NT 4.0。数据库选用MS 的SQL Server。客户端通常采用Win98加PB开发的应用软件，只有门诊收费窗口为了速度选用了DOS和C语言编写的应用软件。
到目前为止，新系统已布网口一千多个、上线已近二百台微机，14个子系统，计有门急诊化价收费（20）、病房医嘱处理（62）、住院病人ADT（16）、药品管理（中西药库、中西药房、门诊药房发药、病房药房发药、摆药（26）、财务（10）、医技科室（16）、检验科（14）、公费医疗（3）、改革办（2）、后勤物资（2）、统计室（1）、系统支持与开发（10）。其中占用存储较大的门急诊化价收费系统于1998年底全部上线，病房医嘱和住院病人ADT于1999年11月中旬全部上线。
随着海量随机存储器（硬盘）价格的下降（目前大约500元/1GB），今天的软件设计人员已经不再把主要注意力放到如何节约存储空间，而是更多地注意系统的响应时间、可扩展性、功能的完善与客户友善性，甚至包括程序编制的简单化。处在今天的环境去想二十年前的程序员为了节约二个字节的存储空间而引发今天的全球性的Y2K问题，实在有点滑稽可笑。然而，正是由于人们不再吝啬磁盘空间，这又反过来导致信息系统数据量膨胀的过快。象目前北京协和医院的系统，以管理为主，仅仅是数字和字符类的数据，1999年12月一个月的数据增量（包括索引等系统开销）已经达到1,230MB就是证明。
从本质上来讲：
1 任何一个医院信息系统，只要一旦投入实际运行并且不间断地运行下去，机内累积的数据如果不做特殊处理就会无限制地增长下去 l 用户对数据的需求也是无限的，某收款窗口要为数月前结帐的病人退款和重新结帐；某临床医生要查看二年前一个病人的医嘱；一位医院管理工作者可能要求对某项特定收费项目进行十年的回顾总结性研究；
2 无论海量随机存储器（硬盘）价格如何便宜，但任何一个具体系统的磁盘容量总是有限的；也就是说，系统的空间容量是有限的 l 众所周知，表越大，读插改的速度越慢；库越大，维护起来越困难，越费时间，出问题的概率越高；也就是说，系统容许的响应时间是有限的
3 程序员喜欢简单的数据结构，因为这样会使程序简单，从而节约系统开发资源；就是说，为了节约时空资源，设计过于复杂的数据结构，并不总是上算的
因此，如何平衡这些互相矛盾的因素，那些是应该满足的，那些是可以满足的，那些是在一定条件下才能满足的，那些是无法满足的。如何找出科学经济的方法，合理地解决无限需求和有限资源间的矛盾。这就是本篇论文的目的。
二、 分析
图1和图2分别展示了医院1999年全年（以周为间隔）和1999年12月（以天为间隔）数据库中数据变化的情况。
图1展示的趋势提示：
1 自1999年第26周到52周的半年时间内，系统内累积数据从2,034MB增长到6,685MB。增长了4,651MB，平均月增长为775MB。
2 自22周开始，连续四周陆续完成了从数据库中清除1998年过期门诊数据的工作，使得数据库增加了2.5GB以上的可用空间。
3 1-22周的良好线性表示了门诊数据量的增长趋势，大约每周80.5MB，每月338MB。
4 26-52周曲线的非线性增长是由于在此期间有越来越多的病房完成上线，直到十一月中旬。
图2的趋势曲线提示：
1 在完成全部住院病房上线后，数据量的增长呈现较好的线性。
2 全月数据增量最大，达到1,230MB，日增量约为40MB。
3 明显看出周末数据增长平缓
4 十二月最后一周曲线趋于平缓大约和临近新年假期有关 由此可以得到结论，CHIS系统运行于北京协和医院规模的医院，为保持一年完整数据的处理能力，需要的实时数据库空间为15GB。如果容许仅保持半年的实时数据，则8GB的数据库容量就足够了。
虽然CHIS集中式的数据库中包含六百多张表，但有些表的大小是不变的（像250张字典表），多数表（例如财务凭单、药品入出库记录、住院病人首页和入院记录等）一年的增量不过几百条到万八千条记录，真正可称为海量数据的年增长百万上千万条纪录的表只有有限的几个。解决海量数据的存储问题实质上就是解决这几张表的存储问题。表1列出了这几张表的名字、记录数和大小。图3展示这些表所占空间的比例。
从图3可以清楚地看到:
1 仅仅七张数据增长最快的表已占全库数据量的91%
2 每张表均包括数据和索引
3 由于住院病人各系统11月底才全部上线， 因此5，6，7三张表一年的实际数据量应该是当前的三倍
可见， 只要处理好表1所列七张表，就可以有效地控制整个系统的数据增长问题。
三、 综合使用海量数据的策略
3.1 CACHE 表 ( Cache Table ) 高速缓存技术是计算机软硬件设计中经常采用的技术。其基本思路是：被处理对象集合中并不是所有元素被选中处理的概率都是一样的；将概率大的元素放在处理速度高的缓存区内；处理逻辑是先处理高速缓存区中的元素，如果高速缓存区中没有该元素，则从海量低速区查找； 将高速缓存技术的思路用于门诊和住院病人记录。虽然每年系统要处理100万门/急诊病人记录（费用细目则高达500万条），2-3万住院病人记录（收费细目高达1，000万条），但对系统来说，对这些病人数据的处理频度是很不相同的。把门诊病人分为七日内就诊病人和七日外就诊病人，显然七日内就诊病人数据的重复使用率要高（统计、结帐、纠错、查询、补票等）。七日内就诊病人的数据大体是一个常量，对该组表的操作（读、改、插）就不会因为这些表的无限制增长而越来越慢。类似地，我们也把住院病人数据表分为在院病人和已出院病人二组，在院病人的数据会被频繁使用（与已出院病人比较），由于在院病人人数要大大小于已出院病人人数，所以，绝大多数情况下，大大加快了数据处理速度。 把实时表（Cash Tables）中的数据转移到海量表，通常采用存储过程和批任务的方法。例如门诊病人的数据，每天夜里1：00am把前一天的全部数据添加到海量表，同时删掉实时表中七天前的数据。实时表成了一个有七天延迟时间的先进先出的栈。显然，超过一周时间间隔的统计分析要对海量表进行，但此类操作的实时性要求比起窗口业务要低的多。 这种方法的缺点是使得数据结构变的复杂，一个表分裂成两个表，一组表分裂成两组表，写起程序来费力、费时，但这是值得的。 实现对二组表处理的转换，不外乎二种方法：一个是靠程序透明地自动地转换，另一个是靠用户手工切换，依赖于处理环境和需求的不同，程序员各有不同的选择。 这种方法虽然能解决系统的响应速度问题，但并没有解决数据量快速膨胀，最终会撑满整个数据库和磁盘空间的问题。
3.2 过期库 ( Out of Date Database ) 由于实时操作的数据库（我们称之为Active Database）容量总是有限的，我们需要建立另一个数据库-过期库。过期库中保存门诊病人和住院病人的过期数据。过期的定义依赖于不同的医院和不同的业务，当然也依赖于资源的多少。
实际实现需要二组软件的支持：
1 要能够按用户意愿把过期数据移到过期库，用户可以选择时间界限，选择门诊病人还是住院病人，要保证数据的完整一致性。要提供复制、移动和删除多种手段一次性或分次地完成转移，要十分注意海量数据处理时日志表的容量问题。过期库中的过期数据只能采用删除的手段。
2 要为用户提供专门的软件模块实现对过期数据的处理，包括检索、查询、统计、删除等操作。由于过期库中只有少数数据表（图三所示七张表），没有大量的辅助字典和相关表，因此，此时无法用修改INI文件连接参数的方法，利用已有程序完成检索、查询、统计任务。 过期库可以解决实时数据库的无限膨胀问题，但它依然无法解决有限的磁盘容量问题。 清除过期数据当然是限制实时数据库的无限膨胀，节省磁盘空间的简易手段，但众所周知，长期积累的原始数据是医院的宝贵财富，随便丢弃，实在可惜。
3.3 归档库 ( Archive Database ) 归档库是指某一时刻实时数据库的备份，该备份准备长期保存。它可以特殊命名（例如冠以年号）的数据库形式存在在联机磁盘上，也可以DUMP文件的格式存在磁带上。通常归挡数据库总是在年初（如果磁盘资源过少，也可能年初、年中各一次）转移过期数据到过期库之前进行。 由于归档库是实时数据库某一时刻的备份，因此它包含有一段期间内系统所拥有的全部信息（例如一年内）。如果归档库是以数据库形式存在在联机磁盘上，我们只需要把INI文件中的数据库连接参数指向该归档库，时钟立刻倒流到"快照"的那一时刻，系统的全部功能均可实现。如果归档库是以DUMP文件的格式存在磁带上，在使用它之前，必须将其装载到磁盘的数据库中，8GB的库可能需要几十分钟。 如果医院有足够的资源和需要，可以把过去几年的归档库均分别建立在磁盘上，用户使用起来会既便捷又方便。 因为有磁带保留归档库的手段，归档库可以解决磁盘容量不足的难题。
3.4 备份库 ( Backup Database ) 备份库是实时库的复制品，它要尽可能地与主库动态地保持一致，其主要目的是保证主库发生故障或损坏时，它可以被用作替代品。
为了使主库能够更有效率地支持窗口业务，我们常常把不含INSERT和UPDATE操作的费时的统计、分析作业安排在备份库上执行。 保证数据的安全性是备份库的主要作用，但这超出了本文的范围，不再赘述。
图4展示了CHIS系统综合使用海量数据策略的示意图。
表2给出了使用不同的方法处理海量数据时各自的性能特点。当然，十全十美的方法是不存在的，设计者只能按照需要恰当地选用。
|
|
发表于 2002-10-10 11:43:41
