作为阿里引入 MySQL 数据库的第一批践行者之一，我经历了从Oracle的“一统天下”到被 MySQL 从周边应用逐步“蚕食”，直至核心系统都被替换成 MySQL的多个阶段。最初这是一个令人振奋的过程，虽然也伴随着DBA团队的不安，但总体都非常顺利。但随着这个过程的不断推进，痛苦慢慢袭来，尤其是对开发团队的影响越来越大。再后来…(再后来的事情就不便细说了)
现在回过头来仔细思考，方向决策没有任何问题，但实际执行过程及执行策略还是存在不少可以商榷的地方。比如成本比较的核算方式，执行范围的一刀切等等。
正是因为有这些“前因”，所以在2013年 OTN嘉年华上做了下面这样一个颇具争议的分享，针对目前吵得比较火热的“去IOE”中的“O”所涉及到的数据库领域的产品选择问题聊了下自己的看法。
随着阿里系的“去IOE”运动在社区的宣传声越来越大，国内正在掀起一股“去xxx”的技术潮。不仅仅是互联网企业，包括运营商以及金融机构都已经开始加入到这个潮流之中。作为运动中的这个“O”的Oracle数据库，自然就成为了众矢之的，众多CIO及CTO们都展示出一副欲除之而后快的表情。那在实际的应用场景中，我们到底该如何去选择数据的存取软件呢?
大概在09到10年左右，突然一夜之间满世界都在谈论 NoSQL，到处是关系型数据库要被 NoSQL 替代的声音，几乎所有人都在鼓吹NoSQL的各种好，但到目前为止也没有看到哪个数据库软件的市场受到了NoSQL的大冲击，当初红极一时的Cassandra也从老东家 Facebook的最初应用场景中退出舞台而改用了HBase。当初从关系型数据库 MySQL 转投 NoSQL 怀抱的 Twitter 经历了各种“痛”之后，又回到了MySQL的怀抱…
作为一个架构师，面对如此众多选择的时候，到底该依据什么来作出正确的决定呢?下面是笔者经验中常用的3步决策思路，希望对大家稍有启发。
一、 系统对比
功能差异
Oracle无疑是功能最为全面一个，无论是用于OLTP场景还是OLAP场景，都有很好的技术手段支撑;MySQL作为开源数据库软件的代表，对于关系型数据库常用的功能也都全面覆盖到了，但作为 OLAP场景所不可或缺的 Hash Join这一特性确实给 MySQL 的 OLAP之路造成了较大阻碍;而各 NoSQL 产品大多都不能进行非 K/V 式的数据存取，能支持多维度条件过滤的产品选择较少。
所以从功能角度来比较： Oracle > MySQL > NoSQL
性能强弱
根据过去的一些测试及实际应用场景的经验，基于同等硬件资源，可以从以下3个角度来对比性能：
写入：由于 NoSQL 在数据存储及日志记录方面的架构及实现优化，相对 Oracle 及MySQL来说都有不小的优势。而 MySQL 和 Oracle 二者差异并不是特别大，暂且认为二者并列吧。
所以从写入性能角度来比较：NoSQL > Oracle = MySQL
简单查询
关于简单查询性能的争议一直很大，有人测试出 Oracle 不如 MySQL 的结果，也有人测试出 MySQL 比 Oracle 差的结果。其实可能二者的测试都没有问题，真正的问题在于各自的测试场景的差异，尤其是并发数的差异可能会对测试结果造成非常大的影响。在高并量不断增加的时候(如到达128)，MySQL就会逐渐显示出力不从心的状况了。至于 NoSQL，至少在笔者的测试场景下大部分时候都是比前面二者性能要差。当然肯定会有大量的 NoSQL 粉丝们会跳出来反对，但请记住我们要的不是一个 Cache 产品，也不是比较大规模集群下的能力。
所以从简单查询性能角度来比较：Oracle > MySQL > NoSQL
复杂查询(至少含有 Join)
NoSQL 产品不支持 Join，所以无疑垫底，MySQL 的查询优化器由于所基于的统计信息相对少很多，当Query 复杂度很高的时候容易出现执行计划不是最优选择的问题，而 Oracle 由于大量的统计信息支持，使得其查询优化器更为智能，对复杂查询有更优的表现。
所以复杂查询的性能角度：Oracle > MySQL > NoSQL
扩展能力
扩展能力或者说扩展方便程度，一直是影响架构师选型的一个重要因素，毕竟我们的数据产生速度越来越快，很多时候都难以通过单机来解决问题。
单纯从扩展便利性角度来看，大部分 NoSQL 产品都有较好的分布式支持方案，无疑是最佳选择，而 Oracle 由于其对数据一致性的严格要求，以及架构的一些限制，扩展便利程度较 MySQL 要稍微弱一些。
所以在扩展能力方面：NoSQL > MySQL > Oracle
可维护性
这一点一直是运维人最为关注的因素，毕竟任何一个软件系统都是需要后期维护的。
NoSQL 产品由于发展时间相对较短，对于可维护性角度的支持相对要少很多，虽然大多提供了一些相应的小工具，但总体来说都还是过于简单了些，所以这方面和相对成熟的 MySQL 以及Oracle相比较要弱。而Oracle为后期维护所做的工作无疑是最为全面，无论是运行状态的跟踪，还是基础的备份恢复等，都很完善。
所以在可维护性角度方面：Oracle > MySQL > NoSQL
商业支持
NoSQL 产品目前有商业支持的很少，MySQL 的本地化商业支持选择并不多，Oracle方面的商业支持无论是大型公司还是初创团队，选择性相对比较广泛
所以在商业支持方面：Oracle > MySQL > NoSQL
软件成本
这方面没有太多争议：Oracle > MySQL = NoSQL
人才环境
这是很多人会忽略的一个因素，但实际上可能会给后续的使用及维护带来非常大的影响。Oracle作为发展了多年的数据库领域的龙头，所以整个 Oracle DBA 行业相对比较成熟，人才体系也相对稳定。MySQL 数据库作为后起新秀，已经有不少人投入其怀抱，但总体来说无论从数量还是质量角度来看，都远不如 Oracle DBA 这一群体。NoSQL 方面的人才就更为匮乏了。
所以从人才环境角度：Oracle > MySQL > NoSQL
二、 场景分析
一致性要求
虽然无论你什么时候去问任何一个业务方，都会告诉你他系统的数据是不能有任何一条丢失的，任何时候都需要实时反馈变化。但实际上是当你换一个提问方式，告诉他们如果在极端情况下(比如断电)也要确保数据不会有任何丢失，会增加几十上百万的成本，那这个时候得到的回答可能就会完全不一样了。所以我们在了解业务方对数据一致性要求的需求时候，一定要明确厉害关系，分清数据级别，并且做到最大化的信息透明，才能挖出最清晰的需求。对于数据一致性的保护，Oracle 无疑是做的最可靠的一个。
并发规模
并发规模会考验我们的扩展能力，如果并发规模很大，那我们就需要很好的扩展能力以保证后续并发增长的需求。选用一个难以扩展的系统，会导致后续并发规模增长过程中无论是时间成本还是经济成本都很高。
逻辑复杂度
很显然，如果业务逻辑过于复杂，至少 NoSQL 肯定不是合适的选择，至于 MySQL 还是 Oracle，那就是考验二者功能及性能的时候了。
总容量规模
我们的系统数据容量规模自然也会影响到软件选型，规模非常大的，肯定要用分布式系统支持，至少也得分库分表吧，这时候的扩展能力就会充分显示出其优势。
三、 平衡决策
经过了第一步的“系统对比”，以及第二步的“场景分析”，我们已经为系统选型积累到相对充分的信息了，那是不是就可以比较明确的选择出合适的系统了呢?
这时候我们可能会发现我们的数量规模很大，但是又希望能够维护方便容易控制。这时候我们就面临如下问题：数据量规模大选NoSQL更合适，便于维护又是Oracle的优势，怎么办? 又或者如果我们有这样一个场景：某交易系统，并发量很大，对于数据一致性要求很高，业务逻辑也并不简单，怎么办?Oracle可以为我们提供很好的数据保护，面对复杂逻辑的时候也能有最好的性能，但在扩展的时候会面临成本压力。MySQL可以提供较好的扩展方案，而且成本相对会较低，NoSQL 无法解决复杂逻辑的业务场景。
类似问题可能会频繁出现在我们的架构师面前，需要大家根据各种利弊进行权衡，做好平衡决策，在尽可能满足业务需求的前提下，选择一个更合适的系统。有些时候可能也不得不作出牺牲极少数业务需求来换取系统更大的发展，而不要为了保全某些极端场景的需求而影响整个选型。
总结
数据存储软件的多样化趋势势不可当，不管是传统龙头的 Oracle，还是开源典范的 MySQL，以及 NoSQL 这一新秀，各有其特色，但同样也都有其短板。没有谁是万能的，同样也没有哪一种架构能应对所有问题。
作为一个架构师，我们的选型工作需要做到下面几点：
1. 在平时的工作中做好积累，以获得上面的第一步“系统对比”中的信息。
2. 在面对具体业务需求的时候，充分挖掘最真实的需求，并将各种利弊信息透明化
3. 在最终决策的时候做好平衡，从需求实现，成本控制以及维护管理多个角度权衡利弊
4. 对新技术学习的渴求不能影响选型结果，同样也不能对新技术的使用带有恐惧。
Oracle，MySQL 以及 NoSQL，都只是一个软件而已，实际使用效果更多的取决于使用者的能力。一个优秀的使用者能够充分利用其优势避开其软肋，最终获得最大化的价值。
最后，在选型的过程中既要充分吸收业内经验，又不能人云亦云。不要看到别人的“去O”运动声势浩大，就一棍子打死 Oracle，你只看到了别人希望你看到的内容。