通過阿裡來看大型應用數據庫是選擇Oracle MySQL 還是 NoSQL?

本文我們來看大公司阿裡巴巴如何在常用數據庫 Oracle MySQL 及 NoSQL 中如何選擇來看這幾個數據庫的對比。

作為阿裡引入 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，你只看到了別人希望你看到的內容。