真是无知者无畏啊。banq这句言论一出,坦白地讲,真的使我怀疑是不是已经脱离了实际开发,变得只是纸上谈兵了。
我现在慢慢发觉,搞JAVA的人有一个通常的特点,就是对JAVA相关的东西无限崇拜,而对除JAVA之外的所有东西都看小,认为不值一提,认为JAVA就是一切,认为JAVA就可以解决一切,其它所有都变得不重要了,OS,数据库,通通都不值一提了。我怀疑某天banq会起个大标题,操作系统的综结,那更加是笑掉大牙了。
事实上是这样吗?真的可以忽略数据库了吗?真的以为J2EE容器可以解决一切吗?按照我的经验,在大数据量高并发的情况下,数据库真是少做点优化都不行,整个系统都运行不了。我曾在两家国内最大的门户网站工作过,里面的数据量大得惊人,而且访问量也惊人,banq见过成千万记录的表,几十G的数据库,而且每秒并发接近一千吗?真是少优化一点都会死人。有时候还要对DB采取一些非常规的优化。建表的初期就要对其表结构等斤斤计较,这样才顶得住这么大的负载。忽略数据库,让EJB容器去调优?让O/R Mapping工具去帮你自动生成表结构?笑话啦,恐怕给多十倍的硬件都顶不住。
别跟我提J2EE的cache,如jbosscache之类的东西。这个开发过JAVA应用的人都知道,不是什么很高深很值得吹的东西,而且它解决不了所有的问题。而且不太成熟。相比之下,各种DBMS内部久经考验的查询缓存更是值得留意。我更加信赖DBMS内部的查询缓存,更成熟更可靠。而且这两点根本不矛盾。我不介意你在app server加缓存,但是这并不能解决所有的问题,更加不能代替数据库方面的优化。
另外说点题外话,虽然我平时也是搞JAVA居多,我也很喜欢JAVA的优美。但项目上的一些事实还是应该不带有色眼镜去客观地看待的。在我们这边,apache无论遇到多大的负荷,从不崩溃过。我们这年的习惯是每年春节前重启其一次,虽然没这个必要。mysql之类的东西负荷更加重,但也极少崩溃,始终稳稳定定。但是resin/tomcat之类的,重压之下就有点难顶了。无论怎么优化,平均两三星期肯定需要有一次重启的。resin会好点,tomcat更加不行。拥戴JAVA,J2EE是件好事,JAVA也是一个好的东东,但也要注重事实。OS(UNIX),数据库,httpd等这些都是人类智慧的结晶,不是随随便便看两本J2EE的书就嚷着去可以取代的。
to xgyxgy
>页面的数据量大得惊人,而且访问量也惊人,banq见过成千万记录的表,>几十G的数据库,而且每秒并发接近一千吗

我曾经设计的J2ME+J2EE游戏系统目标在线是十万人在线,几千人同时在线的聊天室对我是小case,好像我有些不谦虚,对不起。

>resin会好点,tomcat更加不行

那是因为开发者掌握Java的火候还不到。

我经历过你说的并发访问量焦头烂额的痛苦,经过几年研究我才大力推荐内存计算,如果有人以为我是无病呻吟,我也没办法。

banq老师提倡的内存计算模型注重的更偏向于实时性能,前一位朋友的意见是在完成持久工作的同时兼顾性能的调优,不可否认,数据这玩意实在难以琢磨,或者象f4口中的女人,保鲜期短的可怜,用完就byebye,或者象牛郎哥与织女小姐,非得千百年来痴心无悔的弄个什么海枯石烂的不可。所以偶觉得数据可以大致分为两部分,当计算为先的时候则采纳banq老师的方法,反正好多数据都是临时的,存到后台去反而很占地儿,先封装在对象里您随便调着用,等那些把那些可计算的数据差不多都折腾完了以后,也就是该存储为先的时候则继续采用成熟的数据库技术来完成,一般来说这些数据都是比较关键和基础的,正好让那些dba大师们显显身手来调调优什么的。偶总觉得可以借用GC一类的思想,也将数据分分类,在不同的生存期内存在于不同的位置,找一个管理者来将那些较老化的数据相关内容进行不定期的持久,也可以反过来将那些需要用来构建新的对象的持久化字段提取到中间层来以被利用,可能自己觉得自己的思想太保守了,但实在是想不出更好的方法来协调这种矛盾的。

