『创业团队最佳选择是Oracle+MongoDB，而不是MySQL』，当深蓝在QQ群里抛出这样的观点的时候，就像是在马蜂窝里丢了一串鞭炮一样热闹起来。
创业者甲: 开什么玩笑，Oracle要收钱的，太贵了，完全不适合创业团队！！
架构师乙: Oracle太重了！对创业团队来说并不合适，哪里见过互联网公司用Oracle的，太扯淡了……
架构师丙: 对啊，谁见过互联网公司用Oracle的啊，行业趋势是去IOE呢，让创业公司主推Oracle这不是逆水行舟么？太坑人了！！
创业者丁: 创业阶段业务量也不是太大，用Oracle完全没必要啊，技术成本考虑也没法选Oracle啊，土豪创业当我没说……
几乎是所有人，压倒性一致的反对深蓝的这一"逆行倒施"的观点。
我们可以看到大家表示非议的几个核心点主要有：
互联网使用开源是行业主流，特立独行的风险很大；
使用费用，而Oracle是要收费的，还不止一点点！！
MySQL完全能支撑初期的业务需求，为啥要用Oracle这么个收费的东西。
互联网公司选择开源或自研，而不是商用，首要的原因是多数商用软件的设计目标并未考虑过互联网公司面临的高并发、海量用户场景，所以根本无法满足基本需求；其次，互联网公司业务变化快，在线业务通常是面向最终消费者，强调用户体验，出现问题需要第一时间及时响应处理。倘若核心技术不是自己深度掌握，很难有足够快速的问题解决能力；最后，公司发展到一定规模之后，使用商业软件会带来不菲的成本支出问题。
但实际上这个问题相对前面两点不算决定性因素，一方面是到了这个规模，也有一定的经济承受能力，另一方面是授权费多少其实都是谈判出来的，通常会远低于零售价格，也不会真正全面采购正版授权：商用软件厂商并不希望把你一次放血搞死，持续吸血才是他们的理想。
但是，开源软件通常缺乏有效的官方技术支持，需要技术团队耗费时间精力；通常开源软件的完善程度也并不算高，需要使用公司投入更多人力完善周边，综合使用成本并不见得很低。当然，这部分开支具有较大的隐蔽性，并且很难具体量化，同时也不需要一次性支出，所以通常会被大家被认为是相比商业软件更便宜的方案。( 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）
作者：深蓝
本文来自云栖社区合作伙伴"DBAplus"，原文发布时间：2016-05-19
