浅谈系统优化设计--复杂运算放在逻辑层还是在数据库层?

本文记录了一次回访客户过程中发现的问题:由于业务人员频繁调用复杂的对账存储过程,导致数据库服务器CPU长时间处于90%以上。文章探讨了解决方案,并对比了将复杂逻辑放在数据库层与应用层的优缺点。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

     前段时间,我们去回访客户,看了今年上半年优化的一个系统,看看性能怎么样。去了以后,客户反映感觉还可以,不慢,就是说这段时间数据库服务器的CPU有时超过了90%,会持续一段比较长的时间,可能有几十分钟。

     下午,就发现这时候数据库服务器的CPU一直在90%以上。通过sql server profile也没查出什么问题。觉得操作很正常,后来通过DMVs发现,执行我以前改写的几个存储过程,执行次数比较多,但是估计前台调用很频繁。

    后来通过他们的联系和交流,结果是:有不少业务人员在操作完数据后,再去查一次我以前写那几个对账存储过程(最多超过450行)调数据。

    这里介绍一下对账存储过程:

       以前因为将对账逻辑封装在JBOSS应用层,当时发现查询速度慢,一旦查询的人多,jboss的cpu就一直是100%,业务无法操作,但数据库服务器还好。后来我就将其全部逻辑封装在数据库层(4个存储过程,3个函数),速度比以前大大提高。

     注: 这里的对账有好几个角度,所以有4个存储过程。

    分析结果:      

       业务人员大量调用对账存储过程进行复杂计算

      开始我跟客户讲:这里的对账,是比较复杂的逻辑计算,是比较耗CPU的,一般使用的比较少,

       一个业务人员一个月查一次都不错了,而现在是下面10多人在持续调用。所以数据库服务器CPU一直在90%以上,但幸运的是客户的系统并没因为90%而引起速度慢或者是Down机情况,业务正常运行。

      经过这件事,我一直在想,复杂逻辑计算是放在逻辑层还是放在数据库层好啊?

   查了一下资料,解决复杂逻辑有:

         1,建立同步数据库,将读和写分离。(使用比较多) 如:淘宝网        

         2,将复杂逻辑计算放在逻辑层,当然SQL语句是经过优化过的(在逻辑层做集群服务,分成多台应用服务器JBOSS): 如 ebay   

     当然上面两个方法都有他的好处,看大家怎么使用了。我个人倾向第一种,将业务逻辑放在数据库层,也正如Tom在《Oracle 高效设计》提倡的尽量使用数据库来提高性能。

转载于:https://www.cnblogs.com/zping/archive/2008/11/18/1336254.html

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值