深度推薦：創業團隊為什麼要選擇Oracle而不是MySQL？

『創業團隊最佳選擇是oracle+mongodb，而不是mysql』，當深藍在qq群裡抛出這樣的觀點的時候，就像是在馬蜂窩裡丢了一串鞭炮一樣熱鬧起來。

創業者甲: 開什麼玩笑，oracle要收錢的，太貴了，完全不适合創業團隊！！

架構師乙: oracle太重了！對創業團隊來說并不合适，哪裡見過網際網路公司用oracle的，太扯淡了……

架構師丙: 對啊，誰見過網際網路公司用oracle的啊，行業趨勢是去ioe呢，讓創業公司主推oracle這不是逆水行舟麼？太坑人了！！

創業者丁: 創業階段業務量也不是太大，用oracle完全沒必要啊，技術成本考慮也沒法選oracle啊，土豪創業當我沒說……

幾乎是所有人，壓倒性一緻的反對深藍的這一"逆行倒施"的觀點。

我們可以看到大家表示非議的幾個核心點主要有：

網際網路使用開源是行業主流，特立獨行的風險很大；

使用費用，而oracle是要收費的，還不止一點點！！

mysql完全能支撐初期的業務需求，為啥要用oracle這麼個收費的東西。

mysql是網際網路的行業主流選擇？ 

網際網路公司選擇開源或自研，而不是商用，首要的原因是多數商用軟體的設計目标并未考慮過網際網路公司面臨的高并發、海量使用者場景，是以根本無法滿足基本需求；其次，網際網路公司業務變化快，線上業務通常是面向最終消費者，強調使用者體驗，出現問題需要第一時間及時響應處理。倘若核心技術不是自己深度掌握，很難有足夠快速的問題解決能力；最後，公司發展到一定規模之後，使用商業軟體會帶來不菲的成本支出問題。

但實際上這個問題相對前面兩點不算決定性因素，一方面是到了這個規模，也有一定的經濟承受能力，另一方面是授權費多少其實都是談判出來的，通常會遠低于零售價格，也不會真正全面采購正版授權：商用軟體廠商并不希望把你一次放血搞死，持續吸血才是他們的理想。

但是，開源軟體通常缺乏有效的官方技術支援，需要技術團隊耗費時間精力；通常開源軟體的完善程度也并不算高，需要使用公司投入更多人力完善周邊，綜合使用成本并不見得很低。當然，這部分開支具有較大的隐蔽性，并且很難具體量化，同時也不需要一次性支出，是以通常會被大家被認為是相比商業軟體更便宜的方案。( btw, 商業軟體公司确實應該考慮分期模式，或是引入金融創新應該會帶來更多實際的收入，當然雲計算也算是分期付費的一個變種分支。畢竟現金流對于多數公司而言都是非常關鍵的，細水長流好過一次榨幹呢。)

當然，是培養自己的團隊去填開源軟體的坑，或是發明自己的輪子，還是選擇商用軟體？多數網際網路公司的選擇都是混搭： 能用開源解決的用開源，開源不那麼靠譜的就用商用的頂上，再慢慢找合适的時機替換。

now，讓我們來看看在用oracle或商用資料庫的知名網際網路公司有哪些？

一号店、jd：都是mysql和oracle的混合體系，還買了吊炸天的oracle一體機(一台oracle exadata x5有24t記憶體，576核cpu，價格估計幾千萬到上億人民币)；

蘇甯易購：是ibm一手打造的技術團隊和技術體系，使用的是db2、mysql、oracle的混合體系；

攜程旅行：.net技術為主，是以是以sql server為主、mysql為輔的混合體系；

唯品會：也是mysql和oracle的混合體系；

·····

似乎在用商用資料庫的網際網路公司并不在少數，而且他們都是在核心業務使用oracle。 

另外，我們還可以看到基本全是電商類型的網際網路公司。

當然，看上去他們用商用資料庫執行個體的總占比相對mysql要少得多，而且似乎内部都有在發起減少使用商用資料庫的趨勢。

