数据库是IT领域应用为普遍的基础软件之一。在企业的核心业务系统之中，数据库往往扮演着非常重要的角色，在一定程度上会直接影响项目的成败关。应该说，过去数据库选型并不是太难：因为几乎所有（但不）基于数据库的应用都要选择关系型数据库，选型时重点考虑的是到底选Oracle还是DB2、Sybase或者SQL Server，在方向上不会出问题。

然而，选择多了，在传统关系型数据之外有了以Hadoop的HBase、MongoDB为代表的NoSQL、还有在互联网网企业广泛使用的以MySQL为代表的开源数据库。有了选择其实是一种痛苦。在面临更多数据库选项，特别是市场充斥着一些类似“开源数据库取代商业数据库”、“NoSQL取代关系型数据库”的说法的时候，更有必要理性正视自己的业务需求，客观分析各种选项的优缺点，然后做出正确的选择。

关系型数据库不可替代

“和以前相比，现在市场上有太多不理性的声音，其中有些甚至是完全错误的说法。而出现这些错误的根源在于，缺乏对数据库技术的了解。”甲骨文公司副总裁及大中华区技术产品事业部总经理吴承杨告诉记者。

甲骨文公司副总裁及大中华区技术产品事业部总经理吴承杨

在吴承杨看来，离开了具体的业务需求，简单地说采用Hadoop + NoSQL来替代关系数据库、采用开源的关系型数据库诸如MySQL是否更节省成本是没有什么意义的，而认为关系型数据库已经过时更是毫无道理。

“现在关系型数据库仍然不可替代，特别是一些关键的核心业务系统中，即使在互联网公司它的作用也是如此。”吴承杨介绍说。

全球在线支付巨头PayPal就是Oracle数据库产品的忠实用户。作为一家快速增长的互联网金融企业，PayPal面临着海量数据、业务服务等级SLA要求高，这个高速的OLTP环境中运行着超过500个数据库实例，在峰值时段，需要每秒钟处理超过30万执行，实时分析 99.99% 的关键应用，针对95%需求 < 40 ms 响应时间（这是Paypal在2012年公布的数据）。PayPal选用了甲骨文公司全线产品包括Oracle Database、Oracle Exadata、Oracle GoldenGate、Active Data Guard等，搭建了业务关键数据库、主生产中心和容灾生产中心的关键架构。

实际上，即使像MapReduce技术的发源地Google也不认为NoSQL能取代关系型数据库MySQL，Google认为其业务逻辑在没有SQL的查询支持下无法工作，为此他们正在开发F1分布式关系型数据库系统。

多种数据管理技术共存

当然，不可否认，近年来关系型数据库的确遇到了很多挑战，其中为主要的是数据处理类型日趋复杂，数据量的爆炸性增长。这两者都会给数据库带来性能压力，过去解决这两个问题的办法是对设备和软件进行升级，但现在这一办法开始行不通了。一方面，垂直向上扩展（Scale-up）终究能力有限，而且成本巨大；另一方面，在对类似网络访问日志这样的数据资源采用传统数据库有些“大材小用”，技术上并不合适，成本也太高。

值得一提的是，对于这些的挑战，关系型数据库也在积极应对，这主要表现在通过水平扩展（Scale-Out）策略来应对数据量增长以及性能带来的压力，具体手段包括列存储、智能扫描、内存计算以及数据库一体机等。

“任何一种技术都有其应用范围，关系型数据库也不例外，我们不能指望它帮助我们解决所有数据管理方面的需求，这也正是NoSQL兴起的原因。”吴承杨表示，“NoSQL的本质是对关系型数据库的一些特征与约束进行简化，以满足一些特定的需求，而不是要推翻它。正如关系型数据库有其适用范围一样，NoSQL有其适用范围，并非所有场景都合适。”

NoSQL适合那些对数据操作需求比较简单，一般不需要采用SQL语句的场合，比如网络日志的处理，在这些场合如果采用关系型数据库就不得不承受那些并不需要的高级功能（如强事务性、丰富的索引、强一致性保障）能而带来的扩展性约束、性能约束和高成本。

“从长远来看，未来数据库技术已经会走向传统关系型数据库与NoSQL这些数据库并存、内存化（即内存计算）、数据库云以及数据库一体机。”吴承杨说，这也正是甲骨文近年来在数据库领域的投资重点。

实际上，作为甲骨文其他业务的基础，甲骨文在数据库市场不敢懈怠，并一直致力于创新。比如，版本的Oracle数据库12c采用了创新的多租户架构，用户可以利用Oracle数据库12c轻松实现云端整合，显著提高运行效率并大大降低成本。近期，甲骨发布了划时代的数据库产品OracleDatabase In-Memory，进一步增强了Oracle数据库12c的威力，帮助企业实时挖掘深度数据信息，提高交易性能。还有在云计算方面，甲骨文的数据库即服务（Database-as-a-Service，DBaaS）能够帮助企业简化其IT系统化，并进一步达到动态优化和资源管理的高效系统。