Oracle MySQL or NoSQL 續（cr isky000)

前言

隨著阿里系的“去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，你只看到了別人希望你看到的內容。

轉載自 簡朝陽