这样一来当数据激增的时候也没什么好恐怖的,用中间层做过滤和缓冲用后台做持久和容灾不就得了,也许谈不上什么结晶不结晶的,数据库也是要发展的,如果现在就结了晶定了论或是G一级的数据就吓倒一大批,那等T一级甚至P一级的数据时代来临的时候难道改回用人工数手指头么?banq老师的想法有道理在于中间层除了要协助后台完成存储工作之外,更加重要的是要能够让前台的响应能力得到最大化的提升,既然很多的事情只经过两层的处理就可以迅速的满足高并发响应需求了,又何必多此一举要把球倒到后场去再倒回来呢,也多了一个出错的环节啊。但是后台恐怕是不会消亡的,而且不是所有的数据一上来就成为某某对象的属性形式来激活于中间层的,所以就需要应用服务器们在承前--完成请求响应的同时,还要启后--负责从后台抓取基础数据来组建对象缓存并在适当的时候调整缓存的内容以总保持着在宝贵的内存空间里存储的是使用率最高的那些数据快照,这样通过中间层的努力来实现了对性能和存储的一个比较适当的折中,可以告诉那些挑剔的用户,如果您只关心速度的话那不如直接用isqlplus来查询得了,如果只热衷于玩oo的话不如去学什么smalltalk,既然是要做系统,那最好还是按照现实中实际的情况来协调吧。

不成熟的意见啊,没有论据和数字做基础的,希望大家凑活着一看,或是只当个乐吧。

中间件是个大而乱的概念。说其乱,是其定义至今仍无明确界定。
过去,有两大基础软件:操作系统和数据库。来了中间件,无非是从两足鼎立改为三足鼎立而已。
至今为止,中间件并未切入到数据库层里去。何来终结数据库一说?
古老的数据库技术一直充满生机。当前,数据库正处于变革关头。下一代应该是真正适应(不光是能存储)XML的数据库。独霸这么多年的关系型正面临着重大挑战。
Oracle多年来在做的一件事,是想把商务逻辑和分布式机制(应用服务器就这两块)纳入到数据库里面。
到今天为止,从未出现过什么数据库时代。现在看来,今后倒有可能出现。
banq 我想你是走火入魔了,是该清醒一下的时候了。
banq 我很佩服你,你说的是我想的

我很早以前就不只一次的跟我的同事说,逻辑实现在数据库纯粹扯谈
可惜知者了了,我直到目前为止身边的同事也基本"初级阶段",对结构,设计一无所知,却全部都是非常厉害的"问题解决者"和"功能制造者",而且都十分的自负,认为自己可以完成一切,某种程度上来讲,他是对的.就如同楼上那些回复你,抨击你的人一样.
但这是一种好的学习的态度吗?你愿意这么不厌其烦的回复他们,跟他们解释讲述,我告诉你,这是没用的,99%的"程序员"只是为了要一份工作而已,他们并不热爱程序,其中包括80%的的人是反对一切的.你怎么讲也没有用处.你又何必呢?

我九九年参加工作,辗转北京,深圳几大软件公司,在深圳华为的时间比较长,我的经验,应该是有一些说服力,国内的软件公司都是以解决方案和项目开发为主,不会重视技术,更别提所谓的"技术研发",这和你想向大家讲述的完全是背道而驰,反而是这些为了完成功能而完成功能的人更有市场,研究结构在国内软件行业没有意义.

目前国内软件产业(其实国内并没有软件产业),已经被太多的无知者和自以为是者充斥,就比如任何一片技术文章都会有人出来反对,根本没有讨论的意思,其实我早已失望.也很长时间没回过这么长一个贴了
hehe
就这样吧

又看了看那些回复
hehe..

banq你真是对驴探琴.

