"关键是要认识到，与保证站点性能相比，丢失少许数据的故障是可接受的。"Benedetto说。
不知道大家是否注意到这一句话。
简单的说数据库已死，是断章取义，在日常的生活中你必须在性能与丢失数据之间找到一个平衡。数据库最求的是数据安全性，而cache完成的是提高性能，这两个并不存在什么不可调和的矛盾，简单的说瓶颈在于数据库是不对的。
>你必须在性能与丢失数据之间找到一个平衡。数据库最求的是数据安全性，而cache完成的是提高性能
你这个观点表面上是对的，但已经过时，对javaEE集群完全不了解。
集群保证7x24小时不间断运行，任何一台服务器当机损坏都不会造成整个系统停止，再加上现在内存价格极其低廉，百度最近开始用闪存硬盘替代传统的快速硬盘，说白了，在极端情况下，就是将所有数据装入内存，系统一周7天24小时不停机，内存不会掉电，何来数据丢失？
全年只有1%不到时间关机维护，关机之前会将所有内存数据再写入数据库等永久保存介质如硬盘上。所以，你会明白著名社交网站LinkedIn为什么一开机就要耗时8小时，他敢频繁这样开关机吗？
所以，彻底抛弃数据库这个奶嘴，才能真正成熟起来。
[该贴被banq于2008-09-18 10:00修改过]
jdon网站在进行功能升级的时候有没有关机？怎么做到在不关机的情况下进行功能升级？
上面的话说明你没有了解什么叫真正的企业应用。
你的话存在两个矛盾：
首先cache是为了解决速度问题，所谓的速度问题并不交易速度，而是展现速度，即将数据对象放于内存中，当有请求到来的时候可以加速展现，可是如果数据改变那？？必须重新调入内存或者在内存中进行修改，设计到修改就要涉及线程问题，就是锁的问题。你的锁怎么实现，你的锁的粒度怎么样，你怎么调节，是全部还是部分，据我所致j2ee的粒度与数据库的比简直就没有办法可以比较。在需要锁调度情况下，我孤陋寡闻了，真的不知道有什么解决方案。
其次，是否会丢失数据，简直是笑话了，硬件坏与不坏根本不是你我能说的算的，就算做raid1的硬盘两块都坏了的情况我都见过，何况只是闪存的硬盘，而且闪存硬盘也是硬盘，只是在随机读取上具备一定的优势，对于企业一个硬盘的损坏可以接受，但是用户数据的丢失却是不一定能够接受的（比如你的银行存款，你的手机费，你的证券信息，你的信用情况，你的身份敏感信息）。这些在db上可以通过log来恢复，请问你用j2ee的什么来恢复？？
所以请不要从一个极端走向另外一个极端，片面的偏执只会让别人发现你的愚昧。
你所谓的企业应用是以数据库为中心的应用，那是过去集中式计算，还是应该对当前分布式计算和云计算多了解一下再和我争论，本站5年来一直在普及这方面知识：
数据库的灾难恢复确实好，那是有一个前提，就是这台数据库发生灾难，但是在集群的情况下，任何一台发生灾难，其他服务器已经有状态复制，有failover，20台服务器全部崩溃发生灾难的概念几乎为0，
所以，就根本不会发生你所谓的单点灾难，没有单点灾难风险，它的恢复功能也就无效。
>据我所致j2ee的粒度与数据库的比简直就没有办法可以比较。在需要锁调度情况下，我孤陋寡闻了，真的不知道有什么解决方案。
对Java的JTA机制不了解，也对BEA Tuxedo没有了解，贴个地址先去看看：http://www.bea.com/framework.jsp?CNT=index.htm&FP=/content/products/tux/
再贴个分布式事务原理给你供你参考：
http://natishalom.typepad.com/nati_shaloms_blog/2007/08/lessons-from-am.html
你别再跟我说：事务和你说的锁是两回事.当然，我估计你会说，这些事务底层也依赖数据库事务，数据库作为JTA的一个事务resource，当然是分布式事务的一个底层实现，我想强调的是：在数据库事务上，我们现在已经封装了更多的东西，就象在操作系统上我们也封装了更多东西，你是不是从操作系统底层开始企业开发应用呢？
不知道你是否收到过这样的短信：XX银行晚上XX时到XX时进行停机维护，带来不便敬请谅解。恐怕你没有注意到吧。如果以后有机会你可以注意以下。我想说明的是系统并没有你想象中那么完美，通常这种停机是由于硬件问题导致的，银行的服务器是采用集群式的，而且通常都有异地灾备中心。但是仍然需要停机说明什么问题那？？我想大家都明白。不要说银行怕花钱，没有采用好的设备。
谢谢你介绍的文章，简单看了以下，也许没有理解的很深刻，我暂时的理解就是事务，那么为了防止竞争冒险，必然会使用锁的机制（包括数据库也是采用这种方式），但是数据库可以到表，到行，而线程事务估计只能到方法，对于访问的数据是没有什么选择权的，而且数据库可以使用共享锁，在java范围内我暂时没有看到过共享锁及递归锁的实现。希望能够提供一定的资料让我学习以下。
>在java范围内我暂时没有看到过共享锁及递归锁的实现
当然有了，其实你想象一下，数据库是用C语言编写的，Java也是不差于C的语言，它能做到的，Java怎么能做不到呢？Java做的数据库也有啊。
看看JDK API中FileLock章节 有共享锁和排他锁：
Whether a lock is exclusive or shared may be determined by invoking its isShared method.
http://java.sun.com/j2se/1.4.2/docs/api/java/nio/channels/FileLock.html
说极端点：采取DDD这样业务分析方法，将主要业务模型提炼出来，照顾好好这些业务模型的生命周期，再借助这些模型的缓存(比如Hibernate的CRUD操作就是实现缓存中的模型和对应的数据表同步更新，如果Java没有两下子怎么能做到同步更新呢？)。借助模型的缓存，实际上，我们每个系统都在做一个针对当前业务的小数据库。
什么意思呢？原来你是用一个大数据库方案来解决所有数据处理问题，其实没有一个裤子适合所有人，企业软件没有统一解决方案，所以，如果我们针对每个业务系统做一个度身定制的数据库，肯定相当完美的，Java解决方案加上DDD和缓存，实际上就是接近这个目标。
说实话，帖子写到这个位置真的不知道该怎么回了。
还是回到原点吧，我们讨论的问题是数据库是否已死。
那么首先明白什么是数据库，我们不使用官方的语言，就自己的理解，我认为就是一个数据存储的软件，但是他对于数据的安全性及效率提出了很高的要求。数据库的发展到现在关系型数据库应该已经是第三代了吧。那么以前的方法能不能称之为数据库那？？我觉得也应该。
那么接着说你的观点，你认为数据库已经成为了系统的瓶颈，并例举了 Myspace。那么什么地方是瓶颈你是否分析了？？是CPU运算不足？？是内存不够，还是IO操作的耗时？？其实很容易看出IO操作是其中的问题所在。myspace是一个读多写少的网站，但是你看看他原文中写的，他把许多用户状态信息写入了数据库，要明白数据库第一要务是保障数据的完整性，所以也许你每跳转页面他都要写一次磁盘，这才是瓶颈所在。而并不是数据库的问题（也就是设计要求与软件功能的相悖）。
你可以看看我前面的回复，我认为这是一个数据安全性与用户体验之间的平衡，用户可以接受刚刚写的blog提示出错，但是不能允许自己刚刚的存款被取消。这就是用户需求的目标不同。在不讨论目标的情况下下结论必定是一种错误。
对于你说的20台服务器可以保障安全之类，我想我们都知道，要想保障安全最好的办法就是冗余，这也是唯一的办法，冗余必然涉及到同步问题，多台服务器如何同步，效率问题都值得讨论。“百度最近开始用闪存硬盘替代传统的快速硬盘”我想你举的这个正是以后的发展方向，你把他看作内存，而我把他认为是硬盘，如果写硬盘跟写内存的时间操作一致，那么是用磁盘柜的成本更低还是多台服务器成本更低那？？
我觉得所谓的分布式事务不过是用于解决异构系统，而不是同构系统的一种解决方案，每个东西都有其长处及用途，宝剑锋利你能用它修鞋么？？但是你不能说有了宝剑锥子就应该消失。这个讨论我不希望自己成为数据库的捍卫者，在应用的过程中我也会有所选择，但是不能因为你喜欢一样东西就一定要否定另外的东西，对别人产生误导。
还是思维方式的问题，你不认为数据库是瓶颈，你说可能是设计问题。并针对MySpace提出了你认为问题所在，MySpace访问理论上是无限增长的，全球人都可能访问它，难道我们就不能找到一个一劳永逸的方法对待未来的增长，非得每次不行了打个强心剂去救它，如果我们做企业软件也是这个思路就完了。
所以，这是思维方式的差别，你完全误解了问题的根本，也是Hibernate创始人所说的：数据库是最不具有伸缩性的。
也就是最不具有弹性和灵活性的，我想大多数人对弹性和可伸缩性很不容易理解，我也不想在这里多说。没有弹性的oo思维实际很难理解什么是可伸缩性的。
我们讲OO，实际就是追求未来的可扩展性和灵活性，否则软件只要功能做好就可以了，同样，对于数据库，我们不只是要求它有数据存储功能，也希望它能够随着我们系统处理能力变化能够方便拓展，可惜实践下来，包括从理论上看：数据库都是阻碍我们扩展伸缩的一个瓶颈，这个瓶颈往往表示在性能上。
可伸缩表现在具体方面就是：随着访问负载的提高，我们能够不改动软件，只增加服务器就能扩展处理能力，这是方便灵活的可伸缩性，很显然，数据库做不到这点。（集群的数据库我已经在文章中说了）
对于，一个没有可伸缩的 没有弹性的东西，就是僵化，僵化就是死亡的代名词。这就是数据库死了的含义。
真的很难说明白了。
我现在就一个，你数据持久化的最终解决方案是什么？？
你的答案要是不用我就放弃我的观点了。
只要你能回答一个简单的问题.
用你所说位的对象缓存技术，如何实现复杂的对象关系索引和排序问题？
你只能说现在的框架设计不是基于数据库表格来设计，也就是说不是所谓的ERD为核心的框架设计，但是不能说出“数据库已死”这种谬论。只靠persistence是不可能实现数据库中稳定和强大的索引和关系模型的检验(norm 1,2,3,4,5)。在论坛里也有人提出过这个问题，就是数学上的迭代问题。到现在为止对象设计，在设计方面没有一个有效的和准确的模式可以依据来检查设计中的对象关系是否是在一个绝对正确的模式中。
还有一个问题，既然Hibernate的创始人也这么认为，我想问问，他为什么还要映射到数据库，它可以直接用xml或者byte来实现object persistence。这也是问题的问题所在，因为object之间的索引和关系不能再cache中或者persistence中实现。或者说即使实现了，最后的persistence技术也不能解决同步和保证关系的正确性。
在告诉你一个简单的例子，文件系统就是一种数据库，它的文件信息完全靠本身的数据库结构维护，大型系统更需要数据库来维护关系模型，OOP的关系也需要最后在数据库中维护。
还是要说，中国的程序员太喜欢说出绝对的话。这是误导，也是误人子弟。
我不用回答你的问题，因为你的问题和我提出的观点是南辕北辙。
你打好oo基础，先学好设计模式后，具备OO思维后。到时就会自然明白。
我理解你对我的指责，就象基督教和马克思主义之间争论一样，是两种完全不同的世界观，所幸的是，以前主流都是你们的声音，现在在Jdon我的声音已经发出5年多，越来越多人开始学习模式，越来越多人具备OO思维，越来越多人意识到软件不只是完成功能就行，可伸缩性在系统架构中已经成为第一设计要素，这就是真理的力量。
[该贴被banq于2008-09-22 09:04修改过]
你不是不用回答我的问题,是我的问题本来就密切关系到整个系统的设计方面.
你也不要武断的定论我提出的问题的初衷和观点.
我设计的每个系统都在应用设计模式,OO,DDD等等。但是这是两种事情。
就事论事，就题论题。数据库已死，你举出一个系统彻彻底底抛弃了数据库，完全靠persistence来运行的，你举得出来，那就叫见鬼了。
我说了，你所谓的数据库已死论，属于误人子弟的谬论。从设计上，可以应用对象设计模式来做，但是这根数据已死才使你所谓的两种不相干的事情。
这么说吧，如果是被这么多fresh bird众星捧月般的banq“大师”，你身为一个有着影响他人学习计算机程学设计方向的人，如果你不能耐心解答我们这些“不学无术”的人的问题，总是用迂回的战术来躲避，未免时间长了，你自己的身后的“光环”也会消失。
为了让你的框架继续有人使用，你的书可以继续续印下去，为什么不知面的跟我讨论一下深刻一点的问题呢。
我还是那句话，如果说有人妄下定论，就要拿出足够的证据，如果连最基本的反驳例证都没有，你何来的数据库之死这种结论？
你也放心，你可以跟我玩游记战，唐赛我，但是网络世界好的就是，傻子多，聪明的人更多。
来，大师，给我说一下如何解决我提出的那么简单的反驳，dare me, please!
banq 你还是无法解决数据持久化的问题。这个问题我想只要你做企业应用（通讯类的除外）都会要涉及。我只想知道你最终会用什么方式解决那？？
而且说实话，banq混淆了很多逻辑上的东西与物理上的东西，就像unix一个卷并不是代表一个硬盘，你一定要说那就是一个硬盘，一个硬盘存在性能问题，这只能说明你对这一层缺乏了解。