一.软件功能对比
二.成本考虑
三.满足业务场景
四.平衡各种资源
一.是否满足业务场景，各DB系统软件功能对比
1.功能对比
oracle功能是大而全并且非常完善，无论是锁定机制还是事物支持，无论是内置函数还是外部可扩展功能，无论OLTP和OLAP都能很好的支撑。
mysql作为开源数据的代表，得到了广泛的应用，关系型数据库的常用功能也全面覆盖到了，但mysql的缺失大表的hash join功能，这让他在OLAP发展受阻。
nosql主用用于K/V环境查询的场景，在事务以及Join方面都未支持，能支持多维度复杂过滤的产品比较少。
从功能角度比较 oracle > mysql > nosql
2.性能强弱
2.1 write性能
Oracle需要记录Redo Log且保证每次事务都fsync到物理磁盘以保证事务安全，属于连续写;数据的写入大多是在内存中完成，后台进程进行内存到磁盘的定期批量刷新，以随机写为主。MySQL InnoDB引擎与Oracle类似;MyISAM引擎无事务所以没有事务日志到磁盘的fsync问题，但由于其表锁的原因，并发较弱。从总体使用经验来看 和Oracle相差不大。
NoSQL在数据存储及日志记录方面的架构及实现优化，使之在写入性能方面较传统数据库有较大优势。
总的来说write性能 NoSQL > Oracle = Mysql
2.2 简单查询
Oracle在高并发场景下，由于其在事务控制实现方面的优势，以及多进程的机制，显示出了相对明显的优势。
MySQL在并发数不是太高的前提下，如16，32个并发场景下，相对于Oracle没有显示出弱势，甚至部分存储引擎下还有一些优势，但是随着并发数 的增加，就逐步体现出了与Oracle的差距，这与其基于线程的机制也有一定关系。
NoSQL大部分时候的简单查询性能都不如前二者
所以简单查询的性能 Oracle > Mysql > Nosql
2.3 复杂查询
Oracle统计信息涉及的方面非常多，优化器相对于MySQL来说也先进很多，再加上对Join方式的全面支持，无论是从功能还是性能角度来说，多表 Join都是Oracle的优势所在。
MySQL其查询优化器所能参考的统计信息相对较少，优化器深度也比Oracle少很多，所以在多表Join的时候出现执行计划异常并不少见。此外，不 支持 Hash Join 的天生缺陷也让其 Join 能力大打折扣。
NoSQL不支持Join，不具可比性，无疑是最弱的
索引复杂查询性能 Oracle > Mysql > Nosql
3.扩展能力
Oracle由于极高的一致性要求，采用share Everything架构，造成架构上不少限制，使其扩展陈本较高
Mysql的Replication特性对一致性要求较弱，使其架构很灵活，但slave的延迟是个大问题。
Nosql大都支持分布式部署，具有非常好的scale out能力
所以扩展能力 Nosql > Mysql > Oracle
4.商业支持
NoSQL产品目前有商业支持的很少，MySQL的本地化商业支持选择并不多，Oracle方面的商业支持无论是大型公司还是初创团队，选择性相对比较广泛
所以在商业支持方面：Oracle > Mysql > Nosql
5.软件可维护性
这一点一直是运维人最为关注的因素，毕竟任何一个软件系统都是需要后期维护的。
NoSQL 产品由于发展时间相对较短，对于可维护性角度的支持相对要少很多，虽然大多提供了一些相应的小工具，但总体来说都还是过于简单了些，所以这方面和相对成熟的MySQL以及Oracle相比较要弱。而Oracle为后期维护所做的
工作无疑是最为全面，无论是运行状态的跟踪，还是基础的备份恢复等，都很完善。
所以在可维护性角度方面：Oracle > Mysql > Nosql
三.业务场景分析
1.数据一致性要求
虽然无论你什么时候去问任何一个业务方，都会告诉你他系统的数据是不能有任何一条丢失的，任何时候都需要实时反馈变化。但实际上是当你换一个提问方式，告诉他们如果在极端情况下（比如断电）也要确保数据不会有任何丢失，会增加几十上百万的成本，那这个时候得到的回答可能就会完全不一样了。所以我们在了解业务方对数据一致性要求的需求时候，一定要明确厉害关系，分清数据级别，并且做到最大化的信息透明，才能挖出最清晰的需求。对于数据一致性的保护，Oracle 无疑是做的最可靠的一个。
2.并发规模
并发规模会考验我们的扩展能力，如果并发规模很大，那我们就需要很好的扩展能力以保证后续并发增长的需求。选用一个难以扩展的系统，会导致后续并发规模增长过程中无论是时间成本还是经济成本都很高
3.逻辑复杂度
如果业务逻辑过于复杂，至少NoSQL肯定不是合适的选择，至于MySQL还是Oracle，那就是考验二者功能及性能的时候了。
4.总容量规模
我们的系统数据容量规模自然也会影响到软件选型，规模非常大的，肯定要用分布式系统支持，至少也得分库分表吧，这时候的扩展能力就会充分显示出其优势。
四.平衡各种资源做出最后选择
通过软件功能和成本对比，以及“场景分析”，我们已经为系统选型积累到相对充分的信息了，那是不是就可以比较明确的选择出合适的系统了呢？
这时候我们可能会发现我们的数量规模很大，但是又希望能够维护方便容易控制。这时候我们就面临如下问题：数据量规模大选NoSQL更合适，便于维护又是Oracle的优势，怎么办？ 又或者如果我们有这样一个场景：某交易系统，并发量很大，对于数据一致性要求很高，业务逻辑也并不简单，怎么办？Oracle可以为我们提供很好的数据保护，面对复杂逻辑的时候也能有最好的性能，但在扩展的时候会面临成本压力。MySQL可以提供较好的扩展方案，而且成本相对会较低，NoSQL无法解决复杂逻辑的业务场景。
类似问题可能会频繁出现在我们的架构师面前，需要大家根据各种利弊进行权衡，做好平衡决策，在尽可能满足业务需求的前提下，选择一个更合适的系统。有些时候可能也不得不作出牺牲极少数业务需求来换取系统更大的发展，而不要为了保全某些极端场景的需求而影响整个选型。
总结
数据存储软件的多样化趋势势不可当，不管是传统龙头的Oracle，还是开源典范的MySQL，以及NoSQL这一新秀，各有其特色，但同样也都有其短板。没有谁是万能的，同样也没有哪一种架构能应对所有问题。
作为一个架构师，我们的选型工作需要做到下面几点：
1. 在平时的工作中做好积累，以获得上面的“系统功能对比”和“成本对比”中的信息。
2. 在面对具体业务需求的时候，充分挖掘最真实的需求，并将各种利弊信息透明化
3. 在最终决策的时候做好平衡，从需求实现，成本控制以及维护管理多个角度权衡利弊
4. 对新技术学习的渴求不能影响选型结果，同样也不能对新技术的使用带有恐惧。
Oracle，MySQL 以及 NoSQL，都只是一个软件而已，实际使用效果更多的取决于使用者的能力。一个优秀的使用者能够充分利用其优势避开其软肋，最终获得最大化的价值。
二.成本考虑
1.软件成本
这个没有争议：Oracle > Mysql = Nosql
2.运维成本与团队管理水平
维护的服务器数量、耗电、自动化工具和人员配备数量
系统是否在团队的可控范围之内，出现性能、事故，团队要有能力解决
3.人才环境
Oracle发展几十年，具有充足的人才储备，活跃的社区环境。
MySQL开源数据库的王者，社区活跃，虽然人才总量常常供不应求，但总体还是处于良性状态。
NoSQL新技术，产品众多，社区活跃度远不如前面二者，处于人才极度匮乏状态