张乐奕：应用是否要升级？假设以前的医院用的Oracle数据库，那么转过来用你们的数据库，是否还能升级，语言方面有差别吗？还有您刚才说的死锁，您说通过节点以后，避免了死锁。为什么会避免了死锁？您刚才说的最大的OEM的并发七千，因为你的数据库也放在操作系统上，你的并发七千是什么意义的并发七千。

回答：如果把Oracle系统转为我们的系统的话，我们现在唯一做得比较好的，就是在可视里面实现。

现场热烈讨论

张乐奕：这个查询的代价是一样吗？
回答：代价就是没有用可视的语言进行。拿单纯的数据比看不出来。举个例子，在南非有一个电信公司，它们提出了一个新的需求，要求在一秒钟在一个设备上处理三千条短信。原来它的方案测试商只处理了三百多条，不到四百条。用我们产品的软件开发商有机会接触了这个电信运营商，它把这个数据库迁移过来以后，做了兼容的一些调整。一秒钟1700，这样也没有达到标准，后来就重写的代码。这个测试结果很惊人，达到了10600。短信发来以后，要把它在它的设备上进行缓存，然后再发出去。如果对方设备是关机的状态，信息是收不多的，所以要先保存住。

这个据我了解并不是我们面向对象的优势。它可能直接在底层是这样的。用对象访问的优势在于，我们在进行查询的时候，拿淘宝举例。一个用户登录进去以后，要查询我们交易的记录。在对象世界里面，客户是一个对象，他的订单也是一个对象。我们通过对象建立对象与对象间的关系，在建立对象关系保存的时候，会进入一个指针。当你打开顾客对象的时候，会把这个指针都知道了，我这个订单在哪里，如果知道订单了，到哪里去查。

郭志勇：所有数据库里面，都有这种指针的寻址方式。我想问一下，不管怎么样，我想引用性能条约这方面，大家知道在数据库里面，我们都是基于成本的。虽然咱们是面向对象，而我们普通数据库是关系型数据库，我想说，不管怎么样，我们要展现给客户医疗的检查结果，医嘱等等。这时候，这种大的文本或者图象资料的展现方面性能上有什么比较？

回答：现在世界上在向结构化的这种东西发展，不会要求存储大篇的文本或者扫描、手写。

郭志勇：实际上根据你的存储链接指定了一个地址。

回答：在医学上面处理图片有专门的系统，比如医学影像系统。这个东西不会把它存在数据库里面，因为将来要看的时候传入二进制的流就可以了。这时候的优势，就是将来的处理挖掘，比如现在统计心脏病的信息，我要知道，在高发地区，这些人里面有多少人是吸烟、饮酒的，有什么不良习惯，等等的信息都要进行统计。这种数据结构，定义的信息多种多样。包括人，眼科、儿科、口腔科等等，它们的区别很大。所以现在主流的电子工业的开发商都采用了我们的数据库。

提问：你们的数据库跟去年Oracle收购的公司在本质上有什么差异？数据在内存中建立的方法和它对数据定位的方法不太一样，因为它一定知道数据以后，它有它的算法知道这个数据在哪里？它能够提高处理的效率，数据在内存里面的存储方法是最主要的，同时引入了一个问题，这个应用必须跟它比较好的结合，应用服务器就跟这个服务器在一个上面。应用服务器的进程就是访问服务器的过程。但是它是捆在一起的。如果应用服务器和它分离的话，这个问题就不好解决了。就会遇到很多的问题。我听Oracle人讲了以后，我不知道你们个产品跟它们有什么差异？

回答：谈到这个问题，我们稍微集中在技术的细节上面。在保存数据的时候，是把它存在Bloce上面去。它会把这个bloce和相关的bloce进行缓存。我们通过这种缓存的方式极大的提高我们的缓存运用率。一个澳大利亚的客户，他们每个星期必须要求系统重启一次。当它重启以后发现反映慢，但是过了两天之后，系统速度又非常快了。这是我们的缓存上带来的一些变化。开发人员在写程序的时候，不用考虑太多的结构问题。

提问：刚才你们说一秒钟有七千个访问的系统，应用跟数据库是分开的吗？

回答：一个医疗集团下面有N多个医院，很多的医生前面都有好多的工作站。这样工作站系统是非常庞大的。是通过我们的三层结构对前面的访问进行支持的。

主持人：接下来有请微软公司的孙巍给我们介绍一下Service的内容。

孙巍：先说一下XMILE吧！对于制定这种标准来说，大家也看到，从技术结构来说，它已经渐渐不能再满足我们很多复杂的业务模式的需且。XML应该是未来数据标准很重要的部分。在数据库里面对Xmile的处理来说，也是可以支持一定XML的处理能力。我们对XML的存储上面没有问题，关键就在于查询。