以衆所周知的阿裡為例，最早是使用oracle來支撐業務的，後來逐漸發起了去oracle的趨勢。

此前，阿裡集團用oracle主要集中在淘寶和支付寶。而實際上據阿裡自己透露，在oracle的license費用相對整個技術團隊支出成本而言并不算多，更多的開支是花在中高端儲存設備，小型機，而這些硬體的維護費用更是一筆不小的開支；然而，去oracle程序也并不是一個輕松的過程。從12年初，阿裡開始部分放棄oracle轉投mysql，到15年雙11，支付寶對外宣布支付寶的核心交易流量不再依賴oracle，共曆時3年多，對mysql進行改造、技術架構優化做出了巨大的投入和努力。期間淘寶和支付寶各自經曆了一次遷移失敗…… 這些都是巨大的研發成本投入！

這個投入本身，遠超出了oracle的license費用以及維護費，與其說是技術團隊的高瞻遠矚做長遠打算，還不如說是阿裡集團已經走到了不得不變的階段，ioe這種第三方廠商提供支援的模式不再能支撐阿裡的業務增長需要，成為了首要的瓶頸；

可以想象，每年雙11，oracle都派人駐場進行技術支援，但始終會因為阿裡未能掌握oracle的技術底層核心實作，會導緻出現無法對潛在問題的風險、影響範圍等進行有效的評估和預案準備；

若問題發生後，阿裡也無法及時有效的解決，隻能完全依賴oracle團隊的技術支援，很容易會出現“船上人不得力，坎上人掙斷腰”的尴尬局面。跨部門協調尚且會有部門牆存在，跨公司合作各種商務溝通，對内對外協調會更加困難。這點相信做過團隊管理的人都多少會有深刻的體會。

這種尴尬的局面對于阿裡這樣體量的公司是完全不能接受的，那種感覺就像是你的xx被别人握着一樣，哪怕那個人是你親爹估計也不會多開心吧？何況還隻是一個拿錢做事的合作夥伴。

可以看出，阿裡有這樣的體量資本，去投入開源優化改造，并且業務規模也迫使他不得不這麼做。而去ioe也并非出于mysql免費，oracle收費這麼簡單的成本考量。

然而對于普通創業公司而言，是否值得跟随一線網際網路公司這樣搞去ioe，選擇mysql以節約成本呢？又或者“oracle+mongodb是創業團隊的最佳選擇“才是更正确的道路？

創業公司有什麼特點？看過網際網路的行業整體情況，尤其是對阿裡技術選擇變遷的背景剖析之後，我們再來看看作為網際網路創業公司的特點是怎樣的：

錢永遠是不夠用的，能省則省；

求快，更快，再快！

招人永遠是心中的痛；

如果不能達到足夠市場占有率後盈利或上市，所有努力都是在浪費時間；

規模小，通常沒利潤，燒錢以求快速發展。

深藍看大家各種吐槽差不多之後，又開始繼續發表自己的觀點：

首先呢，作為創業團隊不要太看得起自己了——你那點肉還真不夠甲骨文律師團隊的工資。能被甲骨文盯上，恭喜你已經有足夠的小身闆了呢，值得出去喝一杯慶祝下……

其次呢，創業公司的技術團隊最大的使命是： 求快！支撐整個團隊比競争對手更快的擴大規模，占領市場！！技術絕不能成為整個創業公司團隊裡最短的那塊木闆。然而，創業公司的目标不是b輪或者c輪，而是上市，這意味着使用者量、業務量要達到足夠大的規模。

我知道你們要說等到那時候公司已經融了足夠錢可以找牛人搞定技術難題。too young，too simple！那隻說明你沒踩過足夠的坑。 知易行難!！在公司業務還要繼續高速發展的大背景下，補上技術欠債這種事，基本是個無底洞，哪裡是一兩個牛人就填得平的坑……

