现在的位置: 首页 > 综合 > 正文

数据库时代的终结

2013年12月06日 ⁄ 综合 ⁄ 共 5058字 ⁄ 字号 评论关闭
以数据库为核心的软件时代已经过去,数据库时代早已结束,当我看到J2EE征途中那么多人在对象和数据库之间彷徨痛苦ing的时候,我想我该出来喊一声了。

  其实这句话在几年前肯定有人喊过,因为中间件时代的来临,实际意味着数据库时代终结,正所谓一山无二虎:如果你重视数据库,你的J2EE系统就无法完全OO,只有你忽视数据库,你的系统才有可能完全迈向OO,至于数据库性能调优等特定功能都可交由EJB容器或O/R Mapping工具实现。

  很多年前,包括我自己在内的大部分企业程序员都是从数据库开始我们的职业生涯,最早的是dBase/FoxPro,后来有了 SQL系列数据库, Oracle将数据库时代推向了顶峰。

  每当有一个新项目时,第一步就是首先设计出数据表结构(Table Schema),然后开始使用SQL语句实现业务逻辑,这种开发模式一直重复,就是后来加入了DelPhI/VB,他们也只是承担图形显示实现,这种C/S结构带来最大问题是:非常难于维护,修改起来,迁一动百。

  软件的生命在于运动,当它需要发展时,最棒的软件人员如果对他也束手无策,这是谁的悲哀?

  现在更多人开始接受B/S结构,但是他们中很多人还没有真正明白为什么需要B/S结构,B/S代表的多层架构才是真正目的(因此,伪多层的B/S系统遍地皆是)。

  多层架构实际是将以前系统中的显示功能、业务运算功能和数据库功能完全分开,杜绝彼此的耦合与影响,从而实现松耦合和良好的可维护性。

  一. 从设计上说:由于实现层次完全分离,业务运算功能成为一种中间功能(中间层),它不依赖具体的表现层技术(Jsp/Html applet等),也不依赖具体数据库技术(Oracle/SQL Server),业务运算功能运行在J2EE应用服务器中,当我们的业务运算功能不再依赖数据库时,是否意味着数据库已经不是重点?

  二. 当然,多层结构带来了性能问题:客户端访问数据库中的数据时,通常需要经过多个层次,非常耗费性能, 如何尽量减少数据库访问是J2EE应用系统首要解决的问题,使用存储过程并没有解决这个问题,存储过程的执行还是属于后端,并没有缩短客户端请求所要经历的坎坷路途。

  解决性能问题的根本解决之道是使用对象缓存,现在, 64位CPU提供的巨大内存空间为单台缓存计算提供了硬件基础,更重要的是,这种缓存计算是可伸缩的,通过集群缓存机制(如JBossCache), 通过增加应用服务器的数量,可以提高整个业务逻辑层的缓存计算能力,抛弃过去那种为内存斤斤计较的老思维吧。

  三. 在系统分析之初是否首先需要数据表设计呢?回答是否定的, 以UML为代表面向对象的分析设计方法已经成为强大工具,随着面向模型驱动分析设计(MDA/MDD/DDD)的普及, 面向数据库分析方法正在逐步被抛弃,拥有深厚传统数据库分析习惯的程序员必须面对和接受这种挑战。

  纵观整个J2EE系统开发过程,数据库已经从过去的中心位置降为一种纯技术实现,数据库只是状态持久化的一种手段(文件是另外一种实现手段);什么是持久化?这是相对于内存缓存状态而言,持久化就是当内存断电情况下能永久保存状态数据,但是如果J2EE应用服务器是7X24小时集群运行;几乎永不当机,是否有持久化的必要呢?

  很显然,数据库已经沦为与操作系统中文件系统同样的层面,以它为中心的时代真的结束了,IBM早期将DB2数据库开源已经强烈向我们昭示这点。

  对于J2EE初学者来说,尽早抛弃过去的两种影响:过程语言编程习惯和以数据库为中心的设计习惯,从全新的面向对象角度(OOA、OOD和OOP、AOP)来设计开发你的J2EE系统,J2EE设计开发三件宝:Model、Patterns和Framework

  以上不只是理论,而是我每天正在做的,如果你也是或赞同请广为传播,唤醒更多彷徨痛苦的初学者。

相关文章:

讨论旧系统如何改造成面向OO的?

面向对象建模与数据表建模两种分析设计方法的比较

面向对象与领域建模

DDD(Domain-Driven Design领域驱动设计)实战

Java项目开发中常见根本性认识误区

领域模型驱动设计(DDD)之模型提炼

Java EE/J2EE面向对象编程之道

使用AOP组合JBossCache实现对象缓存

OSCache降低数据库负载

使用缓存提高Web应用系统性能

Java企业系统架构选择考量

状态对象:数据库的替代者

新产品:面向对象数据库db4O

When to use an Embedded ODBMS

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

数据库已死

更多关于数据表分析讨论

讨论

============================

数据库已死

 

  现代软件和以往传统软件主要区别在于:现代软件基于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年喊出“数据库时代的终结一文,回帖长达几百贴, 大部分是怀疑论,不信论,由此可见,由于传统观点影响和不及时与国际新思想同步,国内数据库保皇派还是有相当人数的。我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战略很天真, 你会将你的重要业务企业计算依赖一个很天真不成熟的技术吗?除非你自己也很天真:)。

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

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

数据库时代的终结

软件最大的追求是什么?

Seam文档摘

关于OO和数据库再次探讨

跨越分析与设计的鸿沟

程序设计究竟是做什么事

发表讨论

抱歉!评论已关闭.