看了大家说了这么些,真是热闹啊!我觉的大家后来有些讨论有点偏激了(头脑过于发热了,哈哈)。是不是banq的《数据库时代的终结》起的有点不合适引起的?我看了文章的内容,我也有很多同感。这个“数据库时代的终结”是指以数据库为中心分析、设计和实现的思路的终结,并不是说不要数据库了。我编程编了十几年了,我也是从那个时代过来的。我觉得要以彻底地面向对象、面向方面地进行分析、设计和实现,确实不要过早地把数据库相关的概念引进来,一切都要自然地按面向对象的思想来考虑。只有在考虑系统的整体实现架构、持久层的实现时才把数据库相关的概念引进来,“数据库已经从过去的中心位置降为一种纯技术实现,数据库只是状态持久化的一种手段(文件是另外一种实现手段)”,这句话确实没错!
我看了太多的代码,90%以上的代码都是使用面向对象的语言工具来编写面向过程的程序(有太多的程序员会用JAVA或C++就说自己会面向对象编程,真是可笑)。我的体会是:如果数据库为中心分析和设计,写出来的不可避免的是面向过程的程序,起码是一个不伦不类地面向对象的程序。
看了这么多从开发者角度的论点,我想我可以提供一些用户角度的观点,也许对大家有帮助:
1。用7*24小时的J2EE集群来实现持久性,我不放心也不相信,第一断电这类的事情或者故障之类的事情少不了,第二作为企业管理者,投资少回报高的方案才是首选,7*24小时的J2EE集群方案投资肯定多于数据库方案(买数据库和买中间件一样都是花大价钱,买数据库只怕还可以少买些硬件,少花些钱,至少可以不要投资建立7*24小时的J2EE集群)。
2。没有了数据库,所有都是XML文件,我宁可有个数据库系统方便地管理数据,也不愿对着一堆XML文件发愁。也许开发者们能用JAVA开发出一系列工具来管理XML文件,但是这种方案比数据库管理数据强在哪里?
3。维护的问题。中间件只怕没有那么容易维护,动不动就要给各个中间件厂商联系解决问题,系统维护人员根本就派不上真正用场。我宁愿出问题的时候,只找一个厂商,解决所有问题。另外,有些时候我还是倾向于有自己的源代码,那怕是二次开发,可以随时调整和修改,不必非要眼巴巴盯着中间件厂商,等别人救火是来不及的。

一点点用户方面的看法,我希望开发者在进行技术革新的时候把用户利益放在第一位,这样的技术才会有生命力

对了,还想补充一点,前面看到一个观点,说以数据库为基础开发的应用程序,一头是数据库,一头是界面,中间层就混乱不堪(我不是搞技术的,这是我看了各位的文章后的个人理解,如有错误,请指正),那我想问几个问题:这些程序员有没有受过严格训练?为什么中间层会混乱不堪?数据库软件并不难用,接口也并不怪异,为什么有数据库就设计不出好的结构来?
谬论,简直是误导初学者,其实作者自己在数据库方面的造诣恐怕也是个初学者吧,真是无知者无畏啊!!
真是觉得一叶障目不见泰山啊,面向交易的小数据量的项目作多了,就以为几十万的数据很多了,就以为数据库不过尔尔。君不见什么叫信息爆炸,什么叫信息整合,什么叫数据挖掘??文件固化??内存??简直让人笑掉大牙!!数据库作为一个发展中事务,其必然有历史定位和范畴,作者恐怕看见的只是关系数据库吧,那谁又能断言将来没有面向对象数据库,多媒体数据库,甚至网络神经数据库呢??还是一句话,无知者真无畏啊
>将来没有面向对象数据库,多媒体数据库,甚至网络神经数据库呢
数据库专家Oracle都来做中间件了,你的那些数据概念还是停留在90年代思维上。对象数据库也只是对象中间件的附身产品,其他你说的两种数据库只是单支科研成果,就象操作系统还是在不断发展一样。

对本命题反感或想不通的人说明都没有真正接受中间件思想,需要更新自己的知识库了。

>对本命题反感或想不通的人说明都没有真正接受中间件思想,需要更新自己的知识库了。

典型的本位思想啊,呵呵。oracle作中间件是因为在数据库理论和发展暂时处于瓶颈期的一个商业运作而已,能够证明什么?
你恐怕走火入魔了吧,缓存固化充其量只不过是一种技巧而已,还敢嘲弄科研。懒得指正你呢,愿你早日迷途知返~~
>>对象数据库也只是对象中间件的附身产品
中间件以前是什么的附属产品恐怕你也忘了吧~~