甲骨文数据库将被取代Or不可替代

在 IT 业界，甲骨文是一家有着异常鲜明的“工程师文化”特质的公司。这一特质有着多种体现，体现在其创始人及 CEO 拉里·埃里森依然会在一线引领甲骨文的技术方向；体现在甲骨文会拿出全年利润的一半用于研发（每年研发投入 50 亿美元，2014 财年净利润 109 亿美元）；体现在尽管微软、SAP、IBM、亚马逊的公有云纷纷曲线落地中国，而它还在按兵不动，觉得时机不到，而它眼中的时机，不是寻找本地运营商，不 是寻求政府关系，而是做足技术和人员储备。

　　甚至面对去 IOE、国产化等敏感话题，甲骨文依旧希望让技术来说话，从技术的立场上说服用户面对 IT 采购时更加理性。

　　当数据库领域掀起用开源的数据库代替企业级数据库，用 Hadoop、NoSQL 代替关系型数据库的呼声后，似乎数据库领域的去 IOE、国产化也变得不那么遥不可及了，事实是这样吗？甲骨文公司副总裁及大中华区技术产品事业部总经理吴承杨对此进行详细剖析。

　　理性考虑下选择并非眼花缭乱

　　虽然互联网公司选择开源数据库和 Hadoop、NoSQL 代替企业级数据库、关系型数据库的做法让很多用户心生萌动，但是以下几个来自互联网公司的实例也正说明：作为承上（应用层）启下（架构层）的基础，数据库 （平台层）的选择需要异乎寻常的理性，也并不会令人眼花缭乱。作为 SaaS 全球第一的公司，Salesforce 在一年前与和甲骨文签订了长达九年的战略合作，部署 50 台甲骨文 Exadata（数据库云服务器）一体机，把其所有底层全部架构到甲骨文上。

　　第二个例子是美国最好的支付公司 PayPal，PayPal 大概有 500 个数据库，OLTP 交易可以达到 130 个T，并发进程每秒钟有 12 万，数据量每 18 个月翻一倍，为了满足对精准性和安全性的要求，PayPal 选择了甲骨文的企业级数据库。

　　而发明 MapReduce、hadoop 的谷歌，虽然掀起互联网公司引领大数据的热潮，但是也表示 NoSQL、MapReduce 没有办法取代关系型数据库：在技术层面，它们的业务逻辑在没有 SQL 的查询支持下无法工作，NoSQL 无法代替原有的 MySQL。作为替代，它们正在开发 F1 分布式关系型数据库系统。

　　你要的是松耦合还是紧耦合？

　　其实面对企业级数据库，用户选择替代品的原因也并非一味的“挑战权威”、为了改变而改变，似乎开源的开放、自由、灵活、低成本也是考虑的重要因素。而面对企业级数据库，开源是否真的有着这么多的优势呢？

　　因为同时拥有企业级数据库产品（已经发展到 12c 版本）和开源的关系型数据库产品（MySQL），甲骨文的立场当属中立，它的建议，对用户来说值得参考。对于这两条产品线，吴承杨认为各自都有着非常明确 的应用场景：MySQL 主要定位在关联性、复杂性、可靠性要求不高的非核心交易类的应用上，比如小型企业或者大型企业内部的小部门，MySQL 对复杂 SQL 的支持能力、数据存储能力及大型应用支持能力有限；而企业级数据库在高可用性、安全管理、性能诊断、备份、商业支持等方面的优势迄今依旧是无可替代。

　　在吴承杨展示给记者的一张包含企业级数据库、MySQL、NoSQL、MapReduce 的对比图中，结果一目了然。

　　而开源的开放、灵活，也不是没有限制的，有些时候甚至限制更多。在一些关键性应用或者大型应用上，如果一定要使用开源，意味着要把平台层做的事 情放到应用层。而应用层、平台层和架构层要想部署成云的环境一定要松耦合，也就是上层不需要考虑下层，有平台层去考虑。依旧以 MySQL 为例，如要采用 MySQL，一定要在应用层做很多工作，这就变成紧耦合了，意味着的确减少了数据库的采购和维护成本，但是开发的成本会很大；除此以外，开发时间会很长； 另外，因为所有上层系统都是由开发商来做，用户会被某一家开放商牢牢锁定。

　　企业级数据库三大发展趋势

　　面对传统的企业级数据库与开源数据库、非关系型数据库的技术演进和交织博弈，其实也让甲骨文的企业级数据库策略变得逐渐清晰。对此，有三个趋势：

　　首先就是内存化。甲骨文的即插即用型内存数据库选件 12c In-memory 已经在不久前正式发布，国内也有了第一个内存数据库用户。关于甲骨文的内存数据库产品的特点和特性已经有了非常多的介绍，包括其与友商同类产品的对比，业 界不乏各类声音。如果以一句最通俗的话来解释甲骨文的内存数据库，那就是：在内存、闪存、磁盘三个层面，让原本跑得慢的东西快起来。（有多快？有结果表 明，通过采用 12c In-memory，甲骨文的主要应用程序 JD Edward、PeopleSoft、E-Business Suite 和 Siebel 的性能提高 100 倍至 1000 倍。）

　　其次就是结构化和非结构化统一。NoSQL 在结构化和非结构化共存方面有很多优势，在这方面甲骨文有企业级 NoSQL，也有 MapReduce，这也就意味着其大数据解决方案既包含关系型数据库，也包含非关系型数据库。

　　另外一个趋势，也是云计算时代让企业摆脱传统的 licence 限制、控制成本的有效手段，那就是数据库云。DBaaS（数 据库即服务）在 2013 年的 Oracle OpenWorld 上发布，在 DBaaS 的演进中，有传统的 RAC（Real Application Cluster）标准化平台，有 Exadata 数据库云服务器。数据库云让企业按需使用，提高效率、控制成本，甲骨文数据库 12c 的多租户特性实现真正的随时插卸，甚至可以有几百个可插入式数据库与应用打交道，实现真正云的管理，这也是甲骨文关系型数据库非常领先的特质。

　　让用户的选择更理性

　　作为一家“工程师文化”的公司，甲骨文更希望在技术层面给用户一些理性选择的建议。对于开源数据库 MySQL 和企业级数据库“两手都要硬”的甲骨文来说，不存在两条产品线左右互搏的情况，甲骨文会给用户选择，只是这一选择是建立在理性的基础上。

　　面对客户的选择，甲骨文也有无奈之处，吴承杨告诉记者：“很多时候用户是在选择开发商，开发商再根据它的喜好去选择合作伙伴，我们处于被选择的境地。”

　　而面对国产化的呼声，甲骨文也有着淡然处之的态度。“市场上出现国产数据库是件好事，我们赞同国家在国产数据库上投入和发展，我们也愿意配合。 如果用户站在理性的立场上选择了国产数据库产品，我们也会理解，但是甲骨文数据库的 RAC 技术在国产数据库市场很难看到。对于软件产品来说，其重点在于它的成熟性，而成熟性是通过达到一定量的使用才能实现的。”

　　结束语

　　在吴承杨的介绍中，有众多有说服力的案例，也有失败的教训。据他介绍，今年一家大型 3C 公司邀请国内某家著名公司共同做开源数据库，其中既用到 MySQL 也用到 NoSQL，但是半年之后系统做出来后与应用没有办法很好的结合，最终还是又翻回来采用传统的企业级数据库。对于这样一个实例，并非是要充当血淋淋的反面 教材，而是把用户在采购决策时的不理性呈现出来。开源、大数据、集成系统、内存计算、数据库云...面对纷繁的选择，用户只有了解，才好决策。而甲骨文要 做的，是让技术来说话。