我们对于XML的查询，应该不算量级上的问题。但是我们可以针对XML可以做相应的索引，以及在查询引擎上的优化。这种性能完全是为了满足我们以后对于这种丰富的XML的需求，根据这个需求做。除了对XML的满足以外，你也会发现，现在在互联网上，更多的Web Service的出现，从数据库到应用之间，我们的XML是不需要进行这种转换的，直接在数据库是什么的，我们就可以把出来的XService直接拿来用。也就是从底层的存储，是可以这样做的。

SAP：现在随着企业应用系统，像SOA体系结构的转化，产生的数据类型会变化，数据访问方式也会变化。像Service 2000的时候考虑应用环境的变化，不仅从应用层面的支持，还也一些访问方法，包括关系数据库的引擎等等。再一个，数据库的一个重要点化的趋势，数据库原来主要管数据。现在的趋势，它不仅仅是管理数据本身，包括外界系统怎么样访问数据，这也是很重要的方面。所以提供的Service的版本，跟数据库直接进行通讯，能够大家提高我们企业应用处理的性能。比如接收到一个订单，你可能安排生产、库存、发货等等很多流程。这时候可以用这个体系，发送到多个不同的数据库里做一个处理。这个应该是整个数据库市场未来考验的趋势都会往这个方向走。现在微软迈出了在这个领域，先迈出了一步。另外一部分，关于海量数据这部分，也是当前的应用，我觉得跟现在的应用环境也有很大的关系。过去之所以数据少，是因为我们的应用系统少，产生数据的地方也少，数据和数据交换也少。随着各种应用系统起来的话，我们可以涉及到管理的摸到的地方也越来越多，数据库的引擎对于海量数据的管理，原来只是说最高端的大型企业，说我们电信、银行、我们有海量处理，现在可能不是，现在可能是一个制造业企业，一个数据库里面有几个G的数据是很正常的事情。所以对于海量数据库的要求，微软看到它的下移的趋势。怎么样能够让原来很昂贵的技术，能够在中小企业里面，大家能够以比较较低的PCO整体成本，具有这样的能力。所以在Service2005年里面的各个版本，这方面都有比较大的增强。对于十几个G，几十个G的应用，在这个上面非常常见。

主持人：接下来我还想请冯先生给我们描述一下作为一个数据库专家，你对将来数据库的发展，从用户角度，你觉得有哪些方面需要增强的？或者数据库应该往哪个方向发展？

冯先生：我作为最终用户，我自己面临的困境，比如我作为最终用户，我们在构建一个系统，当然不光是数据仓库，更重要业务系统入手的话，我们肯定先从硬件级别的语言都好做。当一个数据库发生故障的时候，或者一个子级发生故障的时候，怎么能够在比较短的时间内使业务能够连续。在保障我们恢复数据的时候，怎么样把应用提起来。现在不管是存储厂商也好，还有其他的软件厂商，都在搞复制也好，等等整合的产品很多。现在面临这样的困境。因为系统不是单一的，不是说我这个复制过去多那个机房就可以了。其实可能是业务越来越多，有很多的系统数据由于历史原因造成的，不可能否定历史，我现在以前可能用的英文的，中文的，现在面向国际化的。我们的业务在这个机房里面各种形式的都有。比如想在上海搭一个，美国搭一个，如果这个机房发生什么灾难了，怎么包括那边业务的延续呢？

比如Oracle现在大力推的一种方式，像历史上的易贝都不现实用的。因为它没有办法支持很多的东西。用户群体也不是很广。我们随着公司规模越来越大，高层领导会越来越关注这个问题。以前追溯发展的时候没有人考虑这些东西。

目前看来我觉得是比较痛苦的事情，这个整合比较困难。各个厂商的SOA什么也好，我现在感觉IBM没有跟我探讨过SOA的东西，但是我们公司也做过一些事情。Oracle也跟我们沟通过这个事情。跟他们了解，如果当我们数据量比较大的话，都很难做这个事情。对于我来讲，数据库怎么样保障业务的延续性和结合、容灾、跨机房、跨城市的东西，说起来大家都是一套一套的，但是真正实施起来都是很困难的事情。

刘晶炜：因为我做整合做了三、四年了，客观来讲，在海量数据的方面，即使是IBM也没有跨越任何的系统。可能在我们的政府上，我们也做过一些对很多Oracle、Service的老系统做了一个设置。这里面很多的细节问题。里面有一个问题今天没有办法很好的解决。这是我从IBM给你的建议，因为我们自己知道这个技术有多大。比如我们自己在银行，这个领域就是大型的客户，越是核心客户，越关注这点。

