甲骨文數據庫將被取代Or不可替代

在 IT 業界，甲骨文是一家有著異常鮮明的“工程師文化”特質的公司。這一特質有著多種體現，體現在其創始人及 CEO 拉里·埃里森依然會在一線引領甲骨文的技術方向；體現在甲骨文會拿出全年利潤的一半用于研發（每年研發投入 50 億美元，2014 財年凈利潤 109

億美元）；體現在盡管微軟、SAP、IBM、亞馬遜的公有云紛紛曲線落地中國，而它還在按兵不動，覺得時機不到，而它眼中的時機，不是尋找本地運營商，不 是尋求政府關系，而是做足技術和人員儲備。

　　甚至面對去 IOE、國產化等敏感話題，甲骨文依舊希望讓技術來說話，從技術的立場上說服用戶面對 IT 采購時更加理性。

　　當數據庫領域掀起用開源的數據庫代替企業級數據庫，用 Hadoop、NoSQL 代替關系型數據庫的呼聲后，似乎數據庫領域的去 IOE、國產化也變得不那么遙不可及了，事實是這樣嗎？甲骨文公司副總裁及大中華區技術產品事業部總經理吳承楊對此進行詳細剖析。

　　理性考慮下選擇并非眼花繚亂

　　雖然互聯網公司選擇開源數據庫和 Hadoop、NoSQL 代替企業級數據庫、關系型數據庫的做法讓很多用戶心生萌動，但是以下幾個來自互聯網公司的實例也正說明：作為承上（應用層）啟下（架構層）的基礎，數據庫 （平臺層）的選擇需要異乎尋常的理性，也并不會令人眼花繚亂。作為 SaaS 全球第一的公司，Salesforce 在一年前與和甲骨文簽訂了長達九年的戰略合作，部署 50 臺甲骨文 Exadata（數據庫云服務器）一體機，把其所有底層全部架構到甲骨文上。

　　第二個例子是美國最好的支付公司 PayPal，PayPal 大概有 500 個數據庫，OLTP 交易可以達到 130 個T，并發進程每秒鐘有 12 萬，數據量每 18 個月翻一倍，為了滿足對精準性和安全性的要求，PayPal 選擇了甲骨文的企業級數據庫。

　　而發明 MapReduce、hadoop 的谷歌，雖然掀起互聯網公司引領大數據的熱潮，但是也表示 NoSQL、MapReduce 沒有辦法取代關系型數據庫：在技術層面，它們的業務邏輯在沒有 SQL 的查詢支持下無法工作，NoSQL 無法代替原有的 MySQL。作為替代，它們正在開發 F1 分布式關系型數據庫系統。

　　你要的是松耦合還是緊耦合？

　　其實面對企業級數據庫，用戶選擇替代品的原因也并非一味的“挑戰權威”、為了改變而改變，似乎開源的開放、自由、靈活、低成本也是考慮的重要因素。而面對企業級數據庫，開源是否真的有著這么多的優勢呢？

　　因為同時擁有企業級數據庫產品（已經發展到 12c 版本）和開源的關系型數據庫產品（MySQL），甲骨文的立場當屬中立，它的建議，對用戶來說值得參考。對于這兩條產品線，吳承楊認為各自都有著非常明確 的應用場景：MySQL 主要定位在關聯性、復雜性、可靠性要求不高的非核心交易類的應用上，比如小型企業或者大型企業內部的小部門，MySQL 對復雜 SQL 的支持能力、數據存儲能力及大型應用支持能力有限；而企業級數據庫在高可用性、安全管理、性能診斷、備份、商業支持等方面的優勢迄今依舊是無可替代。

　　在吳承楊展示給記者的一張包含企業級數據庫、MySQL、NoSQL、MapReduce 的對比圖中，結果一目了然。

