【IT168 专稿】主持人：大家好，今天我到分论坛就感觉很开心，因为我们今天的阵容非常强大，而且老朋友非常多，这位是Sybase技术总监卢东明先生，这位是冯春培先生，这位是淘宝网的首席DBA。总之，非常多的熟悉的面孔，今天的分论坛不像上午那样，我们不做那样的演讲，大家会做一些探讨性、互动性强的一些讨论，包括我关注Sybase的一些话题也想得到一些答案，首先请专家给我们做一些介绍和发言，然后大家有什么问题向他们提出来，我们做一个互动性讨论。
我们有请卢先生为我们做一个发言。
卢东明：大家好，很高兴又回到IT168，我也很荣幸这一年里面跟大家在ITPUP上就Sybase的一些技术，包括一些商务智能、数据仓库等技术有一些交流，今天也想讲一个比较新颖的话题，今天片子比较有趣，有很多图，主要的要点是看看能不能跟大家分享一个很重要的信息，就是“商业智能呼唤革命性的技术”，现在越来越多的企业进入商务智能之后，我们怎么样带领大家把它做好。
最近跟很多大的企业聊了很长时间，给我的感觉就像坐在钱堆上的孩子一样，他们很有钱，但是他们不知道怎么样去用钱，不知道怎么样把企业里头真正的黄金都挖出来，坐在宝贵的数据上，坐在宝贵的黄金上，他们现在不一定能发挥企业最大的潜力，怎么样在竞争中取胜，这个给很多企业都提出了一个最直接的挑战，就是商务智能，他们都在认识到商务智能是能把企业所有的黄金挖掘出来的最好的武器。
像中移动、国家电网、国内的各家国有的甚至一些海外进来的金融机构，都在倡导做商务智能、精英分析，商务智能给大家带来的直接挑战就是数据量的显著的、成倍数的膨胀，各种各样的数据，不光是企业的业务数据，也包括非结构化的数据等等，在这样一个数据膨胀的形成下，它们会遇到很多挑战，数据膨胀、数据爆炸、性能下降等等的挑战，有一个很有趣的地方就是，大家都是数据库论坛，其实数据库这个库字就把大家定在这儿了，实际上我们是在玩儿存储的，怎么样把数据存储下来，怎么样通过一些运算把数据里面的信息，把数据转化成信息、转化成价值和黄金。
从最早的时候，数据的存储是通过纸带，慢慢变成磁带、磁盘，磁带到磁盘有一个跳跃，能够随机地定位，到了硬盘数据多了，容量大了。现在硬盘已经跟一个硬币差不多大小，可以集成很多的信息，但是有一个非常重要的要点希望大家能够看到，也就是说所有的ETB，有效的传输带宽，一个磁盘它的有效传输带宽到底是在上升还是在下降，什么叫做有效的传输带宽呢，也就是分到每一个单位到底有多大的带宽传输给外边，整体效能要发挥出来，中间有很多通讯的，也就是说你把数据存进去了这个没有问题，但是能不能在CPU想用这些数据的时候能够以最快的速度给CPU，过去二十五年里面磁盘的容量增长了一万倍，非常恐怖的数字，但是我们市面上我们市面上能够买到一个TB的盘，以前10兆已经算是很大的硬盘了。我二十多年前接触计算机的时候十兆的硬盘、五兆的硬盘，容量增加了一万倍，其实传输率只增长了100倍，也就是说最终真正有效的传输带宽是下降的而不是上升了。
在座的都是DBA，我们拿数据来说一些话，做一个更精确的论证，比如说十年前，我们不推二十五年前了，十年前一般的硬盘是5GB，现在是500G，十年增加了100倍，但是单个盘的IO传输率仅仅增长了二十倍，从3MB/秒变成了60MB/秒，过去10TB要用2000块盘，现在二十个盘就够了。但是反过来总的IO的吞吐量，如果每个盘都有3兆的传输率，这两千块盘可以提供每秒六G的传输速度，但是现在反而下降了，也就是说如果有10个TB的数据仓库，要做运算的时候涉及到这十个TB，原来只需要花半个小时，现在需要两个半小时。也就是为什么现在随着数据膨胀，我们的计算机系统甚至比以前的系统某种程度上来说还要慢。
所以说硬盘正在变成磁带，越来越慢了，反过来，存储的开销，大家都知道，越来越大，在整个系统里面占的比例越来越大，现在很多搞IT的人，谈到自己的数据库都会有这样的感觉，它很老实，也很能吃苦，也很爱我，可是我要的是能给我挑虱子的，这是两个猴子的谈话，结合我们的IT，我们会发现我们的数据库的确很老实、也很吃苦，每天在那儿算，但是是不是我们要的呢？其实不是，因为我们数据的膨胀是急速增长的，我们如果没有一个突破性的手段的话，我们就没有办法真正解决你想解决的问题。
想像彭祖一样活到800岁可能是一个梦想，但是将人的寿命延长到200岁也许并不遥远，几年前科学家发现一个INDY基因，果蝇的寿命从37天到了110天，我们如果要突破的话，是需要在基因上、数据库底层进行改变，如果没有这个变化的话，我们只能让数据库更能吃苦一点，你们是不是也在寻找数据仓库、海量的数据性能突破的基因呢，我想每个人心里都有这样的愿望。
这个其实就反映到两类不同的应用上，一类是OLTP，还有一类是OLAP，这两类应用的特性实际有很大的不同，我这边用红的标出来的应该说是最难突破的，比如说OLTP是以删除、修改为主的操作，而OLAP是查询、复杂运算为主的操作，事务量一个多一个少，单个事务查询时间很难突破。比如用户做股票，有的证券公司打出来说，如果我60秒之内没有找到你的单子的话不收佣金。对一个并发度高来说，也是一个很难突破的地方，怎么样应付几千个并发，在抢单子的时候能够找到数据。更难的是数据量从几行变成几千亿行的时候怎么样处理，有没有很好的手段，这是这两类应用非常不一样的地方。
最后有两个需要注意，一个是OLTP里面，大家通常是往三范式方向走，减少数据重复，提高效率。但是在OLAP大家反而往相反的方向走，因为要尽可能用多维的模型，让数据一次查询中越快越好，而不在数据的节省，所以说为什么有很多发现数据膨胀好多倍。这也是比较难处理的地方。还有一个特点是在查询的时候，OLTP所有字段都能给，而OLAP只在几个字段能给。
我们可以用几幅照片来表现一下OLTP和OLAP，OLTP就像钱一样散着，但是数据仓库是非常多的钱在一块，海量的数据，我现在问你一个问题，这里边一共多少钱，这就是很典型的OLAP的操作，或者一百块钱有多少捆，100的、20的、50的、10的做一个统计。如果钱全部散在这儿的话，我想DBA也不要做了，再吃苦耐劳也不要了，但是整理起来，按列放，你就会发现，好像数起来也不难，每一沓一万的话还是能数出来的，实际上数据仓库里面也有这样的东西。Sybase就有一个突破，让大家在海量数据里面以非常快的速度查到你要的数据，Sybase提出一个全新的理念就是列式存储，就好象刚才的人民币按列堆在那儿以后，我已经分好了你去查，其实很容易，不是需要几千几夜才能查出来的东西。那么相比之下，传统的所有数据库都是按行存的，刚才已经解释清楚了，按行存有很多优势，一个信息进来我们可以很快地找到位置。也就是当我做一个统计的时候，势必要把所有的信息扫描，等等很多遇到的问题就会出来。
那么列式是怎么样做呢，就好象我现在进来的人在门口进行一个分析，所有戴眼镜的人全坐在这边，男士后边女士前边，这样数的时候你说戴眼镜的在哪我光看这边就知道了。列式存储就是帮你做这样的工作，在数据进来的时候把它按列排放，进行了有机的存储，这个时候你就会发现，我对数据进行了有效的排放以后，你再进行查询的时候，你就会发现我只会读那几个列，一扫就能够扫出来，这就是列式存储的革命性所在，这个革命性给大家带来的其他的优势是什么呢？是压缩，数据能够得到大量的压缩，刚才说了列式有一个优势是说查询的时候节省大量的IO，不需要去查找跟我无关的列，减少了90%的IO，但是这还不算，在一个列的情况下，我可以根据这个列的数据类型，根据它的数据类型可以对它进行很有效的压缩，比如说这一个列上一共只有几十种值，随着它重复了几十万遍，比如说中国的省份不超过三十几个，但是把人口算出来有十几亿，但是我不需要算十几亿的省的名字，IQ会把它代码化，把北京、天津这样的名字变成代码，真正在数据列里面存的是那些代码，运算的时候可以成千倍地提高效率。
那么压缩了以后你就会发现，最终的数据库的大小和传统的数据相比，可能会从二点几个T到六个T，这个压缩比给大家带来的东西是什么呢，实际上最终是一个钱，因为你到底用多少钱去做事情。05年雅虎的数据仓库是100个T，但是AIELSEN Media是17个T，从这样的你可以看到，原数据的量是差不多的，但是雅虎用了不同的东西，要多六倍来完成。所以跟我们的友商相比，我们的压缩技术非常典型。如果像雅虎那样节省一下，这个嫌是非常可观的。
同样的数据，比如说100GB的仓库，放到IQ里面一个小东西就解决了，但是友商需要一个机柜才可以做下来，10TBIQ用两个机柜，192块硬盘就完成了，但是用Oracle的系统的话需要花3000个硬盘，26个盘柜，可以看到这两套系统相比起来，不管代价还是每年的运营成本都相差非常显著。
右边这套系统估计每年的电费大约是50万美金，维护整个机房的开销，而且这是每年都要花的。
IQ去年年终做了一个全球最大的数据库的测试，一个PB，以前的硬盘是10兆，现在不仅GB不是一个可值得提的数字，TB都很一般了，你说我的数据库里面有一个TB还会听一听，PB就是下一个阶层了，1000个TB存了六万亿条股票信息，这样的数据量很多人要问加载要花多长时间加载，我们花了三个星期的时候，每秒钟300万行数据，把六万亿行数据加载。加载完了以后从一个PB，变成了160个TB左右，也就是说整体数据的压缩率达到了84%。大家可能在座的都是DBA，会觉得这套系统非常贵，这套系统我想国内很多企业都买得起，我想在座的有些人你们的企业数据中心里边按照这个配置都可以够好几套了。
SybaseIQ是去年国内包括国际上第一个把我们的数据库被媒体正式地认可为绿色的数据库，什么意思呢？是指的说它给你带来的价值不光是在产品性能上、不光是产品稳定性和整体解决方案上，而且是在整个的环境保护上、以及节能减排，产品的ROI上都有非常显著的效果，这是国内目前唯一一个绿色的数据库，节省的电费包括存储空间都80-90%以上，给企业的信息是非常清晰的，需要用什么样的代价来开发一个系统、维护一个系统。
IQ上有九种专门为数据仓库列式存储设计的索引，LF、HG等，加速整个复杂查询、海量数据查询的效率。
扩充，可伸缩性，当你的一个硬件系统不能够支持你的查询的情况下，可以通过IQ的多路并法的机制，可以线性地扩展，它把负载全部挪到CPU和内存上，你会发现在添加节点的时候，光线通道不再是一个头疼的瓶颈问题，每次增加CPU和内存的时候，你就会发现效率、并发度就会呈线性增长，几乎完全跟CPU的主频数锁定了。
在整体的架构上，除了IQ充当数据仓库的核心引擎以外，前端的BI的展现工具，后边的建模和原数据管理工具，有的地方我们提供我们的产品，没有我们的产品的时候我们都是开放的接口，像业界的都跟IQ有很好的接口。
速度上会有成倍的增长，TCO上面，经济性，通常一个项目放到IQ上会比传统的行式数据库减少30-70%的存储和开销，扩展性可以支持大量的用户量。
所以回到我今天带给大家的主要信息，也就是商务智能挑战革命性的技术，Sybase IQ是响应这个挑战的最好的工具，目前美国有几家公司是新兴的公司，他们也是在做列式数据库，他们从创投那边拿到钱，都在做列式数据库，这几家中有一家公司后台的主要技术人员和业务人员是什么人呢？是七十年代MIT的资深教授等，这几位大佬在支持它，这些公司的产生从一个侧面来验证现在列式数据库的春天就要来到。现在数据的膨胀程度已经给行式数据库提出了不可解决的问题，列式数据库应运而生，到了蓬勃发展的阶段，我们在技术上有一个前瞻性，很多企业现在选Sybase IQ做他们的数据仓库也是看重了这一点，他们知道几年以后他们的数据量可能会更大，没有办法绑定一个行式数据库走到五年以后。
主持人：感谢卢总的精彩发言，展示了那么美妙的技术。
提问：我有个统计数据，数据仓库项目80%都是失败的，包括我自己做项目，带项目也好，实际上自己也挺失望的，我也搞不清楚数据仓库的概念是成功的还是失败的，我觉得数据仓库不光是一个存数据的问题，最重要的一个问题是业务问题，我觉得数据仓库本质上是业务问题，一定需要有一些业务专家来做这些东西，比如说做一些业务建模，还有质量的问题，不同业务数据系统数据质量可能存在一些问题，最终得到的结果整合过来以后得到的期望跟用户有一定的差距，再一个问题是从业务数据库到数据仓库本身需要转换，当中发生一些数据的损耗，我觉得这三个问题才是最重要的。发生任何一个问题，做数据仓库都不是成功的。
卢东明：我很同意你的观点，虽然我不一定同意80%都是失败的这样的数据，另外一点数据仓库大家可能会有这样一个感觉是数据仓库失败率比较高，原因有几点，一个是数据仓库跟传统的业务型的项目比起来周期比较长，在它没有成功的时候我们是不是把它叫做失败的，这是有商榷的。就好象大家做车一样，从中国汽车工业开始，在没有做出很成功的车型或者企业的时候，我们是不是把中国的汽车工业称为失败呢，我觉得不应该，大家都还在探索，国际上也不是每个都能成功，但是大家还是看到商务智能越来越有迫切性了。
当然另外你说的ETL或者前端展示也好，它的作用在整个BI系统工程的过程中都占有它的地位，比如我们现在提供的产品，刚才说了，在整体的架构上面，Sybase IQ只是做了一个其中的环节而已，并不是说我们解决了整体的东西，但是每个环节如果都能够有各自的厂商进行突破性的进展，我想可能你会发现整个项目会比现在想象得容易得多，就好象我前两天给人家做演示的时候也讲到一个，我手机上面就有一个Excel的程序，这个东西十年前不可想象的，那个时候要想让企业做一个电子表格的东西，他也会认为这是非常难处理的事情，所以计算机的发展既给大家一个视角，也给大家一个历史观，也就是说计算机永远在处理现在难办的事情。刚才你提到ETL的过程，其实很多技术的进展也对整个体系的应用开发理念提出各种各样的挑战或者是各种新的见解，比如说ETL，好像大家觉得是顺理成章的事情，一个项目有原数据，转换要需要ETL，但是现在你会发现，有很多过程放在数据库里面比放在ETL里面有成几千倍的提高，现在有一个理念叫ELT，就是我抽取出来以后，先放到数据库里面，先L，这个比用ETL工具快不知道多少倍。那么这个概念是怎么提出来的，还是由于列式数据库能够显示出来，如果没有这样的突破的话，我想ELT这个概念也出不来。
所以就像盲人摸象一样，没有人能够看到商务智能是一个整体的大象怎么样走，怎么样运转，所以每个公司都围绕着大象的某一个角度在做事情。
提问：我问一下Sybase IQ的具体技术问题，列式存储压缩的功能默认的情况下就是有的，就是一定会压缩。有些行的数据可能列非常少，基本上都是单列。
主持人：关于列式存储是Sybase的专利技术吗？现在有一些厂商也在开发，这些专利是否是从中借鉴。还有像IBM可不可以借鉴这种技术。
提问：我这边再跟一下，列存储的话，在数据库里面第一行到第一百行，这个值比如都是一的话，可能就这样标一下一到一百是哪个值。还有一个就是Sybase IQETL的性能，因为前端数据库转化到Sybase里面效率会怎么样，因为我们现在都在提倡实时的ETL概念，要求比较高，这块我想问一下，在转换到Sybase IQ的话能够提供什么好办法。
卢东明：一个是压缩技术，IQ里面的压缩技术是自动有的，不需要设定或者是制订才能产生的，所以为什么我们并没有把IQ定位成一个压缩型的数据库而把它定位成列式数据库，也就是它的根本，它的本原第一步是列式数据库，压缩的特性是随着列式数据库而来的，其实压缩这个概念我想大家玩儿DB2的都知道，比如说DB2九版本也做到了某些压缩的功能甚至非常好，但是跟IQ的理念不一样，IQ是每个列自动进行压缩，的确你刚才讲到的，有些数据是不可压缩的，比如说我们举一个例子，刚才讲的一个PB的数据仓库，它的结果无非是这样，股票的代码、时间、当然精确到秒了，然后可能有最高价、最低价、买价卖价，成交价等等，这些价格实际上是不可压缩的数据。只能结果压缩的存储，但是解决不了运算，因为运算的时候还要解压缩再拿回来，这个过程实际上已经证明了是不可行的，通过压缩完了以后存储，产后减少IO，解压回来再运算是不可行的，IQ不是用这种方式去做的，IQ是在时间、交易商这些所谓我们说的基数比较低的字段上，比如说性别、省份、公司、代码等等，这些是属于低级数的，价钱、通话时长，一些属性，这属于高级数的，重复率非常低的，在高级数的信息上面，实际上任何一个数据库都没办法做到压缩。但是IQ能够做到的压缩是在低级数上，如果有一个极端的列，性别，就两个基数，IQ的压缩里可能是几十万倍，所以我们宣称的压缩率，在整个数据库的压缩率，并不是一个几十倍的压缩，因为有些压缩不了。
提问：打断一下，我理解对于低级数的列，Sybase IQ是不是仍然尝试去压缩。
卢东明：这有一个质的区别，Sybase IQ不是说通过对低级数进行压缩以后再运算的时候进行解压缩，因为对计算机来说，我们统计一下男和女，计算机在乎的是男女还是一二，还是典型的描述，它根本不在乎，计算机拿到一和零去运算和拿到男和女运算是无所谓的，我们显示的时候会说男多少个，女多少个，所以IQ压缩以后已经用比特表示这些数据了，运算又在比特运算，出来的值告诉你，中间运算的过程没有任何解压缩的过程，这也就是为什么在这些低级数上进行运算效率会成倍提高的原因。至于你要找到两个股票，这个股票价格都是九块三毛七分的在哪个时间上，我想任何的数据库都没有办法可走。
如果你要做的是把表里面的东西全部拿出来的话，Sybase IQ的优势不大。BI上的应用更多的是把数据的特征统计出来，或者通过一些算法，把结果统计出来，我要数据没有用，你要几千亿行数据吗，你不要，你只要统计结果。
主持人：IQ应该是一个数据仓库的产品，不是Sybase的数据库。
卢东明：一个谈到专利技术，实际上是这样，我们IQ里面有很多专利技术，但是列式数据库的概念Sybase并没有专利起来，所以很多小的公司在做列式数据库，这个实际上很多公司都看到这个去世了，这个趋势实际上也更加巩固了Sybase IQ在这个领域的领头地位，这几家公司目前在全球的成功用户加起来不超过50个，Sybase IQ的成功用户一千个。刚才也提到IBM有没有可能借鉴或者是有一天也能够做一个列式数据库，这个我没有办法替Oracle和IBM回答，但是它想做必须像Sybase现在这样，Sybase IQ的产品没有基于ASE的前身，是完全不同的产品线，IBM、Oracle如果要超过这个，必须要做一个完全列式的数据库，我不认为会存在一个在行式的基础上做了一个列式的东西统起来还叫Oracle，因为你把数据按行存了，你的开销已经在那儿了，就不存在我能为你节省空间，再做一个列式数据库，至于什么时候他们出这样的产品，这个不是我回答的问题。
另外提到Sybase IQ数据加载的效率怎么样，刚才一个PB的数据仓库我想可以给大家一个非常好的例证，每秒中300万行，我们在国内亲自做的案例，我们做到的数字通常是可以做到五万到十万到几十万行每秒，会经常见的，这跟传统的行式数据库相比，它的效率一般来说还是在十倍以上。但是有一点我要强调的是这个ETL的过程不管你多实时，这个ETL一定是一个批量的方式，列式数据库的优点和缺点都非常清晰，我不喜欢逐行操作，不要把数据按行给我。但是这个缺点非常好规避，你只需要把数据缓存一下。
卢东明：对于历史数据库这方面，IQ有很强的应用，这是一个非常自然而且常见的应用案例，比如说我们在交行、农行包括一些其他的银行，因为整个银监会的要求，他们就会要保留这样的数据，在美国也是，个人的报税记录在美国国税局保留七年，这些数据怎么存，实际上列式数据库本身就已经按列分区了，这是它性能提高的原因，因为我分区了所以才不碰那些不用的数据。如果说一个静态的数据库，进去不再修改了。比如原来的数据库是光纤盘做的，但是我只有每年就碰几次，我可以用一半或者更少的代表做下来。另外出于法律原因，有些公司需要跟主管部门或者证监会、银监会证明恩我这些数据库数据进来以后的确是静态的，我没有做过任何的改动，怎么证明呢，通过硬件来证明，把这些历史数据放到一个只读的存储上，IQ完全可以在只读的存储上进行操作，因为对IQ来说我的操作特性不是沿着磁道一次读500K或者1M。
主持人：我们再次对卢总的演讲表示感谢。
主持人：接下来有请阿里巴巴的技术经理做一个主题演讲，《大型应用设计中的数据库架构》
冯春培：去年五月份在杭州，看了一个几百人的大厅，也没有用话筒，我觉得这个也不用了。我讲东西不喜欢用文档的东西把思路框住，说得好听叫天马行空，不好叫想多哪说到哪。
我前面把自己的印象比较深的东西尽量表达出来，其实题目不是我定的，这个题目是主办方定的，谈这个问题呢，在这些比较大型的应用中我们怎么考虑架构的问题，大家在座的也大多是这样的角色，刚开始的时候，数据库应用发展的时候，大家那时候数据也少，应用也少，没有价格不价格的概念，能实现功能、收回钱来就成功了，慢慢地发展呢，积累得数据越来越大，客户对信息化系统的依赖也越来越重了，很多并发的要求、海量的查询，当然我主要讲OLTP的类型，这样发展之后呢，数据越来越重要了，于是产生了有人来管理维护数据库，不能丢，有些企业像金融企业丢了跟钱都有关系，电信那边少收点钱还没有关系。当然有人管理数据库，运用的问题就凸显出来了，于是就产生了数据库的管理维护的这些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项目组就可以跟老板说，我支持你可扩展、保障地的可用性，没问题。这是我的终极目标，我不希望说像以前一样总是听到各个业务部门回应我说，我们这个数据库什么时候就不行了，撑不住了，你跟我说到底能够支撑到什么时候，由于业务发展，有时候具有爆炸性，不像传统行业一样，我就非常难以回答，这也是我的一个痛，所以说我也是希望未来的某一天，也许一年、两年，那个时候我可以跟大家交流时候说，我们的数据库非常好，可扩展、可靠性非常好。我也希望大家欧这个概念，现在也许你的系统还比较小，但是总有一天越来越多的企业会提出这样的要求，当这个机遇降临的时候，你就可以勇敢地站起来，承担责任，体现你的价值。
主持人：他从一个用户角度说在数据库管理和架构中遇到的问题，解决的问题还有正在解决的问题。
提问：现有的数据库压力下面，比如我一月份是某种压力，在现有的压力下面，过了一个月以后的话，这个压力肯定会上来，如何评估过一个月后的压力到底有多大？
冯春培：比如说你这个系统刚上学一个月，要告诉第二个月多大是没有办法的，我们的经验，我们对所有的应用，如果一旦上线有一段时间，这个系统的IO，主机的CPU，数据库每秒钟有多少逻辑图，我们都有长期的趋势图，每个人对这个曲线都非常熟悉，对我们来讲我发现一个低点或者高点发生了我们就会去调查那个时刻有什么任务也好，我们的曲线是什么样子的，比如我们很明显地知道，我们负载，前半年稳定在1.5到2，现在在2.5到3，你的业务方如果能给你提供一些帮助，比如说用户的增长量，你们最近要不要搞大型的推广活动，很多是相关的，我们是非常关心我们公司什么时候要搞个大型的推广，搞什么免费的活动，这对我们有很大的压力，我们基本上业务方要做的时候都会找后台去沟通，我们预计下个月做什么东西，你们有没有很好地准备。我们根据它业务增长的目标。
比如我们现在淘宝这种应用，一个动态的PV，一个点击，一百万个点击里面有多少比例是动态的PV，这个东西长期下来是可以得出来的，每个动态的PV会产生多少逻辑图，多少IO是可以统计出来的，经过历史统计可以修正一些参数，然后去运用。我们团队的人我会问你数据库有多少IO，你比较了然地回答出来。如果你比较熟悉了，你就会很好地解决。
主持人：前一段有一个案例是奥运会的售票，一到时间马上网站就崩溃了，我想这是模型不太好。
提问：我提个问题，可能跟技术不太相关的，您在公司里面的名望或者地位，还有阿里巴巴对数据库的重视程度也好，他们对数据库非常重视，在中国普通的现象是什么呢，公司领导并不重视数据库的前期工作，我想您是不是也经过这样的阶段，刚开始领导并不听你说的。非得等公司遇到一些比较大的困难，甚至花了很大的代价才重视这个的吗？
冯春培：我明白你的意思，我去阿里巴巴的时候，去之前是第三个，前面两个明天疲于奔命，我去时大家都不认识我，除了这个圈子的人比较熟悉之外，做架构的根本就不知道你，我去也是花了很多的力气，我看到了所有的问题，去跟很多部门沟通，协调解决这些问题，我希望某些部门配合我做一些变化，做完了之后呢，那我就会说，这个变化我用一个具体数据说，我做这个事情达到什么目标，有什么效果，把这个东西弄出来，要让他们部门知道，还要知道领导知道，知道他干这件事情给大家带来多大的价值和收益。这个事情慢慢地去贯彻，多打交道以后对方也觉得跟你们配合有点意思，能有一个东西来说话，慢慢地逐步提高影响力。
不能等说系统承载不了了，你一来一下把它弄好了，这种概率很少。由此比如我们现在招人，我们非常强调跟其他部门的合作、沟通，配合，我们要求非常高，所以很多的工作模式和习惯，制度流程都已经很成型了，我们现在便一个应届毕业生进来三个月，保证可以接受我们的业务，当然我们希望他更有潜力。
我们经历了几年的时候才形成了影响力。
主持人：要么你改变世界，要么世界改变你，要改变企业的行为和模式，那么你创立一种制度使得企业运转更好。
提问：我的问题很简单，因为淘宝、阿里巴巴机器负载是几到几。
冯春培：这是操作系统上表现出来的，这个在CPU等待队列里面排队的数量。
卢东明：我其实有一点感受，我觉得很多我们现在接触的国内大型的用户，刚才非常同意春培的观点，做DBA的要想证明一些什么事情，或者改变公司的做法，把它量化，不要定性地说，数据库慢了，或者数据库很忙，然后项目很紧等等，要量化，跟你领导汇报的时候把它量化出来，数据库负载到了什么程度。
冯春培：你还可以说逻辑度降低了多少，百分比是多少，虽然领导不明白这个意思，但是他能看到这个变化。
卢东明：另外我也注意到很多国内企业有时候和我接触的国外企业一个很大的差别是什么呢，没有一个Q-A系统，没有一个良性循环的机制，从开发系统，到QA系统，到上线系统，我不知道你们在座的公司里面会说今天这个点不行了没问题，大家想一想Google这种公司，还几百个机子没事，它是通过整个体系结构上，通过技术上的方案，彻底地解决了这个问题。${PageNumber}
主持人：留下来请IBM的专家刘晶炜先生给我们做一个主题发言。
刘晶炜：各位好，我想在切入正题以前，说一下刚才那个问题，满有意思的，卢总也提到了，我想今天的题目不光是讲技术，更多是围绕创新来讲，大家反思一下我们的IT，大多数DBA，从CEO角度来讲是怎么看待DBA，你是业务核心吗？能够为业务带来什么。我们大多数人，DBA的日常规律在做什么，我相信维护、备份都非常重要，但是07年全球有一个CIO的论坛，CIO对公司的作用是什么，过去把我们看成一个支撑的角色，不出问题的角色。
我自己去年，从06年下半年开始接触XML，我自己亲自拜访过两百个客户，下面把我自己的体验跟各位交流一下，我觉得这个技术不是一个支持技术，它是一个创新技术，IT能不能对业务的运作有一个价值。
第一个行业，也算是一个行业，医疗行业，医疗行业从哪进去呢？为什么这个行业需要呢？各位你去看各家医院，你们自己去医院看病提高的病例是什么形式的，有没有人想过把这个东西做成电子化的，我介入这个行业以后，过去六年国内很多医院想做电子版的，而且医改方案也出来了，从技术层面看，这里面的障碍有什么。
你们自己想想，你自己去医院做体检某种病的描述，或者同一种病不同的人也不一样，第一件事情就是如何建模，这容易吗？第二个问题，为什么有时候数据库要加字段呢，不同的人做血常规类型也是不一样的，过去这几年跑了国内的二三十家，电子病例就是医生写个word文章，所有的精确性的东西无法做到。
第二种呢，在2003年2004年叫做结构化电子病例概念，一个科室一个科室做，刚开始几十张表就能完成，后来太复杂了，而且不同医院需求不同，你做出来的东西适应性很差。我们大家搞数据搞了那么多年，我们有信心说我们是了解数据的专家吗？这是看哪个角度，我们做业务需求的时候最大的难点在哪？沟通啊，业务人员能有多大程度上的差异呢，今天设计屏障之高，已经成为很大的问题。
今天在架构层面上有没有容纳的空间，我们很多的变化是业务来导致的，而不是IT产生的。
下面我们看看做了什么， 我们搞IT的人很容易画一个流程，几个大的环节可以很好地归纳下来，但是具体的东西，开什么内容，是你自己花两个星期做调研呢，还是给他一张表格让他填，后台如果两三百张表谁看得懂，怎么进去怎么出来，出去换一种别的用法怎么办呢？大量的程序编制要完成，另外不同的客户一定会有数据内容的差别吧，比如说我是这家医院的，我有自己的需求。会不会影响到结构，影响到以后我们怎么办？这是我们最开始切入的领域，这个问题只是医疗有吗？还是因为它结构复杂，我们每个行业都在复杂性的层面逐渐地走，这一点浓缩过来，我认为今天的数据库层面上面。每个行业的数据库都是几十张表，几百张表。如果数据库发展到五十万张表以后我们的方式还是这样吗，另外我们业务的灵活性是在增长还是降低，。频率是越来越慢还是越来越快呢，第三点有没有很多业务部门说你收了那么多数我用不起来，瓶颈在哪呢？是数据不可理解，大家都很难用，只有少数的专家能用，这个是现实。
下面我们就会看到，这个过程中我自己深刻地体会到了，真正地冲击到了数据库的核心点，也就是我们今天回头思考一下，关系型数据库解决什么问题，当年奠定关系性数据库的两个巨头有一个已经过世了，去年我们把第二个请过来了，他98年决定做XDM，今天我们数据库是不是只为交易服务呢，以前交易相对是固定的。
我们如果从IT的基石来看，就像修楼房一样，最早是木头结构、接着是砖瓦结构，要盖一百层的，必须换成钢筋水泥，有了数据库已经支撑了三十年，如果再往后思考未来十年，我们的信息系统会以什么样的复杂度来扩展，你觉得这个结构还再支撑增长十倍吗？未来方向在哪里，究竟技术鸿沟和业务鸿沟越来越大还是越来越小。这一点他就带来了XML的灵活性。
在这块我只讲我们的定位，需求之初我们就思考那些东西应该用XML，这就是说我们为什么认为这是对IT大的改变，这种改变会在哪发生呢，任何一次大型的变化绝对不是今天占据领先地位的行业，所以我们回避了金融、电信业，我们转向大家可能认为很复杂的医疗业，像社保等领域，这个点上面，我们会看到既有关系型，也有XML。关系型的东西多少能够变成XML，能够带来什么价值。
技术上面来说我们从九版本出来以后，四大方面，二十多个专利搞了五年，春粗、索引、查询和处理、数据标准化这块，我们定位是到复杂的交易，性能提高了2.5倍。
下面讲几个例子，医疗记录里面，最直接的模式，现在国家都要去做了，今年北京市要求所有的每个常住人口，要为每个人简历健康档案，人出生到死亡每个信息都要建立下来，这里面会涉及到多少复杂信息。它有XML文档，一块一块切开。我们注意看一下，这里面大片的东西都是XML设计，这是它的主述信息，每个里面多个层级，以前设计的时候，是不是要把需求调研得很清楚，里边的每个关系都要浓缩成ER模型展开，今天细节的事情可以交给业务人员做，也可以容纳对这种方式的标准型管理，有很多很多的环节可以用这样的方式设计和思考。
但是对我冲击最大的还不仅仅是这种简单的改变，下面再改变一下我们如何来认识数据，这就是我刚才提到的，谁是真正了解数据的人，过去相当长的一段时间我们认为我们是，但是在这个行业里面率先碰到了瓶颈，一个大夫需要七年才能上岗，这些知识怎么可能在半年左右的需求调研中很清楚地拿出来，这是极为困难的事情，所以我碰到好几家医疗公司的技术负责人是医生转过来的，它的设计思路给我很大的冲击，首先他想到的不是见面，而是从他自己的业务知识库里面应该有什么数据，症状，症状怎么描述，部位怎么描述，这些信息能不能能够从他的思维逻辑的时候，在做任何一件事情把这些元素拼在一起，浓缩成一些复杂的组建，当我和业余流程挂挂钩的时候形成一个模板。
这里大家看一下，比如说我去调研一个需求，见面设计表怎么设计，大多数是这样的，这是一个病例的录入过程，比如说耳科，耳科里面有很多的病，比如极性支气管炎，有很多的信息，这个好像跟我们的word非常相像，医生做这个的时候，这是由大夫自己定义的，整个见面由大夫自己进行定义，这个部分包括什么原件。一般到一个医院做的时候，是一个科室的医生审核这些模板，做出来之后可以再去运用。
现在比如说西医包括中医，同时在一家医院设计出来的模板，换到另外一家医院，缩短了业务人员交流上的鸿沟，适应变化，这块我们做了简单的对比，如果我们只采用关系型的体系进行思考，我们见到的数据就是这样，如果开使用XML的方式以后，哪个更标准化一点，你的表结构设计，系统没有做出来以前是没有办法审核的，一些懂业务的专家是有机会能够参与的，能够看得懂这些信息，左侧我们是单纯的数据管理，右侧我们想到什么，这个知识沉淀下来而且不断地扩充，新项目上的时候能够以多快的速度利用原有的知识，而不是把整个的数据库表拿过去。
在查询方面，今天所有人都在用电脑，每个人都有资料库，数据库只是相对专业的资料，文件系统用什么方式解决呢？怎么样培训我们的人使用呢，XML的路径不像我们拉平了，二维的关系，需要一系列的关系，只要你数据摆在那儿，只要给他一个路径，业务人员就可以去查，我们的运用体系上面能不能够相对灵活地把供应点用好。我们以前全文检索大家都觉得非结构化的来做。
今天我们讲百度、google那种搜索，但是搬到企业上更精确，大概什么时间服过什么药，曾经出现什么症状，你是希望医生对结构了如指掌还是希望他有灵活性，我们用XML体系可以找到一个平衡点。
第二块是在政府领域里面，都会涉及表单问题，今天大部分的系统，如果表单特别多，三千六百多的税单，数据模式的多样性，弥散的数据，业务的变化，表的格式发生变化，你的底层的数据就要变化。今天我们普遍百万的是什么方法来实现的呢，这边可能后台是很多很多张表，每张表几十个字段都有可能有，我做的过程是什么呢？在界面输入出来的值，要把数据库的数据展现成表的结构给别人看的时候，每次变化给大家带来的变化是多大，大家可以体会一下。纽约税务换了个思路，既然表单是一个完整的整体，为什么要把它拆开呢，一类表单只是一类对象而已，一张表里面可能有多类，第二数据库里面适应灵活性不外乎两种方法，一个是笼统地放进去，冗余的方式，这种方式肯定会有一些大家都有的信息。
如果在数据层上面能够提供一定的灵活性，应用层能 提供灵活性呢，这边我们就跟国内一些做税务的软件厂商直接来交流了，举个例子来说今天中国的国税登记表，下面支撑的二十多张表，去年前面国家从六类登记表转变成32个登革表，现在我们不外乎就是登记信息、税种信息、变更历史。我们不需要二十张表了，只需要二十张表，在里面不同企业登记记录，如果能够做到这一点，我们再下来看一下整个软件体系里面，一个运用究竟怎么造成的，有界面、业务逻辑、数据层，我们基本上已经考虑用XML，底层很少去考虑，只是碰到问题再去改，从来没有主动考虑过，对应带来的问题就是整个架构，不光是SOA这个框架。业务一变化，这个体系就要发生变化。就要做很多的处理，如果我们能够融入XML，把一些可能会变的变成XML体系的话，我们的流程引擎做的是类似的事情，在这个层次上大家可以去考虑一下，医疗的业务应用也是做了这层，可以由业务人员自己参与设计，可以直接进行参与。
这一点我们也在不同地方尝试过补充模式，原来一张大表，很多字段，即使做得再多可能还是不够，比较简单的方法是应该保留的还是关系型的。第二种叫主从模式，第三种就是关联扩展。演化出一张关系表，如果结构一样一张关系表就够了，如果不同的关系是不同的东西呢？是不是要演化很多张表呢，出去用XML进行设计的话，首先业务人员能不能参与，在哪些层面上能够参与，以后的管理和维护、适应性能不能提高？当然在这里面还包括自循环，我们今天一个数型结构以后，不外乎编码，第二个是这个字段里面的值到另外一个字段，在同一张表里面一张张去做。
这是我们社保领域做的，每个地区都有不同的扩展，每个地区扩展由这个地区自主完成，当然你如果能够预见到，也可以来做的，但是这个我们来看它的成本，以及可维护性，除了这个以外我们在另外一个行业还发现一些很有意思的事情，就是XML带有标签，使得数据可理解，就成为一个上下文的概念，数据有上下文以后就可以被越来越多的普通业务人员使用，如果我们只是看到一个阿拉伯数字，这个数据没有什么意义，大家理解不了，但是如果我们把它存在的位置，前后背景都能够联系在一起的时候，你会对整个数据的理解是不一样的，我们来看这个点在一些行业里面起什么作用。
这个是公安行业，商务智能除了在管理上给领导做报告以外，或者海量的数据放在这儿，出来的结果是什么？是花哨的图，大量的一线人员要信息的时候不要做什么汇总，他能够看到完整的信息，今天怎么实现呢，只有自己写代码去实现，公安领域可能吗，所有每个警察破案的思路一样吗，每个人都可能不一样，人口信息、旅馆信息，坐飞机的记录，在逃人员的记录很多，最重要的是根据一把小刀的特点找到在哪个地方用过，这个人有什么网络，跟他认识的是谁，跟他同时住过一个地点的是哪些人，这里对一线员工最有价值，对公安、银行都是这样，而今天在这一点来说很难实现，你不可能利用其中的每一个需求。
今天互联网的数据比任何一个行业都多，但是大家用互联网的时候没有困难呢，为什么互联网数十亿的网页大家都访问得很方便呢，因为你看得懂，点这个网页就可以过许，那能不能今天的数据库里面，已经收集的信息，这些信息没有意义吗，它能不能够让业务人员更自主地用这个信息。这个点的内容我举个简单的例子，假设系统里面有两条记录，今天在数据库里面存成关系型，但是当它出现第三条系统的时候，警察最关心的章三是张四的驾驶证是一样的，而李四和张四的电话号码是一样的，这就意味着这三个人也许是一个人，这种联系的可能性是在哪联系的呢？这个个案是通过驾驶号来关联的，这是非常多的点，你能不能总结出来，花多大的力气能开放完，这就展现出数据可被理解和不可被理解会有多大理解。数据如果本身就是XML的话，你就只需要有一个框架，帮助业务人员自己去找链接，然后自己去完成。这一类的业务运用，我们在现实场景里面，公安领域里面，包括构建社区网络。我们希望做到的是能够把数据库里面的信息标记完了之后呢，这是一个人，这个人所关联的所有信息，这个人联到不同的人，而且这里面业务系统会产生很大的代价吗，如果要做到这一步，必须要对整体上的原数据有一个管理和运用，但是它的价值是多大呢？就相当于零售行业，以前客户到后台找一个东西。现在超市怎么做的呢，各个地方，每种类型的商品分门别类，自己走进去拿东西，数据库能不能让用户走进去拿东西呢，就是要让客户进去。
同样数据交换体系里面，这也是在去年很多领域进展比较多的，越来越多的政府部门需要做数据交换，比较方便，但是会涉及到两个方面，在这种复杂的形成下，一个通才会越来越少，一个行业的应用我可能还说我是这个行业的大佬，我拿出来的90%是准的，但是现在这种情况下必须要自主参与，而且往往在政府的这种业务过程中，要交换的数据每年在变。这个是我们跟杭州一家挺大的公司做的合作。后台通过业务复制往中心送。
在美国现在已经开始推行XML的标准，如果传统技术做的时候要分拆成不同的关系型的表，如果这些数据都能被理解的话，维度就是对数据的分类，指标、产品等是不同的维度，定义数据标准的时候，如果这个数据能够以相对原样的方式保存，这个时候维度又可以拖拽。唯一考虑的就是数据和效益的问题，如果数据量不是太大，那我是不是可以做成一个虚拟的。
今天比较难的是做出一个系统能适应不同的需求。我们看到更多的一些变化是今天IT层面上的，其实我跟银行的人都做过探讨，今天IT尤其在数据层上面产生非常多的挑战，涉及到架构层上的挑战，过去十年二十年我们是以一个固定的业务需求，固定的业务需求直接推到固定的业务逻辑，这种逻辑套过来是一个一个单独的业务系统，数据库并不重要，只是保证系统稳定运行就好了，效率不好了我加台机器，这是我们过去关注的重点，今天碰到的很大问题在哪，数据有了之后，要开始发生交互了。但是这种运用越做越多后发现数据的规划不合理，因为你这些数据应该不应该归属于你这个业务系统，开始只是在业务功能上思考这个问题，国外也是这个思路，走到一定程度发现，以前每个城市都是一个一个自己的房子建起来，建起来之后发现供暖、供电不应该由自己来管理，IT结构也是这样，在数据层上一些大的企业认识到必须提到整体平台上。
这是中国移动的IT咨询架构里面的一张图，这就是我们今天看到的核心业务里面的，ADB，但是这种模式发展到后面，在上层有非常多的交互，一个业务运用必须有很多的流程，现在最理想的是走这种模式，今天大家都在讲以客户为中心提供服务，但是客户信息分得很散。但是你在整个架构上面在不断地同步，整个架构缺失，国外很多大型的行业都逐渐认识到这个问题了，我们数据层要促进业务的发展。
业务应用里面的专有的数据还是相关的，但是共享的信息因此剥离出来独立完成，SOA必须从表层走向流程，再走向数据，一层层深入，才能真正做到业务的星火。我们希望未来的数据，银行开户这个动作，在网上可能开户、开信用卡可能开户，很多环节可以开户，但是今天开户的行为被封装在某个业务模型中，处理的逻辑、数据也不一致，这个剥离出来以后，对数据不需要人为干预的一些操作浓缩成为业务服务，来给各个功能系统服务，这块会一层层，从底层的服务，这种概念已经谈了好几年了，这种服务的时候整个的思考逻辑是一种对象化的思考，在每个层级你会看到，它的接口衔接都基本上已经开始XML，这样的大势情况下，有什么理由我们数据库组织不应该改变。这也是带来一个深层次的变化。
我们看一下今天的信息系统发展的轨迹，最早的是1884年，当时是MIT的一个教授，面临的困难是美国的人口统计局统计人口，十年一次，但是困难是十年周期还处理不完，他发明了打孔机，然后把打孔的信息放在磁带上面，最后磁盘，随机读写，这个时候才慢慢产生数据管理，数据库的概念。最早的是网状的，数据和业务逻辑没有很好地分离，1970年有了关系型的理论，77年的时候到后来交易的概念，今天从理论层面上我们看到，这条线已经支撑了将近三十年的历史，另外一条线现在大家用的互联网最早追溯的源头，当时是罗斯福总统的技术顾问，他当时并不是一个技术人员，他想的是给总统提供的资讯合不到一起，他后来想到了在非结构化层面上用到了鼠标的概念，使我们人类访问信息的方式产生了质变，我们可以按照我们的思路跳转，不断地去改变，最重要的是不在于他创造了互联网，它早就有，但是只在技术圈用，没有普通人去做网页，他最大的改变就是让大多数的普通人能够参与，使得全世界互联网的参与的人高了。
去年我们在市场上取得了一系列的突破，我看了一下你们的报告，跟我们的数据非常不一样，我们去年的业务成长了100%以上，在中国的业务，我相信这个仅仅是开始，我接到很多的业务。深刻的变革才慢慢开始。
谢谢各位！
主持人：感谢刘晶炜先生给我们带来的激情澎湃的演讲，大家有什么问题可以提出来。
提问：我从您那个表上看到，如果有一个全文检索的需求，从语句来讲怎么实现这个东西。
刘晶炜：我调一篇给你看一下。
刘晶炜：在数据的组织方式，XML的组织方式，每一种技术都有它适合的领域，也有它的极限性，我们的根本的组织数据逻辑的思路改变了，以前关系型是把同类数据放在一起，XML是把有关系的数据放在一起，你这个人相关的数据存在一块，这种方式天然来说有个缺陷，缺陷就是刚才你说到的，我也不想回避，在我做统计的时候，我的数据不像在数据仓库里面，我要拿它的时候，不需要把整个都拿出来，但是还是要点一点过去，这个是不可能做到跟传统的数据仓库的性能，这个我们跟国内的用户也探讨过，在哪个领域使用，如果是几亿条记录，而且这几亿条结构也没什么变化，你为什么要用XML呢？有变化的信息，本来联系到一起了也可以用。
提问：我想知道我在设计数据库的时候我怎么知道这个字段是放在XML里面还是外面。
刘晶炜：我们现在呢有几种情况，我接触了很多行业，他比较早地采用XML设计了，第二种政府我们做的方法是这样，原来已经有了很多设计体系，我们在做新系统的时候，去参照你的业务的属性有没有变化的可能性以及以后会怎么样去用它，我们一般来讲会把需要索引，大家关联性比较强的数据保留关系性数据库。应该来说这种设计理念和这个模式我们在全球才推出来，还在摸索的过程中，我不认为有一个特别成熟的体系。
提问：你前面说到，数据建模的建立，可以分散给各个熟悉业务的人去做，就是我们可以把任务分散开来，不是我们自己做，分散必然导致大家之间不知道别人干什么。
刘晶炜：可能是我讲得不是特别清楚，我们讲分的时候是提供了，以前的是基本所有的事情是我们做，今天我们分的时候是要看什么东西应该分出去，跟性能相关的我们应该分出去吗，索引的构建可能还是由IT完成，分的不能是更好地大家协作，数据库构建国家中需要业务人员参与的时候是对模型的构建，这个地方需求调研的时候，把这个部分的数据模型交给业务人员参与，我们真正去实现的时候不一定按照这个模式，但是作为DBA的责任是什么？是按照一个大树存呢还是两三个下树拼起来存呢。那是DBA的责任。
提问：我们以前用关系性数据库的时候，和XML的开发体系有没有改变。
刘晶炜：我认为一定会有改变的，我不是这方面的专家，以前就是把表结构设计完了交付，现在等于是表结构里面宏观的设计完成了，但是微观的设计可能分出去，不一定是完全直接采用它，那过来以后很容易理解它的需求，这个对软件的生命周期有一些微调，不会有根本的改变。
主持人：我们现在请刘晶炜先生入坐，刚才卢东明也回来了，大家有问题可以再问。
提问：你相当于业务人员把数据定义好之后，你这样会造成沟通的问题，现在我们所从事的开发，开始DBA是技术支持，不受企业的重视，我们通常也是应用推动技术，然后再返回到我刚才的所说，这个模式合适吗？
刘晶炜：我觉得你说的问题去年我拜访非常多的用户，基本上从技术人员、业务人员都提到类似的考虑，而且在现实的情况下面，从业务的需求处理，首先我们讲在需求的沟通上面，这种方式大家更容易协作，在管理层面上碰到一些新问题。
主持人：下面我们分开来讨论一下，再次感谢三位嘉宾。