我们最近刚刚做的就是新推出的一种方式，现在尝试着一个新产品出来，一个尝试着复制的方式，我们在一台机器上面，595的机器，我们大概一秒钟做三万笔。第二种方式，一般来说就是多结点。多结点最麻烦的就是没有两块数据。当你考虑容灾甚至不仅仅是容灾，很多用户考虑容灾方案。容灾这个系统还要提供服务，至少提供查询的服务。这个技术当一个操作过来的时候，往这边写的时候，后面定期的把一次写的操作分到几个地方去。你读的时候，实际上我有几份同样的技术，你查的时候外面有一层，是找任何一个结点，这里面有好多新技术去做。这些，我相信整个市场要选的用户，都是大用户，但是不会有特别多的用户。

卢东明：你刚才提到容灾的东西，这个有一点国情的区别。因为在美国，这个公司做数据库的时候，有一次我跟我老板讨论的时候DR的问题。也就是容灾的问题。他的观点让我大吃一惊。他觉得我们容灾的系统一动不能动。中国很多企业都会面临这样的问题，就是闲置一台机器是很大的浪费。我们拿来做一些查询或者分布吧！但是，后来能够理解它的观点，我们是一个金融公司，每天的交易量大概几亿美金。当你面临这样一个系统的时候，你能不能把备份的系统，控制到20%以下的CPU可以接受。到时候把这些挪过去可以撑到百分之百还能够用，事实上你控制不了。那个钱你必须要花。

冯先生：硬件上的投资怎么都好解决。这个方案还要考虑它的复杂性，其实国内，有些银行像一些大银行，发生故障，比如北京发生了故障，全国业务可能停了。要不要切到上海，最终选择整个系统都停了，因为它怕切了有问题。为什么有问题？因为这个事情很复杂。

张乐奕：硬件可能完全一样，但是你说很完整的测试在中国的这种情况下不会实现。

冯先生：你后面逐渐加了，业务系统也变了，你能不能保证过去之后都在你的掌控之中，没有人有这个把握。一个系统当它变化发生的时候，很难控制。

SAP：目前我们容灾，两个环境，在你的生产环境里面能够正常运行，要保证在灾倍里面正常的运行。今天我做了新的业务，我改了我的一段程序，也许这个东西切过去以后，不能够保证正常的运行。要保证正常运行的时候，你在新业务测试的时候，你要做切换测试。还要做灾倍演习，因为演习存在大的风险。所以以目前的技术而言，你要做很完整意义上的灾倍，不是很简单的事情。

张乐奕：一个系统投资越高，越不敢动。如果你投资十万块钱的时候，随便切。
主持人：这个问题我们一直讨论不清楚。

SAP：它所贯穿的层次在硬件、软件、技术、操作系统等等各方面都有应用。

冯先生：因为一个系统切换过来不是一个数据库，可能有很多的数据库。要保证整个公司的业务连续，要保证整个的业务都要过去，都过去以后，是不是两个都跑到一台机器上了等等的问题都非常的复杂。这种事情对我来说是很痛苦的事情，如果你要把它拔高到整个的软件或者其他环境，在我们国家目前没法解决。这不是花钱不花钱的问题，比如总行长要不要决策，到底要不要切，这个涉及到政治的风险。如果一旦切过去不行的话，风险就高了，他可能今年就难过了。
我们的数据库在仅仅保障数据库的条件下，要能正常。

提问：我发现厂商讲究的下一代的数据库应该是SMS，而我们用户关注的就是可靠性。

主持人：可能厂商走的路跟用户关注的东西不一致。大家看看以后能不能一致一些。

张乐奕：因为厂商要领导，所以它必须要前瞻。

提问：我想问的，厂商弄了这些潮流，是不是能变成有用的东西。

张乐奕：有一些是可以的，但是需要尝试。到现在来看，真正的生产使用环境有几个在用JAVA系统的。

张乐奕：曾经失败的面向对象的数据库，在92年的时候，这个面向对象的数据库出了很久。

易贝：面向对象的问题，我们易贝层面考虑过，但是欧洲等等地方，它们没有任何一个面向的对象能够承受到这么大的程度。你要想超出关系数据库的成本，是不存在的。所以这里面存在一个性能的问题，还有数据浪费的问题。

SAP：当我们讲Xmile的时候，Xmile要解决当前不能解决的问题。

主持人：因为时间的关系，今天下午的讨论活动就到此结束了。大家在活动结束之后，可以自行结组讨论。谢谢大家的积极参与。