　　而開源的開放、靈活，也不是沒有限制的，有些時候甚至限制更多。在一些關鍵性應用或者大型應用上，如果一定要使用開源，意味著要把平臺層做的事 情放到應用層。而應用層、平臺層和架構層要想部署成云的環境一定要松耦合，也就是上層不需要考慮下層，有平臺層去考慮。依舊以 MySQL 為例，如要采用 MySQL，一定要在應用層做很多工作，這就變成緊耦合了，意味著的確減少了數據庫的采購和維護成本，但是開發的成本會很大；除此以外，開發時間會很長； 另外，因為所有上層系統都是由開發商來做，用戶會被某一家開放商牢牢鎖定。

　　企業級數據庫三大發展趨勢

　　面對傳統的企業級數據庫與開源數據庫、非關系型數據庫的技術演進和交織博弈，其實也讓甲骨文的企業級數據庫策略變得逐漸清晰。對此，有三個趨勢：

　　首先就是內存化。甲骨文的即插即用型內存數據庫選件 12c In-memory 已經在不久前正式發布，國內也有了第一個內存數據庫用戶。關于甲骨文的內存數據庫產品的特點和特性已經有了非常多的介紹，包括其與友商同類產品的對比，業 界不乏各類聲音。如果以一句最通俗的話來解釋甲骨文的內存數據庫，那就是：在內存、閃存、磁盤三個層面，讓原本跑得慢的東西快起來。（有多快？有結果表 明，通過采用 12c In-memory，甲骨文的主要應用程序 JD Edward、PeopleSoft、E-Business Suite 和 Siebel 的性能提高 100 倍至 1000 倍。）

　　其次就是結構化和非結構化統一。NoSQL 在結構化和非結構化共存方面有很多優勢，在這方面甲骨文有企業級 NoSQL，也有 MapReduce，這也就意味著其大數據解決方案既包含關系型數據庫，也包含非關系型數據庫。

　　另外一個趨勢，也是云計算時代讓企業擺脫傳統的 licence 限制、控制成本的有效手段，那就是數據庫云。DBaaS（數 據庫即服務）在 2013 年的 Oracle OpenWorld 上發布，在 DBaaS 的演進中，有傳統的 RAC（Real Application Cluster）標準化平臺，有 Exadata 數據庫云服務器。數據庫云讓企業按需使用，提高效率、控制成本，甲骨文數據庫 12c 的多租戶特性實現真正的隨時插卸，甚至可以有幾百個可插入式數據庫與應用打交道，實現真正云的管理，這也是甲骨文關系型數據庫非常領先的特質。

　　讓用戶的選擇更理性

　　作為一家“工程師文化”的公司，甲骨文更希望在技術層面給用戶一些理性選擇的建議。對于開源數據庫 MySQL 和企業級數據庫“兩手都要硬”的甲骨文來說，不存在兩條產品線左右互搏的情況，甲骨文會給用戶選擇，只是這一選擇是建立在理性的基礎上。

　　面對客戶的選擇，甲骨文也有無奈之處，吳承楊告訴記者：“很多時候用戶是在選擇開發商，開發商再根據它的喜好去選擇合作伙伴，我們處于被選擇的境地。”

　　而面對國產化的呼聲，甲骨文也有著淡然處之的態度。“市場上出現國產數據庫是件好事，我們贊同國家在國產數據庫上投入和發展，我們也愿意配合。 如果用戶站在理性的立場上選擇了國產數據庫產品，我們也會理解，但是甲骨文數據庫的 RAC 技術在國產數據庫市場很難看到。對于軟件產品來說，其重點在于它的成熟性，而成熟性是通過達到一定量的使用才能實現的。”

　　結束語

　　在吳承楊的介紹中，有眾多有說服力的案例，也有失敗的教訓。據他介紹，今年一家大型 3C 公司邀請國內某家著名公司共同做開源數據庫，其中既用到 MySQL 也用到 NoSQL，但是半年之后系統做出來后與應用沒有辦法很好的結合，最終還是又翻回來采用傳統的企業級數據庫。對于這樣一個實例，并非是要充當血淋淋的反面 教材，而是把用戶在采購決策時的不理性呈現出來。開源、大數據、集成系統、內存計算、數據庫云...面對紛繁的選擇，用戶只有了解，才好決策。而甲骨文要 做的，是讓技術來說話。

                    <span id="shareA4" class="fl">                            
                        </span>