2008IT技术精英年会数据库分论坛热点扫描
2008年1月13日，第二届中国IT技术精英年会的数据库分论坛在九华山庄举行，和去年一样，数据库分论坛依然成为本年度最为火热的论坛。来自于业界的技术专家Sybase软件中国有限公司技术总监 卢东明，阿里巴巴首席DBA，oracle数据库ACE冯春培，以及IBM软件公司技术经理刘晶炜，给大家做了三场精彩的技术讲座和报告。
商业智能呼唤革命性的技术
Sybase软件中国有限公司技术总监 卢东明指出，数据规模的增长，导致的数据存储和传输，已经成为当今数据库及商务智能最大的挑战。我们花在存储方面的开销包括：硬件开销，折旧开销，管理开销，人员开销已经达到了惊人的地步；另外，尽管在过去的25年中，硬盘的容量增长了10000倍，传输率增长了100倍，但有效传输带宽（ETB）实际上下降了100倍。这些都成为数据库仓库和商业智能性能方面最大的挑战。
卢东明认为，BI市场方面，同样是需要专业的东西做专业的事情，就是说需要专门的数据库产品来支撑企业的数据仓库，数据挖掘等BI应用，Sybase给出的答案就是Sybase IQ系列产品和方案。这一观点引发参会网友和技术专家热烈的讨论。
Sybase IQ的诸多特性，引起来大家的关注，一个是压缩技术，IQ里面的压缩技术是自动有的，不需要设定或者是制订才能产生的。 卢东明介绍，Sybase并没有把IQ定位成一个压缩型的数据库而把它定位成列式数据库，也就是它的根本，它的本原第一步是列式数据库，压缩的特性是随着列式数据库而来的。比如说DB2九版本也做到了某些压缩的功能甚至非常好，但是跟IQ的理念不一样，IQ是每个列自动进行压缩，但有些数据也是不可压缩的。
对于商业智能，厂商都在盲人摸象
另外，与会专家也谈到了数据仓库项目成败的问题。除了技术问题以外，领域专家和业务方面的问题，也是导致数据仓库项目失败的重要原因。统计数据表明，数据仓库项目80%都是失败的。网友谈到，不管是自己做项目，还是带项目也好，实际上自己也挺失望的，搞不清楚数据仓库的概念是成功的还是失败的。
大部分专家赞同数据仓库不光是一个存数据的问题，最重要的一个问题是业务问题，而本质上是业务问题。这些东西一定需要有一些业务专家来做这些东西，比如说做一些业务建模，还有质量的问题，不同业务数据系统数据质量可能存在一些问题，最终得到的结果整合过来以后得到的期望跟用户有一定的差距，再一个问题是从业务数据库到数据仓库本身需要转换，当中发生一些数据的损耗，这三个问题才是最重要的。发生任何一个问题，做数据仓库都不是成功的。
卢东明解释了关于数据仓库项目失败率较高的原因，一个是数据仓库跟传统的业务型的项目比起来周期比较长，在它没有成功的时候我们是不是把它叫做失败的，这是有商榷的。就好象大家做车一样，从中国汽车工业开始，在没有做出很成功的车型或者企业的时候，我们是不是把中国的汽车工业称为失败呢，我觉得不应该，大家都还在探索，国际上也不是每个都能成功，但是大家还是看到商务智能越来越有迫切性了。
卢东明认为，对于ETL或者前端展示的作用在整个BI系统工程的过程中都占有它的地位，在整体的架构上面，Sybase IQ只是做了一个其中的环节而已，并不是说我们解决了整体的东西，但是每个环节如果都能够有各自的厂商进行突破性的进展，我想可能你会发现整个项目会比现在想象得容易得多。
“就好象我手机上面就有一个Excel的程序，这个东西十年前不可想象的，那个时候要想让企业做一个电子表格的东西，他也会认为这是非常难处理的事情，所以计算机的发展既给大家一个视角，也给大家一个历史观，也就是说计算机永远在处理现在难办的事情。对于ETL的过程，其实很多技术的进展也对整个体系的应用开发理念提出各种各样的挑战或者是各种新的见解，比如说ETL，好像大家觉得是顺理成章的事情，一个项目有原数据，转换要需要ETL，但是现在你会发现，有很多过程放在数据库里面比放在ETL里面有成几千倍的提高，现在有一个理念叫ELT，就是我抽取出来以后，先放到数据库里面，先L，这个比用ETL工具快不知道多少倍。那么这个概念是怎么提出来的，还是由于列式数据库能够显示出来，如果没有这样的突破的话，我想ELT这个概念也出不来。”
卢东明总结到，厂商的各项功能及产品实现对于商业智能而言，就像盲人摸象一样，没有人能够看到商务智能是一个整体的大象怎么样走，怎么样运转，所以每个公司都围绕着大象的某一个角度在做事情
大型应用设计中的数据库架构
阿里巴巴首席DBA冯春培，在数据库管理工作的第一线，对大型应用开发的数据库系统架构，大规模数据库的管理有着深刻的体会和见解。他认为，大规模应用设计的前期，数据库系统架构师的缺席，是导致后期数据库分布式存贮，管理，维护的重要原因。在应用设计时，数据库架构师如何发挥作用，特别是在生产环境中，数据库架构师的职责和任务有哪些，冯春培和大家分享了他在阿里巴巴数据库管理，架构和设计的的经验。
冯春培首先分析了DBA角色产生的过程以及随后的分化。数据在今天变得越来越重要，于是产生了有人来管理维护数据库，不能丢，有些企业像金融企业丢了跟钱都有关系，电信那边少收点钱还没有关系。当然有人管理数据库，运用的问题就凸显出来了，于是就产生了数据库的管理维护的这些DBA很难有精力去支持前端的应用，前端应用的很多需求太多太复杂了，人的精力是有限的，于是DBA慢慢催生了两种角色，一个叫管理DBA，是侧重于后台系统的维护、备份，考虑数据安全，另外也催生了开发DBA的角色，其实很多公司也在慢慢催生这种角色，我们公司这几年一直在坚持这两个方面，开发DBA刚开始跟开发部门打交道，后来发现总是跟他们打交道效率不高，因为一旦到开发部门这儿很多需求就确定了，于是开发DBA的触角就伸到需求开发，甚至已经伸展到运营部门那里，非正式流程上的民间的组织行为就产生了，然后呢，经常跟运营部门打交道之后他们也明白我们的重要性，也会跟我们沟通，我们有个感觉说，比如说下半年，下个季度公司里面运营部门的人想干什么，我们有什么准备，于是开发的这条线就有一个好的模型出来了。
DBA角色的局限性
产生了这两个角色以后，慢慢地我们发现这两种角色已经满足不了我们对未来发展的期望了，为什么呢？因为某一个具体的产品DBA或者某一个开发DBA所面临的是一些很具体的需求，要解决的是一个当前的，跟当前相关的很具体的问题，它很难去考虑或者推动我今年怎么做，我明年后面会变成什么样子，因为有时候一个长期的方向跟短期的行为可能方向并不是一样的，是分离的，里面还牵扯到方方面面的因素以及成本的问题，比如你在公司里面打算干五年和打算干一年考虑是不一样的，所以要考虑价格的问题，比方对于产品级DBA来讲，要高度的是什么问题？最基本的说运用的压力越来越增加。一个小型机可能只有四颗CPU，16级内存，后来换成八颗CPU，32级内存。产品DBA还要决定一台机器承载不了的时候我应该怎么做，通过多台机器分担压力，以及可靠性问题的解决。产品DBA比较现实地在考虑这样的问题。
数据库的规划离不开存储
冯春培认为，数据库的规划和存储技术也息息相关。更长远一点还要考虑到，除了数据库的层面的选择，还有主机、存储，这几年大家都在流行几个概念，虚拟化主机、虚拟化存储，操作系统级别的，大家都在炒这些概念，但是这些概念落到实出，大家的期望是任何一个节点出问题了能持续地提供服务，还要解决数据库扩展的问题，承载更大的压力。
开发DBA这边同样会跟产品DBA配合，他要考虑什么问题，我们的数据量越来越大，应用越来越复杂，比如说淘宝的压力也越来越大，压力一两年可能翻一倍，或者一年翻两倍，你怎么应对，单纯靠扩展主机的性能或者一两个节点，从一个节点增加到三四个节点可能还是不能满足要求，数据库要拆分，怎么拆分法，流行的叫水平分割和垂直分割的问题，垂直分割比如说把大运用拆成都独立的小运用。这高垂直拆，但是垂直拆的时候单个业务可能有非常大的量，可能有几亿条数据，访问量每天非常频繁，现实的需求在我们很多具体的环境中冲突特别强烈，你按照这个业务拆也已经满足不了要求了，就要考虑水平的分法，数据按照用户分还是怎么分，集群里面，拆分了以后，水平分割之后的数据库，它实际上是由一组数据库构成的，每个单点还要考虑安全性的问题，它也不是承担某一个具体应用的人所能决定的，往往变化，甚至在某一个具体的公司里面，在技术上基本上是一个变革，架构上的彻彻底底的变革，国外亚马逊等在一两年前就已经完成了变革，国内现在正在思考这个问题，比如说移动，包括我们公司，也在考虑这些东西怎么个分法，怎么解决扩展性的问题，这个问题其实就要站在一个相当高的高度看，因为普通的角色产品DBA和开发DBA很难承载这个东西，因为这不是数据库的问题了，应用要配合做很多的改造，你必须获得技术部门非常强有力的支持，投入很大的资源，这个事情一做可能要一年两年甚至三年才能完成改造，这就不是我们普通的角色定义能完成得了的，于是我们在想，同样，开发那边有架构设计的，我们DBA这边也要配套地催生做DB架构的角色来跟运用开发的架构遥相呼应，大家一起讨论未来两年我们要做成什么样子，最近半年我们要做什么事情，下半年做什么事情。做这个计划。这个情况的产生呢，基本上跟我们今天要谈论的已经是保持一致了，都到同一个方向上来了。
数据库说起来很简单，如果画张图就是一个垂直分割，下面水平分割，每一个具体的时限。如果没有很大规模的话，可能还是牵扯到把有些应用拆分到其他的地方，但是这样的一些动作会导致我们数据库之间会不会产生数据同步，比如说你垂直分割的时候分到什么力度，太粗了满足不了，太细了维护成本太高。当然对于某个具体的点承载不了的时候，有的人也会考虑读写分离，一个写四个读。用这样的读写分离的方式来解决可靠性的问题，一个点坏了我并不在意，不像我们以前一样提心吊胆，07年我管了十几二十套数据库，可靠性要控制在一个层面上，到底是多少，我不知道各位有没有做过统计，比如说07年我的数据库117分钟故障，当然是分布到很多数据库上，这117分钟是影响应用的，做了很好的分离之后可能就不那么严重了，坏了一个没关系，我移到别的地方去就可以了，画图很容易，道理几分钟我就明白了，但是一旦做起来其实里边有非常多的问题，主机和存储的搭配，操作系统版本的选择，新功能要不要用啊，里头有很细的问题，管理数据库的人有很多的问题，淘宝现在一个表加一个列，也要有一个人凌晨四点钟才能做这个事情，在大规模的运用上有很多的问题。
那么做数据库的架构层面的设计和实施，你要能站在上面描绘这个蓝图，也要能贯彻实施，做成一个具体的东西，然后管理、维护、匹配都得跟上，这一整套下来才能使得我们的应用，那个时候比如说我们DBA项目组就可以跟老板说，我支持你可扩展、保障地的可用性，没问题。这是我的终极目标，我不希望说像以前一样总是听到各个业务部门回应我说，我们这个数据库什么时候就不行了，撑不住了，你跟我说到底能够支撑到什么时候，由于业务发展，有时候具有爆炸性，不像传统行业一样，我就非常难以回答，这也是我的一个痛，所以说我也是希望未来的某一天，也许一年、两年，那个时候我可以跟大家交流时候说，我们的数据库非常好，可扩展、可靠性非常好。现在也许你的系统还比较小，但是总有一天越来越多的企业会提出这样的要求，当这个机遇降临的时候，你就可以勇敢地站起来，承担责任，体现你的价值。
他的话题，引发了参会诸多高级DBA的共鸣和响应。
XML数据库在中国的应用状况
调查数据显示，2007年，IBm数据库产品DB2取得惊人增长。笔者看到IBM官方内部目前还未对外公布的统计数据是增长了140%。刘晶炜在这一数据的基础上，做了中国XML 数据库的应用分析的报告。可以看出，经过一年多的推广，IBm新版数据库DB2 V9的pureXml特性取得了巨大的成功，成为吸引新用户采纳的重要卖点。
另外一个因素，关系数据库面临巨大挑战，难以应对具有复杂、多变结构的数据。关系模型在以下方面面临着挑战：严格的数据及关系定义，高性能的索引机制，缺乏数据模型上的灵活性以及只能适合固定的结构化数据等。这些情况，大部分数据库应用者和开发者都有所了解，也希望关系数据库在这些方面有所突破。
刘晶炜以医疗领域数据和税务行业应用为例，说明了Xml数据库如何解决关系数据库难以解决的应用场景和问题。
刘晶炜谈到，今天比较难的是做出一个系统能适应不同的需求。我们看到更多的一些变化是今天IT层面上的，其实我跟银行的人都做过探讨，今天IT尤其在数据层上面产生非常多的挑战，涉及到架构层上的挑战，过去十年二十年我们是以一个固定的业务需求，固定的业务需求直接推到固定的业务逻辑，这种逻辑套过来是一个一个单独的业务系统，数据库并不重要，只是保证系统稳定运行就好了，效率不好了我加台机器，这是我们过去关注的重点，今天碰到的很大问题在哪，数据有了之后，要开始发生交互了。但是这种运用越做越多后发现数据的规划不合理，因为你这些数据应该不应该归属于你这个业务系统，开始只是在业务功能上思考这个问题，国外也是这个思路，走到一定程度发现，以前每个城市都是一个一个自己的房子建起来，建起来之后发现供暖、供电不应该由自己来管理，IT结构也是这样，在数据层上一些大的企业认识到必须提到整体平台上。
SOA必须从表层走向流程，再走向数据，一层层深入。我们希望未来的数据，银行开户这个动作，在网上可能开户、开信用卡可能开户，很多环节可以开户，但是今天开户的行为被封装在某个业务模型中，处理的逻辑、数据也不一致，这个剥离出来以后，对数据不需要人为干预的一些操作浓缩成为业务服务，来给各个功能系统服务，这块会一层层，从底层的服务，这种概念已经谈了好几年了，这种服务的时候整个的思考逻辑是一种对象化的思考，在每个层级你会看到，它的接口衔接都基本上已经开始XML，这样的大势情况下，有什么理由我们数据库组织不应该改变。这也是带来一个深层次的变化。
嘉宾的演讲结束后，现场数据库技术人员围绕嘉宾就相关技术问题进行讨论咨询，多种技术观点在会场上交流碰撞！与会数据库专家表示，这次数据库论坛不论是从参会人员的素质和层次，还是从交流的话题来看，都可称得上是目前中国最高水平的数据库技术沙龙。
商业智能呼唤革命性的技术
Sybase软件中国有限公司技术总监 卢东明指出，数据规模的增长，导致的数据存储和传输，已经成为当今数据库及商务智能最大的挑战。我们花在存储方面的开销包括：硬件开销，折旧开销，管理开销，人员开销已经达到了惊人的地步；另外，尽管在过去的25年中，硬盘的容量增长了10000倍，传输率增长了100倍，但有效传输带宽（ETB）实际上下降了100倍。这些都成为数据库仓库和商业智能性能方面最大的挑战。
卢东明认为，BI市场方面，同样是需要专业的东西做专业的事情，就是说需要专门的数据库产品来支撑企业的数据仓库，数据挖掘等BI应用，Sybase给出的答案就是Sybase IQ系列产品和方案。这一观点引发参会网友和技术专家热烈的讨论。
Sybase IQ的诸多特性，引起来大家的关注，一个是压缩技术，IQ里面的压缩技术是自动有的，不需要设定或者是制订才能产生的。 卢东明介绍，Sybase并没有把IQ定位成一个压缩型的数据库而把它定位成列式数据库，也就是它的根本，它的本原第一步是列式数据库，压缩的特性是随着列式数据库而来的。比如说DB2九版本也做到了某些压缩的功能甚至非常好，但是跟IQ的理念不一样，IQ是每个列自动进行压缩，但有些数据也是不可压缩的。
对于商业智能，厂商都在盲人摸象
另外，与会专家也谈到了数据仓库项目成败的问题。除了技术问题以外，领域专家和业务方面的问题，也是导致数据仓库项目失败的重要原因。统计数据表明，数据仓库项目80%都是失败的。网友谈到，不管是自己做项目，还是带项目也好，实际上自己也挺失望的，搞不清楚数据仓库的概念是成功的还是失败的。
大部分专家赞同数据仓库不光是一个存数据的问题，最重要的一个问题是业务问题，而本质上是业务问题。这些东西一定需要有一些业务专家来做这些东西，比如说做一些业务建模，还有质量的问题，不同业务数据系统数据质量可能存在一些问题，最终得到的结果整合过来以后得到的期望跟用户有一定的差距，再一个问题是从业务数据库到数据仓库本身需要转换，当中发生一些数据的损耗，这三个问题才是最重要的。发生任何一个问题，做数据仓库都不是成功的。
卢东明解释了关于数据仓库项目失败率较高的原因，一个是数据仓库跟传统的业务型的项目比起来周期比较长，在它没有成功的时候我们是不是把它叫做失败的，这是有商榷的。就好象大家做车一样，从中国汽车工业开始，在没有做出很成功的车型或者企业的时候，我们是不是把中国的汽车工业称为失败呢，我觉得不应该，大家都还在探索，国际上也不是每个都能成功，但是大家还是看到商务智能越来越有迫切性了。
卢东明认为，对于ETL或者前端展示的作用在整个BI系统工程的过程中都占有它的地位，在整体的架构上面，Sybase IQ只是做了一个其中的环节而已，并不是说我们解决了整体的东西，但是每个环节如果都能够有各自的厂商进行突破性的进展，我想可能你会发现整个项目会比现在想象得容易得多。
“就好象我手机上面就有一个Excel的程序，这个东西十年前不可想象的，那个时候要想让企业做一个电子表格的东西，他也会认为这是非常难处理的事情，所以计算机的发展既给大家一个视角，也给大家一个历史观，也就是说计算机永远在处理现在难办的事情。对于ETL的过程，其实很多技术的进展也对整个体系的应用开发理念提出各种各样的挑战或者是各种新的见解，比如说ETL，好像大家觉得是顺理成章的事情，一个项目有原数据，转换要需要ETL，但是现在你会发现，有很多过程放在数据库里面比放在ETL里面有成几千倍的提高，现在有一个理念叫ELT，就是我抽取出来以后，先放到数据库里面，先L，这个比用ETL工具快不知道多少倍。那么这个概念是怎么提出来的，还是由于列式数据库能够显示出来，如果没有这样的突破的话，我想ELT这个概念也出不来。”
卢东明总结到，厂商的各项功能及产品实现对于商业智能而言，就像盲人摸象一样，没有人能够看到商务智能是一个整体的大象怎么样走，怎么样运转，所以每个公司都围绕着大象的某一个角度在做事情
大型应用设计中的数据库架构
阿里巴巴首席DBA冯春培，在数据库管理工作的第一线，对大型应用开发的数据库系统架构，大规模数据库的管理有着深刻的体会和见解。他认为，大规模应用设计的前期，数据库系统架构师的缺席，是导致后期数据库分布式存贮，管理，维护的重要原因。在应用设计时，数据库架构师如何发挥作用，特别是在生产环境中，数据库架构师的职责和任务有哪些，冯春培和大家分享了他在阿里巴巴数据库管理，架构和设计的的经验。
冯春培首先分析了DBA角色产生的过程以及随后的分化。数据在今天变得越来越重要，于是产生了有人来管理维护数据库，不能丢，有些企业像金融企业丢了跟钱都有关系，电信那边少收点钱还没有关系。当然有人管理数据库，运用的问题就凸显出来了，于是就产生了数据库的管理维护的这些DBA很难有精力去支持前端的应用，前端应用的很多需求太多太复杂了，人的精力是有限的，于是DBA慢慢催生了两种角色，一个叫管理DBA，是侧重于后台系统的维护、备份，考虑数据安全，另外也催生了开发DBA的角色，其实很多公司也在慢慢催生这种角色，我们公司这几年一直在坚持这两个方面，开发DBA刚开始跟开发部门打交道，后来发现总是跟他们打交道效率不高，因为一旦到开发部门这儿很多需求就确定了，于是开发DBA的触角就伸到需求开发，甚至已经伸展到运营部门那里，非正式流程上的民间的组织行为就产生了，然后呢，经常跟运营部门打交道之后他们也明白我们的重要性，也会跟我们沟通，我们有个感觉说，比如说下半年，下个季度公司里面运营部门的人想干什么，我们有什么准备，于是开发的这条线就有一个好的模型出来了。
DBA角色的局限性
产生了这两个角色以后，慢慢地我们发现这两种角色已经满足不了我们对未来发展的期望了，为什么呢？因为某一个具体的产品DBA或者某一个开发DBA所面临的是一些很具体的需求，要解决的是一个当前的，跟当前相关的很具体的问题，它很难去考虑或者推动我今年怎么做，我明年后面会变成什么样子，因为有时候一个长期的方向跟短期的行为可能方向并不是一样的，是分离的，里面还牵扯到方方面面的因素以及成本的问题，比如你在公司里面打算干五年和打算干一年考虑是不一样的，所以要考虑价格的问题，比方对于产品级DBA来讲，要高度的是什么问题？最基本的说运用的压力越来越增加。一个小型机可能只有四颗CPU，16级内存，后来换成八颗CPU，32级内存。产品DBA还要决定一台机器承载不了的时候我应该怎么做，通过多台机器分担压力，以及可靠性问题的解决。产品DBA比较现实地在考虑这样的问题。
数据库的规划离不开存储
冯春培认为，数据库的规划和存储技术也息息相关。更长远一点还要考虑到，除了数据库的层面的选择，还有主机、存储，这几年大家都在流行几个概念，虚拟化主机、虚拟化存储，操作系统级别的，大家都在炒这些概念，但是这些概念落到实出，大家的期望是任何一个节点出问题了能持续地提供服务，还要解决数据库扩展的问题，承载更大的压力。
开发DBA这边同样会跟产品DBA配合，他要考虑什么问题，我们的数据量越来越大，应用越来越复杂，比如说淘宝的压力也越来越大，压力一两年可能翻一倍，或者一年翻两倍，你怎么应对，单纯靠扩展主机的性能或者一两个节点，从一个节点增加到三四个节点可能还是不能满足要求，数据库要拆分，怎么拆分法，流行的叫水平分割和垂直分割的问题，垂直分割比如说把大运用拆成都独立的小运用。这高垂直拆，但是垂直拆的时候单个业务可能有非常大的量，可能有几亿条数据，访问量每天非常频繁，现实的需求在我们很多具体的环境中冲突特别强烈，你按照这个业务拆也已经满足不了要求了，就要考虑水平的分法，数据按照用户分还是怎么分，集群里面，拆分了以后，水平分割之后的数据库，它实际上是由一组数据库构成的，每个单点还要考虑安全性的问题，它也不是承担某一个具体应用的人所能决定的，往往变化，甚至在某一个具体的公司里面，在技术上基本上是一个变革，架构上的彻彻底底的变革，国外亚马逊等在一两年前就已经完成了变革，国内现在正在思考这个问题，比如说移动，包括我们公司，也在考虑这些东西怎么个分法，怎么解决扩展性的问题，这个问题其实就要站在一个相当高的高度看，因为普通的角色产品DBA和开发DBA很难承载这个东西，因为这不是数据库的问题了，应用要配合做很多的改造，你必须获得技术部门非常强有力的支持，投入很大的资源，这个事情一做可能要一年两年甚至三年才能完成改造，这就不是我们普通的角色定义能完成得了的，于是我们在想，同样，开发那边有架构设计的，我们DBA这边也要配套地催生做DB架构的角色来跟运用开发的架构遥相呼应，大家一起讨论未来两年我们要做成什么样子，最近半年我们要做什么事情，下半年做什么事情。做这个计划。这个情况的产生呢，基本上跟我们今天要谈论的已经是保持一致了，都到同一个方向上来了。
数据库说起来很简单，如果画张图就是一个垂直分割，下面水平分割，每一个具体的时限。如果没有很大规模的话，可能还是牵扯到把有些应用拆分到其他的地方，但是这样的一些动作会导致我们数据库之间会不会产生数据同步，比如说你垂直分割的时候分到什么力度，太粗了满足不了，太细了维护成本太高。当然对于某个具体的点承载不了的时候，有的人也会考虑读写分离，一个写四个读。用这样的读写分离的方式来解决可靠性的问题，一个点坏了我并不在意，不像我们以前一样提心吊胆，07年我管了十几二十套数据库，可靠性要控制在一个层面上，到底是多少，我不知道各位有没有做过统计，比如说07年我的数据库117分钟故障，当然是分布到很多数据库上，这117分钟是影响应用的，做了很好的分离之后可能就不那么严重了，坏了一个没关系，我移到别的地方去就可以了，画图很容易，道理几分钟我就明白了，但是一旦做起来其实里边有非常多的问题，主机和存储的搭配，操作系统版本的选择，新功能要不要用啊，里头有很细的问题，管理数据库的人有很多的问题，淘宝现在一个表加一个列，也要有一个人凌晨四点钟才能做这个事情，在大规模的运用上有很多的问题。
那么做数据库的架构层面的设计和实施，你要能站在上面描绘这个蓝图，也要能贯彻实施，做成一个具体的东西，然后管理、维护、匹配都得跟上，这一整套下来才能使得我们的应用，那个时候比如说我们DBA项目组就可以跟老板说，我支持你可扩展、保障地的可用性，没问题。这是我的终极目标，我不希望说像以前一样总是听到各个业务部门回应我说，我们这个数据库什么时候就不行了，撑不住了，你跟我说到底能够支撑到什么时候，由于业务发展，有时候具有爆炸性，不像传统行业一样，我就非常难以回答，这也是我的一个痛，所以说我也是希望未来的某一天，也许一年、两年，那个时候我可以跟大家交流时候说，我们的数据库非常好，可扩展、可靠性非常好。现在也许你的系统还比较小，但是总有一天越来越多的企业会提出这样的要求，当这个机遇降临的时候，你就可以勇敢地站起来，承担责任，体现你的价值。
他的话题，引发了参会诸多高级DBA的共鸣和响应。
XML数据库在中国的应用状况
调查数据显示，2007年，IBm数据库产品DB2取得惊人增长。笔者看到IBM官方内部目前还未对外公布的统计数据是增长了140%。刘晶炜在这一数据的基础上，做了中国XML 数据库的应用分析的报告。可以看出，经过一年多的推广，IBm新版数据库DB2 V9的pureXml特性取得了巨大的成功，成为吸引新用户采纳的重要卖点。
另外一个因素，关系数据库面临巨大挑战，难以应对具有复杂、多变结构的数据。关系模型在以下方面面临着挑战：严格的数据及关系定义，高性能的索引机制，缺乏数据模型上的灵活性以及只能适合固定的结构化数据等。这些情况，大部分数据库应用者和开发者都有所了解，也希望关系数据库在这些方面有所突破。
刘晶炜以医疗领域数据和税务行业应用为例，说明了Xml数据库如何解决关系数据库难以解决的应用场景和问题。
刘晶炜谈到，今天比较难的是做出一个系统能适应不同的需求。我们看到更多的一些变化是今天IT层面上的，其实我跟银行的人都做过探讨，今天IT尤其在数据层上面产生非常多的挑战，涉及到架构层上的挑战，过去十年二十年我们是以一个固定的业务需求，固定的业务需求直接推到固定的业务逻辑，这种逻辑套过来是一个一个单独的业务系统，数据库并不重要，只是保证系统稳定运行就好了，效率不好了我加台机器，这是我们过去关注的重点，今天碰到的很大问题在哪，数据有了之后，要开始发生交互了。但是这种运用越做越多后发现数据的规划不合理，因为你这些数据应该不应该归属于你这个业务系统，开始只是在业务功能上思考这个问题，国外也是这个思路，走到一定程度发现，以前每个城市都是一个一个自己的房子建起来，建起来之后发现供暖、供电不应该由自己来管理，IT结构也是这样，在数据层上一些大的企业认识到必须提到整体平台上。
SOA必须从表层走向流程，再走向数据，一层层深入。我们希望未来的数据，银行开户这个动作，在网上可能开户、开信用卡可能开户，很多环节可以开户，但是今天开户的行为被封装在某个业务模型中，处理的逻辑、数据也不一致，这个剥离出来以后，对数据不需要人为干预的一些操作浓缩成为业务服务，来给各个功能系统服务，这块会一层层，从底层的服务，这种概念已经谈了好几年了，这种服务的时候整个的思考逻辑是一种对象化的思考，在每个层级你会看到，它的接口衔接都基本上已经开始XML，这样的大势情况下，有什么理由我们数据库组织不应该改变。这也是带来一个深层次的变化。
嘉宾的演讲结束后，现场数据库技术人员围绕嘉宾就相关技术问题进行讨论咨询，多种技术观点在会场上交流碰撞！与会数据库专家表示，这次数据库论坛不论是从参会人员的素质和层次，还是从交流的话题来看，都可称得上是目前中国最高水平的数据库技术沙龙。
