|
锁定老帖子 主题：一次小项目的思考
该帖已经被评为良好帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2009-08-25
楼上的说法正好证明了：以数据库为中心的编程方式，最终是极难扩展的。
倘若我把逻辑采用java对象表达，自然就减少的对数据库的依赖。 原本要执行2万条SQL，可能现在只需要执行几条获取数据的SQL就能够完成原先的业务。 |
| 返回顶楼 | |
|
发表时间：2009-08-25
最后修改：2009-08-25
tianhaoleng 写道 楼上的说法正好证明了：以数据库为中心的编程方式，最终是极难扩展的。
倘若我把逻辑采用java对象表达，自然就减少的对数据库的依赖。 原本要执行2万条SQL，可能现在只需要执行几条获取数据的SQL就能够完成原先的业务。 ORM, object最终还是要map到relational database,我不知道你两万条sql怎么减到几条获取数据的SQL 对于很多OLTP类型的系统，hibernate, EJB-QL之类的根本是无法胜任的。这种情况下从性能方面考虑，只能以数据库为中心。 |
| 返回顶楼 | |
|
发表时间：2009-08-25
ray_linn 写道 TheMarine 写道 metadmin 写道 我们对系统进行分析后，采取了缓存、临时表两种手段，极大降低调用数据库次数，提高每次调用效率。这两种方式，对系统性能提升非常大。上月数据只要1天时间就能处理完毕。 只要稍微合理利用数据库，同时对自己的程序进行优化。显然数据库还是好的方式！！ 你所说的不正好证明了数据库是缺乏弹性的,数据库是有极限的,把负载全部丢在数据库端,全部依赖数据库性能解决业务复杂度就是你遇到的问题,也是现在普遍的,如果负载继续增加呢?单机数据库会撑不住的,弹性就是在增加集群服务器的时候性能随之明显提升,当然数据库集群也是可以的,但是相比app集群的代价呢? 拜托大家都真正去理解一下"数据库已死"的真实含义之后再来说吧,数据库是一定要也一定会使用的,但是把设计重心移到业务上,利用集群,缓存减轻数据库负载才是他说的意思. 胡扯。 假如一秒钟里有1万次insert,1万次select，而且这些数据调用都是必须的，看不出你的app集群有什么用处，而且只会更慢，因为数据库不单单要处理这么多次SQL，而且还要parser这么多次SQL. 减少数据库调用的有效方法之一，客户端可以用缓存，服务器端可以用临时表，游标，缓存等等方法。app集群根本不能减轻数据库调用的压力，2万条SQL调用分配到10个app集群上，数据库端收到的还是2万条SQL. 应该没有人会认为app集群会使得数据库总操作减少.我的意思可能没有表达明白,我是说,当你把负载集中到服务器,操作缓存,尽可能的减少数据库操作次数的前提下,使用app集群可以显著提高性能.同时你既然说集群没用,那么也等于说,系统性能的瓶颈在数据库端了.而我们要解决的就是让数据库解放出来,不要单单的承受那么大的压力,因为它的弹性比app来的小. |
| 返回顶楼 | |
|
发表时间：2009-08-25
logicgate 写道 tianhaoleng 写道 楼上的说法正好证明了：以数据库为中心的编程方式，最终是极难扩展的。
倘若我把逻辑采用java对象表达，自然就减少的对数据库的依赖。 原本要执行2万条SQL，可能现在只需要执行几条获取数据的SQL就能够完成原先的业务。 ORM, object最终还是要map到relational database,我不知道你两万条sql怎么减到几条获取数据的SQL 对于很多OLTP类型的系统，hibernate, EJB-QL之类的根本是无法胜任的。这种情况下从性能方面考虑，只能以数据库为中心。 OLAP？ |
| 返回顶楼 | |
|
发表时间：2009-08-25
ray_linn 写道 TheMarine 写道 metadmin 写道 我们对系统进行分析后，采取了缓存、临时表两种手段，极大降低调用数据库次数，提高每次调用效率。这两种方式，对系统性能提升非常大。上月数据只要1天时间就能处理完毕。 只要稍微合理利用数据库，同时对自己的程序进行优化。显然数据库还是好的方式！！ 你所说的不正好证明了数据库是缺乏弹性的,数据库是有极限的,把负载全部丢在数据库端,全部依赖数据库性能解决业务复杂度就是你遇到的问题,也是现在普遍的,如果负载继续增加呢?单机数据库会撑不住的,弹性就是在增加集群服务器的时候性能随之明显提升,当然数据库集群也是可以的,但是相比app集群的代价呢? 拜托大家都真正去理解一下"数据库已死"的真实含义之后再来说吧,数据库是一定要也一定会使用的,但是把设计重心移到业务上,利用集群,缓存减轻数据库负载才是他说的意思. 胡扯。 假如一秒钟里有1万次insert,1万次select，而且这些数据调用都是必须的，看不出你的app集群有什么用处，而且只会更慢，因为数据库不单单要处理这么多次SQL，而且还要parser这么多次SQL. 减少数据库调用的有效方法之一，客户端可以用缓存，服务器端可以用临时表，游标，缓存等等方法。app集群根本不能减轻数据库调用的压力，2万条SQL调用分配到10个app集群上，数据库端收到的还是2万条SQL. 将2万次操作，分散到10台app，是否会令db减轻压力，这个，是否有相应经验的人谈一谈。 另外，采用app集群等方式，通过缓存等手段，或分散SQL的操作，或者根本就是在缓存中来取数据，来减轻对db的操作。 |
| 返回顶楼 | |
|
发表时间：2009-08-25
TheMarine 写道 ray_linn 写道 TheMarine 写道 metadmin 写道 我们对系统进行分析后，采取了缓存、临时表两种手段，极大降低调用数据库次数，提高每次调用效率。这两种方式，对系统性能提升非常大。上月数据只要1天时间就能处理完毕。 只要稍微合理利用数据库，同时对自己的程序进行优化。显然数据库还是好的方式！！ 你所说的不正好证明了数据库是缺乏弹性的,数据库是有极限的,把负载全部丢在数据库端,全部依赖数据库性能解决业务复杂度就是你遇到的问题,也是现在普遍的,如果负载继续增加呢?单机数据库会撑不住的,弹性就是在增加集群服务器的时候性能随之明显提升,当然数据库集群也是可以的,但是相比app集群的代价呢? 拜托大家都真正去理解一下"数据库已死"的真实含义之后再来说吧,数据库是一定要也一定会使用的,但是把设计重心移到业务上,利用集群,缓存减轻数据库负载才是他说的意思. 胡扯。 假如一秒钟里有1万次insert,1万次select，而且这些数据调用都是必须的，看不出你的app集群有什么用处，而且只会更慢，因为数据库不单单要处理这么多次SQL，而且还要parser这么多次SQL. 减少数据库调用的有效方法之一，客户端可以用缓存，服务器端可以用临时表，游标，缓存等等方法。app集群根本不能减轻数据库调用的压力，2万条SQL调用分配到10个app集群上，数据库端收到的还是2万条SQL. 应该没有人会认为app集群会使得数据库总操作减少.我的意思可能没有表达明白,我是说,当你把负载集中到服务器,操作缓存,尽可能的减少数据库操作次数的前提下,使用app集群可以显著提高性能.同时你既然说集群没用,那么也等于说,系统性能的瓶颈在数据库端了.而我们要解决的就是让数据库解放出来,不要单单的承受那么大的压力,因为它的弹性比app来的小. 作为讨论前提，我们先假设采用APP和采用SP的SQL语句长度接近，那么采用APP和采用SP有什么区别呢？ a. 采用APP，SQL语句被发送至服务器端，服务器端Parser该SQL语言编译SQL，执行后（可被缓存）之后返回值。 b. 采用SP, SQL语句直接执行后返回值。 由于每秒被发送至服务器的SQL语句相同，根据<Oracle高级编程>一书，a 要比 b 慢上20倍，对于相同的SQL的总量，a 要比 b慢上许多，对数据库的CPU更是折磨。 |
| 返回顶楼 | |
|
发表时间：2009-08-25
但是我们使用缓存,为什么非得在1秒内执行完呢?
|
| 返回顶楼 | |
|
发表时间：2009-08-25
最后修改：2009-08-25
TheMarine 写道 但是我们使用缓存,为什么非得在1秒内执行完呢?
这正是我上面回复的，提出一个比较极端的问题，以此说明app无济于事。但事实上，采用app，并非是为了能够让db在1秒钟能够处理完10000条insert或10000条update。 |
| 返回顶楼 | |
|
发表时间：2009-08-25
最后修改：2009-08-25
TheMarine 写道 但是我们使用缓存,为什么非得在1秒内执行完呢?
1. 缓存是种中立技术，无论采用app或者采用SP，都可以使用。 2. 缓存是会“脏”的，越繁忙的系统，缓存就越容易“脏”,越重要的系统，缓存使用的就越少。 3. 集群缓存技术更复杂，也更容易“脏”。 |
| 返回顶楼 | |
|
发表时间：2009-08-25
rainlife 写道 TheMarine 写道 但是我们使用缓存,为什么非得在1秒内执行完呢?
这正是我上面回复的，提出一个比较极端的问题，以此说明app无济于事。但事实上，采用app，并非是为了能够让db在1秒钟能够处理完10000条insert或10000条update。 从执行效率上看，SP永远是冠军。 |
| 返回顶楼 | |
