数据库已死

    我以前好像很少转载过别人写的文章, 大多情况下是看到不错的文章后,自己收藏起来. 今天看到一篇不错的文章, 对我有不少的感触,觉得自己仅仅收藏起来有些"自私",于是转载一下. 应该说, 自己以前也若多若少地想过类似的问题,如感兴趣,请看帖子"项目所得:一个非典型性改动带来的思考(三) 之项目设计"(http://rmn190.iteye.com/blog/339798)中的第二个所想,即"数据库实现业务逻辑".

    下面这篇文章解答我的一些疑问,同时也帮我指明了以后发展的一个方向.
    原文链接: http://www.jdon.com/artichect/dbdead.htm  数据库已死
---------------------------数据库已死------------
     现代软件和以往传统软件主要区别在于：现代软件基于internet互联网技术，运行于开放的网络环境，不象传统软件只是运行在封闭的局域网，运行环境的区别就决定了软件操作用户的多少，在一个开放互联网环境， 你的软件系统用户是不断增长，特别是那些对所有人群开放的社区网站系统，更是承受前所未有的访问负载。那么，这些软件系统承受的压力主要会集中在软件的哪个环节呢？如果你使用传统软件的设计思路，那么无疑压力都集中在数据库上。

　　随着用户的爆发量增长，在某个凌晨醒来时，你发现：数据库已死。

　　传统软件系统实则应该叫数据库软件系统，是一个数据库系统，开发这样的系统非常简单，成本 也非常低廉，只要根据需求先设计好数据表结构，然后，就找一些大学毕业生写大量SQL语句，虽然还使用 JAVA/PHP/.NET等语言，但实际上这些语言只是将SQL送往数据库执行的运输工，没有什么价值和地位。

　 　所以，这样的系统运行在互联网环境下以后，主要负载就集中在数据库的SQL运行上，也就是说：整个软件系统性能关键点就集中在数据库上了，数据库是性能 主角，是王者；虽然你购置了昂贵的Websphere/weblogic等应用服务器，但是由于Java只是运输工，根本起不到性能上负载分担的作用。

　　著名的社区网站MySpace就是因为一个好的idea，用户疯狂增长，但是系统却不能平滑承受增长的用户访问，这些用户访问网站缓慢、无法访问甚至丢失数据，他们经过几次伤筋动骨的架构升级，在微软SQLServer直接技术支持下， 好容易才勉强应付过去。看看他们痛苦经历，你是否也愿意再来一次呢？详细情况： http://www.jdon.com/jivejdon/thread/34601.html

　　从中可以看出，数据库性能微调和挖潜总是有限度的，对数据库性能优化提高性能的步伐永远赶不上用户增长量， 有人也提出数据库集群的概念，其实数据库集群是一个骗人概念，一般只是备份，在集群数量和failover上有制约， 否则，数据库巨头Oracle不会跑到JavaEE阵营摇旗呐喊，还最早推出EJB3服务器，并扬言要收购JavaEE过去老大 Bea Weblogic。

　　很显然，数据库成已经为软件系统的主要性能瓶颈了，单纯依靠数据库自救的方式已经行不通，是宣布数据库退出主角时候了，那么由谁来宣布：教皇数据库已死？无疑是Java。

　　Java社区早在本世纪初就提出中间件概念，用以取代数据库地位，实则就是将软件系统主要负载从数据库上转移到中间件服务器上，分担负载。 也就是说：Java社区提出：既然数据库已经成为瓶颈，修修补补也无济于事，不如放弃它，不再依赖它。

　　也就是说：Java不再做SQL的运输工，不再是跑龙套的了，而是主角，那么如何让Java成为主角呢？那必须依赖对象 这个概念，对象是生活在中间件服务器内存中，它又是数据库数据的业务封装，它和数据库有着 千丝万缕的关系，但是它又和关系数据库存在天然矛盾 ，两者水火不容。

　　过去，我们是将业务逻辑写成SQL送往数据库执行，导致数据库成为业务逻辑主要运行瓶颈，那么，如果我们将 业务逻辑用对象概念表达，而不是SQL，那么我们的业务逻辑就围绕内存中的对象反复计算，这样，负载不是集中在 对象运行的中间件服务器上（也就是应用服务器Weblogic/websphere/JBoss/Tomcat）？而对象/中间件都是用Java 语言表达的，无疑，这样的架构，Java才成为主角。

　　再进一步想想：如果我们从软件系统开始之初，就使用对象分析设计，不与数据库沾边，整个流程就完全OO，分析设计直至代码都摆脱了数据库影响，这个流程如下：

　　分析建模 细化设计(通过Evans DDD ) 架构设计 代码实现 调试测试 部署运行。

　　那么数据库在什么时候建立呢？数据库表结构的创建可以延缓到部署运行时，由Hibernate/EJB CMP/JPA等ORM技术自动实现。这样， 整个上游环节就不涉及数据库技术，而是使用更符合自然的表达OO方式，软件质量就更高了。我在J道网站已经大量阐述了如何从OO分析 到OO实现的过程，包括我的Jdon框架也直接支持这样一个自然方式。

　　现在，很多人已经理解，分析设计要用OO，但是数据库是运行阶段缺少不了的，确实，这是正确观点，我们夺取数据库的王位，不是将它打倒，只是理性和平移交权力重心而已，数据库退出主角地位，让位于Java中间件，也预示着过去数据库为王的时代的结束， 但是数据库会和操作系统一样，成为我们现代软件系统一个不可缺少重要的基础环节。

　　正是基于这样事实，虽然我早在2005年喊出“数据库时代的终结 一文，回帖长达几百贴， 大部分是怀疑论，不信论，其实2003年国外TSS就有一篇“给数据库休息吧 ” （休息不代表退休，而是退居幕后，就象操作系统作用一样），由此可见，由于传统观点影响和不及时与国际新思想同步，国内数据库保皇派还是有相当人数的。我 BanQ人微言轻，抛出这些观点被保皇派讥讽为所疯话，那么看看，著名ORM框架Hibernate和SEAM框架创始人Gavin King的一段观点：

　　In almost all enterprise applications, the database is the primary bottleneck, and the least scalable tier of the runtime environment. 数据库成为了大多数企业应用的主要瓶颈，也成为了运行环境中最不具伸缩性的层。... PHP/Ruby的用户会说什么都不共享（share nothing）的架构照样具有很好的伸缩性，.... 这些傻瓜真正想的是“除了数据库以外什么都不共享(Share nothing except for the database)”的架构。更多参看这里

　 　所谓伸缩性，就是弹性，整个软件架构既支持小负载运行，也支持大负载支持，只要增加服务器即可； 由于软件系统负载已经从SQL转移到内存中的对象上，那么我们就可以通过增加这些应用服务器数量，通过分布式计算甚至云计算，达到业务对象在多台应用服务 器之间传递共享，而不必通过数据库这个环节，既减轻数据库负载，又能轻松扩充性能，不必走 集中试大型主机之路，只要添置低廉PC服务器即可。经过权威测试：websphere/weblogic的20台PC服务器集群 性能不亚于一台SUN/IBM的中型机，性价比已经一目了然了。

　　JavaEE的服务器的集群相对于Linux等操作系统集群 的好处在于：JavaEE集群 能够针对某个繁忙负载大的具体业务功能进行集群，换句话说： 就是做到精确制导，精确解决问题，而显然，Linux操作系统的集群则无法直至业务核心的。

　　从另外一个方面看：虽然现在PHP号称走上对象路线，Ruby的铁轨开始铺进企业，但是他们的运行环境实则依赖数据库的， 特别是Ruby On Rails还是最适合Evans DDD 对象建模路线，但是目前来讲还是"披着羊皮的狼"，批着DDD，实则是以数据库中心。当然相信 ROR等将来会提供分布式计算环境，但是JavaEE在2002年时就通过EJB以及分布式缓存 成熟稳定地提供分布式计算的中间件，并且已经大量成熟应用。

　　本文结束以前，我相信大家明白，在众多语言平台竞争中，为什么Java能够击败过去拳王数据库，夺得新的拳王冠军，以及他的特点所在。有人可能会说：你忘记谈.NET了，这个不用我回答你，用微软中国董事长张亚勤的话回答：8年前.NET战略很天真 ， 你会将你的重要业务企业计算依赖一个很天真不成熟的技术吗？除非你自己也很天真:)。

2003年旧文Give your DB a Break!

云计算成为现实

(OO + 分布式计算) = 软件架构的方向

著名社交网站LinkedIn的Java架构技术

数据库时代的终结

软件最大的追求是什么？

Seam文档摘

关于OO和数据库再次探讨

跨越分析与设计的鸿沟

程序设计究竟是做什么事