别急，你們是不是想說，如果創業初期就考慮太多，用過重的技術會導緻還沒站穩腳就被對手幹死了！！問題是你們告訴我，隻是單純的資料庫操作，oracle能比mysql複雜多少？

說了那麼多虛的，舉個例子可能會更有說服力一些：

假設有兩個創業公司：亞麻訊和fbay，都幾乎同時發展到b輪，每天的訂單量都也差不多水準，亞麻訊有日均10萬單左右，fbay則領先亞麻訊幾萬單；

同時容我拍腦袋的認為，mysql單執行個體可以支撐日均20萬單的業務量，而oracle單執行個體可以支撐日均100萬單。

亞麻訊一開始選擇的是oracle+mongodb做存儲，而fbay是用mysql+mongodb做存儲，那麼情況應該會是這樣的。

fbay意識到單個mysql執行個體可能很快就無法支撐業務的增長，按照業界主流做法，那需要拆庫拆表，拆業務線，做橫向擴充以支撐更大的業務壓力。拆庫拆表之後又會遇上讨厭的cap理論，分布式事務等等一堆麻煩事，需要組建一個幾十人的soa服務化團隊來做分布式服務架構……總之一堆事，做得快應該一年能 搞個大概出來，這中間快馬加鞭，空中修飛機之類的，斷斷續續的事故不斷。營運每次做促銷活動總得很謹慎的問技術團隊，這個姿勢行不行，那個秒殺會不會又把 系統搞挂了……運氣好應該能來得及趕上業務增長的速度。

亞麻訊的團隊似乎就從容多了，業務團隊天天賣力的使勁變着花樣做活動促銷，反正系統容量瓶頸還有段不小一段距離呢；另一方面技術團隊也開始了未雨綢缪，成立了一個骨幹小分隊，從容不迫的開始來拆庫拆表，拆子系統，服務化這些技術的研究，并有計劃的漸進推進系統改造更新。這時候甲骨文找上門來了，雙方進行了一番”友好“的磋商之後，甲骨文老奸巨猾，想把亞麻訊的技術團隊持續的綁在oracle技術線上，于是開出了一個相對優惠的價格，雙方愉快的一起撸了一頓燒烤……而誰說漂亮說就會死心踏地跟着甲骨文混啦？一轉身，他們就啟動了把非強事務類業務，逐漸從核心oracle執行個體拆到mongodb的遷移工作。

親，知道這兩家這一輪競争下來的結果麼？

fbay發展速度遠遠被亞麻訊甩在了身後，第二年亞麻訊順利拿下c輪融資，而fbay還繼續在c輪魔咒的陰影下掙紮。然而對于競争激烈的網際網路行業而言，不能做細分領域第一第二的公司，最後都隻有死路一條……

對于亞麻訊而言，oracle最大的價值便在于技術團隊通過正确的技術選型為它整個公司争取到了非常寶貴的市場競争時間窗，這時候你們還覺得商用資料庫的授權費很貴麼？天下武功，唯快不破！！

最後得吐槽下，你們現在覺得mysql dba好招麼？因為市場過于稀缺，一個mysql dba的待遇差不多能養兩個oracle dba了……更要命的是還壓根招不到，可愁死我了。

單純從表的資料量而言，mysql的最佳實踐建議是單表百萬級，控制在千萬級内；而oracle單表可以千萬級甚至億級也沒太大問題。而且，mysql從一開始的設計目标便不是為了追求強一緻性事務，這導緻mysql的可靠性和事務性方面就完全和oracle不在一個可比較的級數。高并發壓力情況下，mysql丢資料的機率是遠超oracle的；然而oracle的費用貴是無法回避的事實，oracle資料庫依然是昂貴的稀缺資源。應隻把最核心，同時非常強調資料一緻性的強事務類的業務放在oracle上，用好nosql和分布式緩存，降低核心oracle資料庫的負載壓力。

經平台同意授權轉載

來源：程式源（微信号：agoodjob11）

作者：深藍

<b></b>

<b>本文來自雲栖社群合作夥伴"dbaplus"，原文釋出時間：2016-05-19</b>