一.軟件功能對比
二.成本考慮
三.滿足業務場景
四.平衡各種資源
一.是否滿足業務場景，各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新技術，產品眾多，社區活躍度遠不如前面二者，處于人才極度匱乏狀態