|
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (1)
|
|
|---|---|
| 作者 | 正文 |
|
最后更新时间：2008-05-07
从来就没有见过一句顶1W句的SQL。倒是Hibernate让我们省了很多表到对象的转换语句。
你把业务都写死在数据库上了。如果业务中途要调用远程查询一些数据呢？你做DBLink访问人家数据库？人家数据库不许你这么访问怎么办？对方没有数据库只有Web Service呢？存储过程基本上就只能和自己及可以提供和自己链接的数据库打交道。这样能适应需求吗！！！ 现在需求分析、领域建模，都是以UML的用例、类来分析。用ER图分析需求，你看现在哪本教开发的书还这么写？ 开发现在讲究敏捷、随需应变。可以快速组合业务流程。你存储过程能做到吗？ 现在开发初期需求不明确，造成数据结构反复变动。你数据库每变一次，存储过程都要重写。Java只需要改改对象，框架会自动修改对应的数据库结构。 |
| 返回顶楼 | |
|
最后更新时间：2008-05-07
留恋存储过程的，我想大多数人可能是最近几年都脱离了实际的开发的人。记得当初某人曾说，用存储过程吧，反正这个业务10年也不会发生变化。而且我还不是在一个人那里听到的这个说。但是这些系统仅仅过了三年就要升级，因为业务规模和企业需求的发展大大超乎当初的设想。
不要以为一种技术理论开始流行仅仅是人们的炒作。把业务分层，与数据和显示、硬件隔离的思想，已经出现了20年了。可以说分层的思想一出现，人们就在说这个问题。而且一直对这个问题的看法如此一致。这些都是建立在大量的大规模企业应用的基础上得到的血的教训带来的。 可以说即便硬件的更新再快，也赶不上需求的要求。CPU和IO瓶颈，昨天是，今天是，明天依旧是问题。而一旦需求来了，不会有时间给你去解决这个问题。这个时候最简单的方式，就是直接加点应用服务器。这个方法比任何方法都见效快，而且往往也最便宜。 |
| 返回顶楼 | |
|
最后更新时间：2008-05-07
robbin 写道 暂且不谈开发效率、维护性的问题，业务逻辑用存储过程来实现最大的危害在于，你没有办法进行群集扩展！
金融和电信行业的确在数据库服务器的硬件投资少不会吝惜，但是数据库服务器是单点的，极难扩展，即便Oracle的群集，他的共享存储数据库也是单点的，如果业务逻辑的运算非常消耗CPU和IO，你没有任何有效的办法来扩展系统的性能。 对于并非极度依赖数据的业务逻辑运算，如果在应用服务器端来实现的话，特别是采用SNA架构的情况下，理论上可以获得无限的水平扩展能力，只要加服务器就行了。但如果你放在数据库里面，你就大眼瞪小眼了，加服务器都不管用了。 对于那些对于性能要求极度苛刻的大负载应用，比方说阿里巴巴，拥有中国最强的Oracle DBA团队，已经把Oracle的配置优化到极限，已经把SQL优化到极限了。他们绝对不允许程序员把业务逻辑写成存储过程，甚至不允许程序员创建触发器、不允许程序员创建表的外键约束，外键关系自己在程序里面维护。凡是能够在应用层进行检查的工作绝不能放在数据库层，加重数据库服务器的负担。 我只希望大家记住一点：数据库服务器出现CPU和IO瓶颈，你没有办法扩展，但是应用服务器出现CPU和IO瓶颈，你只需要加服务器就行了。 有点疑惑，如果把大量的业务逻辑放到webserver来处理，那么webserver和dbserver之间数据的传输量肯定会比把业务放到dbserver进行处理，然后dbserver只返回少量处理后的数据多。 当访问量大规模提高之后，webserver和dbserver这种传输的消耗肯定也要大规模提高。这个地方如果出现瓶颈是能用添加服务器来解决的？ |
| 返回顶楼 | |
|
最后更新时间：2008-05-07
我只希望大家记住一点：数据库服务器出现CPU和IO瓶颈，你没有办法扩展，但是应用服务器出现CPU和IO瓶颈，你只需要加服务器就行了。
有个问题。如果中间件服务器扩展到10台，假设同时10台机器上同时需要计算大量业务运算，而这些运算最终还是要到数据库上运算的到时一样会有IO瓶颈的。 企业应用系统的集群，我认为主要是解决高可用性，很多业务是7×24的，所以用群集的。 业务逻辑用存储过程来实现最大的危害在于，你没有办法进行群集扩展！没明白这个和业务逻辑用存储过程有什么关系。 |
| 返回顶楼 | |
|
最后更新时间：2008-05-07
ygxdha 写道 robbin 写道 暂且不谈开发效率、维护性的问题，业务逻辑用存储过程来实现最大的危害在于，你没有办法进行群集扩展！
金融和电信行业的确在数据库服务器的硬件投资少不会吝惜，但是数据库服务器是单点的，极难扩展，即便Oracle的群集，他的共享存储数据库也是单点的，如果业务逻辑的运算非常消耗CPU和IO，你没有任何有效的办法来扩展系统的性能。 对于并非极度依赖数据的业务逻辑运算，如果在应用服务器端来实现的话，特别是采用SNA架构的情况下，理论上可以获得无限的水平扩展能力，只要加服务器就行了。但如果你放在数据库里面，你就大眼瞪小眼了，加服务器都不管用了。 对于那些对于性能要求极度苛刻的大负载应用，比方说阿里巴巴，拥有中国最强的Oracle DBA团队，已经把Oracle的配置优化到极限，已经把SQL优化到极限了。他们绝对不允许程序员把业务逻辑写成存储过程，甚至不允许程序员创建触发器、不允许程序员创建表的外键约束，外键关系自己在程序里面维护。凡是能够在应用层进行检查的工作绝不能放在数据库层，加重数据库服务器的负担。 我只希望大家记住一点：数据库服务器出现CPU和IO瓶颈，你没有办法扩展，但是应用服务器出现CPU和IO瓶颈，你只需要加服务器就行了。 有点疑惑，如果把大量的业务逻辑放到webserver来处理，那么webserver和dbserver之间数据的传输量肯定会比把业务放到dbserver进行处理，然后dbserver只返回少量处理后的数据多。 当访问量大规模提高之后，webserver和dbserver这种传输的消耗肯定也要打规模提高。这个地方如果出现瓶颈是能用添加服务器来解决的？ 在这个自然界中，所有的线性关系（假定是Y = K × X）都是对实际的非线性关系的模拟， 在一定的误差范围内，是存在适用范围的 一旦X超出这个范围的边界值，线性预期值(Y)与实际值的偏差就会大到不容忽视的地步， 这个偏差通常会反过来削弱被期待的效应(Y)，类似于一个负反馈系统 于是，被期待的效应(Y)就会随着X的增大而趋近一个极限值 经济学上的“边际效应递减”，说的是类似的意思 比方说：在只有一台server的时候，再增加一台server，性能的提高是明显的，接近K ×(1+1) 但随着server越来越多，效果就会越来越不明显，甚至于发生恶化 在软件工程的领域，一定的条件下，增加人员可以缩短开发时间 但是，这并不意味着增加N倍的人员就可以使开发时间缩短到原来的1/（N+1） 所以，没有银弹 |
| 返回顶楼 | |
|
最后更新时间：2008-05-07
莫生气 写道 我现在就比较头痛，接收的项目里面有块重要的业务逻辑的是用存储过程写的，现在改点东西，都得找DBA改，然后再联调
完全听不懂你在说什么。DBA来给你改存储过程？ |
| 返回顶楼 | |
|
最后更新时间：2008-05-07
ygxdha 写道 有点疑惑，如果把大量的业务逻辑放到webserver来处理，那么webserver和dbserver之间数据的传输量肯定会比把业务放到dbserver进行处理，然后dbserver只返回少量处理后的数据多。 当访问量大规模提高之后，webserver和dbserver这种传输的消耗肯定也要打规模提高。这个地方如果出现瓶颈是能用添加服务器来解决的？ 嘿嘿，真的那么肯定吗？你给我一个具体的数字告诉我，究竟提高到什么程度，每秒要传输多少MB的数据？不要空对空的扯淡。 我不妨给你一个数据参考参考，JavaEye每天是70万页面访问量，处理80万动态请求，访问峰值的时候Web服务器和DB服务器之间的网络数据传输量是2MB每秒，平均每秒传输不到1MB。 我就算你的企业应用系统每天有800万动态请求，你服务器之间的峰值数据传输量也不过20MB每秒而已。好吧，也许你又说JavaEye处理的数据量不够大，我再给你扩大5倍，算你峰值每秒数据传输量100MB，够不够大？ 可即便如此，现在随随便便的普通台式机的网卡都已经是千兆网卡了，处理你这峰值每秒100MB简直轻而易举，更不要说专用的高速服务器网卡了。对于大规模的群集应用，有更加高速的光纤，每秒几GB都不成问题，但你要真有每秒几GB的数据量，嘿嘿，老实告诉你，中国还没有多少企业应用系统有这么大的网络数据传输的需求。 |
| 返回顶楼 | |
|
最后更新时间：2008-05-07
我只希望大家记住一点：数据库服务器出现CPU和IO瓶颈，你没有办法扩展，但是应用服务器出现CPU和IO瓶颈，你只需要加服务器就行了。
robbin 你能给出一个具体的数字么？究竟提高到什么程度？ 当然JavaEye这类网站这类的应用，我是同意的观点。 我想这个帖子是在业务系统为主的前提下 |
| 返回顶楼 | |
|
最后更新时间：2008-05-07
mcpssx 写道 java处理业务肯定不如SQL，PL/SQL可以一句顶一万句，JAVA里面好多都是废话，比如jdbc里面的什么准备statment啊之类的。 你这就说的牵强了，jdbc里的PreparedStatement你以为是他专门搞出来的东西？他就是直接对应数据库的特性而来的，你没用过数据库的PreparedStatement吧？用SQL也可以直接写的PreparedStatement的，同样使用？做占位符，然后多次输入参数多次执行。 |
| 返回顶楼 | |
|
最后更新时间：2008-05-07
phlsbg 写道 我只希望大家记住一点：数据库服务器出现CPU和IO瓶颈，你没有办法扩展，但是应用服务器出现CPU和IO瓶颈，你只需要加服务器就行了。
robbin 你能给出一个具体的数字么？究竟提高到什么程度？ 当然JavaEye这类网站这类的应用，我是同意的观点。 我想这个帖子是在业务系统为主的前提下 比方说我2005年给X行咨询的一个关于全行票据交易的项目，很繁重的业务运算，一开始跑的还挺快，但上了十几个省的分行以后，一个WebSphere顶不住了，繁忙的时候页面响应很慢，几乎出不来了。于是我们做了水平和垂直群集，两台HP9000的小型机跑应用服务器，每台小型机上面跑两个WebSphere实例，做垂直群集，小型机之间再做水平群集。总共是4个WebSphere实例的群集，这下业务系统就恢复了正常。等全国30省的所有分行全部开放以后，每天还是跑得稳稳的。如果业务量再大，还可以继续添加服务器和WebSphere实例。如果你都把业务放在数据库里面实现，我看你怎么扩展数据库和硬件？ |
| 返回顶楼 | |
