http://www.lupaworld.com/viewnews_127497.html
从Oracle三大并购案看MySQL的去留存活
发布时间: 2009-04-23 10:32 作者: 赵建凯 来源: IT168
关键词: MYSQL ORACLE 发展趋势 并购案 数据库
Sun发布MySQL 5.4预览版
在被甲骨文宣布并购Sun的同时，Sun于
Sun说明，MySQL 5.4版让InnoDB存储引擎可扩展到16位 x86服务器及64为 CMT服务器，并改善子查询最佳化（subquery optimizations）与结合（JOIN）功能，因此对特定查询的响应速度可快上90%，而且这些效能与延伸性的改善不需要使用额外的应用程序或撰 写SQL程序代码便能使用。
Sun软件架构副总裁Karen Tegan Padir表示，透过新版的MySQL，开发人员不用修改应用程序就能增加效能与延展性，以符合更多的使用者及数据处理需求，而且更适用于对称多处理 （Symmetrical Multi-Processing，SMP）系统上的扩充部署。
ThePlatform的数据库部署经理Phil Hildebrand表示，初期测试MySQL 5.4时发现其应用程序效能最高可提升40%。
根据Sun所列出的MySQL 5.4版特性，其改善的部份包括提升近两倍的延伸性；改善查询分析运作方式让子查询可在零散的时间进行以加快响应速度；采用新的查询法则；采用 SIGNAL/RESIGNAL提供更健全的错误管理以改善储存程序；在预先编好的指令（prepared statements）中支持输出参数；改善Information Schema及对DTrace的支持等。
MySQL 5.4预览版支持Linux及Solaris 10的64位版本，预计在今年出炉的正式版将会扩大支持Microsoft Windows、Sun Solaris 10、Mac OS X、Free BSD、HP-UX、IBM AIX及IBM i5/OS等其它软、硬件平台。
甲骨文（Oracle）于
MySQL的路还有多长？
甲骨文(Oracle)迎娶Sun后，是否宣告MySQL就此消失，是许多MySQL使用者与企业关切的重要议题。现在，我们试着从甲骨文的并购史与MySQL的市场状况等2个层面来试图解答这个问题。
甲骨文向来善于从并购来的公司中发现好产品。此话怎讲？让我们先一起来回顾甲骨文是如何处理并购来的产品服务：
BEA并购案：扶持优秀产品
并购BEA后，甲骨文大刀阔斧的以BEA的Java Container–WebLogic，取代自身的Java Containers–OC4J(Oracle Containers for J2EE)：甲骨文的中间件软件（Fusion Middleware；FMW）产品改以BEA的WebLogic为核心。甲骨文会这么做，主要是因为WebLogic的效能比OC4J佳。
而且还开始支持、销售BEA的其它产品，以Portal为例，甲骨文自己虽然也有Portal产品，但在并购BEA后，我们开始在甲骨文中间件软件 (FWM)这条产品线中，看到BEA的WebLogic Portal(WLP)踪影；除此之外，甲骨文的经销伙伴在销售Portal产品时，也转以WebLogic Portal(WLP)为主。
Siebel并购案：挖掘好的产品
在这里我们想讨论的不是Seibel的客户关系管理(CRM)软件，而是Seibel客户关系管理软件内建的商业智能（BI）引擎。Siebel被并购 后，除Siebel客户关系管理软件跃为甲骨文的客户关系管理软件的主流产品外，客户关系管理软件里的商业智能引擎也被挖掘、发展成甲骨文主力推广的商业 智能产品，即商业智能企业版（Business Intelligence Enterprise Edition；BIEE）。至于甲骨文原生的商业智能产品─Oracle Discovery，则退居为二线产品，即商业智能标准版（Business Intelligence Standard Edition；BISE）。
随着甲骨文的产品策略调整，甲骨文的经销合作伙伴也渐渐不再销售甲骨文的原生商业智能产品─Oracle Discovery，也就是现在的商业智能标准版(BISE)；关于这点，我其实挺讶异的，毕竟，甲骨文当初看中的是Seibel的客户关系管理 (CRM)软件，没想到，最后竟然连客户关系管理软件的组件─商业智能引擎，也一并用上了，而且还拔擢成一线产品。
在实际比较、试用过商业智能企业版(BIEE)与商业智能标准版(BISE)等两套产品后，我认为甲骨文的策略是对的，也佩服其细心与远见。毕竟，就系统成熟度来说，Siebel的商业智能引擎远高于甲骨文原来的商业智能工具。
Hyperion并购案：留下、发展有价产品
在甲骨文挖掘Siebel客户关系管理软件的商业智能引擎成为商业智能的主力产品后，市场对于其会如何整合并购进来的Hyperion、重划商业智能产品线，十分关注。
会宣告商业智能企业版(BIEE)结束营业、改以Hyperion为商业智能工具的一线产品吗？如是依照以往的经验，Hyperion确实可能凭借既有 市场份额完全取代甲骨文的商业智能企业版(BIEE)，毕竟，商业智能企业版(BIEE)只是从Seibel客户关系管理软件的一个组件发展出来，而且， 商业智能企业版(BIEE)的市场占有率也不可能(短期内)一下子就冲得跟Hyperion一般。但是，很特别的，甲骨文把商业智能企业版(BIEE)留 下来了，而且还加进了Hyperion IR与 Hyperion Essbase的某些功能，推出新的商业智能工具─BIEE Plus。
至于Hyperion的其它产品，如企业绩效管理(Enterprise Performance Management；EPM)，甲骨文则为其在中间件软件(FMW)这条产品线中找到定位：在商业智能分析的金融等专业应用领域中，成为甲骨文的主力产品。
从上述三个并购案来看，甲骨文对于被整合公司的产品态度，并不单纯以本家/外来者、或者是以市占率作为优先考虑，产品本身的可用性、技术性、整合性，以 及发展性，才是左右其产品决策的核心。也因如此，我认为只要是够成熟、有其技术或发展价值的产品，就算它是外来品，仍有机会在甲骨文的产品线中，崭露头 角。
市场（使用者）有权决定MySQL的存续
MySQL之于甲骨文的状况，其实有点像Sparc/Solaris之于IBM的情况。
开源这个特性已保障了MySQL的存续。决定MySQL能否继续存在这个市场的人，是热爱使用开源的广大使用者以及开发者，而不是甲骨文。也就是说，就算甲骨文这个大当家对MySQL的态度是存而不论，难道MySQL(非甲骨文)的开发者就不能持续地开发、维护它吗？
换个方向想，就算甲骨文决定以目前的版本为基础，开发一个新的、需要付费的MySQL版本，难道开源体制下的MySQL爱好者、开发者不能基于既有的 MySQL版本开发另一套依旧免费(Free)的MySQL吗？(版本、名称必须与既有版本做区格，以免出现混淆或者是侵权）。讲难听一点，甲骨文只买得 走MySQL这个名字、无法独霸MySQL的源码(Source Code)。理由也很简单，MySQL的源码已经开放(Open）很久了；所以，最差的情况是，开发人员以这些被开放(Open)出来的MySQL源码为 基础、稍做改良，并且改个名字（看是要叫nonOracleSQL、DuncanSQL、或ShowSQL都可）后，就可以重新再出发了。说不定，在甲骨 文宣布并购Sun的同时，已有MySQL的忠实爱好者、或支持MySQL的开发者已在这么做了。
另外，甲骨文也不是第一次涉入Open Source的软件；至少在2007 年，其就透过Unbreakable Linux计划跨足Linux服务市场了，可你猜怎么着？红帽(Red hat)、FreeBSD或其它的Linux厂商并没有因为甲骨文宣布加入该市场而消失。
MySQL亦然；从某个角度来看，甲骨文只不过是广大MySQL开发者的一份子，MySQL存活与否，是由市场供需（需：有人要使用；供：有人进行维 护)决定，而不是甲骨文说了算。 再者，以MySQL的市场使用率来说(这边必须再次强调，我说的不是数据存储量)，其极可能是数据库市场之冠，毕竟，有太多开发人员、微型与中小型企业喜 爱、使用MySQL这个免费又开放的数据库产品。在这样的状况下，换做我是甲骨文，即便MySQL没办法为我赚钱，我至少还是可以利用MySQL赚个"名 "。
平心而论，Solaris以及其它的硬件才是甲骨文垂涎之处，MySQL反倒不是重点，在这样的状况下，我个人认为，短期内甲骨文对MySQL的态度可 能是：存而不论。但这又如何呢？支持MySQL的开发者、企业还是可在开源的规划下使用、维护与开发它，不论现在或未来，甚至是将之换个名字再出发；那甲 骨文若决定加入MySQL的开发与维护市场，结果如何？那我们又为何不能采以开源(Open Source)中的开放(Open)胸襟，拥抱、欢迎他的加入呢？
没有评论:
发表评论