我从事软件开发已经三年时间了,对系统分析一直存在着一种莫名的热爱,一直希望在这个领域有所突破,也是自己的一个突破,到目前为止,我参与的大型项目的开发也有几个,都已经被很多客户使用,其中我作为系统分析人员的是几个模块,针对题目所示的大数据量处理我在分析过程中主要从三个方面进行考虑:
表结构的设计
程序的性能
数据库的设置
对于大数据量的处理人们最关注也许就是操作时的性能问题,曾经在一次做医疗软件的开发过程中遇到过这个问题,我们要实现系统对多个医院病人的统一管理,因为许多医院在使用系统的初始阶段会有大量数据需要上传,并且需要对大批量数据进行增删查改等操作,在设计初期,我把解决性能问题的途径分了三个部分
1、表结构设计:表结构设计阶段,我们为了尽可能的减少表关联时可能存在的时间耗费,把数据存储在比较少表中,每个表针对查询时的主要查询字段,建立索引,加快检索数据的速度,
2、程序设计:在程序设计阶段,为了减少运行时间我没有采用任何OR-MAPPING工具,那些工具或许会使开发过程相对简单一点,结构清晰一点,但是它封装的如此完美,让我们被局限在了他的美丽憧憬中,迷失了自己,不再能随心所欲的驾驭我们的代码,而且它浪费了太多的时间在创造简洁操作的美景了,依据当时的需要,选择映射工具对我来说是得不偿失的,我采用了存储过程对数据表进行操作,利用存储过程可以减少数据库管理系统编译sql的时间,但是如果系统太大,太多的存储过程也不见得是个好的选择,还好我们的模块涉及的表并不多,算是一个比较小的子模块,在进行查询时界面显示进行了异步处理,多少个纪录就查询多少个,只有请求时才会进行下一步的查询,这样减小了请求的响应时间,也避免了把全部数据加载进内存的需要,变大数据为小数据处理,
实在程序实际阶段是最应该注重性能,也许就因为一个查询语句的设计不当,对性能就有将近几个数量级的影响,就查询来讲,先做连接再做选择就难以和先做选择再做连接在性能上相比拟
3、数据库设置:
我使用的是oracle数据库,数据库的设置也许适合大多数人的需要,但是并不一定是你所需要的,当时完成程序开发之后,我们使用loadrunner针对每个存储过程进行了性能测试,调整了共享池的大小,缓存的大小,使其与数据处理的频度和记录数量相匹配
对于数据库来说,进行操作时每次的获得数据库连接,维护每一个连接是相当浪费系统资源的,特别是对于web应用,而且获得连接后还要记得关闭连接,如果由于系统异常或者其他原因导致连接没有关闭,就有可能引起数据库系统的内存泄露,最终我们不得不重新启动服务器,如果使用全局connection的话,connection一直不关闭,但是,同一连接使用次数过多,就会不稳定,进而导致web server频频重启,所以我们使用连接池,它的宗旨就是预先建好连接放置于内存对象中以备使用,
这是结合项目开发经验做的一个小小的总结,不足之处还请指正