三.业务场景分析
　　1.数据一致性要求
　　虽然无论你什么时候去问任何一个业务方，都会告诉你他系统的数据是不能有任何一条丢失的，任何时候都需要实时反馈变化。但实际上是当你换一个提问方式，告诉他们如果在极端情况下（比如断电）也要确保数据不会有任何丢失，会增加几十上百万的成本，那这个时候得到的回答可能会完全不一样了。所以我们在了解业务方对数据一致性要求的需求时候，一定要明确厉害关系，分清数据级别，并且做到大化的信息透明，才能挖出清晰的需求。对于数据一致性的保护，Oracle 无疑是做的可靠的一个。
　　2.并发规模
　　并发规模会考验我们的扩展能力，如果并发规模很大，那我们需要很好的扩展能力以保证后续并发增长的需求。选用一个难以扩展的系统，会导致后续并发规模增长过程中无论是时间成本还是经济成本都很高
　　3.逻辑复杂度
　　如果业务逻辑过于复杂，至少NoSQL肯定不是合适的选择，至于MySQL还是Oracle，那是考验二者功能及性能的时候了。
　　4.总容量规模
　　我们的系统数据容量规模自然也会影响到软件选型，规模非常大的，肯定要用分布式系统支持，至少也得分库分表吧，这时候的扩展能力会充分显示出其优势。
　　四.平衡各种资源做出后选择
　　通过软件功能和成本对比，以及“场景分析”，我们已经为系统选型积累到相对充分的信息了，那是不是可以比较明确的选择出合适的系统了呢？
　　这时候我们可能会发现我们的数量规模很大，但是又希望能够维护方便容易控制。这时候我们面临如下问题：数据量规模大选NoSQL更合适，便于维护又是Oracle的优势，怎么办？ 又或者如果我们有这样一个场景：某交易系统，并发量很大，对于数据一致性要求很高，业务逻辑也并不简单，怎么办？Oracle可以为我们提供很好的数据保护，面对复杂逻辑的时候也能有好的性能，但在扩展的时候会面临成本压力。MySQL可以提供较好的扩展方案，而且成本相对会较低，NoSQL无法解决复杂逻辑的业务场景。
　　类似问题可能会频繁出现在我们的架构师面前，需要大家根据各种利弊进行权衡，做好平衡决策，在尽可能满足业务需求的前提下，选择一个更合适的系统。有些时候可能也不得不作出牺牲极少数业务需求来换取系统更大的发展，而不要为了保全某些极端场景的需求而影响整个选型。
　　总结
　　数据存储软件的多样化趋势势不可当，不管是传统龙头的Oracle，还是开源典范的MySQL，以及NoSQL这一新秀，各有其特色，但同样也都有其短板。没有谁是的，同样也没有哪一种架构能应对所有问题。
　　作为一个架构师，我们的选型工作需要做到下面几点：
　　1. 在平时的工作中做好积累，以获得上面的“系统功能对比”和“成本对比”中的信息。
　　2. 在面对具体业务需求的时候，充分挖掘真实的需求，并将各种利弊信息透明化
　　3. 在终决策的时候做好平衡，从需求实现，成本控制以及维护管理多个角度权衡利弊
　　4. 对新技术学习的渴求不能影响选型结果，同样也不能对新技术的使用带有恐惧。
　　Oracle，MySQL 以及 NoSQL，都只是一个软件而已，实际使用效果更多的取决于使用者的能力。一个的使用者能够充分利用其优势避开其软肋，终获得大化的价值。