在web网站中大量采用存储过程性能讨论

dap570

这个帖子再来点碰撞+花火 基本就可以受"精"了 : )

其实未必都有那么高的并发哦,
没有那么大的并发 也就不需要去考虑得那么精细了, 精细化的应用会消耗高昂的人力 物力 财力..

killkill_shadow

原帖由 dap570 于 2010-6-29 21:01 发表
这个帖子再来点碰撞+花火 基本就可以受"精"了 : )

其实未必都有那么高的并发哦,
没有那么大的并发 也就不需要去考虑得那么精细了, 精细化的应用会消耗高昂的人力 物力 财力..

这句话就可以受"精"了

maclean

还是tom那段话吧， 能用SQL解决的不要用存储过程，能用存储过程解决的不要用java ,能用java 解决的不要用C,C都不能解决了需要考虑下是否需要实现了

大致是这样。。。

熊猫儿

学习了。。。

yueyangflash

原帖由 <i>wisdomone1</i> 于 2010-6-29 17:30 发表 <a href="http://www.itpub.net/redirect.php?goto=findpost&pid=16036424&ptid=1319266" target="_blank"><img src="http://www.itpub.net/images/common/back.gif" border="0" onload="if(this.width>screen.width*0.7) {this.resized=true; this.width=screen.width*0.7; this.alt='Click here to open new window\nCTRL+Mouse wheel to zoom in/out';}" onmouseover="if(this.width>screen.width*0.7) {this.resized=true; this.width=screen.width*0.7; this.style.cursor='hand'; this.alt='Click here to open new window\nCTRL+Mouse wheel to zoom in/out';}" onclick="if(!this.resized) {return true;} else {window.open('http://www.itpub.net/images/common/back.gif');}" onmousewheel="return imgzoom(this);" alt="" /></a><br />

<br />

<br />

<br />
    为何数据库服务器较于应用服务器不易扩展，因为数据库扩展要作的工作 多吧，比如：前期升级测试，io压力测试，调n多参数，回退方案，而应用就是简单的添加节点就好了？<br />
<br />
我们准备上jboss 集群，这种架构又是怎么一回事呢，谢谢！

<br />

数据库的扩展成本确实比较高（贼有钱的企业除外），DB服务器永远都比APP的服务器贵。一般都考虑在应用层扩展，在应用层处理，而不考虑将DB复杂化！

wisdomone1

原帖由 wolfop 于 2010-6-29 14:50 发表
从应用分层的原则，大量使用存储过程导致业务逻辑分散在DB和应用服务器层，肯定不好开发维护和更新。
从性能来说,SP肯定不是最优的，我知道的案例就有某运营商原来计费批价都用SP，后来很难满足性能的问题。
总体来说，SP可以用，但要很慎重，最好只用来维护，不用于业务逻辑和支撑高并发高性能的东西。

    具体来说, 你所言的sp主要用于维护是指什么工作呢?可否具体化下,谢谢1

不再画地为牢

原帖由 wolfop 于 2010-6-29 17:53 发表

虽然我不知道淘宝怎么做，但是一般大并发的OLTP系统不会做这种SUM操作，不过也不一定应用层做。经常的做法是ELT或者goldengate之类的东西将OLTP数据复制到ODS/DSS系统做SUM

如果是很大规模的统计，肯定是交给数据仓库做，DB一般只提供根据主键或者或者索引的单挑或者不多的多条查询，比如某一天的交易总额你让数据库做，这对于OLTP简直就是个灾难

wuxunhym

PL/SQL在功能上有不少扩展，相比较C++与sql的结合，是能够减少一些代码量。各有利弊。
但，如果能用一条sql语句，就不要用pl/sql。

wuxunhym

原帖由 zhangfengh 于 2010-6-30 10:33 发表
找平衡点，要看你的数据库压力到底能达到什么程度，是否真的需要用应用层去分担数据库的压力

如果压力真的那么大，那么利用应用层也无可厚非；如果压力达不到，又何必去用应用层做数据库的事情呢

个人看法：能够用到数据库的功能的还是要尽可能的用。如果数据库仅仅作为一个容器，只是为了保存数据用，那何必用oracle呢，又要花钱买人家的软件，又要花钱买人家的服务。直接存进文本，自己处理岂不是好

尽管数据库的功能强大，但在OLTP系统里，一个有破坏性的语句能够导致其他语句运行相当缓慢，因此都会尽可能的将语句简单再简单。OLTP系统应该以用户为主要的，这是数据库在整个系统中的宗旨。
应用层相对来说容易扩展，而数据库难一些。 如果在设计时候将压力转向了数据库层面，用户和使用增长到一个数量级后，极有可能还是要回到起点去调整整个架构。何不在设计时候做到相对简单呢……

直接存到文本，当然更省钱省事！不过，这个反例没有说服力。用户怎么怎么查数据呢？ 总不能让用户花几十秒甚至更久的时间去找一条数据呀。

lei

其实事无绝对的。
开发维护角度：看你的开发人员多少，当然也要看你的团队人员的技能构成和水平，根据个人的经验，觉得还是存储过程相比较Java的那些玩艺要容易、轻量、好管理、好沟通、也好分层。
性能角度：看你的软硬件平台能力，看你的数据量来选择架构吧，先期可以开发一个原型模块加足够的压力测试一下，个人觉得，存储过程的性能对一般的封闭系统足够了，从你的那个例子存储过程看，你的系统可能只是基于web的管理信息类系统，而不是像前面贴子里面的阿里公司那样的公众开放系统，所以扩展性的考虑不是第一位的。

[ 本帖最后由 lei 于 2010-6-30 11:36 编辑 ]