coder
2008-08-13 07:36
一亿只是一张表的数据量,我觉得如果吧全部表缓存起来是不太好的。这个成本也太高了。

banq
2008-08-13 10:55
>一亿只是一张表的数据量,我觉得如果吧全部表缓存起来是不太好的

一般不这么做,没有必要这么做,缓存总是比较小,最频繁使用的留在缓存里面。

从业务角度讲,在某段时间中业务数据访问比较集中,这段业务数据使用业务对象缓存效率高。比如财务 库存系统,总是当月数据查询得比较多,不可能10年前的数据查询量要大于当月的,所以,缓存就对当月数据性能起到提升作用,如果当月量比较大,可以用分布式缓存,多几个服务器,LInkedin的内存就达到2T。

如果象google搜索那么分散,从业务上无法有集中数据,那么采取google的并发查询策略,当然,我认为企业计算这种可能性很小,因为企业管理运行,总是关注当月资金流 物流情况,这是重点。

另外我对你前面提出很多依赖数据库API进行的复杂算法,其实换个思维想想,这些强劲的数据库API是整合在数据库产品中,如果拿出来,不就变成中间件了,而且好处是不依赖这个数据库产品,这是趋势,当然,某个厂商不希望拿出来,否则不好卖DB产品,但是作为用户以及技术客观发展,拿出来是大势所趋啊。所以,我们思维不能以现实怎么样就怎么样,而应该以发展眼光看。

[该贴被banq于2008-08-13 11:01修改过]

coder
2008-08-13 13:28
1。从业务角度讲,在某段时间中业务数据访问比较集中,这段业务数据使用业务对象缓存效率高。比如财务 库存系统,总是当月数据查询得比较多,不可能10年前的数据查询量要大于当月的,所以,缓存就对当月数据性能起到提升作用,如果当月量比较大,可以用分布式缓存,多几个服务器,LInkedin的内存就达到2T。

这也要考虑成本,企业的目的就是利益的最大化,同样是能少几个服务器能够解决的,为什么要多几个服务器呢,尤其是像中国现在的企业。不可能缓寸数据库就必然要直接操纵数据库。

2,另外我对你前面提出很多依赖数据库API进行的复杂算法,其实换个思维想想,这些强劲的数据库API是整合在数据库产品中,如果拿出来,不就变成中间件了,而且好处是不依赖这个数据库产品,这是趋势,当然,某个厂商不希望拿出来,否则不好卖DB产品,但是作为用户以及技术客观发展,拿出来是大势所趋啊。所以,我们思维不能以现实怎么样就怎么样,而应该以发展眼光看。

面向对象总是过分的强调扩展,以至于做了很多额外的工作。其实有些是不必要的。比如说数据库扩展,象这种变化一般是不会发生的,企业怎么可能一会又从ORACLE移植SQLSERVER呢,就算有也只是极少数,就好比打个比方,面向对象总是预测可能的一切变化,你出去旅游,你要考虑所有可能出现的情况,以至于你得做好一切准备,比如你要带好一汽车的东西去面对可能出现的问题,下雨了要伞,饿了要面包,生病了要药,走累了要椅子休息,包打不开又得准备老虎钳,老虎钳坏了又要准备好锤子,其实这些是不会发生的。以至于我们的系统过分的臃肿。有些扩展是没有必要的。

当然如果你是一个做中间件的公司,那是要适当考虑扩展的,因为你的产品是要给很多公司用的,得面对很多情况。

面向对象思想很好,但不要过度设计,数据库也非常重要。不要为了面向对象而面向对象,最终目的是给企业创作价值。谁少花钱又创造了更多的价值才是银蛋。

freebox
2008-08-13 15:29
基于缓存的应用不必要拿到1亿数据,基于数据库的应用也同样不必要拿到1亿数据,我想说的是对于同等数据量,这两种方案都是可行的,为什么不采用内存检索而去查询db呢?

再说一下我认识的比较狭隘的扩展问题,我参与过一个项目,他们的某些内容是用sqlserver存贮的,而另一些内容是用oracle存贮的,但是这两种存贮实际上共同完成了一个业务目的。有一天,维护oracle的人走了,但是他们还照常变更着需求,我也不用担心我不会oracle而无法完成那部分数据的查询和持久作业,我是在和对象说话。事实上我是第二周才知道那部分是oracle做的持久,之前我一直以为全部都是sqlserver。

dreammore
2008-08-14 11:37
OO与db确实一直在争论不休,不过越辩道理越明。

我支持OO技术

猜你喜欢
11Go 上一页 1 2 3 4 5 6 7 ... 11 下一页